RFR 9: JDK-8146028 : Common Cleaner for finalization replacements in java.base
chris.hegarty at oracle.com
Wed Jan 6 14:39:26 UTC 2016
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 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
> 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.
>> 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 ).
More information about the core-libs-dev