"Go" Understanding JVM Memory Area

Introduction

For C + + programmers, the processing of memory allocations and recoveries has been a daunting problem. Java because of its own automatic memory management mechanism, make management memory become very easy, not prone to memory leaks, overflow problems.

Not Easy does not mean that there is no problem, once a memory leak or overflow occurs, debugging can become very difficult. This requires a deep understanding of the memory area of the virtual machine. It is ultimately possible to determine where in the JVM the memory-related anomalies occur.

Memory Area

When the JVM is running, the class loader (ClassLoader) is required to load the bytecode of the required class, which is loaded and executed by the execution engine , which takes a bit of space to store the data (analogy between CPU and main memory ). This memory space allocation and release process is what we care about, called the Runtime data area .

For CS-related practitioners, an in-depth understanding of the operating system's memory hierarchy, allocation and garbage collection process is beneficial. Similarly, to locate areas where memory problems occur, the runtime data area must be profiled.

Run-time Data area

As shown, the runtime data area includes: program counter (i.e. PC Register),Java Virtual machine stack (VM stack),java heap (heap), method area , a local method stack (Native). Let's take a closer look at each data region .

The JVM is actually a virtual computer , designed to achieve " one-time compilation, execution everywhere ." Therefore, when understanding the runtime data area, it is possible to learn from the operating system memory and register analogy.

Program counter

Each thread in the virtual machine has its own register, which is called the program counter (PC). In order to ensure the independence between threads, the space inside the PC is thread-private .

• thread Private : a zone that can only be accessed by this thread , and other threads do not have access.

Function of the program counter

multithreading in a virtual machine implements concurrent execution by thread-rotation scheduling, allocating time slices to each thread. At the same time, the processor can only execute one thread. When you switch to another thread, if you do not save the execution position of the thread that is not currently executing, the next time the processor executes the thread, it will restart execution. This situation is clearly intolerable.

The purpose of introducing a program counter is to record the execution of a thread and facilitate thread recovery after the next switchover.

Mechanism of program counters

How do I log the execution of a thread? In fact, it is not complicated, just to record the address of the executing virtual machine bytecode instruction . If you are running the Native(local) method, the value of the counter is Undefined.

The program counter is the only area that has no outofmemoryerror exceptions .

Java Virtual Machine Stack

When each Java method executes, it is necessary to allocate memory space to store local variable tables , operand stacks , dynamic links , method exits and other information. Call this part of memory a stack frame . The virtual machine stack is used to store stack frames and is a memory model for Java method execution.

Obviously we need to allocate stack space for each method we execute , so the Java Virtual machine stack is also thread-private .

The role of virtual machine stacks

The virtual machine stack records the process that the Java method executes . When each method starts executing, a stack frame record information is created for it, and the method executes to the completion process, corresponding to the stack frame in the virtual machine stack into the stack of the process .

Local variable table

The local variable table is an important part of the stack frame. The base data type for which the compilation period is defined, the object reference (equivalent to the object address ), and the returnaddress type ( byte code instruction address ).

The local variable table space is allocated during compilation and does not change its size during the execution of the method.

Abnormal

1. Throws a stackoverflowerror exception when the thread requests a stack depth that is greater than the allowable depth.
2. When the length is not enough, the virtual machine stack can be dynamically expanded to request memory. If you cannot request enough memory, throw a outofmemoryerror exception.

Local method Stack

The local method stack is similar to the virtual machine stack, where the virtual machine stack records the execution of the Java method, and the local method stack records the Native method.

The local method stack also throws Stackoverflowerror and outofmemoryerror exceptions.

Java Heap

The Java heap is used to store object instances and allocate memory space for all objects .

All object instances are allocated space on the heap, so the Java heap is a shared area for all threads . The Java heap is also responsible for memory reclamation After the end of the object's life cycle, so the Java heap is often referred to as the GC heap (garbage collected heap).

Memory model

From the perspective of memory recycling, Java heap can be divided into Cenozoic (young Generation) and Laosheng (old Generation). This partitioning is done in order to better reclaim memory (Laosheng memory is prioritized for recycling).

, the new generation can also be divided into Eden Space , fromsurvivor Space , tosurvivor space .

Permanent Generation (Permanent Generation) is used to store static type data and is not related to the garbage collector.

Note : This illustration shows the memory model of the JVM heap , which includes the Java heap Zone and the permanent generation zone . Therefore, the permanent generation does not belong to the Java heap .

Abnormal

The Java heap is also extensible (-XMX and-xms parameters). Throws a outofmemoryerror exception if the memory in the heap cannot be allocated for an object instance and cannot be extended.

Method area

The method area stores data such as class information , constants , static variables , and is a thread-shared area. To differentiate from the Java heap, the method area also has an alias non-heap(not a heap).

Method area ≠ permanent generation

The method area is the permanent generation? Not so.

The hotspot virtual machine chooses to use a permanent generation to implement the method area, thus eliminating the work of writing memory management code for the method area. This is only an implementation, and no other virtual machine (BEA JROCKIT,IBM J9) has the concept of a permanent generation.

Implementing a method area through a permanent generation is prone to memory overflow and may be replaced in the future.

In the virtual machine specification, the implementation of the method area is not explicitly defined , so the method area cannot be equated to a permanent generation.

Abnormal

Throws a outofmemoryerror exception when the method area does not meet the needs of memory allocation.

Run a constant-rate pool

The runtime Constant pool is used to hold various literal and symbolic references generated during the compilation period.

The running constant pool is dynamic, allowing new constants to be placed in the pool during runtime. For example , the Intern () method of the String class .

package intern;public class Main1 {    public static void main(String[] args) { String s0= "I‘m coding"; String s1=new String("I‘m coding"); String s2=new String("I‘m coding"); System.out.println( s0==s1 ); System.out.println( s0==s1.intern()); s2=s2.intern(); System.out.println( s0==s2 ); }}

Output results

falsetruetrue

In this example, S0 is stored directly in the constant pool , and the object instances of S1 and S2 store in the Java heap . = = directly compares the hashcodeof the object, so the first line outputs false. The S1.intern () method returns a reference to S1 in a constant pool, which is not created.
The string stored by S1 is already present in the constant pool, returns the S0 reference directly, and the second line outputs true.
similarly , S2 receives the return value of S2.intern (), the string value is the same as S0, and the third line outputs true.

The run-time-constant pool is part of the method area and is therefore limited by the memory of the method area. Throws a outofmemoryerror exception when the memory cannot be requested.

Summarize

For the memory management of the JVM, the most important thing is to compare it with the OS memory management knowledge and combine practice to learn. The purpose of understanding the JVM memory area is also to be able to accurately locate the area where the memory-related anomalies occur in the project, and deal with them in time.

Later on, we will understand the object creation process and the OutOfMemoryError exception on the basis of this article.

"Go" Understanding JVM Memory Area