JVM Internals — Complete Notes

Hello.java          your source
    |  javac                        <- compiles ONCE, at build time
    v
Hello.class         BYTECODE — platform-independent instructions for the imaginary machine
    |  java Hello
    v
   JVM              loads it, verifies it, runs it
    |  interpreter (immediately)  +  JIT compiler (for the hot parts)
    v
machine code        actual x86 / ARM instructions for THIS CPU

// Source:
int add(int a, int b) { return a + b; }

// javap -c Hello.class  ->
//   0: iload_1        // push local var 1 (a) onto the operand stack
//   1: iload_2        // push local var 2 (b)
//   2: iadd           // pop both, add, push result
//   3: ireturn        // pop and return it

// Note there are no registers — the JVM is a STACK machine. Everything is
// push/pop on an operand stack. That's what makes it portable.

+---------------------------------------------------------------+
|                    1. CLASS LOADER SUBSYSTEM                  |
|      Loading  ->  Linking (Verify/Prepare/Resolve)  ->  Init  |
+---------------------------------------------------------------+
                              |
                              v
+---------------------------------------------------------------+
|                    2. RUNTIME DATA AREAS                      |
|                                                               |
|   SHARED BY ALL THREADS        |    PER-THREAD                |
|  +-------------------------+   |   +----------------------+   |
|  |         HEAP            |   |   |    JVM Stack         |   |
|  |  Young  |     Old       |   |   |  (frames: locals +   |   |
|  | E S0 S1 |               |   |   |   operand stack)     |   |
|  +-------------------------+   |   +----------------------+   |
|  +-------------------------+   |   +----------------------+   |
|  |  Metaspace (native mem) |   |   |   PC Register        |   |
|  |  class metadata         |   |   +----------------------+   |
|  +-------------------------+   |   +----------------------+   |
|  +-------------------------+   |   |  Native Method Stack |   |
|  |  Code Cache (JIT output)|   |   +----------------------+   |
|  +-------------------------+   |                              |
+---------------------------------------------------------------+
                              |
                              v
+---------------------------------------------------------------+
|                    3. EXECUTION ENGINE                        |
|      Interpreter   |   JIT Compiler (C1/C2)   |   GC          |
+---------------------------------------------------------------+
                              |
                    JNI  ->  Native libraries

1. LOADING
     Find Foo.class (disk / jar / network), read the bytes,
     create a java.lang.Class object representing it. Metadata -> Metaspace.

2. LINKING
     a. VERIFICATION   — is this bytecode legal and safe? (no stack overflows, valid types,
                          no jumping into the middle of an instruction). This is why the JVM
                          can safely run untrusted bytecode. Also why it rejects a corrupt .class.
     b. PREPARATION    — allocate static fields and set them to DEFAULT values.
                          static int x = 5;  ->  x becomes 0 here. NOT 5. Not yet.
     c. RESOLUTION     — turn symbolic references ("the class named com.Foo") into direct
                          references (a pointer). May be lazy — often deferred to first use.

3. INITIALIZATION
     Run the static initialisers and static field assignments, in source order —
     the compiler bundles them into a method called <clinit>.
     NOW  static int x = 5;  actually assigns 5.

class Holder {
    static { System.out.println("Holder initialised"); }
    static int VALUE = 42;
    static final int CONSTANT = 99;         // compile-time constant!
}

// TRIGGERS initialization:
new Holder();                  // instantiating
Holder.VALUE;                  // reading a non-final static
Holder.someStaticMethod();     // calling a static method
Class.forName("Holder");       // reflection (by default)

// Does NOT trigger it:
Holder[] arr = new Holder[10];  // creating an array of them
Holder.CONSTANT;                // static final with a constant initialiser is INLINED by javac
                                // at compile time — the class is never even loaded!
Sub.inheritedStaticField;       // only the DECLARING class is initialised, not the subclass

Bootstrap ClassLoader        (written in C++, shows as `null` from Java)
    |                        loads the core JDK: java.lang.*, java.util.*  (java.base module)
    v
Platform ClassLoader         (called "Extension" before Java 9)
    |                        loads JDK modules that aren't core
    v
Application ClassLoader      loads YOUR classes from the classpath / modulepath
    |
    v
(your own custom loaders — Tomcat, Spring Boot, OSGi, plugin systems)

// When asked to load "com.example.Foo", a loader:
//   1. Have I already loaded it? -> return the cached Class
//   2. Ask my PARENT to load it  -> recursion, all the way to Bootstrap
//   3. Only if every ancestor failed do I try to load it myself

System.out.println(String.class.getClassLoader());        // null  -> Bootstrap
System.out.println(MyClass.class.getClassLoader());       // jdk...AppClassLoader

