RFR: 8290892: C2: Intrinsify Reference.reachabilityFence [v3]

[Vladimir Ivanov]

On Thu, 29 May 2025 06:51:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> a) intrinsics are performance optimizations, not correctness building blocks; 

The fact that many intrinsics are performance optimizations doesn't mean all intrinsics should be.  

> I also cannot remember any existing intrinsic that is a counter-example for (a)

`Reference::get`.

> This is not about the backports, but about having the correct fallback when we need it.

I provided it as a justification why we may need access to current implementation even if we know it's not 100% correct. 

> Users then ask: "Is it safe to disable the intrinsic? Would my application crash/misbehave without it? Would it run slower?"

There's no single answer possible here and it depending on what users expect. If there's a severe regression after the fix, as the stop-the-gap solution, it's common to restore original behavior users had before the change arrived (and that's `-XX:DisableIntrinsic=_Reference_reachabilityFence`). If somebody asks for a workaround which is 100% correct, it can be suggested to also disable method inlining (`-XX:CompileCommand=dontinline,java.lang.ref.Reference::reachabilityFence`), but it won't be the mode they run before and it'll introduce additional risks for them (mostly, performance-wise).

So, there's a way to achieve both. Also, `-XX:DisableIntrinsic=_Reference_reachabilityFence` covers the most common scenario we may need and it's the simplest one from implementation POV.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25315#discussion_r2114437062