deoptimizationlisted

# Deoptimization ## Purpose Decide whether a deoptimisation is the JIT working correctly or a method that will never reach stable optimised code. C2 can optimise using profile assumptions protected by guards, or registered dependencies checked when the runtime changes. Deoptimisation preserves Java behavior when an assumption fails. Recorded trap history can change later compilation decisions. A bounded burst that decays under continued representative traffic can be normal; 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. Reuse supplied logs, workload history and prior checks. Establish the affected startup or steady-state service criterion, recovery authority and capture budget; ask only for missing facts that would change the next action. 2. **Collect the reason, the a