Subj : Re: Spidermonkey JIT
To   : Peter Paulus
From : Brendan Eich
Date : Thu Apr 21 2005 02:25 pm

Peter Paulus wrote:
> Michael Ten-Pow wrote:
> 
>> Has there been any recent effort to write a JIT compiler for 
>> Spidermonkey?  If not, do people agree that this is worthwhile?  It 
>> seems as though more and more applications are now built solely upon 
>> JS.   Like Mr. Eich has said, the Parrot JIT interface is a 
>> possibility, as is  libjit.  Licensing issues do exist though.


Beyond licensing, SpiderMonkey's runtime and API are about ten years 
old, if you squint.  People wouldn't want the JIT to require rewriting 
native functions to, e.g., use a GC write barrier.  Native methods 
matching the JSNative signature must be called with valid JSStackFrames, 
not only for debuggers, but for security checks (annotation, the down 
link, script->principals; fortunately, we can reorganize JSStackFrame to 
improve the JIT's life, as that struct is not part of a public API).

This API compatibility says that reusing an existing JIT may be less of 
a help than it might seem.

Then there are the dynamic type issues that JITs for other languages may 
not have to sweat.

Still, it would be a fun project.  If done well, esp. in Mozilla XUL app 
contexts, if done so that calls from JITted code to XPConnected native 
DOM and other C++ methods involved no extra layers of native stack 
frame, and if the right debugging information were generated along with 
the native code, it might yield the holy grail for XUL+Mozilla hackers: 
integrated debugging in one's favorite debugger.


> A general remarks about our QuarkXPress plugin that allows you to 
> javascript QuarkXPress (about 45 host objects, C++), is that is running 
> too slow. I've been doing some profiling to determine bottlenecks.
> 
> Most of the time spent is in the QuarkXPress API. So I've been 
> optimizing around that code. But I've been wondering what the effect of 
> javascript JIT would be for our plugin.


Couldn't you bound that?  If time spent in the JS engine, including the 
GC, is 1/n of the critical path, then you know not to bother if n is 
large enough, or even if if n is small but the JIT speedup wouldn't make 
it that much bigger.


> I've been playing with the idea to build this myself, but it is way too 
> far from our core business (I'm not granted the time for it). To gain 
> some insights though, I started developing a bytecode disassembler based 
> on a vistor design pattern. But after about 2 days work was abondoned, 
> because of other more pressing matters. The visitor could be used as a 
> start for a jit-compiler.
> 
> This has resulted in a (far from complete) disassembler.


BTW, SpiderMonkey includes disassembly code, #ifdef DEBUG.  See the 
Disasesmble native function in js.c, follow its callgraph.

/be

.