JIT Deoptimization — 250x Latency from Class Loading

Every time you run a Java or Python program and it magically gets faster the longer it runs, that's a Just-In-Time compiler quietly doing something remarkable: watching your code execute, figuring out which paths are traveled most, and recompiling those exact paths into hyper-optimized native machine code — at runtime. No restart required, no ahead-of-time guessing. The JIT is one of the most sophisticated pieces of software running silently in your production systems right now.

The problem it solves is fundamental: interpreted languages are portable because they run on a virtual machine, but virtual machines are slow because they translate instructions at runtime. Ahead-of-time compilers solve speed but sacrifice runtime information — they can't know which branch your users actually take or what types your polymorphic methods actually receive. JIT compilation threads this needle by compiling adaptively, using real execution data to make optimizations no static compiler could ever make.

By the end of this article you'll understand exactly how HotSpot's tiered compilation pipeline works, what profiling data the JIT actually collects, why deoptimization exists and when it fires, how to read JIT logs to debug performance regressions, and what production patterns silently kill JIT effectiveness. You'll go from 'the JVM warms up' to 'I can explain exactly what's happening during warmup and why.'

JIT Compilation: The Hot Path Optimizer That Can Also Burn You

Just-in-time (JIT) compilation is a runtime technique that converts bytecode into native machine code during program execution, targeting only frequently executed code paths. The core mechanic: the JVM profiles method invocations and loop iterations, then compiles the hot spots — typically methods called more than 10,000 times — into optimized native code. This gives Java near-native performance while preserving portability.

In practice, the JIT compiler uses tiered compilation: first interpreting bytecode, then compiling with C1 (quick, minimal optimization), and finally with C2 (aggressive, profile-guided optimization). The key property: compilation happens asynchronously on a background thread, so your application keeps running during compilation. But deoptimization — reverting to interpreted code — can happen when assumptions made during compilation are invalidated, such as when a new class is loaded that changes the class hierarchy.

Use JIT when you need both portability and performance — essentially any server-side Java application. It matters because the difference between interpreted and JIT-compiled code can be 10-100x on hot paths. However, the cost of deoptimization can spike latency by 250x in pathological cases, making it critical to understand what triggers recompilation.

The JIT Pipeline: From Bytecode to Native Code in Three Tiers

HotSpot JVM doesn't flip a single switch from 'interpreted' to 'compiled'. It runs a tiered system with five distinct levels, though three are conceptually important: pure interpretation (Tier 0), the C1 client compiler (Tiers 1-3), and the C2 server compiler (Tier 4).

Tier 0 is pure interpretation — the interpreter executes bytecode directly and, critically, it's also gathering profiling data: method invocation counts, branch frequencies, and receiver type profiles for virtual calls. This data is cheap to collect and priceless later.

Once a method is invoked roughly 2,000 times (the -XX:Tier3InvocationThreshold), C1 compiles it quickly into native code with light optimizations. C1 is fast to compile and produces code about 2-5x faster than interpreted. But it keeps profiling.

Once that same method hits roughly 15,000 invocations or its loop back-edges accumulate enough, C2 takes over. C2 spends significantly more time compiling — using the profiling data C1 collected — and produces code that rivals hand-written C. The key insight is that C2 can inline virtual method calls because the profile told it 'this call site always receives a HashMap, never anything else.' It bets on that. If it's wrong, it deoptimizes.

import java.util.HashMap;
import java.util.Map;

public class TieredCompilationDemo {
    private static final Map<String, Integer> wordFrequency = new HashMap<>();
    static {
        wordFrequency.put("java", 42);
        wordFrequency.put("jit", 99);
        wordFrequency.put("compiler", 7);
    }

    private static int lookupFrequency(String word) {
        Integer frequency = wordFrequency.get(word);
        return (frequency != null) ? frequency : 0;
    }

    public static void main(String[] args) throws InterruptedException {
        String[] wordsToLookup = {"java", "jit", "compiler", "unknown"};
        int totalIterations = 500_000;
        int batchSize = totalIterations / 5;

        for (int batch = 0; batch < 5; batch++) {
            long startNanos = System.nanoTime();
            for (int i = 0; i < batchSize; i++) {
                String word = wordsToLookup[i % wordsToLookup.length];
                int freq = lookupFrequency(word);
                if (freq < 0) {
                    System.out.println("Negative frequency — impossible but prevents DCE");
                }
            }
            long elapsedMs = (System.nanoTime() - startNanos) / 1_000_000;
            double throughput = (double) batchSize / elapsedMs * 1000;
            System.out.printf("Batch %d: %,d lookups in %d ms → %,.0f lookups/sec%n", batch + 1, batchSize, elapsedMs, throughput);
            Thread.sleep(50);
        }
    }
}

