How does GraalVM's deoptimization mechanism work when a speculative optimization fails?

Both the Graal JIT and Native Image (for optimizations based on runtime profile assumptions) sometimes compile code based on a speculative assumption - for example, "this call site has only ever seen one concrete implementation, so inline it directly" - that might later turn out to be wrong.

sequenceDiagram
  participant Opt as Optimized code
  participant Runtime as Graal Runtime
  participant Interp as Interpreter/Uncommon trap handler
  Opt->>Opt: Assumption violated (e.g. new subtype seen)
  Opt->>Runtime: Trigger deoptimization
  Runtime->>Interp: Reconstruct interpreter state from compiled frame
  Interp->>Interp: Resume execution correctly in interpreter/lower tier
  Interp-->>Runtime: Optionally recompile with updated profile

When the assumption is violated at runtime, an uncommon trap fires: execution bails out of the optimized machine code, the runtime reconstructs an equivalent interpreter (or lower-tier) execution state from the compiled frame's metadata, and execution resumes correctly from that point - guaranteeing the program never produces wrong results even though it took an optimistic shortcut.

If the same code path deoptimizes repeatedly, Graal will eventually recompile it with the new, more general profile information rather than repeatedly guessing wrong and paying the deopt cost over and over.