JVM Automatic Memory Management-Java memory area and memory overflow exceptions, jvm-java

JVM Automatic Memory Management-Java memory area and memory overflow exceptions, jvm-java

Abstract: JVM memory division, which may cause memory overflow exceptions.

1. JVMRuntime memory Zone

The JVM divides the memory managed by the Java program into the following areas:

 

1.1Program counters

The program counter is a small memory space. In the Java Virtual Machine specification, it is the only memory area with no specified OutOfMemoryError.

The program counter can be seen as the row number indicator of the bytecode executed by the current thread. When the bytecode interpreter is working, the counter value is changed to select the next bytecode instruction to be executed, the basic functions such as branch, loop, jump, exception handling, and thread recovery all depend on counters.

Each thread has an independent program counter. If the thread executes a Java method, the value of the counter record is the bytecode address of the virtual machine being executed; if the Native method is executed, the counter value is blank (Undefined ).

 

Java 1.2Virtual Machine Stack

Java Virtual Machine stack is also the "stack" that we often say (in fact, this statement is not rigorous enough <^ _ ^>). It is private to the thread and has the same lifecycle as the thread.

The VM stack describes the Memory Model of Java method execution. Each method creates a stack frame for storing information such as the local variable stack, operand stack, dynamic link, and method exit. The process from calling to execution completion of each method corresponds to the process of putting a stack frame in the VM stack into the stack.

The local variable table stores eight types of basic data and object references known during the compilation period, the reference pointer pointing to the starting address of the object or representing the handle of the object or other locations related to the object) and returnAddress type (pointing to the address of a bytecode instruction ).

Java virtual machine specification specifies two exceptions for this region:

• StackOverflowError

This exception is thrown if the stack depth requested by the thread is greater than the depth allowed by the virtual machine;

• OutOfMemoryError

This exception is thrown if the VM stack can be dynamically expanded but cannot be applied for enough memory during expansion;

 

1.3Local method Stack

Similar to the Virtual Machine stack, But it executes the Native method service.

 

Java 1.4Heap

"GC" heap, created when the VM is started and shared by all threads. In the standardized description of Java virtual machine, all object instances and arrays must be allocated on the stack (with the development of JIT compiler and the gradual maturity of escape technology, the allocation of all objects on the stack is not so absolute ).

If the remaining memory in the heap is insufficient for instance allocation and cannot be expanded, an OutOfMemoryError is thrown.

 

1.5Method Area

"Non-Heap" stores class information, constants, static variables, and Code Compiled by the compiler.

According to Java Virtual Machine specifications, when the method area cannot meet the memory allocation requirements, an OutOfMemoryError will be thrown.

 

1.6Runtime constant pool

A part of the method area. When the class is loaded and enters the method area, it stores various literal and symbolic references generated during the compilation period.

During running, new constants may also be placed in the pool, such as the commonly used intern () method of String.

When the memory allocation requirement cannot be met, an OutOfMemoryError is thrown.

 

1.7Direct Memory

This part is not part of the VM runtime data zone, nor is it the memory area defined in the Java VM specification. However, it is also frequently used and may throw an OutOfMemoryError.

The Direct Memory is mainly used by NIO (the class added by JDK1.4) and is referenced by the DirectByteBuffer object stored in the Java heap. In some cases, the performance can be significantly improved, avoiding Data Replication back and forth between the Java heap and Native heap.

 

2. HotSpotVirtual Machine objects

The process of allocating, layout, and accessing common objects in the Java heap is discussed.

2.1Object Creation

• When the VM encounters a new command, it first checks whether the parameter of this command can locate a Class symbol reference in the constant pool, check whether the class referenced by this symbol has been loaded, parsed, and initialized. If not, execute the corresponding class loading process first;
• After the class loading check is passed, the VM allocates memory for the new object:

• Pointer collision

If the memory in the Java heap is absolutely regular, all used and idle memory are put on one side, and a pointer is placed in the middle as the indicator of the demarcation point, then, the allocated memory only moves the pointer to the idle space to a distance equal to the object size;

• Idle list

The memory in the Java heap is not regular. In this case, the virtual machine must maintain a list to record which memory blocks are available. When allocated, a large enough space is found on the list and allocated to the object instance, and update the records in the list.

In the case of concurrency, memory allocation on the heap may lead to synchronization issues of memory allocation. There are two solutions: one is synchronous memory (CAS) allocation; the other is to use TLAB (local thread allocation buffer), that is, a small block of memory is allocated in advance for each thread in the Java heap. In this way, the thread needs to allocate memory on its own TLAB to avoid synchronization overhead. However, synchronization is still required when TLAB is fully allocated and re-allocated. After the memory allocation is complete, the virtual machine needs to initialize the allocated memory space to a zero value (excluding the object header ).

• The Virtual Machine will perform necessary settings on the object, such as the instance of the class of the object, how to find the metadata information of the class, the hashCode of the object, and the GC age division. The information is stored in the object header.

Finally, execute the init method to generate truly available objects.

 

2.2Object Memory Layout

In a hot spot virtual machine, the layout of objects stored in the memory can be divided into three areas: object header, instance data, and alignment filling.

• Object Header

• Mark Word

Stores data in the running hours of an object, such as hashCode, GC generational age, lock status mark, lock held by the thread, biased thread ID, and time stamp;

• Type pointer

A pointer to its class metadata. The VM uses this pointer to determine the class instance of the object.

• Instance data

Various types of field content defined in the program code, including inherited from the parent class.

• Alignment Filling

It does not necessarily exist. It only acts as a placeholder to meet the requirements of the HotSpot VM Automatic Memory Management System for the object's starting address must be an integer multiple of 8 bytes.

 

2.3Object Access and positioning

Java programs operate on specific objects on the stack through reference data on the stack. Mainstream access methods:

* Handle

In the Java heap, a memory block is used as the handle pool. The reference stores the handle address of the object, and the handle contains the specific address information of the object instance data and type data.

Advantage: when the object moves, you only need to change the pointer of the handle, and the corresponding reference does not need to be changed;

 

• Direct pointer

Reference stores the object address and can access data through reference.

Advantage: the access speed is fast, and the overhead of one pointer location is less than that of the handle method. HotSpot VM uses this method.

References

Deep understanding of Java Virtual Machine: JVM advanced features and best practices (version 2nd)