8386292: Shenandoah: Simplify and strengthen C1 barriers by shipilev · Pull Request #31576 · openjdk/jdk

shipilev · 2026-06-18T17:11:42Z

For Valhalla enablement, I was chasing a few issues that reproduce under stress testing. A few of them are in C1 barriers, where we apparently clobber registers. This shows up prominently under heavy register pressure in Valhalla tests. We can and should simplify C1 barriers by delegating them to assembler barriers where possible. The whole lot of complexity would go away then.

Currently, Shenandoah C1 barriers are shaped like this:

Method main body: inline gc-state check, jumps to (2)
Method outline "C1 stub" that sometimes does filters, like cset checks, calls to (3)
Slow "C1 runtime stub" that optionally does even more checks, saves/restores the registers and calls the runtime

Steps (2) and (3) are the bulk of C1 barriers, those implementations are written specifically for C1. But there is no real point in having them for baseline compiler like C1. For maintainability reasons, we can delegate to assembler barriers that are at the same efficiency ballpark.

In this change, the shape of the barriers is:

Method main body: inline gc-state check, jumps to (2)
Method outline "C1 stub" that is a thin adapter for (3)
Slow "C1 runtime stub" that now delegates to assembler barrier set to generate the real meat

There are maintainability savings at steps (2) and (3), since we push down most of the implementation to (3); I believe I have fixed some register clobbering bugs that were showing up in Valhalla because of this simplification. We now do fairly little code in C1, which I am very happy with.

There are code density savings at step (2), because we do not generate a lot extra code that shows up in every C1 method. There are also assorted quality of life improvements along the way to make the code more straight-forward.

If you stand way back and look at it from a distance, you can think about this as LBE-shaped refactoring of C1 barriers. In contrast to LBE, this rewrite favors maintainability over peak performance. At some point in the future we might be able to coalesce the assembler, C1 and C2 barriers completely, but I am not 100% confident it is going to work for peak perf.

I am throwing more testing at this now, but would appreciate early review in case there are obvious gaps.

Additional testing:

Linux x86_64 server fastdebug, hotspot_gc_shenandoah
Linux x86_64 server fastdebug, tier1 with -XX:+UseShenandoahGC -XX:TieredStopAtLevel=1
Linux x86_64 server fastdebug, all with -XX:+UseShenandoahGC -XX:TieredStopAtLevel=1
Linux AArch64 server fastdebug, all with -XX:+UseShenandoahGC -XX:TieredStopAtLevel=1
Linux PPC64 / RISC-V cross-compilation and basic smoke tests

I confirm that I make this contribution in accordance with the OpenJDK Interim AI Policy.

Progress

Change must not contain extraneous whitespace
Commit message must refer to an issue
Change must be properly reviewed (2 reviews required, with at least 1 Reviewer, 1 Author)

Issue

JDK-8386292: Shenandoah: Simplify and strengthen C1 barriers (Enhancement - P4)

Reviewers

Roman Kennke (@rkennke - Reviewer)
Fei Yang (@RealFYang - Reviewer)
Kelvin Nilsen (@kdnilsen - Reviewer)

Contributors

Martin Doerr <mdoerr@openjdk.org>

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 31576

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

Using diff file

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

Using Webrev

Link to Webrev Comment

bridgekeeper · 2026-06-18T17:13:13Z

👋 Welcome back shade! 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 · 2026-06-18T17:15:08Z

@shipilev 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:

8386292: Shenandoah: Simplify and strengthen C1 barriers

Co-authored-by: Martin Doerr <mdoerr@openjdk.org>
Reviewed-by: rkennke, fyang, kdnilsen

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 54 new commits pushed to the master branch:

892c881: 8387253: Locale incorrectly accepts extlangs after non 2*3ALPHA lang
da7bde5: 8385643: Shenandoah: Rework mark loop inlining
a9fa499: 8387044: test/jdk/javax/script/CommonSetup.sh incorrectly sets isCygwin=true for MSys/MinGW
... and 51 more: https://git.openjdk.org/jdk/compare/2e179fec7b5113a3b526ee4ad5c66d6b7f0179e2...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 · 2026-06-18T17:16:14Z

@shipilev 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.

openjdk · 2026-06-18T17:16:16Z

The total number of required reviews for this PR has been set to 2 based on the presence of this label: hotspot. This can be overridden with the /reviewers command.

mlbridge · 2026-06-18T17:20:08Z

Webrevs

…t parts are dead

shipilev · 2026-06-22T15:07:34Z

/contributor add @TheRealMDoerr

openjdk · 2026-06-22T15:09:19Z

@shipilev
Contributor Martin Doerr <mdoerr@openjdk.org> successfully added.

RealFYang · 2026-06-23T01:05:12Z

+  __ prologue("shenandoah_keepalive_barrier", false);
+  const Register tmp_obj = x10;
+  const Register tmp1 = t1;
+  const Register tmp2 = t2;


t1 is one of the two reserved scratch registers which may be clobbered implicitly by some macro-assemblers.
Can we simply use x11 and x12 for tmp1 and tmp2 respectively? I think that should be safer.

