Hi, On 03/02/18 18:15, Paul Sandoz wrote:
Thanks! Paul.
On Mar 2, 2018, at 9:11 AM, Vladimir Ivanov <vladimir.x.ivanov@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/ind... 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.ht...
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