https://blog.csdn.net/shenwansangz/article/details/95601232
In some commercial virtual machines (such as HotSpot), Java programs are initially interpreted and executed through an interpreter. When the virtual machine finds that a method or code block runs particularly frequently, it will identify these codes as " Hot code".
In order to improve the execution efficiency of the hot code, at runtime, the virtual machine will compile these codes into machine code related to the local platform and perform various levels of optimization. The compiler that completes this task is called a just-in-time compiler (Just In Time Compiler, the JIT compiler)
## Just-in-time compiler is not a necessary part of the virtual machine, but the compilation performance of the just-in-time compiler and the degree of code optimization are one of the most critical indicators to measure the excellence of a commercial virtual machine
"-Client" or "-server" parameter
There are two built-in just-in-time compilers in the HotSpot virtual machine: Client Complier and Server Complier, referred to as C1 and C2 compilers, which are used on the client and server respectively. Which compiler the program uses depends on the mode of the virtual machine. The HotSpot virtual machine automatically selects the operating mode according to its own version and the hardware performance of the host machine. The user can also use the "-client" or "-server" parameter to force the specified virtual machine to run in Client mode or Server mode
Use Client Complier to get higher compilation speed, and Server Complier to get better compilation quality
Hot Spot Detection
There are currently two main hot spot detection methods:
(1) Hot spot detection based on sampling:
The virtual machine using this method periodically checks the top of the stack of each thread. If it is found that certain methods often appear on the top of the stack, then this method is a "hot method". The advantage of this detection method is that it is simple and efficient to implement, and it can also easily obtain the method call relationship (just expand the call stack). The disadvantage is that it is difficult to accurately confirm the popularity of a method, and it is easy to be blocked by threads or other outsiders. Factors that disrupt hot spot detection
(2) Hot spot detection based on counter
The virtual machine using this method establishes a counter for each method (even code block) to count the number of executions of the method. If the number of executions exceeds a certain threshold, it is considered a "hot method". This kind of statistical method is more complicated to implement, it is necessary to establish and maintain a counter for each method, and the method call relationship cannot be directly obtained, but its statistical results are relatively more precise and rigorous.
## The second method used in the HotSpot virtual machine is a counter-based hot spot detection method. Therefore, it prepares two counters for each method: method call counter and back-end counter. It is on the premise of determining the virtual machine operating parameters Down, these two counters have a certain threshold, when the counter exceeds the threshold overflow, it will trigger JIT compilation
JIT compilation threshold: -XX:CompileThreshold=Nflag
JIT compilation is triggered by the value of -XX:CompileThreshold=Nflag. In Client compiler mode, the default value of N is 1500, and in Server compiler mode, the default value of N is 10000
Method call counter
When a method is called, it will first check whether the method has a JIT-compiled version. If it exists, the compiled native code will be used first. If there is no compiled version, the method call counter value is increased by 1, and then it is judged whether the sum of the method call counter and the backside counter value exceeds the method call counter threshold. If the threshold is exceeded, a code compilation request for this method will be submitted to the just-in-time compiler
Backward counter
Counting the number of executions of the loop body code in a method, the instruction that jumps backward when the control flow is encountered in the bytecode is called "back edge".
Rebound can effectively be considered as the number of times the loop is executed, not only because it is the end of the loop, but also because it executes a branch statement, such as continue
On-Stack Replacement (OSR): The JVM must be able to start executing the compiled version of the loop while the loop is running.
https://developer.ibm.com/zh/articles/j-lo-just-in-time/
If there is a long loop in the method or a program that never exits and provides all the logic, the JVM needs to compile the loop without waiting for the method to be called. So every time the loop is executed, the branch counter will increment and self-check. If the branch counter count exceeds its own threshold, then this loop (not the entire method) will be eligible to be compiled
JIT compiled code cache
When the JVM compiles the code, it saves the assembly instruction set in the code cache.