C2 produces significantly better optimized code, but it takes much longer to compile. For a method that runs one million times, spending five seconds compiling it pays off. For a method that runs ten thousand times and then returns, spending five seconds compiling it is pure waste — the compilation time exceeds the total execution time. Tiered compilation solves this by using C1 (which compiles in ~100ms) to get native code quickly for warmup, then promoting the truly hottest methods to C2 for peak performance. This delivers both fast startup and high throughput without forcing you to choose between them.

"Made not entrant" marks compiled code as inactive — new calls to that method will no longer use this compiled version. This happens when a method is deoptimized (assumptions violated) or when a newer compiled version replaces it. The existing activations of the old compiled code are allowed to run to completion; they become "zombie" code. "Deoptimized" specifically refers to an active compiled code frame being interrupted mid-execution and resumed in the interpreter. If you see "deoptimized" frequently, it indicates a problem — a compiled path is hitting conditions that invalidate its assumptions during normal execution.

The JVM tracks invocation counts separately for each compilation tier. After a method is compiled at tier 3 (C1 with full profiling), its invocation counter continues incrementing. When the count reaches the tier 4 threshold (default ~100,000, controlled by -XX:Tier4InvocationThreshold), the JVM queues the method for C2 compilation. The profiling data collected at tier 3 guides C2's optimization — type profiles, branch probabilities, and receiver histograms help C2 make better inlining and specialization decisions. If the method's hotness drops below a minimum threshold before promotion, it may never reach C2.

Deoptimization occurs when compiled code's assumptions are violated at runtime. Common causes include a call site becoming megamorphic (receiving more receiver types than expected), a class used in the compiled code being unloaded, an assumption about nullness or array length proving false, or the code cache filling and forcing eviction. When deoptimization occurs, the JVM marks the compiled code as non-entrant, existing activations run to completion, and new calls fall back to the interpreter (or a less-optimized compiled version). The JVM may then recompile with more conservative assumptions if the code is still hot. During deoptimization, the JVM must transfer control through a safepoint, which briefly pauses all Java threads.

On-stack replacement (OSR) lets the JVM replace the currently executing code of a method while it is still running — not just when a new invocation begins. This is essential for long-running server applications because a hot loop in a method might run for hours before the method naturally returns. Without OSR, the loop would execute interpreted code for its entire lifetime if its back-edge counter never reached the compilation threshold before the loop started. With OSR, the JVM detects the hot loop mid-execution, compiles a replacement version, and transfers control to the compiled code at the next loop back-edge. The application experiences a brief pause at the OSR transition point but immediately benefits from compiled performance for the remaining loop iterations.

The C1 and C2 compilers maintain separate compilation queues organized as priority heaps. When picking the next method to compile, the compiler selects the method with the highest "compilation benefit to cost ratio" — hotter methods with smaller bytecode bodies provide more return on compilation time investment. The JIT tracks estimated compilation cost (based on bytecode size, complexity metrics) and estimated benefit (based on current invocation count and measured speedup from previous compilations). A method that runs 100,000 times and compiles in 50ms gets priority over a method that runs 10,000 times and compiles in 500ms. During burst load patterns, this prioritization prevents the queue from saturating with cold methods, but during sustained high load, the queue can still back up when the compilation throughput cannot keep up with the rate of methods becoming hot.

OSR and deoptimization are separate mechanisms that interact at transition points. OSR replaces running interpreted or lower-tier compiled code with higher-tier compiled code mid-execution. Deoptimization replaces compiled code that has become invalid with lower-tier or interpreted code. An OSR transition can trigger deoptimization if the OSR compilation itself makes assumptions that are later violated — for example, if an OSR-compiled loop later receives a type at a call site that it did not anticipate. Conversely, deoptimization can trigger OSR — when a method deoptimizes, if it is still hot, the JVM queues it for recompilation at a lower tier, and that recompilation can use OSR to re-enter compiled code at a later loop back-edge. The two mechanisms are designed to work together to keep hot code compiled at the appropriate tier despite changing runtime conditions.

Tiered compilation keeps multiple compiled versions of the same method in the code cache simultaneously — the same method may have a tier 1 C1 version, a tier 3 C1 version, and a tier 4 C2 version all coexisting. This is necessary because different versions serve different purposes: the older version may still be executing on threads that have not yet been deoptimized, and newer versions may be waiting for promotion. With single-tier compilation, only one version exists per method. When tiered compilation is aggressive and many methods are being compiled at multiple tiers simultaneously, the code cache fills faster. The JVM manages this through code cache flushing (-XX:+UseCodeCacheFlushing), which evicts cold (not currently executing) compiled methods when the cache reaches high occupancy. However, flushing can cause previously compiled methods to run interpreted if they become hot again, creating a performance dip that requires recompilation.

