deletions | additions       diff --git a/experim.tex b/experim.tex  index 6fd49cf..6d597de 100644  --- a/experim.tex  +++ b/experim.tex 
...
For {\tt b-trees} - the only benchmark in our suite showing a recursive pattern - we insert an OSR point in the body of the method that accounts for the largest {\em self} execution time of the program. Such an OSR point might be useful to trigger recompilation of the code at a higher degree of optimization, or to enable some form of dynamic optimization (for instance, in a recursive search algorithm we might want to inline the comparator method provided by the user at the call).  Results for the unoptimized and optimized versions of the benchmarks are reported in Figure~\ref{fig:code-quality-base} and \ref{fig:code-quality-O1}, respectively. For both scenarios we observe that the overhead is very small, i.e. less than $1\%$ for most benchmarks and less than $2\%$ in the worst case. In some cases, code might run slightly faster after OSR point have been inserted due to cache and instruction alignment effects. We analyzed the code produced by the x86_64 back-end: the OSR machinery is lowered into three native instructions that load a counter in a register, compare it against a constant value and jump to the OSR block accordingly. The number of times the OSR condition is checked in for  each benchmark is identical to those reported for the same as in  the experiments reported  in Table~\ref{tab:sameFun} Table~\ref{tab:sameFun}.    \paragraph{Overhead of OSR transitions}