RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Roger Riggs Roger.Riggs at Oracle.com
Wed Oct 14 13:54:16 UTC 2015


Hi Alan,

On 10/14/2015 9:35 AM, Alan Bateman wrote:
> On 14/10/2015 14:24, Roger Riggs wrote:
>> Hi,
>>
>> Confirmed,  the design and implementation encapsulate the cleanup so 
>> it can be run consistently
>> at-most-once either at close or when it is unreferenced.
>> It has not been a problem for sun.misc.Cleaner because the cleanup is 
>> *only* done when
>> the ref is unreachable.  But there are issues about latency in 
>> getting resources released and reusable.
> There are a few places the in JDK where we do use Cleaner::clean for 
> exactly this reason.
>
> One thing that I've been wondering about is why the abstract 
> XXXCleanable classes are public, is that intended?
Being able to subclass the XXXCleanable classes allows more efficient 
implementation of the cleaners
in both size and performance.  The subclass adds the necessary state for 
the cleanup and implements
the performCleanup method.  Only a single object is created (and gc'd), 
reducing the size of headers
and cross references between separate objects.  Only the performCleanup 
method is overridable to
maintain the robustness of the Cleaner implementation.

If the XXXCleaner classes are not subclassed, a separate object is 
needed for the state and behavior.
Either that extra object is created by the binding if lambda is used, or 
by the class needing the cleanup.
It is not a big cost but is proposed to optimize the design and 
implementation.

Peter's email [1] provided another description of the use case for 
subclassing.

I'm working on a webrev to show how the Cleaner would be used instead of 
finalizers
and it will show use use of both lambdas and explicit cleanup classes.

Roger

[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/035826.html


>
> -Alan.




More information about the core-libs-dev mailing list