For the first time JVM-1 memory area

For the first time JVM-1 memory area

JVM memory model

Five memory models

Program counter

Used to store the address of the unit where the next instruction is located

Belongs to thread private area

It is a register in a computer processor that contains the address of the instruction currently being executed. When each instruction is fetched, the program counter address is incremented by one, and the program counter points to the next instruction in the sequence. When the computer is restarted or reset, the program counter is reset to zero

Features

• Also known as the instruction counter, when the program starts, it must be its starting address
• When the execution performs a non-sequential jump, the subsequent instructions are obtained from the instruction register,
• The program counter has the structure of registering information and counting functions
• This block of memory is the only area in the virtual machine where there is no OutOfMemoryError

Java virtual machine stack

Like the program counter, the Java virtual machine stack is also thread-private , and its life cycle is the same as that of the thread. It describes the memory model of Java method execution. The data for each method call is passed through the stack.

When each method is executed, a stack frame is created to store the local variable table, operation stack, dynamic link, method exit and other information. The process in which each method is called corresponds to the process of a stack frame from pushing to popping in the virtual machine stack.

The Java virtual machine stack contains the following parts:

Local variable table (see https://www.cnblogs.com/kesan/p/11368934.html for actual operation of local variable table)

Operand stack

Dynamic link

Method export

There are two exceptions in the Java virtual machine stack: StackOverFlowError and OutOfMemoryError.

• StackOverFlowError: If the memory size of the Java virtual machine stack does not allow dynamic expansion, when the depth of the thread request stack exceeds the maximum depth of the current Java virtual machine stack, a StackOverFlowError exception will be thrown.
• OutOfMemoryError: If the memory size of the Java virtual machine stack allows dynamic expansion, and the memory is used up when the thread requests the stack, and cannot be dynamically expanded anymore, an OutOfMemoryError exception is thrown.

The Java virtual machine stack is also thread-private, and each thread has its own Java virtual machine stack, which is created as the thread is created, and dies as the thread dies.

The Java stack can be compared to the stack in the analog data structure. The main content saved in the Java stack is the stack frame. For each function call, a corresponding stack frame is pushed onto the Java stack. After each function call is over, a stack frame is pop up.

Native method stack

The local method stack is very similar to the role played by the virtual machine stack. The difference is that the virtual machine stack executes Java method (that is, bytecode) services, while the local method stack serves the native methods used by the virtual machine. To call c or c++, we can open the jdk installation directory and we can see that there are also many files written in c, which may be the c code called by the native method.

Possible exceptions
StackOverflowError Stack overflow
OutOfMemory memory overflow

heap

The largest piece of memory managed by the Java virtual machine. The Java heap is a memory area shared by all threads and is created when the virtual machine starts. The sole purpose of this memory area is to store object instances. Almost all object instances and arrays are allocated memory here.

All threads share, store object instances, and are also the main area of ​​GC management, usually called GC heap

Current mainstream virtual machines such as HotPot can be implemented by extension (by setting -Xmx and -Xms). If there is no memory in the heap to complete the instance allocation, and the heap cannot be expanded, an OOM error (OutOfMemoryError) will be reported.

(For garbage collection, please see the next decomposition)

Method area

The method area, like the Java heap, is a memory area shared by each thread . It is used to store data such as class information, constants, static variables, and code compiled by the JIT compiler that have been loaded by the virtual machine. Although the Java virtual machine specification describes the method area as a logical part of the heap, it has an alias called Non-Heap (non-heap) , which should be used to distinguish it from the Java heap.

In JDK 1.8, the method area (HotSpot's permanent generation) was completely removed (JDK1.7 has already started), and replaced by metaspace, which uses direct memory.

Special area

Constant pool

Use final modified member variables, once the value is given, it cannot be changed

Static constant pool

Constant pool in .class file

The constant pool mainly stores two constants: literals and symbolic references . The literal quantity is closer to the concept of constants at the Java language level, such as text strings, constant values ​​declared as final, and so on. The symbolic reference belongs to the concept of compilation principle. Including the following three types of constants:

• Fully qualified names of classes and interfaces
• Field name and descriptor
• Method name and descriptor

The benefits of the constant pool: The constant pool is to avoid frequent creation and destruction of objects and affect system performance, which realizes the sharing of objects.

For example: string constant pool, put all string literals into a constant pool during compilation.

1. Save memory space: All the same string constants in the constant pool are merged, occupying only one space.
2. Save running time: faster than equals() when comparing strings. For two reference variables, you can judge whether the actual values ​​are equal only by judging whether the references are equal.

Static constant pool for storing a variety of compiler generated literal references and symbols , this part will be stored in the method area after loading class runtime constant pool of. The symbol reference actually refers to the string in the constant pool , but the symbol reference does not directly store the string, but the index of the stored string in the constant pool .

When the Class file is loaded, the java virtual machine will transfer the contents of the static constant pool to the runtime constant pool. Part of the symbol references in the static constant pool will be converted to direct references , such as static methods of the class. Or private methods, instance construction methods, parent class methods. This is because these methods cannot be overridden by other versions, so symbol references can be converted into direct references when loading, and some other methods are used in this method. The symbol reference is converted to a direct reference only when it is first called.

Runtime constant pool

Runtime Constant Pool is part of the method area . For the runtime constant pool, the Java virtual machine specification does not make any detailed requirements. Virtual machines implemented by different providers can implement this memory area according to their own needs. However, generally speaking, in addition to saving the symbolic references described in the Class file, the translated direct references are also stored in the runtime constant pool.

There is a more important feature of the runtime constant pool: dynamic . Java requires that the content of the constant pool during compilation can enter the runtime constant pool, and the constants generated at runtime can also be placed in the pool. Commonly used is the intern() method of the String class.

Since the runtime constant pool is part of the method area, it will naturally be limited by the method area memory. When the constant pool can no longer apply for memory, an OutOfMemoryError will be thrown .

String constant pool

The string constant pool exists in the runtime constant pool (the runtime constant pool existed before JDK7, and it has been transferred to the heap in JDK7).

The existence of string constant pool enables JVM to improve performance and reduce memory overhead.

1. Whenever we use a literal (String s="1";) to create a string constant, the JVM will first check the string constant pool, if the string already exists in the constant pool, then assign the address of the string object Give reference s (reference s in the Java stack. If the string does not exist in the constant pool, it will instantiate the string and put it in the constant pool, and assign the address of the string object to the reference s (reference s In the Java stack).
2. Whenever we use the keyword new (String s=new String("1");) to create a string constant, the JVM will first check the string constant pool. If the string already exists in the constant pool, it is no longer in the character string The string constant pool creates the string object, and the direct heap creates a copy of the object, and then assigns the address of the object in the heap to the reference s. If the string does not exist in the constant pool, the string will be instantiated and its Put it in the constant pool, then create a copy of the object in the heap, and then assign the address of the object in the heap to the reference s.

The relationship between the three constant pools

When JVM executes a certain class, it must be loaded, connected, and initialized, and the connection includes three stages of verification, preparation, and analysis.

The static constant pool is used to store various literals and symbol references generated during compilation, and when the class is loaded into memory, jvm will store the contents of the static constant pool in the runtime constant pool. The string constant pool stores reference values, which exist in the runtime constant pool.

Advantages of using constant pool

1. Save memory space, all the same string constants in the constant pool are merged, occupying only one space
2. Save running time

Changes in the three constant pools in different JDK versions

1.6

• The static constant pool is in the Class file.

• The runtime constant pool is in the Perm Gen area (that is, the method area). (The so-called method area is a logical part of the Java heap. In order to distinguish it from the Java heap, it is also called non-heap (Non-Heap). Then the Perm Gen (permanent generation) area is also regarded as a part of the method area. Kind of realization.)

• The string constant pool is in the runtime constant pool.

1.7

• The static constant pool is in the Class file.
• The runtime constant pool is still in the Perm Gen area (that is, the method area). In the JDK7 version, the transfer of permanent generation has already begun. For example, symbol references (Symbols) are transferred to the native heap; interned strings are transferred to the java heap; class statics are transferred to the java heap . But the runtime constant pool still exists, but a lot of content is transferred, and it only contains these transferred references. Some methods or codes for transferring constant pools during test runtimes circulating on the Internet are actually tests on the transfer of string constant pools.
• The string constant pool is allocated to the main part of the Java heap (known as the young and old generations). That is, the string constant pool is separated from the runtime constant pool.

1.8

• The static constant pool is in the Class file.
• The JVM has moved the runtime constant pool from the method area, and has opened up an area in the Java Heap to store the runtime constant pool. At the same time, the permanent generation was removed and replaced with metaspace. Metaspace is not in the virtual machine, but uses local memory. Therefore, by default, the size of the metaspace is limited only by local memory. It is mainly used to store some metadata.
• The string constant pool exists in the Java heap.

Direct memory

• Off-heap memory, metadata to go, stack space, direct memory, jvm as a C++ program, mmap data, etc.
• Direct memory is controlled by jvm parameter -XX:MaxDirectMemorySize
• It is not affected by GC itself, but there are objects that refer to this memory in the heap, which is indirectly affected by GC, typically java code system.g
• It is the space defined by the jvm, which is at the same level as the heap and metadata

PermGen (permanent generation)

• Java 8 removes hotspot vm from the permanent generation and migrates its original data to Java Heap or Metaspace

Reasons for removal
1. Because Permanent Generation memory is often insufficient or memory leaks occur, java.lang.OutOfMemoryError: PermGen (very common in Java Web development) is triggered.
2. Removing Permanent Generation can promote the integration of HotSpot JVM and JRockit VM. Because JRockit has no permanent generation.

Metaspace

Starting from jdk1.8, use metaspace to replace permanent generation.
Permanent generation: This area will store class-related data including class definitions, structures, fields, methods (data and code), and constants. It can be adjusted by (the following two are non-heap configuration parameters) -XX:PermSize and -XX:MaxPermSize. If Perm Gen space is used up, it will cause java.lang.OutOfMemoryError: PermGenspace exception.
Store data

The method area stores the information of each class:
(1) ClassLoader reference (ClassLoader)
(2) Runtime constant pool: contains all constants, field references, method references, attributes
(3) Field data: each field Name, type (such as the full path name of the class, type or interface), modifiers (such as public, abstract, final), attributes
(4) method data: the name of each method, return type, parameter type (in order), Modifiers and attributes The
method area stores the information of each class:
(1) ClassLoader reference (ClassLoader)
(2) Runtime constant pool: contains all constants, field references, method references, and attributes
(3) Field data: The name and type of each field (such as the full path name of the class, type or interface), modifiers (such as public, abstract, final), attributes
(4) method data: each method name, return type, parameter type ( In order), modifiers, attributes
(5) Method code: bytecode of each method, operand stack size, local variable size, local variable table, exception table and the start position, end position, code of each exception handling Handle the offset address in the program counter, the constant pool index of the caught exception class