8332082: Shenandoah: Use consistent tests to determine when pre-write barrier is active

[earthling-amzn]

trafficstars

This is consistent with c1 and other platforms.

---

Progress

• [ ] Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue

Issue

• JDK-8332082: Shenandoah: Use consistent tests to determine when pre-write barrier is active (Task - P4)

Reviewers

• Kelvin Nilsen (@kdnilsen - no project role) ⚠️ Review applies to 2769c97c

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/19180/head:pull/19180
$ git checkout pull/19180

Update a local copy of the PR:
$ git checkout pull/19180
$ git pull https://git.openjdk.org/jdk.git pull/19180/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 19180

View PR using the GUI difftool:
$ git pr show -t 19180

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/19180.diff

Webrev

Link to Webrev Comment

[bridgekeeper[bot]]

:wave: Welcome back wkemper! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk[bot]]

@earthling-amzn This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8332082: Shenandoah: Use consistent tests to determine when pre-write barrier is active

Reviewed-by: kdnilsen, shade

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 172 new commits pushed to the master branch:

• 0a9d1f8c89e946d99f01549515f6044e53992168: 8332749: Broken link in MemorySegment.Scope.html
• c9a7b9772d96d9a4825d9da2aacc277534282860: 8332829: [BACKOUT] C2: crash in compiled code because of dependency on removed range check CastIIs
• 7fd9d6c760c66d3e2f4034cf1a6b1b583ff829a9: 8332340: Add JavacBench as a test case for CDS
• 417d174aa1b7bd3b5755e5f2352d9bbe6ce6f183: 8331348: Some incremental builds deposit files in the make directory
• 303ac9f270f567d821d156f3a9d4f4c070f43f95: 8332671: Logging for pretouching thread stacks shows wrong memory range
• 90758f6735620776fcb60da9e0e2c91a4f53aaf1: 8332808: Always set java.io.tmpdir to a suitable value in the build
• e19a421c30534566ba0dea0fa84f812ebeecfc87: 8332720: ubsan: instanceKlass.cpp:3550:76: runtime error: member call on null pointer of type 'struct Array'
• 2581935b47afaf661a94c8a8e50ce08065d632f6: 8332528: Generate code in SwitchBootstraps.generateTypeSwitch that require fewer adaptations
• b890336e111ea8473ae49e9992bc2fd61e716792: 8328083: degrade virtual thread support for GetObjectMonitorUsage
• 4e6d851f3f061b4a9c2b5d2e3fba6a0277ac1f34: 8325324: Implement JEP 477: Implicitly Declared Classes and Instance Main Methods (Third Preview)
• ... and 162 more: https://git.openjdk.org/jdk/compare/2d622152b07bba0aba8fd5b1e24293e28d6e69f5...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[openjdk[bot]]

@earthling-amzn The following labels will be automatically applied to this pull request:

• hotspot
• shenandoah

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

[mlbridge[bot]]

Webrevs

• 02: Full - Incremental (cff7dc0c)
• 01: Full - Incremental (3271fecf)
• 00: Full (2769c97c)

[earthling-amzn]

Both the gc-state and satb-active flags are synchronized to thread local fields on a safepoint. I expect the cost for the barrier to access either of them is similar. However, there is some additional c2 code that looks like it recognizes the barrier IR based on the presence of nodes to load the gc state: (for example, ShenandoahBarrierSetC2::is_shenandoah_marking_if).

[earthling-amzn]

Also, as pointed out in https://github.com/openjdk/jdk/pull/18148, ShenandoahBarrierSetC2::verify_gc_barriers is looking for the IR nodes that check ShenandoahThreadLocalData::satb_mark_queue_active_offset, so inconsistencies abound. I've never seen verify_gc_barriers raise an assert , even though it is trueInDebug. Is verify_gc_barriers broken?

[shipilev]

Hold on. Here is the C2 SATB barrier check, which checks gc-state for MARKING: https://github.com/openjdk/jdk/blob/2f10a316ff0c5a4c124b94f6fabb38fb119d2c82/src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp#L241-L243

What this PR changes is ShenandoahBarrierSetAssembler::satb_write_barrier_impl, which is the SATB barrier for generic assembly code. Yes, some of that may be reached from C2.

