RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with "RuntimeException: Error: poll() returned null; expected ref object"

Peter Levart peter.levart at gmail.com
Fri Jul 31 13:23:58 UTC 2015



On 07/31/2015 12:56 AM, Kim Barrett wrote:
> On Jul 30, 2015, at 5:33 PM, David Holmes <david.holmes at oracle.com> wrote:
>>> So I think I can either:
>>>
>>> 1. Go ahead with my change + Peter's change.
>>>
>>> 2. Give this back to core-libs while I step carefully away :-)
>>>
>>> I *think* option (1) is at least an improvement.  But I completely
>>> missed Peter's race, despite having specifically looked for problems
>>> there, so take my opinion with an appropriate quantity of salt.
>> I vote for 1 as well. I think we have now given good coverage to the two sources of problems (the two lock-free regions):
>> - reference queue state can be seen while queue state is in transition
>> - queue empty state can be seen while reference state is in transition
> New webrev, with both changes:
>
> http://cr.openjdk.java.net/~kbarrett/8132306/webrev.01/
>

This looks good now. Thanks for taking both of the issues together. I 
wonder if a similar racy test could be devised for the 2nd race. I doubt 
the ReferenceEnqueue test was meant to catch invalid races specifically. 
It was more a coincidence that it failed.

I tried to create a reproducer for 2nd race, but it is not reliable and 
sometimes needs several minutes to fail.

Now I have to check if my prototype for improved Reference handling:

http://cr.openjdk.java.net/~plevart/misc/JEP132/ReferenceHandling/webrev.06/

suffers from these or similar races too. From 1st look it seems so.

Regards, Peter



More information about the hotspot-gc-dev mailing list