Hi Peter,
Thanks, well spotted. I adjusted to:
try {
return finalized.get();
} finally {
Reference.reachabilityFence(o);
}
I also created this issue:
https://bugs.openjdk.java.net/browse/JDK-8199462
http://cr.openjdk.java.net/~psandoz/jdk/buffer-reachability-fence/webrev/
I will push today or tomorrow.
Paul.
> On Mar 11, 2018, at 1:03 AM, Peter Levart <peter.lev...@gmail.com> wrote:
>
> 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
>
