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

Attila Szegedi szegedia at
Wed Oct 10 14:01:40 UTC 2018

> On 2018. Oct 10., at 11:50, Andrew Haley <aph at> wrote:
> On 10/10/2018 10:39 AM, Luke Hutchison wrote:
>> […]
>> does not have a race condition between the "new A()" instance being
>> invoked and reachability analysis realizing that there is a "this"
>> reference in the finally block? Is it always true that there is an
>> overlap between the reference to the invocation target being held
>> and the reference to "this" in the method body being considered as
>> reachable?

> You need two threads to have a race condition. I'm not sure what
> you're trying to ask: the reachabilityFence must run strictly after
> the body of the try clause, and it the object will be reachable until
> then.

I believe the finalizer thread is the second thread he had in mind.

> […]
>>> No. Believe it or not, a live method does not constitute an access
>>> to an object. An object can die and be finalized even before one
>>> if its methods is entered.
>> That is highly surprising.
> Yes, it is . You are not the first to be surprised by this.
>> This makes finalizers a lot less reliable and more difficult to use
>> than they could be.
>> Wouldn't it make sense to consider the invocation targets in the stack
>> during liveness analysis, so that out of the cases you gave, "finalizers
>> may be run too soon (as here,) too late, or never", at least the "too soon"
>> case is fixed?
> We considered doing that; the discussion is online somewhere. I was in
> favour of doing what you suggest, but there is some performance impact
> of preserving liveness for all methods. In the end it was decided that
> we'd provide reachabilityFence.

I think the general consensus is that finalization is a shunned feature[1]. Weakening optimizations, or really making any tradeoff no matter how small for the purpose of improving finalization ergonomics is not going to happen as there’s no perceived value in doing it.


[1] unofficial term I just made up, but I like the ring of it.

> -- 
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. < <>>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

More information about the jdk-dev mailing list