Written by sumitbhoyar

JVM

The JVM is the runtime environment that loads, verifies, optimizes, and executes Java bytecode on a specific machine.

1. What the JVM is responsible for

At a high level, the JVM is responsible for:

  • Loading code (classes, interfaces)
  • Verifying code for safety and correctness at runtime
  • Managing memory (allocation, layout, garbage collection)
  • Executing bytecode (interpretation and JIT compilation)
  • Providing runtime services (reflection, threads, exceptions, synchronization, monitoring)

Why this exists:

  • The JVM abstracts away OS + CPU details, giving “write once, run anywhere”.
  • It enforces safety guarantees (type safety, bounds checks) so untrusted code cannot crash or corrupt the host process easily.
  • It enables runtime optimizations using profiling (JIT), which static compilation cannot fully do with the same insight.

Real-world example:

  • A Spring Boot microservice ships as a fat JAR. The JVM:
    • Loads framework classes on startup (Spring, Jackson, Tomcat/Netty).
    • Builds object graphs (beans, controllers).
    • JIT-compiles hot paths like HTTP request dispatch and JSON (de)serialization as traffic ramps up.
    • Manages the heap for long-lived singletons and short-lived request objects.

2. JVM architecture (high level)

A conceptual view:

+--------------------------------------------------------------+
|                       JVM PROCESS                            |
|                                                              |
|  +--------------------+   +-------------------------------+  |
|  |   Class Loaders    |   |       Execution Engine        |  |
|  |  (Bootstrap, App)  |   |  Interpreter + JIT Compiler   |  |
|  +--------------------+   +-------------------------------+  |
|                                                              |
|  +--------------------------------------------------------+ |
|  |               Runtime Data Areas (Memory)              | |
|  |  - Method Area / Metaspace                             | |
|  |  - Heap                                                | |
|  |  - Java Stacks (one per thread)                        | |
|  |  - PC Registers (one per thread)                       | |
|  |  - Native Method Stacks                                | |
|  +--------------------------------------------------------+ |
|                                                             |
|  +--------------------+    +------------------------------+ |
|  |  Native Interface  |    |   OS / Hardware Integration  | |
|  |   (JNI, signals)   |    | Threads, I/O, timers, etc.   | |
|  +--------------------+    +------------------------------+ |
+--------------------------------------------------------------+

Key pieces and why they exist:

  • Class Loaders
    • Dynamically load classes as needed (lazy loading).
    • Support modularity (different loaders for app, framework, plugins).
    • Enable isolation (e.g., app server with per-application class loaders).
  • Execution Engine
    • Interpreter + JIT to execute bytecode efficiently.
    • JIT can leverage runtime profiling for aggressive optimizations.
  • Runtime Data Areas
    • Separate areas for objects, metadata, stacks, etc. to:
      • Optimize GC for objects (heap).
      • Keep per-thread execution state local (stacks).
      • Share class metadata across threads (method area/metaspace).
  • Native Interface & OS integration
    • Enable use of native libraries (e.g., crypto, networking).
    • Map Java threads to OS threads, handle signals, timers.

In a high-throughput backend, nearly all critical code runs in the execution engine with JIT-compiled methods living in separate code cache memory, heavily optimized based on live traffic.

3. Class loading process (Loading → Linking → Initialization)

The JVM spec defines a three-step lifecycle for each class:

  1. Loading
  2. Linking (Verification → Preparation → (optional) Resolution)
  3. Initialization

3.1 Loading

  • A ClassLoader reads the class bytes (from JAR, module, network, etc.).
  • It creates an in-memory Class object representing that type.

Why:

  • Late loading allows you to load only what you actually need (e.g., only certain controllers in a feature set).
  • Enables dynamic features like OSGi, application servers, hot deployment.

Spring example:

  • When a Spring Boot app starts, the application ClassLoader loads:
    • Your @SpringBootApplication class.
    • All dependencies as their classes are first referenced during startup.

3.2 Linking

Linking has three subphases:

  1. Verification
    • Bytecode is checked for correctness and safety (control flow, type correctness, stack discipline).
    • Prevents malformed or malicious bytecode from breaking the JVM.
  2. Preparation
    • Static fields are allocated and given default values (0, null, false).
    • No user code is run yet.
  3. (Optional) Resolution
    • Symbolic references (class names, method names) are resolved to actual runtime structures.
    • Often done lazily: resolution can occur on first use of a method/field.

