RFR: 8301584: Generational ZGC: Add barrier elision tests

[Axel Boldt-Christmas]

On Fri, 3 Feb 2023 15:19:48 GMT, Roberto Castañeda Lozano <rcastanedalo at openjdk.org> wrote:

> This changeset adds test cases exercising C2's barrier elision on combinations of different
> 
> - pairs of dominating / dominated accesses (allocations, loads, stores, atomic operations),
> - control structures (local, conditions, loops),
> - object types (arrays, class instances), and
> - levels of information available during C2's analysis (known vs. unknown array indices).
> 
> The changeset exposes node barrier data to the [IR test framework](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/lib/ir_framework/README.md) by including it in the node's dump output. This extension is useful not just for testing but also for debugging purposes, for example when exploring C2's intermediate representation with IGV:
> 
> ![igv](https://user-images.githubusercontent.com/8792647/216639224-aa288dd8-72cc-43a5-a445-a93d65004dac.png)
> 
> The following tests illustrate a missing optimization in C2's barrier elision (reported in [JDK-8301769](https://bugs.openjdk.org/browse/JDK-8301769)), where barriers that should be elided are not:
> 
> - `testStoreThenAtomic`
> - `testAtomicThenLoad`
> - `testAtomicThenStore`
> - `testAtomicThenAtomic`
> 
> The changeset does not contain IR checks expecting elision in these cases, to reduce CI pipeline noise. The tests are restricted by now to x64, since volatile loads and stores in other platforms suffer from the same issue (see [JDK-8301769](https://bugs.openjdk.org/browse/JDK-8301769)).
> 
> **Testing:** tier1-7 (windows-x64, linux-x64, macosx-x64; release and debug mode)

Looks good. Interesting test framework, good to know this exists.

We should upstream the `src/hotspot/share/gc/shared/c2/barrierSetC2.hpp` and `src/hotspot/share/opto/machnode.cpp` changes

test/hotspot/jtreg/compiler/gcbarriers/TestZGCBarrierElision.java line 329:

> 327: 
> 328:     @Test
> 329:     // The second atomic access barrier should be elided, but is not.

Is it worth explicitly documenting the behaviour and the wanted/expected behaviour in annotations?
E.g.

    @Test
    @IR(counts = { IRNode.Z_GET_AND_SET_P_WITH_BARRIER_FLAG, REMAINING, "2" }, phase = CompilePhase.FINAL_CODE)
    @IR(counts = { IRNode.Z_GET_AND_SET_P_WITH_BARRIER_FLAG, ELIDED, "0" }, phase = CompilePhase.FINAL_CODE)
    // The second atomic access barrier should be elided, but is not.
    // @IR(counts = { IRNode.Z_GET_AND_SET_P_WITH_BARRIER_FLAG, REMAINING, "1" }, phase = CompilePhase.FINAL_CODE)
    // @IR(counts = { IRNode.Z_GET_AND_SET_P_WITH_BARRIER_FLAG, ELIDED, "1" }, phase = CompilePhase.FINAL_CODE)
    static void testAtomicThenAtomic(Outer o, Inner i) {
        field1VarHandle.getAndSet​(o, i);
        field1VarHandle.getAndSet​(o, i);
    }


Same goes for all the other test cases.

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

Marked as reviewed by aboldtch (Committer).

PR: https://git.openjdk.org/zgc/pull/12