JaegerMonkey

This is the coder's badge of glory, That he protect and tend his monkey, Code with honor, as is due, And through the bits to God is true. --damons, IRC

JaegerMonkey (or JägerMonkey) is a new method JIT for SpiderMonkey. The goal is to get reliable baseline performance on the order of other JS JIT systems. JM will be 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 constant operands.

Bug 536277 is the meta bug for this project.

Planning

First Deliverable

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.

Ongoing Work

Completed Work

Imported the Nitro assembler and verified that it works with a basic test harness and the beginnings of the compiler.

JS stack cleanup and simplification. See Bug 536275.

Basic method JIT compiler with about 20 fast paths.

PIC, in rough form.

Current Work

Upgrade the compiler to hold values in registers and avoid stack and other memory traffic.

Change the basic jsval to a 128-bit format with values unmodified (no masking or shifting) in the top 64 bits.

Finish PIC.

Next Steps

Better global variable access.

Better closure variable access.

Cheaper transitioning on and off trace.

More method compiler fast paths.

Developing JaegerMonkey

Getting the Code

The code is currently in a user repo:

http://hg.mozilla.org/users/danderson_mozilla.com/jaegermonkey/ 

Building

Currently we only support shell builds. To build with JM, pass this option to configure:

--enable-methodjit

For debug spew, you can add --enable-methodjit-spew. It is enabled by default if you also specified --enable-debug.

For more information on building, see Building SpiderMonkey.

Running

Use the -m option to run with the method jit turned on. You can learn more about debug spew with:

 JMFLAGS=help /path/to/js -m

Design Discussion

Initial 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 "assembly blatter".

3. To make trace transitions fast, change the interpreter and trace 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 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 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 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 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 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 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 Optimizations

1. 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.
2. 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.
3. 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.
4. Fast transition to and from traces. There are parts to this goal. First, a simpler stack layout will allow traces, Jäger, and interpreter to execute on the stack, instead of using separate stacks with copying back and forth. Second, we can use PIC-like techniques to make trace lookup fast. Third we can separate the type tags from values on the VM stack so that, when we enter trace, the required type checking reduces to a memcmp and, when we leave trace, the type restoration reduces to a memcpy.
5. 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.
6. 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.
7. Fast closures. This is important for advanced web apps as well as Dromaeo and the V8 benchmarks. See bug 517164.
8. Fast global variable access. We should get globals closer to being a slot access. See bug 548844
9. Faster arguments access. fp->argv[0] should be a compile-time static offset from fp. See bug 539144