Execution Engine: Interpreter, JIT Compiler, and Garbage Collector

The Execution Engine is where the JVM actually runs your code. It takes bytecode from the Runtime Data Areas and executes it, either by interpreting it or by compiling it to native machine code on the fly. It also manages memory through the Garbage Collector, reclaiming objects that are no longer needed.

Understanding the Execution Engine helps you reason about JIT warmup behavior, choose the right GC algorithm, and diagnose performance problems in production.

Introduction

The Execution Engine is where the JVM actually runs your code. It consumes bytecode from the Runtime Data Areas and executes it through one of two paths: interpretation, which reads and executes bytecode instructions one at a time, or JIT compilation, which translates hot bytecode to native machine code at runtime for much faster execution. The third major component of the execution engine is the Garbage Collector, which reclaims memory from objects that are no longer reachable. Together, these three pieces determine your application’s performance characteristics — startup speed, peak throughput, and latency stability.

Understanding the Execution Engine gives you the mental model for reasoning about JIT warmup behavior, choosing the right GC algorithm, and diagnosing performance problems in production. When your application starts slowly and then speeds up, that is tiered compilation in action. When you see periodic latency spikes despite ample heap, that is often Full GC pause behavior. When your CPU usage spikes during startup and then stabilizes, that is the JIT compiler at work.

This guide covers the interpreter, JIT compiler, and garbage collector as integrated components of the JVM execution pipeline. You will learn how bytecode becomes native code, which JIT optimizations drive the biggest performance gains, how the GC identifies and reclaims unreachable objects, and which collector to choose based on your latency versus throughput requirements.

When NOT to Use

If your application does not have strict latency or throughput requirements, you can treat the interpreter, JIT compiler, and garbage collector as black boxes. The JVM defaults handle most workloads adequately. Do not switch GC algorithms or disable tiered compilation without measurements showing actual problems. A service handling hundreds of requests per second with consistent latency does not need ZGC; G1 is fine.

Avoid JIT internals unless you are tracking down specific issues. Compilation thresholds, inline budgets, and escape analysis settings are JVM-specific and vary between versions. Time spent tuning -XX:CompileCommand flags is usually better spent improving your hot code paths or algorithmic complexity. The exception is when you have clear evidence from async-profiler, Java Flight Recorder, or GC logs that compilation is actually the problem.

Pick your GC algorithm based on data, not preference. G1 balances latency and throughput for a range of workloads, but batch jobs that care about throughput may run faster with Parallel GC. Trading systems with ultra-low-latency requirements may need ZGC or Shenandoah. If you do not have measurable latency outliers violating SLAs, stick with the G1 defaults. Runtime Data Areas and JVM Startup and Shutdown give you the memory and initialization context that sits underneath the execution engine.

Execution Engine Architecture

graph LR
    Bytecode["Bytecode<br/>Instructions"]

    subgraph "Execution Engine"
        Interpreter["Interpreter"]
        JIT["JIT Compiler<br/>Client/Server"]
        GC["Garbage<br/>Collector"]
        NMI["JNI/Native<br/>Interface"]
    end

    Bytecode -->|Hot Code| JIT
    Bytecode -->|Cold Code| Interpreter
    Interpreter -->|Profile| JIT
    JIT -->|Native Code| Execution
    Execution --> NMI
    NMI --> GC

The Interpreter

The interpreter reads bytecode instructions one at a time and executes them directly. When the JVM starts, it uses the interpreter for all code. Interpretation is fast to start but slow to execute because each instruction requires a lookup and dispatch cycle.

The interpreter performs a switch on the opcode and calls the appropriate implementation. This dispatch overhead adds up. A simple arithmetic operation might require dozens of JVM instructions just to fetch operands and store results.

The interpreter records profiling information: which methods are called frequently, which branches are taken, which types flow through each call site. This profiling data feeds the JIT compiler.

Tiered Compilation

Modern JVMs use tiered compilation to balance startup speed and peak performance:

Tier 1: Interpreted bytecode. Fast startup, slower execution. Tier 2: Simple JIT compilation (client compiler). Quick native code generation with basic optimizations. Tier 3: Limited profiling JIT (server compiler). More aggressive optimizations based on profiling data. Tier 4: Full optimization JIT (server compiler). Maximum optimization for proven hot paths.

The JVM promotes methods through tiers as they become hotter. Deoptimization can cause a method to drop back to a lower tier if assumptions are violated.

