Results 1 - 10
of
43
Trace-based Just-in-Time Type Specialization for Dynamic Languages.
- In Proceedings of the ACM SIGPLAN Conference on Programming Language Design and Implementation,
, 2009
"... 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 t ..."
Abstract
-
Cited by 81 (5 self)
- Add to MetaCart
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.
Tracing the meta-level: PyPy’s tracing JIT compiler
- Proceedings of the 4th workshop on the Implementation, Compilation, Optimization of Object-Oriented Languages and Programming Systems
, 2009
"... We attempt to apply the technique of Tracing JIT Com-pilers in the context of the PyPy project, i.e., to programs that are interpreters for some dynamic languages, including Python. Tracing JIT compilers can greatly speed up pro-grams that spend most of their time in loops in which they take similar ..."
Abstract
-
Cited by 42 (5 self)
- Add to MetaCart
(Show Context)
We attempt to apply the technique of Tracing JIT Com-pilers in the context of the PyPy project, i.e., to programs that are interpreters for some dynamic languages, including Python. Tracing JIT compilers can greatly speed up pro-grams that spend most of their time in loops in which they take similar code paths. However, applying an unmodified tracing JIT to a program that is itself a bytecode interpreter results in very limited or no speedup. In this paper we show how to guide tracing JIT compilers to greatly improve the speed of bytecode interpreters. One crucial point is to un-roll the bytecode dispatch loop, based on two hints provided by the implementer of the bytecode interpreter. We evalu-ate our technique by applying it to two PyPy interpreters: one is a small example, and the other one is the full Python interpreter. 1.
Abstract YETI: a graduallY Extensible Trace Interpreter
, 2008
"... The implementation of new programming languages benefits from interpretation because it is simple, flexible and portable. The only downside is speed of execution, as there remains a large performance gap between even efficient interpreters and systems that include a just-in-time (JIT) compiler. Augm ..."
Abstract
-
Cited by 22 (0 self)
- Add to MetaCart
(Show Context)
The implementation of new programming languages benefits from interpretation because it is simple, flexible and portable. The only downside is speed of execution, as there remains a large performance gap between even efficient interpreters and systems that include a just-in-time (JIT) compiler. Augmenting an interpreter with a JIT, however, is not a small task. Today, Java JITs are typically method-based. To compile whole methods, the JIT must re-implement much functionality already provided by the interpreter, leading to a “big bang ” development effort before the JIT can be deployed. Adding a JIT to an interpreter would be easier if we could more gradually shift from dispatching virtual instructions bodies implemented for the interpreter to running instructions compiled into native code by the JIT. We show that virtual instructions implemented as lightweight callable routines can form the basis for a very efficient interpreter. Our new technique, interpreted traces, identifies hot paths, or traces, as a virtual program is interpreted. By exploiting the way traces predict branch desti-nations our technique markedly reduces branch mispredictions caused by dispatch. Interpreted traces are a high-performance technique, running about 25 % faster than direct threading. We show that interpreted traces are a good starting point for a trace-based JIT. We extend
Tracing for web 3.0: trace compilation for the next generation web applications
- In VEE
, 2009
"... Today’s web applications are pushing the limits of modern web browsers. The emergence of the browser as the platform of choice for rich client-side applications has shifted the use of in-browser JavaScript from small scripting programs to large computationally intensive application logic. For many w ..."
Abstract
-
Cited by 15 (1 self)
- Add to MetaCart
(Show Context)
Today’s web applications are pushing the limits of modern web browsers. The emergence of the browser as the platform of choice for rich client-side applications has shifted the use of in-browser JavaScript from small scripting programs to large computationally intensive application logic. For many web applications, JavaScript performance has become one of the bottlenecks preventing the development of even more interactive client side applications. While traditional just-in-time compilation is successful for statically typed virtual machine based languages like Java, compiling JavaScript turns out to be a challenging task. Many JavaScript programs and scripts are short-lived, and users expect a responsive browser during page loading. This leaves little time for compilation of JavaScript to generate machine code. We present a trace-based just-in-time compiler for JavaScript that uses run-time profiling to identify frequently executed code paths, which are compiled to executable machine code. Our approach increases execution performance by up to 116 % by decomposing complex JavaScript instructions into a simple Forth-based representation, and then recording the actually executed code path through this low-level IR. Giving developers more computational horsepower enables a new generation of innovative web applications.
Decoupled Lifeguards: Enabling Path Optimizations for Dynamic Correctness Checking Tools
"... Dynamic correctness checking tools (a.k.a. lifeguards) can detect a wide array of correctness issues, such as memory, security, and concurrency misbehavior, in unmodified executables at run time. However, lifeguards that are implemented using dynamic binary instrumentation (DBI) often slow down the ..."
Abstract
-
Cited by 15 (6 self)
- Add to MetaCart
(Show Context)
Dynamic correctness checking tools (a.k.a. lifeguards) can detect a wide array of correctness issues, such as memory, security, and concurrency misbehavior, in unmodified executables at run time. However, lifeguards that are implemented using dynamic binary instrumentation (DBI) often slow down the monitored application by 10–50X, while proposals that replace DBI with hardware still see 3–8X slowdowns. The remaining overhead is the cost of performing the lifeguard analysis itself. In this paper, we explore compiler optimization techniques to reduce this overhead. The lifeguard software is typically structured as a set of eventdriven handlers, where the events are individual instructions in the monitored application’s dynamic instruction stream. We propose to decouple the lifeguard checking code from the application that it is monitoring so that the lifeguard analysis can be invoked at the granularity of hot paths in the monitored application. In this way, we are able to find many more opportunities for eliminating redundant work in the lifeguard analysis, even starting with welloptimized applications and hand-tuned lifeguard handlers. Experimental results with two lifeguard frameworks—one DBI-based and one hardware-assisted—show significant reduction in monitoring overhead.
Generalized just-in-time trace compilation using a parallel task farm in a dynamic binary translator
- in Proceedings of the ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI’11). ACM
, 2011
"... Dynamic Binary Translation (DBT) is the key technology behind cross-platform virtualization and allows software compiled for one Instruction Set Architecture (ISA) to be executed on a processor supporting a different ISA. Under the hood, DBT is typically implemented using Just-In-Time (JIT) compilat ..."
Abstract
-
Cited by 13 (3 self)
- Add to MetaCart
(Show Context)
Dynamic Binary Translation (DBT) is the key technology behind cross-platform virtualization and allows software compiled for one Instruction Set Architecture (ISA) to be executed on a processor supporting a different ISA. Under the hood, DBT is typically implemented using Just-In-Time (JIT) compilation of frequently executed program regions, also called traces. The main challenge is translating frequently executed program regions as fast as possible into highly efficient native code. As time for JIT compilation adds to the overall execution time, the JIT compiler is often decoupled and operates in a separate thread independent from the main simulation loop to reduce the overhead of JIT compilation. In this paper we present two innovative contributions. The first contribution is a generalized trace compilation approach that considers all frequently executed paths in a program for JIT compilation,
Incremental Dynamic Code Generation with Trace Trees
- Technical Report
, 2006
"... The unit of compilation for traditional just-in-time compilers is the method. We have explored trace-based compilation, in which the unit of compilation is a loop, potentially spanning multiple methods and even library code. Using a new intermediate representation that is discovered and updated lazi ..."
Abstract
-
Cited by 12 (0 self)
- Add to MetaCart
The unit of compilation for traditional just-in-time compilers is the method. We have explored trace-based compilation, in which the unit of compilation is a loop, potentially spanning multiple methods and even library code. Using a new intermediate representation that is discovered and updated lazily on-demand while the program is being executed, our compiler generates code that is competitive with traditional dynamic compilers, but that uses only a fraction of the compile time and memory footprint.
Categories and Subject Descriptors D.3.4 [Programming Languages]: Processors—Incremental compilers; optimization
Improving the Performance of Trace-based Systems by False Loop Filtering
- In Proceedings of Sixteenth International Conference on Architectural Support for Programming Languages and Operating Systems
, 2011
"... Trace-based compilation is a promising technique for language compilers and binary translators. It offers the potential to expand the compilation scopes that have traditionally been limited by method boundaries. Detecting repeating cyclic execution paths and capturing the detected repetitions into t ..."
Abstract
-
Cited by 9 (3 self)
- Add to MetaCart
(Show Context)
Trace-based compilation is a promising technique for language compilers and binary translators. It offers the potential to expand the compilation scopes that have traditionally been limited by method boundaries. Detecting repeating cyclic execution paths and capturing the detected repetitions into traces is a key requirement for trace selection algorithms to achieve good optimization and performance with small amounts of code. One important class of repetition detection is cyclic-path-based repetition detection, where a cyclic execution path (a path that starts and ends at the same instruction address) is detected as a repeating cyclic execution path. However, we found many cyclic paths that are not repeating cyclic execution paths, which we call false loops. A common class of false loops occurs when a method is invoked from multiple callsites.
Trace fragment selection within methodbased JVMs
, 2008
"... Java virtual machines have historically employed either a “whole-method ” or a “trace ” methodology for selecting regions of code for optimization. Adaptive whole-method optimization primarily leverages intra-procedural optimizations derived from classic static compilation techniques whereas trace o ..."
Abstract
-
Cited by 8 (1 self)
- Add to MetaCart
(Show Context)
Java virtual machines have historically employed either a “whole-method ” or a “trace ” methodology for selecting regions of code for optimization. Adaptive whole-method optimization primarily leverages intra-procedural optimizations derived from classic static compilation techniques whereas trace optimization utilizes an inter-preter to select, manage, and dispatch inter-procedural fragments of frequently executed code. In this paper we present our hybrid approach for supplement-ing the comprehensive strengths of a whole-method JIT compiler with the inter-procedural refinement of trace fragment selection and show that that the two techniques would be mutually beneficial. Using the “interpreterless ” Jikes RVM as a foundation, we use our trace profiling subsystem to identify an application’s working set as a collection of hot traces and show that there is a significant margin for improvement in instruction ordering that can be ad-dressed by trace execution. Our benchmark hot-trace profiles indi-cate that 20 % of transitions between machine-code basic blocks as laid out by the JIT compiler are non-contiguous, many of which are transfers of control flow to locations outside of the current virtual memory page. Additionally, the analyses performed by the adaptive whole-method JIT compiler allow for better identification of trace starting and stopping locations, an improvement over the popular next-executing-tail (NET) trace selection scheme. We show min-imal overhead for trace selection indicating that inter-procedural trace execution provides an opportunity to improve both instruc-tion locality as well as compiler-directed branch prediction without significant run-time cost.
A Trace-based Java JIT Compiler Retrofitted from a Method-based Compiler
"... Abstract—This paper describes our trace-based JIT compiler (trace-JIT) for Java developed from a production-quality method-based JIT compiler (method-JIT). We first describe the design and implementation of our trace-JIT with emphasis on how we retrofitted a method-JIT as a trace-based compiler. The ..."
Abstract
-
Cited by 8 (3 self)
- Add to MetaCart
(Show Context)
Abstract—This paper describes our trace-based JIT compiler (trace-JIT) for Java developed from a production-quality method-based JIT compiler (method-JIT). We first describe the design and implementation of our trace-JIT with emphasis on how we retrofitted a method-JIT as a trace-based compiler. Then we show that the trace-JIT often produces better quality code than the method-JIT by extending the compilation scope. Forming longer traces that span multiple methods turns out to be more powerful than method inlining in extending the compilation scope. It reduces method-invocation overhead and also offers more compiler optimization opportunities. However, the trace-JIT incurs additional runtime overhead compared to the method-JIT that may be offset by gains from the improved code quality. Overall, our trace-JIT achieved performance roughly comparable to the baseline method-JIT. We also discuss the issues in trace-based compilation from the viewpoint of compiler optimizations. Our results show the potentials of trace-based compilation as an alternative or complementary approach to compiling languages with mature method-based compilers. Keywords—trace-based compilation, JIT, Java I.