RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with "RuntimeException: Error: poll() returned null; expected ref object"
peter.levart at gmail.com
Thu Jul 30 10:20:04 UTC 2015
On 07/30/2015 11:12 AM, Daniel Fuchs wrote:
> Hi Peter,
> I'm glad you're looking at this too! We can't have too many eyes :-)
> On 30/07/15 10:38, Peter Levart wrote:
>> Suppose we have a Reference 'r' and it's associated ReferenceQueue 'q'.
>> Currently it can happen that the following evaluates to true, which is
>> q.poll() == null && r.isEnqueued()
> But on the other hand this can only happen if two different
> threads are polling the queue - in which case only one of them
> will get the reference. In such a situation, the symmetric condition
> would not be surprising (as the other thread would
> get q.poll() != null):
> r.isEnqueued() && q.poll() == null
> The original bug fixed by Kim is more surprising, because there's only
> one Thread doing the polling, and it does get:
> r.isEnqueud() && q.poll() == null
> although nobody else is polling the queue.
> This should no longer occur in this situation with Kim's fix.
> -- daniel
Yes, these are two different issues. The one Kim has fixed is the race
of above expressions with Queue.enqueue() (when the queue is changing
from the associated instance to ENQUEUED). The one I'm pointing at and
Kim has already identified as potential issue is the race of the
r.isEnqueued() && q.poll() == null && r.isEnqueued() ==> true
....with Queue.[realy]poll() (when the queue is changing from ENQUEUED
Which only happens if at least two threads are polling the queue, but is
equally surprising and prone to cause bugs, don't you think?
More information about the hotspot-gc-dev