Speculative Optimization and Deoptimization: The JIT's Calculated Gamble

The most powerful and most misunderstood JIT technique is speculative optimization. The C2 compiler doesn't just optimize what it knows to be true — it optimizes what the profiling data suggests is almost always true, then installs a guard that triggers deoptimization if that assumption is violated.

Consider a polymorphic call site: animal.speak() where Animal is an interface. If the profile says 99.9% of calls see a Dog object, C2 inlines Dog.speak() directly at that call site, eliminating the virtual dispatch entirely. It inserts a type check guard: 'if this isn't a Dog, bail out.' When a Cat suddenly arrives, the JIT traps that guard, tosses out the compiled code for that method, and drops back to interpreter mode — this is deoptimization.

Deoptimization is not catastrophic in isolation, but watch for these triggers in production: loading a new class that invalidates a 'this class has no subclasses' assumption (ClassLoading deopt), a null being seen at a previously non-null call site, or hitting a branch that was never taken during profiling. Each deopt event forces recompilation, and if they happen in a tight loop during peak traffic, you'll see latency spikes that look identical to GC pauses but won't show up in GC logs.

You can observe deopt events with -XX:+PrintDeoptimization — every senior Java engineer should spend a day reading these logs in a staging environment.

public class DeoptimizationTriggerDemo {
    interface Greeter {
        String greet(String name);
    }
    static class FriendlyGreeter implements Greeter {
        @Override
        public String greet(String name) {
            return "Hey there, " + name + "!";
        }
    }
    static class FormalGreeter implements Greeter {
        @Override
        public String greet(String name) {
            return "Good day, " + name + ". How do you do?";
        }
    }

    private static String performGreeting(Greeter greeter, String name) {
        return greeter.greet(name);
    }

    public static void main(String[] args) throws InterruptedException {
        Greeter friendlyGreeter = new FriendlyGreeter();
        Greeter formalGreeter   = new FormalGreeter();

        System.out.println("=== Phase 1: Warming up with monomorphic call site ===");
        long sumLength = 0;
        for (int i = 0; i < 100_000; i++) {
            String result = performGreeting(friendlyGreeter, "Alice");
            sumLength += result.length();
        }
        System.out.printf("Phase 1 complete. Total chars processed: %,d%n%n", sumLength);
        Thread.sleep(200);

        System.out.println("=== Phase 2: Introducing second type — watch for deoptimization ===");
        sumLength = 0;
        for (int i = 0; i < 50_000; i++) {
            Greeter active = (i % 2 == 0) ? friendlyGreeter : formalGreeter;
            String result = performGreeting(active, "Bob");
            sumLength += result.length();
        }
        System.out.printf("Phase 2 complete. Total chars processed: %,d%n", sumLength);
        System.out.println("\nCheck your console above for PrintDeoptimization output.");
        System.out.println("Look for: 'bimorphic' or 'type profile changed' reason codes.");
    }
}

What the JIT Actually Inlines — And Why Inlining Is the Master Optimization

Experienced engineers know 'inlining' is good, but few can articulate why it's the master optimization that enables all others. Here's the mechanism: when the JIT inlines a called method into its caller, the combined code body is now visible to the optimizer as a single unit. Constants propagate across the former call boundary, dead branches get eliminated, allocations can be stack-allocated (scalar replaced) instead of heap-allocated, and loop invariants can be hoisted. Without inlining, each of these is blocked by the opacity of the call.

The JIT decides what to inline based on three factors: method size (bytecode size, controlled by -XX:MaxInlineSize, default 35 bytes and -XX:FreqInlineSize, default 325 bytes for hot methods), call frequency from the profile, and call chain depth. Getters, setters, and small utility methods almost always get inlined. Methods that exceed the size threshold won't, even if they're blazing hot — this is a common performance trap.

The practical consequence: your method boundaries matter for JIT performance in ways that have nothing to do with code organization. A method that's 36 bytecodes long might not inline where a 34-bytecode version would. You can verify inlining decisions with -XX:+PrintInlining and -XX:+UnlockDiagnosticVMOptions. Look for '@ X callee is too large' messages — those are your inlining failures.

public class InliningThresholdDemo {
    private static double calculateCircleArea(double radius) {
        return Math.PI * radius * radius;
    }

