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

Peter Levart peter.levart at gmail.com
Sun Mar 6 13:00:14 UTC 2016


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/

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).

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




More information about the core-libs-dev mailing list