Deep understanding of JVM (1)-Java memory region, jvm-java

Deep understanding of JVM (1)-Java memory region, jvm-java

1. Data Area During Running

During Java program execution, the Java Virtual Machine divides the memory it manages into several different data regions.

The memory managed by the Java Virtual Machine will include the following runtime data areas:

1. Program counters

1) The Program counter (Program CounterRegister) is a small memory space. Its function can be seen as the row number indicator of the bytecode executed by the current thread. in the concept model of a virtual machine, the bytecode interpreter is used to select the bytecode commands, branches, loops, jumps, and exception handling to scare a hop by changing the value of this counter, this counter is required for basic functions such as thread recovery.

2) Java Virtual Machine multithreading is implemented by switching threads in turn and allocating processor execution time. At any specific time, a single processor (for a multi-core processor, It is a kernel) only the commands in one thread are executed. therefore, in order for the thread to be switched back to the correct execution position, each thread requires an independent program counter. The counters between each thread do not affect each other and are stored independently, we call this type of memory area "thread private memory ".

2) If the thread is executing a Java method, this counter records the address of the Virtual Machine bytecode instruction being executed; if the Native method is being executed, the counter value is null (Undefined ). this memory region is the only region in which the Java Virtual Machine specification does not specify any OutOfMemoryError conditions.

2. Java Virtual Machine Stack

1) Like program counters, Java Virtual Machine stack (Java Virtual Machine Stacks) is also proprietary to threads, and its lifecycle is the same as that of threads. the VM Stack describes the Memory Model of Java method execution. Each method creates a Stack Frame to store local variable tables, Operation stacks, and dynamic links, method exit and other information. each method is called until the execution is completed, which corresponds to the process from the inbound stack to the outbound stack of a stack frame in the VM stack.

2) The local variable table stores various basic data types (Boolean, byte, char, short, int, float, long, double) known during the compilation period, and object references (reference type, it is not the same as the object itself. According to different virtual machine implementations, it may be a reference pointer pointing to the starting address of the object, or it may point to a handle representing the object or other locations related to the object) and returnAddress (pointing to the address of a bytecode instruction ).

3) data of the 64-bit long and double types occupies two local variable spaces (slots), and the remaining data types only occupy one, the memory space required by the local variable table is allocated during compilation. when you enter a method, the size of the local variable space allocated in the frame is completely determined, the table size of local variables is not changed during method running.

• If the stack depth requested by the thread is greater than the depth allowed by the virtual machine, an StackOverflowError exception is thrown;
• If the Virtual Machine stack can be dynamically expanded (currently most Java virtual machines can be dynamically expanded, but the Java Virtual Machine specification also allows a fixed-length Virtual Machine stack ), an OutOfMemoryEoor exception is thrown when sufficient memory cannot be applied during expansion.

3. Local method Stack

1) The Native Method Stacks plays a very similar role with the Virtual Machine stack. The difference is that the virtual machine stack performs Java (also known as bytecode) services for virtual machines, the local method stack uses Native METHOD services for virtual machines. the language, usage and data structure of the method used in the local method stack in the virtual machine specification are not mandatory. Therefore, the specific virtual machine can freely implement it. even some virtual machines (such as Sun HotSpot virtual machines) directly combine the local method stack and Virtual Machine stack into one. like the Virtual Machine stack, StackOverflowError and OutOfMemoryError are thrown in the local method stack area.

4. JavaHeap

　　　　1) for most applications, Java Heap is the largest memory managed by Java virtual machine. java heap is a memory area shared by all threads. It is created when the VM is started. the only purpose of this memory area is to store object instances, where almost all object instances are allocated memory. this point is described in the Java Virtual Machine specification: All object instances and arrays must be allocated on the stack, but with the development of JIT compiler and the gradual maturity of escape analysis technology, stack allocation, the scalar replacement optimization technology will lead to some subtle changes. All objects are allocated to the stack and gradually become less "absolute.

2) Java Heap is the main area of the Garbage collector management, so it is often called "GC Heap" (Garbage Collected Heap, currently, the collectors basically use generation-based collection algorithms. Therefore, Java heap can be subdivided into the new generation and the old generation. There is an Eden space in detail, From the original vor space, to allocate vor space. from the perspective of memory Allocation, the Java pairs shared by threads may be divided into private Allocation buffers (Thread Local Allocation Buffer, TLAB) for multiple threads ). however, no matter how it is divided, it is irrelevant to the storage content. No matter which region it is stored, it is still an object instance. The purpose of further division is to better recycle the memory, or allocate memory faster.

3) According to the Java Virtual Machine specification, the Java stack can be physically discontinuous memory space, as long as the logic is continuous, just like our disk space. during implementation, it can be either fixed or extensible. However, the mainstream virtual machines are all implemented according to the Extensible (through-Xms to initialize the heap, -Xmx maximum heap space). If the heap does not have memory for instance allocation and the heap cannot be expanded, an OutOfMemoryError error will be thrown.

5. Method Area

　　　　1) The Method Area, like the Java heap, is the memory Area shared by various threads. It is used to store class information, constants, and static variables loaded by virtual machines, real-time compiler compiled code and other data. although Java Virtual Machine Standards describe the method area as a logical part of the Heap, it has an alias called Non-Heap, which should be distinguished from Java Heap.

6. runtime constant pool

1) The Runtime Constant Pool is part of the method area. in addition to descriptions such as the version, field, method, and interface of the Class, the Class file also contains the Constant Pool Table ), it is used to store various types of literal and symbolic references generated during the compilation period. This part of content will be stored in the runtime pool of the method area after the class is loaded.

2) Another important feature of the runtime constant pool relative to the Class file constant pool is that it is dynamic. Java does not require constants to be generated only during compilation, that is to say, it is not the content of the constant pool preset into the Class file that can enter the runtime constant pool in the method area. During the runtime, new constants may also be placed in the wing, the intern () method of the String class is widely used by developers.

7. Direct Memory

1) Direct Memory (Direct Memory) is not part of the data zone during virtual machine running hours, nor is it the Memory area defined in Java Virtual Machine specifications. However, this part of Memory is also frequently used, it may also cause an OutOfMemoryError exception. obviously, the distribution of direct memory on the local machine is not limited by the size of the Java heap. However, since the memory is used, it will certainly be limited by the total memory size of the local machine and the addressing space of the processor. when configuring virtual machine parameters, the server administrator usually ignores the Direct Memory according to the actual memory-Xmx and other parameter information, the sum of each memory area is greater than the physical memory limit (including physical and operating system-level restrictions), resulting in an OutOfMemoryError error during dynamic expansion.