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

Aleksey Shipilev aleksey.shipilev at oracle.com
Fri Oct 4 13:37:43 UTC 2013


Hi Peter,

On 10/04/2013 04:43 PM, Peter Levart wrote:
> http://cr.openjdk.java.net/~plevart/jdk8-tl/Cleaners/webrev.02/

So you are taking on assisting the ReferenceHandler directly. Nice idea.

I can only glimpse over the changes at this point...
 - You can't add the public methods to java.ref.* APIs (as easily);
should we require this, turn  new methods to privates, and use
sun.misc.SharedSecrets as the doorway.
 - The internal double-linked list schematics makes me itchy; my patch
cleaned this up, can yours?
 - ReferenceQueue.drainLoop: combine the try blocks
 - Reference: rename enqueueNext -> tryEnqueueNext
 - Reference: rename waitForNotifyIfNonePending -> waitForNotify
 - Reference: please don't move static initializer, harder to read the
cahnge
 - Bits: please declare the variables on the individual lines
 - Bits: don't you want to keep Thread.sleep(100) around to let GC catch
up with the reference processing? This will also help the case of
completely asynchronous System.gc() -- your code will just spin over the
System.gc()'s and throw OOME.
 - Cleaner: cleanCount is a strange name given we most probably
anticipate and tolerate overflow. There is also the theoretical chance
we will overflow and spin right to the same count. Make it AtomicLong?
 - Cleaner: since we are using JDK 8 interfaces anyway, why not using
the lambda for cleanConsumer?

Thanks,
-Aleksey.



More information about the core-libs-dev mailing list