Deep understanding of the JVM (i)--java memory area

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

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

1. Program counter

1) Program Counterregister is a small memory space that acts as a line number indicator of the bytecode that is being executed by the current thread. In the virtual machine concept model, the bytecode interpreter works by changing the value of this counter to select the byte code instructions that need to be executed, branching, looping, jumping, exception handling, thread recovery and other basic functions need to rely on this counter to complete.

2) 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 kind of memory area is "thread private memory."

2) If the thread is executing a Java method, this counter logs the address of the executing virtual machine bytecode instruction; If the native method is being executed, the counter value is empty (Undefined). This memory area is the only area in the Java Virtual Machine specification that does not stipulate any outofmemoryerror conditions.

2. Java Virtual machine stack

1) As with 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 is executed by the Java method: When each method is executed, a stack frame is created at the same time to store the local variable table, Operation Stack, dynamic link, method exit and other information. Each method is called until the completion of the process, corresponding to a stack frame in the virtual machine stack from the stack to the process of the stack.

2) The local variable table holds the various basic data types (Boolean, Byte, char, short, int, float, long, double) that are known at compile time, object references (reference types, which are not equivalent to the object itself, are implemented according to different virtual machines , he may be a reference pointer to the start address of the object, or it may point to a handle representing the object or other location associated with the object, and the ReturnAddress type (the address of a bytecode directive).

3) where 64-bit lengths of long and double data occupy 2 local variable space (slots), the rest of the data types occupy only one, the memory space required for the local variable table is allocated during compilation, and when a method is entered, This method requires that the local variable space allocated in the frame is fully deterministic and does not change the size of the local variable table while the method is running.

• A Stackoverflowerror exception is thrown if the thread requests a stack depth that is greater than the virtual machine's allowable depth;
• If the virtual machine stack can be dynamically extended (most of the current Java Virtual machine can be dynamically extended, but the Java Virtual Machine specification also allows a fixed-length virtual machine stack), when the extension cannot request enough memory when the Outofmemoryeoor exception is thrown.

3. Local Method Stack

1) The role of the local method stack (Native methods Stacks) is very similar to the virtual machine stack, except that the virtual machine stack executes Java methods (that is, bytecode) services for the virtual machine, while the local method stack uses the Native method service for the virtual machine. The language used in the virtual machine specification for methods in the local method stack is not mandatory for use and data structures, so a specific virtual machine is free to implement it. Even some virtual machines, such as Sun HotSpot virtual machines, combine the local method stack and the virtual machine stack directly. As with virtual machine stacks, the local method stack area throws Stackoverflowerror and OutOfMemoryError exceptions.

4.Java Heap

　　　　1) For most applications, the Java heap (Java heap) is the largest piece of memory managed by a Java virtual machine. 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. This is described in the Java Virtual Machine specification: All object instances and arrays are allocated on the heap, but with the development of the JIT compiler and escape analysis technology gradually mature, stack allocation, scalar replacement optimization technology will lead to some subtle changes occur, All objects are allocated on the heap and gradually become less "absolute".

2) Java heap is the main area of garbage collector management, so it is often called "gc Heap" (garbage collected heap), if from the perspective of memory recycling, because the collector is now basically the generation of the collection algorithm used, so the Java heap can be subdivided into: The new generation and the old age; In detail there is Eden space, from Survivor space, to survivor space and so on. If viewed from a memory allocation perspective, a thread-shared Java pair might divide multiple thread-private allocation buffers (thread Local Allocation buffer, Tlab). However, in any case, regardless of the content, no matter what area, the storage is still an object instance, the purpose of further partitioning is to better reclaim memory, or faster allocation of memory.

3) 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. In the implementation, can be either fixed-size or extensible, but the current mainstream virtual machines are implemented according to the extensible (through-XMS initialization heap,-xmx the maximum heap space), if there is no memory in the heap to complete the allocation of instances, and the heap can not be expanded, A OutOfMemoryError exception will be thrown.

5. Method area

　　　　1) 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 immediately compiled code 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, which should be distinguished from the Java heap.

6. Run a constant-rate pool

1) The runtime Constant pool is part of the method area. class file In addition to the class version, fields, methods, interfaces, and other descriptive information, there is a constant pool (Constant pool Table), used to hold the compilation period generated by the various literal and symbolic references, which will be stored in the method area after the class load in the run constant pool.

2) Another important feature of running a constant pool relative to a class file is the dynamic, and the Java language does not require constants to be generated only at compile time, that is, the content of the constant pool in the class file is not pre-placed to enter the method area to run the frequent pool. It is also possible to put new constants into the wings during the run, which is more than the Intern () method of the string class used by developers.

7. Direct Memory

1) 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. 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 and the processor addressing space. When a server administrator configures a virtual machine parameter, it is generally based on parameter information such as actual memory-xmx, but often ignores direct memory, making the sum of each memory region larger than the physical memory limit (including physical and operating system-level limitations). This causes a OutOfMemoryError exception to occur when dynamic scaling occurs.

Deep understanding of the JVM (i)--java memory area