[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