Trace-based Just-in-Time Type Specialization for Dynamic Languages

1. Trace-based Just-in-Time Type Specialization for Dynamic Languages Andreas Gal, Brendan Eich, Mike Shaver, David Anderson, David Mandelin, Mohammad R. Haghighat, Blake Kaplan, Graydon Hoare, Boris Zbarsky, Jason Orendorff, Jesse Ruderman, Edwin Smith, Rick Reitmaier, Michael Bebenita, Mason Chang, Michael Franz

2. Dynamic Languages JavaScript, Python, and Ruby They are expressive, accessible to non-experts, and make deployment as easy as distributing a source file JavaScript is the de facto standard for client-side web programming and is used for the application logic of browser-based productivity applications Dynamically-typed (most of them, not all) The types of expressions may vary during runtime Traditional static analysis is too expensive 2

3. Solution: Trace-based Jit Compiler Jit Compiler: a hybrid approach that combines interpreter and static compiler Trace-based compilation - trace: an acyclic path through CFG - schedule traces as if they were basic blocks - need compensation code for off-trace path TraceMonkey: starts running JavaScript in a fast-starting bytecode interpreter, and detects hot bytecode sequences (trace) as the program runs, recording and compiling them into native code. Two assumptions - programs spend most of their time in hot loops - code in hot loops are type-stable

4. Outline Algorithm for dynamically forming trace trees to cover a program, representing nested loops as nested trace trees How to speculatively generate efficient type-specialized code for traces from dynamic language programs Implementation based on the SpiderMonkey JavaScript interpreter

5. Typed Trace • A typed trace is a trace annotated with a type for every variable (including temporaries) on the trace. (type-stable) • Guard instructions to guarantee assumptions, side exit the trace if guards fail • Optimizations achieved: - type specialization - representation specialization: objects, numbers - function inlining • Abort a trace - unpredictable exits - limited memory

6. Trace Tree An extension of typed trace with branch traces A tree always starts at a loop header A tree closes the loop: - at loop header as it started (type-stable) - at a side exit (type-unstable) - at break or return statements (end trace and exit to the trace monitor) Extend a tree with branch starting at side exits (only control-flow branches) Blacklist: avoid checking failed traces again and again

7. Trace Tree Cont. • Unsolved problem • if a loop meets the following conditions • - The VM can form at least one root trace for the loop • - There is at least one hot side exit for which the VM cannot complete a trace • - The loop body is short • Then the overhead exceeds the optimization

8. Nested Trace Tree Formation 1 for (var i = 2; i < 100; ++i) { 2 if (!primes[i]) 3 continue; 4 for (var k = i + i; k < 100; k += i) 5 primes[k] = true; 6 }

9. Trace Tree Optimization Front-end filters - a soft-float filter converts floating-point LIR instructions to sequences of integer instructions - CSE (constant sub-expression elimination) - expression simplification: constant folding .. - source language semantic-specific expression simplification Back-end filters Dead data-stack store elimination Dead call-stack store elimination Dead code elimination

10. Implementation Calling Compiled Traces Trace Stitching Trace Recording Preemption Calling External Functions

11. Evaluation

12. Evaluation cont. Outperform the fastest available JavaScript compiler (V8) and the fastest available JavaScript inline threaded interpreter (SFX) on 9 of 26 benchmarks

13. Related Work Trace optimization for dynamic languages General trace optimization Type specialization for dynamic languages Native code generation by interpreters