deletions | additions       diff --git a/experim.tex b/experim.tex  index 8d7e624..917294b 100644  --- a/experim.tex  +++ b/experim.tex 
...
\ifauthorea{\newline}{}  \paragraph{OSR machinery generation.}  We now discuss the overhead of the \osrkit\  library for the insertion of inserting  OSR machinery in the IR of a function. \mytable\ref{tab:instrTime} reports for each benchmark the number of IR instructions in the instrumented function, the number of live values to transfer and the time spent in the IR manipulation. Locations for OSR points are chosen as in the experiments about code quality.  For open OSR points, we report the time spent in inserting the OSR point in theoriginal  function and in generating the stub; both operations do not depend on the size of the function. For resolved OSR points, we report the time spent in inserting the OSR point and in generating the continuation function. Not surprisingly, constructing such a continuation  function takes longer than the other operations (i.e., up to 1 ms vs. 20-40 us), as it involves cloning and manipulating the body of the target function - that is in this case,  the source function itself - as described in Section {\bf XXX}; as the required  timespent in it  depends on the size of the function, the table also  contains an additional a  column in which time is normalized against the number of IR instructions in the function. \begin{table}   \begin{small} 
...
\ifauthorea{\newline}{}  \paragraph{Discussion.}  Experimental %Experimental  results presented in this section suggest that inserting an OSR point is unlikely to degrade the quality of generated code, and the time required to fire an OSR transition is negligible (i.e., order of nanoseconds). Instrumenting the original IR is cheap, while the cost of generating a continuation function - either when inserting a resolved OSR point, or from the callback method invoked at an open OSR transition - is likely to be dominated by the cost of its compilation. For a front-end, the choice whether to insert an OSR point into a function for dynamic optimization depends on the trade-off between the expected benefits in terms of execution time and the overhead for generating on optimized version of the function and eventually JIT-compiling it; compared to these two operations, the cost of OSR-related operations is negligible. Experimental results presented in this section suggest that inserting an OSR point is a quick operation and is unlikely to degrade the quality of generated code. The time required to fire an OSR transition is negligible (i.e., order of nanoseconds), while the cost of generating a continuation function - either when inserting a resolved OSR point, or from the callback method invoked at an open OSR transition - is likely to be dominated by the cost of its compilation. For a front-end, the choice whether to insert an OSR point into a function for dynamic optimization merely depends on the trade-off between the expected benefits in terms of execution time and the overheads from generating and JIT-compiling an optimized version of the functio; compared to these two operations, the cost of OSR-related operations is very likely to be negligible.