First, the structure diagram of JVM
1.1 Java Memory Structure
The JVM memory structure mainly has three main blocks: heap memory, method area and stack .
The heap memory is the largest piece in the JVM. It consists of the young generation and the old generation, and the young generation memory is divided into three parts, Eden space, From Survivor space, To Survivor space . By default, the young generation follows the ratio of 8:1:1 to allocate;
The method area stores data such as class information, constants, static variables, etc. It is an area shared by threads. To distinguish it from the Java heap, the method area also has an alias Non-Heap (non-heap);
The stack is further divided into the Java virtual machine stack and the native method stack, which are mainly used for method execution.
1.2 How to control the memory size of each area through parameters
1.3 Control parameters
-Xms sets the minimum size of the heap.
-Xmx sets the maximum size of the heap.
-XX:NewSize sets the minimum space size of the new generation.
-XX:MaxNewSize sets the maximum space size of the new generation.
-XX:PermSize sets the minimum size of the permanent generation.
-XX:MaxPermSize sets the maximum size of the permanent generation.
-Xss sets the stack size per thread.
The parameters of the old generation are not set directly, but two parameters, the heap space size and the young generation space size, can be set for indirect control.
Old generation space size = heap space size - young generation large space size
1.4 The relationship between the JVM and system calls
The method area and the heap are memory areas shared by all threads; while the Java stack, native method stack and programmer counter are memory areas that are run private to threads.
Second, the role of each area of the JVM
2.1 Java heap (Heap)
For most applications, the Java Heap is the largest piece of memory managed by the Java Virtual Machine. The Java heap is a memory area shared by all threads, created when the virtual machine starts. The only purpose of this memory area is to store object instances, and almost all object instances allocate memory here.
The Java heap is the main area managed by the garbage collector, so it is often referred to as the "GC heap". From the perspective of memory recovery, since the collectors basically adopt the generational collection algorithm, the Java heap can also be subdivided into: the new generation and the old generation; more detailed are Eden space, From Survivor space, To Survivor space, etc.
According to the Java Virtual Machine Specification, the Java heap can be in a physically discontinuous memory space, as long as it is logically continuous, just like our disk space. When implemented, it can be implemented as either fixed size or extensible, but the current mainstream virtual machines are implemented in accordance with extensibility (controlled by -Xmx and -Xms).
If there is no memory in the heap to complete the instance allocation, and the heap can no longer be expanded, an OutOfMemoryError exception will be thrown.
2.2 Method Area
The Method Area, like the Java heap, is a memory area shared by each thread. 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. Although the Java virtual machine specification describes the method area as a logical part of the heap, it has an alias called Non-Heap (non-heap), which should be distinguished from the Java heap.
For developers who are accustomed to developing and deploying programs on HotSpot virtual machines, many people are willing to call the method area "Permanent Generation" . The design team chose to extend the GC generational collection to the method area, or use the permanent generation to implement the method area only.
The Java virtual machine specification has very loose restrictions on this area, except that it does not require contiguous memory like the Java heap and can choose fixed size or expandable, and you can also choose not to implement garbage collection. Relatively speaking, garbage collection behavior is relatively rare in this area, but it is not that data enters the method area as "permanently" as the name of the permanent generation. The memory recovery goal of this area is mainly for the recovery of the constant pool and the unloading of types. Generally speaking, the recovery "score" of this area is relatively unsatisfactory, especially the unloading of types. The conditions are quite harsh. Recycling is indeed necessary.
According to the Java virtual machine specification, when the method area cannot meet the memory allocation requirements, an OutOfMemoryError exception will be thrown.
2.3 Program Counter Register
The program counter (Program Counter Register) is a small memory space, and its role can be seen as a line number indicator of the bytecode executed by the current thread. In the conceptual model of the virtual machine (only the conceptual model, various virtual machines may be implemented in some more efficient ways), the bytecode interpreter selects the next item to be executed by changing the value of this counter when working. Bytecode instructions, branch, loop, jump, exception handling, thread recovery and other basic functions all need to rely on this counter to complete.
Since the multithreading of the Java virtual machine is achieved by switching threads in turn and allocating processor execution time, at any given moment, a processor (for a multi-core processor, a core) will only execute one thread instructions in . Therefore, in order to restore the correct execution position after thread switching, each thread needs to have an independent program counter. The counters of each thread do not affect each other and are stored independently. We call this type of memory area "thread private". " of the memory.
If the thread is executing a Java method, this counter records the address of the virtual machine bytecode instruction being executed; if the thread is executing a Natvie method, the counter value is empty (Undefined).
This memory region is the only region that does not specify any OutOfMemoryError conditions in the Java Virtual Machine Specification.
2.4 JVM Stacks (JVM Stacks)
Like program counters, Java Virtual Machine Stacks are also thread-private and have the same life cycle as threads. The virtual machine stack describes the memory model of Java method execution: when each method is executed, a stack frame (Stack Frame) is created at the same time to store the local variable table, operation stack, dynamic link, method exit and other information. The process of each method being called until the execution is completed corresponds to the process of a stack frame from being pushed to the stack in the virtual machine stack.
The local variable table stores various basic data types known at compile time (boolean, byte, char, short, int, float, long, double), object references (reference type, which is not equivalent to the object itself, according to different virtual machines implementation, it may be a reference pointer to the starting address of the object, or it may point to a handle representing the object or other location related to the object) and returnAddress type (pointing to the address of a bytecode instruction).
The 64-bit long and double types of data occupy 2 local variable spaces (Slots), and the rest of the data types only occupy 1. The memory space required by the local variable table is allocated during compilation. When entering a method, how much local variable space the method needs to allocate in the frame is completely determined, and the size of the local variable table will not be changed during the method 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 expanded, but the Java virtual machine specification also allows a fixed-length virtual machine stack), and an OutOfMemoryError exception will be thrown when sufficient memory cannot be applied for during expansion.
2.5 Native Method Stacks
The role played by the native method stack (Native Method Stacks) and the virtual machine stack is very similar, the difference is that the virtual machine stack serves for the virtual machine to execute Java methods (that is, bytecode), while the native method stack is for the virtual machine. Native method service used by the virtual machine. The virtual machine specification does not mandate the language, usage and data structure of the methods in the native method stack, so a specific virtual machine can freely implement it. Even some virtual machines (such as the Sun HotSpot virtual machine) directly combine the native method stack and the virtual machine stack into one. Like the virtual machine stack, the native method stack area also throws StackOverflowError and OutOfMemoryError exceptions.