Phase detection using trace compilation

Abstract

Dynamic compilers can optimize application code specifically for observed code behavior. Such behavior does not have to be stable across the entire program execution to be beneficial for optimizations, it must only be stable for a certain program phase. To specialize code for a program phase, it is necessary to detect when the execution behavior of the program changes (phase change). Trace-based compilation is an efficient method to detect such phase changes. A trace tree is a collection of frequently executed code paths through a code region, which is assembled dynamically at run time as the program executes. Program execution tends to remain within such a trace tree during a stable phase, whereas phase changes cause a sudden increase in side exits from the trace tree. Because trace trees are recorded at run time by observing the interpreter, the actual values of variables and expressions are also available. This allows a definition of phases based not only on recurring control flow, but also on recurring data values. The compiler can use constant values for variables that change their value rarely and rely on phase detection to handle the case when the variable value actually changes. Our evaluation shows that phase detection based on trace trees results in phases that match the intuitive expectation of a programmer and that are also useful for compiler optimizations.

Efficiently parallelizing instruction set simulation of embedded multi-core processors using region-based just-in-time dynamic binary translation

“…loop header, method entry) [2,15,17,19,36], or always enabled when interpreting code [4]. Various backbone data structures have been suggested to capture recorded traces such as trace-trees [14], control-flow-graphs (CFG) of traced basic blocks [4], or hybrids between trace-trees and CFGs called trace-regions [2] or trace-graphs [18].…”

“…• Global Recording Structure -Most [2,14,15,[17][18][19]36] JIT compilation systems use one shared global recording structure ( 1 in Figure 1) to incrementally build CFG sections. This scheme works well for single-threaded execution environments but does not scale to multi-threaded applications as additional synchronisation is required when recording in parallel for multiple threads.…”

“…This region can then be executed by multiple threads wishing to execute the same region of code, 2. a strategy for sharing translated regions between application threads, to both reduce pressure on the JIT subsystem, and Figure 1. Comparison of recording approaches for multithreaded applications: 1 recording using a shared global structure [2,15,17,19,36] requiring synchronisation, 2 lock free recording using private local structures. Finally, 3 shows our lock free region recording approach using private local thread-agnostic region structures.…”

“…A similar global trace cache is used by Häubl [18] for the Hotspot JVM. Wimmer et al [36] note that tracing enables simple phase change detection by comparing the ratio of side exits taken to the time spent in the trace itself. Traces can be discarded and recompiled when a phase change is detected.…”

Trace-based compilation for the Java HotSpot virtual machine

“…Furthermore, when our trace-based compiler compiles traces for the first time, it may happen that not all relevant paths have been recorded yet. This is a common problem for trace compilation, as different parts of a method might be hot during different execution phases of the application [29].…”