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

[Erik Österlund]

Hi Andrew,

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 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.

Thanks,
/Erik

On 2018-10-10 14:38, Andrew Haley wrote:
> On 10/10/2018 11:56 AM, Luke Hutchison wrote:
>> For examle, I just tested this, and it seems to prevent the finalizer from
>> being run early (I create a local static instance FENCE of type Fence to
>> try to avoid Hotspot optimizing away the empty method
>> Fence::reachabilityFence) -- but is there a reason this could fail with
>> future Hotspot optimizations?:
> Absolutely, yes. I'm surprised it works.
>
> A volatile store will probably work, but even that isn't guaranteed
> unless someone reads the result of the store.
>