This article has participated in the “Digitalstar Project” and won a creative gift package to challenge the creative incentive money.

Small knowledge, big challenge! This article is participating in the creation activity of “Essential Tips for Programmers”

During the execution of Java programs, the Memory area managed by the Java VIRTUAL machine is divided into different data areas, each of which has different functions. To understand the JVM, we need to understand it as a whole, how memory regions are divided, and what each represents (this article focuses on several concepts of memory regions).

1. The method of area

A Method Area is an Area of memory shared by threads that stores information about classes loaded by the virtual machine, constants, static variables, and code compiled by the just-in-time compiler. There is also a method area called non-heap, which is supposed to distinguish it from the Java Heap.

In the case of the HotSpot virtual machine, the method area is also called the persistent generation. In essence, the two are not equivalent. The HotSpot virtual machine only extends GC generation collection to the method area, or implements the method area using the persistent generation, so that the HotSpot garbage collector can manage this part of memory as well as the Java heap. There is no need to deal specifically with the memory management of the method area. Other virtual machines do not have the concept of persistent generation. HotSpot has abandoned the concept of persistent generation and adopted Native Memory to implement the method area. Currently, HotSpot in JDK1.7 has removed the string constant pool that was stored in the persistent generation.

In addition to the fact that the method area, like the Java heap, does not require continuous memory and can choose to be fixed size or extensible, it can also choose not to implement garbage collection.

OutOfMemoryError is thrown when the method area cannot meet memory allocation requirements.

2. The Java heap

For most applications, the Java Heap is the largest chunk of the interior managed by the Java virtual machine. The Java heap is an internal area shared by all threads and created at virtual machine startup. The sole purpose of this memory area is to hold object instances, and almost all object instances are allocated memory here. The Java Virtual Machine specification states that all class instances and array objects are allocated in the heap. As technology has evolved, assigning all objects to the heap has become less “absolute.”

The Java Heap is the primary area where the Garbage collector works, and is often referred to as the Garbage Collected Heap. From the point of view of memory collection, the Java heap can be further subdivided, as most collectors now use generational collection algorithms, as described in the historical article heap memory generation. From a memory Allocation perspective, it is possible to allocate Thread Local Allocation Buffers (TLabs) that are private to multiple threads in a Java heap shared by threads. However, no matter how to partition, it has nothing to do with the storage content, no matter which area, the storage is still the object instance, the purpose of further partition is just for better memory recycling or faster memory allocation.

According to the Java Virtual Machine specification, the Java heap can be in a physically discontinuous memory space, as long as it is logically contiguous. Both fixed size and dynamic expansion and contraction can be implemented, but most current virtual machines can be dynamically expanded and contracted (controlled by -xmx and -xMS). An OutOfMemory error is thrown if there is not enough memory in the heap to complete the instance allocation and the heap can no longer be extended.

3. Java VM stack

The Java Virtual Machine Stack is also thread-private and has the same lifetime as a thread. The virtual machine Stack describes the memory model of Java method execution: as each method is executed, a Stack Frame is created to store information about local varitables, operand stacks, dynamic links, method exits, and so on. The process of each method from invocation to completion corresponds to the process of a stack frame in and out of the virtual machine stack.

In the Java Virtual Machine specification, two exceptions are specified for this area:

If the thread request stack is deeper than the virtual machine allows, the virtual machine will throw a StackOverflowError.

If the virtual stack can scale dynamically (and most virtual machines currently do, except that the Java Virtual Machine specification allows a fixed-length virtual stack), if there is not enough memory for scaling or for creating a new thread to create an initial size virtual stack, The Java virtual machine will throw OutOfMemoryError.

4. Local method stack

The function of Native Method Stacks is similar to that of the Java virtual machine stack, but the difference is that the Java virtual machine stack is for the virtual machine to use Java methods, while the Native Method stack is for the virtual machine to use Native methods. It is an important extension to the Java Virtual Machine, which allows Java to call native method libraries directly through JNI (C/C++)

Public native int hashCode () public native int hashcode()

5. Program counter

The Program Counter Register is a small area of memory that is thread private. It can be thought of as a line number directive for the bytecode executed by the current thread. The bytecode interpreter works by changing the value of this counter to select the next bytecode instruction to be executed. Branch, loop, jump, exception handling, thread recovery and other basic functions need to be completed by this counter.

Multithreading in the Java VIRTUAL machine is implemented by switching CPU time slices in turn, and at any given moment, one processor (or core for multi-core processors) will execute instructions in only one thread. Therefore, in order to restore the thread to the correct execution position after switching, each thread needs an independent program counter that does not affect each other and is stored independently.

If the thread is executing a Java method, this counter records the address of the virtual machine bytecode instruction being executed. If you are executing a Native method, this counter is null (Undefined). This memory region is the only one in the Java virtual machine that does not specify any OutofMemoryErrors.

6. Runtime constant pool

The Runtime Contant Pool is part of the method area. The Constant Pool Table is used to store various literals and symbolic references generated at compile time. This part of the Table is stored in the runtime Constant Pool of the method area after the class is loaded.

Runtime constant pool relative to the class files is an important feature of their constant pool is dynamic, the Java language does not require constant cannot be produced at compile time, into the class is not preset method of the contents of the constant pool can enter to the runtime constant pool, during the running of program can also be new constants in the constant pool, For example, the intern() method of the String class.

Because the runtime constant pool is part of the method area, it is also limited by the size of the method area memory, and an OutOfMemory exception is thrown when the constant pool can no longer claim memory.

7. Direct memory

Direct Memory is not part of the run-time data portion of the virtual machine, nor is it defined in the Java Virtual Machine specification, but it is frequently used and can cause OutofMemoryErrors. When garbage is collected, the virtual machine collects garbage from the direct memory, but it cannot tell the garbage collector to collect garbage when it is running out of space, as the new generation and the old generation do. It has to wait until the old generation is full, and then “by the way” cleans up garbage from the direct memory.

NIO was added in JDK1.4, introducing a Channel and Buffer based I/O method that can allocate off-heap memory directly using Native libraries. This is then referenced by a DirectByteBuffer object stored in the Java heap. 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 size, but by the total native memory size and processor addressing space.

The run-time data area is mainly the first five method areas, the Java heap, the Java virtual machine stack, the local method stack, and the program counter. The latter two run-time constant pools can be grouped in the method area. Direct memory is not actually part of the run-time data area.

See In-depth Understanding of Java Virtual Machines, Real Java Virtual Machines

Welcome to the comments section to communicate


In addition to Java virtual machine related series of content and MySQL advanced related more content, such as lock, MVCC, read and write separation, sub-library sub-table, etc., is still in the update, if you want to know more about the content can also leave me a message, welcome to pay attention to hurry more.

I am Mr. Ji, with the output force input and continue to learn, continue to share the series of technical articles, as well as the whole network worth collecting good articles, welcome to pay attention to the public number, do a continuous growth of technical people.