A technical story for a kid who speaks Java fluently
Narrator (you): The terminal blinks. You type:
java -Xms256m -Xmx2g -server MyGameAnd press Enter.
Kid: That’s it? That’s when the magic starts?
You: 🔥 That’s when the JVM is born.
🌅 Phase 1: Birth — JVM Startup
The OS loads the JVM executable (java → libjli.dylib/jli.dll → libjvm.so) into memory.
✅ JVM Initialization begins:
- Allocates process memory (heap, metaspace, thread stacks, native memory).
- Parses VM flags:
-
-Xms256m: "Reserve 256 MB right now for the heap." -
-Xmx2g: "But you *may grow up to 2 GB — ask the OS nicely."* -
-server: "Use the Server VM — C2 JIT, parallel GC, biased locking… we’re in for the long haul."
-
➡️ HotSpot VM (Oracle’s implementation) boots its internal subsystems:
-
Threads: Creates the main thread, compiler threads (
C1,C2), GC threads (e.g., G1 concurrent mark), service threads. - Memory Managers: Sets up heap regions (for G1: 2048 regions, ~1 MB each), metaspace (native memory for class metadata), code cache (for JIT’d native code).
-
Runtime: Initializes
java.lang.System,java.lang.Thread, signal handlers.
Kid: Wait — no classes yet?
You: None! Just the machine is ready. Now… it needs its first instruction.
📜 Phase 2: The Quest Begins — Loading MyGame
The JVM now must run MyGame.main(String[]).
But MyGame.class is just a file — a binary container in the *class file format* (per JVM Spec §4).
🔁 Class Loading: Delegation in Action
Application Class Loader says:
“I’m in charge ofMyGame. But first — ask my parent.”
→ Delegates to Extension Class Loader.Extension CL says:
“Not injre/lib/ext? Then ask *my parent.”*
→ Delegates to Bootstrap Class Loader.-
Bootstrap CL (native, written in C):
→ Scansjre/lib(e.g.,rt.jar, nowmodulesin JDK 9+).
→ Loads core:java/lang/Object.class,java/lang/Class.class,java/lang/String.class, …
→ Builds their in-memory representations:-
Klass*structures (C++ objects inside HotSpot) - Method tables, vtables, constant pools
- Links
Object→Class→ClassLoader
-
-
Now back down:
- Extension CL loads any JCE providers, etc.
-
Application CL finally loads
MyGame.classfrom the classpath.
🔍 Deep Dive Moment:
The.classfile is parsed into:
magic: 0xCAFEBABE✅minor/major version(e.g., 61.0 = Java 17)constant_pool[]: 50 entries —#1 = Methodref: java/lang/Object."<init>":()V,#15 = Utf8: "Hello", etc.fields[],methods[],attributes[](likeCode,LineNumberTable)
🧪 Phase 3: Linking — Making Sense of the Scroll
Now MyGame is loaded — but not yet trusted.
Step 1: Verification (Bytecode Verifier — Type 2)
The JVM checks:
- No jumps into the middle of instructions.
- Stack maps: “At instruction 12, stack must be [I, Ljava/lang/String;]”
- No
getfieldonnull. No type mismatches. → If fails?java.lang.VerifyError— “This scroll is cursed!”
Step 2: Preparation
- Allocates memory for static fields:
static int score = 0; // ← set to 0 (default)
static String name; // ← set to null
→ Stored in the static field section of the InstanceKlass.
Step 3: Resolution
For every symbolic reference in the constant pool:
-
#23 = Class: GameEngine→ resolve to actualKlass*(triggers loading GameEngine! — recursive!) -
#25 = Methodref: GameEngine.start:()V→ resolve to method holder + vtable index.
🔁 This may cascade: loading GameEngine → loads Player → loads java/util/ArrayList → … until the entire dependency tree is linked.
Kid: So linking can load more classes?
You: Yes! Like pulling one thread — the whole sweater unfolds.
✨ Phase 4: Initialization — The First Spark
Now the JVM calls:
MyGame.<clinit>() // class initializer
- Executes static initializers in textual order:
static {
score = 100;
name = "Hero";
engine = new GameEngine(); // ← triggers *GameEngine.<clinit>* and *GameEngine.<init>*
}
➡️ Objects are born in the heap:
-
new GameEngine()→- Allocates raw memory (TLAB — Thread-Local Allocation Buffer, fast path!)
- Zeroes fields
- Sets
klasspointer (metadata) - Runs
<init>(constructor)
Heap layout (simplified HotSpot):
[ Mark Word (64b) | Klass Pointer (compressed oop) | fields… ]
🔍 Fun Fact:
If heap is full and no GC can recover space during allocation?
→OutOfMemoryError: Java heap space— even before main() starts!
🏃 Phase 5: Running main() — The Engine Ignites
Finally — the JVM invokes:
MyGame.main({}) // String[] args = empty
➡️ A new frame is pushed onto the main thread’s Java Stack.
Frame layout:
[ Local Variables (0: args ref) ]
[ Operand Stack (empty) ]
[ Frame Data (return PC, previous frame pointer) ]
Now the Execution Engine takes over.
First, the Interpreter runs bytecode:
0: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
3: ldc #3 // String "Game starting..."
5: invokevirtual #4 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
...
Each instruction:
- Pops values from operand stack
- Does work (e.g., resolve field, call method)
- Pushes results back
It’s safe. It’s portable. It’s… slow.
But the JVM is watching.
🚀 Phase 6: JIT Compilation — The Speed Awakening
The HotSpot (profiling data) notices:
- Method
GameLoop.update()called >10,000 times (default-XX:CompileThreshold=10000) - Backedge count (loop iterations) in
render()exceeds 15,000
➡️ The C1 Compiler (Client, fast compile) kicks in:
- Compiles
update()to optimized native x86-64/ARM64 - Inserts safepoints (polling points for GC/stopping threads)
- Stores result in Code Cache
Later, if update() is still hot — C2 Compiler (Server, slow but ultra-optimized) recompiles it:
- Inlines
Player.move()→Vector.add() - Eliminates bounds checks (if proven safe)
- Reorders memory ops
- Uses CPU registers aggressively
Now, future calls to update() jump directly into native code — no interpretation.
📊 Code Cache fills up?
→ If-XX:+ReservedCodeCacheSizeis too small?CodeCache is full. Compiler has been disabled.⚠️
Performance drops — interpreted again.
🗑️ Phase 7: Garbage Collection — The Silent Guardian
While the game runs, objects pile up in the Eden (young gen):
-
new Particle(),new TemporaryBuffer(), etc.
When Eden fills → Minor GC (Young Collection):
- Stop-The-World (briefly!)
- Mark: Find all live objects (roots: stack frames, statics, JNI refs)
- Copy: Survivors → Survivor Space (S0/S1, from/to toggling)
- Promote: Old enough? → Old Gen (Tenured)
After many cycles — Old Gen fills → Major GC / Mixed GC (G1):
- Concurrent marking phase (runs while app runs!)
- Then Mixed GC: cleans young + some old regions (chosen by “garbage %” heuristic)
- Compacts memory to avoid fragmentation
🕰️ Pause times?
- G1 aims for
-XX:MaxGCPauseMillis=200(default)- ZGC/Shenandoah? Sub-millisecond — no stop-the-world! (but newer, not default)
🧩 Phase 8: Native Calls — Opening the Door
At some point:
static { System.loadLibrary("sound"); }
native void playExplosion();
➡️ JVM uses JNI:
- Looks for
libsound.so(Linux),sound.dll(Windows) - Resolves
Java_MyGame_playExplosionsymbol - On call:
- Transitions thread to _thread_in_native state
- Jumps to native code (via
call stub) - Native code runs — full OS access!
- On return: checks for pending exceptions, safepoint requests
⚠️ If native code crashes? JVM process dies. No try/catch saves you.
🌙 Phase 9: Shutdown — The Final Frame
When main() returns — or System.exit(0) is called:
- Runs shutdown hooks (
Runtime.addShutdownHook()) - Stops all non-daemon threads
- Flushes I/O buffers
- Unloads classes (if possible — rarely done in practice)
- Frees heap, metaspace, code cache
- JVM process exits → OS reclaims all memory.
The castle dims.
The robot chef bows.
The magic — complete.
🎁 Final Recap Map (For the Kid’s Wall)
[Shell]
↓ `java MyGame`
[JVM Process Born]
├─ Memory: Heap (Eden/Survivor/Old), Metaspace, Code Cache
├─ Threads: main, GC, Compiler, Service
└─ Subsystems Initialized
[Class Loading Chain]
Bootstrap → Extension → Application → MyGame
[Linking]
Verify → Prepare → Resolve (cascading!)
[Initialization]
<clinit> → static blocks → new objects (Heap!)
[Execution]
Interpreter → (HotSpot) → C1 JIT → C2 JIT
[Memory Management]
TLAB alloc → Minor GC → Promotion → Mixed GC → Compaction
[Native World]
JNI → libsound.so → _thread_in_native → return
[Shutdown]
Hooks → Cleanup → Exit
Ascii Map
┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ USER SHELL │
│ $ java -Xms512m -Xmx4g -server -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:+PrintGCDetails -XX:+PrintCompilation MyGame │
└───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┬────────────────┘
▼
┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ JVM PROCESS (HotSpot) — BORN │
│ ┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │
│ │ Native OS Layer (C/C++) │ │
│ │ • libjvm.so (Linux), jvm.dll (Win), libjvm.dylib (macOS) loaded by OS loader │ │
│ │ • Threads created at startup: │ │
│ │ - main (JavaThread) │ │
│ │ - VM threads: VMThread (safepoint coordinator), ConcurrentGCThread (G1ConcMark), CompilerThreads (C1, C2), ServiceThread, WatcherThread │ │
│ │ • Memory layout initialized: │ │
│ │ - Java Heap: 512 MB reserved (G1: divided into ~2048 regions, ~2 MB each) │ │
│ │ - Metaspace: native memory (non-heap) for Klass*, method metadata, annotations │ │
│ │ - CodeCache: segmented (non-nmethod, profiled nmethod, non-profiled nmethod); stores JIT-compiled native code │ │
│ │ - Thread stacks: 1 MB default (adjustable via -Xss) │ │
│ └───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┬────────────────┘ │
│ ▼ |
│ ┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │
│ │ Class Loading Subsystem (Delegation Model) | │
│ │ | │
│ │ ┌──────────────────────────────────────────────────────────────────────────┐ ┌──────────────────────────────────────────────────────────────────────────┐ ┌───────────────────────────────────────────────────────────────────────────────────────┐ │ │
│ │ │ Bootstrap ClassLoader (native, no Java object, parent = null) │ │ Extension ClassLoader (sun.misc.Launcher$ExtClassLoader) │ │ Application ClassLoader (sun.misc.Launcher$AppClassLoader) │ │ │
│ │ │ - Implemented in C inside JVM │ │ - Parent: Bootstrap │ │ - Parent: Extension │ │ │
│ │ │ - Loads core platform classes: │ │ - Loads extensions from jre/lib/ext (or java.ext.dirs) │ │ - Loads application classes from CLASSPATH (dirs, JARs, ZIPs) │ │ │
│ │ │ • java.lang.Object, String, System, Thread... │ │ • e.g., sun.security.provider, javax.* (legacy) │ │ • MyGame.class, com.mygame.Engine.class, lib/game.jar │ │ │
│ │ │ - Sources: jrt:/ (JDK 9+ module system), jre/lib/modules │ │ - Now largely deprecated (replaced by module path) | │ │ │ │
│ │ └──────────────────────────────────────────────────────────────────────────┘ └──────────────────────────────────────────────────────────────────────────┘ └───────────────────────────────────────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ │ Delegation Flow: AppCL → asks ExtensionCL → asks BootstrapCL → if not found, AppCL tries its own URLs (parent-first, but can be bypassed via custom CL) │ │
│ └───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┬──────────────────────────────────────────────────┘ │
│ ▼ │
│ ┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │
│ │ Linking & Initialization (JVM Spec §5) │ │
│ │ │ │
│ │ 1. Verification (Type 2 — at link time) │ │
│ │ • Data-flow analysis verifies: │ │
│ │ - Operand stack consistency (no under/overflow) │ │
│ │ - Type correctness (no putfield on non-ref, no array store exception at runtime) │ │
│ │ - No illegal control flow (e.g., jump into middle of instruction) │ │
│ │ • Failure → java.lang.VerifyError │ │
│ │ │ │
│ │ 2. Preparation │ │
│ │ • Allocate memory for static fields in InstanceKlass │ │
│ │ • Initialize to *default* values: │ │
│ │ int x; → 0, boolean flag; → false, Object ref; → null │ │
│ │ │ │
│ │ 3. Resolution │ │
│ │ • Convert symbolic references in Constant Pool to direct references: │ │
│ │ #3 = Class java/lang/System → Klass* for java.lang.System │ │
│ │ #10 = Field System.out:PrintStream → field offset in Klass │ │
│ │ #22 = Method Game.update:()V → Method* + vtable index │ │
│ │ • May recursively trigger loading/linking of referenced classes │ │
│ │ │ │
│ │ 4. Initialization (<clinit>) │ │
│ │ • Execute static initializers and static blocks *in source order* │ │
│ │ static { score = 100; engine = new GameEngine(); } │ │
│ │ • Object creation: │ │
│ │ - TLAB allocation (fast-path, thread-local) in Eden │ │
│ │ - Header: [Mark Word (64b) | Klass Word (32b compressed oop)] │ │
│ │ - Fields zeroed, then constructor (<init>) executed │ │
│ └───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┬────────────────┘ │
│ ▼ |
│ ┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │
│ │ Runtime Data Areas (JVM Spec §2.5) │ │
│ │ │ │
│ │ ┌───────────────────────────────────────┐ ┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ ┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ │
│ │ │ PC Register (per thread) │ │ Java Stack (per thread) │ │ Heap (shared, GC-managed) │ │ │
│ │ │ • Holds address of current bytecode │ │ • Grows downward │ │ │ │ │
│ │ │ • Undefined for native methods │ │ • Frame created on method entry: │ │ ┌───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ │ │
│ │ │ │ │ [Local Variable Table] + [Operand Stack] + [Frame Data (return PC, prev frame ptr)] │ │ │ Young Generation │ │ │ │
│ │ │ │ └──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┬───────────┘ │ │ ┌──────────────────────────────────────┐ ┌──────────────────────────────────────────────────────────────┐ │ │ │ │
│ │ │ │ ▼ │ │ │ Eden (object allocation) │───▶│ Survivor Space (S0 ↔ S1, copying collection) │ │ │ │ │
│ │ │ │ ┌──────────────────────────────────────────────────┐ │ │ └──────────────────────────────────────┘ └──────────────────────────────────────────────────────────────┘ │ │ │ │
│ │ │ │ │ Method Area (shared, created at JVM start) │ │ │ │ ▲ │ │ │ │
│ │ │ │ │ • Stores per-class structures: │ │ │ ▼ (promotion after ~15 GC cycles) │ │ │ │ │
│ │ │ │ │ - Runtime Constant Pool(per-class symbol tbl)│ │ │ ┌───────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │
│ │ │ │ │ - Field/method metadata │ │ │ │ Old Generation (Tenured) │ │ │ │ │
│ │ │ │ │ - Static field storage │ │ │ │ • Region-based (G1): ~2048 regions, 1–32 MB each │ │ │ │ │
│ │ │ │ │ - JIT-compiled code? No — that’s CodeCache! │ │ │ │ • Mixed GC: collects Eden + selected Old regions (highest garbage ratio) │ │ │ │ │
│ │ │ │ └──────────────────────────────────────────────────┘ │ │ └───────────────────────────────────────────────────────────────────────────────────────────────────────────┘ │ │ │ │
│ │ │ │ │ | │ │ │ │
│ │ │ │ ┌──────────────────────────────────────────────────┐ │ └───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ │ │ │
│ │ │ │ │ Native Method Stacks (per thread) │ │ │ │ │
│ │ │ │ │ • Used when thread is in _thread_in_native state │ └────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ │ │
│ │ │ │ │ • No JVM-enforced limits — OS controls size │ │ │
│ │ └───────────────────────────────────────┘ └──────────────────────────────────────────────────┘ │ │
| | | |
│ └────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ │
│ ▲ |
│ │ |
│ ┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │
│ │ Execution Engine │ │
│ │ │ │
│ │ ┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ |
│ │ │ Interpreter │ │ │
│ │ │ • Bytecode interpreter loop: fetch → decode → execute │ │ │
│ │ │ • Template-based (C++ templates emit assembly for each bytecode) │ │ │
│ │ │ • Slow for hot code, but fast startup, low memory │ │ │
│ │ └───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┬────────────┘ │ │
│ │ │ │ │
│ │ ┌───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────▼────────────────────┐ │ │
│ │ │ JIT Compiler — HotSpot Adaptive Optimization │ │ │
│ │ │ • Profiling: method invocation counters, backedge counters (loops) │ │ │
│ │ │ • Tiered Compilation (default since JDK 8): │ │ │
│ │ │ │ │ │
│ │ │ ┌──────────────────────────────────────────────────────────────┐ ┌───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ │ │
│ │ │ │ C1 Compiler (Client) │───▶ | C2 Compiler (Server) │ │ │ │
│ │ │ │ • Fast compile (~100–300 ms) │ │ • Slow compile (~1–5 sec), high optimization │ │ │ │
│ │ │ │ • Enables profiling (e.g., branch counts) │ │ • Inlining (up to 9 levels), escape analysis, lock elision, vectorization (SIMD), loop unrolling │ │ │ │
│ │ │ │ • Output: profiled nmethods in CodeCache │ │ • Uses Ideal Graph (Sea of Nodes) for global optimization │ │ │ │
│ │ │ │ • Good for client apps, short-lived processes │ │ • Stored in non-profiled CodeCache segment │ │ │ │
│ │ │ └──────────────────────────────────────────────────────────────┘ └───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ │ │ │
│ │ └────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ │ ┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ │
│ │ │ Garbage Collection (G1 Example) │ │ │
│ │ │ • Concurrent Marking Cycle: │ │ │
│ │ │ 1. Initial Mark (STW, piggybacks on Young GC) │ │ │
│ │ │ 2. Concurrent Mark (app threads run) │ │ │
│ │ │ 3. Remark (STW, finishes marking) │ │ │
│ │ │ 4. Cleanup (STW, calculates live bytes per region) │ │ │
│ │ │ • Mixed GC Phase: │ │ │
│ │ │ - After Cleanup, scheduler triggers Mixed GCs │ │ │
│ │ │ - Each pause collects: Eden + *N* Old regions (selected by garbage % heuristic) │ │ │
│ │ │ - Goal: meet -XX:MaxGCPauseMillis (e.g., 100 ms) │ │ │
│ │ │ • Humongous Objects (>50% region size) → allocated in Old directly; cleaned in Remark/Cleanup │ │ │
│ │ └────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ │ │
│ └────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ │
│ ▲ |
│ │ |
│ ┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ |
│ │ Java Native Interface (JNI) │ |
│ │ │ |
│ │ ┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ │
│ │ │ Native Method Libraries │ │ │
│ │ │ • Loaded via System.loadLibrary("sound") → dlopen()/LoadLibrary() → finds libsound.so/dll/dylib │ │ │
│ │ │ • Symbol resolution: Java_MyGame_playExplosion → native void JNICALL Java_MyGame_playExplosion(JNIEnv*, jobject) │ │ │
│ │ │ • Call sequence: │ │ │
│ │ │ 1. Transition thread state: _thread_in_Java → _thread_in_native │ │ │
│ │ │ 2. Call stub jumps to native code │ │ │
│ │ │ 3. Native code runs — full OS access, no GC safepoints │ │ │
│ │ │ 4. On return: check for pending async exceptions, safepoint requests, GC needs │ │ │
│ │ │ • Critical: native code must NOT hold JVM locks across calls; must call JNI functions to access Java objects │ │ │
│ │ └────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ │ │
│ └────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ │
│ ▲ |│ │ |
│ ┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │
│ │ Shutdown Sequence (JVM Spec §12.8) │ │
│ │ 1. Trigger: main() returns OR System.exit(status) OR fatal error (e.g., OutOfMemoryError: Metaspace) │ │
│ │ 2. Run shutdown hooks (in reverse registration order) — e.g., flush logs, save state │ │
│ │ 3. Run finalizers (if -XX:+ExplicitGCInvokesFinalization; discouraged) │ │
│ │ 4. Stop all non-daemon threads (interrupt + join) │ │
│ │ 5. Close system resources: stdin/stdout, file descriptors, network sockets │ │
│ │ 6. Deallocate: │ │
│ │ - Heap → return to OS (mmap/munmap) │ │
│ │ - Metaspace → free virtual memory ranges │ │
│ │ - CodeCache → purge native code │ │
│ │ - Unload shared classes (if class data sharing used) │ │
│ │ 7. JVM process terminates (exit(status)); OS reclaims full process memory space │ | │ | | |
│ └────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
🔑 Key Legend (Embedded in Diagram)
- STW = Stop-The-World (all app threads paused)
- CP = Constant Pool
- LVs = Local Variables
- OS = Operand Stack
- TLAB = Thread-Local Allocation Buffer (fast-path heap alloc — not shown, but implied in "Heap → Eden")
- G1 Regions = Heap divided into fixed-size regions (default ~1–32 MB); GC selects “garbage-rich” ones
- HotSpot = Oracle’s JVM implementation (adaptive optimization engine)
Top comments (0)