    private static double calculateCircleAreaVerbose(double radius) {
        double pi = Math.PI;
        double radiusSquared = radius * radius;
        double rawArea = pi * radiusSquared;
        double roundedArea = Math.round(rawArea * 1_000_000.0) / 1_000_000.0;
        if (Double.isNaN(roundedArea) || Double.isInfinite(roundedArea)) {
            throw new ArithmeticException("Invalid radius produced non-finite area: " + radius);
        }
        return roundedArea;
    }

    private static long benchmarkSmallMethod(int iterations) {
        double accumulator = 0.0;
        long startNanos = System.nanoTime();
        for (int i = 1; i <= iterations; i++) {
            double radius = i * 0.001;
            accumulator += calculateCircleArea(radius);
        }
        long elapsedNanos = System.nanoTime() - startNanos;
        System.out.printf("  Small method total area sum: %.2f%n", accumulator);
        return elapsedNanos;
    }

    private static long benchmarkVerboseMethod(int iterations) {
        double accumulator = 0.0;
        long startNanos = System.nanoTime();
        for (int i = 1; i <= iterations; i++) {
            double radius = i * 0.001;
            accumulator += calculateCircleAreaVerbose(radius);
        }
        long elapsedNanos = System.nanoTime() - startNanos;
        System.out.printf("  Verbose method total area sum: %.2f%n", accumulator);
        return elapsedNanos;
    }

    public static void main(String[] args) {
        int warmupIterations = 200_000;
        int benchIterations  = 2_000_000;
        System.out.println("Warming up JIT (both methods to Tier 4)...");
        benchmarkSmallMethod(warmupIterations);
        benchmarkVerboseMethod(warmupIterations);
        System.out.println("\n--- Benchmark (" + benchIterations + " iterations each) ---");
        long smallNanos   = benchmarkSmallMethod(benchIterations);
        long verboseNanos = benchmarkVerboseMethod(benchIterations);
        System.out.printf("%n  Small method (likely inlined):   %,d ms%n", smallNanos / 1_000_000);
        System.out.printf("  Verbose method (may not inline): %,d ms%n", verboseNanos / 1_000_000);
        System.out.printf("  Overhead factor: %.2fx%n", (double) verboseNanos / smallNanos);
        System.out.println("\nCheck PrintInlining output for '@ X callee is too large' to confirm.");
    }
}

Production JIT Gotchas: Warmup Strategies, OSR, and the Flags That Actually Matter

On-Stack Replacement (OSR) is a JIT feature you've almost certainly benefited from without knowing its name. Normally, a method is compiled and the next invocation runs the compiled version. But what about a method with a loop that runs for ten million iterations in a single call? Without OSR, you'd interpret all ten million iterations because the method never returns to get recompiled. OSR solves this by replacing the executing method frame mid-execution — the JIT compiles the method while it runs and swaps the stack frame to the compiled version at a loop back-edge. OSR-compiled code is slightly less optimal than normal JIT-compiled code because the frame layout must match the interpreter's at the replacement point, limiting some optimizations.

For microservices and serverless, warmup is an existential problem. Your JIT hasn't seen enough traffic to compile the hot paths, so your first thousand requests are slow — potentially violating SLAs. Three production strategies work: (1) Replay-based warmup using recorded traffic replayed at startup before the instance joins the load balancer. (2) Ahead-of-time profile injection using CDS (Class Data Sharing) or GraalVM's PGO (Profile-Guided Optimization), which serializes profiles from a training run. (3) JVM flags tuning — -XX:CompileThreshold=500 and -XX:Tier4InvocationThreshold=5000 lower thresholds at the cost of compiling with less profile data, which means slightly less optimal code but faster warmup.

GraalVM Native Image takes the opposite trade: it compiles everything AOT using Substrate VM, eliminating warmup entirely at the cost of peak throughput (no runtime profiles) and dynamic class loading.

public class OsrAndWarmupDemo {
    private static double longRunningSetup(int iterationCount) {
        double runningTotal = 0.0;
        for (int i = 1; i <= iterationCount; i++) {
            runningTotal += Math.sqrt(i) * Math.log1p(i);
            if (i == 10_000) System.out.println("  [iteration 10,000] — JIT likely compiling this method NOW via OSR");
            if (i == 50_000) System.out.println("  [iteration 50,000] — now running in OSR-compiled native code");
        }
        return runningTotal;
    }

