JVM Memory various areas of division of Labor Simple introduction

JVM Memory Each area is briefly described:

Program Counter:
A program counter is a small amount of memory space that can be thought of as the line number indicator of the byte code executed by the current thread.

When using multi-threading, in order to return to the correct execution location after thread switching, 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 native method is being executed.

This memory area is the only area in the Java Virtual Machine specification that does not have any outotmemoryerror conditions in the right.

Java Virtual machine stack:
Like the program counter, the Java Virtual machine stack is also thread-private, with the same life cycle as the thread.

Each method creates a stack frame to store local variable tables, operand stacks, dynamic links, method exits, and other information.

Each method from the call until the completion of the process, corresponding to a stack frame in the virtual machine stack into the stack of the process.

A Stackoverflowerror exception is thrown if the thread requests a stack depth that is greater than the virtual machine's allowable depth;

A OutOfMemoryError exception is thrown if the virtual machine stack can be dynamically scaled and cannot request enough memory for expansion.

Local method Stack:
The local method stack is very similar to the virtual machine stack, but 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 stack is the native method service used by the virtual machine.
As with virtual machine stacks, the local method stack area throws Stackoverflowerror and OutOfMemoryError exceptions.

Java heap:
For most applications, the Java heap is the largest chunk of memory.
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 primary area of garbage collector management. From the memory recycling point of view, because the collector is now basically the generation of collection algorithms, so the Java heap can be subdivided into: the new generation and the old age. From the memory allocation point of view,
Allocation buffers In the Java heap that may be private to multiple threads.

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 are usually extensible (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.

The Java Virtual Machine specification has a very loose limit on the method 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 memory recovery target for this area is primarily for the collection of constant pools and for unloading types.
The OutOfMemoryError exception is thrown when the method area does not meet the memory allocation requirements.

To run a constant-rate pool:
Running a constant pool is part of the method area. class file, in addition to the version, field, method, interface, and other descriptive information, there is also a constant pool of information for
Stores the various literal and symbolic references generated during the compilation period, which are stored in the run-time pool of the class load backward into the method area.

Java virtual machines have strict specifications for each part of a class file, and each byte is used to store which data must conform to the requirements of the specification to be recognized, loaded, and executed by the virtual machine, but for the operational
The Java Virtual Machine specification does not require any details.

Another important feature of running a constant pool with respect to a regular pool of class files is its dynamic nature.
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.

JVM Memory various areas of division of Labor Simple introduction