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

[Peter Levart]

Hi Alan,

On 02/23/2016 04:33 PM, Alan Bateman wrote:
>
>
> On 22/02/2016 21:41, Mandy Chung wrote:
>> :
>>> I added new method to Cleaner:
>>>
>>>     public boolean helpClean() { }
>>>
>> I’m in two minds of making this a public method. An explicit way to 
>> enqueue pending references as well as invoke Cleanable::clean.  If it 
>> goes in, the method name needs to be renamed.
>>
> I'm also not sure that it's a good idea to have this be part of the 
> Cleaner API. If feels like it's exposing too much of the internals. Is 
> it really needed?

Without it, the DirectBufferAllocTest fails.

As John Cage (the character from Ally McBeal) would say: "I'm puzzled!". 
My previous iterations used similar method on the internal CleanerImpl 
class and there were suggestions to expose the functionality as public API.

I don't think this method exposes too much of internals. In the sense 
where it would prevent any possible future rearrangement of the 
internals or evolving of the Cleaner API. It doesn't talk about any 
queue(s) or ReferenceHandler thread. It keeps the Cleaner implementation 
details private. It just enables giving CPU time to assist with cleanup 
and if used as hinted in @implNote, provides back-pressure to allocating 
threads. I think this is a nice way of solving the problem of balancing 
allocation with deallocation. The same problem concurrent GC algorithms 
have, like G1 or CMS. If they can not keep-up with allocation threads, 
they pause them and do the cleanup while the world is stopped.

Regards, Peter