Java Virtual Machines in the process of executing Java programs will be managed by dividing the memory into several different data regions, which have their own purpose, have their own creation time and destruction time, and some areas with the virtual machine process started to exist, Some areas are built or destroyed depending on the start and end of the user thread. Java Virtual Machine Second Edition, virtual machine managed memory contains the following runtime data regions
- Program counter: Program Counter Register is a small memory space that can be interpreted as the line number indicator of the bytecode that is being executed by the current thread. The multithreading of a Java Virtual machine is implemented by thread switching and allocating processor execution time, so that at any one time, a processor executes only one thread of instruction, and in order for the thread to switch back to the correct execution location, each thread needs to have a separate program counter, and the counters between the threads do not affect each other. Isolated storage. So the program counter is thread-private . The memory area occupied by the program counter is the only area in the Java Virtual Machine specification that does not stipulate any outofmemoryerror conditions.
- Java Virtual machine stack: 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 to store the local variable table, the Operation 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 local variable table holds the basic data types, object references, returnaddress types that are known during compilation (64-bit long and double types of data take up 2 local variable space, and the remaining data types occupy only 1). The memory space required for the local variable table has been allocated during compilation and does not change the size of the local variable table while the method is running. If the thread requests a stack depth greater than the virtual machine allows, the Stackoverflowerror exception is thrown , and if the virtual machine stack can be dynamically extended, The OutOfMemoryError exception is thrown when the extension fails to request enough memory.
- Local method Stack: The local method Stack (Native methods Stacks) is similar to the virtual machine stack, with the main difference being that the virtual machine stack executes the Java bytecode service for the virtual machine, and the local method stack is the Native method service used for the virtual machine. The local method stack area throws Stackoverfowerror and OutOfMemoryError exceptions for the same reason as the Java Virtual machine stack.
- Java heap: The Java heap (Java heap) is the largest area of memory managed by a virtual machine. It is an area of memory that is shared by all threads and created when the virtual machine is started . The only purpose of the Java heap is to hold object instances (the Java Virtual Machine Specification description is: All object instances and arrays are allocated on the heap). However, with the development of JIT compiler and the gradual maturation of escape analysis Technology, stack allocation, scalar replacement optimization technology will lead to some subtle changes, all objects are allocated on the heap is not so absolute . Java heap is the main area of garbage collector management, known as the "GC Heap", the heap is divided into a very detailed area of memory space, but in any case, is not related to the storage content, regardless of which memory space area, stored is still an object instance, The purpose of further partitioning is to better reclaim memory or to allocate memory more quickly. The Java heap can be in a physically discontinuous memory space, as long as it is logically contiguous. The heap controls the maximum and minimum heap space allocations through-XMX and-XMS, and throws a OutOfMemoryError exception if there is not enough memory in the heap to complete the instance assignment and the heap can no longer be expanded.
- Method Area: The method area, like the 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 describes the method area as a logical part of the heap, but in fact the method area has an alias called "Non-heap". The method area does not require contiguous memory, you can choose a fixed size or extension, and you can choose not to implement garbage collection. The memory reclamation target of the method area is primarily for the collection of constant pools and the unloading of types. the Java Virtual Machine specification specifies that the OUTOFMEMORYERROR exception will be thrown when the method area does not meet the memory allocation requirements.
- Run a constant pool: 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 pooltable), a constant pool for the compilation period generated by a variety of literal and symbolic references, which are stored in the method area after the class is loaded into the run constant pool. The Java Virtual machine has strict formatting for each part of the class file, but there is no requirement for the Java Virtual Machine specification to run the constant pool. Running a constant pool has an important feature compared to the class file constants pool, and the run-time pool is dynamic. This means that the content of the constant pool in the class file is not pre-placed to enter the method area to run the frequent pool, and the new constants may be put into the pool during the run, such as String.intern (). The run-time pool is limited by the memory of the method area and 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 an area of memory defined in the Java VM specification, but this partial memory can cause outofmemoryerror anomalies to occur. For example, NIO (new I/O) allocates out-of-heap memory directly using the native library, and it is clear that the allocation of the computer's direct memory is not limited by the Java heap size, but since it is memory, it is always limited (the size of the total memory of the machine, the limit of processor addressing space). Sometimes the JVM optimizer is equipped with parameters, often ignoring the direct memory, so that the sum of each memory area is greater than the physical memory limit, resulting in the dynamic expansion of the OutOfMemoryError exception.
Java memory area-deep Java Virtual machine read-after summary