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