An in-depth analysis of memory management in Java virtual machines

This article brings you an in-depth analysis of memory management in Java virtual machines. It has certain reference value. Friends in need can refer to it. I hope it will be helpful to you.

Runtime memory includes:

1. Method Area

2. Virtual machine stack (VM Stack)

3. Native Method Stack

4. Heap ( Heap)

5. Program counter Register

Program counter

is a comparison The small memory space can be regarded as a line number indicator of the bytecode executed by the current thread. (The bytecode interpreter works by changing the value of this counter to select the bytecode instructions that need to be executed).

Since the multi-threading of the Java virtual machine is implemented by switching threads in turn and allocating processor execution time, at any given moment, a processor will only execute instructions in one thread. Therefore, in order to return to the correct execution position after thread switching, each thread needs to have an independent program counter. The counters between each thread do not affect each other and are stored independently. We call this type of memory area "thread private" of memory.

If the thread is executing a Java method, this counter records the address of the virtual machine bytecode instruction being executed. If it is a native method, the counter value is empty.

Java virtual machine stack

The Java virtual machine stack is also private to the thread, and its life cycle is the same as that of the thread.

The virtual machine stack depicts the memory model of execution: when each method is executed, a stack frame is created to store local variable tables, operand stacks, dynamic links, method exits and other information. The process from the call to the completion of execution of each method corresponds to the process of a stack frame being pushed into the stack and popped out of the stack in the virtual machine.

The stack generally refers to the virtual machine stack, or the local variable table part of the virtual machine stack.

The local variable table stores various basic data types known at compile time, object references and returnAddress types (pointing to the address of a bytecode instruction).

The long and double type data will occupy two local variable spaces (Slots), and the other data types will only occupy one.

The memory space required by the local variable table is allocated at compile time. When entering a method, the amount of local scalar space that the method needs to allocate in the frame is completely determined and will not change during the running of the method. The size of the local variable table.

The virtual machine specification stipulates two exception conditions 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 the expansion When insufficient memory cannot be applied for, an OutOfMemoryError exception will be thrown.

Local method stack

The function of the virtual machine stack is very similar. The local method stack serves the Native methods used by the virtual machine. There are no mandatory rules on the language, usage and data structures in native methods.

Java Heap

For most applications, the Heap is the largest piece of memory managed by the virtual machine.

The heap is a memory area shared by all threads and is created when the virtual machine starts. The only purpose of this memory area is to hold object instances, and almost all object instances are allocated memory here (all object instances and arrays).

The Java heap is the main area managed by the garbage collector. Because modern collectors basically use the striped collection method, the Java heap can also be subdivided into: new generation and old generation.

From the perspective of memory allocation, the thread-shared Java heap may be divided into multiple thread-private allocation buffers (Thread Local Allocation Buffer, TLAB).

Java heap can handle physically discontinuous memory space, as long as it is logically continuous. When implemented, it can be implemented as a fixed size or scalable, but mainstream virtual machines are implemented as scalable (-Xms, -Xmx control).

Method area

Like the Java heap, it is a memory area shared by each thread. It is used to store class information, constants, static variables, and just-in-time compiler compiled information that have been loaded by the virtual machine. code and other data. Although the Java virtual machine describes the method area as a logical part of the heap, it has an alias called Non-Heap to distinguish it from the Java heap.

In addition to not requiring continuous memory like the Java heap and having the option of fixed size or expandability, you can also choose not to implement garbage collection. Garbage collection rarely occurs in this area, but it does not exist permanently like the eternal generation after entering the method area. Memory recycling in this area is mainly aimed at recycling the constant pool and unloading types.

The runtime constant pool

is part of the method area. In addition to the class version, fields, methods, interfaces and other information, the class file contains information. Another piece of information is the Constant Pool Table, which is used for various literals and symbol references generated during compilation. This content will be stored in the runtime constant pool in the method area after the class is loaded.

It is dynamic. Only the contents of the constant pool pre-installed in the Class file can enter the runtime constant pool in the method area. New constants may also be put into the pool during runtime. This feature is often used by developers. is the intern() of the String class.

Creation of objects

When the virtual machine receives a new instruction, it first checks whether the parameters of this instruction can be located in the constant pool. A symbolic reference to a class, and checks whether the class represented by this symbolic reference has been loaded, resolved, and initialized. If not then the corresponding class loading process must be performed first.

Allocate memory for new objects after class loading check. The amount of memory required by an object is fully determined after the class is loaded.

After the memory allocation is completed, the memory space that the virtual machine needs to be allocated is initialized to zero. If TLAB is used, this work can be carried out in advance when TLAB is allocated.

Next, the virtual machine makes necessary settings for the object, such as which class the object is an instance of, how to find the metadata information of the class, the hash code of the object, the GC generation age of the object, and other information. This information is placed in the object header of the object.

After completing the previous step, the task for the virtual machine has been completed, but from the perspective of the Java program, object creation has just begun, and has not yet been executed.

Memory layout of objects

The layout of object memory in memory can be divided into 3 parts: object header, instance data and alignment filling.

The object header of the HotSpot virtual machine includes two parts:

1. Stores the runtime data of the object itself, such as hash, GC generation age, lock status flag, and thread holding lock , biased thread ID, biased timestamp, etc. The data length in 32-bit and 64-bit virtual machines is 32bit and 64bit respectively, which is officially called "Mark word".

2. Type pointer, which is the pointer of the object's class metadata. The virtual machine uses this pointer to determine which class the object is an instance of. If the object is a Java array, there must be a piece of data used to record the length of the array in the object header, because the virtual machine can determine the size of the Java object through the metadata of ordinary Java objects, but it cannot determine it from the metadata of the array. The size of the array.

Object access positioning (P48)

The reference data on the Java program stack can access the object instances in the heap through the following two mainstream methods.

Handle: A piece of memory will be allocated in the Java heap to be used as a handle. The reference stores the handle address of this object. The handle contains the specific properties of the object instance data and type data.

Direct pointer: In the layout of Java heap objects, relevant information on how to prevent access to type data must be considered.

Related recommendations:

Detailed introduction to the memory runtime data area managed by Java virtual machine

Detailed explanation of JAVA with pictures and text Virtual machine related knowledge - JVM memory model

The above is the detailed content of An in-depth analysis of memory management in Java virtual machines. For more information, please follow other related articles on the PHP Chinese website!