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

[Roland Westrelin]

On Wed, 11 Jun 2025 00:18:09 GMT, Cesar Soares Lucas <cslucas 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.
>
> LGTM. Thanks.

@JohnTortugo @earthling-amzn @shipilev thanks for the reviews and testing.

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

PR Comment: https://git.openjdk.org/jdk/pull/25729#issuecomment-2967202208