Hi,
On 11/23/2015 11:32 PM, mark.reinh...@oracle.com wrote:
( Finally getting back to this, after too many weeks of travel ... )
2015/10/20 11:28 -0700, roger.ri...@oracle.com:
Sorry for the silence, JavaOne preparations and the availability of
folks who wanted to review have stretched things out.
The Cleaner API was very simple and saw feature creep as the ideas for
how it might be used were explored. There are concerns about
committing to supporting subclassable CleanableReferences in all
future JDK versions before there had been a chance to see how if they
would be useful and necessary to address the need to reduce the use of
finalization within the OpenJDK and beyond.
...
Updated Javadoc:
http://cr.openjdk.java.net/~rriggs/cleaner-doc/
Updated Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/
I'm very happy to see this API return to something like its original
simple form, but I think it can be simplified even further.
We have a very strong need for phantom-ref-based cleaners, so as to
discourage people from relying upon flaky finalization. The arguments in
support of the weak and soft forms have, by contrast, been rather weak
(and soft?). I don't think it's right to bake methods into a core API
based on just a couple of hypothetical use cases. I'd much rather see
the Cleaner::{phantom,soft,weak}Cleanable methods reduced to a single
register method,
Cleaner.Cleanable register(Object, Runnable);
which would create the phantom form only. If strong justification for
the other forms arise then we can generalize this later, either to
distinct register{Soft,Weak} methods or, perhaps, to a method that takes
a type token.
- Mark
I don't have a strong argument for keeping the weak and soft variants in
the public API, although the use of soft variant for triggering periodic
cleaning based on current memory demand looks promising, but:
- please keep the internal variants of
jdk.internal.misc.CleanerImpl.XXXCleanable classes
- as I understand, WeakReference(s) are potentially more efficient than
PhantomReference(s)
Please correct me if I'm wrong. My current understanding is that
PhantomReference is the weakest type of Reference and therefore does not
prevent any other type of reference from being processed. But
PhantomReference is also a type of Reference that is not automatically
cleared by GC when equeued (like FinalReference but unlike Weak and
SoftReference). What that means is that in order for PhantomReference's
referent to be GC-ed, it has to go through at least 2 rounds of GC:
- 1st GC round discovers a phantom-reachable referent and hands the
PhantomReference(s) pointing to it to Java code
- Java code must clear() PhantomReference(s) manually to make the
referent unreachable
- 2nd GC round can garbage-collect the unreachable referent
Weak (and Soft) Reference(s) OTOH are cleared automatically by GC as
they are hooked on the pending chain. I don't know if GC optimizes this
situation currently (could use a hint from GC team at Oracle), but in
case GC discovers a weakly-reachable referent and atomically clears all
WeakReferences pointing to it, it could also collect the referent at the
same time if clearing the WeakReference(s) made it unreachable (i.e.
there are no weaker-than-WeakReferences pointing to it). WeakReferences
are therefore in my understanding (at least potentially) more efficient
than PhantomReferences which are more like finalizers with benefits in
that they don't allow access to the referent and that they are manually
registered.
What is actually the reason for the following issue:
https://bugs.openjdk.java.net/browse/JDK-8024421
to have the resolution: "Won't Fix"?
If PhantomReference is the weakest type of reference and it doesn't
allow access to it's referent by Java code, what purpose does not
automatically clearing its referent by GC have and would doing so break
anything? In my understanding the specification that says:
"Unlike soft and weak references, phantom references are not
automatically cleared by the garbage collector as they are enqueued. An
object that is reachable via phantom references will remain so until all
such references are cleared or themselves become unreachable."
...serves no purpose. If a referent is kept phantom-reachable or not
after it is discovered is not observable in any other way than by the
amount of memory that can be freed at any one time.
Regards, Peter
