One Compiler: Deoptimization to Optimized Code

Deoptimization enables speculative compiler optimizations, which are an essential part in nearly every high-performance virtual machine (VM). But it comes with a cost: a separate first-tier interpreter or baseline compiler in addition to the optimizing compiler. Because such a first-tier execution uses a fixed stack frame layout, this affects all VM components that need to walk the stack. We propose to use the optimizing compiler also to compile deoptimization target code, i.e., the non-speculative code where execution continues after a deoptimization. Deoptimization entry points are described with the same scope descriptors used to describe the origin of the deoptimization, i.e., deoptimization is a two-way matching of two scope descriptors describing the same abstract frame. We use this deoptimization approach in a high-performance JavaScript VM written in Java. It strictly uses a one-compiler approach, i.e., all frames on the stack (VM runtime, first-tier execution in an JavaScript AST interpreter, dynamic compilation, deoptimization entry points) originate from the same compiler. Code with deoptimization entry points generated by the optimizing compiler imposes a much smaller overhead than a traditional first-tier execution.