Context-sensitive trace inlining for Java

Abstract

Method inlining is one of the most important optimizations in method-based just-in-time (JIT) compilers. It widens the compilation scope and therefore allows optimizing multiple methods as a whole, which increases the performance. However, if method inlining is used too frequently, the compilation time increases and too much machine code is generated. This has negative effects on the performance.Trace-based JIT compilers only compile frequently executed paths, so-called traces, instead of whole methods. This may result in faster compilation, less generated machine code, and better optimized machine code. In the previous work, we implemented a trace recording infrastructure and a trace-based compiler for JavaTM, by modifying the Java HotSpot VM. Based on this work, we evaluate the effect of trace inlining on the performance and the amount of generated machine code.Trace inlining has several major advantages when compared to method inlining. First, trace inlining is more selective than method inlining, because only frequently executed paths are inlined. Second, the recorded traces may capture information about virtual calls, which simplify inlining. A third advantage is that trace information is context sensitive so that different method parts can be inlined depending on the specific call site. These advantages allow more aggressive inlining while the amount of generated machine code is still reasonable.We evaluate several inlining heuristics on the benchmark suites DaCapo 9.12 Bach, SPECjbb2005, and SPECjvm2008 and show that our trace-based compiler achieves an up to 51% higher peak performance than the method-based Java HotSpot client compiler. Furthermore, we show that the large compilation scope of our trace-based compiler has a positive effect on other compiler optimizations such as constant folding or null check elimination.

Trace transitioning and exception handling in a trace-based JIT compiler for java

“…Our new trace-based compiler also incorporates a more advanced trace inlining technique that we described in a recently accepted article [Häubl et al 2013]. The work in that article significantly increased peak performance but focused on trace inlining heuristics and covered neither trace transitioning nor exception handling.…”

“…Trace inlining is our most profitable optimization. It is more powerful than method inlining because traces contain context-sensitive information, which helps us to avoid inlining unnecessary method parts [Häubl et al 2012[Häubl et al , 2013. This is shown in Figure 4, where two different callers invoke the same method.…”

“…In previous work [Häubl and Mössenböck 2011;Häubl et al 2012Häubl et al , 2013, we implemented a trace recording infrastructure and a simple trace-based JIT compiler for Java based on the production-quality Java HotSpot VM. Our implementation supports two different kinds of traces: loop traces anchored at loop headers, and method traces anchored at method entries.…”

“…In previous work [Häubl and Mössenböck 2011;Häubl et al 2012Häubl et al , 2013, we implemented a trace recording infrastructure and a simple trace-based JIT compiler by modifying Oracle's Java HotSpot Virtual Machine (VM). This article contributes the following new aspects:…”

Tracing vs. partial evaluation: comparing meta-compilation approaches for self-optimizing interpreters

“…Future work could verify this by studying both techniques on top of the same optimization infrastructure. For instance a tracing JIT compiler on top of HotSpot [18] could be used to verify whether the observed engineering benefits are a consequence of tracing. On the other hand, if the partial evaluated language would be more geared towards it than Java, it might also reduce the selfoptimizations that are necessary to reach peak performance.…”