Java Virtual machine Stacks, Thread-private, has the same life cycle as the thread, describing the memory model that the Java method executes: Each method executes with a stack frame created, due to the storage of local variable tables, operand stacks, dynamic links, Method exports and other information. The execution of each method corresponds to the stack frame in the virtual machine stack, the stack process.
- local variable table:
- holds the various basic data types, object reference types, and returnaddress types that are known at compile time (the address of a byte-code directive: function return address). A
- long, double occupies two local variable control slots. The memory space required by the
- local variable table is determined at compile time, and when a method is entered, the local variable control that the method needs to allocate in the stack frame is fully deterministic and cannot be dynamically resized.
- Exception: The stack frame depth of a thread request is greater than the depth allowed by the virtual machine---stackoverflowerror, if the virtual machine stack can be dynamically extended (most virtual machines allow dynamic scaling, or you can set a fixed-size virtual machine stack). However, it is not possible to apply enough memory---outofmemorerror.
-
Operand stack:
- LIFO, the maximum depth is determined by the compilation period. When the stack frame is created, the operand stack is empty, and the operand stack is used to store constants or variables that the JVM copies from the local variable table, provides the extract, and the result into the stack, and also holds the parameters required by the calling method and the results returned by the accepted method. The
- operand stack can hold a value of any data type defined in the JVM.
- at any point in time, the operand stack has a fixed stack depth, with a base type of two depth in addition to a long, double, and the other occupying a depth
-
Dynamic connection:
&NB Sp Each stack frame contains a reference to the method that the stack frame belongs to in the run-time pool, which is held to support dynamic connections during method invocation. A large number of symbolic references exist in the constant pool of the class file, and the method invocation directives in the bytecode are referenced as parameters to the symbol in the constant pool that points to the method. These symbolic references, some of which are converted to direct references (such as final, static, and so on) during the class loading phase or when they are first used, are called statically resolved, and the other part is converted to direct references during each run, which is called dynamic connections.
- Method return Address:
- When a method is executed, there are two ways to exit the method: The execution engine encounters a bytecode instruction returned by either method or encounters an exception, and the exception is not processed in the method body. Regardless of the exit mode, after the method exits, it is necessary to return to the location where the method was 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 state of its upper-level method. In general, the method normally exits, the caller's PC counter value can be used as the return address, the stack frame is likely to save the counter value, and the method exits unexpectedly, the return address is to be determined by the exception handler, the stack frame is generally not save this part of the information.
- The process of exiting the method is actually the same as putting the current stack frame out of the stack, so the possible actions to exit are: Restore the local variable table of the upper method and the operand stack, and if there is a return value, press it into the operand stack of the caller stack frame, and adjust the value of the PC counter to point to an instruction following the method invocation
Java Virtual Machine stack
