JVM & Platform Architecture

At runtime, four subsystems interact in a fixed logical order—this is the diagram worth memorizing:

  YOUR CODE (.java → .class bytecode)
              │
              ▼
┌─────────────────────────────────────────────────────────────────┐
│  ① CLASS LOADER SUBSYSTEM                                       │
│     Bootstrap → Platform → Application (+ custom loaders)       │
│     Load · Link (verify, prepare, resolve) · Initialize         │
└────────────────────────────┬────────────────────────────────────┘
                             │ types & metadata stored in
                             ▼
┌─────────────────────────────────────────────────────────────────┐
│  ② RUNTIME DATA AREAS                                           │
│     Heap (objects) · Metaspace (class metadata)                 │
│     Per-thread: Java stack, PC register, native method stack    │
└────────────────────────────┬────────────────────────────────────┘
                             │ bytecode executed by
                             ▼
┌─────────────────────────────────────────────────────────────────┐
│  ③ EXECUTION ENGINE                                             │
│     Interpreter · JIT (C1 / C2) · GC threads · runtime stubs      │
└────────────────────────────┬────────────────────────────────────┘
                             │ JNI calls into
                             ▼
┌─────────────────────────────────────────────────────────────────┐
│  ④ NATIVE METHOD INTERFACE (JNI)                                │
│     C/C++ libraries, OS APIs, GPU drivers, compression codecs     │
└─────────────────────────────────────────────────────────────────┘

What each layer does in production

• Class loaders — bring types into the VM; wrong loader boundaries cause ClassNotFoundException, LinkageError, and Metaspace leaks on redeploy.
• Runtime data areas — where object graphs (heap), per-thread call state (stacks), and class metadata (Metaspace) live; OOM types tell you which area failed.
• Execution engine — interprets cold bytecode, JIT-compiles hot paths, runs GC; CPU profiles and pause times originate here.
• JNI / native — every I/O, clock, and crypto call eventually hits native code; JNI misuse can corrupt heap or leak native memory outside GC’s view.

The three phases

Bootstrap → Platform → Application

JDK 8 and earlier documentation used “Extension class loader”; JDK 9+ module system renamed concepts but the delegation idea persists.

Delegation model (parent-first)

When asked to load com.example.PaymentService, the application loader first delegates to its parent (platform), which delegates to bootstrap. Only if parents cannot find the class does the child define it.

Application ClassLoader  "com.example.Foo?"
        │  not found in parent chain for com.example.*
        ▼
Platform ClassLoader     (delegates upward first)
        ▼
Bootstrap ClassLoader    java.* only
        │
        └──► returns java.lang.String if already loaded

Child defines com.example.Foo only when parents pass.

Why it matters: You cannot replace java.lang.String from a malicious JAR on the classpath—bootstrap already defined the real one. Containers sometimes use child-first (inverse) for servlet isolation so webapp copies of libraries win over shared ones—powerful but easy to misconfigure.

Dynamic class loading

Classes appear after startup through:

• Reflection — Class.forName("com.plugin.Rule") triggers loading if absent.
• Bytecode generation — Hibernate, Mockito, Spring CGLIB create synthetic subclasses at runtime.
• Agents — -javaagent: transforms classes at load time (metrics, tracing).
• Custom loaders — OSGi, plugin architectures, URLClassLoader over HTTP (rare, security risk).

// Context class loader — critical in thread pools + EE containers
ClassLoader previous = Thread.currentThread().getContextClassLoader();
try {
    Thread.currentThread().setContextClassLoader(myPluginLoader);
    Class<?> plugin = Class.forName("com.vendor.Plugin", true, myPluginLoader);
    Runnable task = (Runnable) plugin.getDeclaredConstructor().newInstance();
    task.run();
} finally {
    Thread.currentThread().setContextClassLoader(previous);
}

Stored per loaded class (not per object instance):

• Full bytecode of methods, field/method tables, inner class tables
• Runtime constant pool (strings, class references, method handles)
• Annotations visible to reflection (unless stripped by ProGuard)
• vtable / itable structures for virtual dispatch

Metaspace grows by committing native memory in chunks. Limits:

-XX:MetaspaceSize=256m          # initial commit threshold (triggers GC earlier)
-XX:MaxMetaspaceSize=512m       # hard cap — ClassLoader.defineClass fails beyond this
-XX:+TraceClassLoading          # verbose — dev/troubleshooting only

                    HEAP ( -Xmx caps total )
    ┌──────────────────────────────────────────────────────────┐
    │  YOUNG GENERATION                                         │
    │  ┌─────────────────────────────────────────────────────┐ │
    │  │  EDEN  — every new object starts here (TLAB bump)    │ │
    │  └─────────────────────────────────────────────────────┘ │
    │         │ minor GC (copying) when Eden full              │
    │         ▼                                                │
    │  ┌──────────────┐    copy live objects    ┌──────────────┐ │
    │  │ Survivor S0  │ ◄──────────────────────► │ Survivor S1  │ │
    │  │  (empty swap)│      age++ each survive │              │ │
    │  └──────────────┘                         └──────────────┘ │
    └────────────────────────────┬─────────────────────────────┘
                                 │ age > TenuringThreshold (e.g. 15)
                                 ▼ promotion
    ┌──────────────────────────────────────────────────────────┐
    │  OLD GENERATION — long-lived caches, singletons, pools   │
    │  major / mixed / full GC collects here                    │
    └──────────────────────────────────────────────────────────┘

Object allocation lifecycle

1. TLAB allocation — each thread bumps a pointer in a Thread-Local Allocation Buffer in Eden (fast path, lock-free).
2. Eden fill — when Eden cannot fit the object, a minor GC (Young collection) runs.
3. Copy collection — live objects copied to the empty survivor space; dead objects vanish (no sweep in young gen).
4. Aging — each survivor round increments age; when age ≥ threshold, object is promoted to Old Gen.
5. Old Gen pressure — long-lived graphs (caches, HTTP client pools, static collections) fill Old; collector runs concurrent or STW phases depending on algorithm.

Object layout (HotSpot 64-bit, compressed oops on): mark word + klass pointer + fields; arrays add length. Alignment padding affects footprint—why “small objects” still cost 16+ bytes.

A frame contains:

• Local variable array — fixed-size table: parameters, int i, reference variables, long/double take two slots.
• Operand stack — bytecode is stack-oriented: iload_1, iload_2, iadd pops two ints, pushes sum.
• Constant pool reference — for instructions like ldc, invokevirtual.
• Return address — where to continue after return (used by interpreter/JIT).

int add(int a, int b) {
    return a + b;
}
// Compiled bytecode conceptually:
//   iload_1, iload_2, iadd, ireturn
// Frame locals: [this?] a b  (static methods omit this)

Default stack size -Xss (often 1 MB per thread on Linux). A service with 500 platform threads ≈ 500 MB stack alone—virtual threads (Java 21) shrink this cost for I/O workloads.

PC (program counter) register

Per thread, holds the address of the current bytecode instruction being executed. After an instruction completes, the PC advances. If the thread is running native code (JNI), the PC is undefined—native code uses real CPU program counters on the native stack.

Native method stack

When you call System.arraycopy or socket I/O, HotSpot may enter an intrinsic or JNI implementation written in C++. That execution uses the native method stack (often the same pthread stack as the Java stack on HotSpot, interleaved). Native allocations are invisible to Java heap GC—memory leaks in JNI malloc require native profilers.

Interpreter → C1 → C2

Tiered compilation (-XX:+TieredCompilation, default on server): methods start interpreted, get C1 quickly for speed, then “upgrade” to C2 when hot enough. Short-lived CLI apps may never reach C2.

Warm-up and thresholds

• -XX:CompileThreshold — invocations before C2 compile (default tiered uses complex counters, not one number).
• OSR (On-Stack Replacement) — compile hot loops inside cold methods (loop in rarely called handler).
• Deoptimization — rare path assumption fails (e.g. class hierarchy change) → fall back to interpreter, fix assumptions, maybe recompile.

# Code cache — OutOfMemoryError: CodeCache if too small
-XX:ReservedCodeCacheSize=256m
-XX:InitialCodeCacheSize=64m

# Observe compilations (example output)
#   123    4   !   3   java.util.HashMap::getNode  (bytes,code) type level

java -XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions \
     -XX:CompileCommand=print,com.example.HotPath::process

GC roots & reachability

Root set (starting points for tracing)—if there is no path from any root to an object, it is garbage:

• Local variables and operand stacks of active stack frames (per thread)
• Static fields of loaded classes
• JNI global references (native code holding Java objects)
• Objects used as monitors for synchronized
• JVM internal tables (JNI handles, code cache oops, etc.)

Mark-and-sweep (foundation)

