Explore Java's virtual machine memory

Before discussing the JVM memory area analysis, take a look at the process that the Java program performs specifically:

Java program execution Process: Java source code files (. java file), Java Compiler (Java compiler)->java bytecode file (. class file), ClassLoader (class Loader)->runtime data area (runtime data)- > execution engine (execution engines). Let's take a look at the runtime data area of the Java program execution.

So what are the parts of the run-time data area?

• Program counter (Counter Register)

• Java Virtual machine stack (VM stack)

• Local methods Stack (Native method Stacks)

• Method area

• Heaps (heap)

First, the program counter

Used to indicate which instruction the program executes, which is logically the same as the function of a program counter in assembly language. The JVM specification stipulates that if a thread executes a non-native method, the program counter holds the address of the instruction that is currently required to execute, and if the thread executes the native method, the value in the program counter undefined. Each thread has its own independent program counter. Why is it? Because of multithreading, a CPU core only executes instructions from one thread, so each thread has its own independent program counter in order to be able to revert to the point where the program was executed before the switch after the thread switch.

Second, Java Virtual machine stack

A stack frame is stored in the Java Virtual machine stack, and when the program executes a method, it creates a stack frame and presses it into the stack, and when the method executes, the stack frame is removed. 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 is mainly the local variables in the storage 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 start address of the object, It may also point to a handle that represents an object or other location associated with this object) and the ReturnAddress type (the address of a bytecode directive), where 64-bit long and double-type data consumes 2 local variable spaces (slots). The remaining data types only occupy 1. The size of the local variable table can be determined by the compiler, so the size of the local variable table will not change during program execution. In the Java Virtual Machine specification, there are two exceptions to this area: if the thread requests a stack depth greater than the virtual machine allows, the STACKOVERFLOWERROR exception will be thrown, and if the virtual machine stack can be dynamically extended (most of the current Java virtual machines can be dynamically extended, However, the Java Virtual Machine specification also allows a fixed-length virtual machine stack, which throws a OutOfMemoryError exception if the extension cannot request enough memory.

Operand stacks

The virtual machine takes the operand stack as its working area, and all the computational processes in the program are done with the help of the operand stack, and most of the instructions are to pop the data from here, perform the operation, and then press the result back to the operand stack.

Dynamic connection

Each stack frame contains a reference to the method that the stack frame belongs to in the run-time pool, which points to the running constant pool: constants that are likely to be used in the class during method execution, and the reference is held to support dynamic connections during method invocation

Method return Address

When a method executes, it returns to the place where it was previously called, so a method return address must be saved in the stack frame.

Additional Information

The virtual machine specification allows specific virtual machine implementations to add information that is not described in the specification to the stack frame, such as highly relevant information, which is entirely dependent on the specific virtual machine implementation. In the actual development, the dynamic connection, the method return address and other additional information is generally classified as a class, called the stack frame information.

Third, the local method stack

The local method stack (Native methods stack) is very similar to the virtual machine stack, but the difference between them is that the virtual machine stack executes Java methods (that is, bytecode) services for the virtual machine, while the local method stack is the Native method service used by the virtual machine. As with virtual machine stacks, the local method stack area throws Stackoverflowerror and OutOfMemoryError exceptions.

Iv. Heaps (heap)

In the C language, programmers can request and free space on the heap through the malloc function, and with the function. So what's it like in Java? The heap in Java is used to store the object itself as well as an array (of course, the array references are stored in the Java stack), and almost all of the object instances are allocated memory here. In Java, programmers do not have to care about the issue of space release, the Java garbage collection mechanism is automatically processed. In addition, the heap is shared by all threads, and there is only one heap in the JVM.

V. Method areas

The method area, like the Java heap, is a memory area shared by each thread that stores the class information, constants, static variables, and compiler-compiled code that have been loaded by the virtual machine. The runtime Constant pool is part of the method area. In addition to descriptive information such as the version, field, method, and interface of the class file, there is also a constant pool (Constant pool Table) that holds the various literal and symbolic references generated during the compilation period, which will be stored in the run-time pool of the class load backward into the method area. In the JVM specification, there is no mandatory requirement for the method area to implement garbage collection. Many people are accustomed to calling the method area "permanent generation" because the hotspot virtual machine implements the method area as a permanent generation, so that the JVM's garbage collector can manage this part of the area as if it were managed by the heap, eliminating the need to specifically design a garbage collection mechanism for this part. Since JDK7, however, the hotspot virtual machine has removed the run-time constant pool from the permanent generation.

Explore Java's virtual machine memory