How do a frame's local variable array and its operand stack cooperate while bytecode executes, and how are arguments and return values handed between a caller's frame and a callee's frame?

## Two areas, two jobs A JVM frame separates *storage* from *computation*. - The **local variable array** is random-access storage indexed by number. It holds the parameters and locals of the invocation. Nothing computes here. - The **operand stack** is a small last-in-first-out working area, empty when the frame is created and (for a well-formed method) empty again when it completes. Every instruction that computes takes its inputs from the top of this stack and leaves its output there. That split is why almost all bytecode reads as *load, compute, store*. ``` int c = a + b; // a=slot1, b=slot2, c=slot3 iload_1 // stack: [a] iload_2 // stack: [a, b] iadd // pops both, pushes sum -> [a+b] istore_3 // pops into slot 3, stack empty again ``` Depth here peaks at 2, which is what the compiler records as `max_stack`. ## Slot layout rules - **Instance methods**: slot 0 is the receiver, `this`. **Static methods**: slot 0 is the first parameter. This is why `aload_0` at the top of an instance method means "push `this`". - Parameters follow in declaration order, then the body's locals. - **`long` and `double` occupy two consecutive slots**, referenced by the lower index; slot *n+1* is reserved and must not be addressed on its own. They likewise consume two units of operand-stack depth. (`getfield` on a `long` field pops one reference and pushes two units.) - The compiler may **reuse a slot** for source variables whose scopes do not overlap, so slot indices do not map one-to-one onto declared names. ## The call protocol between frames The operand stack is not only for arithmetic — it *is* the argument-passing mechanism, and this is the part candidates most often get vague about. 1. In the caller's frame, push the receiver first for an instance call (`invokevirtual`, `invokeinterface`, `invokespecial`), then each argument in left-to-right order. A static call (`invokestatic`) pushes arguments only. 2. The invoke instruction consumes exactly those values from the caller's operand stack. It creates a **new frame** for the callee, and the consumed values become the callee's local slots starting at 0 — receiver at 0 for an instance method, then the arguments, widening `long`/`double` across two slots each. 3. The callee runs with its own empty operand stack. 4. On `ireturn`/`areturn`/etc., the return value is popped from the callee's operand stack; the callee frame is destroyed; the value is pushed onto the **caller's** operand stack. A `void` method (`return`) pushes nothing. So the caller's operand stack behaves like an argument staging area followed immediately by a result slot — which is why chained expressions such as `a.f().g()` compile to a run of pushes and invokes with no intermediate locals at all. ``` total = list.size() + 1; aload_1 // push list (receiver) invokevirtual size:()I // pops receiver, pushes int result iconst_1 iadd istore_2 ``` Notice `size()`'s frame came and went entirely between instructions 1 and 2; all the caller ever sees is that the receiver disappeared and an `int` appeared. ## Abrupt completion If an exception is thrown and a handler exists in the current method, the operand stack of the frame is **cleared**, the exception object is pushed as the single value, and execution jumps to the handler's bytecode index. If no handler matches, the frame is popped and the exception is rethrown in the caller — which is exactly why a stack trace shows the chain of frames unwound. ## Why the design looks like this A stack machine with statically known depth makes the class file compact (no register allocation encoded, no operand addresses), makes verification tractable (the verifier simulates the operand stack's types at every instruction), and leaves the real machine's register allocation to the JIT. When a method is compiled, this shuttle largely evaporates: values stay in machine registers, and the operand stack exists only as metadata that lets the runtime reconstruct the abstract state when it needs to build a stack trace or deoptimize back to the interpreter. ## What to take away Locals are named storage; the operand stack is the calculator's display. Arguments go *out* through the caller's operand stack and arrive *in* as the callee's low local slots; results come back onto the caller's operand stack. Long and double are two-wide in both areas, and `this` is slot 0 of an instance method.