deletions | additions       diff --git a/approach.tex b/approach.tex  index dce2b87..a1ea7ad 100644  --- a/approach.tex  +++ b/approach.tex 
...
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.  In the resolved OSR scenario (see Figure~\ref{fi:overview-osr-final}), instrumentation consists of adding a check of the OSR condition and, if it is satisfied, a function call that fires the OSR. OSR followed by a return statement.  The invoked function is an instrumented version of \fvariant, which we call \fosrto. The assumption is that \fosrto\ produces the same side-effects and return value that one would obtain by \fbase\ if no OSR were performed. Differently from \fvariant, \fosrto\ takes as input all live variables of \fbase\ at \textsf{L}, performs an optional compensation code ({\tt comp_code}) to fix the computation state, and then jumps to a point \textsf{L'} from which execution can continue. The OSR practice often makes the conservative assumption that execution can always continue from the same program state. However, this assumption may reduce the number of points where sound OSR transitions can be fired. The compensation code adds flexibility, allowing OSR transitions to happen at arbitrary places in the base function. %\ref{fi:overview-osr-final} 
...