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