Just-In-Time Compiler

The JIT compiler solves the interpretation bottleneck by compiling hot bytecode to native machine code at runtime. When a method is invoked many times, the JIT compiler spends time upfront compiling it, then all future calls run at native speed.

JIT Compilation Process

1. Profiling: The interpreter collects execution statistics. Which methods are hot? What types flow through each call site? Which branches are taken most frequently?

2. Compilation Request: When a method’s invocation count exceeds the JIT threshold, the compiler queues it for compilation.

3. Code Generation: The JIT compiler generates native machine code. Different JVMs use different compilers: HotSpot uses C1 (client) and C2 (server); GraalVM uses Graal as a modern alternative.

4. Installation: The compiled code replaces the interpreted version. Calls to this method now go directly to native code.

5. Deoptimization: If assumptions are violated (e.g., a class gets loaded that invalidates type speculation), the JVM can revert to interpreted mode.

JIT Optimizations

The JIT compiler performs aggressive optimizations based on profiling data:

Inlining replaces method calls with the method body. This eliminates call overhead and enables further optimizations across method boundaries. The JIT inlines small methods and hot call sites automatically.

Dead Code Elimination removes code whose results are never used. If a computation is performed but its result is discarded, the JIT can eliminate the computation entirely.

Constant Folding evaluates constant expressions at compile time. If x is always 10, expressions like x + 5 become 15.

Loop Unrolling reduces loop overhead by performing multiple iterations per loop body evaluation. This reduces branching and enables vectorization.

Escape Analysis determines if an object escapes the method or thread. If an object does not escape, the JIT can allocate it on the stack instead of the heap, eliminating allocation and garbage collection overhead entirely.

Garbage Collection Architecture

The Garbage Collector automatically reclaims memory from objects that are no longer reachable. This eliminates dangling pointers and use-after-free bugs while reducing manual memory management burden.

GC Roots

The GC identifies reachable objects by tracing from GC roots. GC roots are objects that are inherently reachable:

• Local variables and parameters on the JVM stack
• Active Java threads
• Static variables (loaded from class metadata)
• JNI references
• Exception objects currently being thrown

Anything not reachable from GC roots through object references is garbage.

GC Algorithms

Modern JVMs offer several GC algorithms, each optimized for different workload characteristics:

Serial GC uses a single thread for all GC work. It stops the world (STW) during collections. Appropriate for small heaps and single-threaded applications. Enabled with -XX:+UseSerialGC.

Parallel GC (Throughput GC) uses multiple threads to speed up GC. Designed to maximize throughput by completing GC quickly. Appropriate for batch workloads. Enabled with -XX:+UseParallelGC.

CMS (Concurrent Mark Sweep) aims to reduce pause times by doing most work concurrently with application threads. Deprecated in Java 9. Appropriate for interactive applications that cannot tolerate long pauses. Enabled with -XX:+UseConcMarkSweepGC.

G1 (Garbage First) divides the heap into regions and collects garbage region by region. It aims to meet pause time goals while delivering high throughput. Default GC since Java 9. Enabled with -XX:+UseG1GC.

ZGC and Shenandoah are ultra-low-pause collectors designed for applications requiring minimal latency. They perform most work concurrently, achieving pause times under 1 millisecond regardless of heap size. Enabled with -XX:+UseZGC or -XX:+UseShenandoahGC.

GC Phases

Most GC algorithms work in phases:

Mark identifies all reachable objects by tracing from GC roots. This phase is often done with the application paused (stop-the-world).

Remark completes marking by handling edge cases like objects modified during the concurrent mark phase.

Sweep/Compact reclaims memory from unreachable objects and moves surviving objects to eliminate fragmentation.

Young vs. Old Generation GC

Minor GC (young GC) collects the young generation. It is usually fast because the young generation is small and most objects are short-lived. Minor GC is stop-the-world but brief.

Major GC (old GC) collects the old generation. It is slower because the old generation is larger. The G1 algorithm refers to “mixed GC” when it collects both young and old regions.

Full GC collects the entire heap. It is the most disruptive and usually indicates a problem: either the heap is too small or a memory leak exists.

Production Failure Scenarios

