deletions | additions       diff --git a/overview.tex b/overview.tex  index b2769e0..9c69e9b 100644  --- a/overview.tex  +++ b/overview.tex 
...
Consider the generic OSR scenario shown in \ifauthorea{Figure~}{}\ref{fi:osr-dynamics}. A base function \fbase\ is executed and it can either terminate normally (dashed lines), or an OSR event may transfer control to a variant \fvariant. The decision of whether an OSR should be fired at a given point \osrpoint\ of \fbase\ is based on an {\em OSR condition}. A typical example in JIT-based virtual machines is a profile counter reaching a certain hotness threshold, which indicates that \fbase\ is taking longer than expected and is worth optimizing. Another example is a guard testing whether \fbase\ has become unsafe and execution needs to fall back to a safe version \fvariant. This scenario includes deoptimization of functions generated with aggressive speculative optimizations.   Classical OSR implementations adjust the stack so that execution can continue in \fvariant\ with the current frame \mynote{add citations}. \cite{chambers1992design}.  This requires manipulating the program state 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~\cite{Lameed_2013} \mynote{cite WebKit}. call~\cite{Lameed_2013,webkit14}.  Our implementation targets two general scenarios: 1) {\em resolved OSR}: \fvariant\ is known before executing \fbase\ as in the deoptimization example discussed above; 2) {\em open OSR}: \fvariant\ is generated when the OSR is fired, supporting deferred compilation strategies. In both cases, \fbase\ is instrumented before its execution to incorporate the OSR machinery. We call such OSR-instrumented version \fosrfrom. 
...
The open OSR scenario is similar, with one main difference (see \ifauthorea{Figure~}{}\ref{fi:overview-osr-open}): instead of calling \fosrto\ directly, \fosrfrom\ calls a stub function \fstub, which first creates \fosrto\ and then calls it. Function \fosrto\ is generated by a function {\tt gen} that takes the base function \fbase\ and the OSR point \osrpoint\ as input. The reason for having a stub in the open OSR scenario, rather than directly instrumenting \fbase\ with the code generation machinery, is to minimize the extra code injected into \fbase. Indeed, instrumentation may interfere with optimizations, e.g., by increasing register pressure and altering code layout and instruction cache behavior.  %\subsection{Discussion}  %\label{ss:discussion}  \paragraph{Discussion.}  Instrumenting functions for OSR at a higher level than machine code yields several benefits:   \begin{enumerate} 
...