RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation

[Peter Levart]

On 10/02/2013 07:30 PM, Aleksey Shipilev wrote:
> On 10/02/2013 09:15 PM, Peter Levart wrote:
>> On 10/02/2013 06:31 PM, Alan Bateman wrote:
>>> One thing that I'd like to understand is the implication of moving
>>> from phantom to weak references.
>> I think Cleaners as WeakReferences are not correct.
>>
>> Imagine the following code:
>>
>>          Reference<ByteBuffer> refBb;
>>          {
>>              ByteBuffer dbb = ByteBuffer.allocateDirect(1000);
>>              refBb = new SoftReference<>(dbb);
>>          }
>>          System.gc(); // can clear Cleaners, might already process them
>>
>>
>>          ByteBuffer dbb = refBb.get(); // whoops!
>>
>>
>> ...you could get a reference to direct ByteBuffer after the cleaner has
>> already deallocated it's native memory block...
> Ummm, aren't the Cleaners forbidden to run in this case?
>
> The strength is: strong > soft > weak > phantom, that is:
>   We can not process strongly-reachable soft references.
>   We can not process strongly/softly-reachable weak references.
>   We can not process strongly/softly/weakly-reachable phantom references.
>
> If you keep the either strong or soft reference to dbb, then it's softly
> reachable, not yet weakly-reachable, and then Cleaners are still
> standing by. Note that Cleaners might run if your dbb is
> phantomly-reachable, but that is OK, since you will not be able to
> recover dbb through phantomref anyway.

You're right. I jumped to conclusion to quickly. I was mislead by the 
agility of a particular reference type to be cleared. It only makes 
sense that the strength is inversely proportional to agility.

Regards, Peter

> -Aleksey.