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

[Aleksey Shipilev]

On Thu, 22 May 2025 22:12:19 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/ref/Reference.java line 662:
>> 
>>> 660:      * @since 9
>>> 661:      */
>>> 662:     @IntrinsicCandidate
>> 
>> Sounds like we also want to restore `@DontInline` to cover the case when intrinsic is not available / disabled for some compiler. I vaguely remember some intrinsic handling code checks whether method is prohibited from inlining (maybe affects only global `-XX:-Inline`, not sure), so it might be as straightforward.
>
> I'd like to use `-XX:DisableIntrinsic=_Reference_reachabilityFence` to switch to current behavior (no fence).
> Also, `@DontInline` would require special handling in C1 to unconditionally inline it.
> 
> `@ForceInline` was there primarily to communicate the interaction with JVM. (Existing inlining heuristics should just unconditionally inline empty methods.) Once `@IntrinsicCandidate` is there, I don't see much value in any other annotations.

But the whole point of this PR is that "current behavior" is incorrect, isn't it?

I think disabling `_Reference_reachabilityFence` intrinsic (or, failing to inline the intrinsic for some other reason) should fail-safe to non-inlined method, not fail-deadly to a broken RF. In other words, let's not rely on intrinsic to work for correctness; non-intrinsified version should be correct as well.

I agree `@DontInline` would require a bit of extra fiddling in C1, but I suspect it should be as easy as copy-pasting a few hunks around `LIRGenerator::do_blackhole`.

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

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