According to the "Java Virtual Machine Specification (2nd Edition)", the memory managed by the Java virtual machine includes several runtime data areas as shown below:
1.
Program Counter The Program Counter (Program Counter Register) is a small memory space, and its function can be regarded as the line number indicator of the bytecode executed by the current thread. In the conceptual model of the virtual machine (only the conceptual model, various virtual machines may be implemented in some more efficient ways), the bytecode interpreter selects the next item to be executed by changing the value of this counter when working. Bytecode instructions, branch, loop, jump, exception handling, thread recovery and other basic functions all need to rely on this counter to complete. Since the multithreading of the Java virtual machine is achieved by switching threads in turn and allocating processor execution time, at any given moment, a processor (for a multi-core processor, a core) will only execute one thread instructions in . Therefore, in order to restore the correct execution position after thread switching, each thread needs to have 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". " of the memory. If the thread is executing a Java method, this counter records the address of the virtual machine bytecode instruction being executed; if the thread is executing a Natvie method, the counter value is empty (Undefined). This memory region is the only region that does not specify any OutOfMemoryError conditions in the Java Virtual Machine Specification.
2. The Java virtual machine stack
, like the program counter, is also private to the thread, and its life cycle is the same as that of the thread. The virtual machine stack describes the memory model of Java method execution: 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. The process of each method being called until the execution is completed corresponds to the process of a stack frame from being pushed to the stack in the virtual machine stack.
Some people often divide Java memory into heap memory (Heap) and stack memory (Stack). This division method is relatively rough, and the division of Java memory area is actually far more complicated than this. The popularity of this division can only show that most programmers are most concerned about the memory areas most closely related to object memory allocation. The "heap" referred to will be described later, and the "stack" referred to is the virtual machine stack, or the local variable table part of the virtual machine stack.
The local variable table stores various basic data types (boolean, byte, char, short, int, float, long, double) and object references (reference types) known at compile time. It is not equivalent to the object itself. According to different virtual machine implementation, it may be a reference pointer to the starting address of the object, or it may point to a handle representing the object or other location related to the object) and returnAddress type (pointing to the address of a bytecode instruction).
The 64-bit long and double types of data occupy 2 local variable spaces (Slots), and the rest of the data types only occupy 1. The memory space required by the local variable table is allocated during compilation. When entering a method, how much local variable space the method needs to allocate in the frame is completely determined, and the size of the local variable table will not be changed during the method execution. In the Java virtual machine specification, two exception conditions are specified for this area: if the stack depth requested by the thread is greater than the depth allowed by the virtual machine, a StackOverflowError exception will be thrown; if the virtual machine stack can be dynamically expanded (most current Java Virtual machines can be dynamically expanded, but the Java virtual machine specification also allows a fixed-length virtual machine stack), and an OutOfMemoryError exception will be thrown when sufficient memory cannot be applied for during expansion.
3. Local method stack
The role played by the native method stack (Native Method Stacks) and the virtual machine stack is very similar, the difference is that the virtual machine stack serves for the virtual machine to execute Java methods (that is, bytecode), while the native method stack is for the virtual machine. Native method service used by the virtual machine. The virtual machine specification does not mandate the language, usage and data structure of the methods in the native method stack, so a specific virtual machine can freely implement it. Even some virtual machines (such as the Sun HotSpot virtual machine) directly combine the native method stack and the virtual machine stack into one. Like the virtual machine stack, the native method stack area also throws StackOverflowError and OutOfMemoryError exceptions.
4. Java heap
For most applications, the Java heap (Java Heap) is the largest piece of memory managed by the Java virtual machine. The Java heap is a memory area shared by all threads, created when the virtual machine starts. The only purpose of this memory area is to store object instances, and almost all object instances allocate memory here. This point is described in the Java Virtual Machine Specification: all object instances and arrays must be allocated on the heap, but with the development of JIT compilers and the gradual maturity of escape analysis technology, stack allocation and scalar replacement optimization technology will Will cause some subtle changes to occur, all objects are allocated on the heap and gradually become less "absolute".
The Java heap is the main area managed by the garbage collector, so it is often called the "GC heap" (Garbage Collected Heap, fortunately it is not translated into "garbage heap" in China). From the perspective of memory recovery, since the collectors basically adopt the generational collection algorithm, the Java heap can also be subdivided into: the new generation and the old generation; more detailed are Eden space, From Survivor space, To Survivor space, etc. From the perspective of memory allocation, the Java heap shared by threads may be divided into multiple thread-private allocation buffers (Thread Local Allocation Buffer, TLAB). However, no matter how it is divided, it has nothing to do with the storage content. No matter which area, the object instance is still stored. The purpose of further division is to reclaim memory better or allocate memory faster. In this chapter, we only discuss the role of memory regions. The details of allocation and reclamation of the above-mentioned regions in the Java heap will be the subject of the next chapter.
According to the Java Virtual Machine Specification, the Java heap can be in a physically discontinuous memory space, as long as it is logically continuous, just like our disk space. When implemented, it can be implemented as either fixed size or extensible, but the current mainstream virtual machines are implemented according to extensibility (controlled by -Xmx and -Xms). If there is no memory in the heap to complete the instance allocation, and the heap can no longer be expanded, an OutOfMemoryError exception will be thrown.
5. Method area
The method area (Method Area), like the Java heap, is a memory area shared by each thread. It is used to store data such as class information, constants, static variables, and code compiled by the real-time compiler 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 (non-heap), which should be distinguished from the Java heap.
For developers who are accustomed to developing and deploying programs on the HotSpot virtual machine, many people are willing to call the method area "Permanent Generation", which is essentially not equivalent, just because the HotSpot virtual machine's The design team chose to extend the GC generational collection to the method area, or use the permanent generation to implement the method area only. For other virtual machines (such as BEA JRockit, IBM J9, etc.), there is no concept of permanent generation. Even the HotSpot virtual machine itself, according to the official roadmap information, has now abandoned the permanent generation and "moved" to Native Memory to realize the planning of the method area.
The Java virtual machine specification has very loose restrictions on this area, except that it does not require contiguous memory like the Java heap and can choose fixed size or expandable, and you can also choose not to implement garbage collection. Relatively speaking, garbage collection behavior is relatively rare in this area, but it is not that data enters the method area as "permanently" as the name of the permanent generation. The memory recovery goal of this area is mainly for the recovery of the constant pool and the unloading of types. Generally speaking, the recovery "score" of this area is relatively unsatisfactory, especially the unloading of types. The conditions are quite harsh. Recycling is indeed necessary. In Sun's BUG list, there have been several serious BUGs that caused memory leaks due to the fact that the lower version of the HotSpot virtual machine did not completely reclaim this area. According to the Java virtual machine specification, when the method area cannot meet the memory allocation requirements, an OutOfMemoryError exception will be thrown.
6. Runtime constant pool
The Runtime Constant Pool is part of the method area. In addition to the class version, fields, methods, interfaces and other descriptions of the class, there is also a constant pool (Constant Pool Table) in the Class file, which is used to store various literals and symbolic references generated during compilation. This part The content will be stored in the runtime constant pool of the method area after the class is loaded. The Java virtual machine has strict regulations on the format of each part of the Class file (including the constant pool, of course). What kind of data each byte is used to store must meet the requirements of the specification, so that it will be recognized by the virtual machine. Load and execute. but for
The runtime constant pool, the Java virtual machine specification does not require any details, and virtual machines implemented by different providers can implement this memory area according to their own needs. However, in general, in addition to saving the symbolic references described in the Class file, the translated direct references are also stored in the runtime constant pool. Another important feature of the runtime constant pool compared to the Class file constant pool is that it is dynamic. The Java language does not require that constants must only be generated at compile time, that is, the content of the constant pool in the Class file cannot be entered before entering the method. There is a runtime constant pool, and new constants may also be put into the pool during runtime. This feature is used more by developers than the intern() method of the String class. Since the runtime constant pool is part of the method area, it is naturally limited by the memory of the method area. When the constant pool can no longer apply for memory, an OutOfMemoryError exception will be thrown.
7. Direct memory
is not part of the virtual machine runtime data area, nor is it a memory area defined in the Java Virtual Machine Specification. JDK1.4 added NIO and introduced an I/O method based on channels and buffers. It can use the Native function library to directly allocate off-heap memory, and then use a DirectByteBuffer object stored in the Java heap as a reference to this memory. to operate. This improves performance because it avoids copying data back and forth between the Java heap and the Native heap.
When the sum of each memory area is greater than the physical memory limit, an OutOfMemoryError exception is thrown.