Data area parsing and usage in Java Virtual runtime

Java, in executing a java program, divides the memory it manages into several different data regions. These zones have their own use, creation, and destruction time, some are created with the start of the virtual machine, destroyed with the VM's exit, and some correspond to thread one by one, created and destroyed as the thread begins and ends .

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

Program counter (Counter Register)

It is a small amount of memory space, which can be seen as a signal indicator of the bytecode executed by the yourselves thread.

Each JVM thread has its own PC register, each of which is isolated from each other and stored independently, a memory area called "Thread-private" memory

At any one time, a JVM thread executes only one method of code. The method is called the current method of the thread

If the method is a Java method, the PC register holds the address of the bytecode instruction that the JVM is executing

If the method is native, the value of the PC register is undefined.

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

Java VM Stack (Java Virtual machine stack)

As with the PC registers, the Java Virtual machine stack is also thread-private. Each JVM thread has its own Java Virtual machine stack, which is created at the same time as the thread and whose life cycle is the same 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 operand stack, the dynamic link, the method exit, and so on. Each method is called until the completion process corresponds to a stack frame in the virtual machine stack from the stack to the stack.

The JVM stack can be implemented as a fixed size, or it can be dynamically extended based on calculations.

If a fixed-size JVM stack design is used, then the JVM stack capacity of each thread should be selected independently when threads are created. The JVM implementation should provide the means to adjust the initial capacity of the JVM stack, and if you adopt a dynamically expanding and shrinking JVM stack, you should provide the means to adjust the maximum and minimum capacity.

Stackoverflowerror will be thrown if the thread requests a stack depth greater than the depth allowed by the virtual machine;

If the JVM stack can be dynamically scaled, but fails to request enough memory when trying to scale out, throw outofmemoryerror.

Local methods Stack (Native method Stacks)

The local method stack acts similarly to the virtual machine stack, which executes the Java method service for the virtual machine, which is the native method used by the virtual machine.

The virtual machine specification is not mandatory for the language used by methods in the local method stack, usage and data structures, and even some virtual machines (such as hotspot) directly merge the two.

This thing throws the same exception as the virtual machine stack above.

Java heap (Java heaps)

The largest piece of memory managed by a virtual machine, which is also shared by all threads , is created when the virtual machine is started, the meaning of which is to hold an object instance, where almost all object instances and arrays are allocated memory. The objects are managed automatically, which is commonly known as GC (Garbage Collector). That's it, there's a GC carrying it, don't worry about destroying the recycling thing.

The Java heap can be either fixed size or dynamically scaled as demand (-XMS and-XMX), and shrinks automatically when too much space is not required.

The memory used by the Java heap does not need to be guaranteed to be physically contiguous, as long as it is logically contiguous.

The JVM implementation should provide a means for programmers to adjust the initial capacity of the Java heap, and for a heap that can be dynamically scaled and shrunk, it should provide a means of adjusting its maximum and minimum capacity.

If there is no memory in the heap to complete the instance assignment and the heap cannot be expanded, OutOfMemoryError will be thrown.

Method area

The same as the heap is a memory area shared by each thread that stores data such as class information, constants, static variables, and code compiled by the instant compiler that are loaded by the virtual machine. Although this area is described by the virtual machine specification as a logical part of the heap, its name is non-heap and is used to make a difference with the heap.

The method area is created when the virtual machine is started.

The capacity of a method area can be a fixed size, or it can be scaled dynamically as the requirements of the program execute, and shrink automatically when too much space is not required.

The method area can be discontinuous in the actual memory space.

The Java Virtual machine implementation should provide a means for the programmer or end user to adjust the initial capacity of the method area, and for the dynamic expansion and contraction of the method area, it should provide the means to adjust its maximum and minimum capacity.

The OutOfMemoryError is thrown when the method area does not meet the memory allocation requirements.

Here is a small example to illustrate the relationship between heaps, stacks, and method areas.

 Public class Test2 {public    staticvoid main (string[] args) {public        new Test2 ();        //JVM Loading the Test2 class information into the method area, the new Test2 () instance is saved in the heap area, the Test2  reference is saved in the stack }    }  

Run a constant pool (runtime Constant)

It 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 pool Table) that 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.

Direct Memory

Direct memory is not part of the data area when the virtual machine is running, nor is it a memory area defined in the Java VM specification, but this portion of memory is also used frequently and can cause outofmemoryerror anomalies to occur.

In JDK1.4 NiO, Bytebuffer has a method of allocatedirect (int capacity), which is an I/O method based on channel (channels) and buffers (buffer). It can use the native library to directly allocate out-of-heap memory and then manipulate it through a Directbytebuffer object stored in the Java heap as a reference to that 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.

Data area parsing and usage in Java Virtual runtime