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

[Vladimir Ivanov]

On Wed, 3 Sep 2025 08:30:47 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>>>> Representing ReachabilityFence as memory barrier (e.g., MemBarCPUOrder) would solve the issue, but performance costs are prohibitively high.
>> 
>>> How bad is it? MemBarCPUOrder pinches all memory, so I assume this breaks a lot of optimizations when RF is sitting in the hot loop? I remember we went through a similar exercise with Blackholes: [JDK-8296545](https://bugs.openjdk.org/browse/JDK-8296545) -- and decided to pinch only the control. I guessing this is not enough to fix RF, or is it?
>> 
>> Yes, if a barrier stays inside loop body, it breaks a lot of important optimizations. It may end up almost as bad as a full-blown call (except a barrier can be moved around while a call can't). And moving a node when it depends both on control and memory is more complicated than just a CFG node. Moreover, as you can see in the proposed solution, even CFG-only representation is problematic for loop opts, so additional care is needed to ensure RFs are moved out of loops. 
>> 
>> As an alternative approach, I thought about reifying RF as a data node (think of `CastPP`) and then linking its referent to all safepoints it dominates after loop opts are over.  But that would only affect `optimize_reachability_fences()`. Everything else  would stay the same. So, I decided to stay with CFG-only representation for now.
>
> @iwanowww Let me know whenever this is ready to review again 😊

@eme64 please, take another look. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/25315#issuecomment-3250854323