Coursepodia
LESSON 02 · BEGINNER4 min read

Bytecode Disassembly, The Constant Pool & Stack Machine Execution

Disassemble class files using javap. Master the constant pool, operand stack instructions, local variable arrays, and bytecode verification.

OpenJDK 21+ (LTS)Free to readModule 1 of 15
YOUR NEXT SMALL WINS

By the end, you’ll be able to…

  • Disassemble .class files using javap -v to inspect internal bytecode structures.
  • Understand the Constant Pool as a central lookup table for symbols and literals.
  • Model the LIFO Operand Stack and Local Variable Array operations (iload, istore, iadd, invokevirtual).

01The Stack-Based Virtual Machine

Unlike modern hardware CPUs (like x86-64 or ARM64) which are register-based machines with hardware registers (RAX, RBX, X0), the Java Virtual Machine is an abstract Stack-Based Machine. Every thread possesses its own Java Virtual Machine Stack consisting of frames.

Each stack frame contains two critical structures: the Local Variable Array (which holds method arguments and local variables) and the Operand Stack (a LIFO work area where computations are staged). Bytecode instructions push operands onto the operand stack, perform operations by popping them, and push results back.

notes.txtPlain text
+---------------------------------------------------+|              JVM Stack Frame Architecture         |+---------------------------------------------------+|  [Local Variable Array]   |    [Operand Stack]    ||  Slot 0: this             |    Top -> [ 30 ]      ||  Slot 1: int a = 10       |           [ 20 ]      ||  Slot 2: int b = 20       |    (iadd pops 2,      ||  Slot 3: int result       |     pushes 30)        |+---------------------------------------------------+

02Disassembling Bytecode with javap

The JDK provides a built-in disassembler tool: javap. By executing javap -c -v ClassName, you can inspect the exact bytecode instructions generated by the Java compiler.

Consider a simple addition: int c = a + b. In bytecode, this compiles to iload_1 (push value from local variable slot 1 onto operand stack), iload_2 (push value from slot 2 onto stack), iadd (pop both integers, sum them, push result), and istore_3 (pop result and store into slot 3). This transparent visibility demystifies exactly how Java executes.

notes.txtPlain text
// Disassembled bytecode for: int add(int a, int b) { return a + b; }public int add(int, int);  Code:     0: iload_1       // Push local variable 'a' onto operand stack     1: iload_2       // Push local variable 'b' onto operand stack     2: iadd          // Pop both, add them, push sum     3: ireturn       // Return integer on top of operand stack

03The Constant Pool Table

Inside every compiled .class file is the Constant Pool Table. Rather than embedding long strings, class names, method signatures, and numeric constants directly into instruction opcodes, bytecode instructions reference integer indices in the constant pool.

An instruction like ldc #2 references entry #2 in the constant pool. This design drastically reduces .class file sizes through deduplication and enables rapid symbol resolution during the Linking phase.

notes.txtPlain text
Constant pool:   #1 = Methodref          #4.#15         // java/lang/Object."<init>":()V   #2 = String             #16            // "Coursepodia Java"   #3 = Fieldref           #17.#18        // java/lang/System.out:Ljava/io/PrintStream;   #4 = Class              #19            // java/lang/Object

04Why This Matters in Production

Reading bytecode is an essential skill for high-performance engineering. When evaluating the cost of modern language features—such as String concatenation (invokedynamic with makeConcatWithConstants), auto-boxing (Integer.valueOf), or Java 21 Pattern Matching—bytecode inspection reveals the exact overhead.

If an inner loop is boxing primitives into heap objects, you can spot the hidden INVOKESTATIC Integer.valueOf instruction in javap in seconds, allowing you to refactor before performance regressions hit production.

05Production Architecture & Engineering Trade-Offs

Algorithmic efficiency in real-world software is heavily influenced by CPU hardware architecture, specifically the L1, L2, and L3 cache hierarchies and hardware branch predictors. While an algorithm may exhibit an optimal theoretical asymptotic complexity like O(n), poor spatial locality caused by pointer chasing across fragmented memory blocks can make it perform slower than a theoretically inferior algorithm operating over contiguous array memory.

When implementing two pointers and sliding window routines, developers must maintain strict boundary invariants to eliminate off-by-one errors and avoid redundant recomputations. Precomputing prefix sums or maintaining monotonic tracking queues transforms polynomial search operations into deterministic linear scans that execute with minimal memory allocations.

LET IT CLICK

The ideas worth keeping.

  • The JVM evaluates bytecode using an Operand Stack and Local Variable Array inside stack frames.
  • The Constant Pool deduplicates identifiers and literal constants for memory efficiency.
  • Use javap -c -v to inspect bytecode and uncover hidden auto-boxing or dynamic invocations.
TURN UNDERSTANDING INTO SOMETHING YOU CAN DO

Make it yours.

Type and test your code right here in the interactive workspace. Run your solution, check the output, and compare with the worked guide when ready.

01

Exercise 1: Tracing Operand Stack Transitions

Provide a dry-run trace table showing the Operand Stack contents before and after each instruction for: iconst_5, iconst_3, imul, iconst_2, iadd.

your_turn_1.java☕Java
Ctrl + ↵
Output
Click Run or press Ctrl+Enter
Output will appear here after you run the code.
Explore a worked solution
one_possible_solution.javaJava
// Dry-run trace table:// Opcode    | Stack (bottom -> top)// iconst_5  | [5]// iconst_3  | [5, 3]// imul      | [15]// iconst_2  | [15, 2]// iadd      | [17]

Each instruction pushes or pops values from the LIFO operand stack, evaluating (5 * 3) + 2 = 17.

02

Exercise 2: Spotting Auto-Boxing in Bytecode

Write a method that takes an int and adds it to a List<Integer>, explaining which bytecode instructions signify heap allocation.

your_turn_2.java☕Java
Ctrl + ↵
Output
Click Run or press Ctrl+Enter
Output will appear here after you run the code.
Explore a worked solution
one_possible_solution.javaJava
// Code: list.add(42);// Bytecode contains: BIPUSH 42 -> INVOKESTATIC Integer.valueOf (I)Ljava/lang/Integer;// The Integer.valueOf instruction auto-boxes the primitive into a heap object.

Generics cannot store raw primitives, so the compiler automatically injects Integer.valueOf to create an object reference.

A SMALL QUESTION. A USEFUL NEXT STEP.

What stayed with you?

Check the ideas while they’re fresh. Your answers stay in this page and feedback appears as you go.

A LITTLE ACTIVE RECALL0 / 3 answered
01How does the JVM execute computations differently from an x86 CPU?
02What is the purpose of the Constant Pool inside a .class file?
03Which javap command-line flags display full disassembled bytecode and internal tables?
⚡CODING CHALLENGE
🔒Required to Mark Lesson Complete

Exercise 1: Tracing Operand Stack Transitions

Provide a dry-run trace table showing the Operand Stack contents before and after each instruction for: iconst_5, iconst_3, imul, iconst_2, iadd.

EXPECTED OUTPUT
Build successful. (Java 15)
[Process exited normally]
Main.javaJava
Ctrl + ↵
Execution Console
Click "Run & Verify" (or press Ctrl + Enter) to test your code against the challenge.

Keep exploring.

The official references behind this lesson, when you want a second angle or the full details.

One lesson closer.

Reading is a start. Trying it yourself makes the connection.

Solve the hands-on coding challenge in the knowledge section to verify your code and unlock lesson completion.