this is for holding javascript data
Daniele Cono D'Elia edited experim.tex
over 8 years ago
Commit id: 7ca085d1505dec287ec809477320980baa4736c3
deletions | additions
diff --git a/experim.tex b/experim.tex
index d90d5ce..7d4cb71 100644
--- a/experim.tex
+++ b/experim.tex
...
\end{itemize}
\paragraph{Impact on code quality.}
In order to measure how much a never-firing OSR point might impact code quality, we analyzed the source-code structure of each benchmark and profiled its run-time behavior to identify performance-critical sections for OSR point insertion. The distinction between open and resolved OSR points is
nearly irrelevant in this
context, as generated code is nearly identical: the only difference is that for an context: we chose to focus on open OSR
the call instruction triggering the transition takes points, as their calls take an
additional extra argument
(a {\tt null} for profiling
value). We thus focus on open OSR only. that we set to {\tt null}.
For iterative benchmarks, we insert an OSR point in the body of their hottest loops. We classify a loop as hottest when its body is executed for a very high cumulative number of iterations (e.g., from a few thousands up to billions) and it either calls the method with the highest {\em self} time in the program, or it performs the most computational-intensive operations for the program in its own body. These loops are natural candidates for OSR point insertion: for instance, the Jikes RVM inserts yield points on backward branches to trigger operations such as method recompilation through OSR and thread preemption for garbage collection. In the \shootout\ benchmarks, the number of such loops is typically 1 (2 for {\tt spectral-norm}).