RFR: 8299327: Allow super late barrier expansion of store barriers in C2

[Roberto Castañeda Lozano]

On Fri, 23 Dec 2022 14:29:53 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

> ZGC uses super late barrier expansion for load barriers in C2. Generational ZGC needs to do the same thing but for store barriers.

Hi Erik, god fortsättning! Looks good, I just have a few (minor) comments. Do not forget to update the copyright headers.

src/hotspot/cpu/aarch64/aarch64.ad line 7976:

> 7974: %{
> 7975:   match(Set mem (StoreP mem src));
> 7976:   predicate(n->as_Store()->barrier_data() == 0);

Why does the instruction below (`storeimmP0_volatile`) not require a similar predicate? Just checking - I guess the omission is intentional since it follows from the ZGC repo.

src/hotspot/cpu/ppc/ppc.ad line 6538:

> 6536: 
> 6537: // Store Pointer
> 6538: instruct storeP(memoryAlg4 dst, iRegPsrc src) %{

The ADLC peephole replacement logic is not barrier data-aware as far as I can see. I wonder if barrier data is propagated correctly by peephole rules like the one in https://github.com/openjdk/jdk/blob/17a3f0e2577f2f9eb3fe62a4b8261e3dbe4c3b28/src/hotspot/cpu/ppc/ppc.ad#L14877-L14881. But I guess this is a question for PPC maintainers.

src/hotspot/share/opto/graphKit.cpp line 1569:

> 1567:     st->as_Store()->set_unsafe_access();
> 1568:   }
> 1569:   if (barrier_data != 0) {

Do we need this check? The analogous load construction logic (https://github.com/openjdk/jdk/blob/17a3f0e2577f2f9eb3fe62a4b8261e3dbe4c3b28/src/hotspot/share/opto/memnode.cpp#L951) does not have it.

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

Marked as reviewed by rcastanedalo (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11779