[PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup

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


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) {


         return finalized.get();

The last two statements should be reversed or else the test could 
produce a false alarm:

         boolean fin = finalized.get();
         return fin;

Regards, Peter

More information about the core-libs-dev mailing list