Scenario	Root Cause	Symptoms	Resolution
GC Thrashing	Heap too small, excessive short-lived objects	High CPU, frequent GC, application pauses	Increase heap, optimize allocation patterns
Long GC Pauses	Wrong GC algorithm for workload, heap misconfiguration	Latency spikes, timeouts	Switch to low-pause GC (G1, ZGC), tune parameters
JIT Compilation Overhead	Excessive hot methods, compilation queue backlog	Sudden CPU spikes during warmup	Tiered compilation flags, increase code cache
Deoptimization Storms	Volatile type assumptions, class loading patterns	Performance instability	Reduce dynamic class loading, stabilize types
Metaspace GC Pressure	Classloader churn	High GC CPU, metaspace growth	Audit classloader lifecycle, limit dynamic proxies
Direct Buffer Memory Exhaustion	Excessive NIO buffer allocation	Native OOM, disk swap	-XX:MaxDirectMemorySize, audit ByteBuffer usage

Trade-off Analysis

Trade-off	Considerations
Throughput vs. Latency	Parallel GC maximizes throughput but causes long pauses. ZGC minimizes pauses but uses more CPU. G1 balances both.
Memory Footprint vs. Fragmentation	Compacting collectors eliminate fragmentation but use extra memory and CPU. Non-compacting collectors are faster but cause fragmentation.
JIT Compilation Time vs. Run Time	More aggressive JIT compilation improves peak performance but increases startup time and memory usage.
Young vs. Old Collection	Frequent young collection is cheap but promotes objects prematurely. Rare old collection is expensive when it happens.
Concurrent vs. Stop-The-World	Concurrent GC reduces pause times but uses CPU that could run application code. STW pauses are brief but still disruptive.

Failure Scenarios Deep Dive

Deoptimization Storms in Polymorphic Call Sites

When a method call site is polymorphic (calling different implementations based on receiver type), the JIT compiler initially generates monomorphic code assuming a single type. If multiple new types appear at that call site, the JIT must deoptimize and fall back to megamorphic dispatch, which is slower. This can cause “deoptimization storms” when class loading is uneven or when libraries dynamically generate proxy classes. Monitoring deoptimization counts with -XX:+PrintDeoptimization helps identify affected sites. The fix involves reducing dynamic proxy generation or forcing megamorphic dispatch earlier using @ForceInline hints.

CMS Concurrent Mode Failure

CMS (Concurrent Mark Sweep) can fail in two ways. First, “concurrent mode failure” occurs when the concurrent marking phase cannot complete before the old generation fills up, triggering a fallback to a stop-the-world full GC. Second, “promotion failed” occurs when the JVM tries to promote an object from young to old generation but finds insufficient contiguous space in the old generation. Both manifest as unexpected long pauses. The fix involves adjusting CMSInitiatingOccupancyFraction to start collection earlier, or switching to G1 which handles fragmentation better.

ZGC Heaps Larger Than Available Physical Memory

ZGC is designed for very large heaps (multi-terabyte range), but it requires all heap pages to be mapped in memory at all times. If the heap exceeds physical memory, ZGC will start swapping heavily, causing dramatic latency increases that defeat the purpose of using ZGC. The rule: ZGC works best when the heap fits comfortably in physical memory. For memory-constrained environments, G1 with proper tuning is often a better choice. Use ZAllocationSpikeTolerance to handle transient allocation spikes, but do not rely on it to compensate for undersized memory.

Implementation Patterns

// Forcing GC (not recommended for production, but useful for testing)
public class ForceGC {
    public static void main(String[] args) {
        // Make objects eligible for collection
        byte[] bigArray = new byte[1024 * 1024];
        bigArray = null;

        // Request GC
        System.gc();  // Hint to JVM, may be ignored

        // Better: run finalization
        System.runFinalization();
    }
}

// Soft references for caches (auto-reclaimed before OOM)
import java.lang.ref.SoftReference;

public class SoftReferenceCache<K, V> {
    private final Map<K, SoftReference<V>> cache = new HashMap<>();

    public V get(K key) {
        SoftReference<V> ref = cache.get(key);
        return ref != null ? ref.get() : null;
    }

    public void put(K key, V value) {
        cache.put(key, new SoftReference<>(value));
    }

    public void clear() {
        cache.clear();
    }
}

// Weak references for canonical mappings (reclaimed on GC)
import java.lang.ref.WeakHashMap;

public class WeakCache<K, V> {
    // Keys are weakly referenced - GC reclaims entry when key is weakly reachable
    private final WeakHashMap<K, V> cache = new WeakHashMap<>();

    public V get(K key) {
        return cache.get(key);
    }

    public void put(K key, V value) {
        cache.put(key, value);
    }
}

