Java virtual machine stack
The Java Virtual Machine assigns a virtual stack to each thread, and the Java virtual stack is thread private.
Each virtual machine stack has several stack frames, and each stack frame corresponds to a method in the Java code. When a thread executes a method, it means that the corresponding stack frame of the method has entered the virtual machine stack and is at the top of the stack (first in, then out). Each Java method from the call to the end of execution corresponds to the process of a stack frame from the stack to the stack.
Each stack frame stores local variable table, operand stack, dynamic link, return address and so on.
Local Variable Table (Local Variable Table) is a group of Variable value storage space, used to store method parameters and Local variables defined in methods. The capacity of the local Variable table is the smallest unit in Variable Slot. The Java Virtual Machine specification does not define how much memory space a slot should occupy, but it does specify that a slot should be able to hold data types up to 32 bits.
② Operand Stack (temporary data storage area used for calculation) : Operand Stack is also called operation Stack. When a method is implemented, the operand stack is empty, with the method of execution and bytecode instruction execution, from local variables or object instances in the field of reproduction constant or variable written to the operand stack, again with the calculation of the elements in the stack to the local variables or method is returned to the caller, that is out of/into the stack operation. A complete method execution usually involves multiple such push/push processes.
(3) Dynamic linking: In a class file, a method calls other methods by converting symbolic references of those methods into direct references to their memory addresses. Symbolic references exist in the runtime constant pool in the method area.
In the Java virtual machine stack, each stack frame contains a symbolic reference to the method that the stack belongs to in the runtime constant pool. This reference is held to support Dynamic Linking during method invocation. Some of these symbolic references are converted directly to direct references during class loading or the first time they are used, which is called static resolution. The other part is converted to a direct reference during each run, which is called a dynamic join.
When a method is executed, there are only two ways to exit it:
Method return instruction: When the execution engine encounters a bytecode instruction returned by a method, there may be a return value passed to the upper method caller. This exit is called the normal completion exit.
Exception exit: An exception encountered during the execution of a method and not handled causes the method to exit.
Regardless of the exit method, after the method exits, the program needs to return to the location where the method was called in order to continue execution, and the method may need to store some information in the stack frame when it returns. Used to help restore the execution state of its upper-level methods. The process of method exit is actually equal to the current stack frame out of the stack, so exit possible operations are: 1. Restores the local variable table and operand stack of the upper method. 2. Push the return value (if any) into the operand stack of the caller’s stack frame. 3. Adjust the value of the program counter to point to an instruction following the method call instruction.
Local method stack
The difference between the Native Method stack and the Java virtual machine stack is that the virtual machine stack executes Java methods, while the Native Method stack executes Native methods. Otherwise, it is basically the same.
Program counter
Program counters are used to determine the order in which instructions are executed, such as loops, branches, jumps, exception catches, etc. The JVM implements multithreading by switching threads in turn, keeping program counters private as threads to ensure that each thread executes in the correct order. A program counter is a very small memory space that can be thought of as a line number indicator of the bytecode being executed by the current thread. The program counter is the only specified area of the Java virtual machine where memory overflow does not occur.
The heap
The heap is an area of objects shared by all threads and is the main area for GC. The subdivisions are Cenozoic era and old age. The New generation can be subdivided into one Eden and two Survivor areas (From,To). Eden stores objects created through new or newInstance. Most of them are short-lived. Under normal circumstances, after one GC, the surviving objects will be transferred to one of the Survivor zones, and then they will be transferred to the old age after 15 GC by default. In cases where the Survivor zone is full, the JVM puts some objects directly into the old age based on the guarantee mechanism. When an object occupies too much memory, it is put directly into the old age.
Heap memory, which holds objects and arrays, is the largest area of memory managed by the JVM and is created at vm startup. At the level of garbage collection, now collectors are basically using generational collection algorithms.
The Hotspot virtual machine implementation starts to do away with persistent generation in JDK1.7, moving the string constant pool, class static variables from the original method area to the Java Heap.
Methods area
The Method Area, like the Java heap, is an Area of memory shared by threads that stores data such as type information that has been loaded by the virtual machine, constants, static variables, and code caches compiled by the just-in-time compiler.
The Runtime Constant Pool is part of the method area. The Constant Pool Table is used to store various literals and symbolic references generated at compile time. This part of the Table is stored in the runtime Constant Pool of the method area after the Class is loaded.
Things like integer constant pools, string constant pools, and so on are part of constant pools.
The method region is also called the permanent generation. In the past (before custom classloaders were common), classes were mostly “static” and were rarely unloaded or collected, thus being called “Permanent.”
The design team of the HotSpot VIRTUAL machine chose to extend GC generation collection to the method area, or to implement the method area with persistent generation.
Starting with the permanent generation removal process in JDK7, some of the data stored in the permanent generation has been moved to the Java Heap or Native Heap. However, the permanent generation still exists in JDK7 and is not completely removed: Symbols are transferred to the native heap; Literals (interned strings) are transferred to the Java Heap; Class statics are moved to the Java Heap. With the advent of JDK8, the JVM no longer has PermGen. But the metadata of the class is still there, but instead of being stored in contiguous heap space, it is moved to Native memory called Metaspace.
- Reference article 1[blog.csdn.net/weixin_5722…]
- See article 2: Understanding the Java Virtual Machine in Depth: Advanced JVM features and Best practices