RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation
Aleksey Shipilev
aleksey.shipilev at oracle.com
Wed Oct 2 16:49:20 UTC 2013
On 10/02/2013 08:31 PM, Alan Bateman wrote:
> On 02/10/2013 07:43, Aleksey Shipilev wrote:
>> http://cr.openjdk.java.net/~shade/6857566/webrev.00/
>>
> I'd like to review, I just don't have time at the moment.
Thanks Alan, we can wait.
> One thing that I'd like to understand is the implication of moving
> from phantom to weak references.
I suspected the major trouble would stem from the fact that referents
are retained longer (until the weakrefs are not polled from the RQ).
However, in the case of DirectByteBuffers it does not really matter
since DBB themselves are not referencing much! The native memory chunk
will be kept around regardless whether we used weak or phantom references.
> Also the impact on mapped buffers (map implementation in
> sun.nio.ch.FileChannelImpl) which will need to be changed too.
...AFAIU, the same goes for FileChannelImpl. NativeBuffer also uses
Cleaner, the same reasoning applies.
> Also I think we will need to include a short-running stress test as
> part of this change.
The original issue had the test:
http://cr.openjdk.java.net/~shade/6857566/DirectBufferTest.java
It fails nicely and quickly without the patch. We can convert it to jtreg.
-Aleksey.
More information about the core-libs-dev
mailing list