    private static void simulateWarmupPhase() {
        System.out.println("\n=== Warmup Phase ===");
        for (int warmupRound = 0; warmupRound < 5; warmupRound++) {
            double result = longRunningSetup(20_000);
            System.out.printf("  Warmup round %d result: %.2f%n", warmupRound + 1, result);
        }
        System.out.println("Warmup complete — instance ready to serve traffic.\n");
    }

    public static void main(String[] args) {
        System.out.println("=== Phase 1: Single Long-Running Method Call (OSR Demo) ===");
        long startNanos = System.nanoTime();
        double osrResult = longRunningSetup(5_000_000);
        long osrElapsedMs = (System.nanoTime() - startNanos) / 1_000_000;
        System.out.printf("OSR demo result: %.4f | Elapsed: %d ms%n", osrResult, osrElapsedMs);
        simulateWarmupPhase();
        System.out.println("=== Phase 2: Post-warmup benchmark (fully C2 compiled) ===");
        startNanos = System.nanoTime();
        double warmResult = longRunningSetup(5_000_000);
        long warmElapsedMs = (System.nanoTime() - startNanos) / 1_000_000;
        System.out.printf("Warm result: %.4f | Elapsed: %d ms%n", warmResult, warmElapsedMs);
        System.out.printf("Speedup after full warmup: %.1fx%n", (double) osrElapsedMs / Math.max(warmElapsedMs, 1));
    }
}

JIT Profiling Internals: What Data the JVM Collects and How It Drives Optimizations

The JIT's effectiveness depends entirely on the quality of profiling data it collects during interpretation and C1-compiled execution. The JVM tracks four primary types of profiling data: invocation counters (number of times a method is called), back-edge counters (loop iterations), branch probabilities (taken/not taken for each conditional), and type profiles for every polymorphic call site (which concrete types are seen and how often).

The type profile is stored in a structure called the MethodData Object (MDO). For each call site, the MDO records up to two types (monomorphic/bimorphic) or falls back to a full type histogram for megamorphic call sites. If type checks exceed the profiling budget (default 2 types for virtual calls, 1 for interface calls), the JIT gives up on inlining and uses a virtual dispatch table instead.

You can dump the complete profiling state of a running JVM using jcmd Compiler.print or by aggregating the output of -XX:+PrintMethodData. This is invaluable when debugging why a hot method isn't being optimized the way you expect. For example, if you see a call site is 'megamorphic' (4+ different types at the same site), no inline cache will save you — redesign the code to reduce type variance at that point.

One common production surprise: branch profiling is biased by warmup traffic. If your warmup phase uses different data distributions than production traffic, the branch probabilities recorded during profiling will be wrong, leading to mis-speculated code paths and more deoptimization when real traffic arrives.

# Dump compiled methods and their performance counters
jcmd <PID> Compiler.print

# Print the MethodData for all compiled methods (verbose)
java -XX:+PrintMethodData -XX:+UnlockDiagnosticVMOptions -jar app.jar 2>&1 | grep -E "(method|receiver type|profile)"

# Capture type profile snapshots every 10 seconds
while true; do
  jcmd <PID> Compiler.print > /tmp/jit_profile_$(date +%s).txt
  sleep 10
done

# To see if a specific method is compiled at which tier
jcmd <PID> VM.print_tiered_status | grep -A5 "method_name_here"

Why Java's JIT Compiler Is Not Optional — And Why It Took Over From Pure Interpreters

Every Java developer knows bytecode is platform-independent. That's the party trick. The dirty secret? Pure interpretation of that bytecode is catastrophically slow. Early JVMs proved that — a naive interpreter could be 10-100x slower than compiled C code. Not acceptable for anything beyond a calculator app.

The JIT compiler exists to bridge that gap without sacrificing portability. It watches which methods are hot — called frequently enough to justify the compilation cost — and then converts their bytecode into native machine code. Once compiled, the CPU executes that native code directly. No interpreter overhead. No repeated translation. Just raw speed.

Here's the critical distinction most tutorials gloss over: JIT compilation is not free. The compilation itself burns CPU cycles and memory. That's why the JVM is patient. It waits, collects profiling data, and only compiles when the payoff is real. This cost-benefit analysis is what separates a well-tuned JIT from a garbage one. Misconfigure it, and you'll spend more time compiling than executing.

// io.thecodeforge — cs-fundamentals tutorial

import time

def interpreted_hot_path(iterations):
    # Simulates bytecode interpretation overhead
    result = 0
    for i in range(iterations):
        # Each iteration 'interprets' the addition
        result += i * 3 - 2
    return result

