JVM notes: Java memory area

1. Overview
For developers engaged in C, C + + program development, in the field of memory management, they both have the highest right to the "emperor" is also engaged in the most basic work of the "working people"----have each object of the "ownership", but also assume the life of each object to the end of the maintenance responsibility.
For Java programmers, with the help of the automatic memory management mechanism of the virtual machine, it is no longer necessary to write the paired Delete/free code for each new operation, which is not prone to memory leaks and memory overflow problems, and it all looks good to manage memory by the virtual machine. However, it is because Java programmers put the power of memory control to the Java Virtual machine, in the event of memory leaks and overflow problems, if you do not understand how the virtual machine uses memory, then troubleshooting will be a difficult task.

2. 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. These zones have their own purpose, as well as the creation and destruction of time, and some regions exist as the virtual machine process starts, and some regions depend on the user thread's start and end to build and destroy. According to the Java Virtual Machine specification (Java SE version 7), the memory managed by the Java Virtual machine will include the following runtime data regions:


2.1 Program Counters

Program Counter Register is a small amount of memory space, which can be seen as the line number indicator of the byte code 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 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.

This memory area is the only area in the Java Virtual Machine specification that does not stipulate any outofmemoryerrory conditions.

2.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 , and each method creates a stack frame to store information such as the local variable table, the operand stack, the dynamic link, the method exit, and so on. each method from the call until the completion of the process, corresponding to a stack frame in the virtual machine into the stack to the process of the stack.

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 If the virtual machine stack can be dynamically extended (most of the current Java virtual machines can be dynamically extended, but the Java Virtual Machine specification also allows a fixed-length virtual machine stack), an OutOfMemoryError exception will be thrown if sufficient memory cannot be requested during the extension .

2.3 Local Method Stack
Local methods Stack (Native method Stacks)The role of the virtual machine stack is very similar, 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 stackthe native method service to use for the virtual machine。 In the virtual machine specification, the method used in the local method stack is not mandated by the voice, usage and data structure, 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 a virtual machine stack, local method Stack areaStackoverflowerror and OutOfMemoryError Exceptions will also be thrown。

2.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 isan area of memory shared by all threads, which is 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(The heap is the runtime data area from which merory for all classes instances and arrays is allocated), but with the development of the JIT compiler and the Escape analysis technology Gradually maturing, stack allocation, scalar substitution optimization technology will cause some subtle changes to occur, all the 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 referred to as the "GC Heap" (garbage collected heap). From the memory recovery point of view, since the collector is now basically using a generational collection algorithm, all Java heap can also be subdivided into: the new generation and the old age, and then a little 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 Local Allocation buffer,tlab). However, regardless of the partition, it is not related to the content, no matter what area, storage is still an object instance, the purpose of further division 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 .

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

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

2.6 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 tabel) that holds the various literal and symbolic references generated during the compilation period . This section is stored in the run-time pool of the class load backward into the method area.

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 .

2.7 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. However, this part of memory is also used frequently, and may cause outofmemoryerror anomalies to occur.

The new Input/output class was added to JDK 1.4, introducing an I/O approach based on channel and buffer, which can be used to directly allocate out-of-heap memory 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.

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 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 region is greater than the physical memory limit (including physical and operating system-level limitations), resulting in dynamic scaling OutOfMemoryError exception .

Reference:

"In-depth understanding of Java virtual machines"

Java Virtual Runtime Data area

JVM notes: Java memory area