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

[Vladimir Ivanov]

On Sat, 8 Nov 2025 00:36:12 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> src/hotspot/share/opto/reachability.cpp line 88:
>> 
>>> 86: // RF is redundant for some referent oop when the referent has another user which keeps it alive across the RF.
>>> 87: // In terms of dominance relation it can be formulated as "a referent has a user which is dominated by the redundant RF".
>>> 88: // Until loop opts are over, only RF nodes are considered as usages (controlled by rf_only flag).
>> 
>> Can you say why until after loop opts are over only RF are considered?
>> 
>> How does this play with allocation elimination etc? What if we run this after loop opts where we still have the allocation, but before the elimination. And then we eventually lose all referents. Could something like that happen?
>
>> Can you say why until after loop opts are over only RF are considered?
> 
> It is intended to ensure a RF is superseded by another RF. We can't guarantee that non-RF users won't go away any time before loop opts are over, so there won't be anything keeping the referent alive. 
> 
> But now I don't see why a similar problem doesn't affect RFs as well. While RFs don't go away on their own, they can be pruned as part of dead code elimination.
> 
> I'll rethink how RF redundancy is defined.
> 
>> How does this play with allocation elimination etc? 
> 
> This method works on RF nodes and, hence, it is applicable until RF nodes are eliminated after loop opts are over. 
> 
> RF nodes are ignored during scalarization attempts, so are reachability edges. When an allocation is scalarized, either all RFs having it as a referent or all of it's reachability edges are removed.

I decided to play it safe and got rid of dominance-based redundancy checks until expansion takes place.

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

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