A new frame is created each time a method is invoked. A frame is destroyed when its method invocation completes, whether that completion is normal or abrupt (it throws an uncaught exception).
Frames are allocated from the Java virtual machine stack of the thread creating the frame. Each frame has its own array of local variables , its own operand stack (§2.6.2), and a reference to the runtime constant pool of the class of the current method
Each frame contains an array of variables known as its local variables.
A single local variable can hold a value of type boolean, byte, char, short, int, float, reference, or returnAddress. A pair of local variables can hold a value of type longor double.
Each frame (§2.6) contains a last-in-first-out (LIFO) stack known as its operand stack. The maximum depth of the operand stack of a frame is determined at compile-time and is supplied along with the code for the method associated with the frame
The operand stack is empty when the frame that contains it is created. The Java virtual machine supplies instructions to load constants or values from local variables or fields onto the operand stack. Other Java virtual machine instructions take operands from the operand stack, operate on them, and push the result back onto the operand stack. The operand stack is also used to prepare parameters to be passed to methods and to receive method results.
For example, the iaddinstruction (§iadd) adds two intvalues together. It requires that the intvalues to be added be the top two values of the operand stack, pushed there by previous instructions. Both of the intvalues are popped from the operand stack. They are added, and their sum is pushed back onto the operand stack. Subcomputations may be nested on the operand stack, resulting in values that can be used by the encompassing computation.
Each frame (§2.6) contains a reference to the runtime constant pool (§2.5.5) for the type of the current method to support dynamic linkingof the method code.
The classfile code for a method refers to methods to be invoked and variables to be accessed via symbolic references. Dynamic linking translates these symbolic method references into concrete method references, loading classes as necessary to resolve as-yet-undefined symbols, and translates variable accesses into appropriate offsets in storage structures associated with the runtime location of these variables.This late binding of the methods and variables makes changes in other classes that a method uses less likely to break this code.
Reference:http://blog.csdn.net/vernonzheng/article/details/8458483