Saturday, February 27th, 2010

Mozilla JägerMonkey: Method based JIT + Trace based JIT = speed

Category: JavaScript, Mozilla, Performance

<>blockquote>

David Anderson: “TraceMonkey has rocket boosters, so it runs really fast when the boosters are on, but the boosters can’t always be turned on.”

Opera’s new JIT compiler Carakan is doing well as we just posted. What is Mozilla doing with TraceMonkey? A lot.

Mozilla JägerMonkey adds method based JIT (of V8 and Nitro fame) to keep the boosters on.

We learn more from David Mandelin and David Anderson.

Related Content:

Posted by Dion Almaer at 12:05 am
4 Comments

++++-
4.6 rating from 24 votes

4 Comments »

Comments feed TrackBack URI

I’m very impressed with this release. Doing tests with a sample of complex commands (vector and pixel based), it looks like Opera is in fact the fastest browser around for .

Comment by mudx — February 27, 2010

It’s a clever little idea to get Firefox out of the JS performance slump they’ve been in. Tracing seems awesome on paper, but the relative paucity of code which is traced has been problematic. There are the occasional benchmark where FF just creams V8/Nitro, but it seems pretty rare that tracing actually gets to take over from the (admittedly pretty sophisticated) interpreter.

That said I don’t envy the team that has to maintain two in-tree assemblers, one of which is externally maintained. Still, if they can pull it off smoothly, with fast transitions between Tracing/nanojit and Inline/nitro this will be really lovely. Does anyone know if some version of this is planned for 3.7, or for a later release? It would seem pretty ambitious . . .

Comment by erikharrison — February 28, 2010

erikharrison: two assemblers does sound like too much work (it did to me at first), but it’s not really that bad on closer analysis: the assembler from WebKit (JavaScriptCore’s Assembler subtree) is stable and well-maintained upstream, while NanoJIT is an ongoing and increasingly stable collaboration with Adobe that we’ve been investing in since TraceMonkey started.

These two assembler-like subsystems really do have different requirements and designs, so there will not be only one assembler in any system with tracing and fast inline/call-threaded JITting. For example, tracing assembles backwards up the previous-instruction-linked intermediate form generated and processed in forward order during trace recording, doing register allocation and other passes that JaegerMonkey doesn’t need or want.

Anyway, it’s great to have the JaegerMonkey team finally fixing all the non-tracing performance issues in SpiderMonkey — my monkey from 1996. It is evolving as monkeys do, finally getting some longer legs for running on level ground, or anywhere the [trace] trees are not shaped well enough to swing by its very long TraceMonkey arms ;-).

It should be possible for the JaegerMonkey JIT to generate code that runs as fast as V8 and JSC (assuming we pay off other technical debt in our garbage collector), so TraceMonkey on top of JaegerMonkey should put us ahead, finally delivering on the promise of tracing. We’ll see…

/be

Comment by BrendanEich — March 1, 2010

BrendanEich: I’m very excited about the project. I have some questions about the interaction between the two assemblers, but it’s pure geeky curiosity. It’ll be nice to see the whole Firefox platform running on top of the fastest JS engine once again.

Comment by erikharrison — March 1, 2010

Leave a comment

You must be logged in to post a comment.