Mark: traverse from roots, set mark bit on reachable objects (tri-color abstraction: white/grey/black in concurrent collectors). Sweep: walk heap, free unmarked objects—creates fragmentation in old gen. Production collectors add copying (young gen eliminates fragmentation) and compaction (slide live objects, update references).

Collector reference

Minor GC vs Major GC vs Full GC

• Minor GC / Young GC — collects Eden + survivors (all algorithms). Frequency high; duration often milliseconds on healthy heaps.
• Major GC / Old GC — old generation collection. With G1, often appears as “Mixed” evacuation of old regions with garbage.
• Full GC — stop-the-world collection of entire heap (and often class unloading). Triggers: Metaspace pressure, System.gc(), heap exhaustion, promotion failure. P99 killers—minimize frequency.

Promotion failure: Survivors cannot hold all live objects after minor GC → objects promoted to fragmented old gen → triggers full GC. Sign of survivor sizing, allocation burst, or old gen too full.

Essential JVM flags

# Production-style G1 logging (Java 9+ unified JVM logging)
java -Xms4g -Xmx4g \
     -XX:+UseG1GC \
     -XX:MaxGCPauseMillis=200 \
     -XX:+HeapDumpOnOutOfMemoryError \
     -Xlog:gc*,gc+age=trace:file=gc-%t.log:time,uptime,level:filecount=5,filesize=50m \
     -jar service.jar

# ZGC example (Java 21)
java -XX:+UseZGC -Xms8g -Xmx8g -Xlog:gc*:file=gc.log -jar service.jar

Reading GC log lines

Young collection (G1):

[2.145s][info][gc] GC(12) Pause Young (Normal) (G1 Evacuation Pause)
  [2.145s][info][gc] GC(12) Eden regions: 24->0(20)
  [2.145s][info][gc] GC(12) Survivor regions: 2->3(4)
  [2.145s][info][gc] GC(12) Old regions: 10->10
  [2.145s][info][gc] GC(12) Pause Young (Normal) (G1 Evacuation Pause) 24M->8M(256M) 12.345ms

• Eden regions: 24→0 — Eden evacuated completely.
• 24M→8M(256M) — heap used before → after (committed capacity).
• 12.345ms — STW pause—what hits your API latency for this event.

Mixed GC (G1): collects some old regions with high garbage alongside young—key to G1 old-gen hygiene without full heap pause.

Full GC: log line containing Pause Full — investigate Metaspace, System.gc(), or allocation failure immediately.

Correlate logs with jstat -gcutil <pid> 1000ms: watch O (old) climb toward 100% and FGC count increase.

JDK CLI tools (same JDK as the process)

# Incident capture script (run in same second)
PID=$(jps -l | awk '/com.example.Application/{print $1}')
jstack -l $PID > threads-$(date +%s).txt
jmap -histo:live $PID | head -80 > histo-$(date +%s).txt
jcmd $PID VM.flags > flags.txt
jcmd $PID JFR.start name=incident duration=120s filename=incident.jfr

# Thread dump — look for:
#   java.lang.Thread.State: BLOCKED (on object monitor)
#   "pool-1-thread-3" waiting on java.util.concurrent.locks

jstat -gcutil $PID 1000ms

jconsole

JDK-bundled JMX GUI. Attach to local PID or remote process with JMX ports open. Graphs heap, threads, classes, CPU. Good for quick visual trends; less detail than JFR for deep dives. Enable JMX remotely only with authentication and TLS in production.

VisualVM

Desktop profiler (standalone or via GraalVM downloads). Heap walker, sampler CPU, thread snapshots, heap dump analysis. Compare histograms between two points in time to find leak suspects (objects growing without bound).

async-profiler

Low-overhead sampling profiler using perf_events (Linux/macOS). Produces flame graphs without Safepoint bias that inflates certain JVM stacks. Modes:

• cpu — where CPU time goes (hot methods after JIT)
• alloc — allocation hotspots (who creates byte[]?)
• lock — contended locks

./profiler.sh -d 60 -e cpu -f /tmp/cpu.html <pid>
./profiler.sh -d 60 -e alloc -f /tmp/alloc.html <pid>

Java Flight Recorder (JFR)

Built into OpenJDK. Low overhead when configured (-XX:StartFlightRecording or jcmd JFR.start). Events: GC pauses, socket I/O, method samples, allocation outside TLAB, lock inflation. Analyze in JDK Mission Control (JMC)—timeline correlates GC pause with thread blocked.