Right! I think the risk is low, given we immediately stash these registers here. But you are right we might conflict somewhere down the line. If you feel x11/x12 is safer, let's do that. Done in new commit.

rkennke

This is great! And it's the right thing to do: C1 LIR should not really get any fancy stuff/control flow inserted into its basic blocks. Checking a flag and branching to a stub is about all that C1 can realistically handle.
I have carefully checked the changes and could not find anything wrong with it. (I'm not really familiar with RISCV and PPC assembly, though.)

shipilev · 2026-06-25T12:55:42Z

Thanks for looking!

@TheRealMDoerr, @RealFYang -- do you guys want to run PPC64/RISC-V testing before I integrate?

TheRealMDoerr · 2026-06-25T13:27:50Z

I had already run some tests on PPC64 and they were good. Thanks!

RealFYang

The RISC-V part seems fine to me. My local hotspot_gc_shenandoah test using fastdebug build on linux-riscv64 is good.

shipilev · 2026-06-25T15:22:21Z

Awesome, thanks for testing!

kdnilsen

I'm not fluent in C1, but everything looks good to me. I agree that this simplification is the right direction to move.

shipilev · 2026-06-26T06:16:34Z

Thanks for reviews! Here goes.

/integrate

openjdk · 2026-06-26T06:17:58Z

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

8740fbb: 8386255: Float16Vector NaN canonicalization for hashCode computation
a34314d: 8387260: Shenandoah: ShenandoahOldGeneration::_promoted_reserve should be atomic
892c881: 8387253: Locale incorrectly accepts extlangs after non 2*3ALPHA lang
... and 53 more: https://git.openjdk.org/jdk/compare/2e179fec7b5113a3b526ee4ad5c66d6b7f0179e2...master

Your commit was automatically rebased without conflicts.

openjdk · 2026-06-26T06:18:09Z

@shipilev Pushed as commit 60e4b91.

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

Fix

ac3d141

openjdk Bot added hotspot hotspot-dev@openjdk.org shenandoah shenandoah-dev@openjdk.org labels Jun 18, 2026

openjdk Bot added the rfr Pull request is ready for review label Jun 18, 2026

shipilev commented Jun 19, 2026

View reviewed changes

Comment thread src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp Outdated

shipilev added 9 commits June 22, 2026 09:14

Merge branch 'master' into JDK-8386292-shenandoah-c1-barriers

fbfb26e

PPC: Use fake frames to resolve conflict between register saves

dcb22cf

More cosmetics

a5f5824

Also handle post_barrier -> card_barrier rename

0734eca

A bit more cosmetics

7128645

Stubs are always called with resolved addresses, so patching/code_emi…

b251832

…t parts are dead

Some includes are also dead

ecea032

PPC: More cosmetics

d46fcce

PPC: More robust saving around the call

4a1c095

RealFYang reviewed Jun 23, 2026

View reviewed changes

shipilev added 3 commits June 23, 2026 08:51

PPC: More cosmetics

8fdda4b

AArch64/RISC-V: Use combined register save routines

d6d6334

RISC-V: Polish used registers

55e0210

rkennke approved these changes Jun 25, 2026

View reviewed changes

RealFYang approved these changes Jun 25, 2026

View reviewed changes

openjdk Bot added the ready Pull request is ready to be integrated label Jun 25, 2026

kdnilsen approved these changes Jun 25, 2026

View reviewed changes

openjdk Bot added the integrated Pull request has been integrated label Jun 26, 2026

openjdk Bot closed this Jun 26, 2026

openjdk Bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Jun 26, 2026

Uh oh!

Conversation

shipilev commented Jun 18, 2026 • edited by openjdk Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Contributors

Reviewing

Uh oh!

bridgekeeper Bot commented Jun 18, 2026

Uh oh!

openjdk Bot commented Jun 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openjdk Bot commented Jun 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openjdk Bot commented Jun 18, 2026

Uh oh!

mlbridge Bot commented Jun 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

Uh oh!

shipilev commented Jun 22, 2026

Uh oh!

openjdk Bot commented Jun 22, 2026

Uh oh!

RealFYang Jun 23, 2026

Choose a reason for hiding this comment

Uh oh!

shipilev Jun 23, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

rkennke left a comment

Choose a reason for hiding this comment

Uh oh!

shipilev commented Jun 25, 2026

Uh oh!

TheRealMDoerr commented Jun 25, 2026

Uh oh!

RealFYang left a comment

Choose a reason for hiding this comment

Uh oh!

shipilev commented Jun 25, 2026

Uh oh!

kdnilsen left a comment

Choose a reason for hiding this comment

Uh oh!

shipilev commented Jun 26, 2026

Uh oh!

openjdk Bot commented Jun 26, 2026

Uh oh!

openjdk Bot commented Jun 26, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

5 participants

shipilev commented Jun 18, 2026 •

edited by openjdk Bot

Loading

openjdk Bot commented Jun 18, 2026 •

edited

Loading

openjdk Bot commented Jun 18, 2026 •

edited

Loading

mlbridge Bot commented Jun 18, 2026 •

edited

Loading