JVM Runtime data Area details

JVM Introduction:

A Java Virtual machine (Java virtualmachine abbreviation JVM) is an abstract computer that runs all Java programs and is the operating environment of the Java language.

After all, the JVM is a virtual machine, is a specification, although in line with von Neumann computer design concept, but he is not a physical computer, so his composition is not what memory, controller, arithmetic, input. The JVM is placed in a real operating system to behave more like an application or a process, his composition can be understood as the JVM this process has what functional modules, and these functional modules can be seen as the operation of the JVM operating principle.

JVM Components:

A JVM can be roughly divided into four components:

Class Loader (ClassLoader)

Runtime data area (runtime)

Excution engine (execution engines)

Native Interface (local interface) This article mainly analyzes the JVM runtime data regions.

Run-time data region:

The Java Virtual machine divides the memory it manages into several different data regions during the execution of a Java program. According to the Java Virtual Machine specification (Javase version 7)

, the memory managed by the Java Virtual machine will include the following runtime data regions:

1. Program counter

The program counter, also called the PC Register, is a small memory space that can be seen as the line number indicator of the byte code executed by the current thread, pointing to the address of the next instruction. The bytecode interpreter works by changing the value of this counter to select the next byte-code instruction to execute.

The multithreading of a Java Virtual machine is implemented in a way that threads take turns switching and allocating processor execution time, and at any given moment, a processor executes only the instructions in one thread. 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 (Undefined) 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.

2. Java Virtual machine stack

Like the program counter, the Java Virtual machine stack (Java Stacks) is also thread-private, with the same life cycle as the thread. The virtual machine stack describes the memory model that the Java method executes: Each method creates a stack frame to store information such as local variable tables, operand stacks, dynamic links, method exits, and so on. 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.

It is common for people to differentiate Java memory into heap memory and stack memory, which is somewhat coarser. The "stack" referred to here is the current virtual machine stack, or the local variable table part of the virtual machine stack.

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. It may be a reference pointer to the start address of the object, or it may point to a handle representing the object or other location associated with the object, and the ReturnAddress type, which points to the address of a bytecode directive.

The amount of memory space required for a local variable table is allocated during compilation, and when entering a method, the method needs to allocate much of the local variable space in the 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 stack can be dynamically extended (most of the current Java virtual machines can be dynamically extended, However, the Java Virtual Machine specification also allows a fixed-length virtual machine stack, which throws a OutOfMemoryError exception if the extension cannot request enough memory.

3. Local Method Stack

The local method stack (Native methods stack) is very similar to the virtual machine stack, but the difference between them is that the virtual machine stack executes Java methods (that is, bytecode) services for the virtual machine, while the local method stack is the Native method service used by the virtual machine. Even some virtual machines, such as sun hotspot virtual machines, combine the local method stack and the virtual machine stack directly. As with virtual machine stacks, the local method stack area throws Stackoverflowerror and OutOfMemoryError exceptions. 4. Java Heap

For most applications, the Java heap (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 area of memory is to hold object instances where almost all of the object instances are allocated memory.

The Java heap is the main area of garbage collector management, so it is often called a "gc heap" (garbagecollected heap). From the memory recovery point of view, because the collector is now basically using a generational collection algorithm, so the Java heap can also be subdivided into: the new generation and the old age, the more detailed there is Eden space, from Survivor space, to survivor space. From the memory allocation point of view, the thread-shared Java heap may divide multiple thread-private allocation buffers (thread localallocation buffer,tlab). However, regardless of the partition, it is not related to the content, no matter what area, the storage is still an object instance, the purpose of further partitioning is to better reclaim memory, or to allocate memory more quickly.

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, just like our disk space. When implemented, it can be either fixed or extensible, although the current mainstream virtual machines are implemented in a scalable way (via-XMX and-xms control). A OutOfMemoryError exception will be thrown if there is no memory in the heap to complete the instance assignment and the heap can no longer be expanded.

5. 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 (Not a heap), which should be distinguished from the Java heap.

For developers who are accustomed to developing and deploying programs on a hotspot virtual machine, many people prefer to call the method area the "permanent generation" (Permanent Generation), which is not inherently equivalent. Just because the design team of the hotspot virtual machine chooses to extend the GC collection to the method area, or to use a permanent generation to implement the method area, so that the hotspot garbage collector can manage this part of the memory like the Java heap, eliminating the effort to write memory management code specifically for the method area.

The Java Virtual Machine specification has a very loose limit on the method area, and you can choose not to implement garbage collection, except that you do not need contiguous memory and can choose a fixed size or extensible, as with the Java heap. The garbage collection behavior is relatively rare in this area, but it is not the data that enters the method area as "permanent" as the name of the permanent generation. The memory recovery target for this area is primarily for the collection of constant pools and for unloading types. In the currently released JDK 1.7 hotspot, the string constant pool that was originally placed in a permanent generation has been moved out.

5.1 Running a constant-rate pool

The runtime Constant pool is part of the method area. In addition to descriptive information such as the version, field, method, and interface of the class file, there is also a constant pool (Constant pool Table) that holds the various literal and symbolic references generated during the compilation period, which will be stored in the run-time pool of the class load backward into the method area.

Java virtual machines have strict specifications for each part of the class file (which naturally includes Chang), and 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 a constant pool, the Java Virtual Machine specification does not require any details. Virtual machines implemented by different providers can implement this memory area according to their own needs. However, in general, in addition to saving the symbolic references described in the class file, the translated direct references are also stored in the run-time-constant pool.
Since the run-time-constant pool is part of the method area, it is naturally constrained by the memory of the method area, which throws a OutOfMemoryError exception when the constant pool is no longer able to request memory.

6. 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, but also may cause outofmemoryerror abnormal appearance, so we put here to explain together.

The

New Input/output class, introduced in JDK 1.4, introduces a channel-and buffer-based I/O approach that can be used to allocate out-of-heap memory directly using the native function library. It then operates as a reference to this memory through a Directbytebuffer object stored in the Java heap. This can significantly improve performance in some scenarios because it avoids copying data back and forth in the Java heap and native heap.
The allocation of native direct memory is not limited by the size of the Java heap, but since it is memory, it will certainly be limited by the size of the native total memory (including RAM and swap or paging files) and processor addressing space. When the server administrator configures the virtual machine parameters, the parameter information such as-XMX is set according to the actual memory, but the
Direct memory is often ignored, so that the sum of each memory area is greater than the physical memory limit (including physical and operating system-level limitations). This causes a OutOfMemoryError exception to occur when dynamic scaling occurs.