Tier 1 (C1 simple) kicks in at ~1,500 invocations — fast compilation with minimal profiling, producing native code quickly without deep optimization. The goal is startup acceleration: get some native code running as soon as possible. Tier 2 (C1 limited profiling) promotes at ~5,000 invocations and adds profiling for branch frequencies and type data, enabling better inlining decisions than tier 1. Tier 3 (C1 full profiling) at ~10,000 invocations collects complete type profiles, receiver type histograms, and call site target data — the same data C2 will use for aggressive optimization. Each tier exists to balance compilation time against optimization quality: faster compilation tiers produce less optimized code but do so quickly, while slower tiers produce better code but take longer. The promotion chain means the JVM invests compilation time progressively as a method proves its importance through sustained hotness.

If a method's invocation count drops below a minimum threshold before it is actually compiled by C2 (because C2 compilation takes time and the queue may be backed up), the method may wait in the C2 queue long enough that its hotness decreases. The JVM tracks "age" of compiled methods and may demote a tier 3 method to tier 2 if its hotness falls. When the method finally reaches C2 compilation, the compiler may decide the method is not worth full optimization if its bytecode is large and hotness is marginal. In practice, the threshold for C2 promotion is high enough (~100,000 invocations) that methods reaching C2 are almost always genuinely hot. If a method's hotness drops dramatically after deoptimization, the JVM may never recompile it at C2 — it stays at a lower tier or runs interpreted. This prevents spending expensive C2 cycles on code that is unlikely to recover its compilation cost.

-XX:TieredCompilationPolicy=simple|throughput|latency controls how the JVM selects methods for compilation. The default simple policy compiles methods when they reach tier thresholds (1,500 / 5,000 / 10,000 / 100,000). The throughput policy maximizes throughput by compiling more aggressively at lower tiers and prioritizing C2 compilation for the hottest methods — useful for long-running batch jobs. The latency policy reduces startup latency by prioritizing C1 compilation and limiting C2 queue saturation — useful for microservices with short request windows. You would switch from simple to throughput when running batch workloads that warm up fully, or to latency when running serverless functions or interactive applications where fast response matters more than peak throughput.

OSR compilation must produce a transition frame that is compatible with the interpreter's state at an arbitrary point mid-method — not just at the method entry. The JIT must capture the local variable values and operand stack contents at the OSR trigger point (usually a loop back-edge) and construct a compiled version that can resume from that exact state. This requires special handling in the compiled code: a "OSR entry point" that receives the interpreter's state and transforms it into the compiled stack layout. Regular compilation starts at the method entry with a known empty stack and local variable state. OSR additionally requires the JVM to transfer control at a safepoint while the method is actively running on an interpreter or lower-tier compiled code — this creates a brief pause at the OSR transition point. The complexity is why OSR-compiled code is often less optimized than regularly compiled code — the JIT has less freedom to reorder and restructure.

When a C2-compiled method is deoptimized (assumptions violated, class unloaded, type profile changed), the JVM marks the compiled code as non-entrant. New calls fall back to the interpreter. If the method is still hot (invocation counter still above the tier 3 threshold), the JVM queues it for recompilation — typically back to tier 3, where the profiling data collected before the deoptimization can be reused. If the method is less hot but still relevant, it may be recompiled at tier 2 or even tier 1 with more conservative assumptions. The key point is that C2 deoptimization is not the end — the method gets another chance at a lower optimization level with updated profile data. Each deoptimization cycle teaches the JIT more about the method's actual runtime behavior, often leading to a more stable compiled version on subsequent compilations.

In tiered compilation, lower thresholds (promoting methods to compilation sooner) cause more methods to be compiled at more tiers simultaneously, filling the code cache faster than non-tiered mode. A method compiled at tier 1, then tier 2, then tier 3, then tier 4 occupies four slots in the code cache simultaneously during the promotion chain. The default 48MB code cache was calibrated for non-tiered mode; with tiered compilation, you may need to increase -XX:ReservedCodeCacheSize to 100-256MB to avoid cache pressure from multiple versions per method. Lowering thresholds aggressively (-XX:CompileThreshold=1000) exacerbates this because it creates more compiled methods at lower tiers, all coexisting in the cache. The tradeoff is between warmup speed (lower thresholds) and code cache pressure (more compiled versions simultaneously).

