How JVM Works

JavaMidjava

The Question

How does the JVM work?

What a Strong Answer Covers

• class loader subsystem
• runtime data area
• execution engine
• JIT compiler
• interpreter
• garbage collector
• parent delegation model

Senior-Level Answer

The JVM processes Java programs through four major subsystems: the class loader, the bytecode verifier, the execution engine, and the runtime memory areas.

The class loader subsystem loads `.class` files on demand, following a delegation hierarchy: Bootstrap ClassLoader (core JDK classes from rt.jar), Extension ClassLoader (lib/ext), and Application ClassLoader (classpath). This parent-first delegation prevents user code from shadowing core Java classes. Custom class loaders extend this hierarchy for frameworks, hot deployment, and OSGi-style isolation.

Before execution, the bytecode verifier statically checks `.class` files for structural validity and security properties — ensuring stack consistency, type safety, and absence of illegal memory accesses. This is a core security layer: untrusted bytecode cannot bypass the type system regardless of what compiler produced it.

The execution engine runs bytecode via two paths. The interpreter executes bytecode instructions directly, with no startup cost but slower throughput. The JIT (Just-In-Time) compiler monitors execution via profiling counters. When a method becomes "hot" (executed frequently), HotSpot compiles it to optimized native machine code, applying aggressive optimizations (inlining, escape analysis, loop unrolling) based on observed runtime behavior. This adaptive optimization is why JVM throughput often improves after a warm-up period.

The runtime memory model divides into: the heap (objects and arrays, managed by GC with generational regions — Eden, Survivor, Old Gen), the method area / Metaspace (class metadata, static fields), the JVM stack (one per thread — stack frames with local variables and operand stack), the PC register (per-thread instruction pointer), and native method stacks.

Garbage collection reclaims unreachable heap objects. Modern collectors (G1, ZGC, Shenandoah) use concurrent marking and region-based collection to minimize stop-the-world pauses, which is critical for latency-sensitive applications.

What Separates a 2/3 from a 3/3

Common Mistakes

• Describing JIT as ahead-of-time compilation — JIT compiles at runtime based on profiling, not before execution.
• Not knowing the class loader delegation hierarchy, or assuming there is only one class loader.
• Conflating the heap and the stack — objects live on the heap, stack frames (with primitives and references) live per-thread on the stack.
• Skipping bytecode verification as a security mechanism — it's a critical safety check, not just a syntax validator.

Follow-Up Questions

• Why does JVM performance often improve over the first few minutes of running? — JIT compilation is triggered by hot method detection. Initially the interpreter runs everything; as hot paths are JIT-compiled to native code, throughput increases — the warm-up effect.
• What is escape analysis and what optimization does it enable? — If the JIT determines an object does not escape the creating method (no reference leaves), it can allocate it on the stack instead of the heap, eliminating GC pressure.
• Explain the difference between a stop-the-world GC pause and a concurrent GC phase. — Stop-the-world halts all application threads while GC runs. Concurrent phases run alongside application threads. Modern collectors (ZGC, Shenandoah) minimize stop-the-world by doing most work concurrently.
• What is Metaspace (formerly PermGen) and what goes into it? — Native memory area holding class metadata, method bytecode, and interned strings. Unlike PermGen, Metaspace grows dynamically — OutOfMemoryError from Metaspace indicates a class loader leak, often from hot-deploy cycles.

Related Questions

• JVM vs JRE vs JDK
• Java Platform Independence
• Main Features of Java
• public static void main
• String Constant Pool