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

[Vladimir Ivanov]

On Fri, 12 Sep 2025 14:09:52 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> @eme64 I think I addressed/answered all your suggestions/questions. Please, take another look. Thanks!
>
> @iwanowww Thanks for the updates! I again only looked through most comments as well.
> 
> These are the major topics for me:
> - `StressReachabilityFences` only inserts RF where they are not needed. So this allows us to test the consistency of the RF machinery, but not to test if we are missing RF where they are needed. That is much harder, and we should probably invest in writing more tests for those cases, even if it is really hard. Maybe we can even write fuzzing tests for it?
> - There seems to be missing support for carrying RF edges through incremental inlining, right? File an RFE, or track it elsewhere. Could we create a reproducer for this case / can we extend the existing one? https://github.com/openjdk/jdk/pull/25315#discussion_r2330095168
> - Are we sure that we don't eliminate the RF for the wrong allocation? https://github.com/openjdk/jdk/pull/25315#discussion_r2330230044
> - Extra compile-time due to extra loop-opts round. https://github.com/openjdk/jdk/pull/25315#discussion_r2330176841 . It used to be a 20% increase, now you managed to make it only 10%. Still considerable. All of it just to call `get_ctrl(referent)` in `enumerate_interfering_sfpts`.
> 
> I think some of these issues should also be discussed in the PR description / JIRA description.
> It would be especially nice if you could summarize the scope of the problem of RF, and which parts are now fixed, and which parts you know are not yet fixed. Of course there may be even more we don't know, but best write everything down we already do know. ;)
> 
> Other ideas:
> - You should file an RFE to add your stress flags to the stress job, and also the fuzzer.
> - I did not yet study the reproducer `TestReachabilityFence.java`. We should consider making a fuzzer style test out of it, maybe using the template framework. Feel free to just file an RFE for that, and assign it to me.
> 
> @shipilev @TobiHartmann @chhagedorn 
> I'm soon going on vacation (in a week), and so I'd like the other reviewers to be aware of these issues.
> I don't want to hold up the patch, so feel free to have someone else review. But I'm also happy to come back to this mid October.

@eme64 

> There seems to be missing support for carrying RF edges through incremental inlining, right? File an RFE, or track it elsewhere. Could we create a reproducer for this case / can we extend the existing one? https://github.com/openjdk/jdk/pull/25315#discussion_r2330095168

There's no problem there. Safepoint-attached reachability edges are introduced when no inlining is allowed. 
(There's one case when virtual calls can be strength-reduced to direct calls very late -- `Compile::process_late_inline_calls_no_inline()`, but such transformation is simply disabled for now when reachability edges are present.)

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

PR Comment: https://git.openjdk.org/jdk/pull/25315#issuecomment-3304467597