313
edits
Changes
no edit summary
--damons, IRC<br></blockquote>JaegerMonkey (or JägerMonkey) is '''inline threading''' for SpiderMonkey. The rest goal is to get reliable baseline performance on the order or other JS JIT systems. "Inline threading" really just means a baseline whole-method JIT that doesn't necessarily do many traditional compiler optimizations. Instead, it does dynamic-language-JIT-oriented optimizations like PICs and specialization of this wiki page presents our initial development planconstant operands.
[https://bugzilla.mozilla.org/show_bug.cgi?id= First Deliverable =536277 Bug 536277] is the meta bug for this project.
An inline/call-threaded version of TraceMonkey where: *Inline-threaded part is integrated well with tracing. I.e., we can jump efficiently from inline-threaded code to the trace monitor, and from a trace exit back to inline-threaded code.*With tracing jit OFF, JaegerMonkey is epsilon faster than basic SM.
*With tracing jit ON, JaegerMonkey is not slower than basic TM (on SunSpider, etc.)
Once this is in place, we can then make it faster and faster by adding more optimizations.
= Design Decisions =
The general idea is to do something along the lines of dmandelin's first prototype, Sully's prototype, and Nitro. The important design specifics that we're planning to go with for now are:
1. Do everything per-thread, just like TM does with traces.
2. For the native code generator, take Nitro's cross-platform<br> "assembly blatter".
3. To make trace transitions fast, change the interpreter and trace<br> stack layouts so they closely match.
Discussion on point 2 (code gen):
We considered and rejected these alternatives for the code generator:
2x1. Generate code blocks ahead of time and memcpy blocks together to create native code. I tried this at the beginning of my first prototype, and it didn't work very well. One problem is that relative jump displacements need patching, so this isn't as simple as it first seems. Also, in order to get good perf, you need to<br> bake in constants and do other specialization, which requires increasingly complicated patching.
Adobe is doing an interesting research variant on this idea, where they compile the interpreter C code to LIR, compile that, and then memcpy (and presumably patch) those chunks. But this sounds<br> too complicated and risky for us.
2x2. Generate LIR and compile with nanojit. Sully did this. The main problem is that there is not enough control over the results to get the best code. In particular, there are tricks for calling "stub functions" (functions that implement JS ops that are not inlined) very efficiently that nanojit doesn't currently support. We think there will be other tricks with manual register allocation and such that are also not currently supported. We don't want to<br> gate this work on nanojit development or junk nanojit up with features that will be non-useful for it's current applications. Also, the compilation time is much longer for LIR than for using an assembler.
2x3. Roll our own assembler. This just sounds like extra unnecessary work if we can just use Nitro's.
More detail on point 3 (stack layouts):
Ideally, the interpreter stack layout would be identical to the on-trace stack layout, so that no importation or conversions are necessary. Of course, the interpreter requires type tagging but tracing must not have<br>type tagging, so we have to compromise a little bit.
Luke's current idea is to have the interpreter use two chunks of stack memory. One will have unboxed values. The other will have type tags, and any other metadata the tracer doesn't care about. Allocating<br>stack slots or frames will be just two pointer bumps and a bounds check. In inline-threaded code, 2 registers can be reserved to point to a known position (e.g., start of active frame), so that stack accesses are just a machine load or two (for the tag). Values will be boxed in the current SM style when they are stored to object slots.
The layout of the unboxed stack will be the same in the interpreter or on trace. To get this, we mostly have to delete or move out of band the extra fields in JSStackFrame. We will need to reorder a bit too. Once<br>we have that, to enter trace, we do no work, and to leave trace, we just memcpy typemaps into the interpreter type tags stack.
= Planned First Steps =
The first two chunks of work are to get the stack frame layouts to match, and to import the Nitro assembler. We should be able to do these in parallel, but they block most further work.
Luke is already starting the stack frame layout work. We hope to be able to mostly complete that in a week-long "sprint" in early/mid January. By "sprint", I mean focusing as much as possible on that task for the week,<br>and closely collaborating with each other.
After that, the next step is to get up a basic call-threaded system that doesn't necessarily inline much or optimize anything. The main pieces here are to figure out how to track and manage the compiled code, and<br>do the easy thing to get control flow and calling stub functions working.<br>We hope to be able to do a lot of this in one or two further sprints.
At this point, we can start adding optimizations, and this should parallelize well.
= <br>Planned Optimizations =
#Fast calls to stub functions. This is based on a trick that Nitro uses. The idea is that stub functions logically have an array parameter or several parameters, which include input jsvals and also interpreter stuff like the sp, fp, cx, etc. Much of this is constant so the call can be made fast by setting up an area in the C stack with all the arguments filled in. To make a call, we just have to store the input jsvals and do a call instruction.#Fast paths for all common ops. For all common JSOPs, we need to inline the common cases as a fast path, and only call stub functions for slow or rare cases. This can be done incrementally, op by op.#PIC. This is really a subset of item 2. In fact, "PIC" is a bit wrong, because as Andreas pointed out, we can start by inlining fast paths that access/guard against the property cache.#Eliminate PC update. In an inline-threaded interpreter, we don't need to update the PC, because EIP encodes that. To enable this, we have to make sure no ops snoop the PC. We also need to help the GC/decompiler by making sure we have some way to provide them a PC (using a mapping or something) on demand.
#Eliminate SP update. Inside basic blocks of JSOPs, we shouldn't need to keep a proper stack. Instead, we can teach the compiler to track which logical stack element is in which register and generate faster code.
<br>
