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