Deep understanding of JVM virtual machines: (i) Java Runtime data regions

Overview

The JVM is the essence of the Java language, because its Java language implements cross-platform operation, as well as automatic memory management mechanism, and so on, this article will conceptually introduce the various areas of JVM memory, explain the role of the region.

JVM Runtime Data area model

Java virtual machines in the course of executing a Java program will divide the memory it manages into several different data regions that have their own purpose, as well as the creation and destruction times, and the memory that the Java Virtual Machine manages will include the following number of runtime areas

Program counter

A program counter is a relatively small amount of memory space, which can be seen as the line number indicator of the bytecode that the current thread executes. In the virtual machine conceptual model, the bytecode interpreter works by changing the value of this counter to select the next byte-code instruction to execute, and the basic functions such as branching, looping, jumping, exception handling, thread recovery, and so on, need to rely on this counter to complete.

Because the multithreading of a Java Virtual machine is implemented in a way that threads take turns switching and allocating processor execution time, at any given time, a processor executes only the instructions in one thread. Therefore, in order for the thread to switch back to the correct execution location, each thread needs to have a separate program counter, the counters between the threads do not affect each other, isolated storage, we call this type of memory area is "thread-private" memory.

If the thread is executing a Java method, this counter records the address of the executing virtual machine bytecode instruction, or null if the native method is being executed. This memory area is the only area in the Java Virtual Machine specification that does not stipulate any outofmemoryerror conditions .

Java Virtual Machine stack

Like the program counter, the Java Virtual machine stack is also thread-private , with the same life cycle as the thread. Virtual machine stack Describes the Java method execution of the memory model, each method executes at the same time will create a stack frame for storing local variables table, operand stack, dynamic link, method exit and other information, each method from the call until the completion of the process, corresponding to a stack frame in the virtual machine stack into the stack of the process.

Java memory is often divided into heap memory and stack memory, this distribution is rough, Java memory Area partition implementation is far more complex than this. This kind of classification is more popular only to show that most programmers are most concerned about, the memory area with the most closely related to object memory is the two blocks. The "heap" referred to later will refer to the "stack" that is now being said of the virtual machine stack, or the virtual machine stack in the local variable table part.

The local variable table holds the various basic data types (Boolean, Byte, short, char, int, float, long, double), object references (reference types), and returnaddress types that are known at compile time.

Where 64-bit long and double-type data takes up two local variable space, the rest of the data types occupy only one. The memory space required for a local variable table is allocated during the compiler, and when entering a method, the amount of local variable space that the method needs to allocate in the stack frame is fully deterministic and does not change the size of the local variable table while the method is running.

In the Java Virtual Machine specification, there are two exceptions to this area: if the thread requests a stack depth greater than the virtual machine allows, the STACKOVERFLOWERROR exception will be thrown, and if the virtual machine can be dynamically extended, if the extension cannot request enough memory, The OutOfMemoryError exception is thrown .

Local method Stack

The role of the local method stack and the virtual machine stack is very similar, but the difference between them is that the virtual machine stack bit virtual machine Executes the Java method service, and the local method stack is the native method service used by the virtual machine. The methods used in the heap local method stack in the virtual machine specification are not mandatory for the use of the method and the data structure, so the specific virtual machine can implement it freely.

Some virtual machines (such as hotspots) directly merge the local method stack with the virtual machine stack, and, as with the virtual machine stack, the local method stack throws Stackoverflowerror and OutOfMemoryError exceptions

Java heap

For most applications, 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 store objects smoothly, where almost all of the object power is allocated. The description in this Java Virtual Machine specification is that all object instances and data are allocated on the heap, but as the development of the JIT compiler and the escape analysis technique matures, the allocation on the stack, the scalar substitution optimization technology will cause some subtle changes to occur, all the objects are allocated in how much also gradually become not so " Absolutely. "

