Understanding Java Virtual Machine Stack Frames and Method Invocation

Preface

The JVM executes bytecode using a stack‑based architecture, where all operands are pushed onto the operand stack before operations, differing fundamentally from register‑based designs.

Thought Process

When a method is called, parameters and return values must be stored somewhere; each call creates a stack frame that holds this data.

Stack Frame

A stack frame is created for each method invocation and destroyed when the method completes, either normally or via an uncaught exception.

Each frame contains a Local Variables array, an Operand Stack, Dynamic Linking information, a Return Address, and optional extra data.

Local Variables (Local Variables)

The local variable table is an array allocated at compile time; variables are accessed by index starting at 0.

Each slot can hold a 32‑bit value (boolean, byte, char, short, int, float, reference, returnAddress). 64‑bit types (long, double) occupy two consecutive slots.

For static methods, parameters are passed starting at index 0; for instance methods, index 0 holds the "this" reference, and parameters start at index 1.

Operand Stack (Operand Stacks)

The operand stack is a LIFO stack whose maximum depth is determined at compile time. Values are loaded from the local variable table or fields onto the stack, operated on, and results are pushed back.

Dynamic Linking (Dynamic Linking)

Each frame holds a reference to the runtime constant pool entry for its method, enabling dynamic linking of method calls.

Method Return Address (Method Return Address)

A method can exit normally via a return instruction or abruptly via an uncaught exception.

Normal Completion

The current frame restores the caller's PC, local variables, and operand stack, then continues execution.

Abrupt Completion

If an exception propagates out of the method without being caught, the frame is discarded and no return value is produced.

Method Call Flow Demonstration

The following simple Java program illustrates the execution flow of a method call.

package com.zwx.jvm;

public class JVMDemo {
    public static void main(String[] args) {
        int sum = add(1, 2);
        print(sum);
    }

    public static int add(int a, int b) {
        a = 3;
        int result = a + b;
        return result;
    }

    public static void print(int num) {
        System.out.println(num);
    }
}

Compiling the class and disassembling with javap -c JVMDemo.class yields bytecode such as:

Compiled from "JVMDemo.java"
public class com.zwx.jvm.JVMDemo {
  public com.zwx.jvm.JVMDemo();
    Code:
       0: aload_0
       1: invokespecial #1 // Method java/lang/Object."
":()V
       4: return

  public static void main(java.lang.String[]);
    Code:
       0: iconst_1
       1: iconst_2
       2: invokestatic #2 // Method add:(II)I
       5: istore_1
       6: iload_1
       7: invokestatic #3 // Method print:(I)V
      10: return

  public static int add(int, int);
    Code:
       0: iconst_3
       1: istore_0
       2: iload_0
       3: iload_1
       4: iadd
       5: istore_2
       6: iload_2
       7: ireturn

  public static void print(int);
    Code:
       0: getstatic #4 // Field java/lang/System.out:Ljava/io/PrintStream;
       3: iload_0
       4: invokevirtual #5 // Method java/io/PrintStream.println:(I)V
       7: return
}

The article then explains common bytecode instructions such as iconst_i , invokestatic , istore_n , iload_n , ireturn , and invokevirtual .

Method Invocation Analysis

Java provides four bytecode instructions for method calls (pre‑JDK 1.7): invokestatic , invokespecial , invokevirtual , and invokeinterface . Since JDK 1.7, invokedynamic is also available.

Method Resolution

During class loading, symbolic references are resolved to direct references when the method can be determined at compile time (non‑virtual methods). Otherwise, resolution occurs at runtime.

Non‑Virtual Methods

Static, private, instance constructors, and super calls are non‑virtual and resolved early.

Method Overloading

Overloaded methods are selected at compile time based on the static types of arguments (static dispatch). An example shows why a call with a Human reference invokes the hello(Human) overload even when the actual object is a Man .

Static Dispatch

Static dispatch uses the static type of the receiver and the parameter types; it can involve multiple “quantities” (receiver + parameters) leading to static multi‑dispatch.

Method Overriding

When a subclass overrides a method, the JVM uses invokevirtual to perform dynamic dispatch: at runtime it looks up the actual object's class hierarchy to find the appropriate implementation.

Dynamic Dispatch

Dynamic dispatch determines the method to invoke based on the actual runtime type of the receiver (single‑dispatch).

Static Multi‑Dispatch vs Dynamic Single‑Dispatch

Java combines static multi‑dispatch for overload resolution with dynamic single‑dispatch for overridden methods, making it a static‑multi, dynamic‑single dispatch language.

Summary

The article introduced the JVM stack‑frame layout, explained how local variables and operand stacks work, and demonstrated method call execution from source code to bytecode, covering both overload and override resolution mechanisms.