deoptimizationlisted

# Deoptimization ## Purpose Decide whether a deoptimisation is the JIT working correctly or a method that will never reach stable optimised code. Speculation is what makes C2 fast: it bets on a profiled assumption, embeds a check, and unwinds without ever producing a wrong result when the bet fails. The trap is recorded in method profiling data and can change later compilation decisions. A bounded burst that decays after recompilation is the design working; continued events at the same site require diagnosis rather than an assumption that all deoptimisation is benign. The failure this prevents is both directions of the same mistake — alerting on every `jdk.Deoptimization` event until the alert is ignored, and raising a recompilation cutoff so the JVM takes longer to give up on a method whose underlying assumption keeps changing. ## Workflow 1. **Establish whether the question is one method or a post-deploy pattern**, and fix a reference window (a deploy, a config change, a library or plugin rollout) to correlate against. Inspect the deployed vendor/build, compiler mode and flags alongside project toolchains; JDK 25 observations are not authorization to upgrade the target or enable flags. 2. **Collect the reason, the action and the compile id**, not just the fact. JFR `jdk.Deoptimization` (enabled in the baseline `default.jfc`; stacks enabled by `profile.jfc` or explicit event settings) for production, `-Xlog:deoptimization=debug` for a session. Both see