RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more
chris.hegarty at oracle.com
Mon Mar 7 16:42:39 UTC 2016
On 06/03/16 13:00, Peter Levart wrote:
> 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
> Here's the 1st part:
Looks good to me.
> And here's the 2nd part that applies on top of part 1:
From what I can see. I think this is good.
> 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.
>>> 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:
>>> Regards, Peter
More information about the core-libs-dev