RFR: 8295842: Generational ZGC: Elide barriers on variable array accesses after array allocations

[Erik Österlund]

On Mon, 24 Oct 2022 13:25:22 GMT, Roberto Castañeda Lozano <rcastanedalo at openjdk.org> wrote:

> This changeset extends C2's barrier elision so that variable array accesses (array accesses with unknown offset at compile-time) are elided when they are dominated by the array's allocation and no safepoint is present in between, like in this example:
> 
> 
> Element[] a = new Element[10]; // allocation
> a[i] = e; // variable array access: the barrier is elided
> 
> 
> This is achieved by relaxing the dominator-dominated pair test in [zBarrierSetC2.cpp](https://github.com/openjdk/zgc/blob/a460756f08df30af232fc631e94cf37c10c38352/src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp#L714) so that unknown memory access offsets are accepted for array allocation dominators.
> 
> This refinement does not yield significant overall throughput changes in standard benchmark suites (DaCapo, SPECjvm2008), but has been observed to at least elide a few additional  barriers in individual benchmarks, e.g. DaCapo's H2:
> 
> 
> Value[] keyValues = new Value[groupIndex.length]; // array allocation
> // update group
> for (int i = 0; i < groupIndex.length; i++) {
>     int idx = groupIndex[i];
>     Expression expr = expressions.get(idx);
>     keyValues[i] = expr.getValue(session); // store barrier is elided by this changeset
> }
> 
> 
> #### Testing
> 
> - tier1-5 (windows-x64, linux-x64, linux-aarch64, macosx-x64, and macosx-aarch64; release and debug mode)

You changed get_base_and_offset to return the base even if the offset < 0, and then where get_base_and_offset is used, you check if the offset is < 0 and treat it as if the base returned NULL. Why is that? Is it because there is some kind of array case we want to optimize for, where the offset is negative but valid?

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

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