dcdelia  over 8 years ago

Commit id: 913681c05f5944e073996ef72e694cacdc9eb35f

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. JIT;  McOSRis similar to \osrkit\ as it  encodes OSR entirely in LLVM IR. 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. Lessons However, lessons  from the Jikes RVM~\cite{fink2003design} suggest that generating a function to resume the execution (as \fosrto\ in \osrkit) is likely to yield better performance. \osrkit\ addresses a few 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 only; headers;  4) MCJIT does not allow to modify McOSR relies on features of the legacy JIT (e.g., updating and recompiling  a JIT-ted IR function, and is this function or module) that are  incompatible with McOSR's MCJIT's  design.