Java Virtual Machine (ii): JVM memory model

Are all Java developers likely to encounter such confusion? How much space should I set for heap memory? What area of the runtime data does the OutOfMemoryError exception involve? How to solve it? In fact, if you frequently solve server performance problems, then these problems will become very common, understand the JVM memory is also for the server performance problems can quickly understand the memory area of the problem, in order to quickly solve the production failure.

Take a look at the diagram, which clearly illustrates the layout of the JVM's memory structure.

The memory structure of Java:

There are three main chunks of the JVM memory structure: Heap memory, method area, and stack. Heap memory is the largest piece of the JVM consists of the young generation and the old age, and the young generation of memory is divided into three parts, Eden Space, from Survivor space, to Survivor space, by default, the young generation according to the proportion of 8:1:1 distribution;

The method area stores class information, constants, static variables and other data, is a thread-shared area, for the Java heap, the method area has an alias Non-heap (non-heap), the stack is divided into Java Virtual machine stack and the local method stack is mainly used for the execution of methods.

Learn how to control the memory size of each area by using a graph

Control parameters
-XMS sets the minimum space size for the heap.

-XMX sets the maximum space size for the heap.

-xx:newsize set the Cenozoic minimum space size.

-xx:maxnewsize set the maximum space size for the Cenozoic.

-xx:permsize sets the minimum space size for a permanent generation.

-xx:maxpermsize sets the maximum space size for a permanent generation.

-XSS sets the stack size for each thread.

The parameters of the old age are not set directly, but can be controlled indirectly by setting the heap space size and two parameters of the Cenozoic space size.

Old age space size = heap space Size-young generation large space size

See the relationship between the JVM and the system calls again from a higher dimension

The method area and the memory area that are shared by all threads, while the Java stack, the local method stack, and the programmer's counter are areas of memory that are run as thread-private.

Here we describe in detail the role of each region

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". 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.

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.

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 not inherently equivalent. Just because the design team of the hotspot virtual machine chooses to extend the GC collection to the method area, or use a permanent generation to implement 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.

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

Program counter (Counter Register)

Program Counter Register is a small memory space that acts as a line number indicator of the bytecode that is being executed by the current thread. In the virtual machine concept model (only the conceptual model, the various virtual machines may be implemented in some more efficient way), the bytecode interpreter works by changing the value of this counter to select the next need to execute the bytecode 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.

JVM Stack (JVM Stacks)

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 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.

The Local variables 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 and are implemented according to different virtual machines). 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 (the address of 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.

Local methods Stack (Native method Stacks)

The local methods Stack (Native method Stacks) is very similar to the virtual machine stack, except 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.

Reference:

http://ifeve.com/under-the-hood-runtime-data-areas-javas-memory-model/

In-depth understanding of Java Virtual machines: JVM advanced Features and best practices _ Zhou Zhiming. HD Scan version. pdf

This article is reproduced from

The pure smile of the original

Original address: http://www.cnblogs.com/ityouknow/p/5610232.html

Java Virtual Machine (ii): JVM memory model