8356075: Support Shenandoah GC in JVMCI #25001

rkennke · 2025-05-02T10:35:03Z

In order to support Shenandoah GC in Graal, some changes are required in JVMCI, namely, export Shenandoah relevant symbols.

Testing:

extensive testing with Shenandoah support oracle/graal#10904

Progress

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

Issue

JDK-8356075: Support Shenandoah GC in JVMCI (Enhancement - P4)

Reviewers

Doug Simon (@dougxc - Reviewer) Review applies to 6487a9f7
Aleksey Shipilev (@shipilev - Reviewer)
Cesar Soares Lucas (@JohnTortugo - Committer) Review applies to c95313a9

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 25001

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

Using diff file

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

Using Webrev

Link to Webrev Comment

This reverts commit d395ac2.

bridgekeeper · 2025-05-02T10:35:39Z

👋 Welcome back rkennke! 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 · 2025-05-02T10:36:06Z

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

8356075: Support Shenandoah GC in JVMCI

Reviewed-by: shade, dnsimon, cslucas

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

9f8fbf2: 8352869: Verify.checkEQ: extension for NaN, VectorAPI and arbitrary Objects
e09d2e2: 8288471: java/awt/ScrollPane/bug8077409Test.java is unstable and fails intermittently in CI
64b58f6: 8356089: java/lang/IO/IO.java fails with -XX:+AOTClassLinking
... and 74 more: https://git.openjdk.org/jdk/compare/482538b100856afe2252395d47e576e6c6d885ce...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 · 2025-05-02T10:36:37Z

@rkennke The following labels will be automatically applied to this pull request:

build
core-libs
graal
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.

rkennke · 2025-05-02T11:45:34Z

/label remove build

rkennke · 2025-05-02T11:45:47Z

/label remove core-libs

openjdk · 2025-05-02T11:46:25Z

@rkennke
The build label was successfully removed.

openjdk · 2025-05-02T11:46:55Z

@rkennke
The core-libs label was successfully removed.

mlbridge · 2025-05-05T13:43:23Z

Webrevs

dougxc

LGTM

shipilev

A few questions:

shipilev · 2025-05-05T15:31:59Z

src/hotspot/share/gc/shenandoah/shenandoahRuntime.hpp

+  static void pre_barrier(JavaThread* thread, oopDesc* orig) {
+    write_ref_field_pre(orig, thread);
+  }


So, why not export write_ref_field_pre, instead of introducing this new method? Style/cleanliness, or something else? I am asking, because every time we add a new stub here, we would need to record it in AOTCache tables for Leyden benefit.

It's about the argument ordering. Graal expects the Thread* to be prependend, while other JITs call it with the Thread* appended. I guess we could change other JIT calls to also prepend the thread, or change the interface to not pass the Thread* at all. I chose to follow G1 and export both variants.

Oh, so this matches JVMCIRuntime::write_barrier_pre for G1 (weird place to have it, but oh well).

Does Graal need the Thread* argument?

I think this method is only called when SATB buffer is full. So the performance of this method is likely not affected by getting the current thread down in caller. So I think it would be more straight-forward to sharpen ShenandoahRuntime::write_ref_field_pre by dropping Thread* and then exporting that. Maybe also under the SR::write_barrier_pre name to be even more consistent for everything else.

Maybe @JohnTortugo wants to clean up more mess in C2 related to this :)

Graal does not need the Thread* argument, but the runtime code behind write_ref_pre() currently uses it. I agree, it does not look performance critical to pass it through. However, getting rid of it seems to blow the scope of this PR. I'd rather do this as a follow-up.

Actually, I'd probably add the new entry for Graal without the Thread* argument now, and fix the others in a follow-up. Otherwise we need to deal with it on the Graal side again later once we change the entry points.

OK, but that follow-up risks changing the JVMCI interface again? How about we introduce:

static void write_barrier_pre(oopDesc* pre_val) { write_ref_field_pre(pre_val, JavaThread::current()); }

...and then the follow-up purges the old write_ref_field_pre? The implementation might need to be in .cpp.

src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp

JohnTortugo

LGTM. Thanks.

src/hotspot/share/jvmci/vmStructs_jvmci.cpp

shipilev

All right, this works, thanks!

rkennke · 2025-05-06T11:08:00Z

Thanks!

/integrate

openjdk · 2025-05-06T11:08:51Z

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

ecfaf35: 8356083: ZGC: Duplicate ZTestEntry symbols in gtests
1eee15e: 8258229: Crash in nmethod::reloc_string_for
8c4f2ff: 8356182: Build fails on aarch64 without ZGC
... and 78 more: https://git.openjdk.org/jdk/compare/482538b100856afe2252395d47e576e6c6d885ce...master

Your commit was automatically rebased without conflicts.

openjdk · 2025-05-06T11:09:00Z

@rkennke Pushed as commit 614ba9f.

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

dougxc · 2025-05-06T11:53:29Z

src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp

