Deep Java Virtual Machine (program run)

Intro: Open the Black box

Honestly, for C + + 's entire compilation run process, I did not fully understand, several times was asked to live, it seems that the Assembly did not learn, but after reading the "Deep Java Virtual Machine", for Java code to run every detail, have a more comprehensive understanding.

Describe the overall process: Programmers write Java programs according to the Java API, various classes of files, a Java compiler to compile a Java program as a class file, class file by a certain distribution method by the Java Virtual machine loading, connection, initialization, becomes the class class of the Java Virtual Machine method area and then is instantiated as the object of the heap area, and as the virtual machine executes, the object may no longer be referenced and garbage collected, then the class file may become inaccessible and be unloaded by the virtual machine, and finally the virtual machine exits with the end of the last non-background thread.

Step One: Write Java program "build *.java"

A Java file allows you to define only a Java class that is public, because the virtual machine is defined by the mechanism of the file name of the search type. Java programmers write programs based on the Java API.

Step two: Compile the Java file to "generate class" for the class file

The structure of the class file contains all the information that the Java virtual machine needs to know about the class. The file content is roughly: Magic, version, Chang, This_class, Super_class, interfaces, fields, methods, properties

The class file is a little bit around the constant pool. Constants in a constant pool are not the narrow constants of our programmer's perspective , the name of a class is constant, the description of a method is a constant, and the description of a property is also a constant. The constant pool contains all the literal information, through the index, you can find the name and description of a method, a field name, a constant string, and so on. In the connection model, there is a parsing process, because in the bytecode, all are symbolic references, such as calling a method, bytecode is called a constant area of the content, this content represents a method, so this needs to be parsed, this constant area of the reference to the direct reference to the method. The parsed items in a constant pool are flagged so that the next time you don't have to parse them again.

So we look at how the class file completely expresses the information of a kind: The name of the class can be obtained through the constant pool pointed to by This_class, the parent class through Super_class, interface, method, field can be found in the corresponding file segments in the constant area of the basic information. The bytecode of the method defines the bytecode in the attribute field of the method, and the properties of the method define how many variables to use, and how much stack space is required.

Step three: Mount, connect, initialize "Generate class"

At the very beginning we emphasized that through certain distribution methods, this is because the class file may exist with the running virtual machine, or it may exist with a user-defined type loader on the network, and developers can define a flexible mechanism for obtaining code.

1, load. The mount must produce a binary stream representing that type (read the file or from the network or otherwise), parse the binary data into an internal data structure, and create a Java.lang.Class class

2, verify. Verify that the semantics of the Java language are met.

3, ready. Allocates memory for class variables and initializes them to default values.

4, parsing. is to look for symbolic references to classes, interfaces, fields, and methods in a constant pool of types, replacing them with a direct reference process. Parsing is optional until the symbol reference is used for the first time.

5, initialize. The initial value initialized to "correct", which is the initial value expected by the programmer, is defined by static in the code and is collected in the <clinit> method.

Step four: class instance generation, garbage collection "Generate class instance: Object"

Now that everything is in place, the program starts running. The memory is as separate as

At this point, I think we have a comprehensive understanding of the entire process (we deliberately ignore the security-related topics)

From the point of view of the virtual machine, the first is the class file to be confronted, the class file is read and parsed, the PC register is set to the main portal, and then the bytecode is executed. The bytecode is always for the stack, so the virtual machine knows that the operand is on the stack. Bytecode is defined by operators and operands, which may be local variables of the Java stack, and may be references to constant pools. If it is a reference to a constant pool and has not yet been resolved, it needs to be resolved. At any time, the stack is a basic variable or object reference, and the execution is done.

Deep Java Virtual Machine (program run)