RFR (XS): 8014890 : Reference queues may return more entries than expected

[Aleksey Shipilev]

On 06/19/2013 06:09 PM, Thomas Schatzl wrote:
>> With that notion in mind, I start to wonder if we just need to move the
>> check in enqueue() down into the synchronized(lock), and extend it to
>> capture NULL:
>>
>> --- a/src/share/classes/java/lang/ref/ReferenceQueue.java	Mon Jun 17
>> 16:28:22 2013 +0400
>> +++ b/src/share/classes/java/lang/ref/ReferenceQueue.java	Wed Jun 19
>> 17:53:24 2013 +0400
>> @@ -56,8 +56,9 @@
>>
>>      boolean enqueue(Reference<? extends T> r) { /* Called only by
>> Reference class */
>>          synchronized (r) {
>> -            if (r.queue == ENQUEUED) return false;
>>              synchronized (lock) {
>> +                if (r.queue == ENQUEUED || r.queue == NULL)
>> +                    return false;
>>                  r.queue = ENQUEUED;
>>                  r.next = (head == null) ? r : head;
>>                  head = r;
>>
>> Will it be equivalent to what Thomas is trying to accomplish?
> 
> Yes, this is equivalent. Instead of checking the separate ENQUEUED and
> NULL values I simply used an "r.queue != this" check which would get
> both cases. R.queue cannot have other values than ENQUEUED, NULL or the
> queue's value set at initialization.

Yeah, for my taste, explicitly checking for ENQUEUED || NULL declares
the intent more clearly. YMMV, though. I'm OK with plumbing the hole...
your style. :)

-Aleksey.