deletions | additions       diff --git a/prev-eval-sol.tex b/prev-eval-sol.tex  index 8685ca6..a5f3c29 100644  --- a/prev-eval-sol.tex  +++ b/prev-eval-sol.tex 
...
\subsection{Comparison to previous approaches}  \label{ss:prev-eval-sol}  Lameed and Hendren~\cite{lameed2013feval} proposed two dynamic techniques for optimizing \feval\ instructions in McVM: {\em JIT-based} and {\em OSR-based} specialization. Both attempt to optimize a function $f$ that contains instructions of the form \feval$(g,x,y,z...)$, leveraging information about $g$ and the type of its arguments observed at run-time. The optimization produces a specialized version $f'$ where \feval$(g,x,y,z...)$ instructions are replaced with direct calls of the form $g(x,y,z,...)$. The two approaches differ in the points where code specialization is performed.   In JIT-based  specialization, which work $f'$ is generated when $f$ is called. In contrast, OSR-based specialization interrupts $f$  as follows. it executes, generates a specialized version $f'$, and resumes from it. OSR-based specialization is more general than JIT-based specialization, as the latter only works if the \feval\ argument $g$ is one of the parameters of $f$.   \ifdefined\fullver  \paragraph{JIT-based specialization.}   [...]  \paragraph{OSR-based specialization.} This approach triggers an OSR in a function $f$ when a loop containing an \feval\ becomes hot. At that time, an optimized version $f'$ of $f$ is generated and control is diverted to $f'$. $f'$ is created by an optimizer that attempts to replace an \feval$(g,x,y,z...)$ instruction with a direct call $g(x,y,z,...)$ with unboxed parameters. The optimizer works at IR level and uses the actual values of $g$ and its arguments (known at the OSR time) to specialize the code. The direct call to $g$ is guarded by a condition that checks if $g$ and the type of its parameters remains the same as observed when the OSR was fired. If the guard fails, the code falls back to executing the original \feval\ instruction.  This method overcomes the limitations of JIT-based specialization, supporting optimization of \feval$(g,...)$ calls in functions that do not receive $g$ as a parameter. \fi  However, it is substantially slower for two main reasons: \begin{enumerate}  \item When a function $f$ is first compiled from MATLAB to IR by McVM, the functions it calls via \feval\ are unknown and the type inference engine is unable to infer the types of their returned values. Hence, these values must be kept boxed in heap-allocated objects and handled with slow generic instructions in the IR representation of $f$ (suitable for handling different types). These generic instructions are inherited by the optimized continuation function $f'$.% generated when OSR is fired.