Deep understanding of Java Virtual Machines (13) Java instant compiler JIT mechanism and compilation optimizations

In some commercial virtual machines, Java programs are initially interpreted by the interpreter (interpreter), and when a virtual machine discovers that a method or block of code is running particularly frequently, the code is identified as a " hotspot code ." To improve the efficiency of hot spot code execution, the instant compiler (Just in time Compiler) compiles the code into the machine code associated with the local platform at runtime and optimizes it at various levels.

1. Instant compiler in HotSpot

The interpreter and compiler each have their advantages:

Interpreter Advantage : When the program needs to start quickly, the interpreter can play a role first, eliminating the time to compile, immediately execute. Explains that execution takes up less memory space. At the same time, when the compiler's aggressive optimization fails, it can also be reversed to revert to the state of interpretation execution.

Compiler Advantage : As the program runs, as time goes by, the compiler is gradually working to get more and more code to compile the cost code, which can achieve higher execution efficiency.

Therefore, in the entire virtual machine execution schema, the interpreter and the compiler often work together as shown in.

There are two instant compilers built into the hotspot, called Client Compiler and Server Compiler , or C1 compilers and C2 compilers, respectively. The current hotspot compiler defaults to how the interpreter works in conjunction with one of the instant compilers , which compiler, depending on the mode in which the virtual machine is running, automatically chooses the operating mode based on its version and the hardware performance of the computer. Users can also use the-client and-server parameters to force the specified virtual machine to run in client mode or server mode. This combination is called "mixed Mode", which allows the user to force the virtual machine to run in "interpretation mode" (interpreted mode)using the parameter-xint, at which time the compiler is completely Mixed. In addition, using-xcomp to force a virtual machine to run in "compile mode" (Compiled modes)will take precedence over compile, but the interpreter still has to be able to access the execution process without compiling. The virtual Machine-version command allows you to view the current default run mode.

2. Compiled objects and trigger conditions

There are two types of "hotspot code" that will be compiled in real time during the run:

• methods that are called multiple times
• The loop body that was executed multiple times

For the first, the compiler will use the entire method as the compiled object, which is also the standard way to JIT-compile . For the second is the loop body, but the compiler will still use the entire method as the compilation object, because it occurs during method execution, called stack substitution .

Determine whether a piece of code is hot code, is not required to start the immediate compilation, such behavior is called hotspot detection (hot spot Detection), the detection algorithm has two kinds, respectively.

• sampling-based hotspot detection (sample Based hot spot Detection): The virtual opportunity cycle of each line stacks the top of the check, if some methods often appear on the top of the stack, this method is "hot method." The benefits are simple, efficient, and easy to get method call relationships. The disadvantage is that it is difficult to identify the method's reduce, which is susceptible to thread blocking or other exogenous disturbances.
• counter-based hotspot detection (Counter Based Hot Spot Detection): A counter is established for each method (even a block of code), and the number of executions exceeding the threshold is considered a "hotspot method". The advantage is accurate and rigorous statistical results. The disadvantage is that you can't get the calling relationship of a method directly.

Hotspot uses the second-technology-based hotspot probe, and there are two types of counters: The method call counter (invocation Counter) and the Back Edge counter (return edge Counter).

Both counters have a certain threshold value that will trigger JIT compilation after it has passed.

The first is the method call counter . The default threshold in Client mode is 1500, 10,000 times in Server mode, which can be set artificially by-xx:compilethreadhold. If you do not make any settings, the method call counter does not count the absolute number of times the method is called, but rather a relative frequency of execution, that is, the number of times a method has been called within a period of time. When a certain time limit is exceeded, if the number of calls to the method is still insufficient for it to be submitted to the immediate compiler, then the call counter of this method is halved, which is called the attenuation of the method call counter heat (Counter Decay), This period of time becomes the statistic of this method for the half-decay period (Counter Half life time). The action of heat attenuation is in the way when the virtual machine is garbage collected, the time of the half-decay period can be set by using the virtual machine parameter-xx:counterhalflifetime parameter, in seconds. The entire JIT-compiled interactive process is as follows.

