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

Emanuel Peter epeter at openjdk.org
Wed Jun 18 08:05:35 UTC 2025


On Wed, 18 Jun 2025 07:58:24 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   renaming
>
> src/hotspot/share/opto/reachability.cpp line 46:
> 
>> 44:  *     moves loop-invariant ones outside loops;
>> 45:  *   (2) reachability information is transferred to safepoint nodes (appended as edges after debug info);
>> 46:  *   (3) reachability information from safepoints materialized as RF nodes attached to the safepoint node.
> 
> Can you expand the explanation a little, please? I don't really understand. Why do you do this? What does it achieve?

It could be helpful if you wrote a paragraph (maybe at the top), about the interaction of SafePoint and ReachabilityFence. And you should also define "reachability information", I don't yet understand what that entails.

> src/hotspot/share/opto/reachability.cpp line 55:
> 
>> 53:  * RF nodes may interfere with RA, so stand-alone RF nodes are eliminated and reachability information is
>> 54:  * transferred to corresponding safepoints. When safepoints are pruned during macro expansion, corresponding
>> 55:  * reachability info also goes away.
> 
> Is it ok that this info goes away?

Is this what could currently go wrong with your implementation, or what would go wrong if we only used Safepoints?

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

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


More information about the hotspot-compiler-dev mailing list