Documenting JVM Memory model content

Statement: This content is bloggers in the cattle online to see the answer published by netizens, because the feeling summed up is better, so excerpt come for everyone to learn.

Content:

Most JVMs divide the memory area into method area (non-heap), Heap (heap), program Counter Register (Application counter), VM stack (virtual machine stack, also translated into Java method stack), N Ative method Stack (local methods stack), where method area and Heap are thread-shared, VM Stack,native method Stack and program Counter Register non-threaded Shared. Why is it divided into thread sharing and non-thread sharing? Please continue looking down.

First, we are familiar with the working process of a generic Java program. A Java source program file will be compiled into a bytecode file (with class extension), each Java program needs to run on its own JVM, and then inform the JVM program run the portal, and then by the JVM through the bytecode interpreter load run. So how does the program get involved in each memory area after it starts running?

In a nutshell, when the JVM is initially running, it allocates the method area and heap (heap), and each time the JVM encounters a thread, it assigns it a program Counter Register (Application counter), VM stack (virtual machine stack), and N Ative method Stack (local stack), when the thread terminates, the memory space occupied by the three (virtual machine stack, local method stack, and program counter) is also freed. This is why I divide the memory area into thread sharing and non-thread sharing, and the three areas of non-thread sharing have the same life cycle as the owning thread, while the areas shared by the threads are the same as the Java program's life cycle. So this is the reason that the system garbage collection takes place only in the area of the thread share (which actually occurs on the heap for most virtual machines).

As shown:

The following summarizes the role of each region:

A) program counter (PC Register)

Because in the JVM, multithreading is to get CPU execution time by rotating threads, so at any given moment, a CPU kernel only executes instructions in one thread, therefore, in order to be able to make each thread switch back to the program execution location before switching, Each thread needs to have its own independent program counter, and cannot be interfered with each other, otherwise it will affect the normal order of execution of the program. So, so to speak, the program counters are private to each thread. Because the size of the space that is stored in the program counter does not change with the execution of the program, there is no memory overflow phenomenon (OutOfMemory) for program counters.

b) Java stack

The Java stack holds a stack of frames, each of which corresponds to a called method that includes a local variable table (local Variables), an operand stack (Operand stack), and a reference to the run-time pool of the class to which the current method belongs (Reference To runtime constant pool), method return address, and some additional additional information. When a thread executes a method, it creates a corresponding stack frame and pushes the stack frame to be built. When the method finishes executing, the stack frame is stacked.

c) Local method stack

The local method stack works very much like the Java stack. The difference is simply that the Java stack is for the Java Method service, while the local method stack is the one that performs the local method (Native) service.

d) Heap

The heap in Java is used to store the object itself as well as an array (the array references are stored in the Java stack). The heap is shared by all threads, and there is only one heap in the JVM.

E) Method Area

As with heaps, it is a zone that is shared by threads. In the method area, information is stored for each class (including the name of the class, method information, field information), static variables, constants, and compiler-compiled code. In the class file, in addition to the description of the fields, methods, interfaces, and so on, there is a constant pool that stores the literal and symbolic references generated during compilation.

Documenting JVM Memory model content