Looking around, I see that C1 AArch64, RISC-V, x86 ShenandoahBarrierSetAssembler::generate_c1_pre_barrier_runtime_stub-s use gc_state == MARKING too: https://github.com/openjdk/jdk/blob/2f10a316ff0c5a4c124b94f6fabb38fb119d2c82/src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp#L695-L698 https://github.com/openjdk/jdk/blob/2f10a316ff0c5a4c124b94f6fabb38fb119d2c82/src/hotspot/cpu/riscv/gc/shenandoah/shenandoahBarrierSetAssembler_riscv.cpp#L642-L646 https://github.com/openjdk/jdk/blob/2f10a316ff0c5a4c124b94f6fabb38fb119d2c82/src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp#L226-L228

It looks to me the current status is:

• Assembler:
  • AArch64, RISC-V: SATBMarkQueue.isActive
  • x86, PPC: gc_state == MARKING
• C1 (IR):
  • All platforms: SATBMarkQueue.isActive
• C1 (assembler stub):
  • All platforms: gc_state == MARKING
• C2 (IR):
  • All platforms: gc-state == MARKING

So, are we better off going the other way around, towards gc-state == MARKING? This would "only" need to rewrite AArch64, RISC-V parts in assembler, and shared C1 barrier part.

[earthling-amzn]

ShenandoahBarrierSetC2::verify_gc_barriers is also looking for IR node pattern for SATBMarkQueue.isActive, so it'll need rework too.

[earthling-amzn]

We usually benchmark with tiered compilation disabled. I will run some tests with tiered compilation configured to stop at level 1.

[earthling-amzn]

Total time here is defined as the sum of 10 measurement runs for each of the 20 working benchmarks in the dacapo suite. The total time was taken for jdk:master and this PR with -XX:TieredStopAtLevel=1 to keep all benchmarks running in C1.

jdk:master:
  Category |  Count |         Total |      GeoMean |      Average |     Trim 0.1 |       StdDev |      Minimum |      Maximum
    result |    200 |   2110857.000 |     7656.397 |    10554.285 |     9063.875 |     8894.464 |     1159.000 |    36836.000

This PR:
  Category |  Count |         Total |      GeoMean |      Average |     Trim 0.1 |       StdDev |      Minimum |      Maximum
    result |    200 |   2139852.000 |     7711.781 |    10699.260 |     9129.150 |     9166.330 |     1167.000 |    37336.000

This is a 1.4% increase in total time when running with just C1. The increase at trimmed mean 10% is just 0.7%. I'm okay with this.

[earthling-amzn]

/integrate

[openjdk[bot]]

Going to push as commit ddd73b458355bffeaa8e0e5017c27d6c6af2dc94. Since your change was applied there have been 172 commits pushed to the master branch:

• 0a9d1f8c89e946d99f01549515f6044e53992168: 8332749: Broken link in MemorySegment.Scope.html
• c9a7b9772d96d9a4825d9da2aacc277534282860: 8332829: [BACKOUT] C2: crash in compiled code because of dependency on removed range check CastIIs
• 7fd9d6c760c66d3e2f4034cf1a6b1b583ff829a9: 8332340: Add JavacBench as a test case for CDS
• 417d174aa1b7bd3b5755e5f2352d9bbe6ce6f183: 8331348: Some incremental builds deposit files in the make directory
• 303ac9f270f567d821d156f3a9d4f4c070f43f95: 8332671: Logging for pretouching thread stacks shows wrong memory range
• 90758f6735620776fcb60da9e0e2c91a4f53aaf1: 8332808: Always set java.io.tmpdir to a suitable value in the build
• e19a421c30534566ba0dea0fa84f812ebeecfc87: 8332720: ubsan: instanceKlass.cpp:3550:76: runtime error: member call on null pointer of type 'struct Array'
• 2581935b47afaf661a94c8a8e50ce08065d632f6: 8332528: Generate code in SwitchBootstraps.generateTypeSwitch that require fewer adaptations
• b890336e111ea8473ae49e9992bc2fd61e716792: 8328083: degrade virtual thread support for GetObjectMonitorUsage
• 4e6d851f3f061b4a9c2b5d2e3fba6a0277ac1f34: 8325324: Implement JEP 477: Implicitly Declared Classes and Instance Main Methods (Third Preview)
• ... and 162 more: https://git.openjdk.org/jdk/compare/2d622152b07bba0aba8fd5b1e24293e28d6e69f5...master

Your commit was automatically rebased without conflicts.

[openjdk[bot]]

@earthling-amzn Pushed as commit ddd73b458355bffeaa8e0e5017c27d6c6af2dc94.

:bulb: You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.