The JVM attaches an invocation counter to every method and loop back-edge counter to every loop. When a method is called or a loop iterates, the corresponding counter increments. Once a counter reaches the compilation threshold (default 10,000 for the server JVM), the JVM queues the method for JIT compilation. The JIT compiler picks methods from the queue based on priority — hotter methods with higher counter values are compiled first. After compilation, the counter continues running; if assumptions are violated, the method deoptimizes and the counter decrements, potentially triggering recompilation with different optimization levels.

On-stack replacement allows the JVM to replace the currently executing interpreted code of a method with compiled code while the method is still running. This is critical for long-running server applications where a method might take minutes to execute but contains a hot loop that runs thousands of times per second. Without OSR, the loop would have to finish before the compiled version could take over — which could take hours or never happen at all. With OSR, when the back-edge counter reaches the OSR threshold, the JVM creates a compiled version and seamlessly transfers execution to it at the next loop iteration boundary, even though the method never returned.

Escape analysis determines whether an object allocated within a method escapes the method's scope — meaning it could be accessed by another thread, stored to a heap field, or returned from the method. If the JIT compiler proves an object does not escape, it can apply three powerful optimizations. First, it can allocate the object on the stack instead of the heap, eliminating allocation and deallocation cost entirely. Second, it can eliminate synchronization locks on objects proven to be thread-local, as no other thread can access them. Third, it can scalar replace the object — replacing references to the object with the object's fields spread across registers and stack slots, eliminating the object allocation altogether. These optimizations can dramatically reduce GC pressure in code that allocates many short-lived objects.

When the code cache reaches its maximum size, the JVM disables JIT compilation entirely for the remainder of the process life. New methods and loops that become hot run in interpreted mode forever. This causes a dramatic, sudden performance drop that is easy to mistake for a GC pause or other issue. The JVM prints warning messages when the code cache reaches 90% and 98% occupancy. To avoid this, set -XX:ReservedCodeCacheSize large enough for your workload — typically 100MB to 256MB for large applications. You can also enable -XX:+UseCodeCacheFlushing (on by default) to evict cold compiled code and make room, though this risks deoptimizing previously compiled hot methods.

C1 (Client Compiler, also called c1.dll or tiered level 1-3) is the fast, low-optimization JIT compiler designed for quick compilation with minimal impact on application responsiveness. It produces native code faster than C2 but applies fewer aggressive optimizations — no advanced speculative optimizations, less aggressive inlining, no loop optimizations. C2 (Server Compiler, tiered level 4) is the slow, high-optimization compiler that takes much longer to compile but produces significantly faster code through aggressive inlining, escape analysis, range check elimination, loop unrolling, and speculative optimizations based on runtime type profiles. Tiered compilation uses C1 first (at lower invocation thresholds) to get quick native code for hot paths, then promotes the hottest methods to C2 for full optimization as they remain hot.

The JIT compiler inlines methods when the call site is hot enough and the method is small enough that the compile time cost pays for itself in reduced call overhead. Criteria include: method size (typically under 35 bytes of bytecode), call site frequency (hotter calls are inlined first), and type profile stability (monomorphic calls are better candidates than megamorphic). The -XX:MaxInlineLevel flag limits how many levels of nested calls can be inlined together — a depth of 9 means the JIT can inline a chain of 9 method calls into one compiled sequence. Beyond the inline level, other limits exist: -XX:FreqInlineSize limits the size of frequently called methods, and -XX:MaxInlineMethodBytecodes caps the total bytecode size of inlineable methods. Inlining across virtual call boundaries requires the JIT to prove the receiver type, which happens more often when the call is monomorphic.

Deoptimization occurs when compiled code's assumptions are violated at runtime — a call site becomes megamorphic, an assumption about nullness proves false, or a class used in the compiled code is unloaded. The JVM marks the compiled code as non-entrant (stops sending new calls to it) and existing activations are allowed to run to completion. This "zombie" code is later evicted when no threads are executing it. If the call site is still hot, the JVM queues the method for recompilation. On recompilation, the JIT compiler uses more conservative assumptions — for example, it may emit a type check before the previously speculated fast path, or it may avoid inlining across an interface that has become megamorphic. This create a compile-deoptimize-recompile loop that eventually converges to stable optimized code for stable runtime profiles.

