RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

[Mandy Chung]

> On Mar 6, 2016, at 5:00 AM, Peter Levart <peter.levart at 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