JVM Internals & Performance Terminology — Interview Reference

Why this matters in interviews

Senior Java interviews routinely probe JVM internals to assess whether a candidate can reason about production behavior — not just write correct code. Understanding garbage collection, JIT compilation, and memory areas lets you diagnose OutOfMemoryError incidents, tune throughput vs latency trade-offs, and explain why certain coding patterns (static collections, thread-locals, finalizers) are dangerous at scale. Interviewers at FAANG and fintech companies use these topics to separate engineers who know Java from those who understand the JVM.

Concept

JVM Architecture — ClassLoader Subsystem

JVM Architecture — Runtime Data Areas

Garbage Collection — Fundamentals

Garbage Collection — G1GC

Garbage Collection — Low-Latency Collectors

Garbage Collection — Tuning Flags

JIT Compilation

String Pool & Interning

Memory Leaks & Diagnostics

Common JVM Errors

Key rules / gotchas

• Parent delegation is security-critical: Without it, a malicious JAR could shadow java.lang.String. Custom classloaders that break delegation (like some hot-reload frameworks) require explicit security consideration.
• Metaspace is unlimited by default: Unlike PermGen, Metaspace has no fixed ceiling unless you set -XX:MaxMetaspaceSize. A classloader leak will silently consume native memory until the OS kills the process.
• System.gc() is a hint, not a command: The JVM may ignore it. Never rely on it in production code. Use it only in controlled benchmarks or tests — and always note that it may trigger a Full GC, halting all threads.
• Escape analysis can be fooled: Passing an object to a method that the JIT cannot inline prevents stack allocation, even if the object never truly escapes. Keep performance-critical value-like objects small and contained.
• Soft references are cleared lazily: The GC clears SoftReferences "before" OOM, but "before" can mean "very close to" — your cache may still get cleared during a GC pause that precedes OOM. Never use soft references for critical data.
• WeakHashMap keys are the referents, not the values: Values in a WeakHashMap can still prevent GC if values hold strong references back to keys (circular reference), defeating the purpose of the weak map.
• G1 pause targets are soft goals: -XX:MaxGCPauseMillis is G1's target, not a hard real-time guarantee. Evacuation failures can still cause longer STW pauses. Use ZGC or Shenandoah for hard latency requirements.
• TLAB exhaustion causes contention: When a thread's Thread-Local Allocation Buffer (TLAB) is full, it must synchronize to request a new one. Excessive TLAB refills show up as allocation stalls in async-profiler.
• StackOverflowError is recoverable (barely): Unlike most Errors it can be caught, but the stack is still nearly full at the catch site — attempting significant work in the handler is dangerous.
• Deoptimization cascades: A class hierarchy change (e.g., adding a new subtype at runtime via reflection or class loading) can trigger mass deoptimization of previously JIT-compiled call sites, causing a temporary performance cliff.

Code example

import java.lang.ref.WeakReference;

public class JavaLabRunner {

    public static void main(String[] args) throws InterruptedException {
        // ── 1. Runtime memory inspection ─────────────────────────────────
        Runtime rt = Runtime.getRuntime();
        long maxHeap   = rt.maxMemory();      // -Xmx value
        long totalHeap = rt.totalMemory();    // currently committed heap
        long freeHeap  = rt.freeMemory();     // free within committed heap
        long usedHeap  = totalHeap - freeHeap;

        System.out.printf("Max heap   : %,d bytes (%.1f MB)%n", maxHeap,   mb(maxHeap));
        System.out.printf("Committed  : %,d bytes (%.1f MB)%n", totalHeap, mb(totalHeap));
        System.out.printf("Used       : %,d bytes (%.1f MB)%n", usedHeap,  mb(usedHeap));
        System.out.printf("Free       : %,d bytes (%.1f MB)%n", freeHeap,  mb(freeHeap));
        System.out.printf("CPU cores  : %d%n%n", rt.availableProcessors());

        // ── 2. ClassLoader hierarchy traversal ───────────────────────────
        System.out.println("=== ClassLoader hierarchy ===");
        ClassLoader loader = JavaLabRunner.class.getClassLoader();
        while (loader != null) {
            System.out.println("  " + loader.getClass().getName() + " → " + loader);
            loader = loader.getParent();
        }
        // Parent of Application ClassLoader is Platform (or Bootstrap), which is null
        System.out.println("  [Bootstrap ClassLoader — native, no Java object]");
        System.out.println();

        // ── 3. WeakReference behavior ─────────────────────────────────────
        System.out.println("=== WeakReference demo ===");
        Object strongRef = new Object();                      // strong reference
        WeakReference<Object> weakRef = new WeakReference<>(strongRef);

        System.out.println("Before nulling strong ref: weakRef.get() = " + weakRef.get());

        strongRef = null;   // remove the only strong reference
        // Hint GC — NOTE: System.gc() is advisory only; never use in prod
        System.gc();
        Thread.sleep(100);  // give GC a moment (not reliable in all JVMs)

        Object afterGc = weakRef.get();
        System.out.println("After GC hint            : weakRef.get() = " + afterGc);
        // Expected: null — the GC is free to collect it now
        System.out.println();

        // ── 4. String interning and pool comparison ───────────────────────
        System.out.println("=== String pool / intern demo ===");
        String a = "hello";                      // goes to string constant pool
        String b = "hello";                      // same pool entry
        String c = new String("hello");          // new heap object, NOT pooled
        String d = c.intern();                   // returns the pooled "hello"

        System.out.println("a == b            : " + (a == b));       // true  — same pool object
        System.out.println("a == c            : " + (a == c));       // false — c is on heap
        System.out.println("a == d            : " + (a == d));       // true  — d is the pool object
        System.out.println("a.equals(c)       : " + a.equals(c));    // true  — content equal
        System.out.println();

        // ── 5. Trigger GC + re-check memory (with caveat) ─────────────────
        System.out.println("=== Memory after allocating & GC hinting ===");
        // Allocate some garbage
        for (int i = 0; i < 100_000; i++) {
            @SuppressWarnings("unused")
            byte[] trash = new byte[1024]; // immediately unreachable after each iteration
        }

        long beforeGc = rt.totalMemory() - rt.freeMemory();
        System.gc(); // ADVISORY — JVM may ignore this; never rely on it in production
        Thread.sleep(100);
        long afterGcMem = rt.totalMemory() - rt.freeMemory();

        System.out.printf("Used before GC hint: %.1f MB%n", mb(beforeGc));
        System.out.printf("Used after  GC hint: %.1f MB%n", mb(afterGcMem));
        System.out.println("(Results are JVM-dependent; System.gc() is not guaranteed to run)");
    }