# Simulate JIT: compile once, run many times
compiled_func = lambda n: sum(i * 3 - 2 for i in range(n))

# Warmup for JIT simulation
for _ in range(1000):
    compiled_func(100)

iterations = 5000000

start = time.perf_counter()
total = interpreted_hot_path(iterations)
print(f"Interpreted: {time.perf_counter() - start:.4f}s, result={total}")

start = time.perf_counter()
total = compiled_func(iterations)
print(f"Compiled:    {time.perf_counter() - start:.4f}s, result={total}")

How the JIT Compiler Works: Profiling, Queuing, and the Compiler Threads You Didn't Know Existed

The JIT compiler doesn't just randomly compile methods. It's a disciplined, feedback-driven system. Here's the actual flow: when a method is invoked, the interpreter runs it and the JVM's profiling subsystem starts collecting metrics — invocation counts, loop back-edge counts, branch taken/not-taken ratios. These counters live in the method's metadata, not some separate log file.

Once the invocation count hits a configurable threshold (CompileThreshold), the method gets queued for compilation. But here's the gotcha: compilation happens on dedicated compiler threads, not the application threads. HotSpot has separate thread pools for C1 (client, quick compile) and C2 (server, aggressive optimization). If all compiler threads are busy, new requests go into a queue. If the queue overflows, methods stay interpreted until a thread frees up.

This queue depth is a silent performance killer. I've seen production incidents where a burst of traffic flooded the compiler queue, causing interpreted execution to spike and response times to crater. The fix? Tune -XX:CICompilerCount and -XX:CompileThreshold. More threads for big workloads, lower thresholds for latency-sensitive apps. Defaults are for laptops, not Netflix.

The compilation itself is asynchronous. The application thread continues interpreting until the compiled code is ready. Then the JVM performs an on-stack replacement (OSR) or waits for the next invocation to use the native version. That's why your first thousand requests are slow — they're being interpreted while the JIT is warming up.

// io.thecodeforge — cs-fundamentals tutorial

import time
import threading
from queue import Queue

# Simulate JIT compiler queue with limited workers
def compile_method(method_name, complexity):
    time.sleep(0.01 * complexity)  # Simulate compilation time
    print(f"[JIT] Compiled {method_name}")

compiler_queue = Queue()
max_workers = 2  # Simulate -XX:CICompilerCount

def compiler_worker():
    while True:
        method, complexity = compiler_queue.get()
        compile_method(method, complexity)
        compiler_queue.task_done()

# Start compiler threads
workers = []
for _ in range(max_workers):
    t = threading.Thread(target=compiler_worker, daemon=True)
    t.start()
    workers.append(t)

# Simulate methods being called and queued
hot_methods = [("processOrder", 5), ("validatePayment", 3), ("calculateTax", 4)]

print("Application starts — interpreting methods...")
for method, complexity in hot_methods:
    compiler_queue.put((method, complexity))
    print(f"[Queue] {method} enqueued (depth={compiler_queue.qsize()})")

# Wait for compilation to complete
compiler_queue.join()
print("All methods compiled — application now running native code.")

Tiered Compilation: V8 TurboFan, JVM C1/C2

Tiered compilation is a strategy used by modern JIT compilers to balance startup performance and peak throughput. Instead of compiling all code at the highest optimization level immediately, execution begins in an interpreter or a simple compiler, and hot methods are progressively recompiled with more aggressive optimizations. The Java Virtual Machine (JVM) implements tiered compilation with two primary compilers: C1 (client) and C2 (server). C1 performs lightweight optimizations and compiles quickly, reducing warmup time. C2, on the other hand, applies extensive optimizations like inlining, loop unrolling, and escape analysis, but takes longer to compile. The JVM monitors method invocation counts and loop back-edge counts to decide when to upgrade from C1 to C2. Similarly, V8, the JavaScript engine in Chrome and Node.js, uses a tiered system: it starts with an interpreter (Ignition) and then compiles hot functions with the baseline compiler (Sparkplug) and finally with the optimizing compiler (TurboFan). TurboFan performs speculative optimizations based on type feedback and can deoptimize if assumptions are violated. For example, a JavaScript function that always receives integers might be compiled assuming integer arithmetic, but if a string is passed, TurboFan deoptimizes to the interpreter. This tiered approach ensures that code runs quickly during startup while still achieving near-native performance for long-running applications. In production, understanding tiered compilation helps in tuning warmup strategies, such as using -XX:TieredStopAtLevel to force a specific compilation level for testing.

