Implement Deoptimization in JIT

Topic Overview

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.

Your Task

Implement deoptimization: run speculatively optimised code, and when one of its assumptions fails, rebuild the exact interpreter state at the failing instruction and finish the call in the interpreter: without the program noticing anything except speed.

Input

cCopy
Loading…

Functions are straight-line; instructions are numbered from pc 0. Several func and run lines may appear, functions before the runs that use them.

Semantics

• Interpreter (generic): a value is an integer (64-bit) or a float (double); + - * on two integers gives an integer, anything involving a float gives a float.
• Optimised code assumes every operand is an integer and every result fits in 32 bits. Before each instruction it checks, in order: left operand is an integer, right operand is an integer, then after computing, the result is within [-2³¹, 2³¹-1]. A failing check is a deopt with reason NAME is float (the first failing operand, using its name, or its literal text) or overflow.
• On deopt at pc i: the interpreter frame is the parameters plus every local assigned before pc i. The interpreter re-executes from pc i (the failed instruction has no effect in optimised code) and returns the result.
• Each function tolerates 2 deopts; after its second deopt it is marked not optimizable and later runs go straight to the interpreter.

Output

One line per run:

cCopy
Loading…

Arguments and values print as integers, or with %g if they are floats. The frame lists parameters then locals, in order of definition. After the second deopt of a function, append -> NAME marked not optimizable to that line.

Example

Input:

cCopy
Loading…

Output:

cCopy
Loading…

Requirements

1. A value type that is either an integer or a float, and one interpreter loop that can start at any pc with a given frame.
2. The optimised executor must stop at the failing instruction and hand over its frame.

Hidden tests cover a deopt in the middle of a function (so the frame contains computed locals), 32-bit overflow, float literals in the code, and a function that hits the deopt limit.