Implement Deoptimization in JIT

Bail Out When Assumptions Fail

Optimized JIT code assumes types, shapes, and constant values. When reality diverges, deoptimization reconstructs the interpreter frame and resumes in the safe tier. HotSpot's uncommon_trap and V8's deopt points are critical for correctness.

Deopt Metadata

Record mapping from optimized registers and stack slots back to interpreter locals. On guard failure, call runtime to rebuild frame, invalidate optimized code, continue interpreting.

cCopy
Loading…

• Every guard has associated deopt reason
• OSR entry needs exit paths too
• Invalidated code must not be re-entered
• Debugging deopt bugs is notoriously hard

Connecting to real compilers

Production compilers embed this step inside a longer pipeline. GCC flows through cpp, cc1, assembly, and ld; Clang uses the driver, Sema, LLVM IR passes, and a target backend. LLVM bitcode, JVM bytecode, and WASM are other familiar IRs at the same layer. The exercise isolates one pass so you can test it alone before chaining it to the next stage.

Why for this exercise

You will implement deoptimization in your JIT. This exercise asks you to emit guard checks, maintain deopt maps, and transfer control back to the interpreter when speculative assumptions fail.