Writing in the front

The runtime data area for the JVM described in this article is based on the HotSpot VIRTUAL machine.

An overview of the

During the execution of a Java program, the JVM divides the memory it manages into several different data regions. Each of these areas has its own purpose and time of creation and destruction. Some areas exist with the start of the virtual machine process, while others are created and destroyed depending on the start and end of the user thread.

HotSpot runtime data area

The run-time data area prior to HotSpot 1.8 is different, mainly because the method area has been moved into the meta-space.

Thread private area

PROGRAM COUNTER REGISTER

A program counter is a small area that stores the address of the bytecode being executed by the current thread. (In this case, there are actually two “current” : the current thread being executed by the CPU, and the current thread being executed by the bytecode instructions.) The bytecode interpreter works by changing the value of the program counter to select the next bytecode to execute. For single core, multiple threads are implemented by thread switching in turn, only one thread at any moment will be able to get the CPU’s executive power and the thread of execution of the bytecode instruction, therefore, in order to make the thread to restore to the executing after the location of the bytecode, each thread needs to have its own the program counter.

Note: Program counters are the only area where the Java Virtual Machine specification does not specify any OutofMemoryErrors. Because it is thread-private, its life cycle is created with the creation of the thread and dies with the end of the thread.

VM STACK

The virtual stack is also thread-private, so it has the same lifetime as the program counter. The virtual machine stack describes the in-memory model of Java method execution.

Each method creates a stack frame (one method corresponds to one stack frame, which is the basic unit of the stack) to store information about local variables, operand stacks, dynamic links, method exits, and so on. Each method is executed by thread from start to finish, corresponding to a stack frame in the virtual machine stack (push) and out of the stack (pop) process. Local variables to store the compiled knowable various basic data types (byte, short, int, long, float, double, char, Boolean), object reference (reference types, it is stored: object handle to address or refer to represent object).

The Java Virtual Machine specification specifies two possible exceptions to the virtual machine stack: StackOverflowError and OutOfMemoryError.

StackOverflowError: A StackOverflowError is raised when the thread request stack depth exceeds the maximum depth of the current Java virtual machine stack.

OutOfMemoryError: An OutOfMemoryError is thrown if a thread fails to allocate sufficient memory for the vm stack during dynamic stack expansion.

NATIVE METHOD STACK

The local method stack is similar to the virtual machine stack. The virtual machine stack is the memory space created by executing Java methods, while the local method stack is the memory space created by executing Native methods.

Like the virtual stack, the local method stack throws StackOverflowError and OutOfMemoryError exceptions, and the throw conditions are similar.

An area of memory shared between threads

HEAP (HEAP)

The heap is an area shared by all threads that holds objects and arrays.

It is described IN the Java Virtual Machine specification that all object instances and arrays are allocated on the heap, but with the development of JIT (Just-in-time) compilers and the maturation of escape analysis techniques, not all objects are allocated only on the heap. For example: As escape analysis techniques mature, objects that can be reclaimed in real time may also be allocated on the virtual stack.

Since the generation collection algorithm is now used, the heap can be subdivided into new generation and old generation from the point of view of memory collection. The new generation can be divided into Eden space, From Survivor space and To Survivor space.

Note: in 1.8, the implementation of the method area has been completely changed from the previous permanent generation to meta-space.

METHOD AREA

The method area, like the heap, is an area shared by all threads and is used to store information about classes that have been loaded by the virtual machine, constants (final-modified), static variables, JIT compiled code, and so on. Although the Java Virtual Machine specification describes the method area as a logical part of the Heap, it has an alias called non-heap, which is supposed to distinguish it from the Java Heap.

The permanent generation is the method region, right?

In the early days, many developers preferred to call the method area “permanent generation.” In fact, the name “persistent generation” comes from the fact that the HotSpot team is not going to redesign the garbage collection algorithm for the method area. In order to keep the generation collection algorithm in the heap in the method area, the method is called “persistent generation” in accordance with the heap name. There is no “permanent generation” for JRocket and J9, so when HotSpot 1.8 merged with JRocket, the concept of “permanent generation” was completely abandoned (in fact, since 1.7) in place of metaclase, which uses direct memory.

Method area garbage collection is very difficult!!

Because the Java virtual Machine specification is very loose on the method area, and can not even implement garbage collection, in general, this area of memory collection is not satisfactory, especially type unload, the conditions are very harsh, but because modern frameworks rely heavily on THE JIT technology, resulting in method area occupation ratio gradually increased. So it’s very important to recycle the method area. According to the Java Virtual Machine specification, OutOfMemoryError is thrown when the method area cannot meet memory allocation requirements.

RUNTIME CONSTANT POOL

JDK1.7 and later JVMS have moved the runtime constant pool out of the method area, creating an area in the Java Heap to house the runtime constant pool.

This area was originally part of the methods area prior to 1.7, and one of the pieces of information in the Class file is the constant pool (or a constant table, in which the Class file stores data).

The run-time constant pool stores a complex set of literals and symbolic references.

literal

Literals include final constants, such as final int x = 1, static variables, and other literals.

Symbolic reference

Symbolic references mainly include fully qualified names of classes, field names and descriptors, method names and descriptors, including many symbols, such as: () can also be regarded as symbolic references.

Literal and symbolic references are stored in the runtime constant pool in the method area after the Class is loaded (the ClassLoader loads the Class bytecode file). However, in addition to saving symbolic references described in the Class file, translated direct references are also stored in the runtime constant pool. The Java language does not require constants to be generated in the constant pool of a Class file at compile time, nor can only constants from the constant pool of a Class file enter the runtime constant pool. It is possible to generate new constants to store in the runtime constant pool during a thread’s execution of a method, such as the String intern() method. An OutOfMemoryError is raised when the runtime constant pool fails to allocate memory.

DIRECT MEMORY

Direct memory is not part of the JVM runtime data area, nor is it defined in the VIRTUAL machine specification, but it is frequently used. It may also cause an OutOfMemoryError.

The NIO(New Input/Output) class added in JDK1.4 introduces an I/O mode based on Channel and Buffer, which can directly allocate out-of-heap memory using Native function library. It then operates through a DirectByteBuffer object stored in the Java heap as a reference to this memory. This can significantly improve performance in some scenarios because it avoids copying data back and forth between the Java heap and Native heap.

Native direct memory allocation is not limited by the Java heap, but since it is memory, it is limited by the total native memory size and processor addressing space.

conclusion

Java Virtual machine contains a lot of content, this article is only the Java virtual machine running data area of the Java memory management module to do a brief analysis, about the rest of the memory management module will continue to update, please look forward to!

reference

  • In-depth Understanding of Java Virtual Machine · Advanced JVM features and Best Practices (edition 2)
  • Mp.weixin.qq.com/s/EZ4DDTC0C…
  • Blog.csdn.net/qq_41212104…
  • www.cnblogs.com/chanshuyi/p…
  • Snailclimb. Gitee. IO/javaguide / #…

The public,

If you want to follow my updated articles and the dry goods I share in real time, you can follow my official account we are all guinea pigs