Deep understanding of Java virtual Machine (i)-JVM runtime data area __java

Preface

For Java programmers, with the help of the virtual machine automatic memory management mechanism, it is no longer necessary to write the corresponding Delete/free code for each new operation, it is not easy to have memory leak and memory overflow problem, the virtual machine manages memory. However, it is also the Java programmer who gives the power of memory control to the Java virtual machine, and if there is a memory leak and overflow problem, if you don't understand how the Java virtual machine is using memory, then troubleshooting will become an exceptionally difficult task.

This article will conceptually describe the various areas of Java Virtual machine memory, as well as the role of each region, the service object, and the problems that may arise.

This series of articles is my reading in-depth understanding of the second edition of the Java Virtual Machine learning notes, if there are errors in the request to correct. JVM Runtime data region

The Java Virtual machine divides the memory it manages into several different data regions as it executes the Java program. These areas have their own purpose, have been created and destroyed, and some areas are created as the virtual machine process is started, and some areas are created and destroyed by the start and end of the user's thread. According to the Java Virtual Machine specification (Java SE 7), the memory managed by the Java Virtual machine will include several run-time data regions, as shown in the following illustration:

1. Program Counter
Program Counter Register is a small memory space that can be viewed as the line number indicator of the bytecode executed by the current thread. In the conceptual model of virtual machines (only conceptual models, a variety of virtual machines may be implemented in more efficient ways, and the bytecode interpreter works by changing the value of this counter to select the next byte code instruction, branch, loop, jump, exception handling that needs to be executed, Basic functionality, such as thread recovery, relies on this counter for completion.

Because the multithreading of Java virtual Machines is achieved through the way that threads rotate and allocate processor execution time. At any given moment, a processor executes only the instructions in one thread. Therefore, in order to return to the correct execution position after the thread switch, each thread needs to have a separate program counter, the counters between the threads do not affect each other, isolated storage.

If the thread is executing a Java method, the counter records the address of the byte-code instruction being executed, or null if the native method is being executed (undefined).
This memory area is the only area that does not specify any outofmemoryerror in the Java Virtual Machine specification.

The program counter is thread-private, and its lifecycle and line Cheng (born with threads, out of thread).

2. Java Virtual machine stack
The virtual machine stack (Java Virtual Machine stack) describes the memory model that the Java method executes: Each method is executed with the creation of a stack frame (the stack frame) to store information such as local variables table, operand stack, dynamic link, method exit, and so on. Each method corresponds to the process of a stack frame being pushed from the stack to the stack in the virtual machine stack from the process of being invoked until execution completes.

In the Java Virtual Machine specification, two exceptions are specified for this area:
If the thread requests a stack depth greater than the depth allowed by the virtual machine, the Stackoverflowerror exception is thrown;
If the virtual machine stack can be dynamically extended (most Java virtual machines are currently extensible), OutOfMemoryError exceptions will be thrown if the extension cannot be applied to enough memory.

Like program registers, Java Virtual machine stacks are thread-private and have the same lifecycle as threads.

3. Local Method Stack
The local methods stack (Native method stack) and the virtual machine stack play a very similar role, the difference is that the virtual machine stack for the virtual machine to perform Java method services, and the local method stack is for the virtual machine to use the Native method service. In the virtual machine specification, the language, usage, and data structure of the method used in the local method stack are not enforced, so the specific virtual machine is free to implement it.

As with virtual machine stacks, the local method stack area also throws Stackoverflowerror and OutOfMemoryError exceptions.

As with virtual machine stacks, the local method stack is also thread-private.

4, Java heap (Java Heap)
For most applications, the Java heap (Java Heap) is the largest chunk of memory managed by a Java virtual machine. The Java heap is an area of memory that is shared by all threads and is created by the virtual machine. The only purpose of this memory area is to hold the object instance, where almost all object instances and arrays are allocated memory.

The Java heap is the main area of garbage collector management, and is often referred to as a "GC heap" (Garbage collected Heap). From the point of view of memory recycling, because now the collector basically uses the collection algorithm, so the Java heap can also be subdivided into: the Cenozoic and the old era, and can be divided into: 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, they can be either fixed or extensible, although the current mainstream virtual machines are implemented in a scalable way (controlled by-XMS and-XMX). If there is no allocation of memory completion instances in the heap, and the heap can no longer be extended, the OutOfMemoryError exception is thrown.

5. Methods Area
The method region, like the Java heap, is an area of memory shared by individual threads that holds data such as class information, constants, static variables, and JIT-compiled code that have been loaded by the virtual machine. The method area is created when the virtual machine is started.

The Java Virtual Machine specification has a very loose limit on the method area, and optionally does not implement garbage collection, except that it does not require discontinuous memory space and can be fixed size or extensible.

According to the Java Virtual Machine specification, a OutOfMemoryError exception is thrown if the memory space of the method area does not meet the memory allocation requirement.

6, the operation of the constant amount of pool
The runtime (Runtime Constant Pool) is part of the method area. class file In addition to the version of the classes, fields, methods, interfaces, and so on, there is also a constant pool (Constant pool Table) that holds the various literal and symbolic references generated by the compilation period, which are stored in the Run-time pool in which the class loads the LIFO method area.

7, Direct Memory
Direct memory is not part of a virtual Run-time data area, nor is it a memory area defined in the Java Virtual Machine specification (Memory). However, this part of memory is also used frequently and may cause outofmemoryerror anomalies to occur.

A new Input/output class was added to JDK 1.4, introducing an I/O method based on channel (Channel) and buffer (buffer), which can directly allocate heap memory using the native function library, It then operates through a Directbytebuffer object stored in the Java heap as a reference to this block of memory. This can significantly improve performance in some scenarios because it avoids replicating data back and forth in the Java heap and the native heap.

Here we have a general overview of the runtime time zone of the Java Virtual machine, and then continue to introduce more information about the JVM.