RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization
Peter Levart
peter.levart at gmail.com
Tue Nov 24 13:12:12 UTC 2015
Hi,
On 11/23/2015 11:32 PM, mark.reinhold at oracle.com wrote:
> ( Finally getting back to this, after too many weeks of travel ... )
>
> 2015/10/20 11:28 -0700, roger.riggs at 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
More information about the hotspot-gc-dev
mailing list