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

[Emanuel Peter]

On Fri, 23 May 2025 04:42:08 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review feedback
>
>>> 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 😊

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

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