public class TieredExample {
    public static void main(String[] args) {
        long start = System.nanoTime();
        for (int i = 0; i < 100000; i++) {
            compute(i);
        }
        long end = System.nanoTime();
        System.out.println("Time: " + (end - start) / 1e6 + " ms");
    }

    static int compute(int x) {
        return x * 2 + 1;
    }
}

AOT vs JIT vs Interpreter: Performance Comparison

Ahead-of-time (AOT) compilation, just-in-time (JIT) compilation, and interpretation represent three execution strategies with distinct trade-offs. Interpreters execute source code or bytecode directly without translation, offering fast startup and low memory overhead but poor peak performance. JIT compilers translate code at runtime, initially interpreting and then compiling hot paths to native code, achieving high peak performance at the cost of warmup time and memory for compiled code. AOT compilers pre-compile code to native binaries before execution, eliminating warmup entirely and providing consistent performance, but they lack runtime profiling and can miss platform-specific optimizations. For example, a simple loop that sums integers: in an interpreter, each iteration incurs dispatch overhead; in a JIT, the loop is compiled to efficient machine code after a few iterations; in AOT, the loop is already native but may not be as optimized as JIT's adaptive techniques. Consider a Java application: startup with the interpreter is immediate, but throughput is low. With JIT (C2), after warmup, throughput can be 10-100x higher. AOT (e.g., GraalVM native image) starts instantly and has consistent performance, but peak throughput may be 20-30% lower than JIT due to lack of profile-guided optimizations. For JavaScript, V8's JIT can optimize hot functions based on type feedback, while AOT compilation (e.g., with WebAssembly) sacrifices that adaptability. In practice, the choice depends on use case: microservices with short-lived processes benefit from AOT's fast startup; long-running servers benefit from JIT's peak performance; scripting and prototyping favor interpreters. Modern runtimes often combine all three: e.g., JVM uses interpreter + C1 + C2, and GraalVM offers AOT as an alternative.

# Simulating interpreter vs JIT vs AOT
import time

def compute(n):
    total = 0
    for i in range(n):
        total += i
    return total

# Interpreter-like (no optimization)
start = time.time()
result = compute(10**7)
print(f"Time: {time.time() - start:.2f}s")

Deoptimization: How JITs Recover from Incorrect Assumptions

Deoptimization is a mechanism that allows a JIT compiler to revert from optimized native code back to a less optimized state (often the interpreter) when the assumptions made during compilation are invalidated. This is crucial for speculative optimizations, where the compiler assumes certain runtime conditions (e.g., a variable is always an integer, a method is monomorphic, or a class is never subclassed). If those assumptions break, the compiled code may produce incorrect results, so the JVM or V8 must deoptimize to a safe execution point. For example, in Java, the JIT may inline a virtual method call assuming only one implementation exists. If a new subclass is loaded later, the compiled code is invalidated, and the execution transfers to the interpreter at a deoptimization point. This process involves reconstructing the interpreter state from the optimized code's state, which can be expensive. In V8, TurboFan uses type feedback to optimize JavaScript functions. If a function is called with a new type, TurboFan deoptimizes and recompiles with updated feedback. Deoptimization can cause significant latency spikes—up to 250x in extreme cases due to class loading triggering deoptimization across many methods. To mitigate, JVMs use techniques like on-stack replacement (OSR) to transition smoothly and avoid recompilation storms. In production, monitoring deoptimization events (e.g., with -XX:+PrintDeoptimization) helps identify problematic assumptions. For instance, if a hot method frequently deoptimizes due to class loading, consider using -XX:CompileCommand to exclude it from compilation or restructure code to reduce polymorphism. Understanding deoptimization is key to writing JIT-friendly code: avoid megamorphic call sites, use final classes/methods, and minimize dynamic class loading in hot paths.

public class DeoptExample {
    interface Shape { int area(); }
    static class Circle implements Shape {
        int r;
        Circle(int r) { this.r = r; }
        public int area() { return (int)(Math.PI * r * r); }
    }
    static class Square implements Shape {
        int s;
        Square(int s) { this.s = s; }
        public int area() { return s * s; }
    }
    public static void main(String[] args) {
        Shape shape = new Circle(5);
        long sum = 0;
        for (int i = 0; i < 100000; i++) {
            sum += shape.area(); // monomorphic call site
        }
        // Later, introduce a new type
        shape = new Square(4);
        for (int i = 0; i < 100000; i++) {
            sum += shape.area(); // now megamorphic, may deoptimize
        }
        System.out.println(sum);
    }
}