Explain the internal working of the Graal compiler's speculative optimizations?

Speculative optimization means the compiler generates code based on an assumption about runtime behavior that isn't provably always true, but is true often enough (based on collected profile data) to be worth betting on, backed by a safety net if the bet is wrong.

flowchart TD
  A[Collect profile data during interpretation/lower tier] --> B[Identify likely-true assumption]
  B --> C[Compile optimized code assuming it holds]
  C --> D[Attach guard/uncommon trap for the assumption]
  D --> E{Assumption holds at runtime?}
  E -->|Yes| F[Run fast optimized path, no overhead]
  E -->|No| G[Deoptimize back to interpreter/lower tier]

Common examples include type speculation (assuming a variable is always a specific concrete class, skipping the type check), monomorphic inlining (assuming a call site always targets the same method implementation, inlining it directly instead of a virtual dispatch), and branch probability speculation (laying out machine code assuming the historically more common branch is taken).

Each speculation is paired with a lightweight runtime guard; if the guard check fails, execution deoptimizes rather than silently producing wrong results, which is what makes it safe to be aggressive - the compiler can bet on the common case without risking correctness in the rare case.

This combination of "optimize for the common case, safety-net for the rare case" is a large part of why Graal-compiled code can outperform code compiled with only provably-safe optimizations.