RFR  java/lang/ref/EarlyTimeout.java failed
ivan.gerasimov at oracle.com
Thu Mar 27 13:36:50 UTC 2014
Thank you Peter!
> There could be a little delay (say half the timeout: 500ms) specified
> after main thread returns from the startedSignal.await(); and before
> setting referent = null; and doing System.gc(). This would decrease
> the chance that the reference is enqueued before EarlyTimeout threads
> enter queue.remove(1000), thus making the test more reliable in
> failing with unpatched code.
Yes, you're right.
I've checked the test against jdk9-b01 (no fix for 6853696 yet).
It gives 2.5% of false negatives (i.e. in 5 out of 200 runs the
reference was enqueued before calling to remove()).
With an additional delay of TIMEOUT / 2 this number dropped to 0%.
With jdk9-b05 (with fix for 6853696) no false positives were shown with
or without this additional delay.
> Now even if the referent is released and System.gc() is called, that
> does not guarantee that a WeakReference is going to be enqueued before
> the EarlyTimeout threads timeout and the result could as well be 0
> collected references. To increase the chance that the reference is
> enqueued in a timely manner, main thread could, immediately after
> System.gc(), call:
> (since SharedSecrets is in sun.misc protected package,
> JavaLangRefAccess instance would have to be obtained using reflection
I would prefer not to complicate the test too much, if you don't mind. I
think the test already shows reliable reproducibility.
>> I suggest to return to the very first trivial fix:
> But this webrev *is moving startedSignal.await() after System.gc()* ...
Oops, sorry. It was meant to be /8038333/*0*/webrev/, of course!
Now, I updated the webrev with the additional delay as you suggested:
Would you please have a look?
More information about the core-libs-dev