Why:

  • Verification gives strong safety guarantees even if class bytes don’t come from javac (dynamic bytecode generation).
  • Resolving lazily reduces startup time and memory; you only pay for what you touch.

3.3 Initialization

  • Executes class initialization logic:
    • Static initializers (static { ... })
    • Static field initializations (static Foo f = new Foo())

Order example:

  • Main references MyService.class:
    • MyService is loaded.
    • Linked (verified, prepared, resolved as needed).
    • Initialized (static blocks run) before first active use.

In a Spring Boot startup, lots of classes are being initialized:

  • Configuration classes with static initializers.
  • Framework singletons (e.g., some caches, configuration holders).

4. ClassLoader types and delegation model

4.1 Main ClassLoader types (typical HotSpot)

Conceptual hierarchy:

           [Bootstrap ClassLoader] (native, part of JVM)
                    |
            [Platform (Ext) ClassLoader]
                    |
             [Application ClassLoader]
                    |
           [Custom / Framework ClassLoaders]
  • Bootstrap ClassLoader
    • Loads core Java classes (java.lang.*, java.util.*, etc.).
    • Implemented in native code, not a normal Java object.
    • Why: core classes must be loaded before Java code can run and must be trusted.
  • Platform (or Extension) ClassLoader
    • Loads “platform” libraries (e.g., JDK’s own modules).
    • Separates JDK internals from application code.
  • Application (System) ClassLoader
    • Loads app classes from the classpath/modulepath.
    • Default parent for many custom loaders.
  • Custom ClassLoaders
    • Application servers, OSGi, frameworks (e.g., Spring Boot LaunchedURLClassLoader) define their own.
    • Used for isolation (multi-tenant servers) and advanced loading strategies (fat JARs, plugins).

4.2 Delegation model (parent-first)

Default model (simplified):

  1. When a ClassLoader is asked to load com.example.Foo:
    • It first asks its parent to load the class.
    • If parent cannot find it, then it tries to load it itself.

Why:

  • Ensures a single trusted copy of core classes (e.g., you cannot replace java.lang.String).
  • Avoids class identity confusion (two different String versions).

Alternative: some frameworks use child-first delegation for plugins or application classes to override libraries from parents.

Real-world:

  • A Spring Boot fat JAR uses a custom loader to read classes from nested JARs but still delegates to parent first for core Java and JDK libs.

5. Runtime data areas (overview only)

Conceptual memory layout:

+-------------------------------+
|       Method Area /          |
|        Metaspace             |
|  (class metadata, methods)   |
+-------------------------------+
|            Heap               |
|  (all objects, arrays)        |
+-------------------------------+
| Per Thread:                   |
|  +-------------------------+  |
|  | Java Stack             |   |
|  | (frames, locals)       |   |
|  +-------------------------+  |
|  | PC Register            |   |
|  +-------------------------+  |
|  | Native Method Stack    |   |
|  +-------------------------+  |
+-------------------------------+

Key areas:

  • Method Area / Metaspace
    • Stores class metadata: field/method info, constant pool, bytecode, etc.
    • Metaspace is native memory (since Java 8).
    • Why: separate metadata from heap to avoid class metadata impacting object GC; easier to tune and isolate.
  • Heap
    • All objects and arrays.
    • Managed by GC (young/old generations, etc.).
    • Why: a separate, GC-managed region allows the runtime to move objects and compact memory to avoid fragmentation.
  • Java Stacks (one per thread)
    • Each stack has frames: local variables, operand stack, references to constant pool.
    • Why: fast per-thread execution, no locking required for local variables.
  • PC Register (per thread)
    • Holds the address of current executing instruction.
    • Very low-level; essentially part of the interpreter/JIT implementation.
  • Native Method Stacks
    • For methods executed via JNI.
    • Why: native code uses C-style stacks and calling conventions, separate from Java frames.

In a long-running microservice, heap and GC behavior are critical: too small a heap → frequent GCs; too large → longer GC pauses and more memory footprint.

6. Bytecode execution (Interpreter vs JIT)

Execution engine typically has:

  1. Interpreter
  2. JIT Compiler

