A latency-sensitive JVM service shows recurring throughput dips, and its compilation output shows the same few methods being invalidated and recompiled over and over in steady state. How would you investigate whether repeated deoptimization is the cause, and what would you change?

## Step 1: establish that it is compilation at all Throughput dips have several common causes and they are distinguishable by evidence, not intuition. Before touching the JIT: - **GC?** Check the GC log for pauses of matching duration and frequency. Deopt dips do not correlate with allocation rate the way GC does. - **Safepoints?** `-Xlog:safepoint` reveals long time-to-safepoint or non-GC safepoint operations (revocation, deoptimization requests themselves) that stop all threads. - **Compilation?** `-XX:+PrintCompilation` timestamps, JFR's `jdk.Compilation` and `jdk.Deoptimization` events, and compiler-thread CPU usage. Overlay the timelines. Deoptimization-driven dips line up with clusters of `made not entrant` and re-compilations of the *same* methods. ## Step 2: characterize the deoptimizations The useful aggregation is (method, bytecode index, reason, count over time). - **Bounded and decaying** — a warmup phenomenon. Normal; either accept it or move it earlier with a warmup routine. - **Steady-state and recurring at the same site** — a real problem worth chasing. - **Correlated with class loading** — look at `-Xlog:class+load`. Something is loading classes in steady state: a lazily initialized plugin, per-type generated proxies or serializers, `Class.forName` on request data. Each new implementation can invalidate compiled code that assumed a unique implementor. Common reasons and what they mean: | Reason | Typical cause | |---|---| | `class_check` | receiver type at an inlined call site differs from the profile — polymorphism, proxies, per-tenant implementations | | `unstable_if` / `unreached` | a branch the profile called dead is now taken — changed traffic mix, feature flag flip, error path | | `null_check` | first nulls flowing where none were profiled | | `bimorphic` / `polymorphic` | a site outgrowing its guarded inline | | `constraint` / dependency invalidation | class loading broke a hierarchy assumption | ## Step 3: rule out the look-alikes - **Code cache exhaustion.** When the code cache fills, HotSpot flushes compiled methods and may disable compilation entirely (`CodeCache is full. Compiler has been disabled.`). The symptom — methods constantly recompiled, throughput sagging — mimics deopt churn, but there are no deopt events. Check code-cache usage via JFR/JMX and raise `ReservedCodeCacheSize` if it is genuinely tight. - **Compiler queue saturation.** Many classes loading at once starves compilation; methods run at lower tiers for long stretches. - **Profile pollution without deopt.** A megamorphic site simply compiles to a virtual dispatch — slower, but stable and deopt-free. That is a design cost, not churn. ## Step 4: change the cause, not the flags Ordered by how often they are the right answer: 1. **Reduce receiver variety at hot sites.** A generic helper called with dozens of implementations gets one shared, useless profile. Splitting it (duplicate the small helper, use per-type entry points, or make the site type-stable) restores monomorphic inlining. This is "profile pollution" and it is the most common real fix. 2. **Stop lazily loading in steady state.** Pre-create proxies, pre-load plugin implementations, eagerly initialize serializer/mapper caches so the hierarchy stabilizes during warmup. 3. **Stop using exceptions for expected outcomes.** Every rare-turned-common throw both costs directly and destabilizes a previously pruned path. 4. **Warm the real workload.** A warmup that exercises only the happy path leaves every alternate branch and type to be discovered in production. Warm with representative traffic, including errors and alternate types. 5. **Consider architectural stability.** If a hot path must be polymorphic across many types, accept virtual dispatch and optimize elsewhere — do not contort the design to chase inlining. 6. **Flags, last.** `-XX:PerMethodTrapLimit` / `-XX:PerBytecodeTrapLimit` change how quickly speculation is withdrawn; compiler directives (`-XX:CompilerDirectivesFile`) can disable inlining at a specific site. These are targeted, measurable-only-with-benchmarks interventions and they age badly across JDK upgrades. Never start here, and never ship one without a measurement and a comment explaining it. ## Step 5: decide whether it matters The honest principal-level answer includes a cost judgement. Deopt churn that costs a fraction of a percent of throughput is not worth a design change; the same churn producing multi-hundred-millisecond p99.9 outliers in a latency SLO is. Quantify the dip's contribution before restructuring code — and prefer changes that also improve the design (fewer megamorphic god-helpers, less lazy initialization, fewer exceptions on normal paths) over changes whose only justification is the compiler.