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

[Roger Riggs]

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

Roger



>
> -Chris.