The Java heap is the main area of garbage collector management, so it is often a "gc heap". From the memory recovery point of view, since the current collector basically uses the Generational collection algorithm, so the Java heap can also be subdivided into: the new generation and the old age; the finer points can be divided into Eden space, from Survivor space, to survivor space, etc. From the memory allocation point of view, the thread-shared Java heap may be divided into a number of thread-private allocation buffers, but regardless of the partition, regardless of the content of the storage, no matter what area, the store is still an object instance, the purpose of further partitioning is to better reclaim memory, or faster allocation of memory. An OutOfMemoryError exception is thrown when there is no memory in the heap to complete the instance assignment, and the heap cannot be extended.

Method area

The method area, like the Java heap, is an area of memory shared by each thread that stores data such as class information, constants, static variables, and code compiled by the immediate 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", which should be distinguished from the Java heap.

Many people are willing to refer to the method area as a permanent generation, which is essentially not equivalent, just because the design team of the hotspot virtual machine chooses to extend the GC collection to the method area, or use the permanent generation to implement the method area. This allows the hotspot garbage collector to manage this part of the memory just like the Java heap, eliminating the effort to write memory management code specifically for the method area. For other virtual machines, there is no concept of a permanent generation. In principle, how to implement a method area is a virtual machine implementation detail that is not constrained by the virtual machine specification.

Garbage collection behavior is less frequent in this area; the memory recovery target for this area is primarily for the recovery of constant pools and the unloading of types. In general, the recovery of the area "performance" is more difficult to satisfy, especially the type of unloading, the conditions are quite harsh.
The Java Virtual Machine specification has a very loose limit on the method area, except that the Java heap does not require contiguous memory and can choose a fixed size or extensible exception, and optionally does not implement garbage collection, which is relatively rare in this area, But it is not the data that enters the method area as "permanent" exists as the name of the permanent generation. The memory recovery target for this area is primarily for the collection of constant pools and unloading of heap types, which is, in general, really necessary for this area to be recycled. The OutOfMemoryError exception is thrown when the method area does not meet the memory allocation requirements.

Run a constant pool

Running a constant pool is part of the method area. class file In addition to the class version, fields, methods, interfaces and other descriptive information, there is also a constant pool of information for the compiler to generate the individual literal and symbolic references, the Department of content will be loaded in the class load into the method area of the run constant pool storage.

Java Virtual machine Heap class file each part of the format has strict rules, each byte is used to store which data must conform to the requirements of the specification to be recognized, loaded and executed by the virtual machine, but for running the constant pool, the Java Virtual Machine specification every need to do any detail requirements, Virtual machines implemented by different vendors can implement this memory area according to their own requirements. However, in general, in addition to maintaining the symbolic references described in the class file, the translated direct references are also stored in the run constant pool.

Another important feature of running a constant pool relative to a class file constant pool is dynamic, and the Java language does not require constants to be generated only at compile time, that is, the contents of a constant pool that is not pre-placed in a class file can enter the method area to run a frequent pool. It is also possible to put the constant of the heart into the pool during the run, which is much more than the Intern () method of the string class used by the developer.

A OutOfMemoryError exception is thrown when a constant pool can no longer request memory.

Direct Memory

Direct Memory is not part of the data area when the virtual machine is running, nor is it an area of memory defined in the Java VM specification. But this part of the memory is also used frequently, and may also cause memory overflow exceptions.

The NIO class was added to the JDK1.4, which introduced a channel-based I/O approach that could use the native library to directly allocate out-of-heap memory and then manipulate it through a Directbytebuffer object stored in the Java heap as a reference to that memory. This can significantly improve performance in some scenarios because it avoids copying data back and forth in the Java heap and the native heap.

Obviously, the allocation of native direct memory is not limited by the size of the Java heap, but since it is memory, it is bound to be limited by the total memory size of the machine and the processor addressing space.

If direct memory is omitted, the sum of each memory area is greater than the physical memory limit (including physical and operating system-level limitations), which causes OutOfMemoryError to occur dynamically.

This article is for reference from: "In-depth understanding of Java virtual machines"

Deep understanding of JVM virtual machines: (i) Java Runtime data regions