Hi,
On 03/02/18 18:15, Paul Sandoz wrote:
Thanks!
Paul.
On Mar 2, 2018, at 9:11 AM, Vladimir Ivanov <vladimir.x.iva...@oracle.com>
wrote:
On 3/2/18 8:01 PM, Paul Sandoz wrote:
Here’s an update Ben and I tweaked:
http://cr.openjdk.java.net/~psandoz/jdk/buffer-reachability-fence/webrev/index.html
I think this looks good but would still like to double check with Vladimir that
the @ForceInline is not problematic.
I confirm that my previous analysis [1] still applies when method is marked w/
@ForceInline.
Best regards,
Vladimir Ivanov
[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-February/051312.html
I was going to suggest to add a test for that JIT assumption, but I see
there's already a test called ReachabilityFenceTest that should catch a
change in JIT behavior that would break reachabilityFence(). I spotted a
flaw in that test. See method fenced():
public static boolean fenced() {
AtomicBoolean finalized = new AtomicBoolean();
MyFinalizeable o = new MyFinalizeable(finalized);
for (int i = 0; i < LOOP_ITERS; i++) {
if (finalized.get()) break;
if (i > WARMUP_LOOP_ITERS) {
System.gc();
System.runFinalization();
}
}
Reference.reachabilityFence(o);
return finalized.get();
}
The last two statements should be reversed or else the test could
produce a false alarm:
boolean fin = finalized.get();
Reference.reachabilityFence(o);
return fin;
Regards, Peter
