RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more
peter.levart at gmail.com
Sun Mar 6 13:00:14 UTC 2016
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:
And here's the 2nd part that applies on top of part 1:
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.
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