RFR: 8358334: C2/Shenandoah: incorrect execution with Unsafe

[Aleksey Shipilev]

On Tue, 10 Jun 2025 14:13:21 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> When a barrier is expanded, some control is picked as a location for
> the barrier. The control input of data nodes that depend on that
> control are updated so the nodes are after the expanded barrier unless
> the barrier itself depends on some of those nodes.
> 
> In this particular failure, a raw memoy `Store` is the input memory to
> the barrier. That `Store` has an anti-dependent `Load`. All 3 nodes
> (barrier, `Load` and `Store`) are at the same control. The `Store` is
> an input to the barrier so it stays before the barrier. The `Load`'s
> control is updated to be after the barrier which breaks the
> anti-dependency. The bug is that the logic that sorts nodes that need
> to be before the barrier and those that can be after ignores
> anti-dependencies. The fix simply extends that logic to take them into
> account.

The patch makes sense.

I ran `make test TEST=all TEST_VM_OPTS=-XX:+UseShenandoahGC` without new failures.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25729#pullrequestreview-2918386137