Memory Structure Model of JVM Runtime Data Area
Program counter
Program Counter (Program Counter Register), also known as PC register. In assembly language, the program counter refers to the register in the CPU, which holds the address of the instruction currently being executed by the program (it can also be said to save the address of the storage unit where the next instruction is located). When the CPU needs to execute the instruction, it needs to Get the address of the storage unit where the current instruction needs to be executed in the program counter, and then get the instruction according to the obtained address. After getting the instruction, the program counter will automatically increase by 1 or get the address of the next instruction according to the transfer pointer, and so on, until After executing all instructions.
Although the program counter in the JVM is not a physically conceptual CPU register like the program counter in assembly language, the function of the program counter in the JVM is logically equivalent to the function of the program counter in assembly language, that is, Said to indicate which instruction to execute.
In the JVM, multi-threading is obtained by taking turns to obtain CPU execution time. Therefore, at any specific moment, the core of a CPU will only execute instructions in one thread. Therefore, in order to enable each thread to be in the thread After the switch, the execution position of the program before the switch can be restored. Each thread needs to have its own independent program counter and cannot be interfered with each other, otherwise it will affect the normal execution order of the program. Therefore, it can be said that the program counter is private to each thread.
In the JVM specification, if the thread executes a non-native method, the program counter holds 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.
Because the size of the space occupied by the data stored in the program counter will not change with the execution of the program, therefore, there will be no memory overflow (OutOfMemory) for the program counter.
Java Virtual Machine Stack
Like the program counter, the Java Virtual Machine Stack (Java Virtual Machine Stacks) is also private to the thread, and its life is the same as the thread. The virtual machine stack describes the memory model of Java method execution; each method will create a stack frame (Stack Frame) for storing local variable table, operand stack, dynamic link, and method exit light information while executing. The process of each method from invocation to completion of execution corresponds to the process of stacking a stack frame from the virtual machine stack to the stack.
In the 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, if it cannot be applied during expansion If there is enough memory, an OutOfMemoryError exception will be thrown.
Native 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 executes Java methods (that is, bytecode) services for the virtual machine, and the local method stack It serves the Native method used by the virtual machine. The language, usage and data structure of the methods in the local method stack are not mandatory in the virtual machine specification, so the specific virtual machine can freely implement it. Sun HotSpot directly combines the local method stack and the virtual machine stack into one. Like the virtual machine stack, StackOverflowError and OutOfMemoryError exceptions are thrown in the local method stack area.
stack
The Java Heap is the largest piece of memory managed by the Java Virtual Machine. The Java heap is an area of memory shared by all threads and is created when the virtual machine starts. The sole purpose of this memory area is to store object instances, where almost all object instances are allocated memory.
Method area
Like the Java heap, the method area is a memory area shared by various threads. It is used to store data such as class information, constants, static variables, and code compiled by the real-time compiler that have been loaded by the virtual machine. In the Class file, in addition to the description information such as the fields, methods, and interfaces of the class, there is a piece of information is the constant pool, which is used to store the literals and symbol references generated during compilation.
A very important part in the method area is the runtime constant pool, which is the runtime representation of the constant pool of each class or interface. After the class and interface are loaded into the JVM, the corresponding runtime constant pool is Created. Of course, it is not the contents of the Class file constant pool that can enter the runtime constant pool. During operation, new constants can also be put into the runtime constant pool, such as the String intern method. In the JVM specification, there is no mandatory requirement that the method area must implement garbage collection. Many people are used to calling the method area "permanent generation" because the HotSpot virtual machine implements the method area in a permanent generation, so that the JVM's garbage collector can manage this area like the heap area, so there is no need for this part. Design a garbage collection mechanism. However, since JDK7, the Hotspot virtual machine has removed the runtime constant pool from the permanent generation.
