RFR [6853696] (ref) ReferenceQueue.remove(timeout) may return null even if timeout has not expired

Ivan Gerasimov ivan.gerasimov at oracle.com
Wed Feb 26 07:08:07 UTC 2014


On 26.02.2014 10:19, Mandy Chung wrote:
>
> On 2/25/2014 1:46 PM, Ivan Gerasimov wrote:
>>
>>> line 61:  I think the test should be:
>>>    if (thread.reference != null || thread.actual < TIMEOUT)
>>>
>> Sorry, I'm not clear why.
>> We have two threads:
>> 1) The lucky one gets non-null reference when it calls remove(). For 
>> this thread the actual time it had spent on waiting may be much less 
>> than 1 sec timeout.
>> 2) The one which receives null from remove(). The amount of time it 
>> should have waited before returning from remove() should not be less 
>> than timeout.
>>
>
> I missed that you remove the strong reference (line 57).   I think 
> it's good to hold the strong reference so that 
> ReferenceQueue.remove(timeout) will timeout and the test can verify 
> reliably.
>
This is an important part.
If we didn't remove the strong reference then both threads would wait 
for the specified period of time even without the fix.
The point is to make both threads wake up from lock.wait(timeout), and 
we do it by removing the strong reference and forcing it be enqueued.

Sincerely yours,
Ivan

> Perhaps once you check the EarlyTimeout threads (both should timeout 
> with null reference), you can clear the referent and call System.gc() 
> and then verify if queue.remove(longTimeout) should not block as the 
> reference should be enqueued for removal.
>
> Mandy
>
>> That's what we should check here:
>> if the thread is not the lucky one (reference == null), we make sure 
>> it spent whole second waiting in remove().
>>
>> Please find the slightly updated version of webrev here:
>> http://cr.openjdk.java.net/~igerasim/6853696/2/webrev/
>> I didn't change the if () clause, as I'm not yet sure why it should 
>> be done.
>
>
>




More information about the core-libs-dev mailing list