1. Constant pool

1.1. The data structure used by the constant pool

The bottom layer of the constant pool uses HashTable

key is the hashValue generated by string and length, and then hash generates index, the index is the key; Value is a HashTableEntry;
1. key
   hashValue = hash string(name, len)
   index = hash to index(hashValue);
   1. According to The string (name) and the length of the string are used to calculate the hashValue
   2, and the index is calculated according to the hashValue, the index is key
2, value
   1, HashtableEntry<oop, mtSymbol>* entry = new entry(hashValue, string());
   2. Encapsulate instanceOopDesc of the Java string class into HashtableEntry
   3. struct HashtableEntry {        INT PTR hash;        void* key;        void* value; instanceopDesc        HashtableEntry* next;    };

1.2. How does the bottom layer of the JVM operate the constant pool

String s = "1";

1. Go to the string constant pool to check, and return the corresponding string object directly.
2. If not, it will create a string object and a char array object.
3. Encapsulate the InstanceOopDesc corresponding to the string object into a HashtableEntry as the value of the StringTable to store

4. new String() is to create another object char[] on the heap to point to typeArrayOopDesc

2. Even Compiler and Parser

2.0 Compilation process

The .java source file is compiled into a .class file by the compiler (javac.exe)
The JVM interprets the .calss file through the ClassLoader (self-decoding interpreter and JIT compiler)—this process needs to call the core class

3. Talk about the interpreter (Just In Time Compiler) and just-in-time compiler (JIT) in the JVM

Function: Interpreter and Just In Time Compiler (Just In Time Compiler, JIT) is a tool in the JVM that converts bytecode into machine code.

Interpreter: The interpreter parses the bytecode into machine code that the set understands. The interpretation method is to read line by line, and execute wherever it is explained.
Even the compiler: A tool that converts the bytecode of the hot code into machine code at one time and caches it locally in units of methods. It avoids the efficiency problem that some codes are interpreted and executed line by line by the interpreter.

2.1 Compiler

2.1.1 Types of just-in-time compilers

C1
C2

2.1.2 Just-in-time compiler layered compilation

Layered compilation
       c1 compiler is a just-in-time compiler in client mode
           1. The triggering conditions are relatively loose compared with C2: less data needs to be collected
           2. Compilation optimization is relatively shallow: basic calculations are finalized during compilation
           3. The execution efficiency of the code compiled by the c1 compiler is lower than that of C2 . The            c2
       compiler is a just-
           in-time compiler in server mode            . , The execution efficiency of the code generated by compilation is higher than that of C1.        The mixed compiler            program triggers the C1 compiler at the beginning of its operation and            triggers the C2 compiler after the program runs for a period of time.

2.1.3 Relationship between Compiler and Interpreter

The code generated by the just-in-time compiler is used by the template interpreter

Interpreter: When the program is executed, the interpreter first plays a role, which saves the compilation time of the compiler and speeds up the execution efficiency of the program
Compiler: During the running of the program, as time goes by, the compiler begins to play a role slowly. After compiling hot codes into local codes, the same codes can be executed later to obtain them directly, with higher execution efficiency .
Interpreters and compilers work together to make programs execute efficiently.

2.1.4 Problem sharing

Share a fault in Ali's early years. Hot
machine cut cold machine fault: After the cold machine was started, a large number of codes were compiled, causing the cpu to explode, and the machine was down .

2.1.5 Hot code storage location

The hot code cache area is in the method area, and CodeCache exists in the C++ code. In a server compiler mode during tuning, the code cache size starts at 2496KB

The code cache size starts at 160KB in client compiler mode

2.1.6 Trigger conditions

Hot code is compiled into hard-coded assembly instructions
Hot code
The smallest unit of just-in-time compilation is not a function, but a code block (for, while)

Judgment hot code detection method

Sampling Hot Spot Detection

Periodically check the top of the thread stack, and the code that often appears on the top of the stack is the hot code

Advantages: simple and efficient.
Disadvantages: vulnerable to thread blocking or other factors

method call counter

In client compiler mode, the default value of N is 1500
In server compiler mode, the default value of N is 10000

It can be set by -XX: CompileThreadhold, and the number of times it is called within a period of time. When a certain time limit is exceeded, if the number of method calls is still not enough to submit it to the just-in-time compiler for compilation, then the call counter of this method will be reduced by half. This process is called method call counter heat decay (Counter Decay) , and this period of time becomes the statistical half-life period (Counter Half Life Time) of this method. The action of heat decay is performed by the way when the virtual machine performs garbage collection. You can use the virtual machine parameter -XX:CounterHalfLifeTime parameter to set the time of the half-life cycle in seconds.

Back Edge Counter

Count the number of times the loop body code is executed in a method, and the instruction that jumps backward when the control flow is encountered in the bytecode is called "Back Edge". Apparently, the purpose of establishing back-edge counter statistics is to trigger OSR compilation. Regarding the threshold of this counter, HotSpot provides -XX:BackEdgeThreshold for users to set, but the current virtual machine actually uses -XX:OnStackReplacePercentage to briefly adjust the threshold.

2.2 Parser

2.2.1 Interpreter types

Bytecode Interpreter
Java Bytecode -> C++ Code -> Hardcoded

template interpreter

Java bytecode -> hardcoded

2.2.2 Operation mode

The parser has three operating modes
1, -Xint pure bytecode interpreter
2, -Xcomp pure template interpreter
program is relatively large
3, -Xmixed bytecode interpreter + template interpreter

Compare the performance of these three operating modes
231
321
is related to the size of the program. When the program is large, Xcomp will make the program larger, and the compiler is very slow.

3. Escape Analysis

3.1 Escape

what object does not escape

Local objects do not generate escapes

what object will escape

Shared variables, method return values, and parameters will escape

3.2 Analysis

three means

3.2.1 Scalar substitution

public void test2() {
    System.out.println(EA);
    System.out.println(1);
}

3.2.2 Lock Elimination

Local object new Object(), the lock is eliminated

public void test() {
    synchronized (new Object()){
        System.out.println("=============");
    }
}

public void test() {
     System.out.println("=============");
}

3.2.3 Object allocation on the stack

In a method that does not generate an escape, the object will be partially allocated on the stack

Reference blog: JVM's mixed mode_yzpyzp's blog - CSDN blog

JVM constant pool, just-in-time compilation and parser, escape analysis