On Jun 8, 2015, at 4:20 PM, Peter Levart <peter.lev...@gmail.com> wrote:
>
>
>
> On 06/08/2015 09:47 PM, Kim Barrett wrote:
>> On Jun 6, 2015, at 11:02 AM, Peter Levart <peter.lev...@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().
