Java Virtual Machine stack, Java Virtual Machine
Java Virtual Machine Stacks is a private thread. its lifecycle is the same as that of a thread. It describes the Memory Model of Java method execution. A Stack Frame is created when each method is executed ), the local variable table, operand stack, dynamic link, method exit, and other information are stored. The execution of each method corresponds to the stack frame in the Virtual Machine stack and the stack exit process.
- Local variable table:
- Stores various basic data types, object reference types, and returnAddress types known during the compilation period (pointing to the address of a bytecode instruction: The return address of the function ).
- Long and double occupy two local variable controls Slot.
- The memory space required by the local variable table is determined during the compilation period. When a method is entered, the local variable control to be allocated in the method stack frame is completely determined and cannot be dynamically changed.
- Exception: the stack frame depth requested by the thread is greater than the depth allowed by the virtual machine --- StackOverFlowError. If the Virtual Machine stack can be dynamically expanded (most virtual machines allow dynamic expansion, you can also set a fixed size of the Virtual Machine stack ), however, you cannot apply for sufficient memory --- OutOfMemorError.
- The maximum depth is determined by the compilation period. When the stack frame is just created, the operand stack is empty. When performing a method operation, the operand stack is used to store the constants or variables copied by JVM from the local variable table, provide extraction, and result into the stack, it is also used to store the parameters required to call the method and receive the results returned by the method.
- The operand stack can store any data type value defined in The jvm.
- The operand Stack has a fixed stack depth at any time. The basic types include long and double, and the others occupy one depth.
Each stack frame contains a reference pointing to the method to which the stack frame belongs in the runtime pool. This reference is held to support dynamic connections during method calling. A large number of symbolic references exist in the constant pool of the Class file. The method call instruction in the bytecode takes the symbolic reference pointing to the method in the constant pool as the parameter. Some of these symbolic references will be converted to direct references (such as final and static domains) during the class loading stage or when used for the first time. These are called static parsing, the other part will be converted to direct reference during each running period, which is called dynamic connection.
- Method return address:
- After a method is executed, there are two ways to exit the method: the execution engine encounters the bytecode command returned by any method or encounters an exception, the exception is not handled in the method body. No matter which exit method is used, after the method exits, it must be returned to the location where the method is called before the program can continue execution. When the method returns, you may need to save some information in the stack frame to help restore the execution status of its upper method. Generally, when the method Exits normally, the caller's PC counter value can be used as the return address. This counter value may be saved in the stack frame, and when the method exits unexpectedly, the returned address is determined by the exception processor. This information is generally not stored in stack frames.
- The exit process of the method is actually equivalent to taking the current stack frame out of the stack. Therefore, the operations that may be performed during exit include restoring the local variable table and the operand stack of the upper method. If there is a return value, then it is pushed into the operator stack of the caller stack frame, and the PC counter value is adjusted to point to a command after the method call command.