6.1 Interpreter

  • Reads bytecode instructions sequentially and executes them.
  • No heavy optimization; startup is fast.
  • Each instruction dispatch is relatively slow.

Why:

  • Ideal for startup and rarely executed code (e.g., error paths, administrative endpoints).
  • Avoids wasting compilation time on code that is run only once or a few times.

6.2 JIT Compiler

  • When a method becomes “hot” (called often enough), the JIT compiles it to native machine code.
  • Native code is then executed directly, bypassing the interpreter.

Why:

  • Native code with optimizations can be orders of magnitude faster.
  • JIT can use runtime profiling data (branch frequencies, types seen, inlining opportunities) not available at static compile time.

Execution flow:

[Bytecode] --> Interpreter ----------------------+
        hot method? YES                          |
                      |                          |
                      v                          |
                JIT Compilation                  |
                      |                          |
                 [Optimized Native Code] <-------+
                      |
                   Execution

Real-world:

  • In a high-throughput backend, the hot paths (request handling chains, serializers, ORM hot queries) end up fully JIT-compiled after a brief warmup, delivering peak throughput.

7. JIT compilation and HotSpot optimizations

HotSpot has multiple compilers (C1, C2; tiered compilation):

  • C1 (client) compiler
    • Fast compilation, moderate optimizations.
    • Good for startup and low-latency warmup.
  • C2 (server) compiler
    • Slower compilation, very aggressive optimization.
    • Good for long-running, stable hot code.

7.1 Tiered compilation

Typical path for a hot method:

  1. Interpreted execution.
  2. Compiled by C1 (possibly with profiling).
  3. Once “hot enough” and stable, recompiled by C2 with full optimizations.

Why:

  • Balances startup latency vs peak performance.
  • Allows the JVM to gather good profiling info before doing expensive C2 optimizations.

7.2 Common HotSpot optimizations (high-level)

  • Inlining
    • Replaces a call with the callee’s body.
    • Removes call overhead, enables further optimizations across method boundaries.
    • Example: List.size() gets inlined inside tight loops.
  • Escape analysis
    • Determines if an object is used only within a method or thread.
    • If so, it can:
      • Allocate it on the stack.
      • Or eliminate allocation entirely (scalar replacement).
    • Example: small temporary objects created inside a hot loop never actually hit the heap.
  • Loop optimizations
    • Loop unrolling, strength reduction, induction variable simplification.
    • Example: optimized for-loops over arrays or ArrayList.
  • Devirtualization
    • Replacing virtual calls with direct calls when the actual type is known (often from profiling).
    • Example: if profiling shows List is always ArrayList, it can call ArrayList methods directly.
  • Speculative optimizations + deoptimization
    • JVM optimizes based on assumptions (e.g., only one implementation of an interface is used).
    • If assumption breaks at runtime, the JVM deoptimizes back to a safer version (possibly interpreter or C1).
    • Enables very aggressive optimizations while preserving correctness.

In a high-throughput service, most hot code is C2-compiled with speculative optimizations. That’s why warmup time matters in benchmarks and cold deployments.

8. JVM lifecycle (startup → steady state → shutdown)

8.1 Startup

Rough sequence:

  1. Process start
    • OS launches the JVM binary (java).
    • JVM initializes internal subsystems: GC, JIT, class loading, thread management.
  2. Main class loading
    • Bootstrap → platform → application ClassLoader load the main class.
    • public static void main(String[] args) is located.
  3. Class initialization
    • Startup code initializes static fields, configuration, frameworks.
    • For Spring Boot, this includes:
      • Classpath scanning.
      • Bean definitions loading.
      • Context creation.
      • Embedded server startup.

Startup concerns:

  • Heavy static initialization slows down time-to-first-request.
  • Lots of classes loaded early increase memory footprint and metaspace usage.

8.2 Steady state

  • The application is accepting requests.
  • JIT has compiled hot methods.
  • GC cycles periodically reclaim memory.

Key properties:

  • Throughput, latency, GC behavior stabilize to some pattern (under stable traffic).
  • Long-running microservices ideally spend most of their time here.

Steady-state tuning:

  • Heap size, GC algorithm (G1, ZGC, Shenandoah, etc.), thread pools, and CPU sizing all matter.
  • HotSpot optimizations are most effective in steady state.