// Phantom references for cleanup actions (reclaimed after finalization)
import java.lang.ref.PhantomReference;
import java.lang.ref.ReferenceQueue;

public class ResourceCleanup {
    public static void main(String[] args) {
        ReferenceQueue<MyResource> queue = new ReferenceQueue<>();
        PhantomReference<MyResource> ref = new PhantomReference<>(
            new MyResource(), queue);

        // When MyResource is GC'd (after finalization),
        // the phantom reference is enqueued
        System.gc();

        // Check queue for cleanup
        PhantomReference<MyResource> polled = (PhantomReference<MyResource>) queue.poll();
        if (polled != null) {
            // Clean up native resources
            polled.clear();
        }
    }
}

Observability Checklist

• Enable GC logging: -Xlog:gc*:file=gc.log:time,uptime,level,tags
• Monitor pause times vs. latency SLAs
• Track allocation rates (bytes/second promoted to old gen)
• Monitor JIT compilation time and code cache size
• Use jstat to track GC statistics: jstat -gcutil <pid> 1000
• Monitor deoptimization counts
• Watch for CMS/G1 old gen exhaustion patterns
• Track metaspace reclamation after classloader cleanup
• Use async-profiler or Java Flight Recorder for detailed analysis

Security Notes

JIT compilation introduces a security consideration: JIT compilers generate code at runtime. If an attacker can influence what code gets JIT compiled (through polymorphic call patterns, for example), they might be able to trigger generation of specific code sequences. Modern JVMs include protections against JIT spraying attacks.

The GC does not automatically sanitize memory. If you store sensitive data in objects and rely on GC to “erase” it, you may be disappointed. The GC reclaims the memory but does not overwrite it. Use explicit clearing (setting byte arrays to zero) for sensitive data that must not be accessible after use.

Common Pitfalls / Anti-Patterns

Assuming System.gc() forces garbage collection. System.gc() is only a hint to the JVM. The JVM may ignore it entirely. In production, never rely on System.gc() to manage memory.

Setting heap too small based on visible memory usage. The JVM uses more memory than the heap. Metaspace, code cache, thread stacks, native memory allocations, and internal JVM data structures all consume memory outside the heap.

Ignoring GC logs. GC logs are invaluable for diagnosing performance issues. They show pause times, allocation rates, and promotion patterns. Enable them in production.

Over-tuning GC parameters. Modern JVMs auto-tune well. Start with defaults and only tune after measuring. Premature tuning based on intuition often makes things worse.

Assuming more threads means better parallel GC performance. Parallel GC threads compete for CPU. Too many threads cause context switching overhead that outweighs parallelism benefits.

Treating G1 as always the best choice. G1 is the default but not optimal for all workloads. Throughput-focused batch jobs may run faster with Parallel GC. Ultra-low-latency requirements may need ZGC or Shenandoah.

Quick Recap Checklist

• Interpreter runs bytecode initially, JIT compiles hot code to native
• Tiered compilation balances startup speed and peak performance
• JIT optimizations include inlining, dead code elimination, escape analysis
• GC reclaims unreachable objects automatically
• GC roots include stack variables, statics, active threads, JNI refs
• Serial GC is single-threaded; Parallel uses multiple threads
• G1 divides heap into regions, aims for pause time goals
• ZGC and Shenandoah are ultra-low-pause collectors
• Young GC collects short-lived objects; old GC collects long-lived ones
• System.gc() is only a hint, not a command
• Different GC algorithms prioritize different aspects (throughput vs. latency)

Interview Questions

Further Reading

• JVM Architecture Overview - How the execution engine fits into the JVM
• Runtime Data Areas - Memory regions the execution engine reads from and writes to
• Class Loader Subsystem - How classes are loaded and initialized before execution
• JVM Startup and Shutdown - How the JIT compiler warms up during startup
• JVM Bytecode Verification - Why the verifier must pass before code executes
• Advanced Java & JVM Internals Roadmap - Structured learning path

Conclusion

The Execution Engine converts bytecode to native code through interpretation and JIT compilation, while the Garbage Collector reclaims unreachable objects through various algorithms (Serial, Parallel, CMS, G1, ZGC, Shenandoah). Tiered compilation balances startup speed against peak performance, and JIT optimizations like inlining, dead code elimination, and escape analysis dramatically improve runtime efficiency. Choose the right GC algorithm based on your latency vs. throughput requirements.