Shulou(Shulou.com)06/03 Report--

Today, I will talk to you about how to understand what the Java virtual machine and JVM architecture is. Many people may not know much about it. In order to make you understand better, the editor has summarized the following for you. I hope you can get something from this article.

JVM (Java virtual machine)

Java virtual machine, java source file (.java) generates bytecode file (.class) through compiler, and bytecode file (.class) is translated into machine code on specific machine through interpreter in JVM (Java virtual machine).

The compiler only needs to face the virtual machine, generate the code that the virtual machine can understand, and then the interpreter converts the virtual machine code into the machine code of a specific system.

The interpreter for each platform is different, but the virtual machine implemented is the same.

After the Java source program is compiled by the compiler, the bytecode is interpreted and executed by the virtual machine. The virtual machine sends each bytecode to be executed to the interpreter, which translates it into machine code on a specific machine, and then runs on the specific machine.

JVM architecture

JVM has two mechanisms, one is to load a class (class or interface) with the appropriate name, called the class loading subsystem, and the other is responsible for executing instructions contained in the loaded class or interface, called the run engine. Each JVM includes five parts: method area, heap, Java stack, program counter and local method stack. The architecture diagram of these parts, together with the class loading mechanism and the running engine mechanism, is as follows:

Each instance of JVM has its own method domain and a heap, which are shared by all threads running in JVM; when the virtual machine loads class files, it parses the class information contained in the binary data in it and puts them into the method domain; when the program runs, JVM puts all objects initialized by the program on the heap When each thread is created, it will have its own program counter and Java stack, in which the value in the program counter points to the next instruction to be executed, and the thread's Java stack is stored as the state of the thread calling the Java method; the state of the local method call is stored in the local method stack, which depends on the specific implementation.

(1) Class loading subsystem

Load connection initialization

(2) method area. Shared by all threads. Garbage collection also cleans up useless type objects in the method area.

a. Type information. When the class loader loads the class, it is extracted from the class file.

The full valid name of the class

The full valid name of the parent class (except interface and java.lang.Object, because there is no parent class)

Modifiers for types

Type Direct Interface list

b. Constant pool. Stores symbolic references to all types, fields, and methods used by a type.

c. Domain information. Jvm must store information about all fields of the type and the order in which they are declared in the method area. The relevant information about the domain includes: domain name domain type domain modifier (public private protected static final volatile transient … )

d. Method information.

Method name

Method return type

Method parameters

Modifiers for methods

Bytecode of the method (except abstract and native) (pointed to by the PC register)

The size of the local variable area of Operand stack and method stack frame

Abnormal table

e. Static variable of the class (all objects share a copy)

f. Class is declared as a final class variable (all objects share a copy)

g. A reference to the class loader that loads a class

H. references to the Class class

i. Method table.

j. An example:

Class Lava {private int speed = 5; void flow ();} Class Volcano {public static void main (String [] args) {Lava lava = new Lava (); lava.flow ();}}

Let's describe how the bytecode of the * * instruction of the main () method is executed. This is just one of the many differences between different jvm implementations.

In order to run this program, you passed "Volcano" to jvm in some way. With this name, jvm finds the class file (Volcano.class) and reads it in. It extracts the type information from the class file and puts it in the method area. By parsing the bytecode in the existing method area, jvm activates the main () method. When executed, jvm maintains a pointer to the constant pool of the current class (Volcano).

Notice that jvm starts execution before the Lava class is loaded. Like most jvm, execution does not wait until all classes have been loaded, it only loads when needed.

The * instruction of main () tells jvm to allocate enough memory for the class listed in the constant pool * item. Jvm uses a pointer to the Volcano constant pool to find the * * entry, which it finds to be a symbolic reference to the Lava class, and then checks the method area to see if lava has been loaded.

This symbolic reference is simply the full valid name of the class lava, "lava". Here we see how important a good data structure is in order for jvm to find a class from a name as soon as possible. Here jvm implementers can use a variety of methods, such as hash tables, lookup trees, and so on. The same algorithm can be used for the implementation of forName () of the Class class.

When jvm discovers that a class called "Lava" has not been loaded, it starts to find and load the class file "Lava.class". It extracts type information from the class file and puts it in the method area.

Jvm then replaces the symbolic reference of the constant pool * * item with a pointer directly to the lava class in the method area. In the future, you can use this pointer to quickly find the lava class. This replacement process is called constant pool parsing (constant pool resolution). What we replace here is a native pointer.

Jvm is finally starting to allocate space for the new lava object. This time, jvm still needs the information in the method area. It uses a pointer to lava data (the pointer to the volcano constant pool * * entry just now) to find out exactly how much space a lava object needs.

Once jvm knows the space required by a Lava object, it allocates the space on the heap and initializes the instance's variable speed to the default value of 0. If the parent of the lava also has an instance variable, it will also be initialized.

When the reference to the newly generated lava object is pushed onto the stack, the * instruction ends. The following instruction uses this reference to activate the java code to set the speed variable to the initial value, 5. Another instruction uses this reference to activate the flow () method of the Lava object.

(3) heap. Stores all objects and arrays at run time.

(4) stack. Each time a new thread is started, a stack is assigned.

(5) the PC register (program counter) always points to the instruction that the thread will execute next. The position of the instruction is placed in the method bytecode in the method area. The content is the offset relative to * instructions.

After reading the above, do you have any further understanding of how to understand the Java virtual machine and JVM architecture? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.