this is for holding javascript data
Camil Demetrescu edited approach.tex
over 8 years ago
Commit id: df2952d2657bf529176b591506f20fe9bdd60d8c
deletions | additions
diff --git a/approach.tex b/approach.tex
index 932e6b6..d6c8dcc 100644
--- a/approach.tex
+++ b/approach.tex
...
Our implementation targets two general scenarios: 1) {\bf resolved OSR}: \fvariant\ is known before executing \fbase, as in the deoptimization example discussed above; 2) {\bf open OSR}: \fvariant\ is generated when the OSR is fired, supporting deferred compilation strategies. In both cases, \fbase\ is instrumented before its execution to incorporate the OSR machinery. We call such OSR-instrumented version \fosrfrom. Instrumentation consists of adding a check of the OSR condition. If the condition is satisfied, \fosrfrom\ fires the OSR via a regular function call.
In the resolved OSR
scenario, shown in Figure~\ref{fi:overview-osr-final}, scenario (see Figure~\ref{fi:overview-osr-final}), the OSR invokes an instrumented version of \fvariant\ called \fosrto, passing to it {\em all variables that are live at the OSR point}. Notice that, differently from \fvariant, \fosrto\ takes as input the live variables of \fbase\ at \textsf{L}.
%and returns the same value when it has terminated. The assumption is that the called function produces the same side-effects and return values that one would obtain by \textsf{f} if no OSR were performed.
...