deletions | additions       diff --git a/approach.tex b/approach.tex  index 160d21d..357d425 100644  --- a/approach.tex  +++ b/approach.tex 
...
\subsection{Overview}  \label{ss:overview}  Consider the generic OSR scenario shown in Figure~\ref{fi:osr-dynamics}. A base function \textsf{f} is executed and it can either terminate normally (dashed lines), or an OSR event may transfer control to a variant \textsf{f'}. The decision of whether an OSR should be fired at a given point \textsf{L} is based on an {\em OSR condition}. A typical example is a guard testing whether a function \textsf{f} has become unsafe and a fallback to a safe version \textsf{f'} is in order. This may happen, e.g., if \textsf{f} was scenario includes deoptimization of functions  generated with aggressive speculative optimizations. Another example is a profile counter reaching a certain hotness threshold, which indicates that \textsf{f} is taking longer than expected and is worth optimizing. This is a frequent scenario in JIT-based virtual machines. Classical OSR implementations adjust the stack so that execution can continue in \textsf{f'} with the current frame \mynote{add citations}. This requires manipulating the program at machine code level and is highly ABI- and compiler-dependent. A simpler approach, which we follow in this article, consists of creating a new frame every time an OSR is fired, essentially regarding an OSR transition as a function call \mynote{cite WebKit and McVM}.   Our implementation targets two general scenarios: 1) \textsf{f'} is known before executing \textsf{f}, as in the deoptimization example discussed above. 2) \textsf{f'} is generated when the OSR is fired, supporting deferred compilation strategies.  %\ref{fi:overview-osr-final}  %\begin{verbatim} 
...