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