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

[Vladimir Ivanov]

On Wed, 17 Sep 2025 01:06:50 GMT, Dean Long <dlong at openjdk.org> wrote:

>> src/hotspot/share/opto/reachability.cpp line 81:
>> 
>>> 79:  * (c) Unfortunately, it's not straightforward to stay with safepoint-attached representation till the very end,
>>> 80:  * because information about derived oops is attached to safepoints in a similar way. So, for now RFs are
>>> 81:  * rematerialized at safepoints before RA (phase #3).
>> 
>> I still don't understand this. What is similar to what? And why is that a problem?
>
> Why don't we put RF edges somewhere else, so they don't look like derived oops?  I was thinking they could go in the monitor area, or if that causes problems, we introduce a new area.

It's solely an implementation limitation. As of now, the only structure imposed on safepoint inputs relates to debug info (represented as JVMState). The rest is adhoc and there are many conflicting use cases introduced over time. The proper way to address it is to introduce proper structure for non-debug inputs, but it requires significant engineering effort to properly handle it across the whole compilation pipeline. For now, I just work-around it by performing additional transformation to avoid conflicts with existing functionality.

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

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