@@ -227,12 +236,22 @@ void CompilerToVM::Data::initialize(JVMCI_TRAPS) {
    assert(base != nullptr, "unexpected byte_map_base");
    cardtable_start_address = base;
    cardtable_shift = CardTable::card_shift();
+  } else if (bs->is_a(BarrierSet::ShenandoahBarrierSet)) {


This change is causing a failure in mach5 tier 1:

[2025-05-06T11:34:44,742Z] /workspace/open/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp:239:35: error: no member named 'ShenandoahBarrierSet' in 'BarrierSet' [2025-05-06T11:34:44,742Z] } else if (bs->is_a(BarrierSet::ShenandoahBarrierSet)) { [2025-05-06T11:34:44,742Z] ~~~~~~~~~~~~^ [2025-05-06T11:34:45,729Z] 1 error generated.

I assume it's missing #if INCLUDE_SHENANDOAHGC.

https://bugs.openjdk.org/browse/JDK-8356265

rkennke added 4 commits April 2, 2025 06:16

Graal Shenandoah support

344955a

Revert "8321373: Build should use LC_ALL=C.UTF-8"

956bbec

This reverts commit d395ac2.

Support for Shenandoah card-table barriers in JVMCI

0bcdb7d

Merge branch 'master' into graal-shenandoah-support

2f54728

openjdk bot added graal graal-dev@openjdk.org build build-dev@openjdk.org hotspot hotspot-dev@openjdk.org core-libs core-libs-dev@openjdk.org shenandoah shenandoah-dev@openjdk.org labels May 2, 2025

rkennke changed the title ~~Support Shenandoah GC in JVMCI~~ 8356075: Support Shenandoah GC in JVMCI May 2, 2025

rkennke added 3 commits May 2, 2025 12:45

Revert unrelated changes

f54cb48

Revert unrelated changes

1543e8f

Remove unnecessary stuff

25a8a6f

openjdk bot removed the build build-dev@openjdk.org label May 2, 2025

openjdk bot removed the core-libs core-libs-dev@openjdk.org label May 2, 2025

Fix ordering of includes

6487a9f

rkennke marked this pull request as ready for review May 5, 2025 13:39

openjdk bot added the rfr Pull request is ready for review label May 5, 2025

dougxc approved these changes May 5, 2025

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label May 5, 2025

shipilev reviewed May 5, 2025

View reviewed changes

Initialize cardtable_start_address to nullptr

c95313a

openjdk bot removed the ready Pull request is ready to be integrated label May 5, 2025

JohnTortugo approved these changes May 5, 2025

View reviewed changes

shipilev reviewed May 5, 2025

View reviewed changes

src/hotspot/share/jvmci/vmStructs_jvmci.cpp Outdated Show resolved Hide resolved

src/hotspot/share/jvmci/vmStructs_jvmci.cpp Outdated Show resolved Hide resolved

rkennke added 2 commits May 5, 2025 18:53

Align backslashes

4434458

Simplify pre-barrier runtime entry

41084f3

shipilev approved these changes May 6, 2025

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label May 6, 2025

openjdk bot added the integrated Pull request has been integrated label May 6, 2025

openjdk bot closed this May 6, 2025

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels May 6, 2025

dougxc reviewed May 6, 2025

View reviewed changes

rkennke mentioned this pull request May 6, 2025

8356266: Fix non-Shenandoah build after JDK-8356075 #25064

Closed

4 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

8356075: Support Shenandoah GC in JVMCI #25001

8356075: Support Shenandoah GC in JVMCI #25001

rkennke commented May 2, 2025 •

edited by openjdk bot

Loading

bridgekeeper bot commented May 2, 2025

openjdk bot commented May 2, 2025 •

edited

Loading

openjdk bot commented May 2, 2025

rkennke commented May 2, 2025

rkennke commented May 2, 2025

openjdk bot commented May 2, 2025

openjdk bot commented May 2, 2025

mlbridge bot commented May 5, 2025 •

edited

Loading

dougxc left a comment

shipilev left a comment

shipilev May 5, 2025

rkennke May 5, 2025

shipilev May 5, 2025 •

edited

Loading

rkennke May 5, 2025

rkennke May 5, 2025

shipilev May 5, 2025

JohnTortugo left a comment

shipilev left a comment

rkennke commented May 6, 2025

openjdk bot commented May 6, 2025

openjdk bot commented May 6, 2025

dougxc May 6, 2025 •

edited

Loading

8356075: Support Shenandoah GC in JVMCI #25001

8356075: Support Shenandoah GC in JVMCI #25001

Conversation

rkennke commented May 2, 2025 • edited by openjdk bot Loading

Progress

Issue

Reviewers

Reviewing

bridgekeeper bot commented May 2, 2025

openjdk bot commented May 2, 2025 • edited Loading

openjdk bot commented May 2, 2025

rkennke commented May 2, 2025

rkennke commented May 2, 2025

openjdk bot commented May 2, 2025

openjdk bot commented May 2, 2025

mlbridge bot commented May 5, 2025 • edited Loading

Webrevs

dougxc left a comment

Choose a reason for hiding this comment

shipilev left a comment

Choose a reason for hiding this comment

shipilev May 5, 2025

Choose a reason for hiding this comment

rkennke May 5, 2025

Choose a reason for hiding this comment

shipilev May 5, 2025 • edited Loading

Choose a reason for hiding this comment

rkennke May 5, 2025

Choose a reason for hiding this comment

rkennke May 5, 2025

Choose a reason for hiding this comment

shipilev May 5, 2025

Choose a reason for hiding this comment

JohnTortugo left a comment

Choose a reason for hiding this comment

shipilev left a comment

Choose a reason for hiding this comment

rkennke commented May 6, 2025

openjdk bot commented May 6, 2025

openjdk bot commented May 6, 2025

dougxc May 6, 2025 • edited Loading

Choose a reason for hiding this comment

rkennke commented May 2, 2025 •

edited by openjdk bot

Loading

openjdk bot commented May 2, 2025 •

edited

Loading

mlbridge bot commented May 5, 2025 •

edited

Loading

shipilev May 5, 2025 •

edited

Loading

dougxc May 6, 2025 •

edited

Loading