Bytecode Instructions: Branching, Returns, and Synchronization

Understand the bytecode instructions that control execution flow rather than compute values: the conditional branches that implement if/while/for (including reference-identity comparisons), the two different instructions a switch can compile to, the type-specific instructions that return from a method, and how synchronized compiles to two entirely different mechanisms depending on whether it's a method modifier or a block — including the exception-handling machinery the compiler silently inserts to make a synchronized block exception-safe.

• Reading javap -c output to trace which branch a compiled if/else actually takes, and matching jump targets (ifne 6, goto 27) back to source lines.
• Explaining why == on two objects never calls equals() — it's if_acmpeq/if_acmpne, an identity comparison, all the way down at the bytecode level.
• Recognizing whether a switch compiled to a tableswitch (dense case labels, O(1) jump table) or a lookupswitch (sparse labels, O(log n) binary search) when reading a disassembly.
• Explaining why a method's return statement always compiles to a type-specific opcode, and why mismatching one (e.g. ireturn in a method declared to return long) is rejected by the bytecode verifier, not just a runtime error.
• Understanding why a synchronized block always compiles to more instructions than a synchronized method, and why that block's bytecode contains an exception handler you never wrote in source.
• Recognizing athrow in a disassembly as the single instruction every throw statement — checked or unchecked, yours or the JVM's own NullPointerException — compiles down to.

Conditional branches: comparing against zero vs. comparing two values

The JVM has two families of conditional jump. One compares a single value against zero (ifeq, ifne, iflt, ifle, ifgt, ifge, plus ifnull/ifnonnull for references); the other compares two values directly off the stack (if_icmpeq, if_icmpne, if_icmplt, if_icmple, if_icmpgt, if_icmpge for int, and if_acmpeq/if_acmpne for references). Both exist so the compiler never has to synthesize a zero to compare against when it already has two live values on the stack:

java
static int classify(int x) {
    if (x == 0) return 0;
    if (x > 0) return 1;
    return -1;
}

static boolean sameOrder(int a, int b) {
    return a < b;
}

plaintext
static int classify(int);
    iload_0
    ifne          6      // x == 0 reduces to a single zero-comparison
    iconst_0
    ireturn
    iload_0
    ifle          12     // x > 0 is still a zero-comparison, just a different one
    iconst_1
    ireturn
    iconst_m1
    ireturn

static boolean sameOrder(int, int);
    iload_0
    iload_1
    if_icmpge     9       // a < b compares two live stack values directly, no zero involved
    iconst_1
    goto          10
    iconst_0
    ireturn

Every comparison operator is compiled to its inverse branch — x == 0 becomes ifne (jump away when not equal), a < b becomes if_icmpge (jump away when not less) — because a branch-on-inverse-condition lets the "true" path fall straight through without a goto, and only the "false" path needs an explicit jump.

ifnull/ifnonnull follow the same zero-comparison family for references — a null reference is represented the same way a zero int is at the bytecode level, which is why s == null compiles identically in shape to x == 0:

plaintext
static boolean isNull(java.lang.String);
    aload_0
    ifnonnull     8
    iconst_1
    goto          9
    iconst_0
    ireturn

if_acmpeq/if_acmpne are the two-value family's reference counterpart to if_icmpeq/if_icmpne — they compare identity, not content, which is exactly why == on two objects means "same reference" at the bytecode level regardless of what equals() would say:

java
static boolean refEquals(Object a, Object b) { return a == b; }

plaintext
static boolean refEquals(java.lang.Object, java.lang.Object);
    aload_0
    aload_1
    if_acmpne     9      // a == b compiles to "jump away if references differ"
    iconst_1
    goto          10
    iconst_0
    ireturn

There's no if_acmpeq/if_acmpne equivalent that calls .equals() — content comparison is always an explicit invokevirtual call the source code has to write, never something the == operator triggers on its own for reference types.

Multi-way branching: tableswitch vs. lookupswitch

