RFR: 8295842: Generational ZGC: Elide barriers on variable array accesses after array allocations
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...) 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) ------------- Commit messages: - Elide barriers on variable array accesses after array allocations Changes: https://git.openjdk.org/zgc/pull/8/files Webrev: https://webrevs.openjdk.org/?repo=zgc&pr=8&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8295842 Stats: 60 lines in 1 file changed: 57 ins; 0 del; 3 mod Patch: https://git.openjdk.org/zgc/pull/8.diff Fetch: git fetch https://git.openjdk.org/zgc pull/8/head:pull/8 PR: https://git.openjdk.org/zgc/pull/8
On Mon, 24 Oct 2022 13:25:22 GMT, Roberto Castañeda Lozano <rcastanedalo@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...) 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
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...) 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)
Roberto Castañeda Lozano has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Refine assertions - Avoid eliding barriers if offsets are negative or undefined - Merge zgc_generational - Elide barriers on variable array accesses after array allocations ------------- Changes: https://git.openjdk.org/zgc/pull/8/files Webrev: https://webrevs.openjdk.org/?repo=zgc&pr=8&range=01 Stats: 74 lines in 1 file changed: 71 ins; 0 del; 3 mod Patch: https://git.openjdk.org/zgc/pull/8.diff Fetch: git fetch https://git.openjdk.org/zgc pull/8/head:pull/8 PR: https://git.openjdk.org/zgc/pull/8
On Wed, 16 Nov 2022 12:11:31 GMT, Roberto Castañeda Lozano <rcastanedalo@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...) 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)
Roberto Castañeda Lozano has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
- Refine assertions - Avoid eliding barriers if offsets are negative or undefined - Merge zgc_generational - Elide barriers on variable array accesses after array allocations
Thanks for looking at this, Erik!
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?
Right. An offset can be a special value `Type::OffsetTop` (-2000000000, representing undefined values), a special value `Type::OffsetBot` (-2000000001, representing unknown values), or a concrete value. Before this PR, we simply required that offsets be concrete and >= 0. The initial version of this PR relaxes this requirement to accept unknown offsets (with offset `Type::OffsetBot`) in allocation-dominated array accesses: Element[] a = new Element[10]; // allocation a[i] = e; // variable array access with unknown offset I have pushed (and re-tested) a new version that makes offset tests more explicit, documents what is expected in each case using assertions, and actually discards candidate array accesses with undefined or concrete-but-negative offsets (which was simply assumed to not happen in the previous revision). Please let me know whether this makes the changes clearer. ------------- PR: https://git.openjdk.org/zgc/pull/8
On Wed, 16 Nov 2022 12:11:31 GMT, Roberto Castañeda Lozano <rcastanedalo@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...) 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)
Roberto Castañeda Lozano has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
- Refine assertions - Avoid eliding barriers if offsets are negative or undefined - Merge zgc_generational - Elide barriers on variable array accesses after array allocations
Thanks for the explanation Roberto. Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.org/zgc/pull/8
On Mon, 21 Nov 2022 09:38:47 GMT, Erik Österlund <eosterlund@openjdk.org> wrote:
Thanks for the explanation Roberto. Looks good.
Thanks, Erik! ------------- PR: https://git.openjdk.org/zgc/pull/8
On Mon, 24 Oct 2022 13:25:22 GMT, Roberto Castañeda Lozano <rcastanedalo@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...) 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)
This pull request has now been integrated. Changeset: 9372b37c Author: Roberto Castañeda Lozano <rcastanedalo@openjdk.org> URL: https://git.openjdk.org/zgc/commit/9372b37c8bad543147b4071644edb8b5c2f658f4 Stats: 74 lines in 1 file changed: 71 ins; 0 del; 3 mod 8295842: Generational ZGC: Elide barriers on variable array accesses after array allocations Reviewed-by: eosterlund ------------- PR: https://git.openjdk.org/zgc/pull/8
participants (2)
-
Erik Österlund
-
Roberto Castañeda Lozano