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

Roger Riggs Roger.Riggs at Oracle.com
Wed Oct 21 13:35:51 UTC 2015


Hi Peter,



On 10/21/2015 4:02 AM, Peter Levart wrote:
> Hi Roger,
>
> I think this is a good compromise. Having the low-level extended 
> functionality in the JDK for internal use until it is proven. Dropping 
> Cleanable.clear() is also a correct move. I currently don't see a use 
> for it. If one registers a cleaning function, why would one then try 
> to change his mind? It's better to decide upfront before registering. 
> You could make final clear() in XxxCleanable classes throw UOE like 
> it's done for get() in XxxCleanableRef. This way no Reference methods 
> will be usefully accessible from Cleanable instance that is given to 
> users and nobody will be tempted to cast it to Reference.
The Reference.clear() function cannot be disabled completely. During a 
normal
close of a resource the Cleanable.clean() is invoked and it needs to 
clear() the Reference.
This eliminates the overhead on the Reference processing system when 
closes occur properly.
We're currently investigating an application with 12 million finalizable 
References; that
puts quite a load on gc.  It is better to clear the references when the 
GC behavior is no long needed.

About clear();  in the case you raised about coordinating cleanup 
between the subclass and superclass.
One design is for the superclass to expose the Cleanable object it 
creates to the subclass.
The subclass would register its own cleanup arranging to call the 
performCleanup of the super's Cleanable.
It would also want to clear() the super's Cleanable  so it never was 
invoked by the GC but
still encapsulates the super's cleanup behavior.

Thanks, Roger



>
> Regards, Peter
>
>
> On 10/20/2015 08:28 PM, Roger Riggs wrote:
>> 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.
>>
>> Recent updates:
>>  - The Cleaner implementation classes and the CleanableReference 
>> abstract classes are
>>    now in the jdk.internal.misc package and are available within the 
>> java.base module.
>>  - The Cleanable.clear method has been dropped; there is no current 
>> use case.
>>    Since the CleanableReferences extend Reference, clear() is 
>> available when subclassing.
>>  - The tests have been extended to cover the exported and internal APIs
>>
>> The Runnable thunk version is very convenient to code but does 
>> transparently create
>> an additional object to hold the bindings.
>> As the Cleaner is applied to the various uses of finalize we'll see 
>> how they would be used
>> and can re-evaluate the exported API needs.
>>
>> Updated Javadoc:
>>   http://cr.openjdk.java.net/~rriggs/cleaner-doc/
>>
>> Updated Webrev:
>>    http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/
>>
>> Thanks, Roger
>>
>>
>>
>>
>




More information about the core-libs-dev mailing list