A switch on int (or a type that reduces to int — char, byte, short, or an enum's ordinal) compiles to one of two dedicated instructions, chosen by the compiler based on how the case labels are distributed, not by anything visible in the source syntax:

java
static int denseSwitch(int x) {
    switch (x) {
        case 0: return 10;
        case 1: return 20;
        case 2: return 30;
        default: return -1;
    }
}

static int sparseSwitch(int x) {
    switch (x) {
        case 1: return 1;
        case 100: return 2;
        case 10000: return 3;
        default: return -1;
    }
}

plaintext
static int denseSwitch(int);
    iload_0
    tableswitch   { // 0 to 2
                0: 28
                1: 31
                2: 34
          default: 37
    }
    ...

static int sparseSwitch(int);
    iload_0
    lookupswitch  { // 3
                1: 36
              100: 38
            10000: 40
          default: 42
    }
    ...

tableswitch is a direct-indexed jump table — it's O(1): the case value itself is the offset into a contiguous array of branch targets, which is exactly why it only works when the labels are dense enough that building that array isn't wasteful. lookupswitch stores explicit (value, target) pairs sorted by value and the JVM binary-searches them — O(log n), but with no wasted table entries for gaps between 1, 100, and 10000. The compiler picks whichever costs less space for the actual label distribution; both compile the same source construct, so nothing about which one you get is under the programmer's control.

Type-specific return instructions

Just like arithmetic, return is not one instruction — it's six, one per category of value, and a void method uses a seventh that returns nothing at all:

plaintext
ireturn   // int, boolean, byte, short, char
lreturn   // long
freturn   // float
dreturn   // double
areturn   // object reference
return    // void — no value on the stack to return

The verifier checks the returned value's type against the method's declared return descriptor at class-load time — a method compiled (by hand-assembled bytecode, since javac would never generate this) with ireturn where the descriptor says J (long) is rejected before the method can run, the same way a .class file with the wrong magic number is rejected before its instructions are read.

synchronized: a method flag vs. an explicit monitor pair

A synchronized method doesn't add any bytecode instructions to the method body at all — it sets the ACC_SYNCHRONIZED access flag, and the JVM acquires the monitor as part of invoking the method:

java
public synchronized void incSynchronizedMethod() {
    count++;
}

plaintext
public synchronized void incSynchronizedMethod();
    flags: (0x0021) ACC_PUBLIC, ACC_SYNCHRONIZED
    Code:
      ...            // ordinary field-increment bytecode — no monitorenter/monitorexit here

A synchronized block, by contrast, has no access flag to lean on — the monitor's scope is arbitrary, decided at the source level — so the compiler emits explicit monitorenter/monitorexit instructions around it:

java
public void incSynchronizedBlock() {
    synchronized (lock) {
        count++;
    }
}

plaintext
public void incSynchronizedBlock();
    Code:
       0: aload_0
       1: getfield      #7          // Field lock:Ljava/lang/Object;
       4: dup
       5: astore_1
       6: monitorenter               // acquire the lock
       7: aload_0
       8: dup
       9: getfield      #13          // Field count:I
      12: iconst_1
      13: iadd
      14: putfield      #13
      17: aload_1
      18: monitorexit                // release the lock — normal exit
      19: goto          27
      22: astore_2
      23: aload_1
      24: monitorexit                // release the lock — exceptional exit
      25: aload_2
      26: athrow
      27: return
    Exception table:
       from    to  target type
           7    19    22   any
          22    25    22   any

That exception table — which never appears in the source — is what makes a synchronized block exception-safe: the compiler generates a second copy of monitorexit, covered by a catch-all handler over the whole block body, specifically so a lock acquired by monitorenter is still released by monitorexit if count++ (or anything inside the block) throws. There's no source-level try/finally written here — the compiler inserts the equivalent of one automatically, purely because a block-scoped lock has no other way to guarantee release on every exit path.

athrow

Every throw statement in Java — checked exception, unchecked exception, or a NullPointerException the JVM itself raises for a bad dereference — compiles to the single athrow instruction, which pops a Throwable reference off the stack and transfers control to the nearest matching handler in the method's exception table (or unwinds the frame if there is none):

java
public void fail() {
    throw new IllegalStateException("bad state");
}

plaintext
public void fail();
    Code:
       0: new           #17    // class java/lang/IllegalStateException
       3: dup
       4: ldc           #19    // String bad state
       6: invokespecial #21    // Method IllegalStateException."<init>":(Ljava/lang/String;)V
       9: athrow

Constructing the exception is just the familiar new/dup/invokespecial object-creation sequence — athrow itself does nothing but hand the already-built object off to the JVM's exception-dispatch machinery.

• Every branch is compiled inverted — the compiler always emits the opposite of the source condition (== becomes ifne, < becomes if_icmpge) so the common "true" path falls through without a jump; this makes hand-reading disassembled conditionals counterintuitive until you internalize that the branch target is always the else path, not the then path.
• A synchronized method pays nothing extra in bytecode, a synchronized block pays for its own exception safety — the method form is a single access-flag bit the JVM handles at invocation time, while the block form costs a duplicated monitorexit and a compiler-generated exception table, because the JVM has no equivalent of "release this monitor when this arbitrary code region exits, however it exits" without that explicit machinery.

java
synchronized (lock) {
    doSomethingThatThrows();   // monitorexit still runs — the compiler's exception table guarantees it
}

• The verifier enforces a Throwable on athrow, not any particular exception type — any object assignable to java.lang.Throwable can be thrown, which is why athrow alone can't distinguish a checked exception from an unchecked one; that distinction is a javac-level, not a bytecode-level, concept — the compiler checks throws clauses at compile time, but nothing in the .class file re-checks it at runtime.
• jsr/ret are documented in the JVMS but no javac since Java 6 emits them, and no JVM since class file version 51 (Java 7) will even load them — older material (and older bytecode-manipulation tooling) still describes them as the mechanism finally blocks used to compile to: a subroutine call (jsr) that pushed a return address for ret to jump back to, letting one copy of the finally body serve every exit path. javac switched to duplicating the finally body inline at every exit instead, and the specification now forbids jsr/ret outright — a class file targeting a modern release that still contained them would fail verification, not run with reduced performance. goto_w (the 32-bit-offset counterpart to goto) is unaffected by this and remains legal, but is only ever emitted for a method body large enough that a 16-bit branch offset can't reach the target — effectively never, outside of generated code.