JEP 132: More-prompt finalization (Re: Another take on Finalization)

[Kim Barrett]

On Jun 8, 2015, at 4:20 PM, Peter Levart <peter.levart at gmail.com> wrote:
> 
> 
> 
> On 06/08/2015 09:47 PM, Kim Barrett wrote:
>> On Jun 6, 2015, at 11:02 AM, Peter Levart <peter.levart at gmail.com>
>>  wrote:
>> 
>>> I understand that it would be desirable for a finalizable object to be made "untracked" as soon as it is manually cleaned-up. This would most certainly give a relief to GC as it could reclaim such untracked objects immediately like normal objects without pushing them through all the finalization steps.
>>> 
>>> Such feature would need new API. Here's my take on such API incorporated in my prototype. This feature is mostly independent of other changes in the prototype and could be provided stand-alone. I choose to incorporate it into the prototype to compare it's overhead with classical finalization in unchanged and changed JDKs:
>>> 
>>>     
>>> http://cr.openjdk.java.net/~plevart/misc/JEP132/ReferenceHandling/webrev.03/
>> While changes are needed to do this sort of thing, it seems to me a better change would be to not use finalize() at all, 
> 
> You mean FinalReference, right?

FinalReference is an implementation detail used in the implementation of finalize().  So yes, I mean FinalReference, but applications have no direct access to them.

> This is the only remaining Reference type that isn't cleared automatically by GC.

PhantomReference is also not automatically cleared, but see JDK-8071507.

> So if a XxxReference is cleared when it is discovered with referent being xxx-ly-reachable and later enqueued by ReferenceHandler thread, then GC has less work with it? Why is automatically cleared Reference more lightweight than FinalReference? Because GC can reclaim such referent right away in the same GC cycle as hooking it on the pending list?

That’s one reason, and is part of the rationale for making the change suggested for JDK-8071507.

Another benefit for PhantomReference is that the code that creates the reference object can also record it for later clearing, such as by a close-like operation.  If the reference is cleared by the application then it never gets added to the pending list at all.

> 
>> but instead use PhantomReference-based cleanup. It provides exactly that kind of behavior, and has other benefits besides.
>> 
>> There is some discussion about doing exactly that for File{Input,Output}Stream (see 
>> https://bugs.openjdk.java.net/browse/JDK-8080225
>> ).
>> 
>> 
> 
> sun.misc.Cleaner is already such thing (a PhantomReference). Would it be of interest to have a public API similar to sun.misc.Cleaner, but with the following difference:
> 
> - public "Cleaners" would be executed by same thread(s) as finalize() methods. This would detach their execution from ReferenceHandler thread which must dispatch all references and must not be disturbed by user code.

There’s been some discussion of a Cleaner-like API for ordinary PhantomReference objects, along with some prototyping.  Having a utility that packages up some of the boilerplate involved in using PhantomReference might help transition away from finalize().