Warning: imagejpeg(C:\Inetpub\vhosts\kidney.de\httpdocs\phplern\27239163
.jpg): Failed to open stream: No such file or directory in C:\Inetpub\vhosts\kidney.de\httpdocs\pget.php on line 117 Comput+Lang+Syst+Struct
2013 ; 39
(4
): 123-141
Nephropedia Template TP
gab.com Text
Twit Text FOAVip
Twit Text #
English Wikipedia
Context-sensitive trace inlining for Java
#MMPMID27239163
Häubl C
; Wimmer C
; Mössenböck H
Comput Lang Syst Struct
2013[Dec]; 39
(4
): 123-141
PMID27239163
show ga
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 [Formula: see text], 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.