JVM memory structure (runtime data area)

Objective The Java program is run through a Java virtual machine. The class bytecode file is loaded into the JVM through the ClassLoader and then executed according to the predetermined rules. The Java Virtual machine divides the memory it manages into several different data regions during the execution of a Java program. These memory areas are uniformly called the run-time data area. The Java runtime Data area can be roughly divided into 5 parts. In particular, it is noted here that the JVM memory partitioning we are talking about is a conceptual model. As shown in the following:

The JVM runtime data area is divided into 5 types:

• Program Counter
• Virtual machine stack (Java stack)
• Heap
• Method Area
• Local Method Stack

Program counter A program counter is a small amount of memory space, which can be seen as the line number indicator of the byte code executed by the current thread. The program counter records the address of the next bytecode instruction that the thread is currently executing. Since Java is multithreaded, each thread needs a separate program counter for switching and recovering between multiple threads, each of which does not affect each other. This type of memory area is known as a "thread-private" memory area. If the thread is executing a Java method, the counter records the virtual machine bytecode instruction address being executed, and if the native method is being executed, the counter value is empty. Since the program counter stores only one byte-code instruction address, there is no outofmemoryerror condition in the memory area.

virtual machine stack

As with program counters, the virtual machine stack is also thread-private, with the same life cycle as the thread. The virtual machine stack describes the memory model that is executed by the Java method, and each method executes at the same time creating a stack frame (for storing local variable tables, operation stacks, dynamic links, method exits, and so on). A stack frame represents a memory model executed by a method, and the stack frame of all the methods currently executing is stored in the virtual machine stack (both executing and awaiting execution). Each method from the call until the completion of the process, corresponding to a stack frame in the virtual machine into the stack to the process of the stack. What we call "local variables stored in stacks" means that local variables in the method are stored in a local variable table representing the stack frame of the method. The execution of the method is to get the data from the local variable table, put it on the operand stack, then perform the operation on the operand stack, then put the result into the local variable table, and finally return the data from the top of the operand stack to the caller of the method. The local variable table holds the various basic data types (Boolean, Byte, char, short, int, float, long, double), object references (reference types, which are not equivalent to the object itself) that are known at compile time. Depending on the virtual machine implementation, it may be a reference pointer to the start address of the object, or it may point to a handle that represents the object or other location associated with the object, and the ReturnAddress type (the address that points to a bytecode directive). A long and double data type of 64 is a length of 2 local variable spaces (slots), and the remaining data types occupy only 1. The memory space required for a local variable table is allocated during compilation, and when a method is entered, the method needs to allocate much of the local variable space in the frame, which is completely deterministic and does not change the size of the local variable table while the method is running. There are two possible exceptions to the virtual machine stack: The stackoverflowerror exception caused by excessive depth of the stack requested by the thread beyond the depth allowed by the virtual machine, and the outofmemoryerror exception caused by the inability of the virtual machine stack to provide sufficient memory.

Heap

The Java heap is the largest piece of memory managed by a Java virtual machine. The Java heap is a piece of memory that is shared by all threads and created when the virtual machine is started. The only purpose of this memory area is to hold object instances: All object instances and arrays are allocated on the heap. but the class object is special, although it is an object, but it is stored in the method area. the Java heap is the primary area of garbage collector (GC) management. Now the collector basically uses the Generational collection algorithm: The new generation and the old age. The garbage collection algorithms used for different "generations" are not the same. The general generation uses the replication algorithm; The old age uses the marker collation algorithm. For different "generations", the general use of different garbage collectors, the new generation of garbage collector and the old garbage collector work together. The Java heap can be a physically discontinuous memory space, as long as it is logically contiguous. The Java heap may throw outofmemoryerror exceptions.

Method area

The method area, like the Java heap, is an area of memory shared by each thread. It is used to store data such as the class information that has been loaded by the virtual machine, constants, static variables, instant compiler compiled code, and so on. after all the bytecode is loaded, the information in the bytecode: class information, method information in the class, constant information, static variables in the class, and so on are all stored in the method area. As its name says: All information about classes and methods is stored in the method area. In addition, if a class is loaded, it generates a Class object (the only object instance that is not generated on the heap) in the method area, which is the external interface for the program to access the information for that class in the method area. With the existence of the object, the reflection is realized. before Java7, the hotspot virtual machine extended the GC generational collection to the method area, using the permanent generation to implement the method area. The memory recovery target for this area is primarily for the collection of constant pools and for unloading types. However, in the subsequent Hotspot virtual machine implementation, the method area is gradually removed from the permanent generation. The run constant pool has been removed from the permanent generation in Java7, and a chunk of the runtime pool is opened in the Java Heap (heap). In Java8, there is no permanent generation, and the method area is placed directly in a local memory area that is not connected to the heap, and this area is called the meta-space. According to the Java Virtual Machine specification, a OutOfMemoryError exception is thrown when the method area does not meet the memory allocation requirements.

Local method Stack

The local method stack is similar to the virtual machine stack, where the difference is that the local method stack is used to execute the local method (the native method), and the virtual machine stack is used to execute a common Java method. In the hotspot virtual machine, the local method stack is put together with the virtual machine stack. The local method stack may throw an exception that is the same as the virtual machine stack.

run a constant-rate pool running a constant pool is part of the method area. class file In addition to the class version, fields, methods, excuses and other descriptive information, there is another information is a constant pool, for the compilation period generated by the various literal and symbolic references, this part will be stored in the method area after the class is loaded into the run-time pool. one of the important characteristics of running a constant pool relative to the class file constants pool is dynamic, and the Java language does not require constants to be generated only at compile time, that is, the contents of the constant pool in the class file are not pre-placed to enter the method area to run the const pool, and new constants may be put in the pool during run time. , this feature is more of a intern () method of the String class. The run-time pool is part of the method area in JDK1.6 and previous versions of the JVM, and the method area in the hotspot virtual machine is placed in a "permanent generation (Permanent Generation)". So the run-time constant pool is also in the permanent generation. However, the JDK1.7 and later versions of the JVM have shifted the run-time pool from the method area, opening a chunk of the Java heap (heap) to hold the run-time pool.

Reference: "In-depth understanding of Java Virtual Machine-JVM advanced features and Best practices" second Edition Zhou Zhiming

JVM memory structure (runtime data area)