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

[Emanuel Peter]

On Tue, 9 Sep 2025 21:27:12 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> src/hotspot/share/opto/reachability.cpp line 49:
>> 
>>> 47:  *
>>> 48:  * It is tempting to directly attach referents to interfering safepoints right from the beginning, but it
>>> 49:  * doesn't play well with some optimizations C2 does.
>> 
>> Do you have an example for such optimizations?
>
> Loop-invariant code motion is one example. Do you want me to add it to the comment?
> 
> After parsing is over, the IR is in valid state, but loop optimizations are the primary reason why it can be broken later.

Just make sure that this information is in the code comments - I'm not just asking for myself here ;)

>> src/hotspot/share/opto/reachability.cpp line 71:
>> 
>>> 69:  * Unfortunately, it's not straightforward to stay with safepoint-attached representation till the very end,
>>> 70:  * because information about derived oops is attached to safepoints the very same similar way. So, for now RFs are
>>> 71:  * rematerialized at safepoints before RA (phase #3).
>> 
>> `the very same similar way` sounds a little funny. I'm also not quite seeing the problem yet. What is the issue with the edges being attached to safepoints here?
>
>> the very same similar way sounds a little funny. I
> Fixed. 
> 
>>  What is the issue with the edges being attached to safepoints here?
> 
> The issue is safepoint-attached representation conflicts with derived oops representation. There's no way to distinguish between them. As of now, VM treats post-debug info edges as representing derived oops which is completely wrong when there are reachability edges present. More work is needed to support both cases.

Ok, thanks for the explanation. Just make sure that information is in the code comments ;)

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

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