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