void method() {
    int x = 5;                          // the VALUE 5 -> stack (primitive local)
    String s = "hello";                 // the REFERENCE -> stack; the String object -> heap (pool)
    Person p = new Person("Ann");       // the REFERENCE p -> stack; the Person OBJECT -> heap
    int[] a = new int[1000];            // reference -> stack; the 1000-int array -> heap
}
// When method() returns, its whole frame is popped:
//   x, s, p, a all vanish instantly — no GC involved.
//   The Person and int[] on the heap are now unreachable, and become GC's problem.

main() calls a(), which calls b():

        |  b()'s frame   |  <- top: local variable array, operand stack, return address
        |  a()'s frame   |
        |  main()'s frame|
        +----------------+
// Each call PUSHES a frame; each return POPS it.
// Infinite recursion = push forever = StackOverflowError.
// This stack of frames is EXACTLY what gets printed as a stack trace.

GC ROOTS (the starting points, definitionally alive):
  - local variables & parameters in every live thread's stack frames
  - static fields of loaded classes
  - active threads themselves
  - JNI references from native code
  - objects used as monitors (locked)

Then: mark everything reachable from a root, transitively.
      Everything NOT marked is garbage — no matter how many references
      those garbage objects hold to EACH OTHER.

class Node { Node other; }

void f() {
    Node a = new Node();
    Node b = new Node();
    a.other = b;
    b.other = a;      // circular reference
}
// After f() returns: a and b are gone from the stack. Nothing reaches either node.
// BOTH are collected. The cycle is irrelevant.

+---------------------------------------------------+----------------------+
|                  YOUNG GENERATION                 |    OLD GENERATION    |
|                                                   |      (Tenured)       |
|  +-------------------+  +--------+  +--------+    |                      |
|  |       Eden        |  |   S0   |  |   S1   |    |  long-lived objects  |
|  |  new objects here |  |survivor|  |survivor|    |                      |
|  +-------------------+  +--------+  +--------+    |                      |
+---------------------------------------------------+----------------------+
        ~80%                 ~10%       ~10%              usually ~2/3 of heap

Minor GC (frequent, fast)  ------^                   Major/Full GC (rare, slow) --^

1. `new Foo()`            -> allocated in EDEN (just bump a pointer — allocation is nearly free)

2. Eden fills up         -> MINOR GC ("young collection"):
                              - mark live objects in Eden + the in-use survivor space
                              - COPY the survivors to the OTHER survivor space, age += 1
                              - wipe Eden and the old survivor space ENTIRELY — instantly
                              - S0 and S1 swap roles

   Key insight: cost is proportional to how many objects SURVIVE, not how many died.
   If 99% of Eden is garbage, a minor GC is almost free. Dead objects cost nothing.

3. Survives ~15 minor GCs (-XX:MaxTenuringThreshold) -> PROMOTED to the Old generation

4. Old generation fills   -> MAJOR / FULL GC: expensive, may pause everything

Also: an object too big for Eden is allocated straight into Old ("humongous" in G1).

1. MARK     — walk from the GC roots, flag everything reachable.
              Cost is proportional to LIVE data.

2. SWEEP    — reclaim everything unmarked.
              Fast, but leaves the heap full of holes -> FRAGMENTATION.
              You can then have 500MB free and still fail to allocate a 1MB array.

3. COMPACT  — slide the survivors together so free space is one contiguous block.
              Expensive (objects move, so every reference must be updated),
              but makes the next allocation a simple pointer bump.

The young generation instead uses COPYING: survivors are copied out and the whole
region is wiped. Compaction is a free side effect — which is why minor GCs are so cheap.

+---+---+---+---+---+---+---+---+
| E | O | S | E | O | O | H | E |    ~2048 regions, each 1-32MB
+---+---+---+---+---+---+---+---+
| O | E | O | S | E | O | E | O |    E=Eden  S=Survivor  O=Old  H=Humongous
+---+---+---+---+---+---+---+---+

// A region's ROLE is dynamic — young and old are just labels, not fixed address ranges.
// G1 tracks how much garbage each region holds, then collects the FULLEST-OF-GARBAGE
// regions first. Hence "Garbage First".
//
// Crucially, it collects only AS MANY regions as fit in your pause budget:
-XX:MaxGCPauseMillis=200          // "keep pauses under 200ms" — a goal, not a guarantee

void recurse() { recurse(); }      // no base case -> frames pile up -> boom
recurse();
// Exception in thread "main" java.lang.StackOverflowError
//     at Main.recurse(Main.java:3)
//     at Main.recurse(Main.java:3)
//     ... the same line, thousands of times

// Real-world causes:
//  - a missing/incorrect recursion base case
//  - accidental mutual recursion: a() -> b() -> a()
//  - toString() calling itself:  return "Foo" + this;   // implicit this.toString()
//  - equals()/hashCode() recursing through a cyclic object graph
//  - a genuinely too-deep (but correct) recursion on a deep tree

