Hi Paul,
Just a note on the test logic...
71 boolean finalized = false;
72 for (int c = 0; c < MAIN_ITERS; c++) {
73 finalized |= nonFenced(LOOP_ITERS);
74 }
...no need to loop to the end (MAIN_ITERS) after the outcome is already
settled:
boolean finalized = false;
for (int c = 0; !finalized && c < MAIN_ITERS; c++) {
finalized = nonFenced(LOOP_ITERS);
}
(Likewise with the fenced loop).
It's also strange that LOOP_ITERS is passed to nonFenced/fenced via
parameter, but WARMUP_LOOP_ITERS, derived from it, is accessed as a
constant directly. Perhaps it would be nicer to just ditch the 'iters'
parameter.
Regards, Peter
On 11/26/2015 05:22 PM, Paul Sandoz wrote:
Hi,
I have updated the patches:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-jdk/webrev/
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-hotspot/webrev/
There is now more documentation on Reference (copied and suitable rearranged
from 166 Fences.java). The method name remains the same.
I have included a ReachabilityFenceTest derived from the tests by Aleksey and
Peter. The test uses iterations rather than time, to be more certain that test
methods will get OSR’ed and then compiled. It runs quite quickly. (I spruced up
the inlining test in the hotspot patch but i will probably remove it).
Ongoing some future aspects to consider (from conversation with John):
1) Using java.lang.invoke.DontInline would be nice. There is a certain pressure
building to move this and other related annotations into an internal
non-exported package. I will follow up with that.
2) It would be useful to have a guard method call in reachabilityFence that
throws an exception (perhaps as an assert) if the method was inlined into
another method. At the moment i don’t quite know how to do this.
Paul.
