RFR 9: JDK-8146028 : Common Cleaner for finalization replacements in java.base

[Chris Hegarty]

On 06/01/16 14:54, Roger Riggs wrote:
> Hi Chris,
>
> On 1/6/2016 9:39 AM, Chris Hegarty wrote:
>> Roger,
>>
>> 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
>>>>> system.
>>>>>
>>>>> Webrev for Review:
>>>>> http://cr.openjdk.java.net/~rriggs/webrev-cleaning-factory-8146028/
>>>> 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
>>>> having
>>>> to qualify exports of jdk.internal.misc to other JDK modules ) ?
>>> That could be useful; but it raises the question about the right/good
>>> granularity.
>>> It might make sense that the desktop module might reasonably share the
>>> Cleaner.
>>> 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
> CleanerFactory and
> the subclassable Cleanable types and leave jdk.internal.misc as a
> dumping ground for
> base module implementations.

That sounds ok to me.

>>>> 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
> processing in
> Reference.tryHandlePending.  There is a fast path dequeuing References
> that need processing
> from the VM.

Oh. I found some references to sun.misc.Cleaner in the VM [1] [2], but
maybe it does not affect how/when these get queued.

-Chris.

[1]
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/tip/src/share/vm/memory/referenceType.hpp#l39
[2] 
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/tip/src/share/vm/classfile/systemDictionary.cpp#l1977