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

[Chris Hegarty]

On 06/03/16 13:00, Peter Levart 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/

Looks good to me.

> 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/

 From what I can see. I think this is good.

-Chris.

>
> 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).
>
> If part2 is to be developed further, I would like to 1st push part1 so
> that maintenance of part2 changeset will be easier.
>
> Regards, Peter
>
> On 02/26/2016 10:39 PM, Roger Riggs wrote:
>> 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
>>>
>>
>