Mechanically, how does the JVM turn an optimized compiled stack frame back into interpreter frames, given that the compiler may have inlined several callees into it, kept values only in registers, and eliminated object allocations entirely?

## The problem statement Optimized code and interpreter code have almost nothing in common. The interpreter has a rigid frame layout: an array of locals, an operand stack, a reference to the method, and a bytecode pointer. Optimized code has none of that — values live in machine registers or arbitrary stack slots, several source methods may have been merged into one frame by inlining, some computations were removed as dead, and some objects were never allocated at all. Deoptimization must produce, from that, a state the interpreter can continue from, such that the program cannot tell the difference. The only way this is possible is if the compiler records how to do it *at compile time*. ## Debug information: scope descriptors and virtual frames Alongside the machine code, an nmethod stores debug metadata for every point where deoptimization may occur — every safepoint and every uncommon trap. At each such point the metadata is a **chain of virtual frames**, innermost first. Each virtual frame carries: - the **method** it belongs to (so an inlined callee is represented explicitly), - the **bytecode index** at which that method is currently "executing", - a **location** for each local slot and each expression-stack slot: a physical register, a stack slot, a constant, or a marker saying the value is dead / not needed, - monitor information: which objects are locked in that frame, - an oop map so GC knows which of those locations hold references. This is why a heavily inlined compiled frame can still produce an honest-looking Java stack trace: the same metadata backs `StackWalker` and exception stack traces, not just deoptimization. The cost is real: debug info can be a substantial fraction of an nmethod's memory, and it is emitted even for code that never deoptimizes. The runtime pays it because without it aggressive optimization would be unsound. ## The reconstruction sequence When a trap fires (or an external request such as a broken dependency demands it), the thread reaches a safepoint state and the runtime: 1. **Locates the debug info** for the exact return address / trap site in the compiled frame. 2. **Decodes the virtual-frame chain**, computing how many interpreter frames are needed and how large each must be. 3. **Reads out every value** from its recorded location — registers are captured from the saved register set, stack slots read from the physical frame, constants materialized. 4. **Rematerializes eliminated objects.** If escape analysis proved an object did not escape, the compiler may have scalar-replaced it: no allocation happened and its fields lived in registers. The interpreter, however, needs a real object reference. So the runtime allocates it now and stores the recorded field values into it. (This is also why deoptimization can, in principle, allocate — and why it can even surface memory pressure.) 5. **Reacquires eliminated locks.** If the compiler elided or coarsened monitors on non-escaping objects, the reconstructed frames must show those monitors held, so the runtime relocks them. 6. **Unpacks the frames.** The compiled frame is replaced by the computed interpreter frames — physically, the stack is unrolled and rewritten. Because N interpreter frames are usually larger than the one compiled frame they replace, the stack grows here; pathological deopt of a deeply inlined frame is one of the few places this matters. 7. **Resumes** in the interpreter at the innermost virtual frame's bytecode index, with the operand stack and locals exactly as the bytecode semantics require. Execution continues as though the method had been interpreted from the start. Side effects already performed are not repeated, because the recorded bytecode index is a point at which the compiled code's observable state is consistent with the bytecode's — the compiler is obliged to keep a valid deopt state at every possible trap. ## Consequences worth knowing - **Deoptimization is expensive** compared to normal execution: metadata decoding, possible allocation, relocking, stack rewriting, plus running interpreted afterwards. It is cheap compared to being *wrong*, which is the point. - **The compiler is constrained by deopt.** It cannot reorder or eliminate a side effect across a possible trap point in a way that would make the recorded state unreconstructible. "Must maintain a valid deopt state" is a real limit on optimization. - **Escape analysis is not undone by the possibility of deopt.** The compiler still elides allocations because rematerialization exists — a nice example of speculation and repair working together. - **Two directions exist.** Deoptimization moves execution from compiled code down to the interpreter; on-stack replacement moves a running interpreted loop up into compiled code. Both rely on the same kind of state mapping, in opposite directions. - **Debugging interacts with it.** Setting a breakpoint or enabling certain JVMTI capabilities forces methods to be deoptimized so the interpreter is in control — which is exactly why a program under a debugger is slow and why timing measured there is meaningless. Being able to say "the compiler records, per trap site, a chain of virtual frames with a physical location for each value, and the runtime replays that chain into interpreter frames, rematerializing scalar-replaced objects" is the answer this question is looking for.