> On Mar 6, 2016, at 5:00 AM, Peter Levart <peter.lev...@gmail.com> wrote:
> 
> Hi,
> 
> I have been asked to split the changes needed to remove 
> jdk.internal.ref.Cleaner into two changesets. The first one is to contain the 
> straightforward non-controversial changes that remove the references to 
> jdk.internal.ref.Cleaner and swaps them with java.lang.ref.Cleaner in all 
> places but Direct-X-Buffer. This part also contains changes that replace use 
> of lambdas and method references with alternatives.
> 
> Here's the 1st part:
> 
> http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.07.part1/
> 

webrev.07.part1 looks okay.

> And here's the 2nd part that applies on top of part 1:
> 
> http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.07.part2/
> 
> 
> Together they form functionally equivalent change as in webrev.06priv with 
> only two additional cosmetic changes to part 2 (renaming of method 
> Cleaner.cleanNextPending -> Cleaner.cleanNextEnqueued and removal of an 
> obsolete comment in nio Bits).
> 

I studied webrev.06priv and the history of JDK-6857566. 

I’m not comfortable for any arbitrary thread to handle the enqueuing of the 
pending references (this change is more about the fix for JDK-6857566).  I like 
your proposed change to take over handling the whole chain of pending 
references at once.  The unhookPhase and enqueuePhase add the complexity that I 
think we can avoid.

I’m okay for only system's cleaner thread to help the reference handler thread 
doing its job.  Would you consider having the special cleaner thread to help 
the enqueuing before waiting on the cleaner's ReferenceQueue?  

The allocating thread may do a System.gc() that may discover phantom reachable 
references.  All it’s interested is only the direct byte buffer ones so that it 
can deallocate the native memory.  What is the downside of having a dedicated 
Cleaner for direct byte buffer that could special case for it?


> If part2 is to be developed further, I would like to 1st push part1 so that 
> maintenance of part2 changeset will be easier.


It’s okay with me to push part1.  I’d like to see different prototypes for 
part2 being explored and evaluate the pros and cons of each one.  Sorry I 
realize this may require additional works.

Mandy

Reply via email to