This new JIT infrastructure, will feature SSA compiler intermediate representations which will facilitate advanced optimizations such as type specialization, function inlining, linear-scan register allocation, dead-code elimination, and loop-invariant code motion.
Main driving forces for IonMonkey are to:
- Provide a backend that can match or beat the Trace JIT or Crankshaft in speed. Sub-goals:
- Fine-grained specialization and de-specialization.
- Integration with type inference.
- Clean, textbook IR so optimization passes can be separated and pipelined with well-known algorithms.
- Document and comment well so the implementation and its side effects can be easily understood.
- Recompilation, debugging, bailouts are all related - and should be solved up-front.
- First SpiderMonkey JIT that starts off with peer reviews!
- (Unknown feasibility) Act as a baseline compiler to replace JM2.
- Manage memory much better, in part to avoid range problems on x64.
InfoQ had a small Q&A with Lead Developer David Anderson, about IonMonkey:
The other side of this challenge is getting that type information extremely quickly. Users would be pretty unhappy if the browser froze for a few seconds because a really heavy analysis was running on their webmail app. Even for benchmarks (which are often short-running) the analysis time tradeoff can be delicate.
A good engine is able to internally group objects that look the same, sort of extracting an internal Java-like class out of them. The JIT can then treat the object as having an actual type, generating super fast code that avoids an expensive property lookup.
InfoQ: What will be the key differences between IonMonkey and Crankshaft which is used by V8?
David: It helps to note that IonMonkey is a long-term investment for us. Firefox already has two JITs, and with IonMonkey that makes a third. V8 also has three. At this rate we'll have added a new JIT every year.
We want to consolidate, and have IonMonkey be the single platform for all our optimization work and research, giving it a "speed" or "scenario" knob that can be adjusted depending on the situation. This also means, like JaegerMonkey, we're paying special attention to sharing almost all our code across x86, x64, and ARM, and I think we're the only open-source engine to do this.
InfoQ: How does IonMonkey compare to the compilation infrastructure of other dynamic languages?
David: LuaJIT and PyPy come to mind - both are pursuing trace compilation, which is a very aggressive specialization strategy also featured in TraceMonkey, our first JIT. The problems to solve are very similar. You have to be able to recover the dynamic program state from highly optimized code, and often deoptimize if you were too aggressive. Both LuaJIT and PyPy have a flexible intermediate representations to work with, and that's the foundation we are building.