From wkemper at openjdk.org Thu May 1 14:25:25 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 1 May 2025 14:25:25 GMT Subject: RFR: Merge openjdk/jdk21u:master Message-ID: Merges tag jdk-21.0.8+1 ------------- Commit messages: - 8318700: MacOS Zero cannot run gtests due to wrong JVM path - 8319690: [AArch64] C2 compilation hits offset_ok_for_immed: assert "c2 compiler bug" - 8314236: Overflow in Collections.rotate - 8320687: sun.jvmstat.monitor.MonitoredHost.getMonitoredHost() throws unexpected exceptions when invoked concurrently - 8353787: Increased number of SHA-384-Digest java.util.jar.Attributes$Name instances leading to higher memory footprint - 8352706: httpclient HeadTest does not run on HTTP2 - 8330598: java/net/httpclient/Http1ChunkedTest.java fails with java.util.MissingFormatArgumentException: Format specifier '%s' - 8343891: Test javax/swing/JTabbedPane/TestJTabbedPaneBackgroundColor.java failed - 8351086: (fc) Make java/nio/channels/FileChannel/BlockDeviceSize.java test manual - 8350224: Test javax/swing/JComboBox/TestComboBoxComponentRendering.java fails in ubuntu 23.x and later - ... and 253 more: https://git.openjdk.org/shenandoah-jdk21u/compare/42157792...d5a2f768 The webrev contains the conflicts with master: - merge conflicts: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=191&range=00.conflicts Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/191/files Stats: 83674 lines in 1494 files changed: 64735 ins; 8729 del; 10210 mod Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/191.diff Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/191/head:pull/191 PR: https://git.openjdk.org/shenandoah-jdk21u/pull/191 From wkemper at openjdk.org Thu May 1 17:43:59 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 1 May 2025 17:43:59 GMT Subject: Integrated: 8355372: GenShen: Test gc/shenandoah/generational/TestOldGrowthTriggers.java fails with UseCompactObjectHeaders enabled In-Reply-To: References: Message-ID: <3bV-rGkGRHjkUNAEElE0_aSdO8t81oMrd88bjWmZY6Y=.0df6a3b1-29db-4592-aa42-7d3d15684455@github.com> On Fri, 25 Apr 2025 20:40:09 GMT, William Kemper wrote: > Add a test case for `-XX:+UseCompactObjectHeaders`, increase pressure on old generation. I ran the test (which includes a compact object headers case now) fifty times without failure. This pull request has now been integrated. Changeset: 9e26b9fa Author: William Kemper URL: https://git.openjdk.org/jdk/commit/9e26b9facba09c4d6f516e8032b876c6d9e95e9e Stats: 24 lines in 1 file changed: 15 ins; 8 del; 1 mod 8355372: GenShen: Test gc/shenandoah/generational/TestOldGrowthTriggers.java fails with UseCompactObjectHeaders enabled Reviewed-by: ysr, kdnilsen ------------- PR: https://git.openjdk.org/jdk/pull/24888 From wkemper at openjdk.org Thu May 1 17:50:18 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 1 May 2025 17:50:18 GMT Subject: RFR: 8354541: Remove Shenandoah post barrier expand loop opts Message-ID: Conflict in file missing from 21. ------------- Commit messages: - 8354541: Remove Shenandoah post barrier expand loop opts Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/192/files Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=192&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354541 Stats: 250 lines in 5 files changed: 0 ins; 248 del; 2 mod Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/192.diff Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/192/head:pull/192 PR: https://git.openjdk.org/shenandoah-jdk21u/pull/192 From cslucas at openjdk.org Thu May 1 18:32:12 2025 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Thu, 1 May 2025 18:32:12 GMT Subject: RFR: 8354541: Remove Shenandoah post barrier expand loop opts In-Reply-To: References: Message-ID: On Thu, 1 May 2025 17:45:02 GMT, William Kemper wrote: > Conflict in file missing from 21. Thank you. LGTM. ------------- Marked as reviewed by cslucas (no project role). PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/192#pullrequestreview-2810410863 From ysr at openjdk.org Thu May 1 21:14:04 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Thu, 1 May 2025 21:14:04 GMT Subject: RFR: 8354541: Remove Shenandoah post barrier expand loop opts In-Reply-To: References: Message-ID: On Thu, 1 May 2025 17:45:02 GMT, William Kemper wrote: > Conflict in file missing from 21. Marked as reviewed by ysr (Committer). ------------- PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/192#pullrequestreview-2810738833 From wkemper at openjdk.org Thu May 1 21:43:07 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 1 May 2025 21:43:07 GMT Subject: Integrated: 8354541: Remove Shenandoah post barrier expand loop opts In-Reply-To: References: Message-ID: On Thu, 1 May 2025 17:45:02 GMT, William Kemper wrote: > Conflict in file missing from 21. This pull request has now been integrated. Changeset: 115e9281 Author: William Kemper URL: https://git.openjdk.org/shenandoah-jdk21u/commit/115e92811971684751d1b570c5982e632cdb532f Stats: 250 lines in 5 files changed: 0 ins; 248 del; 2 mod 8354541: Remove Shenandoah post barrier expand loop opts Reviewed-by: cslucas, ysr Backport-of: 4eae9b5ba61bfe262b43346a7499c98c1a54d2fe ------------- PR: https://git.openjdk.org/shenandoah-jdk21u/pull/192 From wkemper at openjdk.org Thu May 1 22:01:27 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 1 May 2025 22:01:27 GMT Subject: RFR: Merge openjdk/jdk21u:master [v2] In-Reply-To: References: Message-ID: > Merges tag jdk-21.0.8+1 William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 264 commits: - Merge tag 'jdk-21.0.8+1' into merge-jdk-21.0.8+1 Added tag jdk-21.0.8+1 for changeset d5a2f7685996 - 8318700: MacOS Zero cannot run gtests due to wrong JVM path Backport-of: 744e0893100d402b2b51762d57bcc2e99ab7fdcc - 8319690: [AArch64] C2 compilation hits offset_ok_for_immed: assert "c2 compiler bug" Backport-of: 98f0b86641d84048949ed3da1cb14f3820b01c12 - 8314236: Overflow in Collections.rotate Backport-of: 3828dc913a3ea28d622b69bd07f26949128eb5f7 - 8320687: sun.jvmstat.monitor.MonitoredHost.getMonitoredHost() throws unexpected exceptions when invoked concurrently Backport-of: 81484d8c0520cf55ec58fc7b4c81880e69537674 - 8353787: Increased number of SHA-384-Digest java.util.jar.Attributes$Name instances leading to higher memory footprint Backport-of: b64cdc28132c889ca8e21dc9534590ba2a778bcd - 8352706: httpclient HeadTest does not run on HTTP2 Backport-of: e32a0c90feb231d791e6c17e6360f629189cab8b - 8330598: java/net/httpclient/Http1ChunkedTest.java fails with java.util.MissingFormatArgumentException: Format specifier '%s' Backport-of: c9c3c1536880d81ab84d5cb55f4fd0fe3bbf60a2 - 8343891: Test javax/swing/JTabbedPane/TestJTabbedPaneBackgroundColor.java failed Backport-of: c2e14b1b304796753bea2eca81aa24ab4b3bf6db - 8351086: (fc) Make java/nio/channels/FileChannel/BlockDeviceSize.java test manual Backport-of: 08929134b3533362133139c4e964b1b28de6ebfb - ... and 254 more: https://git.openjdk.org/shenandoah-jdk21u/compare/115e9281...de4a4a11 ------------- Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/191/files Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=191&range=01 Stats: 83554 lines in 1483 files changed: 64677 ins; 8722 del; 10155 mod Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/191.diff Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/191/head:pull/191 PR: https://git.openjdk.org/shenandoah-jdk21u/pull/191 From mbaesken at openjdk.org Fri May 2 06:39:52 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 2 May 2025 06:39:52 GMT Subject: RFR: 8355372: GenShen: Test gc/shenandoah/generational/TestOldGrowthTriggers.java fails with UseCompactObjectHeaders enabled In-Reply-To: References:

<_6MD1OrkbiBPcjVkKGXvlH4xGplX11i7L_FAYKXZls8=.1a8d7276-7eac-443c-aa74-a45a3ef65e17@github.com> Message-ID: On Wed, 30 Apr 2025 15:36:32 GMT, William Kemper wrote: > have you had a chance to retest after PR#24940 was integrated? Did not see the issue again after this (of course this is no 'proof' that they will never come back), so I would say looks good ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24888#issuecomment-2846479688 From wkemper at openjdk.org Fri May 2 18:19:21 2025 From: wkemper at openjdk.org (William Kemper) Date: Fri, 2 May 2025 18:19:21 GMT Subject: Integrated: Merge openjdk/jdk21u:master In-Reply-To: References: Message-ID: On Thu, 1 May 2025 14:20:54 GMT, William Kemper wrote: > Merges tag jdk-21.0.8+1 This pull request has now been integrated. Changeset: ee00dcf4 Author: William Kemper URL: https://git.openjdk.org/shenandoah-jdk21u/commit/ee00dcf4c276ae458093483ec686b6d2f1213408 Stats: 83554 lines in 1483 files changed: 64677 ins; 8722 del; 10155 mod Merge ------------- PR: https://git.openjdk.org/shenandoah-jdk21u/pull/191 From rkennke at openjdk.org Mon May 5 13:43:23 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 5 May 2025 13:43:23 GMT Subject: RFR: 8356075: Support Shenandoah GC in JVMCI Message-ID: In order to support Shenandoah GC in Graal, some changes are required in JVMCI, namely, export Shenandoah relevant symbols. Testing: - [x] extensive testing with https://github.com/oracle/graal/pull/10904 ------------- Commit messages: - Fix ordering of includes - Remove unnecessary stuff - Revert unrelated changes - Revert unrelated changes - Merge branch 'master' into graal-shenandoah-support - Support for Shenandoah card-table barriers in JVMCI - Revert "8321373: Build should use LC_ALL=C.UTF-8" - Graal Shenandoah support Changes: https://git.openjdk.org/jdk/pull/25001/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25001&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356075 Stats: 59 lines in 6 files changed: 58 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25001.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25001/head:pull/25001 PR: https://git.openjdk.org/jdk/pull/25001 From dnsimon at openjdk.org Mon May 5 13:53:50 2025 From: dnsimon at openjdk.org (Doug Simon) Date: Mon, 5 May 2025 13:53:50 GMT Subject: RFR: 8356075: Support Shenandoah GC in JVMCI In-Reply-To: References: Message-ID: On Fri, 2 May 2025 10:35:03 GMT, Roman Kennke wrote: > In order to support Shenandoah GC in Graal, some changes are required in JVMCI, namely, export Shenandoah relevant symbols. > > Testing: > - [x] extensive testing with https://github.com/oracle/graal/pull/10904 LGTM ------------- Marked as reviewed by dnsimon (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25001#pullrequestreview-2814890860 From shade at openjdk.org Mon May 5 15:38:46 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 5 May 2025 15:38:46 GMT Subject: RFR: 8356075: Support Shenandoah GC in JVMCI In-Reply-To: References: Message-ID: <26EKhVnyWuLQxzRjvvLzzLcY2iW6fmgqs7qHWOdZQvA=.99efcb44-5788-403a-8ad1-83766184aa17@github.com> On Fri, 2 May 2025 10:35:03 GMT, Roman Kennke wrote: > In order to support Shenandoah GC in Graal, some changes are required in JVMCI, namely, export Shenandoah relevant symbols. > > Testing: > - [x] extensive testing with https://github.com/oracle/graal/pull/10904 A few questions: src/hotspot/share/gc/shenandoah/shenandoahRuntime.hpp line 42: > 40: static void pre_barrier(JavaThread* thread, oopDesc* orig) { > 41: write_ref_field_pre(orig, thread); > 42: } 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. src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp line 240: > 238: cardtable_shift = CardTable::card_shift(); > 239: } else if (bs->is_a(BarrierSet::ShenandoahBarrierSet)) { > 240: cardtable_shift = CardTable::card_shift(); I understand the barrier code does not use `cardtable_start_address`, but should we still initialize it here to `nullptr`? ------------- PR Review: https://git.openjdk.org/jdk/pull/25001#pullrequestreview-2815217376 PR Review Comment: https://git.openjdk.org/jdk/pull/25001#discussion_r2073674847 PR Review Comment: https://git.openjdk.org/jdk/pull/25001#discussion_r2073678010 From rkennke at openjdk.org Mon May 5 15:54:29 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 5 May 2025 15:54:29 GMT Subject: RFR: 8356075: Support Shenandoah GC in JVMCI [v2] In-Reply-To: References: Message-ID: > In order to support Shenandoah GC in Graal, some changes are required in JVMCI, namely, export Shenandoah relevant symbols. > > Testing: > - [x] extensive testing with https://github.com/oracle/graal/pull/10904 Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Initialize cardtable_start_address to nullptr ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25001/files - new: https://git.openjdk.org/jdk/pull/25001/files/6487a9f7..c95313a9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25001&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25001&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25001.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25001/head:pull/25001 PR: https://git.openjdk.org/jdk/pull/25001 From rkennke at openjdk.org Mon May 5 15:54:29 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 5 May 2025 15:54:29 GMT Subject: RFR: 8356075: Support Shenandoah GC in JVMCI [v2] In-Reply-To: <26EKhVnyWuLQxzRjvvLzzLcY2iW6fmgqs7qHWOdZQvA=.99efcb44-5788-403a-8ad1-83766184aa17@github.com> References: <26EKhVnyWuLQxzRjvvLzzLcY2iW6fmgqs7qHWOdZQvA=.99efcb44-5788-403a-8ad1-83766184aa17@github.com> Message-ID: On Mon, 5 May 2025 15:31:59 GMT, Aleksey Shipilev wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Initialize cardtable_start_address to nullptr > > src/hotspot/share/gc/shenandoah/shenandoahRuntime.hpp line 42: > >> 40: static void pre_barrier(JavaThread* thread, oopDesc* orig) { >> 41: write_ref_field_pre(orig, thread); >> 42: } > > 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. > src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp line 240: > >> 238: cardtable_shift = CardTable::card_shift(); >> 239: } else if (bs->is_a(BarrierSet::ShenandoahBarrierSet)) { >> 240: cardtable_shift = CardTable::card_shift(); > > I understand the barrier code does not use `cardtable_start_address`, but should we still initialize it here to `nullptr`? Good point, did that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25001#discussion_r2073702873 PR Review Comment: https://git.openjdk.org/jdk/pull/25001#discussion_r2073705091 From cslucas at openjdk.org Mon May 5 16:26:49 2025 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Mon, 5 May 2025 16:26:49 GMT Subject: RFR: 8356075: Support Shenandoah GC in JVMCI [v2] In-Reply-To: References:

Message-ID: On Mon, 5 May 2025 15:54:29 GMT, Roman Kennke wrote: >> In order to support Shenandoah GC in Graal, some changes are required in JVMCI, namely, export Shenandoah relevant symbols. >> >> Testing: >> - [x] extensive testing with https://github.com/oracle/graal/pull/10904 > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Initialize cardtable_start_address to nullptr src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 137: > 135: ZGC_ONLY(static_field(CompilerToVM::Data, sizeof_ZStoreBarrierEntry, int)) \ > 136: SHENANDOAHGC_ONLY(static_field(CompilerToVM::Data, shenandoah_in_cset_fast_test_addr, address)) \ > 137: SHENANDOAHGC_ONLY(static_field(CompilerToVM::Data, shenandoah_region_size_bytes_shift,int)) \ Also indent trailing backslashes. src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 909: > 907: SHENANDOAHGC_ONLY(declare_function(ShenandoahRuntime::load_reference_barrier_weak_narrow)) \ > 908: SHENANDOAHGC_ONLY(declare_function(ShenandoahRuntime::load_reference_barrier_phantom)) \ > 909: SHENANDOAHGC_ONLY(declare_function(ShenandoahRuntime::load_reference_barrier_phantom_narrow)) \ Also indent trailing backslashes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25001#discussion_r2073801311 PR Review Comment: https://git.openjdk.org/jdk/pull/25001#discussion_r2073801126 From rkennke at openjdk.org Mon May 5 16:58:01 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 5 May 2025 16:58:01 GMT Subject: RFR: 8356075: Support Shenandoah GC in JVMCI [v3] In-Reply-To: References: Message-ID: > In order to support Shenandoah GC in Graal, some changes are required in JVMCI, namely, export Shenandoah relevant symbols. > > Testing: > - [x] extensive testing with https://github.com/oracle/graal/pull/10904 Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Align backslashes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25001/files - new: https://git.openjdk.org/jdk/pull/25001/files/c95313a9..44344585 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25001&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25001&range=01-02 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/25001.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25001/head:pull/25001 PR: https://git.openjdk.org/jdk/pull/25001 From rkennke at openjdk.org Mon May 5 16:58:01 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 5 May 2025 16:58:01 GMT Subject: RFR: 8356075: Support Shenandoah GC in JVMCI [v3] In-Reply-To: <92qsu_6Qj0xyyGYK8dDm97enzXvKNgj7obDEHnhVcds=.d4671e44-1ef0-4c79-a286-fa578a6eb25f@github.com> References: <26EKhVnyWuLQxzRjvvLzzLcY2iW6fmgqs7qHWOdZQvA=.99efcb44-5788-403a-8ad1-83766184aa17@github.com> <92qsu_6Qj0xyyGYK8dDm97enzXvKNgj7obDEHnhVcds=.d4671e44-1ef0-4c79-a286-fa578a6eb25f@github.com> Message-ID: On Mon, 5 May 2025 16:46:46 GMT, Aleksey Shipilev wrote: >> 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25001#discussion_r2073807949 From rkennke at openjdk.org Mon May 5 16:58:02 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 5 May 2025 16:58:02 GMT Subject: RFR: 8356075: Support Shenandoah GC in JVMCI [v3] In-Reply-To: References: <26EKhVnyWuLQxzRjvvLzzLcY2iW6fmgqs7qHWOdZQvA=.99efcb44-5788-403a-8ad1-83766184aa17@github.com> <92qsu_6Qj0xyyGYK8dDm97enzXvKNgj7obDEHnhVcds=.d4671e44-1ef0-4c79-a286-fa578a6eb25f@github.com> Message-ID: <_4ebbEF2UTOwozaLgA8ibDcCi1YF5I4rKA1NN3tBozs=.7ce738b0-7e79-4c93-bc4d-63f534ccc536@github.com> On Mon, 5 May 2025 16:51:39 GMT, Roman Kennke wrote: >> 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25001#discussion_r2073813072 From shade at openjdk.org Mon May 5 17:03:47 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 5 May 2025 17:03:47 GMT Subject: RFR: 8356075: Support Shenandoah GC in JVMCI [v3] In-Reply-To: <_4ebbEF2UTOwozaLgA8ibDcCi1YF5I4rKA1NN3tBozs=.7ce738b0-7e79-4c93-bc4d-63f534ccc536@github.com> References: <26EKhVnyWuLQxzRjvvLzzLcY2iW6fmgqs7qHWOdZQvA=.99efcb44-5788-403a-8ad1-83766184aa17@github.com> <92qsu_6Qj0xyyGYK8dDm97enzXvKNgj7obDEHnhVcds=.d4671e44-1ef0-4c79-a286-fa578a6eb25f@github.com> <_4ebbEF2UTOwozaLgA8ibDcCi1YF5I4rKA1NN3tBozs=.7ce738b0-7e79-4c93-bc4d-63f534ccc536@github.com> Message-ID: On Mon, 5 May 2025 16:55:36 GMT, Roman Kennke wrote: >> 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`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25001#discussion_r2073820137 From rkennke at openjdk.org Mon May 5 20:25:27 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 5 May 2025 20:25:27 GMT Subject: RFR: 8356075: Support Shenandoah GC in JVMCI [v4] In-Reply-To: References: Message-ID: > In order to support Shenandoah GC in Graal, some changes are required in JVMCI, namely, export Shenandoah relevant symbols. > > Testing: > - [x] extensive testing with https://github.com/oracle/graal/pull/10904 Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Simplify pre-barrier runtime entry ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25001/files - new: https://git.openjdk.org/jdk/pull/25001/files/44344585..41084f3e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25001&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25001&range=02-03 Stats: 8 lines in 3 files changed: 4 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25001.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25001/head:pull/25001 PR: https://git.openjdk.org/jdk/pull/25001 From shade at openjdk.org Tue May 6 08:15:16 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 6 May 2025 08:15:16 GMT Subject: RFR: 8356075: Support Shenandoah GC in JVMCI [v4] In-Reply-To: References:

Message-ID: On Mon, 5 May 2025 20:25:27 GMT, Roman Kennke wrote: >> In order to support Shenandoah GC in Graal, some changes are required in JVMCI, namely, export Shenandoah relevant symbols. >> >> Testing: >> - [x] extensive testing with https://github.com/oracle/graal/pull/10904 > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Simplify pre-barrier runtime entry src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp line 239: > 237: cardtable_start_address = base; > 238: cardtable_shift = CardTable::card_shift(); > 239: } 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`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25001#discussion_r2075304100 From stefank at openjdk.org Thu May 8 10:06:47 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 8 May 2025 10:06:47 GMT Subject: RFR: 8356372: JVMTI heap sampling not working properly with outside TLAB allocations Message-ID: While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing: serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one. The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync. The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue. The idea is to better account how much we have allocated in three different buckets: * Outside of TLAB allocations * Accounted TLAB allocations * The last bit of TLAB allocations that hasn't been accounted yet And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample. There are a few things to think about when reading this code: * The thread can allocate and retire multiple TLABs before we cross the sample threshold. * The sampling can take multiple samples in a single TLAB * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample. There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example: 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler 2) Moved thread allocation accounting and sampling code out of the TLAB 3) Moved retiring of TLABs out of make_parseable (needed to support (2)) Some of that could be extracted into a separate PR if that's deemed worthwhile. Tested with the HeapMonitor tests various TLAB sizes. If there are anyone using these APIs it would be nice to get feedback if these changes work well for you. ------------- Commit messages: - 8356372: JVMTI heap sampling not working properly with outside TLAB allocations Changes: https://git.openjdk.org/jdk/pull/25114/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25114&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356372 Stats: 224 lines in 14 files changed: 136 ins; 42 del; 46 mod Patch: https://git.openjdk.org/jdk/pull/25114.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25114/head:pull/25114 PR: https://git.openjdk.org/jdk/pull/25114 From wkemper at openjdk.org Thu May 8 14:25:34 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 8 May 2025 14:25:34 GMT Subject: RFR: Merge openjdk/jdk21u:master Message-ID: Merges tag jdk-21.0.8+2 ------------- Commit messages: - 8353190: Use "/native" Run Option for TestAvailableProcessors Execution - 8354802: MAX_SECS definition is unused in os_linux - 8349501: Relocate supporting classes in security/testlibrary to test/lib/jdk tree - 8333680: com/sun/tools/attach/BasicTests.java fails with "SocketException: Permission denied: connect" - 8333013: Update vmTestbase/nsk/share/LocalProcess.java to don't use finalization - 8320948: NPE due to unreported compiler error The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/193/files Stats: 555 lines in 52 files changed: 228 ins; 223 del; 104 mod Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/193.diff Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/193/head:pull/193 PR: https://git.openjdk.org/shenandoah-jdk21u/pull/193