8.3 Shutdown

  • Triggered by:
    • Normal termination (main returns).
    • System.exit().
    • OS signal (SIGTERM in container, kill, etc.).

Steps:

  • JVM runs shutdown hooks (registered via Runtime.addShutdownHook).
  • Stops accepting new work, attempts graceful shutdown (e.g., Spring Boot closes server, thread pools, DB connections).
  • Final GC or cleanup as needed.
  • Process exits; OS reclaims resources.

Why lifecycle matters:

  • For containerized microservices, graceful termination is critical:
    • Need time between SIGTERM and actual kill for hooks to run.
    • Thread pools and in-flight requests must be drained properly.

9. Performance implications you should actually care about

From a senior dev / architect perspective, the following JVM internals are practically important:

  1. Warmup behavior
    • Cold JVM → mostly interpreted or low-tier compiled code → slower.
    • After warmup → C2-compiled hot paths → significantly higher throughput.
    • Practical implications:
      • Don’t trust single-shot microbenchmarks.
      • Pre-warm apps in production-like environments when startup vs throughput matters.
  2. Class loading & initialization cost
    • Heavy static initialization (large caches, static singletons, classpath scanning) can dominate startup time.
    • For Spring Boot:
      • Too much work in @PostConstruct and static initializers hurts startup and memory footprint.
    • For serverless or short-lived processes, this can be a killer.
  3. Heap sizing and GC behavior
    • Too small heap:
      • Frequent minor GCs, possible major GCs.
      • CPU burns in GC; latency spikes.
    • Too large heap:
      • Longer GC pauses depending on collector.
      • Higher memory cost per container/instance.
    • Tuning:
      • Choose GC (e.g., G1 for balanced throughput/latency; ZGC/Shenandoah for low latency).
      • Size heap based on object allocation rates and live set.
  4. Allocation patterns and object lifetime
    • JVM is very good at allocating and collecting short-lived objects in young gen.
    • What hurts:
      • Large numbers of long-lived objects (huge caches) that survive multiple GCs.
      • High churn of medium-lived objects that often get promoted to old gen.
    • Patterns:
      • Reuse objects only when profiling shows allocation hot spots and GC pressure.
      • Avoid unnecessary boxing, per-request temporary large graphs, etc.
  5. ClassLoader leaks
    • In app servers or plugin systems, if a ClassLoader cannot be GC’d due to references from static fields or thread locals, you get metaspace leaks.
    • In long-running systems, this leads to periodic OOM or forced restarts.
  6. Thread stacks and recursion
    • Each thread has a limited stack size. Deep recursion or massive locals can cause StackOverflowError.
    • Large stack sizes per thread reduce the number of threads you can create.
  7. Native integration
    • JNI or off-heap memory leaks bypass the GC; must be manually managed.
    • Direct ByteBuffers, Netty arenas, etc. require careful lifecycle management.

10. How this is asked in interviews

Here are 8 representative JVM internals questions, with short hints:

  1. Q: What are the main runtime data areas in the JVM?
    Hint: Method area/metaspace, heap, Java stacks, PC, native stacks; know heap vs stack roles.
  2. Q: Explain the class loading process.
    Hint: Loading → Linking (verification, preparation, resolution) → Initialization; emphasize safety and lazy behavior.
  3. Q: What is the parent delegation model in ClassLoaders and why is it used?
    Hint: Parent-first loading to ensure core classes are unique/trusted; avoids conflicts, supports security.
  4. Q: How does the JVM execute bytecode?
    Hint: Interpreter first; JIT compiles hot methods to native code; tiered compilation (C1, C2).
  5. Q: Why does Java sometimes need a “warmup” period before achieving peak performance?
    Hint: JIT compilation and profiling; optimizations applied over time; initial runs are interpreted or low-tier compiled.
  6. Q: What kinds of optimizations can the HotSpot JIT perform?
    Hint: Inlining, escape analysis, loop optimizations, devirtualization, speculative optimizations with deoptimization.
  7. Q: How does the JVM manage memory for long-running applications?
    Hint: Generational heap (young/old), GC cycles, promotion; mention impact of allocation patterns and long-lived objects.
  8. Q: How are class loaders used in application servers or Spring Boot?
    Hint: Separate ClassLoaders per app/module; custom loaders for fat JARs; enables isolation, hot deploy, plugin loading.

Leave a comment