this is for holding javascript data
Daniele Cono D'Elia edited experim.tex
over 8 years ago
Commit id: cb2121ba60117de42074626dd2028736f2ec9fb5
deletions | additions
diff --git a/experim.tex b/experim.tex
index 15c3b6f..a8d0e34 100644
--- a/experim.tex
+++ b/experim.tex
...
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, as they can be used - as in the Jikes RVM - to enable more dynamic inlining opportunities, with the benefits from several control-flow (e.g., dead code elimination) and data-flow (e.g., constant propagation) optimizations based on the run-time values of the live variables. In the shootout benchmarks, the number of such loops is typically 1 (2 for {\tt spectral-norm}).
For
{\tt b-trees} - the only benchmark in our suite showing a recursive
benchmarks, pattern - we insert an OSR point in the body of the method that accounts for the largest {\em self} execution time of the program. Such an OSR point might
enable be useful to trigger recompilation of the
invoked method code at a higher degree of optimization,
[...]
In the shootout benchmarks, ({\tt binary-trees} and {\tt spectral-norm}) show or to enable some form of dynamic optimization (for instance, in a recursive
pattern. search algorithm we might want to inline the comparator method provided by the user at the call).