Main menu:

Site search

Categories

Archive

JägerMonkey & Nitro Components

After our recent blogs about JägerMonkey, some articles out there gave the impression that we were removing nanojit, throwing everything away, or doing all sorts of other radical things that we are not in fact doing. I don’t have a huge problem with that–this is complicated stuff and it’s hard to get right. So Chris Blizzard made a post correcting some of the misconceptions. I thought it might also be easier to see what we’re doing in a picture of the major system compoents of SpiderMonkey, TraceMonkey, JägerMonkey, and Nitro:

The size of each box is proportional to the number of lines of code in that component. (I just measured the file size, including comments and whitespace. LOC is a rough measure of complexity anyway, so it doesn’t matter much.)

(By the way, I might have the JSC/Nitro terminology wrong; I’m not sure exactly what they call the different parts. I’m using “Nitro” to refer to the method JIT, and JSC to refer to the other parts of the engine, but Nitro might actually be a name for the whole engine that includes the method JIT. There is a similar ambiguity in the use of SpiderMonkey/TraceMonkey in Mozilla.)

The key point is that the only piece of WebKit that we are importing is the assembler, which we are using beneath our method JIT. We need our own method JIT because the method JIT’s job is to translate bytecode to cross-platform assembly, and SpiderMonkey and WebKit each have their own bytecode. Also, the generated code interfaces heavily with the giant green box (which implements strings, arrays, regular expressions, dates, etc), which is different for each system.

Note also that we are definitely keeping TraceMonkey, because it has excellent performance on the right kind of code. There is no simple description of the “right kind of code”; one of the main reasons we are doing JägerMonkey is to provide more predictable high performance. JägerMonkey and TraceMonkey are going to work together, TraceMonkey running when it can and JägerMonkey when it must. We’re working on that right now–they work together for basic cases already, and we should have even advanced tracing, such as recursion, working with JägerMonkey soon.

Comments

Comment from FP
Time: March 16, 2010, 12:55 am

Is it the intention (in the long-term) to keep both nanojit and nitro or will you be looking at altering one of them to perform both roles?

Comment from pd
Time: March 16, 2010, 4:57 am

I read other explanations and this one makes more sense, thanks!

What though is the motivation behind all this clarification? It seems like Mozillans are desperate to deny throwing out all existing code and adopting WebKit’s code, or vice versa.

Why is there so much one-upmanship in FOSS? Everyone knows the code is free but then there’s seemingly this sneering at one side or the other if a developer uses some other projects code. Seems quite childish and makes me wonder whether FOSS is as much motivated by the pissing contest mentality as it is about producing the best possible mousetrap.

Comment from njn
Time: March 16, 2010, 3:46 pm

Great diagram!

Pingback from Mozilla dá mais detalhes sobre a nova engine JavaScript
Time: March 17, 2010, 3:01 am

[…] A Mozilla usa um método diferente do adotado pela Apple e Google. Estas compilam 100% do código JavaScript. A Mozilla compila trechos (“tracing”). O código gerado através de tracing é mais eficiente, mas nos pontos onde não pode ser usado é acionado o tradicional e lento interpretador de JS. O que muda agora é que nos locais onde o tracing não é possível será usado uma abordagem como a da Apple.” [referência: blog.mozilla.org] […]

Comment from Tobi
Time: April 3, 2010, 5:58 am

I think there is one thing that hasn’t been asked/answered yet.

Which Firefox version is Jägermonkey going to land on? 3.7 or later?

Anyway, great idea, great work, thanks to get Firefox back to where it is supposed to be (in terms of Speed) =)