deletions | additions       diff --git a/prev-eval-sol.tex b/prev-eval-sol.tex  index 68f1379..7b77ee9 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,...)$, 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, $f'$ is generated when $f$ is called. In contrast, the OSR-based method interrupts $f$ as it executes, generates a specialized version $f'$, and resumes from it.  The two approaches differ in the points where code specialization is performed. In JIT-based specialization, $f'$ is generated when $f$ is called. In contrast, the OSR-based method interrupts $f$ as it executes, generates a specialized version $f'$, and resumes from it.  Another technical difference between the two approaches, difference,  which has substantial performance implications, is the representation level at which optimization occurs. When a function $f$ is first compiled from MATLAB to IR by McVM, IR,  the functions $g$ 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). The JIT method works on the IIR representation of $f$ and can resort to the full power of type inference to infer the types of the returned values of $g$, turning the slow generic instructions of $f$ into fast type-specialized instructions in $f'$. On the other hand, OSR-based specialization operates on the IR representation of $f$, which prevents the optimizer from exploting type inference. As a consequence, for $f'$ to be sound, the direct call to $g$ must be guarded by a condition that checks if $g$ and the type of its parameters remain the same as observed at the time when $f$ was interrupted. If the guard fails, the code falls back to executing the original \feval\ instruction. JIT-based specialization is less general than OSR-based specialization, as it only works if the \feval\ argument $g$ is one of the parameters of $f$.