Finalizer being run while class still in use (escape analysis bug)

[Luke Hutchison]

On Wed, Oct 10, 2018 at 9:53 AM Kim Barrett <kim.barrett at oracle.com> wrote:

> Finalization was deprecated in JDK 9 (*).  There's an ongoing (though
> progressing slowly) process of eliminating its usage in the JDK.
> Sometime after that it may go away entirely, or perhaps require some
> sort of explicit opt-in, making it possible to eliminate various GC
> overheads associated with it.
>
> (*) Use PhantomReference, or a helper like java.lang.ref.Cleaner.
> Though that change the liveness question in this thread.
>

Yes, I saw both the deprecation of finalization and the introduction of
Cleaner -- though there will be a lot of legacy code and legacy runtime
environments that are going to stick around for a long time, especially
given the problems so many people are having moving to JPMS for non-trivial
usecases.

What would be wrong with simply disabling inlining altogether for any
classes that override finalize()? Inlining seems to be the main sticking
point. I would strongly prefer to take a performance hit over having
finalization being so broken. Running finalizers late or never is much less
of a problem than running them early, since running them late or never
*may* lead to resource leaks, but running them early *will almost
certainly* break everything that uses finalizers at some point.

It would be a much better API contract to state that "if you override
finalize(), some code optimizations may not kick in" rather than "if you
override finalize(), things will almost certainly break, and you get to
keep all the pieces".