deletions | additions       diff --git a/artifact/artifact.tex b/artifact/artifact.tex  index 9762cfd..c186296 100644  --- a/artifact/artifact.tex  +++ b/artifact/artifact.tex 
...
The main component of the artifact is an interactive VM called \tinyvm\ built on top of the LLVM MCJIT runtime environment and the \osrkit\ library. The VM provides an interactive environment for IR manipulation, JIT-compilation, and execution of functions either generated at run-time or loaded from disk: for instance, it allows the user to insert OSR points in loaded functions, run optimization passes on them, display their CFGs, and repeatedly invoke a function for a specified amount of times. \tinyvm\ supports dynamic library loading and linking, and includes a helper component for MCJIT that simplifies tasks such as handling multiple IR modules, symbol resolution in presence of multiple versions of a function, and tracking machine-level generated code and data objects.  \tinyvm\ is located in {\small\tt /home/osrkit/Desktop/tinyvm/} and runs a case-insensitite case-insensitive  command-line interpreter: \begin{small}  \begin{verbatim}  osrkit@osrkit-AE:~/Desktop/tinyvm$ tinyvm  diff --git a/artifact/session1.tex b/artifact/session1.tex  index 0bd437e..e63b337 100644  --- a/artifact/session1.tex  +++ b/artifact/session1.tex 
...
\end{verbatim}  \end{small}  \noindent The method returns $1$ as result, which means indicating  that the vector is ordered. Compared to \myfigure\ref{fig:isordascto}, IR code generated for the OSR continuation function {\tt isordto} ({\tt DUMP isordto}) is slightly different as the MCJIT compiler detects that additional optimizations (e.g., loop strength reduction) are possible and performs them. them right away.  We expect code generated for {\tt isord\_stub} to be identical up to renaming to the IR reported in \myfigure\ref{fig:isordstub}. To show native code generated by the MCJIT back-end, we can run \tinyvm\ under {\tt gdb} in a debugger with {\small\tt gdb tinyvm}  and leverage the debugging interface of MCJIT. For instance, once {\tt driver} has been invoked, we can switch to the debugger with {\tt CTRL-Z} and display the x86-64 code for any compiled method with: \begin{small}  \begin{verbatim}  (gdb) disas isordto 
...
\end{verbatim}  \end{small}  Assuming that the steps described above are executed   Native code [...] {\tt gdb} [...]  %In a usage scenario in which input arrays are large, we might want \noindent To return  to perform dynamic inlining as early as possible. We \tinyvm, we  can thus insert use the {\tt fg} command of {\tt gdb}.  diff --git a/artifact/session2.tex b/artifact/session2.tex  index 25ff016..4270f6b 100644  --- a/artifact/session2.tex  +++ b/artifact/session2.tex 
...
\subsubsection{Session 2: Performance Figures}  The experiments can be repeated by executing scripts on a selection of the \shootout\ benchmarks~\cite{shootout}. Each benchmark was compiled in to LLVM IR using  {\tt clang} with both {\tt -O0} and {\tt -O1}. as described in \mysection\ref{ss:bench-setup}.  For each benchmark {\tt X}, {\tt tinyvm/shootout/X/} contains the unoptimized and optimized ({\tt -O1}) IR code, each in two versions: \begin{itemize}[parsep=0pt]  \item {\tt bench} and {\tt bench-O1}: IR code of the benchmark;  %\item {\tt codeQuality}: IR code of the benchmark with the hottest loop instrumented with a never-firing OSR;  \item {\tt finalAlwaysFire} and {\tt finalAlwaysFire-O1}: IR code of the benchmark preprocessed by turning the body of slicing  the hottest loop into a separate function when needed  (see \ref{ss:experim-results}). \end{itemize}  \noindent Each experiment runs a warm-up phase followed by 10 identical trials. We manually collected the figures from the console output and analyzed them, computing confidence intervals. We show how to run the code using {\tt n-body} as an example. Times reported in this section have been measured in VirtualBox on an Intel Core i7 platform, a different setup than the one discussed in \ref{ss:bench-setup}. 
...
\noindent which loads the IR code, performs a warm-up execution of the benchmark, and then 10 repetitions. The experiment duration was $\approx1$m, with a time per trial of $\approx5.725$s.   The benchmark with the hottest loop instrumented with a never-firing OSR point  can be run as follows: with:  \begin{small}  \begin{verbatim} 
...
\end{verbatim}  \end{small}  \noindent Note that the second line inserts a never-firing open OSR point at basic block labeled with {\tt 8} \%8}  (actually {\tt :8}) in function {\tt bench} of file {\tt shootout/n-body/bench.ll}, using branch weight of 5\% as a hint for the LLVM native code generation back-end that OSR firing is very unlikely. The experiment duration was $\approx1$m with a time per trial of $\approx5.673$s. The ratio $5.673/5.725=0.990$ for {\tt n-body} is slightly smaller than the one reported in \ref{fig:code-quality-base} on the Intel Xeon. Xeon platform.  The experiment for building \ref{fig:code-quality-O1} uses scripts in {\tt bench-O1} and {\tt codeQuality-O1}. \paragraph{Question Q2.} This experiment assesses the run-time overhead of an OSR transition by measuring the duration of an always-firing OSR execution and of a never-firing OSR execution, and reporting the difference averaged over the number of fired OSRs. The always-firing OSR execution for {\tt n-body} (unoptimized) is as follows:  \begin{small} 
...
\end{verbatim}  \end{small}  \noindent The second line inserts an always-firing resolved OSR point at instruction labeled with the beginning of basic block  {\tt \%entry} in function {\tt advance} of file {\tt {\small\tt  shootout/n-body/finalAlwaysFire.ll}, generating a continuation function called {\tt advance\_OSR}. A branch weight of 95\% is given as a hint for the LLVM native code generation back-end that OSR firing is a high-probability event. The time per trial was $\approx5.876$s. The never-firing OSR execution used as baseline is as follows:  \begin{small} 
...
\end{verbatim}  \end{small}  \noindent Notice that in a virtualized environment there may be significant fluctuations in the reported times across different trials. trials, as we rely on a high-resolution timer for measurements\footnote{\url{http://www.ncbi.nlm.nih.gov/pmc/articles/PMC4503740/}.}.