Before discussing JVM memory area analysis, let's take a look at the specific execution process of Java programs:
The execution process of a Java program: Java source code file (.Java file) -> Java Compiler (Java compiler) -> Java bytecode file (.class file) -> Class Loader (Class Loader) -> Runtime Data Area (Runtime Data) -> Execution Engine. Let's analyze the Runtime Data Area (runtime data) of the Java program execution process today.
So what parts does the runtime data area include?
-
Program Counter Register
-
Java Virtual Machine Stack (VM Stack)
-
Native Method Stack
-
method area
-
heap
1. Program counter
It is used to indicate which instruction the program executes, which is logically the same as the function of the program counter in assembly language. The JVM specification stipulates that if the thread executes a non-native method, the program counter stores the address of the instruction that needs to be executed currently. If the thread executes the native method, the value in the program counter is undefined. Each thread has its own independent program counter. why? Because under multi-threading, a CPU core can only execute instructions in one thread, so in order to enable each thread to resume the program execution position before the switch after thread switching, each thread has its own independent program counter.
Second, the Java virtual machine stack
The Java virtual machine stack stores stack frames one by one. When the program executes a method, a stack frame is created and pushed into the stack. When the method is executed, the stack frame is removed from the stack. What we call "stack" refers to the Java virtual machine stack. A stack frame includes: local variable table, operand stack, dynamic connection, method return address, additional information
local variable table
It mainly stores the local variables in the method, including the information of the local variables in the method and the parameters of the method. Such as: various basic data types (boolean, byte, char, short, int, float, long, double), object reference (reference type, which is not equivalent to the object itself, may be a reference pointer to the starting address of the object, It may also point to a handle representing an object or other location related to this object) and returnAddress type (pointing to the address of a bytecode instruction), where 64-bit long and double type data will occupy 2 local variables Space (Slot), the rest of the data types only occupy one. The size of the local variable table is determined by the compiler, so the size of the local variable table does not change during program execution. In the Java virtual machine specification, two exception conditions are specified for this area: if the stack depth requested by the thread is greater than the depth allowed by the virtual machine, a StackOverflowError exception will be thrown; if the virtual machine stack can be dynamically expanded (most current Java Virtual machines can be dynamically extended, but the Java virtual machine specification also allows a fixed-length virtual machine stack). If enough memory cannot be applied for during expansion, an OutOfMemoryError exception will be thrown.
operand stack
The virtual machine uses the operand stack as its work area. All calculations in the program are done with the help of the operand stack. Most instructions pop data from here, perform the operation, and then push the result back to the operand. stack.
dynamic link
Each stack frame contains a reference to the method to which the stack frame belongs in the runtime constant pool (pointing to the runtime constant pool: constants in the class may be needed during method execution), and this reference is held for the purpose of Support dynamic connection during method invocation
method return address
When a method finishes executing, it needs to return to the place where it was called before, so a method return address must be saved in the stack frame.
extra information
The virtual machine specification allows a specific virtual machine implementation to add some information not described in the specification to the stack frame, such as highly relevant information, which depends entirely on the specific virtual machine implementation. In actual development, dynamic connection, method return address and other additional information are generally classified into one category, which is called stack frame information.
Third, the local method stack,
The native method stack (Native Method Stack) and the virtual machine stack play a very similar role, the difference between them is that the virtual machine stack serves for the virtual machine to execute Java methods (that is, bytecode), while the native method stack serves. It serves the Native method used by the virtual machine. Like the virtual machine stack, the native method stack area also throws StackOverflowError and OutOfMemoryError exceptions.
Fourth, the heap (heap)
In the C language, programmers can apply for and release space on the heap through the malloc function and the free function. So what is it like in Java? The heap in Java is used to store the objects themselves and arrays (of course, array references are stored in the Java stack), and almost all object instances are allocated memory here. In Java, programmers basically don't have to care about the issue of space release, and Java's garbage collection mechanism will handle it automatically. Also, the heap is shared by all threads, there is only one heap in the JVM.
5. Method area
The method area (Method Area), like the Java heap, is a memory area shared by each thread, which is used to store class information, constants, static variables, and code compiled by the compiler that have been loaded by the virtual machine. The Runtime Constant Pool is part of the method area. In addition to the description information of the class version, field, method, interface, etc. in the Class file, there is also a constant pool (Constant Pool Table), which is used to store various literals and symbolic references generated during compilation. This part of the content It will be stored in the runtime constant pool that enters the method area after the class is loaded. In the JVM specification, there is no mandatory requirement for method areas to implement garbage collection. Many people are accustomed to calling the method area "permanent generation" because the HotSpot virtual machine implements the method area in the permanent generation, so that the JVM's garbage collector can manage this part of the area like the heap area, so there is no need for this part. Design garbage collection mechanism. However, since JDK7, the Hotspot virtual machine has removed the runtime constant pool from the permanent generation.
http://mp.weixin.qq.com/s/Kuj9MzlSoSlBc0OvUjc6Yw