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

Aleksey Shipilev aleksey.shipilev at oracle.com
Wed Oct 2 17:30:01 UTC 2013


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.

-Aleksey.



More information about the core-libs-dev mailing list