Tiered compilation reduces P99 latency during warmup compared to non-tiered because C1 kicks in at 1,500 invocations, getting methods to native code in ~100ms rather than waiting for C2 (which takes seconds). This means the first few thousand requests already run on compiled code, even if not fully optimized. Without tiered, requests during warmup hit interpreted code or wait in the C2 queue, causing high P99. However, tiered introduces its own P99 spikes: when a method transitions from tier 1 to tier 2 or tier 2 to tier 3, the JVM must deoptimize and recompile, briefly returning to slower code. If many methods promote simultaneously (during a load spike), the queue saturates and P99 spikes as requests wait for compilation. The -XX:TieredCompilationPolicy=latency mode helps by being less aggressive with tier promotion, prioritizing compilation responsiveness over compilation depth.

Compilation regression occurs when a method is compiled at a lower tier (e.g., tier 3), runs for a while, is promoted to C2, and then the C2 compilation takes so long that the application experiences a performance dip before C2 code is ready. During C2 compilation, the tier 3 code may be made non-entrant, causing calls to run interpreted until C2 completes. If the method is very large or complex, C2 compilation can take many seconds, during which the application runs slower than it did at tier 3. This is called "compilation regression" — the method regresses in performance during compilation. The solution is often to use -XX:TieredStopAtLevel=3 to prevent promotion to C2 for very large methods, keeping them at tier 3 which is less optimized but more stable during the compilation period.

The regular compilation threshold is CompileThreshold (default 10,000), which controls when a method is considered hot enough to compile. OSR has its own trigger: OSR trigger = CompileThreshold * OnStackReplacementPercentage / 100, which with defaults (10,000 * 933 / 100) gives ~93,300. This OSR threshold is much higher because OSR is triggered by back-edge counters (loop iterations) rather than method invocations. A loop that iterates 93,000 times within a single method invocation triggers OSR. The OnStackReplacementPercentage=933 means OSR triggers at roughly 9.33x the regular threshold. This design ensures that OSR compilation targets long-running loops (which benefit most from compilation) rather than short loops that would finish before compilation would help. The OSR entry point is also more expensive to create than a regular entry point, so the JVM only creates OSR compilations for loops that are genuinely hot.

CPU limits affect the JIT compilation throughput because compilation requires CPU cycles. When the container has limited CPUs, the compilation threads (controlled by -XX:CICompilerCount, default 2-4 based on CPU count) compete with application threads for CPU time. With tiered compilation, more methods are being compiled more aggressively, increasing compilation CPU demand. Under CPU throttling, the compilation queue backs up, warmup takes longer, and tier promotion slows down. To mitigate, you can increase -XX:CICompilerCount to give the JIT more compilation threads (even under CPU limits, more compilation threads can finish sooner), or reduce tier thresholds so methods compile at simpler tiers sooner rather than waiting for deeper compilation. You can also use -XX:TieredStopAtLevel=3 to keep methods at C1 rather than promoting to C2, reducing compilation overhead at the cost of peak performance.

The interpreter is the source of profiling data that drives tier promotion. While executing bytecode, the interpreter increments invocation counters and back-edge counters, records branch taken/not-taken information, and tracks receiver types at virtual and interface call sites. When a method is promoted to tier 1, this profiling data is available immediately. At tier 2 and tier 3, additional profiling is layered on top — more detailed type information, call site targets, and exception frequency. When the method is finally compiled by C2, all this profiling data guides optimization decisions: which branches to prioritize, which call sites to inline, which types to assume. This data is preserved across tier transitions — tier 3 data carries forward to C2. If the method deoptimizes and recompiles, the accumulated profile data is used again. The interpreter is not just a slow fallback; it is an active profiler that enables intelligent compilation decisions.

-XX:TieredStopAtLevel=N stops tiered promotion at level N: 1 stops at C1 simple, 2 stops at C1 limited profiling, 3 stops at C1 full profiling, 4 allows C2. Setting TieredStopAtLevel=1 gives the fastest warmup because every method compiles only at tier 1 (~1,500 invocations) and never promotes to deeper tiers. The resulting code is less optimized than C2 but is produced quickly. Setting TieredStopAtLevel=3 gives moderate warmup (methods promote through tier 3 but not to C2) — useful when C2 compilation time is too long for the workload and the CPU budget for compilation is limited. The tradeoff is peak performance: TieredStopAtLevel=3 means the application never reaches the highest optimization level that C2 provides. For long-running batch jobs that warm up fully, default tiered (stop at 4) gives peak performance. For short-lived processes or serverless functions, stopping at tier 1 or 2 gives better time-to-maximum-performance.