Lightweight finalization for the JDK without any drawbacks was: Why is finalize wrong?

[Doug Lea]

On 08/07/2014 03:43 AM, Jaroslav Tulach wrote:
> Dne Čt 7. srpna 2014 08:17:16, Andrew Haley napsal(a):
>> I'm wondering whether it's really worth your time applying band-aids to
>> a broken mechanism.
>
> Under the assumption WeakReference and ReferenceQueue are flawless, there is no
> reason to call a mechanism based on WeakReference and ReferenceQueue synergy
> "broken".
>
>> An object can be
>> "really gone" even when one of its instance methods is still executing.
>
> That would probably signal a major flaw in the JVM.

Finalization is not broken in the sense of not meeting its specs
(see http://docs.oracle.com/javase/specs/jls/se7/html/jls-12.html#jls-12.6)
but some surprising and undesirable cases are allowed,
and actually occur, in highly concurrent programs.
Including cases where finalizers may run concurrently with
the final invocation of a method on the target.
Because the specs interact with the details of the memory model,
we have been discussing (on jmm-dev list) possible changes
and  improvements. But in the mean time (or in any case), the best
practice is to consider finalization as a last resort, after
ruling out all other possible cleanup strategies.
Finalization is easy to spec, implement, and control in
purely sequential systems, but is a questionable idea in
concurrent ones.

-Doug