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