JVM (1) JVM memory model

Memory, as an important resource in the system, plays a key role in the stable operation and efficient operation of the system, unlike languages like Java and C, which do not require the developer to allocate memory and reclaim memory, but rather the JVM manages the allocation of object memory and the collection of object memory (also known as garbage Collection, GC). This greatly reduces the difficulty of writing the program for developers, but one side effect is that it is difficult to know what the cause is when the system is running with a memory exception thrown by the JVM (such as OutOfMemoryError), and on the other hand, to write high-performance programs, It is often necessary to use memory to improve performance, so how to properly utilize the memory and make the JVM reasonable memory recovery is necessary, this article will analyze the JVM memory structure and the function and function of each region.

The JVM divides the data into 6 regions at run time to store it, as shown in

(1) Procedure counter (program Counter Register)

The program counter is a small amount of memory space, the main function is to record the current thread execution of the line number of bytecode, in the virtual machine conceptual model, the bytecode interpreter works by changing the value of this counter to select the next need to execute the byte code instruction, branch, loop, jump, exception handling, Basic functions such as thread recovery need to rely on this counter to complete.

Because the multithreading of a Java Virtual machine is implemented in a way that threads rotate and allocate processor execution time, at any given moment, a processor (a kernel for a multicore processor) executes only the instructions in one thread. Therefore, in order to recover the thread after switching 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 Natvie 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) VM stack (Java virtual machine Stacks)

Like the program counter, the Java virtual machine stack is also thread-private, with the same life cycle as the thread. The virtual machine stack describes the memory model that is executed by the Java method: Each time a method is executed, a stack frame is created to store the local variable table, the Operation Stack, the dynamic link, the method exit, and so on. Each method is called until the completion of the process, corresponding to a stack frame in the virtual machine stack from the stack to the process of the stack.

Java memory is often differentiated into heap memory (heap) and stack memory (stack), which is coarser, and the division of Java memory areas is actually far more complex. The popularity of this partitioning method only shows that most programmers are most concerned about the memory area that is most closely related to object memory allocation. The "heap" referred to in this section is described later, and the "stack" refers to the current virtual machine stack, or the local variable table portion of the virtual machine stack.

The local variable table holds the various basic data types, object references (reference types, which are not equivalent to the object itself, depending on the virtual machine implementation, which may be a reference pointer to the starting address of the object. It may also point to a handle representing the object or other location associated with the object) and the ReturnAddress type (the address that points to a bytecode directive). The 64-bit length of long and double data takes up 2 local variable space (slots), and the remaining data types occupy only 1. 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, a fixed-length virtual machine stack is also allowed in the Java Virtual Machine specification, which throws a OutOfMemoryError exception when the extension fails to request enough memory.

(3) Local methods Stack (Native method Stacks)

The role of the local method stack with the virtual machine stack is very similar, but the difference is that the virtual machine stack executes Java methods (that is, bytecode) services for the virtual machine, while the local method stack serves the native method used by the virtual machine. The language, usage, and data structure of the methods used in the local method stack in the virtual machine specification are not mandatory, so the virtual machine can implement it freely. 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) Heaps (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 area of memory is to hold object instances where almost all of the object instances are allocated memory. This is described in the Java Virtual Machine specification as: All object instances and arrays are allocated on the heap, but with the development of the JIT compiler and the gradual maturity of the escape analysis technology, stack allocation, scalar replacement optimization technology will lead to some subtle changes occur, All objects are allocated on the heap and gradually become less "absolute".

The Java heap is the main area of garbage collector management, so it is often called a "GC heap". If from the perspective of memory recycling, because the collector is now basically used in the generation of the collection algorithm, so the Java heap can be subdivided into: the new generation and the old age, and more detailed there is Eden space, from Survivor space, to Survivor space. If viewed from a memory allocation perspective, the thread-shared Java heap may divide multiple thread-private allocation buffers (thread localallocation buffer,tlab). However, regardless of the partitioning, it is not the content of the storage, no matter what area, stored is still an object instance, the purpose of further partitioning is to better reclaim memory, or to allocate memory more quickly. In this chapter, we only discuss the role of memory areas, and details of the allocation and recycling of each of these areas in the Java heap will be discussed in other chapters.

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 are willing to call the method area "permanent generation" (Permanent Generation), which is essentially not equivalent, just because the design team of the hotspot virtual machine chooses to put the GC The generational collection is extended to the method area, or the method area is implemented using a permanent generation. For other virtual machines (such as Bea JRockit, IBM J9, etc.) there is no concept of a permanent generation. Even the hotspot virtual machine itself, according to the official route map information, now also has to abandon the permanent generation and "move" to native Memory to achieve the planning of the method area.

The Java Virtual Machine specification has a very loose limit on this 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 of this area is mainly for the recovery of constant pool and unloading of type, in general, the recovery "score" in this area is more difficult to be satisfied, especially the type of unloading, the condition is very harsh, but the recovery of this part of area is really necessary. In the Sun's bug list, several serious bugs have occurred because of a memory leak caused by a low-release hotspot virtual machine that has not been fully reclaimed for this zone.

According to the Java Virtual Machine specification, a OutOfMemoryError exception is thrown when the method area does not meet the memory allocation requirements.

(6) Running a constant pool (runtime Constant)

Running a constant pool is part of the method area. In addition to information such as the version of the class, fields, methods, interfaces, and so on, the class file contains a constant pool (Constant pooltable), which holds the various literal and symbolic references generated during the compilation period, which are stored in the run-time pool of the method area after the class is loaded.

Java virtual machines have strict specifications for each part of a class file (which naturally includes Chang), and each byte is used to store which data must conform to the requirements of the specification, so that it is recognized, loaded, and executed by the virtual machine. However, for running a constant pool, the Java virtual machine specification does not require any details, and the virtual machines implemented by different providers can implement this memory area as they want. 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.

Another important feature of running a constant pool relative to a class file's const pool is dynamic, and the Java language does not require constants to be generated only at compile time, that is, the contents of the constant pool in the class file are not pre-placed to enter the method area to run the const pool, and new constants may be put into the pool during run time. , this feature is the Intern () method of the string class that is used by developers more.

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.

(7) Direct Memory

Direct memory is not part of the data area when the virtual machine is running, nor is the memory area defined in the Java VM specification, but this part of memory is also used frequently and can cause outofmemoryerror anomalies, so let's put it together here.

A new NiO class was introduced in JDK 1.4, which introduces a channel-based I/O mode, which can be used to allocate out-of-heap memory directly using the native library, and then through a directbytebuffer stored in the Java heap object to act as a reference to this block of memory. This can significantly improve performance in some scenarios because it avoids copying data back and forth in the Java heap and 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 will certainly be subject to the size of the native total memory (including RAM and swap or paging files) and the processor addressing space. When the server administrator configures the virtual machine parameters, the parameters such as-xmx are usually 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.

Summarized as

Reference documents:
[1] http://www.cnblogs.com/dingyingsi/p/3760447.html

[2] Http://developer.51cto.com/art/201303/387175.htm

JVM (1) JVM memory model