Unlock Java’s Secrets: How Bytecode Powers Cross‑Platform Execution

Preface

Hello, I am Su San. Starting today I will publish a series of advanced Java fundamentals articles, because a solid foundation is essential for mastering higher‑level concepts such as object layout, garbage collection, and NIO.

The series will be illustrated with diagrams and will be compiled into a PDF for easy reference.

Why Java is Cross‑Platform

Java is an object‑oriented, statically typed language that runs on a virtual machine (JVM). Source files are first compiled into bytecode, which the JVM interprets or JIT‑compiles into native machine code for the underlying operating system. This two‑step process isolates Java programs from OS differences, allowing a single JAR package to run on any platform that provides a compatible JVM.

JVM Memory Structure

The JVM memory is divided into the stack, heap, non‑heap (including the method area and code cache), and the JVM’s own internal structures. The heap stores class instances and arrays, while the method area holds class metadata such as the constant pool.

The stack holds frames for each method invocation. A frame consists of:

Return value

Local variable table

Dynamic linking information

Operand stack

Dynamic Linking and Polymorphism

Bytecode stores symbolic references to methods and fields. At runtime the JVM resolves these symbols to direct references, enabling polymorphic dispatch. For example:

Father f = new Son();
f.method(); // resolved to Son.method at runtime

Methods that are final , static , private , or constructors are bound at compile time (static linking). All other instance methods are bound at runtime (dynamic linking).

Bytecode Instruction Set

Each bytecode consists of an opcode and optional operands. Some opcodes embed the operand (e.g., iconst_1 pushes the integer 1 onto the operand stack), while others require a following operand (e.g., bipush pushes a signed byte constant).

0x04

iconst_1

Push int constant 1 onto stack

0xb7

invokespecial

Invoke instance initialization, private, or superclass method

0x1a

iload_0

Load first int local variable onto stack

0x10

bipush

Push signed byte constant (-128~127) onto stack

The javap tool translates bytecode into these mnemonic forms, making the underlying execution logic visible.

Example: Default Constructor Execution

Consider the following Java class:

class Demo {
    private int a = 1;
    public static void foo() {
        int a = 1;
        int b = 2;
        int c = (a + b) * 5;
    }
}

After compilation, javap -c Demo.class shows the bytecode for the default constructor, which includes the instructions: aload_0 – load this reference invokespecial – call superclass

<init>

iconst_1

– push constant 1 putfield #2 – store the constant into field a The constant pool entry #2 resolves to the field Demo.a, demonstrating how bytecode reveals the actual initialization steps hidden in source code.

Operand Stack Example

For the statement int i = 69;, the generated bytecode is:

0: bipush 69
2: istore_0

The operand stack first receives the constant 69, then istore_0 pops it into local variable slot 0.

Execution Flow Overview

JVM execution mirrors CPU execution: fetch the next bytecode (guided by the program counter), decode it into an operation, execute it (often via the interpreter or JIT), and store results in the local variable table or operand stack.

Tools for Bytecode Inspection

Hex Fiend – a hex editor for viewing raw bytecode files.

IntelliJ IDEA plugin jclasslib Bytecode Viewer – visualizes constant pools, method structures, and code sections.

Next article will discuss how bytecode is loaded by the JVM.