1. Runtime data area
1. The Java virtual machine divides the memory it manages into several different data areas during the execution of the Java program. These areas have their own purposes, as well as the time of creation and destruction. Some areas always exist as the virtual machine process starts, and some areas are created and destroyed depending on the start and end of the user thread.
Second, the program counter
1 Introduction
A: The Program Counter Register is a small memory space, which can be regarded as a line number indicator of the bytecode executed by the current thread.
B: In the conceptual model of the Java virtual machine, when the bytecode interpreter works, it selects the next bytecode instruction to be executed by changing the value of this counter.
C: It is an indicator of program control flow. Basic functions such as branches, loops, jumps, exception handling, and thread recovery all need to rely on this counter to complete.
D: The multi-threading of the Java virtual machine is realized by switching between threads and allocating processor execution time. At any certain moment, a processor (for a multi-core processor is a core) will only execute An instruction in a thread.
E: In order to restore to the correct execution position after thread switching, each thread needs to have an independent program counter. The counters between the threads do not affect each other and are stored independently. This type of memory area is called "thread private" RAM.
2. The thread is executing a Java method, and this counter records the address of the virtual machine bytecode instruction being executed; if the thread is executing a Native method, the counter value should be undefined.
Three, Java virtual machine stack
1 Introduction
A: The Java Virtual Machine Stack is also thread-private, and its life cycle is the same as that of a thread.
B: The virtual machine stack describes the thread memory model of Java method execution: when each method is executed, the Java virtual machine will synchronously create a stack frame to store the local variable table, operand stack, and dynamic connection , Method of export and other information.
C: The process from when each method is called to the completion of execution corresponds to the process of a stack frame from pushing to popping in the virtual machine stack.
2. Stack and local variable table
A: People generally divide the Java memory area into heap memory (Heap) and stack memory (Stack), which is a bit rough in the Java language. The actual memory area division is more complicated than this. However, the popularity of this division indirectly shows that the areas that programmers are most concerned about and are most closely related to object memory allocation are the "heap" and "stack".
B: "Stack" usually refers to the virtual machine stack mentioned here, or more often just the local variable table part of the virtual machine stack.
C: Stores the basic data types (boolean, byte, char, short, int, float, long, double) and object references (reference type, which is not equivalent to the object itself, but may be A reference pointer to the starting address of the object, or it may point to a handle representing the object or other locations related to this object) and returnAddress type (pointing to the address of a bytecode instruction).
D: The storage space of the data type in the local variable table is represented by the local variable slot (Slot). The 64-bit long and double data will occupy two variable slots, and the rest of the data types will only occupy one.
3. Description
A: The memory space required by the local variable table is allocated during compilation. When entering a method, the amount of local variable space that the method needs to allocate in the stack frame is completely determined. The local variable table will not be changed during the running of the method. the size of. ("Size" refers to the number of variable slots)
B: How much memory space the virtual machine really uses (for example, one variable slot occupies 32 bits, 64 bits, or more) to implement a variable slot is completely determined by the specific virtual machine implementation.
4. In the "Java Virtual Machine Specification", two types of abnormal conditions are specified for this memory area:
A: If the stack depth requested by the thread is greater than the depth allowed by the virtual machine, a StackOverflowError exception will be thrown;
B: If the stack capacity of the Java virtual machine can be dynamically expanded [illustration], an OutOfMemoryError will be thrown when the stack is expanded and cannot apply for enough memory.
Fourth, the local method stack
1. The functions of Native Method Stacks and virtual machine stacks are very similar. The difference is that the virtual machine stack serves the virtual machine to execute Java methods (that is, bytecode), while the native method stack is Serve the native method used by the virtual machine.
2. The "Java Virtual Machine Specification" does not have any mandatory provisions on the language, usage, and data structure used by the methods in the local method stack, so the specific virtual machine can freely implement it as needed.
3. Hot-Spot virtual machine) directly combines the local method stack and the virtual machine stack into one.
4. Like the virtual machine stack, the local method stack will also throw StackOverflowError and OutOfMemoryError exceptions respectively when the stack depth overflows or the stack expansion fails.
Five, Java heap
1. A block of memory area, created when the virtual machine starts. This memory area
2. With the development of the Java language, due to the advancement of just-in-time compilation technology, especially the increasingly powerful escape analysis technology, the stack allocation and scalar replacement optimization methods have caused some subtle changes to occur quietly, and Java object instances are allocated on the heap It gradually became less absolute.
3. The Java heap is a memory area managed by the garbage collector, so it is also called "GC heap" (Garbage Collected Heap) in some materials. From the perspective of reclaiming memory, since most modern garbage collectors are designed based on generational collection theory, there are often "new generation", "old generation", "permanent generation", "Eden space", and "From Survivor" in the Java heap. Nouns such as space" and "To Survivor space"
4. The purpose of Java heap segmentation is only to better reclaim memory or allocate memory faster
5. The Java heap can be implemented as a fixed size or expandable, but the current mainstream Java virtual machines are all implemented according to scalability (set by parameters -Xmx and -Xms).
6. If there is no memory in the Java heap to complete the instance allocation, and the heap can no longer be expanded, the Java virtual machine will throw an OutOfMemoryError exception.
Six, method area
1. The Method Area, like the Java heap, is a memory area shared by each thread. It is used to store data such as type information, constants, static variables, and code cache compiled by the JIT compiler that have been loaded by the virtual machine. (Alias non-heap)
2. The method to go and the permanent generation are not equivalent and cannot be confused. The implementation method area belongs to the details of the virtual machine.
3. The permanent generation is prone to memory overflow
The permanent generation has -XX: MaxPermSize upper limit, even if it is not set, there is a default size, and J9 and JRockit as long as they do not touch the upper limit of the process available memory, such as the 4GB limit in a 32-bit system, there will be no problems), and there is Very few methods (such as String::intern()) will cause different performances under different virtual machines due to permanent generation. After Oracle acquired BEA and obtained the ownership of JRockit, it was ready to migrate the excellent features of JRockit, such as the Java Mission Control management tool, to the HotSpot virtual machine, but it faced many difficulties due to the differences in the method area between the two. Taking into account the future development of HotSpot, in JDK 6, the HotSpot development team gave up the permanent generation and gradually changed to the plan to use native memory to implement the method area. By the HotSpot of JDK 7, the original has been placed in permanent The string constant pool, static variables, etc. of the generation were moved out, and in JDK 8, the concept of permanent generation was finally completely abandoned. Instead, the meta-space implemented in local memory like JRockit and J9 was used instead. The remaining content (mainly type information) of the permanent generation in JDK 7 is all moved to the meta space.
If the method area cannot meet the new memory allocation requirements, an OutOfMemoryError exception will be thrown.
Seven, runtime constant pool
1. Runtime Constant Pool is part of the method area. In addition to the description information of the class version, fields, methods, and interfaces in the Class file, there is also a constant pool table (ConstantPool Table), which is used to store various literal and symbolic references generated during compilation. This part of the content Will be stored in the runtime constant pool of the method area after the class is loaded
2. Another important feature of the runtime constant pool compared to the Class file constant pool is that it is dynamic. Constants may not be generated only during compilation, and new constants can also be placed in the pool during runtime.
3. The runtime constant pool is a 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, it will throw an OutOfMemoryError exception.
Eight, direct memory
1. Direct Memory is not a part of the data area of the virtual machine during runtime, nor is it the memory area defined in the "Java Virtual Machine Specification".
2. The direct memory allocation of the machine will not be restricted by the Java heap size, but since it is memory, it will definitely be affected by the total memory (including physical memory, SWAP partition or paging file) of the machine and the processor addressing space When configuring virtual machine parameters, general server administrators will set -Xmx and other parameter information according to the actual memory, but often ignore direct memory, making the sum of each memory area larger than the physical memory limit (including physical and operating system level Limit), resulting in an OutOfMemoryError exception during dynamic expansion.