This page describes how exceptions throwing and catching is implemented in the VM.
Dart VM's IL does not explicitly represent exceptional control flow in its flow graph, there are no explicit exceptional edges connecting potentially throwing instructions (e.g. calls) with corresponding catch blocks. Instead this connection is defined at the block level: all exceptions that occur in any block with the given
try_index will be caught by
CatchBlockEntry with the equal
For optimized code this means that data flow associated with exceptional control flow is also represented implicitly: due to the absence of explicit exceptional edges the data flow can‘t be represented using explicit phi-functions. Instead in optimized code each
CatchBlockEntry is treated almost as if it was an independent entry into the function: for each variable
CatchBlockEntry will contain a
Parameter(...) instruction restoring variable state at catch entry from a fixed location on the stack. When an exception is thrown runtime system takes care of populating these stack slots with right values - current state of corresponding local variables. It’s easy to see a parallel between these
Parameter(...) instructions and
Phi(...) instructions that would be used if exception control flow would be explicit.
How does runtime system populate stack slots corresponding to these
Parameter(...) instructions? During compilation necessary information is available in deoptimization environment attached to the instruction. This environment encodes the state of local variables in terms of SSA values i.e. if we need to reconstruct unoptimized frame which SSA value should be stored into the given local variable (see Optimized IL for an overview). However the way we use these information for exception handling is slightly different in JIT and AOT modes.
AOT mode does not support deoptimization and thus AOT compiler does not associate any deoptimization metadata with generated code. Instead deoptimization environments associated with instructions that can throw are converted into
CatchEntryMoves metadata during code generation and resulting metadata is stored
RawCode::catch_entry_moves_maps_ in a compressed form.
CatchEntryMoves is essentially a sequence of moves which runtime needs to perform to create the state that catch entry expects. There are three types of moves:
*(FP + Dst) <- ObjectPool[PoolIndex]- a move of a constant from an object pool;
*(FP + Dst) <- *(FP + Src)- a move of a tagged value;
*(FP + Dst) <- Box<Rep>(*(FP + Src))- a boxing operation for an untagged value;
When an exception is caught runtime decompresses the metadata associated with the call site which has thrown an exception and uses it to prepare the state of the stack for the catch block entry. See
NOTE: See this design/motivation document for
JIT mode heavily relies on deoptimization and all call instructions have (lazy) deoptimization environments associated with them. These environments are converted to deoptimization instructions during code generation and stored on the
When an exception is caught the runtime system converts deoptimization environment associated with the call site that threw an exception into
CatchEntryMoves and then uses it to prepare the state of the stack for the catch block entry. See
CatchEntryMoves dynamically from deoptimization instructions allows to avoid unnecessary duplication of the metadata and save memory: as deoptimization environments contain all information necessary for constructing correct stack state.
IMPORTANT: There is a subtle difference between DBC and other architectures with respect to catch block entry state. On normal architectures
Parameter(i) at catch entry would be associated with the same stack space that would be used to store variable with index
i. On DBC however at catch entry
Parameter(i) would be allocated to a separate scratch space at the very top of the register space. See