THIS PAGE IS OBSOLETE
	This article is in parts, or in its entirety, outdated. Hence, the information presented on this page may be incorrect, and should be treated with due caution. Visit SpiderMonkey.dev for more up to date information.

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.

Major Optimizations

[Updated 4 May 2010]

First, how far do we have to go? The rough numbers on our reference machine are (arewefastyet.com):

Now, how do we get there?

A (*) means the improvement value is just a guess. Values without stars are based on some kind of measurement.

Description and comments for each item:

• Globals. This means optimizing global variable access with fast paths. dvander has already started this and has wins of 50/500 ms (SS/v8) so far.
• Regexes. There are some regexes we don't compile in SunSpider and v8. There is only one in SunSpider and it would not be hard to extend our current compiler to handle that case. v8 has more, and we don't know which ones count yet and what features are needed.
  The regex project could be completed either by improving our regex compiler, or just taking yarr from JSC. The latter should be preferred if possible. The licensing on yarr is OK, but it uses vector and unicode classes that are GPL and would need to be replaced.
• Strings, Dates, Math. These are key runtime functions. They may be very fast already, or we might have some functions that are slower than they could be. We are doing measurements now.
• jsvals. This is the 128-bit jsvals. This may not turn out to be a huge speedup all on its own, but together with the compiler fast paths it will be very important.
• Compiler fast paths. This means making the JIT inline all commonly run ops. There are probably about 50 of them. This is partially blocked on the new jsvals, because the code generation depends somewhat on the jsval format. But we could start these before finishing the jsvals are done, and patch things up as needed.

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.

Integrated TM and JM.

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 in Mercurial at http://hg.mozilla.org/projects/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