Copyright ©c 2009 ACM 978-1-60558-392-1/09/06...$5.00 or that the same types will occur in subsequent loop iterations. PLDI’09,June 15–20, 2009, Dublin, Ireland. trace, it cannot guarantee that the same path will be followed to lists, requires prior specific permission and/or a fee. one mapping of values to types. When the VM executes a compiled on the first page. To copy otherwise, to republish, to post on servers or to redistribute Each compiled trace covers one path through the program with for profit or commercial advantage and that copies bear this notice and the full citation classroom use is granted without fee provided that copies are not made or distributed ficiently compiled traces. Permission to make digital or hard copies of all or part of this work for personal or the program execution with a small number of type-specialized, ef- both of these expectations hold, a trace-based compiler can cover ters that start as integers to remain integers for all iterations. When values are invariant. (12) For example, we would expect loop coun- expect hot loops to be mostly type-stable, meaning that the types of example, is the de facto standard for client-side web programming their time in hot loops. Even in dynamically typed languages, we small scripts as well as for complex applications. JavaScript, for choice is based on the expectation that programs spend most of deployment as easy as distributing a source file. They are used for piler operates at the granularity of individual loops. This design ular since they are expressive, accessible to non-experts, and make Unlike method-based dynamic compilers, our dynamic com- Dynamic languages such as JavaScript, Python, and Ruby, are pop- quence of instructions a trace. 1. Introduction them, and compiles them to fast native code. We call such a se- identifies hot (frequently executed) bytecode sequences, records Keywords JavaScript, just-in-time compilation, trace trees. fast-starting bytecode interpreter. As the program runs, the system mode execution approach: the system starts running JavaScript in a mance. formance of the generated machine code. Our system uses a mixed- General Terms Design, Experimentation, Measurement, Perfor- languages that reconciles speed of compilation with excellent per- guages]: Processors — Incremental compilers, code generation . We present a trace-based compilation technique for dynamic Categories and Subject Descriptors D.3.4 [ Programming Lan- a web browser. and hence not well suited for the highly interactive environment of programs. mized machine code, traditional static analysis is very expensive have measured speedups of 10x and more for certain benchmark ence might be able to gather type information to generate opti- a dynamic compiler for JavaScript based on our technique and we potential type combinations. While compile-time static type infer- ered alternative paths through nested loops. We have implemented must emit slower generalized machine code that can deal with all elegant and efficient way of incrementally compiling lazily discov- on one specific type. Without exact type information, the compiler method provides cheap inter-procedural type specialization, and an easily transform operations into machine instructions that operate tual dynamic types occurring on each path through the loop. Our may vary at runtime. This means that the compiler can no longer generates machine code on the fly that is specialized for the ac- gramming language such as JavaScript, the types of expressions that identifies frequently executed loop traces at run-time and then tion to generate efficient machine code. In a dynamically typed pro- ternative compilation technique for dynamically-typed languages Compilers for statically typed languages rely on type informa- handle all possible type combinations at runtime. We present an al- chines must provide a low startup time and high performance. is available, traditional compilers need to emit generic code that can experience and enable a new generation of applications, virtual ma- pile than statically typed ones. Since no concrete type information laboration Suite. In this domain, in order to provide a fluid user Dynamic languages such as JavaScript are more difficult to com- applications such as Google Mail, Google Docs and Zimbra Col- and is used for the application logic of browser-based productivity Abstract {mbebenit,changm,franz}@uci.edu University of California, Irvine + {mohammad.r.haghighat}@intel.com Intel Corporation $ {edwsmith,rreitmai}@adobe.com Adobe Corporation # {gal,brendan,shaver,danderson,dmandelin,mrbkap,graydon,bz,jorendorff,jruderman}@mozilla.com Mozilla Corporation ∗ Jesse Ruderman ∗, Edwin Smith #, Rick Reitmaier #, Michael Bebenita +, Mason Chang +#, Michael Franz + Mohammad R. Haghighat $, Blake Kaplan ∗, Graydon Hoare ∗, Boris Zbarsky ∗, Jason Orendorff ∗, Andreas Gal ∗+, Brendan Eich ∗, Mike Shaver ∗, David Anderson ∗, David Mandelin ∗, Languages Trace-based Just-in-Time Type Specialization for Dynamic ----------------Page (0) Break---------------- Section 8. In Section 7 we evaluate our dynamic compiler based on iteration: JavaScript is described in Section 6. Related work is discussed in Here is the sequence of events broken down by outer loop Our implementation of a dynamic type-specializing compiler for the first iteration. to generate efficient machine code from recorded bytecode traces. entering the loop, so the second crossing occurs immediately after compilation based speculative type specialization approach we use that the way our loops are compiled, the loop edge is crossed before ber of individual trace trees. In Section 5 we describe our trace- executed until a loop becomes hot, currently after 2 crossings. Note we describe our approach of covering nested loops using a num- the trace monitor counts the number of times each loop back edge is ture and compile frequently executed code regions. In Section 4 trace. At the start of execution, there are no compiled traces yet, so a general overview of trace tree based compilation we use to cap- the trace monitor , which may decide to record or execute a native The remainder of this paper is organized as follows. Section 3 is When the interpreter crosses a loop edge, TraceMonkey invokes code interpreter. Every loop back edge is a potential trace point. speedups on many programs. TraceMonkey always begins executing a program in the byte- on the SpiderMonkey JavaScript interpreter, achieving 2x-20x transitions between the loops. •We validate our tracing techniques in an implementation based which describes the activities TraceMonkey performs and when it with nested loops. The narrative should be read along with Figure 2, code for traces from dynamic language programs. program, shown in Figure 1, computes the first 100 prime numbers •We explain how to speculatively generate efficient type-specialized how TraceMonkey executes an example program. The example cover a program, representing nested loops as nested trace trees. This section provides an overview of our system by describing •We explain an algorithm for dynamically forming trace trees to 2. Overview: Example Tracing Run This paper makes the following contributions: derMonkey, with a 2x-20x speedup for traceable programs. Section 9 and an outlook on future work is presented in Section 10. Monkey. TraceMonkey supports all the JavaScript features of Spi- a set of industry benchmarks. The paper ends with conclusions in terpreter, SpiderMonkey. We call the resulting tracing VM Trace- We implemented these techniques for an existing JavaScript in- tool to type specialize even complex function call-rich code. code until the loop is done. optimization setting. This makes tracing an attractive and effective edge are the same as the types on entry–then TM can stay in native timizations that would require interprocedural analysis in a static the white boxes. The best case is a loop where the types at the loop Thus, our tracing VM efficiently performs the same kind of op- maximize time spent in the darkest box and minimize time spent in they can be optimized in linear time by a simple compiler (10). boxes are overhead. Thus, to maximize performance, we need to fects of inlining. Because traces have no internal control-flow joins, light gray boxes, TM executes JS in the standard interpreter. White cross function call boundaries, our techniques also achieve the ef- ity. In the dark box, TM executes JS as compiled traces. In the gram to nested, type-specialized trace trees. Because traces can Monkey and the conditions that cause transitions to a new activ- These techniques allow a VM to dynamically translate a pro- Figure 2. State machine describing the major activities of Trace- duplication. number of loops nested to any depth without causing excessive tail the outer trace as normal. In this way, our system can trace any Compiled T race the call to the inner tree as part of the outer trace and finishes Leave existing trace the trace tree for the inner loop. If the call succeeds, the VM records no existing trace side exit to side exit, the outer loop reaches the inner loop header, the system tries to call loop, but then it starts a new trace at the outer loop header. When LIR T race Compiled T race The system stops extending the inner tree when it reaches an outer Compile Execute trees. Our system traces the inner loop exactly as the na ̈ıve version. same types We solve the nested loop problem by recording nested trace loop header loop edge with fi nish at on ever tracing outer loops. LIR T race Compiled T race cache. Alternatively, the VM could simply stop tracing, and give up loop/exit Record Enter hot of unintended tail duplication, which can easily overflow the code ready recording and type combination in the inner loop. In essence, this is a form Monitor compiled trace abort But this requires tracing a copy of the outer loop for every side exit loop/exit Native thus tracing the outer loop inside a trace tree for the inner loop. edge cold/blacklisted loop Interpreting could continue tracing until it reaches the inner loop header again, inner loop header, but the outer loop header. At this point, the VM Bytecodes Overhead Interpret try to record a branch trace, and find that the trace reaches not the Symbol Key VM would detect that a different branch was taken. The VM would the VM would start tracing there. When the inner loop exits, the a na ̈ıve implementation, inner loops would become hot first, and Nested loops can be difficult to optimize for tracing VMs. In snippet. records a trace tree covering all the hot paths through the loop. initialized to an array of 100 false values on entry to this code trace starting at the exit to cover the new path. In this way, the VM Figure 1. Sample program: sieve of Eratosthenes. primes is trace exits. If an exit becomes hot, the VM can record a branch flow is different, or a value of a different type is generated), the 6 } to validate the speculation. If one of the guards fails (if control 5 primes[k] = false; Every compiled trace contains all the guards (checks) required 4 for (var k = i + i; i < 100; k += i) iterations of the loop. 3 continue; typing will be exactly as they were during recording for subsequent 2 if (!primes[i]) Hence, recording and compiling a trace speculates that the path and 1 for (var i = 2; i < 100; ++i) { ----------------Page (1) Break---------------- 16 The result is a native code fragment that can be entered if the for the outer loop, T . native code using the recorded type information for optimization. 1, and at which point TraceMonkey finishes and compiles a trace After recording is finished, TraceMonkey compiles the trace to the current trace. Recording continues until execution reaches line loop header on line 4. was successful and then records the call to the inner trace as part of loop header or exits the loop. In this case, execution returns to the and then returns to the recorder. TraceMonkey verifies that the call TraceMonkey stops recording when execution returns to the trace as a subroutine. This executes the loop on line 4 to completion trace has the required program semantics. inner loop inside the current trace. The first step is to call the inner Thus, on later executions, if and only if all guards are passed, the ready has a compiled trace, so TraceMonkey attempts to nest the and types are identical to those observed during trace recording. Monkey observes that it has reached an inner loop header that al- encodes guards, which are checks that verify that the control flow Monkey starts recording. When recording reaches line 4, Trace- ations performed and the types of all operands. The LIR trace also i=3. Now the loop header at line 1 has become hot, so Trace- ate representation we call LIR. The LIR trace encodes all the oper- TraceMonkey returns to the interpreter and loops back to line 1. 45 records the code along the trace in a low-level compiler intermedi- i and k are integers, and primes is an object. After compiling T , ters recording mode on line 4. In recording mode, TraceMonkey covers lines 4 and 5. This trace can be entered if the PC is at line 4, 45 lines 4-5 becomes hot on its second iteration, so TraceMonkey en- trace recording was started. The first trace in our example, T , i=2. This is the first iteration of the outer loop. The loop on interpreter PC and the types of values match those observed when execute for the same code snippet, including 4 indirect jumps. would ever be taken. The 17 instructions generated by the compiler compare favorably with the 100+ instructions that the interpreter would to a single x86 instruction. Instructions marked with (*) would be omitted by an idealized compiler that knew that none of the side exits Figure 4. x86 snippet for sample program. This is the x86 code compiled from the LIR snippet in Figure 3. Most LIR instructions compile jmp epilog // jump to ret statement mov esp, ebp // restore esp mov ecx, ebp(-4) // restore ecx side_exit_1: ... je side_exit_2 // (*) side exit if call failed test eax, eax // (*) test return value of js_Array_set mov ecx, ebx // (*) created by register allocator add esp, 8 // clean up extra stack space call js_Array_set // call function to set array element push esi // push first argument for call push false // push last argument for call sub esp, 8 // bump stack for call alignment convention jne side_exit_1 // (*) side exit if primes is not an array cmp eax, Array // (*) test whether primes is an array and eax, -4 // (*) mask out object class tag for primes mov eax, edx(4) // (*) load object class word for primes mov edi(16), 0 // (*) store false to interpreter stack mov edi(8), esi // (*) store k to interpreter stack mov esi, ebx(764) // load k from the trace activation record mov edi(0), edx // (*) store primes to interpreter stack mov edx, ebx(748) // load primes from the trace activation record and side exits to verify the assumptions made in this recording: that primes is an array and that the call to set its element succeeds. Sometimes these stores can be optimized away as the stack locations are live only on exits to the interpreter. Finally, the LIR records guards the semantics in SSA form using temporary variables. The LIR also encodes all the stores that the interpreter would do to its data stack. Figure 3. LIR snippet for sample program. This is the LIR recorded for line 5 of the sample program in Figure 1. The LIR encodes xt v7 // side exit if js_Array_set returns false. v7 := eq v6, 0 // test return value from call v6 := js_Array_set(v0, v2, false) // call function to set array element xf v5 // side exit if v5 is false v5 := eq v4, Array // test whether primes is an array v4 := and v3, -4 // mask out object class tag for primes v3 := ld v0[4] // load class word for primes st sp[16], 0 // store false to interpreter stack st sp[8], v1 // store k to interpreter stack v2 := i2f(v1) // convert k from int to double v1 := ld state[764] // load k from the trace activation record st sp[0], v0 // store primes to interpreter stack v0 := ld state[748] // load primes from the trace activation record ----------------Page (2) Break---------------- possible. ate on unboxed values in simple variables and arrays as much as the object representation is the same. In TraceMonkey, objects’ rep- efficient code that eliminates all that complexity, our traces oper- tion, so the simplified code requires guard instructions that ensure with attached type tag bits). Since a trace is intended to represent relationships and object representations can change during execu- complex data structures (e.g., hash tables) in a boxed format (i.e., and speedup compared to the original interpreter code. Inheritance Bytecode interpreters typically represent values in a various one more to get slot 2 from the vector. This is a vast simplification Figure 3 shows an example LIR trace. get the prototype, possibly one to get the property value vector, and generic enough that the backend compiler is language independent. can generate LIR that reads o.x with just two or three loads: one to conversion rules of the source language. The LIR operations are tation that places x in slot 2 of a property vector. Then the recorded TraceMonkey independent of the concrete type system and type o.x in the prototype of o, which uses a shared hash-table represen- are represented by function calls. This makes the LIR used by the property value. For example, the search might finds the value of and conditional exits. Type conversions, such as integer to double, the search process and record the simplest possible LIR to access offset), integer operators, floating-point operators, function calls, found during search. TraceMonkey can simply observe the result of are constant values, memory loads and stores (by address and process also must dispatch on the representation of each object both on entry and via loop edges. The important LIR primitives (e.g., per-object hash tables or shared hash tables), so the search TSSA), phi nodes appear only at the entry point, which is reached Property maps can be implemented with different data structures (low-level intermediate representation). In trace-flavored SSA (or search the property map of o and all of its prototypes and parents. In TraceMonkey, traces are recorded in trace-flavored SSA LIR an object property read expression like o.x, the interpreter must the same techniques used for typed languages. they include features like object inheritance and eval. To evaluate traces is that they can be compiled to efficient machine code using lookup semantics are complex and potentially expensive because refer to them simply as “traces”. The key property of typed loop Representation specialization: objects. In JavaScript, name In this paper, we only discuss typed loop traces, and we will question. of a function. at the side exit location, capturing the new type of the operation in is of type boolean. The entry type map is much like the signature along such a type guard, a new typed trace is recorded originating only if the value of the variable x is of type int and the value of b match those of the typed trace. When the VM observes a side exit (x: int, b: boolean) , meaning that the trace may be entered guarantee that as long as execution is on trace, the types of values before they are defined. For example, a trace could have a type map type from that seen during recording. These guard instructions type map giving the required types for variables used on the trace that conditionally exit if the operation yields a value of a different (including temporaries) on the trace. A typed trace also has an entry observed during recording. The recorder emits guard instructions A typed trace is a trace annotated with a type for every variable object could yield a value of any type, not necessarily the type predecessor node like regular nodes. of unpredictable types. For example, reading a property from an nodes are not recognizable as such in a trace and have a single A potential problem is that some operations can produce values follows one single path through the original program, however, join except the operation itself. block, a trace can contain join nodes. Since a trace always only perform the operation, and then reapply tags. LIR omits everything the top, but may have many exits. In contrast to an extended basic dispatch, mask out the tag bits to recover the untagged value, Similar to an extended basic block, a trace is only entered at and to perform any operation, must check the tag bits, dynamically loop. typical bytecode interpreter carries tag bits along with each value, a loop edge and represent a single iteration through the associated easily produce a translation that requires no type dispatches. A boundaries. TraceMonkey focuses on loop traces , that originate at LIR traces are necessarily type-specialized, and a compiler can A trace is simply a program path, which may cross function call All LIR primitives apply to operands of specific types. Thus, 3.1 Traces Type specialization. trace if necessary. interpreter to keep the exposition simple. structions to verify their assumptions about the state and exit the language interpreter, we will describe them assuming a bytecode cializing for the current trace. Each optimization requires guard in- formed at run time. Although our techniques apply to any dynamic dynamic language constructs to simple typed constructs by spe- In this section, we describe traces, trace trees, and how they are part of recording LIR. All of these optimizations reduce complex Now, we describe the key optimizations that are performed as 3. Trace Trees the trace. Such traces return only via guards. LIR instruction. This is just an unconditional branch to the top of entirely as native code. Most of our traces represent loops and end with the special loop the entire nested loop structure, so the rest of the program runs guard instructions. At this point, TraceMonkey has compiled enough traces to cover are run only if they are supposed to. We call these instructions 23,1 on future iterations, it jumps directly to T . what it was at trace recording, ensuring that the trace instructions 16 jumps directly to the start of T . The side exit is patched so that tions exit from the trace if required control flow is different from 23,1 covers line 3 and returns to the loop header. Thus, the end of T recorder generates conditional exit LIR instructions. These instruc- 23,1 time, the side exit becomes hot, so a trace T is recorded that For every control-flow branch in the source program, the i=6. On this iteration, the side exit on line 2 is taken again. This structures. without ever returning to the monitor. this native storage location and copies them back to the interpreter 45 16 T . T loops back to its own header, starting the next iteration interpreter. When the trace exits, the VM boxes the values from 16 i=5. TraceMonkey calls T , which in turn calls the nested trace recording, independently of the boxing mechanism used by the which executes the continue statement. these variables with simple loads and stores from a native activation The exit is not yet hot, so TraceMonkey returns to the interpreter, them to its activation record. Thus, the trace can read and write 16 original trace, so this causes T to fail a guard and take a side exit. imports local and global variables by unboxing them and copying if statement on line 2 is taken. This branch was not taken in the record area. To make variable accesses fast on trace, the trace also 16 i=4. On this iteration, TraceMonkey calls T . Because i=4, the A trace records all its intermediate values in a small activation ----------------Page (3) Break---------------- then to an integer internally to the array implementation. trace, using the loop header of the root trace as the target to reach. be converted from a double to a string for the property access operator, and threshold, recording starts. Recording stops exactly as for the root 1 Arrays are actually worse than this: if the index value is a number, it must a counter for each side exit, and when the counter reaches a hotness side exits. These traces are recorded much like root traces: there is the hot paths of the program. completely cover the loop, the VM must record traces starting at all tion. The goal is to form trace trees during execution that cover all the loop, or paths with different types or representations. Thus, to This section explains how trace trees are formed during execu- Extending a tree. Side exits lead to different paths through to a single-entry, multiple-exit trace tree . ble value and thus become type stable. directly to that trace. In this way, a single trace expands on demand based on the now updated oracle information will start with a dou- new branch trace from that point and patches the side exit to jump able, we immediately trigger the recording of a new trace, which main trace. When a side exit becomes hot, TraceMonkey starts a is type-unstable due to mis-speculation of a Number-typed vari- some variation, and so the program will take side exits from the particular variable. Whenever we accidentally compile a loop that can be represented by a single trace. But most loops have at least only if no adverse information is known to the oracle about that types, value representations, and inlined functions are all invariant, ing values to integers. Speculation towards integers is performed Especially simple loops, namely those where control flow, value When compiling loops, we consult the oracle before specializ- which we call the “oracle”. 3.2 Trace Trees to sometimes hold non-integer values in an advisory data structure trace we note the fact that the variable in question as been observed ing and returns to the trace monitor. ulative failures involving this variable, and to obtain a type-stable continuing trace recording, the implementation aborts trace record- in the variable, allowing us to close the loop. To avoid future spec- When any situation occurs that prevents the implementation from assuming that at the loop edge we would again find an integer value tations, e.g.,a small-memory device may limit the length of traces. at trace entry we specialized the Number-typed value to an integer, A tracing implementation can also have any number of other limi- ends with a double value. This represents a mis-speculation, since tracer to know the current type map in order to continue tracing. inherently type-unstable since it starts with an integer value but program state in unpredictable ways, making it difficult for the of the variable to a double. As a result, the recorded trace becomes For example, eval or calls to external functions can change the pectedly assigned a non-integer value, we have to widen the type Aborts. Some constructs are difficult to record in LIR traces. value at trace entry. If during trace recording the variable is unex- the interpreter’s state structures. when we observe that Number-typed variables contain an integer interpreter PC at the exit point and any other data needed to restore resent certain Number-typed values as integers on trace. We do so a structure that describes the reason for the exit along with the As mentioned previously, we may speculatively chose to rep- side exit , a small off-trace piece of LIR that returns a pointer to to the trace monitor. that performs a test and conditional exit. The exit branches to a statement. In this case, the VM simply ends the trace with an exit doing the optimization. A guard is just a group of LIR instructions header, for example because execution reaches a break or return requires one or more guards to verify the assumptions made in Finally, the trace might exit the loop before reaching the loop Guards and side exits. Each optimization described above iterations as long they eventually form a stable equilibrium. is the same. other. With this approach we are able to cover type-unstable loop name), the recorder must also emit LIR to guard that the function the entry map of all existing traces in case they complement each is not constant (which in JavaScript includes any call by function unstable trace is added to a region, its exit type map is compared to the interpreter’s standard call code. If the function being entered recorded with the new type map. Every time an additional type- intepreter call stack to be restored later and is much simpler than fail and return to the interpreter. At the same time a new trace is entry and exit LIR saves just enough information to allow the Instead, the iteration is terminated with a side exit that will always record that a call frame has been entered and exited. The frame link the trace back to its own loop header since it is type-unstable. to return to the interpreter, the trace must also generate LIR to iteration. When recording such an iteration, the recorder cannot away by the compiler using copy propagation. In order to be able undefined, before they are set to a concrete type during the first loop in and return values out. These move statements are then optimized iteration of a loop. Some variables inside the loop might initially be need to be recorded for function entry and exit to copy arguments different type map. This scenario is sometime observed for the first in either direction, achieving function inlining. Move instructions In certain cases the trace might reach the loop header with a Function inlining. LIR traces can cross function boundaries trace activation record to enter a trace. large for the integer representation. copy out the state at the end of the trace and copy it back in to the guards. For example, adding two integers can produce a value too enter the trace. The jump can even skip the usual code that would and represented as integers. Some operations on integers require beginning, as all the value representations are exactly as needed to as doubles. When a trace is started, some values may be imported iteration. In this case, the end of the trace can jump right to the as much as it can, switching for results that can only be represented the same type map as on entry. This is called a type-stable loop integers and doubles. The interpreter uses integer representations Ideally, the trace reaches the loop header where it started with In TraceMonkey, we support two representations for numbers: Closing the loop. Trace recording can end in several ways. integers directly and avoid these conversions. several trees for a given loop header. JavaScript VM that wants to be fast must find a way to operate on tree is associated with a loop header and type map, so there may be and then convert any integer result back to a double. 1 Clearly, a point and type map and marking the trace as the root of a tree. Each operate on integers, so they first convert the number to an integer, Starting a tree just means starting recording a trace for the current operators, in particular array accesses and bitwise operators, really cuted a certain number of times (2 in the current implementation). 754 floating-pointer numbers (“doubles”). But many JavaScript TraceMonkey starts a tree when a given loop header has been exe- integer type, only a Number type that is the set of 64-bit IEEE- bytecode is a loop header iff it is the target of a backward branch. Representation specialization: numbers. JavaScript has no headers are easy to detect–the bytecode compiler ensures that a Thus, the guard is a simple equality check on the object shape. they are a natural place to look for hot paths. In TraceMonkey, loop resentations are assigned an integer key called the object shape . Starting a tree. Tree trees always start at loop headers, because ----------------Page (4) Break---------------- at that point. For example, the first recorded trace may be a cycle compiled twice, and both copies must be retained in the trace cache. 2 2 4 5 7 1 6 7 1 loop (with header at i ) becomes hot first, and a trace tree is rooted {i , i , i , i , i , i , i , i , α }. Thus, the outer loop is recorded and loop where the inner loop contains two paths. Usually, the inner exit, recording another branch trace incorporating the outer loop: 2 Figure 7 shows basic trace tree compilation (11) applied to a nested Later, the program might take the other branch at i and then 5 7 1 6 7 1 trace that incorporates the outer loop: {i , i , i , i , i , i , α }. 4. Nested Trace Tree Formation 5 For example, the program might exit at i and record a branch inner loop’s trace tree. bytecodes before returning to the interpreter. to continue tracing, compiling traces for the outer loop inside the blacklisting loops for which the average trace call executes few the outer loop, clearly an undesirable solution. The other choice is As future work, this situation could be avoided by detecting and choices. First, the system can stop tracing and give up on compiling But it is hard to guarantee that this situation will never happen. When execution leaves the inner loop, the basic design has two implementation so that the VM can complete the branch trace. indicate that the trace loops back the tree anchor. basic interpreter. So far, in this situation we have improved the 2 3 5 through the inner loop, {i , i , i , α }. The α symbol is used to trace is high, and causes performance to be even slower than the With a short loop body, the overhead of finding and calling the for a trace, find it, execute it, and fall back to the interpreter. to a concrete value after the first iteration. In this case, the VM will repeatedly pass the loop header, search loops frequently have initially undefined values which change type call an inner tree (or in this case a forest of inner trees), since inner •The loop body is short. ticularly important for nested trace trees where an outer tree tries to complete a trace. to side-exit to the interpreter to cover odd type cases. This is par- •There is at least one hot side exit for which the VM cannot edges to form groups of trace trees that can execute without having match. As such traces accumulate, we attempt to connect their loop •The VM can form at least one root trace for the loop. compile that cannot loop back to themselves due to a type mis- when a loop meets all of these conditions: Figure 6. We handle type-unstable loops by allowing traces to There is a related problem we have not yet solved, which occurs the interpreter will never again even call into the trace monitor. simply replace the loop header no-op with a regular no-op. Thus, (c) Link ed preter executes a loop header no-op. To blacklist a fragment, we Closed Link ed Link ed String header. The VM calls into the trace monitor every time the inter- Number String String bytecode. We define an extra no-op bytecode that indicates a loop it has been blacklisted. We now avoid that problem by patching the amount of time just finding the loop fragment and determining that small loops that get blacklisted, the system can spend a noticeable String Boolean Number After implementing this basic strategy, we observed that for again start recording at that point. T r ace
1 T r ace
2 T r ace
3 marks the fragment as blacklisted, which means the VM will never ter a given number of failures (2 in our implementation), the VM (a) (b) Closed Link ed Link ed Link ed differently during startup than during its steady-state execution. Af- Number Number Boolean Number prevent tracing a chance to end. For example, a loop may behave mentation). This backoff counter gives temporary conditions that at that point until it is passed a few more times (32 in our imple- VM also sets a counter so that it will not try to record a trace starting Number Boolean Number Boolean ing at a given point, the VM records that a failure has occurred. The have been tried and failed. When the VM fails to finish a trace start- T r ace
1 T r ace
2 T r ace
1 T r ace
2 Our prediction algorithm is based on blacklisting traces that to start tracing, it must try to predict whether it will finish the trace. able to run any. To avoid this problem, whenever the VM is about anchor, which is the beginning of the trace tree. the VM repeatedly spends time trying to record traces, but is never a side exit. Both the trunk and the branch trace loop back to the tree could potentially run much more slowly than the base interpreter: attached. The branch trace contain a guard that may fail and trigger As a result, if a hot loop contains traces that always fail, the VM trace. The trunk trace contains a guard to which a branch trace was tracing every time we observe an exception being thrown. Figure 5. A tree with two traces, a trunk trace and one branch a trace for this path and repeatedly fail to do so, since we abort incur a punishing runtime overhead if we repeatedly try to record program opts to use exceptions intensively, we would suddenly because exceptions are usually rare in JavaScript. However, if a catching of arbitrary exceptions. This design trade off was chosen, TraceMonkey does not currently support recording throwing and into a trace, usually because of limitations in the implementation. Sometimes, a program follows a path that cannot be compiled Side
Exit 3.3 Blacklisting Guar d Br anch
T r ace want to cover such paths in an outer tree through tree nesting. T r ace
Anchor a trace tree along a path that leads to an outer loop, because we T runk
T r ace exit does not leave the loop. In particular we do not want to extend T r ee
Anchor only if the side exit is for a control-flow branch, and only if the side Our implementation does not extend at all side exits. It extends T ----------------Page (5) Break---------------- while saving only a few iterations in the interpreter. applications. to record several traces simultaneously, complicating the implementation, NANOJIT , is separate from the VM and can be used for other pend the recording, but that would require the implementation to be able optimized machine code trace. The trace compilation subsystem, 2 Instead of aborting the outer recording, we could principally merely sus- This section explains how a recorded trace is translated to an no duplication. Otherwise, if loops are nested to a depth k, and each 5. Trace Tree Optimization If all the loops in a nest are type-stable, then loop nesting creates start recording the inner loop. 2 we reach it. monitor will see the inner loop header, and will immediately the outer tree can start immediately trying to compile the next time to do this, we simply abort recording the first trace. The trace outer loop for aborting previously. We also undo the backoff so that we have to obtain it before we are able to proceed. In order decrement the blacklist counter on the outer loop, “forgiving” the O •If L does not have a type-matching compiled trace tree yet, back off on compiling it. When the inner tree finishes a trace, we tree, we increment the outer tree’s blacklist counter as usual and call the inner trace directly. RRIn our implementation, when an outer tree aborts on the inner in the trace for L . On future executions, the trace for L will as we are able to build up more traces for the inner tree. a nested trace tree. If the call succeeds, then we record the call OOThus, we should not count such aborts toward blacklisting as long •If L has a type-matching compiled trace tree, we call L as the inner tree is not ready, this is probably a temporary condition. R inner loop of L because we stop the trace when we exit a loop. The key observation is that when an outer trace aborts because OO of a different loop L (O for other loop). Note that L must be an algorithm. R for loop L (R for loop being recorded) and we reach the header which would lead to their being quickly blacklisted by the basic key step of the algorithm occurs when we are recording a trace startup (because the inner tree is not available or takes a side exit), with the range given by the loop edge), we stop the trace. The nesting. The problem is that outer loop traces often abort during When we exit a loop (detected by comparing the interpreter PC The blacklisting algorithm needs modification to work well with start tracing at loop headers exactly as in the basic tracing system. 4.2 Blacklisting with Nesting The algorithm for building nested trace trees is as follows. We traces call the inner loop’s trace tree. and start recording a new branch in the inner tree. compile inner and outer loops separately, and make the outer loop’s a compiled trace for the outer tree, we simply exit the outer trace and which is the inner loop. Using this knowledge, the system can the inner tree. If an inner tree side exit happens during execution of edges, the system can easily determine whether they are nested outer tree would then be able to properly finish and record a call to for a language with structured control flow. Thus, given two loop the inner tree a chance to finish growing. A future execution of the control flow graphs, but rather bytecodes produced by a compiler If this happens during recording, we abort the outer trace, to give we are not tracing arbitrary bytecodes that might have irreduceable tree, so we cannot continue recording or executing the outer tree. and outer loop paths will not be duplicated. Another key fact is that compiled a trace. At this point, the interpreter PC is in the inner tree, the code for each loop can be contained only in its own tree, be if the inner tree took a new side exit for which it had never The key insight is that if each loop is represented by its own trace reason for the inner tree not to return to the same point would 4.1 Nesting Algorithm the call, and side exit if the property does not hold. A common cannot actually guarantee this property, we must guard on it after native code without exponential trace duplication. in the outer tree every time with the same type map. Because we tracing system needs a technique for covering the nested loops with thus when the inner tree is called, it must exit to the same point In order to execute programs with nested loops efficiently, a The goal of nesting is to make inner and outer loops independent; which can easily fill the trace cache. like a function call site: it must return to the same point every time. (on geometric average), this na ̈ıve strategy yields O(nk) traces, An important detail is that the call to the inner trace tree must act In general, if loops are nested to depth k, and each loop has n paths m is close to 1, the resulting trace trees will be tractable. then we compile O(mk) copies of the innermost loop. As long as loop is entered with m different type maps (on geometric average), condition guard (b). The inner tree returns to the outer tree once it exits along its loop loop, and is nested inside an outer tree which “calls” the inner tree. inside the inner most loop (a). An inner tree captures the inner locations. Figure 7. Control flow graph of a nested loop with an if statement the two inner nested trace trees and places guards at their side exit and its nested trace tree configuration (right). The outer tree calls Figure 8. Control flow graph of a loop with two nested loops (left) (a) (b) 6 i 7 i Exit
Guar d 5 i 5 i 4 4 t i Exit
Guar d 3 4 6 2 i i i t 3 i Nes t ed
T r ee 2 2 2 i i t T r ee
Call Nes t ed
T r ee 1 1 1 1 t i Out er
T r ee i t ----------------Page (6) Break---------------- instruction before the current where each v is referred to. Then the pointer. m diately after the current instruction for spilling. Let v be the last activation record. Then, the trace is called like a normal C function The heuristic considers the set R of values v in registers imme- global values are then copied from the interpreter state to the trace carried value (6). stack space, and space for arguments to native calls. The local and spilling. We use a class heuristic that selects the “oldest” register- record containing imported local and global variables, temporary register to each. If there are no free registers, a value is selected for To execute a trace, the monitor must build a trace activation 2 v have not yet been assigned registers, the allocator assigns a free current PC and type map, and if it finds one, executes the trace. 3 1 2 3 1 v = add v , v , it has already assigned a register to v . If v and the current type map, checks the trace cache for a trace for the erator). By the time the allocator has reached an instruction like order to call a native trace for the first time. The monitor computes backward pass over the trace (it is integrated with the code gen- The interpreter must hit a loop edge and enter the monitor in We use a simple greedy register allocator that makes a single FASTCALL on x86). called as functions using standard native calling conventions (e.g., 5.2 Register Allocation PC and type map. Traces are compiled so that they may be Compiled traces are stored in a trace cache , indexed by intepreter machine instruction(s) for it. the backward filter pipeline, nanojit’s code generator emits native 6.1 Calling Compiled Traces After a LIR instruction is successfully read (“pulled”) from key implementation. stores to a value that is never used. In the rest of this section we discuss key areas of the TraceMon- •Dead code elimination. This eliminates any operation that world mark-and-sweep collector. function call inlining. The garbage collector is an exact, non-generational, stop-the- as above, except applied to the interpreter’s call stack used for in a hash table. •Dead call-stack store elimination. This is the same optimization large, unique sets of property names store their properties directly the shape and the array of its own property values. Objects with the top of the interpreter stack at future exits are also dead. to array indexes using a hash table. The object stores a pointer to before the next exit are dead. Stores to locations that are off tural description, called the object shape , that maps property names another trace). Thus, stores to the stack that are overwritten in SpiderMonkey. Most objects are represented by a shared struc- never read back before exiting the trace (by the interpreter or names to arbitrary values. They are represented in one of two ways stores to locations in the interpreter stack. But these values are JavaScript object values are mappings of string-valued property •Dead data-stack store elimination. The LIR trace encodes many GC-controlled blocks aligned on 8-byte boundaries. See Figure 6 for details. All pointers contained in jsvals point to We currently apply three backward filters: least significant bits are a type tag, and the remaining bits are data. through the pipeline. type jsval. A jsval is machine word in which up to the 3 of the nanojit reads one LIR instruction at a time, and the reads are passed In SpiderMonkey, all JavaScript values are represented by the backward program analysis. When running the backward filters, of SpiderMonkey is a bytecode interpreter implemented in C++. optimization filters. These are used for optimizations that require which is used by more than 200 million users world-wide. The core When trace recording is completed, nanojit runs the backward VM embedded in Mozilla’s Firefox open-source web browser (2), and then back again would be removed by this filter. JavaScript Virtual Machine (4). SpiderMonkey is the JavaScript INT INT DOUBLE with . For example, LIR that converts an to a plemented a trace-based dynamic compiler for the SpiderMonkey DOUBLE primarily algebraic identities that allow to be replaced To demonstrate the effectiveness of our approach, we have im- •source language semantic-specific expression simplification, 6. Implementation algebraic identities (e.g., a −a = 0 ), and •expression simplification, including constant folding and a few without affecting the following code •CSE (constant subexpression elimination), the preceding code, because that register can now be used freely ss v was used. The register that was assigned to v is marked free for instructions. corresponding spill code is generated just after the last point where converts floating-point LIR instructions to sequences of integer restore code just after the code for the current instruction. The •On ISAs without floating-point instructions, a soft-float filter s If we need to spill a value v at this point, we generate the We currently apply four forward filters: frees up a register for as long as possible given a single spill. 13 m constant instruction v = 3000 . heuristic selects v with minimum v . The motivation is that this 13 can replace a multiply instruction like v := mul3, 1000 with a write no instruction at all. For example, the constant folding filter filter unchanged, write a different instruction to the next filter, or is a key benefit of tracing. trace is recorded. Each filter may pass each instruction to the next (creating tagged values) are significant costs. Avoiding these costs pipeline. Thus, forward filter optimizations are performed as the Testing tags, unboxing (extracting the untagged value) and boxing struction is immediately passed to the first filter in the forward Figure 9. Tagged values in the SpiderMonkey JS interpreter. Every time the trace recorder emits a LIR instruction, the in- trace: one forward and one backward. undefined off independently, and yet all run in just two loop passes over the null, or optimizations as pipelined filters so that they can be turned on and 110 boolean enumeration for null, undefined, true, false so we chose a small set of optimizations. We implemented the 100 string pointer to JSString handle get good startup performance, the optimizations must run quickly, 010 number pointer to double handle nodes, certain optimizations are easy to implement. In order to 000 object pointer to JSObject handle Because traces are in SSA form and have no join points or φ - xx1 number 31-bit integer representation 5.1 Optimizations Tag JS Type Description ----------------Page (7) Break---------------- that loop (see Section 3.3). complex, especially trying to restart execution after the preemption. Once a loop is blacklisted we never call into the trace monitor for preemption becomes very slow. The implementation was also very mance, as well as more flexibility with tuning hotness thresholds. This solution can make the normal case slightly faster, but then improved, which might give us a small increase in overall perfor- the jump target to an exit routine when preemption is required. (on the second iteration). The hit counter implementation could be compiling the loop edge as an unconditional jump, and patching but we have tuned our loops to become hot and trace very quickly We tested and rejected a solution that avoided the guards by pensive because it requires us to look up the loop in the trace cache, loops. impact requirement met. Incrementing the loop hit counter is ex- In practice, the cost is detectable only for programs with very short activities) is usually less than 5%, so we consider the interpreter 1% increase in runtime on most benchmarks for this extra guard. results (see Figure 12) the total time spent in the monitor (for all the preemption flag at every loop edge. We measured less than a preter is a call to the trace monitor at loop edges. In our benchmark strategy carried over into TraceMonkey: the VM inserts a guard on In our implementation, the only direct modification to the inter- empt now” flag that was checked on every backward jump. This mantic equivalence. In the interpreter, this had been implemented by setting a “pre- formance and a convenient way for implementers to maintain se- scripts from locking up the host system and to schedule GC. mentation should have low impact on non-tracing interpreter per- periodically. The main reasons are to prevent infinitely looping to the currently running interpreter bytecode trace. A good imple- SpiderMonkey, like many VMs, needs to preempt the user program The job of the trace recorder is to emit LIR with identical semantics 6.4 Preemption 6.3 Trace Recording apply this technique to TraceMonkey as future work. ficiently executes the fat opcodes. up to 1.25x on benchmarks with many branch traces. We plan to (i.e. code that has been blacklisted), the interpreter directly and ef- lated project (13) background recompilation yielded speedups of codes only during recording. When running purely interpretatively making background tree recompilation attractive. In a closely re- It is important to note that we split fat opcodes into thinner op- In the future, multicore hardware is expected to be common, method on the object, since it lets us inline this function call. hot, stable trees. convert an object into a primitive value by invoking a well-known mitigated by recompiling only at certain points, or only for very fat bytecodes that recurse back into the interpreter, for example to a branch is added would be prohibitive. That problem might be their problems for trace recording. This is particularly effective for We believe that the cost of recompiling a trace tree every time us to retain the advantages of fat bytecodes while avoiding some of that tree recompilation takes time quadratic in the number of traces. ficult, and recording simple bytecodes is much easier. This enables achieving inter-trace register allocation (10). The disadvantage is bytecodes. Expressing the original semantics this way is not too dif- The alternate solution is to recompile an entire trace tree, thus certain complex bytecodes in the recorder as sequences of simple right away). One way we have mitigated these problems is by implementing processor may not be able to detect that the addresses are the same base interpreter. the instructions use different base registers with equal values, the chunk of code, and (c) TraceMonkey spends less time running the x86 processors often incur penalties of 6 cycles or more (e.g., if traces contain only one special case, not the interpreter’s large in the dynamic instruction stream, we have found that current dispatch costs are eliminated entirely in compiled traces, (b) the a noticeable cost. Also, if the writes and reads are very close in the same way. Also, the advantages are reduced because (a) cache hit rate, for small traces the increased instruction count has require the recorder to reimplement the same special case logic then soon reading back would be expected to have a high L1 Fat bytecodes are a problem for TraceMonkey because they stitching has a noticeable cost. Although writing to memory and compiler more opportunities to optimize the interpreter. In programs with branchy trace trees with small traces, trace lower dispatch cost, and bigger bytecode implementations give the by the branch trace. Fat bytecodes have two advantages: fewer bytecodes means layouts, so the trace activation record can be reused immediately for cached and dense array access). plementation, identical type maps yield identical activation record ments full JavaScript property value access, including special cases register-carried values back to its trace activation record. In our im- complex processing (e.g., the getprop bytecode, which imple- stitching. At a side exit, the exiting trace only needs to write live In fat-bytecode designs, individual bytecodes can implement costs of calling traces from the monitor, in a feature called trace beneficial to pure interpreter performance. Transitions from a trace to a branch trace at a side exit avoid the derMonkey follows a fat-bytecode design, which was found to be 6.2 Trace Stitching In some cases achieving this equivalence is difficult since Spi- extensive testing to achieve semantic equivalence. rise to up to 10% of total execution time. vidual code complexity, it also requires careful implementation and recording branch traces for hot side exits by aborts, this cost can While separating the interpreter from the recorder reduces indi- runtime. In a few programs, where the system is prevented from recorder is currently active. pen infrequently and hence do not contribute significantly to total the interpreter, with an additional runtime check to see whether a show that for programs we can trace well such transitions hap- Since such hooks are relatively rare, we embed them directly into mance. (see also Section 3.3). Our experiments (see Figure 12) preter to call into the recorder again after executing the bytecode. to-trace and trace-to-interpreter transitions is essential for perfor- index argument is out of range). For these, we arrange for the inter- negligible runtime cost, so minimizing the number of interpreter- ing String.charCodeAt, which returns an integer or NaN if the At least in the current implementation, these steps have a non- that cannot be predicted before executing the bytecode (e.g., call- terpreter state. code implementation. Some bytecodes have effects on the type map imported variables back from the trace activation record to the in- the trace ended). Finally, it jumps to the standard interpreter byte- preter JavaScript call stack frames as needed. Finally, it copies the recording routine. Then, it turns off recording if necessary (e.g., applies blacklisting if needed. Then, it pops or synthesizes inter- ery bytecode. The interrupt routine first calls a bytecode-specific state. First, the monitor checks the reason for the trace exit and preter’s dispatch table to call a single “interrupt” routine for ev- When a trace call returns, the monitor restores the interpreter Recording is activated by a pointer swap that sets the inter- ----------------Page (8) Break---------------- ple, we suspected bugs in TraceMonkey’s handling of type-unstable spectral-norm, string-base64, string-validate-input). we suspected would reveal flaws in our implementation. For exam- and, crypto-sha1, math-cordic, math-partial-sums, math- to generate loops, and also to test more heavily certain constructs (3d-morph, bitops-3bit-bits-in-byte, bitops-bitwise- JSFUNFUZZ by nesting random language elements. We modified TraceMonkey is the fastest VM on 9 of the 26 benchmarks JSFUNFUZZ tester, , which generates random JavaScript programs on bitops-bitwise-and. One tool that helped us greatly was Mozilla’s JavaScript fuzz best speedups in integer-heavy benchmarks, up to the 25x speedup mind and contained few loops. and V8 against the baseline (SpiderMonkey). Tracing achieves the suites, but most of them were not designed with tracing VMs in Figure 10 shows the relative speedups achieved by tracing, SFX, During development, we had access to existing JavaScript test (e) V8, the method-compiling JavaScript VM from Google. call-threaded JavaScript interpreter used in Apple’s WebKit, and 6.6 Correctness interpreter, (b) TraceMonkey, (d) SquirrelFish Extreme (SFX), the ent configurations for comparison: (a) SpiderMonkey, the baseline is planned future work. times and reports the average time taken by each. We ran 4 differ- override functions or DOM functions directly from trace. Support program once for warmup, then loads and runs each program 10 Currently, we do not support calling native property get and set driver, which starts a JavaScript interpreter, loads and runs each directly, without unnecessary argument conversions. run faster with tracing. For this, we ran the standard SunSpider test notated with their argument types so that the tracer can call them Benchmark results. The main question is whether programs cost, so we defined a new FFI that allows C functions to be an- GHz Core 2 processor and 2 GB RAM running MacOS 10.5. The FFI’s boxed value array requirement has a performance All experiments were performed on a MacBook Pro with 2.2 trace exit only if necessary. math kernels, and string processing. reenter, and they can be called without problem, and will cause tasks, primarily 3d rendering, bit-bashing, cryptographic encoding, if it is set. There are many external functions that seldom or never execute for minutes. The SunSpider programs carry out a variety of the trace immediately after returning from the external function call VMs. Many programs in those benchmarks use large data sets and Every call to an external function then checks this flag and exits such as SpecJVM98 (3) used to evaluate desktop and server Java piled trace is running. JavaScript programs. This is in stark contrast to benchmark suites the VM set a flag whenever the interpreter is reentered while a com- der consists of 26 short-running (less than 250ms, average 26ms) the call stack or global variables. To address this problem, we made Spider, the industry standard JavaScript benchmark suite. SunSpi- preter by calling scripts, which in turn again might want to access We evaluated our JavaScript tracing implementation using Sun- Another problem is that external functions can reenter the inter- affected by these safety mechanisms. 7. Evaluation rarely performed by host functions, performance is not significantly Since both call-stack access and global variable access are deed revealed several regressions which we subsequently corrected. variables into the activation record during trace execution. loops and heavily branching code, and a specialized fuzz tester in- to side exit. This is necessary since we cache and unbox global read or write global variables, and force the currently running trace Similarly, we detect when host functions attempt to directly at all and run in the interpreter. tion may only be called if the call stack has already been refreshed. cuted by compiled traces. Three of the benchmarks are not traced EQUIRES TACK R S is an untrusted annotation that means the func- recording. In most of the tests, almost all the bytecodes are exe- to only 5 functions, that means the function refreshes the call stack. for crypto-md5, where fully 3% of bytecodes are executed while ORCES TACK stack transitively. F S is a trusted annotation, applied cuted while recording is too small to see in this figure, except EQUIRES TACK R S functions, which are presumed to access the call in parentheses next to each test. The fraction of bytecodes exe- QUIRES TACK S . These annotations are also required in order to call preter and on native traces. The speedup vs. interpreter is shown ORCES TACK E a function must be annotated as either F S or R - Figure 11. Fraction of dynamic bytecodes executed by inter- at any point it needs to be used. In order to access the call stack, preter functions in order to verify that the call stack is refreshed We developed a C++ static analysis and annotated some inter- KA>29:92># L9922?#3!4,56# ficult because traces do not update the interpreter state until exit- 8:?.&1@>.1@>?.@A.1=>2#3%(4(56# 1@>8:?.1@>?.@A.1=>2#3+4*56# order to speed up code that interacts with the host system inside hot 1@>8:?.1@>E@?2.8:?.A?@2D2.1@>?#3%4*56# /8A>98FG8E.92/09?@D2#3$4!56# state in the same way, such as the CallIteratorNext function /9=:>8.<2?#3$4)56# preter builtins that do not use the FFI, but interact with the program /9=:>8.7-(#3%4&56# /9=:>8.?;<$#3(4,56# to read a property from an argument). There are also certain inter- -<>2.B897<>.>8H2#3$4$56# FFI interact with the program state through an interpreter API (e.g., -<>2.B897<>.5:<91#3$4!56# 7<>;./89-@/#3'4,56# is an array of boxed values. External functions called through the 7<>;.:<9I;.?:2/>99@AJ.19@AJ.B<#3$4(56# ?>9@AJ.>9@AJ.0A:9@AJ.D2.@A:0>#3$4,56# 6.5 Calling External Functions ----------------Page (9) Break---------------- dominated by such a replace call. benchmarks have large standard deviations (on the order of the as replace functions. The run time of string-unpack-code is considered very rough, as the values observed on the individual Our implementation currently does not trace functions called simple model of tracing performance. These estimates should be passed a function object used to compute the replacement text. These detailed metrics allow us to estimate parameters for a expression replace operations. The replace function can be traces to native code, and executing native code traces. •The implementation does not currently trace through regular (including time taken to interpret the recorded trace), compiling ities: interpreting bytecodes while not recording, recording traces main loops, we do not trace them. Figure 12 breaks down the total execution time into four activ- tofte and date-format-xparb use such functions in their are able to execute almost all the code natively. other functions implemented in C. Because date-format- cuted as native code. This figure shows that for many programs, we •The implementation does not currently trace eval and some tion of instructions interpreted and the fraction of instructions exe- controlflow-recursive. Detailed performance metrics. In Figure 11 we show the frac- raytrace, access-binary-trees, string-tagcloud, and benchmarks that use recursion extensively: 3d-cube, 3d- SpiderMonkey than in the two other VMs. TraceMonkey achieves a small speedup or no speedup on which are unaffected by tracing and seem to be less efficient in •The implementation does not currently trace recursion, so well, but its run time is dominated by string processing builtins, tively high cost for calling nested traces. string-fasta traces small bodies, so we suspect that the implementation has a rela- be attributed to a few specific causes: not clear, but all of these programs have nested loops with TraceMonkey’s smaller speedups on the other benchmarks can fannkuch, access-nsieve, and crypto-aes. The reason is to the trace compilation approach discussed in this paper. bitops-bits-in-byte, bitops-nsieve-bits, access- compiler. Thus, performance on this benchmark has little relation the interpreter, but are not as fast as SFX and/or V8, namely which is implemented in all 3 VMs by a special regular expression •Some programs trace very well, and speed up compared to regexp-dna is dominated by regular expression matching, code. jit. key runs all the other programs in this set almost entirely as native on this programs by improving the compilation speed of nano- tire program with 1 or 2 traces that operate on integers. TraceMon- forms one very long trace. We expect to improve performance form many bitwise operations, so TraceMonkey can cover the en- access-nbody forms a large number of traces (81). crypto-md5 In particular, the bitops benchmarks are short programs that per- •Two programs trace well, but have a long compilation time. benchmarks access-binary-trees and control-flow-recursive, for which we currently don’t generate any native code. results. We perform worst on benchmark programs that we do not trace and instead fall back onto the interpreter. This includes the recursive the SpiderMonkey interpreter, and almost 5 times faster than V8 and SFX. For a large number of benchmarks all three VMs produce similar to use integer arithmetic, which substantially improves performance. For one of the benchmark programs we execute 25 times faster than type specialization, which includes SunSpider Benchmark programs that perform bit manipulation. We type-specialize the code in question inline threading interpreter and Google’s V8 JS compiler. Our system generates particularly efficient code for programs that benefit most from Figure 10. Speedup vs. a baseline JavaScript interpreter (SpiderMonkey) for our trace-based JIT compiler, Apple’s SquirrelFish Extreme !" #" $!" $#" 01" -./" %!" &'()*+," %#" ----------------Page (10) Break---------------- tually inlined parts of outer loops within the inner loops (because context of Java, a statically typed language. Their trace trees ac- outperform the fastest available JavaScript compiler (V8) and the Trace trees were originally proposed by Gal et al. (11) in the trace trees substantially improves performance. We are able to traces, but did not try to create loop traces specifically. Our performance results confirm that type specialization using the current execution. Dynamo used loop headers as candidate hot syntax or encoding, would improve startup performance. was to perform PGO online so that the profile was specific to implementation, possibly including redesign of the LIR abstract replacement for profile-guided optimization (PGO). A major goal recording and compilation are clearly both expensive, and a better Dynamo (7) by Bala et al, introduced native code tracing as a the tracer, interpreted bytecodes take about 180 cycles to run. Still, specialization and more on other optimizations. recording). One observation supporting this conjecture is that in languages like Java. Thus, these systems have focused less on type in the interpreter (e.g., caches that have not warmed up yet during a longer history that has treated mostly native code and typed compilation is very rough, and may be influenced by startup factors General trace optimization. General trace optimization has and compilation. The estimated 200x slowdown for recording and nested traces for nested loops. be substantially better if we improved the speed of trace recording point representation for all number values) and does not generate These estimates also indicate that our startup performance could will use a less aggressive type speculation (e.g., using a floating- than any other current JavaScript VM. ator has told us that LuaJIT has a similar design to our system, but our compilation techniques can generate more efficient native code pilation ideas. (1). There are no publications on LuaJIT but the cre- code speedup of 3.9x is significantly better. This suggests that Pall’s LuaJIT is a Lua VM in development that uses trace com- of 3.0x relative to our baseline interpreter. Our estimated native and traces all operations. The other VMs we compared with achieve an overall speedup Instead, Psyco transforms loops to mutual recursion before running run natively, we break even after running a trace 270 times. Psyco does not attempt to identify hot loops or inline function calls. compile a bytecode, and we save 26 cycles each time that code is type-specializing trace compiler for a dynamic language (Python). 1/200 the speed of the interpreter. Because it costs 6950 cycles to To our knowledge, Rigo’s Psyco (16) is the only published bytecode. Hence, during recording and compiling the VM runs at traces. about 3800 cycles per bytecode, and compilation 3150 cycles per type-specialized code speculatively with guards along interpreter Using similar computations, we find that trace recording takes dynamic languages. Existing work shares the idea of generating speedup over the interpreter. related work is on applying trace optimization to type-specialize 35 cycles. Native traces take about 9 cycles per bytecode, a 3.9x Trace optimization for dynamic languages. The closest area of interpreter shows that on average, a bytecode executes in about clock cycles by the number of bytecodes executed in the base 8. Related Work 10% in the results.) Dividing the total execution time in processor other programs. (Note that this only makes a difference of about which has much different performance characteristics from the because most of its time is spent in the regular expression matcher, of 26 benchmarks. mean). We exclude regexp-dna from the following calculations, fastest available JavaScript inline threaded interpreter (SFX) on 9 Figure 13. Detailed trace recording statistics for the SunSpider benchmark set. string-validate-input 6 10 13 1 0 1.7 1.3 2.2 1.86x string-unpack-code 4 4 37 0 0 1.0 9.3 9.3 1.20x string-tagcloud 3 6 6 5 0 2.0 1.0 2.0 1.09x string-fasta 5 11 15 6 0 2.2 1.4 3.0 1.49x string-base64 3 5 7 0 0 1.7 1.4 2.3 2.53x regexp-dna 2 2 2 0 0 1.0 1.0 1.0 4.21x math-spectral-norm 15 20 20 0 0 1.3 1.0 1.3 7.12x math-partial-sums 2 4 4 1 0 2.0 1.0 2.0 5.90x math-cordic 2 4 5 1 0 2.0 1.3 2.5 4.92x date-format-xparb 3 3 11 3 0 1.0 3.7 3.7 0.98x date-format-tofte 3 3 4 7 0 1.0 1.3 1.3 1.07x crypto-sha1 5 5 10 0 0 1.0 2.0 2.0 5.95x crypto-md5 4 4 5 0 0 1.0 1.3 1.3 2.30x crypto-aes 50 72 78 19 0 1.4 1.1 1.6 1.64x controlflow-recursive 0 0 0 1 0 - - - 0.98x bitops-nsieve-bits 3 3 5 0 0 1.0 1.7 1.7 2.75x bitops-bitwise-and 1 1 1 0 0 1.0 1.0 1.0 25.20x bitops-bits-in-byte 3 3 4 1 0 1.0 1.3 1.3 8.67x bitops-3bit-bits-in-byte 2 2 2 0 0 1.0 1.0 1.0 25.47x access-nsieve 3 6 8 3 0 2.0 1.3 2.7 3.05x access-nbody 8 16 18 5 0 2.0 1.1 2.3 4.19x access-fannkuch 10 34 57 24 0 3.4 1.7 5.7 2.20x access-binary-trees 0 0 0 5 0 - - - 0.93x 3d-raytrace 10 25 100 10 1 2.5 4.0 10.0 1.18x 3d-morph 5 8 8 2 0 1.6 1.0 1.6 2.86x 3d-cube 25 27 29 3 0 1.1 1.1 1.2 2.20x Loops Trees Traces Aborts Flushes Trees/Loop Traces/Tree Traces/Loop Speedup ----------------Page (11) Break---------------- machine-code-like bytecodes. Researchers have shown how to gen- ommendations expressed here are those of the author and should preter design is a virtual machine that directly executes ASTs or annotation thereon. Any opinions, findings, and conclusions or rec- Native code generation by interpreters. The traditional inter- reprints for Governmental purposes notwithstanding any copyright implementations of JavaScript and Python programs. The U.S. Government is authorized to reproduce and distribute independent type inference that is used to generate efficient C Microsystems under Project No. 07-127. McCloskey (14) has work in progress based on a language- as by the California MICRO Program and industrial sponsor Sun ize on types and translate the program to C++. Foundation under grants CNS-0615443 and CNS-0627747, as well on the Cartesian Product Algorithm and used the results to special- Parts of this effort have been sponsored by the National Science Salib (17) designed a type inference algorithm for Python based Acknowledgments ingly, the two techniques produced nearly the same performance. infer input types and constant receiver types at call sites. Interest- our performance for applications that use those features. In another, they used an offline whole-program static analysis to constructs are currently executed via interpretation, which limits method online each time a method was called with new input types. tions and expression evaluation using eval. All these language guage Self. In one implementation, they generated a specialized pression substitutions using lambda functions, function applica- versions of a procedure specialized for the input types in the lan- We also plan on adding support for tracing across regular ex- Chambers et. al (9) pioneered the idea of compiling multiple as the improved code quality due to tree recompilation. methods instead of traces. times and obtain the best of both worlds, fast tree stitching as well specialization for performance. Most previous work has focused on of the presented dynamic compiler in order to minimize JIT pause guage implementors have long recognized the importance of type adoption of the existing work on tree recompilation in the context Type specialization for dynamic languages. Dynamic lan- support for this capability in the near term. We are also exploring complex. do not trace across recursive function calls, but plan to add the but the profiling and compilation systems are correspondingly more performance of our trace-based JavaScript compiler. We currently piler has more flexibility and can potentially generate better code, Work is underway in a number of areas to further improve the that can include subsets of any number of methods. Thus, the com- a relative of tracing. A region is an subprogram worth optimizing 10. Future Work Suganuma et al. (18) described region-based compilation (RBC), VM. programs amenable to tracing, we achieve speedups of 2x to 20x. interpreter that could easily be gradually re-engineered as a tracing to run a program efficiently. Our experiments also show that on and other optimizations. Their primary focus was on designing an of variables. Thus, a small number of traces per loop is sufficient to Java in order to achieve inlining, indirect jump elimination, are entered with only a few different combinations of value types YETI, from Zaleski et al. (19) applied Dynamo-style tracing Our experimental results show that in practice loops typically tion. optimized native code in two linear passes. inner loops become hot first), leading to much greater tail duplica- which translates a trace from an intermediate representation to specialization algorithm. We also described our trace compiler, to the many paths through a loop nest. We described our type nested traces in order to avoid excessive code duplication due explained how to identify loop nesting relationships and generate tation would improve SunSpider performance. paths and value types through the loop observed at run time. We costs can be substantial; speeding up those parts of the implemen- loop, it generates a tree of native code traces representing the ning native code have a good speedup. Recording and compilation Our technique focuses on aggressively inlined loops, and for each Most programs where the VM spends the majority of its time run- recording hot traces and generating type-specialized native code. speedup vs. interpreter is shown in parentheses next to each test. This paper described how to run dynamic languages efficiently by Figure 12. Fraction of time spent on major VM activities. The 9. Conclusions operations. K?<56# M/,56*# N547>F/# N:FF#O6:,/# M-?#O6:,/# on inline threading, with call threading only for very complex !"# $!"# %!"# &!"# '!"# (!!"# Google’s V8 is a JavaScript implementation primarily based )*+,-./#0$1$23# Spider benchmarks. )*+45678#0$1923# niques have given SFX excellent performance on the standard Sun- )*+6:;<6:,/#0(1$23# :,,/==+.>?:6;+<6//=#0!1923# bined with efficient interpreter engineering, these threading tech- :,,/==+@:??A-,8#0$1$23# tion based on call threading with selective inline threading. Com- :,,/==+?.5*;#0%1$23# :,,/==+?=>/B/#0)1!23# Apple’s SquirrelFish Extreme (5) is a JavaScript implementa- .><57=+).><+.><=+>?+.;<57=+.><=+>?+.;<57=+.>=/+:?*#0$C1$23# Neither call threading nor inline threading perform type special- .><57=+?=>/B/+.><=#0$1D23# dispatch overhead. ,5?<65FG5E+6/,-6=>B/#0(1!23# ,6;7<5+:/=#0(1&23# thus acting as a simple per-method JIT compiler that eliminates the ,6;7<5+4*C#0$1)23# which implement the required bytecodes into a native code cache, ,6;7<5+=8:(#0C1923# *:,#0%1923# 4:<8+7:6I:F+=-4=#0C1923# shown to be a potentially much more efficient dispatch mechanism 4:<8+=7/,<6:F+?564#0D1(23# method for each interpreter bytecode. A call-return pair has been 6/J/27+*?:#0%1$23# =<6>?J+.:=/&%#0$1C23# methods by generating a native call instruction to an interpreter =<6>?J+@:=<:#0(1C23# Call threading, also known as context threading (8), compiles =<6>?J+<:J,F5-*#0(1(23# =<6>?J+-?7:,A+,5*/#0(1$23# mance. =<6>?J+B:F>*:?7-<#0(1923# erate native code with nearly the same structure but better perfor- ----------------Page (12) Break---------------- pages 146–160. ACM New York, NY, USA, 1989. Conference on Programming Language Design and Implementation , gramming Language. In Proceedings of the ACM SIGPLAN 1989 Press, 2007. Technology for SELF, a Dynamically-Typed O bject-Oriented Pro- Conference on Virtual Execution Environments , pages 83–93. ACM [9] C. Chambers and D. Ungar. Customization: Optimizing Compiler Extensible Trace Interpreter. In Proceedings of the International International Symposium on , pages 15–26, 2005. [19] M. Zaleski, A. D. Brown, and K. Stoodley. YETI: A graduallY terpreters. In Code Generation and Optimization, 2005. CGO 2005. gramming Languages and Systems (TOPLAS) , 28(1):134–174, 2006. a Flexible and Efficient Dispatch Technique for Virtual Machine In- tion Technique for Dynamic Compilers. ACM Transactions on Pro- [8] M. Berndl, B. Vitale, M. Zaleski, and A. Brown. Context Threading: [18] T. Suganuma, T. Yasue, and T. Nakatani. A Region-Based Compila- pages 1–12. ACM Press, 2000. Python. In Master’s Thesis , 2004. Conference on Programming Language Design and Implementation , [17] M. Salib. Starkiller: A Static Type Inferencer and Compiler for dynamic optimization system. In Proceedings of the ACM SIGPLAN [7] V. Bala, E. Duesterwald, and S. Banerjia. Dynamo: A transparent Psyco Prototype for Python. In PEPM, 2004. [16] A. Rigo. Representation-Based Just-In-time Specialization and the techniques, and tools, 2006. [6] A. Aho, R. Sethi, J. Ullman, and M. Lam. Compilers: Principles, 300. ACM New York, NY, USA, 1998. on Programming language design and implementation , pages 291– http://webkit.org/blog/214/introducing-squirrelfish-extreme/. tive inlining. In Proceedings of the ACM SIGPLAN 1998 conference [5] Surfin’ Safari - Blog Archive - Announcing SquirrelFish Extreme - [15] I. Piumarta and F. Riccardi. Optimizing direct threaded code by selec- http://www.mozilla.org/js/spidermonkey/. [14] B. McCloskey. Personal communication. [4] SpiderMonkey (JavaScript-C) Engine - Sciences, The University of Texas at Austin, TR-09-06, 2009. [3] SPECJVM98 - http://www.spec.org/jvm98/. trace-based just-in-time compiler for javascript. Dept.of Computer http://www.mozilla.com. [13] J. Ha, M. R. Haghighat, S. Cong, and K. S. McKinley. A concurrent [2] Mozilla — Firefox web browser and Thunderbird email client - Application of Dynamic Receiver Class Distributions. 1994. 02/msg00051.html. [12] C. Garrett, J. Dean, D. Grove, and C. Chambers. Measurement and [1] LuaJIT roadmap 2008 - http://lua-users.org/lists/lua-l/2008- 144–153. ACM Press, 2006. References International Conference on Virtual Execution Environments , pages compiler for resource-constrained devices. In Proceedings of the ernment, or any of the companies mentioned above. [11] A. Gal, C. W. Probst, and M. Franz. HotpathVM: An effective JIT tional Science foundation (NSF), any other agency of the U.S. Gov- 2006. policies or endorsements, either expressed or implied, of the Na- Machine Dissertation . PhD thesis, University Of California, Irvine, not be interpreted as necessarily representing the official views, [10] A. Gal. Efficient Bytecode Verification and Compilation in a Virtual ----------------Page (13) Break----------------