The code cache has a fixed maximum size, and when it fills, the JVM disables JIT compilation entirely for the remainder of the process. New hot methods run interpreted, causing a sudden and dramatic performance drop — often 50% or more throughput reduction. Before the cache fills completely, the JVM prints warnings at 90% and 98% occupancy. Applications that compile thousands of methods (common in Spring-based microservices) can exhaust the default 48MB code cache. Symptoms include: JIT log showing VM warning: code cache is full, throughput dropping after running for hours (cache gradually fills), and profiling showing high interpreter tick frequency on previously fast paths. Increase -XX:ReservedCodeCacheSize to 100-256MB for large applications, and ensure -XX:+UseCodeCacheFlushing is enabled so the JVM can evict cold compiled code proactively.

The JIT compiler inlines methods when the call site is hot enough and the method is small enough that the compile time cost pays for itself in reduced call overhead. Criteria include: method size (typically under 35 bytes of bytecode), call site frequency (hotter calls are inlined first), and type profile stability (monomorphic calls are better candidates than megamorphic). The -XX:MaxInlineLevel flag limits how many levels of nested calls can be inlined together — a depth of 9 means the JIT can inline a chain of 9 method calls into one compiled sequence. Beyond the inline level, other limits exist: -XX:FreqInlineSize limits the size of frequently called methods, and -XX:MaxInlineMethodBytecodes caps the total bytecode size of inlineable methods. Inlining across virtual call boundaries requires the JIT to prove the receiver type, which happens more often when the call is monomorphic.

Deoptimization occurs when compiled code's assumptions are violated at runtime — a call site becomes megamorphic, an assumption about nullness proves false, or a class used in the compiled code is unloaded. The JVM marks the compiled code as non-entrant (stops sending new calls to it) and existing activations are allowed to run to completion. This "zombie" code is later evicted when no threads are executing it. If the call site is still hot, the JVM queues the method for recompilation. On recompilation, the JIT compiler uses more conservative assumptions — for example, it may emit a type check before the previously speculated fast path, or it may avoid inlining across an interface that has become megamorphic. This creates a compile-deoptimize-recompile loop that eventually converges to stable optimized code for stable runtime profiles.

Adaptive compilation is the JVM's strategy of making speculative bets based on observed runtime behavior. When a virtual call site consistently receives the same receiver type, the JIT compiler assumes this will continue and compiles the call as a direct call — eliminating virtual dispatch overhead. If the speculation proves wrong (a different type appears), the JIT deoptimizes and falls back to the interpreter or recompiles with a conservative type check. This approach allows the JVM to achieve near-native performance for real workloads while maintaining safety guarantees. For example, the JIT might assume a null check is never needed if the method has never returned null, and inline the fast path directly. If null is encountered, the deoptimization machinery unwinds to interpreter and triggers recompilation with the null check added. Speculative optimization explains why JIT-compiled code sometimes behaves differently from AOT-compiled code for the same source.

The JIT compiler collects type profiles at virtual and interface call sites during interpreted execution. Every time a call site executes, the JVM records the actual receiver type. Over time, the profile shows whether the site is monomorphic (one type), polymorphic (few types), or megamorphic (many types). For monomorphic sites, the JIT can devirtualize — replace the virtual call with a direct call to the known type's method, then add a type check that deoptimizes if a different type appears. For polymorphic sites, the JIT can emit a type switch that handles the known cases quickly and falls back to the slow path for unknown types. Megamorphic sites prevent most optimizations because the JIT cannot profitably inline any specific implementation. Type profiling data is carried through tier transitions, allowing C2 to specialize for the types it actually sees at runtime.

Regular method compilation begins when a method is invoked — a new call triggers the invocation counter, and when it reaches the threshold, the JVM queues the method for compilation. The compiled version executes on subsequent invocations. OSR (on-stack replacement) compilation begins while a method is already running — a hot loop inside the method triggers the back-edge counter while the method is active, and the JVM compiles a replacement version that can take over mid-execution. OSR is harder because the compiler must construct a transition frame that transfers local variables and operand stack state from the running interpreter to the compiled code, while ensuring all currently executing instructions see a consistent state. Regular compilation is simpler — it starts fresh with the method entry as the only entry point. The JVM uses OSR specifically for long-running server methods where a hot loop would otherwise never get compiled until the method returned.

Pure C2 compilation waits until a method reaches ~10,000 invocations before compiling — and C2 itself takes seconds to minutes to produce optimized code. This means an application runs interpreted for a long time before reaching peak performance. Tiered compilation introduces C1 at lower thresholds (~1,500 invocations) with fast, low-optimization compilation that produces usable native code in ~100ms. The hot method gets compiled quickly and starts running faster than the interpreter. As invocation counts grow, the method is promoted to C2 for full optimization, which takes longer but produces significantly faster code. The net effect is that the application reaches good performance sooner (C1 kicks in fast) and peak performance eventually (C2 takes over for the hottest methods). Without tiered compilation, you must choose between fast startup (skip C2) or high peak performance (wait for C2), but tiered gives you both.