The second counter , which is to count the number of times a loop body code executes in a method, is called "Back edge" when it encounters a command that jumps after the control flow in the bytecode. Obviously, the goal of setting up the counter statistics is to trigger the OSR compilation. For the threshold value of this counter, HotSpot provides-xx:backedgethreshold for user settings, but the current virtual machine actually uses-xx:onstackreplacepercentage to introduce the tuning threshold, which is calculated as follows:

In Client mode, the formula is called the method call counter Threshold (Compilethreshold) X OSR ratio (onstackreplacepercentage)/100. Where the OSR ratio defaults to 933, the threshold value for the back edge counter is 13995.

In Server mode, the formula is the method call counter threshold (Compile threashold) X (OSR (onstackreplacepercentage)-interpreter monitor ratio (interpreterprofilepercent))/ 100

Where the default value of Onstackreplacepercentage is 140,interpreterprofilepercentage default is 33, and if the default value is taken, then the Server mode virtual machine back edge counter threshold value is 10700.

The execution process, such as.

3. Compilation Process

By default, either the immediate compilation request produced by the method call or the OSR request, the virtual machine will continue to execute as interpreted until the code compiler is complete, while the compile action is performed in the compilation thread in the background, and the user can pass the parameters- Xx:-backgroundcompilation to suppress background compilation, so that once the JIT compilation condition is reached, the execution thread commits to the virtual machine and waits until the compilation process is complete before it starts executing the native code of the compiler output.

For the Client mode

It is a simple and fast three-segment compiler that focuses on local optimizations and abandons many time-consuming, global optimization tools.

1. The first stage, a platform-independent front end, creates a high-level intermediate code representation of bytecode (high-level intermediate representaion, HIR). Prior to this, the compiler completed a subset of the underlying optimizations on bytecode, such as method inline, constant propagation, and so on.
2. In the second phase, a platform-related backend generates low-level intermediate code representations (low-level intermediate representation, LIR) from HIR, and other optimizations such as null check elimination, scope check elimination, and so on HIR are done before this Make hir more efficient.
3. In the third stage, the platform-related backend uses the linear scan algorithm (Linear Scan register Allocation) to allocate registers on the LIR, making the peephole (peephole) optimization, and then generating the machine code.

The approximate execution of Client Compiler is shown in the following procedure:

For the Server Compiler mode

It is a typical service-oriented application, with a specially tuned compiler for the performance of the server, and a fully optimized advanced compiler that almost achieves the optimization strength of the GNU C + + compiler when using the-o2 parameter, which performs all the classic optimization actions , such as useless Code elimination (Dead code elimination), loop unfold (loop unrolling), loop expression out-of-band (loop expressions hoisting), eliminate common subexpression (Common subexpression elimination), constant propagation (Constant propagation), basic block punch sequencing (basic block reordering), and some optimization techniques that are closely related to Java language features, such as range check elimination (range checked elimination), null check cancellation (null check elimination, not all null check elimination is dependent on compiler optimizations, some are automatically optimized during code run), and so on. In addition, it is possible to perform some unstable radical optimizations based on the performance monitoring information provided by the interpreter or client Compiler, such as the Guardian inline (guarded inlining), Branch frequency prediction (Branch Frequency Prediction) and so on.

The Server Compiler compiler can take advantage of some processor architectures , such as large register collections on (RISC). From an immediate compilation point of view, the Server Compiler is undoubtedly slow, but it is still much faster than the traditional static optimization compiler, and it is relative to the Client Compiler compiled output code quality has improved, can reduce the execution time of local code, This offsets the additional compile-time overhead, so there are many non-server-side applications that choose to run with a virtual machine that is in servers mode.

Deep understanding of Java Virtual Machines (13) Java instant compiler JIT mechanism and compilation optimizations