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

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

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

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

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

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 }

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

Implementation  Calling Compiled Traces  Trace Stitching  Trace Recording  Preemption  Calling External Functions

Evaluation

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

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