Inside the Java Virtual Machine: JVM Architecture and Execution Flow

The JVM is not a virtual machine in the sense of pretending to be another machine's hardware. It is a **runtime process that loads bytecode, verifies it, and executes it**, either by interpreting it or by compiling it to native code for the actual processor.

That distinction matters because "interpreted" is a common and inaccurate description of Java. Java source compiles to bytecode ahead of time, and then the JIT compiler translates hot bytecode to native machine code while the program runs. A long-running Java program is mostly running natively compiled code, not interpreted bytecode.

YOUR SOURCE                 THE JVM PROCESS
   ┌──────────┐   javac       ┌──────────────────────────────┐
   │  Foo.java│ ────────────> │  Foo.class  (bytecode)       │
   └──────────┘   AOT         │    loaded, verified, run     │
                               │                              │
                               │  interpreter  ─┐             │
                               │                ├─> native   │
                               │  JIT (C1, C2) ─┘    machine  │
                               │                        code  │
                               │  GC  ◄──────── heap          │
                               └──────────────────────────────┘

The concrete version of this process is observable. Running the example for this topic against Temurin 17 prints:

==1. CLASSLOADER SUBSYSTEM ==classes loaded so far : 688String.class loader : null(null = bootstrap)==2. RUNTIME DATA AREAS ==max heap(-Xmx) : 3920 MB==3. EXECUTION ENGINE ==JIT time at start : 37 msJIT time after hot loop: 55 ms== the stack is per-thread and bounded ==StackOverflowError after 21259 frames

The JVM is conventionally described as three subsystems, and this is a useful decomposition rather than a marketing label, because each maps to a distinct part of the process.

What makes this decomposition genuinely useful is that each area maps to a specific kind of production problem. A StackOverflowError is a stack problem, an OutOfMemoryError is usually heap or metaspace, and a NoClassDefFoundError is a class-loading or packaging problem. Knowing which subsystem owns a symptom is most of the diagnosis.

Loading a class is a four-step process, and each step can fail differently.

**Loading** finds the bytes, usually from a JAR. **Verification** checks that the bytecode is safe and structurally valid, which is the security guarantee that distinguishes the JVM from a bare interpreter. **Preparation** allocates memory for static fields and sets them to default values, zero or null, before any code runs. **Initialization** then runs static initializer blocks, which is where static final constants actually receive their real values.

The verifier is worth demonstrating rather than asserting. Corrupting a real class file four different ways produces four different rejections, all before a single instruction executes:

Note the third row. This is the concrete form of the "compiled by a more recent version" error everyone has seen, and it is why a class file compiled on Java 25 will not run on a Java 17 JVM even though Java is famously backward compatible. Backward compatibility runs one direction only: new JVMs run old bytecode, never the reverse.

The example also shows something about delegation that is easier to observe than to explain. String.class.getClassLoader() returns **null**, and that null is not missing data, it is the bootstrap class loader, written in native code, which loaded the core classes. Everything the application loads comes from the application class loader instead:

String.class loader : null(null = bootstrap)our class loader : jdk.internal.loader.ClassLoaders$AppClassLoader@30946e09

The JVM specification defines several runtime data areas. This is where the most common confusion lives, particularly the heap versus stack question.

Two corrections to widespread beliefs are worth making here. First, the stack holds **frames**, and a frame holds primitive values and *references* to objects, not the objects themselves. Second, the classic slogan "primitives on the stack, objects on the heap" is right in effect but wrong in a way that confuses people: a reference is itself a value stored in the frame.

static String makeInFrame() {
    String s = new String("object born inside a stack frame");
    return s;
    // frame dies here, the object does not
}

The example proves this directly. After makeInFrame() returns, its stack frame is gone and unreachable, yet the object is still perfectly usable, because it was on the heap the whole time and only the reference lived on the stack.

Metaspace is the most practically important entry in that table, and it has one property that catches people out: **it is not part of the Java heap, so -Xmx does not limit it.**

The live output from the example makes this visible, because it lists the real memory pools and their types:

CodeHeap 'non-nmethods' Non-heap memoryMetaspace Non-heap memoryCodeHeap 'profiled nmethods' Non-heap memoryCompressed Class Space Non-heap memoryG1 Eden Space Heap memoryG1 Old Gen Heap memoryG1 Survivor Space Heap memoryCodeHeap 'non-profiled nmethods' Non-heap memory

Three things to read out of that list. **Metaspace is off-heap**, so sizing the heap does nothing for it. **There are three separate code caches** for the different JIT tiers, which surprises people who assume compiled code lives on the heap. And **G1 splits the heap into Eden, Survivor, and Old**, so a heap dump is not one undifferentiated blob.

This is the mechanism behind a classic production failure: a class-loader leak in a redeployed application loads new class metadata every deploy, Metaspace grows, and the JVM dies with OutOfMemoryError: Metaspace exhausted even though the heap is barely used.

The heap is split by object age, which is the central insight behind Java's garbage collection performance.

YOUNG GENERATION                OLD GENERATION
  ┌──────────────┐                ┌──────────────────┐
  │ Eden         │ ────────────> │                  │
  │ (new objects)│ survivors     │ long-lived       │
  └──────────────┘ promoted      │ objects          │
  ┌──────────────┐                │                  │
  │ Survivor     │

