Luban College Java Architect Growth Path
1. What parts does the JVM contain
? 1. Class Loader: Load class files into memory. Class loader only loads, as long as it conforms to the file structure, it is not responsible for whether it can run, it is the responsibility of the Execution Engine.
2. Execution Engine (Execution Engine): also called interpreter, responsible for interpreting commands, which are executed by the operating system.
3. Native Interface: The function of the native interface is to integrate different languages for java.
4. Next, explain the runtime data area in detail.
2. The
above picture is the JVM conceptual model (it is just a conceptual model, different java virtual machines have different implementations). Most blog explanations ignore this point, leading to confusion in the reader's concept.
2.1 Program counter
(1) The bytecode interpreter selects the next bytecode instruction to be executed by changing the value of the program counter. Basic functions such as branch, loop, jump, exception handling, and thread recovery all rely on this counter to complete.
(2) Each thread has an independent program counter.
(3) If the execution is a Java method, this counter records the address of the bytecode instruction being executed; if it is a native method, the value of the counter is Undefined. This is also the only area in the JVM specification that does not specify OutOfMemoryError.
2.2 Java virtual machine stack
(1) The Java virtual machine stack is also thread private. The Java virtual machine stack describes the memory model of Java method execution: when each method is executed, a stack frame is created to store information such as the local variable table, operand stack, dynamic link, and method exit. The process of each method from invocation to completion of execution corresponds to the process of pushing the stack frame to popping the stack.
(2) The stack is often said, the stack here refers to the stack frame or the local variable table part in the stack frame. The local variable table stores various basic data types, object references and returnAddress types (a bytecode instruction address) that can be known at compile time. Long and double occupy 2 local variable spaces (Slot), and other data types occupy 1.
(3) Two abnormal conditions are specified in this area. StackOverflow (the stack depth requested by the thread is greater than the depth allowed by the virtual machine) and OutOfMemoryError (cannot apply for enough memory).
2.3 Local method stack
The native method stack is similar to the Java virtual machine stack. The virtual machine stack serves the virtual machine to execute Java methods (bytecode), and the local method stack serves the Native method. HotSpot combines the local method stack and the virtual machine stack into one.
For example, the native-modified method under the Unsafe class is implemented by C or C++ and called by Java.
2.4 Heap
(1) The vast majority of object instances are allocated on the heap, but not absolutely.
(2) If a garbage collector based on the generational collection algorithm is used (it must be based on the generational collection algorithm!), the Java heap can also be subdivided into the new generation and the old generation; and then can be divided into Eden area, From Survivor area, To Survivor area, about generational collection, will be explained in detail later.
(3) When the heap cannot be expanded, an OutOfMemoryError will be thrown.
2.5 Method area
(1) Used to store class information, constants, static variables, and code compiled by the just-in-time compiler. ,
(2) The method area is implemented in the HotSpot virtual machine (the virtual machine with Oracle Jdk and OpenJdk) with permanent generation (personal understanding method area + GC generation collection = permanent generation), HotSpot extends GC generation collection to the method area ( Originally only in the heap), so HotSpot can manage this part of the memory like the Java heap. (For such as BEA Jrockit, IBM J9, there is no concept of permanent generation). In JDK7, the official has moved the string constant pool that originally existed in the permanent generation from the permanent generation (most blogs currently believe that it has been moved to the heap area and has not been verified). The concept of permanent generation is abandoned in JDK8 and metaspace is used instead.
(3) OutOfMemoryError will be thrown in this area.
2.6 Runtime constant pool
(1) The runtime constant pool is part of the method area. The constant pool (Constant Pool Table, used to store various literals and symbol references generated during compilation) for storing Class files. This part of the content will be stored in the runtime constant pool of the method area after the class is loaded.
You can view the class file information by executing the javap -verbose xxxx.class command. The following figure shows the constant pool information
