JägerMonkey: the “halfway” point
JägerMonkey has reached a halfway point: we’ve closed about half the performance gap between our baseline performance (with no tracing) and the competition. You can see this on arewefastyet.com, a site David Anderson created to track our progress. Thanks also to the anonymous contributor who gave us an improved page design.
So far. That improvement represents about 6-8 weeks of work. Major performance improvements we did during that time:
- Polymorphic inline caching (PICs) for object property access. We actually had a pretty good system for optimizing properties before, the property cache. But the property cache requires calls to C++ functions, taking us off the super-fast native jit code. PICs are similar to the property cache, but are more amenable to jit code.
- More compiler “fast paths”. There are two basic ways to implement an operation in a compiler like JM: either calling out to a C++ “stub function”, or inline with the jit code in a “fast path”. We added fast paths for more operations, so we can potentially run about 80% of the operations in the SunSpider/v8 benchmarks in pure jit code. (We’re aiming for 95-99%.)
- Register allocation and local optimizations. We’ve enhanced the compiler so that it uses machine registers more efficiently, trying to hold values in registers and reuse them instead of always loading from and storing to memory.
- Improving global variables. This one is still in progress, but we’ve already posted some perf wins from it. We’re completely overhauling the way global variable accesses are resolved and compiled to make them the fastest they can be in a JM-style system.
I want to add that we’ve referred to JSC (WebKit’s JS engine) and V8 frequently. We’ve been striving to build on what’s been figured out already rather than rediscovering everything. In particular, we took a lot of the design ideas for PICs and globals from JSC, and some more design ideas for PICs and the concept for register allocation from V8. So, credit and thanks to the JSC and V8 teams and their open source efforts.
Next. We have a ton of work left to do, and it’s not easily summarized, so I’ll just mention some highlights.
The new values are planned to be 128 bits, with a full 64-bit payload. Thus, floating-point numbers can be stored directly in the value. Also, the tag bits are off to the side so they don’t have to be added or removed with bit operations.
Strings and regular expressions are also scheduled to get some attention soon.
Final thought. The other big piece of work starting now is to get JägerMonkey to work inside the browser. You can build a browser with JM today, but you probably won’t get too far before crashing. Fixing that is next on my list.