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

[Volker Simonis]

On Wed, Oct 10, 2018 at 5:16 PM Andrew Haley <aph at redhat.com> wrote:
>
> On 10/10/2018 02:09 PM, Erik Österlund wrote:
> > The implementation of reachabilityFence was changed recently to become a
> > normal static method, and stop forcing no inlining. No magic and special
> > treatment by HotSpot.
>
> I'm sure it depends on the JIT being used. I'm slightly surprised
> something so simple works, given that a normal empty method could be
> trivially inlined and the reference dropped. And we know that does
> happen, so I wonder why not here?
>
> Incidentally, I can't find the review thread for 8199462.

The thread was called "[PATCH] Reduce Chance Of Mistakenly Early
Backing Memory Cleanup" and the bug was only created at the very end
of the discussion. You can find it at:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-February/thread.html#51221
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/thread.html#51863

Very interesting reading :)

>
> > I think the analysis made was that the oops would have to be kept
> > alive based on the bytecode level live analysis, as required by
> > deoptimization to work as expected.
>
> > I was curious if this works with Graal and asked Graal folks about it.
> > Turns out it works the same for Graal as JIT and AoT, due to the need to
> > support deoptimization in those configurations, leading the oops to be
> > kept alive. But with SVM, an actual intrinsic will be added to support
> > this operation, as there is no need for deoptimization in SVM, causing
> > the compiler to go a bit further.
>
> Mm, yes. It's not at all nice that the correctness of the Java library
> relies on something which seems to be a side effect of the design of
> the JIT. Still, it's up to other JITs to provide their own
> implementation.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671