The JIT compiler maintains separate compilation queues for C1 and C2. Methods are not served in FIFO order — the compiler picks methods based on a cost-benefit ratio: estimated compilation time divided by estimated performance benefit. Hotter methods with smaller bytecode bodies provide the best return on compilation investment. 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. The JIT tracks estimated compilation cost using bytecode size and complexity metrics, and estimated benefit using current invocation counts and measured speedups from previous compilations. When the queue saturates (burst load pattern), methods wait in the queue, causing warmup latency for requests that hit those methods. Increasing -XX:CICompilerCount (default: 2-4 based on CPU count) allows more parallel compilation threads, which helps when many methods become hot simultaneously.

Non-entrant code is compiled code that the JVM has marked as no longer accepting new calls — the call site no longer dispatches to this version. This happens during deoptimization when the assumptions the compiled code made are violated, or when a newer compiled version replaces an older one. Existing activations of the non-entrant code are allowed to finish executing — these are the "zombie" executions. When no threads are executing the zombie code, it becomes eligible for eviction from the code cache. Zombie code wastes space if it is never evicted, which is why the JVM has sweeping mechanisms to remove code that is both non-entrant and no longer in use. The distinction matters for debugging: "made not entrant" means the code is being deactivated but may still be running, while "zombie" means the code is no longer running at all but still occupies cache space until evicted.

When a class is unloaded, any compiled code that depends on that class becomes invalid — the compiled code may contain constant pool references, inline caches, and assumptions that no longer hold. The JVM marks affected compiled methods as non-entrant and triggers deoptimization for any currently executing frames. At the safepoint, the interpreter takes over for new calls to those methods. If the call site is still hot, the method is queued for recompilation — the recompilation will use the updated class list and avoid the unloaded class. Class unloading is triggered by GC when Metaspace approaches its limit, which means deoptimization from class unloading often occurs during GC pauses. With -XX:+ClassUnloading (default), the JIT compiler is more aggressive with optimizations because it knows classes can be unloaded to free space. Disabling class unloading (-XX:-ClassUnloading) makes the JIT more conservative because it cannot rely on classes being removed.

-XX:CompileThreshold (default 10,000) sets the base threshold for C2 compilation in non-tiered mode. In tiered mode, C1 thresholds are derived from CompileThreshold using tier-specific multipliers and offsets, not from the full C2 threshold. Tier 1 (C1 simple) kicks in at ~1,500 invocations (roughly CompileThreshold / 6). Tier 2 (C1 limited profiling) at ~5,000. Tier 3 (C1 full profiling) at ~10,000. Tier 4 (C2) at ~100,000. These are not direct multiples of CompileThreshold — they are hard-coded ratios that reflect the JVM's empirically determined sweet spots. Changing CompileThreshold only affects the base; it does not proportionally scale the tier thresholds. For aggressive tuning, you set tier thresholds directly via flags like -XX:Tier4InvocationThreshold=50000 rather than relying on CompileThreshold to cascade.

During interpreted execution, the JVM tracks how frequently each branch is taken — not just that a branch exists, but which direction is the common case. This profile is passed to the JIT compiler when it compiles the method. With branch probability data, the JIT can optimize by placing the common path linearly and the uncommon path in a side branch, improving instruction cache locality. The JIT can also eliminate branches entirely when one path is never taken (dead code elimination via profile data). For switch statements, the profile shows which cases are common and allows the JIT to emit a jump table with the hot cases first for faster dispatch. Branch probability also guides loop unrolling decisions — a loop that iterates 10 times on average but has an exit branch gets different unrolling treatment than one that iterates millions of times. This runtime profile is the key advantage JIT has over static compilers.

-XX:+PrintCompilation outputs one line per compilation event. The format is: <thread_id> <compilation_level> <method_name> <tier> <properties> @ <bytecode_offset> <reason>. A line like 3 1 Example.method() @ 42 osr means thread 3 compiled Example.method() at tier 1 (C1) at bytecode offset 42 via on-stack replacement. 3 1 Example.method() made not entrant @ 42 means the compiled version was deoptimized. The tier column shows 1-4 for C1 levels and 4 for C2. The properties column shows flags like % (osr), ! (has exception handler), s (synchronized). "made not entrant" marks code as inactive; "deoptimized" interrupts an active frame. You can correlate these with -XX:+LogCompilation output (XML) for deeper analysis with JITWatch. Frequent "made not entrant" or "deoptimized" entries indicate type profile instability or assumption violations.