deletions | additions       diff --git a/approach.tex b/approach.tex  index f802c3b..ee82d40 100644  --- a/approach.tex  +++ b/approach.tex 
...
Classical OSR implementations adjust the stack so that execution can continue in \fvariant\ with the current frame \mynote{add citations}. 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 \mynote{cite WebKit and McVM}.   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. Instrumentation consists of adding a check of the OSR condition. If condition and, if  the condition is satisfied, \fosrfrom\ a function call that  fires the OSR via OSR, followed by  a regular return statement. The assumption is that the called  function call. produces the same side-effects and return values that one would obtain by \fbase\ if no OSR were performed.  In the resolved OSR scenario (see Figure~\ref{fi:overview-osr-final}), the OSR invokes an instrumented version of \fvariant\ called \fosrto, passing to it {\em all variables that are live at the OSR point}. Notice that, differently from \fvariant, \fosrto\ takes as input the live variables of \fbase\ at \textsf{L}.    %and returns the same value when it has terminated.The assumption is that the called function produces the same side-effects and return values that one would obtain by \textsf{f} if no OSR were performed.  %\ref{fi:overview-osr-final} 
...