Download TraceMonkey

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
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
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 typespecialized code for traces from dynamic language
programs
 Implementation based on the SpiderMonkey
JavaScript interpreter
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
5
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
2
3
4
5
6
for (var i = 2; i < 100; ++i) {
if (!primes[i])
continue;
for (var k = i + i; k < 100; k += i)
primes[k] = true;
}
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