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

[Roger Riggs]

Hi Peter,

I think this cleans up all the points raised earlier.
The optimization for enqueuing from the reference queue seems ok to me 
and should be
more efficient than the previous implementation but I think Mandy or 
Alan should look at it also.

Thanks, Roger


On 2/25/2016 4:17 AM, Peter Levart wrote:
> Hi Alan,
>
> On 02/25/2016 09:00 AM, Alan Bateman wrote:
>>
>>
>> On 25/02/2016 07:24, Peter Levart wrote:
>>> :
>>>
>>> I kept the public boolean Cleaner.cleanNextPending() method which 
>>> now only deals with enqueued Cleanable(s). I think this method might 
>>> still be beneficial for public use in situations where cleanup 
>>> actions take relatively long time to execute so that the rate of 
>>> cleanup falls behind the rate of registration of new cleanup actions.
>> I think we need also need to look at the option where this is not 
>> public. I have concerns that it is exposing implementation to some 
>> extent and that may become an attractive nuisance in the future. This 
>> shouldn't be an issue for the NIO buffer usage, we can keep the usage 
>> via the shared secrets mechanism. I think this is what Mandy is 
>> suggesting too.
>>
>> -Alan.
>
> Sure, no problem. Here's a variant that keeps the 
> Cleaner.cleanNextPending() method private and exposed via 
> SharedSecrets to nio Bits but is otherwise equivalent to webrev.06:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.06priv/ 
>
>
> Regards, Peter
>