> This PR introduces C2 support for `Reference.reachabilityFence()`. > > After [JDK-8199462](https://bugs.openjdk.org/browse/JDK-8199462) went in, it > was discovered that C2 may break the invariant the fix relied upon [1]. So, > this is an attempt to introduce proper support for > `Reference.reachabilityFence()` in C2. C1 is left intact for now, because > there are no signs yet it is affected. > > `Reference.reachabilityFence()` can be used in performance critical code, so > the primary goal for C2 is to reduce its runtime overhead as much as > possible. The ultimate goal is to ensure liveness information is attached to > interfering safepoints, but it takes multiple steps to properly propagate the > information through compilation pipeline without negatively affecting > generated code quality. > > Also, I don't consider this fix as complete. It does fix the reported > problem, but it doesn't provide any strong guarantees yet. In particular, > since `ReachabilityFence` is CFG-only node, nothing explicitly forbids memory > operations to float past `Reference.reachabilityFence()` and potentially > reaching some other safepoints current analysis treats as non-interfering. > Representing `ReachabilityFence` as memory barrier (e.g., `MemBarCPUOrder`) > would solve the issue, but performance costs are prohibitively high. > Alternatively, the optimization proposed in this PR can be improved to > conservatively extend referent's live range beyond `ReachabilityFence` nodes > associated with it. It would meet performance criteria, but I prefer to > implement it as a followup fix. > > Another known issue relates to reachability fences on constant oops. If such > constant is GCed (most likely, due to a bug in Java code), similar > reachability issues may arise. For now, RFs on constants are treated as > no-ops, but there's a diagnostic flag `PreserveReachabilityFencesOnConstants` > to keep the fences. I plan to address it separately. > > [1] > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/ref/Reference.java#L667 > "HotSpot JVM retains the ref and does not GC it before a call to this method, > because the JIT-compilers do not have GC-only safepoints." > > Testing: > - [x] hs-tier1 - hs-tier8 > - [x] hs-tier1 - hs-tier6 w/ -XX:+StressReachabilityFences > -XX:+VerifyLoopOptimizations > - [x] java/lang/foreign microbenchmarks
Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: Remove comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25315/files - new: https://git.openjdk.org/jdk/pull/25315/files/dc37ccad..68150cc6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25315&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25315&range=11-12 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25315/head:pull/25315 PR: https://git.openjdk.org/jdk/pull/25315
