This is the 17th day of my participation in the November Gwen Challenge. Check out the event details: The last Gwen Challenge 2021
preface
These days, I restudied the memory model and memory barrier. When LEARNING the memory barrier, I learned about the Lock prefix instructions. In order to compile the Lock prefix instructions, I went to learn the bytecode instructions.
I spent another afternoon looking at JVM compilation issues as I had to add some running parameters. Knowledge comes in a loop, and we’re not done with the memory barrier yet. This is probably where the fun of self-learning comes in. Knowledge is endless and continuous, so I put together a summary of Java compilation in the evening.
How does Java code work
The Java code we write is a high-level language that machines cannot read. So we need to translate it into machine language (machine code) that the machine can read. Conversion work is mainly divided into the following steps:
Front-end compiler
A Javac is a front-end compiler that compiles Java files into class files made up of bytecode. The Java code is as follows:
public class Info {
public static void main(String[] args) {
int a = 1; System.out.println(a); }}Copy the codeExecute javac info.java to generate the info.class file and use javap -c info.class to view the bytecode in it.
Class contains the following bytecode:
Interpreters and just-in-time compilers
We compile Java files into class files using javac, and when the JVM starts loading the class, bytecode instructions are executed to complete the program’s functions. But the execution of the program is still on the machine, and the machine does not understand bytecode, so we need to convert bytecode into machine code in order for the machine to execute the program. What is machine code? Machine code is a collection of machine instructions that can be directly recognized and executed by a computer in binary code. The interpreter and Just In Time Compiler (JIT) are the JVM’s tools for converting bytecode to machine code.
The interpreter
The interpreter interprets the bytecode line by line into machine code and executes it wherever it is interpreted. Narrowly defined, this means that if you loop for 100 times, you have to execute the code in the body of the loop line by line 100 times. When a program needs to be started and executed quickly, the interpreter can come into play first, saving compilation time and executing immediately.
Just-in-time Compiler (JIT)
The just-in-time compiler, as I understand it, is a tool that converts the bytecode of hotspot code into machine code at once, in units of method, and caches it locally. Avoid the efficiency problem of partial code being interpreted line by line by interpreter. There are two types of just-in-time Compiler, Client Compiler(C1 Compiler) and Server Compiler(C2). C2 is used by default because of its higher performance.
What is hot code?
Methods and loop bodies that are called multiple times are considered hot code. There are two ways to judge hotspot code. One is sampling-based hotspot detection: periodically check the top of each thread stack and count which method appears more often, but it is not accurate. The second is hot spot detection based on counters: it is currently used to establish counters for each method and count The Times of method invocation. Counters are divided into method call counters (the default threshold C1 is 1500 and C2 is 1W, which triggers just-in-time compilation) and loopback counters (which count the number of times a loop body is executed in a method). The following figure shows the execution of a method call counter:
Operation parameters
When executing a Java program, the following parameters are run and debug parameters for compilation.
conclusion
It covers some of the conceptual aspects of compilers and interpreters, but if you don’t feel like you’ve gone too far, take some time to read up on the Java Virtual Machine Specification.