Trace-based just-in-time type specialization for dynamic languages

Abstract

Dynamic languages such as JavaScript are more difficult to compile than statically typed ones. Since no concrete type information is available, traditional compilers need to emit generic code that can handle all possible type combinations at runtime. We present an alternative compilation technique for dynamically-typed languages that identifies frequently executed loop traces at run-time and then generates machine code on the fly that is specialized for the actual dynamic types occurring on each path through the loop. Our method provides cheap inter-procedural type specialization, and an elegant and efficient way of incrementally compiling lazily discovered alternative paths through nested loops. We have implemented a dynamic compiler for JavaScript based on our technique and we have measured speedups of 10x and more for certain benchmark programs.

An Improved Strategy to Eliminate Redundant Compilation Based on Dalvik JIT

“…Most instant compiler on PC platform adopt this strategy. Hotpath VM developed by Andreas Gal and others [5], Mozilla's TraceMonkey [6], Lua's LuaJIT, Python's Pypy [7] and other compilers adopt Trace-based JIT, hot code of which is divided by trace as particle size.…”

“…The interpreter translates some programs into native code via compiler at the first time, and executes those code directly next time. At present, most interpreters adopt this technology such as Firfox's TraceMonkey, Lua's LuaJit and Python's Pypy [3].…”

Hardware/software specialization through aspects: The LARA approach

“…Their system compiles several copies of a given procedure, each customized for one receiver type. Due to the prominence of dynamic programming languages, type specialization has been addressed by various authors, including its use in just-in-time (JIT) compilers [19]. DyC [20] is one of the software compilers considering specialization based on user control through declarative policy annotations.…”

Information Flow Monitor Inlining

“…SpiderMonkey and TraceMonkey by Mozilla [16], V8 by Google [18] and SquirrelFish by Apple. Internally they are very different, so the implementation of a monitor for one runtime would not be useful for the others.…”

“…Microsoft .NET [33] and Google V8 [18]), or, in a more elaborate fashion, compile only the bodies of the loops where the interpreter spends most of the time (e.g. Mozilla TraceMonkey [16] and Sun HotSpot [38]). The key point is that the parts of the program translated to native code are no longer under the step-by-step control of the VM: It is no longer able to mediate every data and control flow event, which we need for information flow (as opposed, e.g., to monitoring system calls for access control).…”