The reasoning is about cost. Most objects die young, so collecting a small young generation frequently and cheaply reclaims most garbage. Objects that survive several collections get promoted to old, where they are collected rarely. The generational hypothesis works because if most objects die young, then young objects die at a high rate, and collection cost is proportional to the *surviving* set, which is small.

The generational design has a practical consequence worth knowing: **minor and major collections are very different events.** A minor collection touches only the young generation and is fast, while a major or mixed collection traverses the old generation and can pause for tens or hundreds of milliseconds.

This is the part where Java stops being interpreted, and it is the reason a Java program gets faster the longer it runs.

The interpreter executes bytecode immediately, which gives fast startup and immediate correctness. The JIT compiler watches for hot methods and compiles those to native code. On modern HotSpot there are two tiers: **C1** compiles quickly with modest optimization for short-running code, and **C2** applies aggressive optimizations for long-running hot code. Compilation happens in a background thread, so it does not simply stop the application.

bytecode method invoked
            │
            v
     interpreter runs it          startup is fast
            │
            v  threshold crossed (e.g. ~10k invocations)
            │
      C1 compiles ──> moderately optimized native code
            │
      hotter still
            v
      C2 compiles ──> aggressively optimized native code
            │              (loop unrolling, inlining, escape analysis)
            v
       native code: much faster

The JEPs this added up to is worth stating plainly. **HotSpot is not purely interpreting, and "Java is interpreted" is false.** What is true is subtler and more interesting: Java has a two-tier execution model, starts interpreted, and progressively replaces itself with native code as it learns which methods matter. A long-running server has mostly stopped being Java by the JIT's own standards.

This is also where **escape analysis** earns its place. The JIT can prove that an object never escapes its method and eliminate the allocation entirely, which is why tight loops in Java can sometimes match hand-written C. It is an optimization, not a guarantee, and you cannot rely on it.

The per-thread stack is finite, and exceeding it is an Error, not an Exception, which matters because catch (Exception e) will not catch it.

The example measures exactly where the boundary falls:

StackOverflowError after 21259 frames

The number varies with stack size and frame complexity, but the mechanism does not. Each recursive call pushes a frame; the stack fills; the JVM throws rather than growing without bound, because unbounded stack growth would eventually exhaust native memory unpredictably.

static int frames = 0;
static void recurse() {
    frames++;
    recurse();
}try {
    recurse();
} catch (StackOverflowError e) {
    // Error, not Exception
    System.out.println("gave up after " + frames + " frames");
}

The practical note is that deep recursion in Java is usually a design signal. In tail-recursive algorithms, an explicit stack or an iterative loop is clearer and does not risk the boundary.

Java's collectors use **reachability**, not reference counting. An object is garbage when it is unreachable from the roots, which are static fields, the stack of live threads, and JNI references. This is why cycles are collected correctly: two objects referencing only each other, and unreferenced from anywhere else, are still garbage.

class Node {
    Node next;
}// A cycle. Reference counting would never free this.
// Reachability collects it immediately.
Node a = new Node();
Node b = new Node();
a.next = b;
b.next = a;
a = b = null;
// both now unreachable -> collected

Generational collection follows from this. New objects go to Eden, and when Eden fills, a minor collection promotes survivors to Survivor and then to Old. The example for this topic produced real collector data under memory pressure:

G1 Young Generation collections=4 time=2 msG1 Old Generation collections=0 time=0 ms-- after System.gc() --G1 Old Generation collections=1 time=3 ms

Read that carefully: the young generation collected four times while old collected zero. That is the generational design working exactly as described, reclaiming short-lived garbage without ever touching the old generation.

The default flags matter because they are why behaviour differs between environments, and two are worth knowing by sight.

-Xint is a genuine diagnostic tool rather than a curiosity. Disabling the JIT isolates bugs that only appear in compiled code, because bytecode and native code do not fail in identical ways. It also makes the program dramatically slower, which is the trade.

Setting -Xms equal to -Xmx is standard practice and is not merely cosmetic. Resizing the heap at runtime is expensive, and fixing the size avoids that work entirely.

The JVM provides real guarantees, and the important part is being precise about their boundaries.

That second-to-last row deserves emphasis because it is a common and outdated claim. The SecurityManager was the basis for describing Java as a sandboxed language, and it is deprecated for removal as of Java 17. On JDK 17 System.setSecurityManager still succeeds, but only after printing a terminally-deprecated warning. Real isolation now comes from containers, separate processes, or the module system, not from an in-process security manager.

Walking one class from source to execution, the three subsystems each do their part. javac produces Foo.class with a magic number and a class file version. The ClassLoader subsystem reads those bytes, and the verifier rejects the class if the structure is unsound, which is the moment the safety guarantee is established. Loading allocates the class into Metaspace, off-heap and not covered by -Xmx. First call executes through the interpreter, which makes startup fast, and once the method is hot the JIT compiles it to native code via C1 and then C2. Objects created along the way live on the heap and are reclaimed by reachability, never by reference counting, and the call stack that got us there is a per-thread structure with a hard ceiling, proven here by a StackOverflowError after 21259 frames.

The point of the three-subsystem decomposition is that it turns runtime failures into specific, locatable areas. ClassFormatError is a class-loading problem. OutOfMemoryError: Metaspace is a leak or a missing flag. StackOverflowError is recursion depth. Unexpected GC pauses are an execution-engine or heap-sizing issue. Knowing the map is most of what debugging a JVM problem requires.