Camil Demetrescu  over 8 years ago

Commit id: 6302bd92aa521dab2c2ae8e1760091db5d1250bd

deletions | additions      

       

%The generated stub calls a function inliner that generates a version of {\tt isord} where the comparator's body, pointed to by live variable {\tt c_osr}, is inlined in the loop body. The optimized version {\tt isordto} is shown in \myfigure\ref{fig:isordascto}.  \paragraph{Comparison with McOSR.}  McOSR~\cite{lameed2013modular} is a library for inserting open OSR points in the legacy LLVM JIT; McOSR encodes JIT, encoding the  OSR machinery  entirely in LLVM IR. IR as \osrkit\ does.  When an OSR is fired, live variables are stored into a pool of globals allocated by the library. McOSR then invokes a user-defined method to transform \fbase\ into \fvariant\ and calls \fbase\ with empty parameters. The new entrypoint of \fbase\ checks a global flag to discriminate if it is being invoked in an OSR transition or as a regular call: in the first case, the state is restored from the pool of global variables before jumping to the OSR landing pad. As the new entrypoint can disrupt LLVM optimizations and lead to poorer performance on subsequent invocations of \fbase, McOSR promptly recompiles \fbase\ after an OSR. However, lessons from the Jikes RVM~\cite{fink2003design} suggest that generating a dedicated  function to resume the execution (as \fosrto\ in \osrkit) \osrkit\ does with \fosrto)  is likely to yield better performance. \osrkit\ addresses improves over McOSR in a number of aspects, including: 1) support for multiple versions of a function active in memory at the same time; 2) support for resolved OSR and compensation code; 3) insertion of OSR points at arbitrary basic blocks, and not only at loop headers; 4) compatibility with the new MCJIT's design (e.g., updating and recompiling a JIT-ted function or module); 5) simpler design that does not require pools of globals to transfer live variables.  %\osrkit\ overcomes  a few number of  limitations of McOSR, including: 1) only one version of a function can be active in memory; 2) there is no provision for resolved OSR points or compensation code; 3) OSR points can be inserted only at loop headers; 4) McOSR relies on features of the legacy JIT (e.g., updating and recompiling a JIT-ted function or module) that are incompatible with MCJIT's design.