// -Xss2m   raises the per-thread stack size.
// This is a legitimate fix ONLY when the recursion is correct and genuinely deep.
// For a bug, raising it just means the crash takes slightly longer.
//
// Note: Java has NO tail-call optimisation. A tail-recursive method still
// pushes a frame per call. Deep recursion must be rewritten as a loop
// with an explicit ArrayDeque as your stack.

class Cache {
    private static final Map<String, byte[]> CACHE = new HashMap<>();   // static = a GC ROOT

    public static void put(String k, byte[] v) {
        CACHE.put(k, v);     // nothing is ever removed. This map is reachable forever.
    }
}
// Every entry is permanently reachable from a root, so GC can never touch it.
// Java "can't leak" only in the C sense — you can absolutely retain objects forever.

// Fixes: an eviction policy (Caffeine, Guava), a bounded LinkedHashMap with
// removeEldestEntry, or WeakHashMap if the key's lifetime should drive it.

// 1. Listeners you register and never remove
button.addListener(this);      // the button now holds `this` forever

// 2. ThreadLocal in a thread pool — the thread never dies, so the value never clears
private static final ThreadLocal<BigThing> TL = new ThreadLocal<>();
TL.set(big);                   // must TL.remove() in a finally!

// 3. Unclosed resources holding native memory
// 4. A HashMap key whose hashCode changes after insertion -> the entry is
//    unreachable by lookup but still strongly referenced by the map

Level 0: INTERPRETER   — execute bytecode directly. Starts instantly, ~20x slower.
                         Counts invocations and loop iterations as it goes.
   |  called often enough
   v
Level 1-3: C1 (client)  — compile fast, optimise lightly. Good code in milliseconds.
                          Also inserts PROFILING counters (which branches? which types?).
   |  still hot (~10,000 invocations)
   v
Level 4: C2 (server)    — compile slowly, optimise aggressively, USING that profile data.
                          This is the code that runs at "Java speed" — often at or near C.

// INLINING — the most valuable optimisation, because it enables all the others
int getX() { return x; }
int sum = getX() + getX();      // becomes: int sum = x + x;  — the calls vanish entirely

// MONOMORPHIC DISPATCH — profile says this call site only ever saw ArrayList,
// so devirtualise the interface call into a direct one (with a type guard).
for (Object o : list) { ... }

// ESCAPE ANALYSIS + SCALAR REPLACEMENT — this object never leaves the method,
// so don't allocate it at all; keep its fields in registers.
Point p = new Point(1, 2);
return p.x + p.y;               // becomes: return 1 + 2;  -> return 3;  and nothing is allocated

// Plus: dead code elimination, loop unrolling, constant folding,
// lock elision (removing locks on provably thread-confined objects)

# --- sizing ---
-Xms2g                      # initial heap. Set it EQUAL to -Xmx in production:
-Xmx2g                      #   avoids pause-inducing resizes and pre-commits the memory
-Xss1m                      # per-thread stack size
-XX:MaxMetaspaceSize=256m   # cap metaspace so a classloader leak fails fast

# --- collector ---
-XX:+UseG1GC                # default since 9
-XX:MaxGCPauseMillis=200    # G1's pause goal

# --- diagnostics: ALWAYS set these in production ---
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/var/log/app/heap.hprof
-Xlog:gc*:file=/var/log/app/gc.log:time,uptime:filecount=5,filesize=10M   # Java 9+ unified logging

# --- containers (Java 10+, on by default) ---
-XX:MaxRAMPercentage=75.0   # use 75% of the CONTAINER limit, not the host's RAM
                            # Use this instead of -Xmx in Kubernetes.

jps                          # list running JVMs and their pids
jstat -gc <pid> 1s           # live GC stats every second — is it collecting constantly?
jstack <pid>                 # thread dump — hangs, deadlocks (it detects them for you)
jmap -histo <pid>            # object histogram: what's on the heap, by count and bytes
jmap -dump:live,format=b,file=heap.hprof <pid>    # full heap dump
jcmd <pid> VM.native_memory  # off-heap usage (needs -XX:NativeMemoryTracking=summary)
jcmd <pid> GC.heap_info

# Then open heap.hprof in Eclipse MAT: "Leak Suspects" report usually names the culprit outright.
# For CPU/allocation profiling: Java Flight Recorder (JFR) — near-zero overhead, ships with the JDK
jcmd <pid> JFR.start duration=60s filename=rec.jfr

HEALTHY — used memory drops back to the same floor every collection:
  used |    /|    /|    /|    /|
       |   / |   / |   / |   / |
       |__/__|__/__|__/__|__/__|____
       floor stays flat -> the live set is constant. This is just normal garbage.

LEAKING — the floor climbs after every full GC:
  used |      /|     /|    /|   /|
       |    _/ |   _/ |  _/ | _/ |
       |  _/   | _/   |_/   |/   |
       |_/_____|/_____|_____|____|__
       floor rising -> something is retained forever -> OOM is coming. Heap dump now.