Phase 14Advanced15 of 17 in Core Java

The JVM in Depth

Class loading, the JVM's memory areas, garbage collectors (G1, ZGC, Shenandoah), the JIT compiler, jcmd/jstack/JFR, and everyday performance pitfalls.

Up to now the Java Virtual Machine (JVM) has been the quiet machine underneath your code: you write classes, it runs them. This phase opens the machine. You'll see how a .class file becomes a live class in memory, where every byte of a running program lives, how the garbage collector finds and frees dead objects without stopping the world for long, how the JIT compiler turns hot bytecode into machine code that can beat hand-written C, and how to look inside a running JVM with jcmd, jstack, jmap and Java Flight Recorder.

Topic 14.1 covers class loading: loaders, delegation, linking and the exact moment a class is initialised. Topic 14.2 maps the memory areas: heap, stacks, Metaspace, the code cache and direct memory, and which OutOfMemoryError each one throws. Topic 14.3 explains garbage collection: reachability, generations, and the collectors you'll meet (Serial, Parallel, G1, ZGC, Shenandoah). Topic 14.4 is the JIT: tiered compilation, inlining, escape analysis and deoptimisation. Topic 14.5 is the tool kit for diagnosing a live process, and Topic 14.6 collects the performance pitfalls that show up again and again in real code reviews.

This is the phase that turns "it's slow" or "it ran out of memory" into a diagnosis. Runnable examples print the same output every time, so they show the rules (initialisation order, reachability, cache sizes, algorithmic cost) rather than timings. Real tool output (GC logs, thread dumps, jcmd reports) varies from machine to machine, so it appears as labelled sample output you can compare with your own. Topic 0.8 gave the short tour; this phase is the full one.

0/6 · 0%

6 topics ~3 h 23 code blocks & diagrams

Start with the first topic

14.1

Class Loading

Before a class can run, a class loader finds its bytes, the JVM links it (verify, prepare, resolve) and finally initialises it by running its static initialisers, exactly once and only on first active use. A class's identity at run time is its name *plus* the loader that defined it.

35 min 4 code practice

14.2

JVM Memory Areas

A running JVM uses several separate memory areas: one shared heap for objects, one stack per thread for method frames, Metaspace for class metadata, a code cache for JIT-compiled code, and other native memory such as direct buffers and thread stacks. Each has its own limit, its own flag, and its own kind of OutOfMemoryError or StackOverflowError.

33 min 4 code practice

14.3

Garbage Collection

The garbage collector frees objects that can no longer be reached from any GC root, so you never free memory by hand. Modern JVMs split the heap into generations because most objects die young, and offer collectors with different goals: G1 (the default since Java 9) balances throughput and pauses, ZGC and Shenandoah keep pauses around a millisecond, Parallel maximises throughput.

35 min 3 code practice

14.4

The JIT Compiler

HotSpot starts by interpreting bytecode, counts which methods and loops are hot, and compiles those to machine code: quickly with C1, then aggressively with C2 using the profile it gathered. C2's big wins are inlining, escape analysis and speculative optimisations that are undone (deoptimised) if their assumptions break.

34 min 4 code practice

14.5

JVM Tools: jcmd, jstack, jmap and JFR

The JDK ships tools that look inside a running JVM without restarting it: jcmd (the Swiss-army knife), jstack for thread dumps, jmap and heap dumps for memory, jstat for GC counters, and Java Flight Recorder (JFR) for low-overhead, always-on recording of what the JVM did. Knowing which one answers which question is most of production troubleshooting.

33 min 4 code practice

14.6

Everyday Performance Pitfalls

Most slow Java code is slow for a handful of ordinary reasons: the wrong algorithm or collection, needless allocation and boxing, string building in loops, exceptions and logging in hot paths, lock contention, and I/O done one byte or one query at a time. Measure first, fix the biggest cost, and measure again.