RFR 9: JDK-8146028 : Common Cleaner for finalization replacements in java.base
Roger.Riggs at Oracle.com
Wed Jan 6 14:54:43 UTC 2016
On 1/6/2016 9:39 AM, Chris Hegarty wrote:
> On 05/01/16 21:24, Roger Riggs wrote:
>> Hi Chris,
>> On 1/5/2016 2:33 PM, Chris Hegarty wrote:
>>> On 5 Jan 2016, at 18:24, Roger Riggs<Roger.Riggs at oracle.com> wrote:
>>>> The follow on work to adding the Cleaner is to replace uses of
>>>> finalization with uses of the Cleaner.
>>>> For the 'easy' cases in the java.base module, it is useful to
>>>> introduce a private Cleaner for the
>>>> java.base module. It is proposed to be held weakly, to allow it to
>>>> terminate on a lightly loaded
>>>> Webrev for Review:
>>> Looks ok Roger. Does it make sense to put CleanerFactory, and maybe
>>> CleanerImpl, into their own internal package, so that it can be used
>>> as a
>>> JDK platform Cleaner ( rather than a base module only cleaner, or
>>> to qualify exports of jdk.internal.misc to other JDK modules ) ?
>> That could be useful; but it raises the question about the right/good
>> It might make sense that the desktop module might reasonably share the
>> Is there any comparable functionality/package already identified?
> I'm not sure that this has come up before. I'm just trying to
> prevent jdk.internal.misc from becoming a general dumping ground
> ( this is not to say that the Cleaner is rubbish, it is not ).
> We can revisit this later, if needed.
I'd want to make a distinction between classes being made available to
OpenJDK for internal use vs implementation classes.
Perhaps a jdk.internal.ref package (or jdk.internal.util) for the
the subclassable Cleanable types and leave jdk.internal.misc as a
dumping ground for
base module implementations.
>>> Is it possible of the NIO Buffers to use this Cleaner?
>> I did prototype using the java.lang.ref.Cleaner instead of
>> sun.misc.Cleaner and it didn't work so
>> well. Some of the tests failed with out of memory exceptions. I
>> suspected that the fast path
>> through the reference processing for the Cleaner was managing to free
>> memory more quickly than
>> was possible with the new Cleaner.
> Ah, I was not aware that the VM had intimate knowledge of
> sun.misc.Cleaner. So, from a JEP 260 point of view, the base
> module will need to retain an internal mechanism for releasing
> NIO buffers ( I was hoping it could use the new Cleaner ).
The VM doesn't know about sun.misc.Cleaner, just the Reference handling
Reference.tryHandlePending. There is a fast path dequeuing References
that need processing
from the VM.
More information about the core-libs-dev