[PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup

Peter Levart peter.levart at gmail.com
Sun Mar 11 09:03:31 UTC 2018


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 at 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



More information about the core-libs-dev mailing list