    private static double mb(long bytes) {
        return bytes / (1024.0 * 1024.0);
    }
}

Interview questions you should be able to answer

• Q: Why does the JVM use parent delegation in the ClassLoader hierarchy, and what problem does it solve?

  Parent delegation ensures that a class is always loaded by the highest-level ClassLoader willing to handle it, typically Bootstrap. This prevents malicious or accidental replacement of core JDK classes (e.g., a rogue java.lang.String on the classpath could not override the Bootstrap-loaded one). It also guarantees that instanceof and cast checks work correctly — two classes with the same name loaded by different ClassLoaders are distinct types in the JVM, which would break type safety if core classes were duplicated.

• Q: How does G1GC's region-based layout differ from the classic generational heap, and why does this matter for pause times?

  Classic generational collectors (Parallel GC, old CMS) divide the heap into fixed contiguous zones (Eden, two Survivors, Old). G1 splits the entire heap into many equal-sized regions (1–32 MB) that are dynamically assigned roles. This means G1 can select a Collection Set of only the most garbage-dense regions to collect in each pause, bounding pause duration regardless of total heap size. In contrast, a Full GC on a traditional collector must process the entire old-gen contiguously, making pause time proportional to heap size.

• Q: What is escape analysis, and how can it eliminate heap allocation for a Java object?

  Escape analysis is a JIT optimization that determines whether an object's reference can leave ("escape") the scope of the method where it is created — either by being stored in a field, returned, or passed to a method the JIT cannot inline. If the object does not escape, the JIT can apply scalar replacement: it decomposes the object into its constituent primitive fields and keeps them as local variables (in registers or on the stack), never allocating a heap object at all. This eliminates GC pressure and object header overhead entirely for short-lived value-like objects such as iterators, Optional, and small DTOs.

• Q: Why did Java 8 replace PermGen with Metaspace, and what are the practical implications?

  PermGen was a fixed-size JVM-managed heap region for class metadata, notoriously prone to OutOfMemoryError: PermGen space when applications loaded many classes (dynamic proxies, JSP compilation, CGLIB). Metaspace uses native OS memory instead, has no fixed upper bound by default, and is subject to the OS's virtual memory limits rather than an arbitrary JVM setting. The practical implication is that Metaspace leaks (classloader leaks) do not crash with an obvious OOM immediately — instead they silently consume native memory until the JVM process is killed by the OS. You must set -XX:MaxMetaspaceSize in production to get a predictable failure mode, and monitor native memory alongside heap.

• Q: How would you diagnose a memory leak in a production JVM without restarting it?

  Start with jstat -gcutil <pid> 5000 to confirm old-gen is growing over time without being reclaimed by Full GCs. Then take a heap dump with jmap -dump:format=b,file=heap.hprof <pid> (or pre-configure -XX:+HeapDumpOnOutOfMemoryError). Analyze the dump in Eclipse MAT or VisualVM: use the "Leak Suspects" report and dominator tree to identify which object graph is retaining the most memory. Check for static collections, unbounded caches, undrained queues, and ThreadLocal values in pooled threads. If the leak is in Metaspace rather than heap, use jcmd <pid> VM.native_memory (with -XX:NativeMemoryTracking=summary) to see classloader-allocated native memory growth, and check which ClassLoaders are accumulating loaded class counts with jstat -class.

• Q: What is the difference between a minor GC and a Full GC, and when does each occur?

  A minor GC collects only the young generation (Eden + Survivor spaces). It is triggered when Eden fills up. Because most objects are short-lived (generational hypothesis), nearly all of Eden is garbage, making minor GC fast — typically under 10 ms. A Full GC collects young gen, old gen, and Metaspace together and always involves a stop-the-world compaction phase. It is triggered when old gen fills (promotion failure), when Metaspace fills, when the GC overhead limit is exceeded, or when System.gc() is called. Full GC pauses can range from hundreds of milliseconds to many seconds depending on heap size and live object count. The goal of GC tuning is to minimize Full GC frequency and duration while keeping minor GC pauses acceptable.

Further reading

• JVM Specification — Chapter 2: The Structure of the Java Virtual Machine
• HotSpot Virtual Machine Garbage Collection Tuning Guide (Java 21)
• G1GC Garbage First Garbage Collector — Oracle official doc
• ZGC — The Z Garbage Collector (OpenJDK wiki)
• async-profiler — GitHub
• Eclipse Memory Analyzer (MAT)
• Aleksey Shipilëv's JVM anatomy quarks (deep JIT & GC internals)
• Java Performance: The Definitive Guide — Scott Oaks (O'Reilly)