RFR: 8334060: Implementation of Late Barrier Expansion for G1 [v20]

[Roberto Castañeda Lozano]

On Fri, 13 Sep 2024 23:18:44 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Roberto Castañeda Lozano has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix a few style issues
>
> src/hotspot/share/opto/output.cpp line 2026:
> 
>> 2024:     if (n->is_MachNullCheck()) {
>> 2025:       assert(n->in(1)->as_Mach()->barrier_data() == 0,
>> 2026:              "Implicit null checks on memory accesses with barriers are not yet supported");
> 
> I don't see here changes in `lcm.cpp` which would prevent it.

I did not make any changes because the current logic in `lcm.cpp` already prevents this, albeit in a rather accidental way: `PhaseCFG::implicit_null_check` requires that all inputs of a candidate memory operation dominate the null check ([here](https://github.com/robcasloz/jdk/blob/d21104ca8ff1eef88a9d87fb78dda3009414b5b8/src/hotspot/share/opto/lcm.cpp#L310-L328)) so that it can be hoisted. This fails if the candidate memory operation has barriers because these always require `MachTemp` nodes, which are placed in the same block as the candidate and break the dominance condition. See a longer explanation [here](https://github.com/openjdk/jdk/pull/19746/files#r1715387255).

Should I add a check to `PhaseCFG::implicit_null_check` to discard these memory accesses more explicitly?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1760814745