RFR: 8290892: C2: Intrinsify Reference.reachabilityFence [v3]
Vladimir Ivanov
vlivanov at openjdk.org
Wed May 28 21:48:52 UTC 2025
On Mon, 26 May 2025 11:02:25 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> But the whole point of this PR is that "current behavior" is incorrect, isn't it?
Strictly speaking, current implementation has a defect and it requires a complete rewrite on C2 side to properly fix it.
Current implementation is part of JDK for a long time (since 11). It's highly unlikely it'll be backported all the way to JDK 11 and it's an open question whether it should be backported at all. So, for diagnostic purposes it makes sense to provide a way to compare old and new implementations irrespective of whether old implementation still has the bug.
> In other words, let's not rely on intrinsic to work for correctness; non-intrinsified version should be correct as well.
A question for you: do you think we should test non-intrinsified case?
Personally, I consider such requirement as way too strong. In this particular case, the method is unconditionally intrinsified in C2. If no intrinsification takes place, it's a bug. (I'm fine with adding an assert & abort compilation if C2 ever observes `Reference.reachabilityFence()` to be inlined.)
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/25315#discussion_r2112806638
More information about the hotspot-compiler-dev
mailing list