deletions | additions       diff --git a/abbrvshortnat.bst b/abbrvshortnat.bst  index 07437a7..9ba635a 100644  --- a/abbrvshortnat.bst  +++ b/abbrvshortnat.bst 
...
{ format.eid output }  if$  }  if$  format.issn %if$  %format.issn  output if $  format.doi output  format.url output  new.block  diff --git a/intro.tex b/intro.tex  index 1635681..ecfebe9 100644  --- a/intro.tex  +++ b/intro.tex 
...
A piece that is currently missing in the environment is a feature to enable on-the-fly transitions between different versions of a running program's function. This feature is commonly known as On-Stack-Replacement (OSR) and is typically used in high-performance virtual machines, such as HotSpot and the Jikes RVM for Java, to interrupt a long-running function and recompile it at a higher optimization level. OSR can be a powerful tool for dynamic languages, for which most effective optimization decisions can typically be made only at run-time, when critical information such as type and shape of objects becomes available. In this scenario, OSR becomes useful also to perform deoptimization, i.e. when the running code has been speculatively optimized and the assumption used for the optimization does not hold anymore, the optimized function is interrupted and the execution continues in a safe version of the code.  Currently VM builders using MCJIT are required to have a deep knowledge of the internals of LLVM in order to mimic a transitioning mechanism. In particular, they can rely on two experimental intrinsics, {\em Stackmap} and {\em Patchpoint}, to inspect the details of the compiled code generated by the back-end and to patch it manually with a sequence of assembly instructions. In particular, a Stackmap records the location of live values at a particular instruction address and during the compilation it is emitted into the object code within a designated section; a Patchpoint instead allows to reserve space at an instruction address for run-time patching and can be used to implement an inline caching mechanism~\cite{deutsch1984inlinecaching, mechanism~\cite{webkit14}.%~\cite{deutsch1984inlinecaching,  webkit14}. %In a 2013 paper  Lameed and Hendren propose McOSR~\cite{lameed2013modular}, a technique for OSR that essentially stores the live values in a global buffer, recompiles the current function and then loads in it the saved state when the execution is resumed. Their approach shows a few limitations that we discuss later on in this paper, and because of some relevant design choices it can work only with the legacy JIT that has been dropped since LLVM's release 3.6.