From ghan at openjdk.org Mon Sep 1 04:22:26 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Mon, 1 Sep 2025 04:22:26 GMT Subject: RFR: 8352969: G1: Improve testability of optional collections [v4] In-Reply-To: References: Message-ID: > This PR introduces a new diagnostic flag EvacuateAllOptionalRegions to force G1 GC to evacuate all optional regions regardless of the predicted pause time. The motivation is to allow testing and validation of optional region evacuation behavior without being constrained by the remaining pause time. Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Optimize implementation and add regression test - Merge remote-tracking branch 'upstream/master' into 8352969 - Update g1YoungCollector.cpp format fix - Simplified implementation - add default value - Implement JDK-8352969 ------------- Changes: https://git.openjdk.org/jdk/pull/26880/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26880&range=03 Stats: 126 lines in 4 files changed: 123 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26880.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26880/head:pull/26880 PR: https://git.openjdk.org/jdk/pull/26880 From ghan at openjdk.org Mon Sep 1 04:26:23 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Mon, 1 Sep 2025 04:26:23 GMT Subject: RFR: 8352969: G1: Improve testability of optional collections [v5] In-Reply-To: References: Message-ID: > This PR introduces a new diagnostic flag EvacuateAllOptionalRegions to force G1 GC to evacuate all optional regions regardless of the predicted pause time. The motivation is to allow testing and validation of optional region evacuation behavior without being constrained by the remaining pause time. Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: format fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26880/files - new: https://git.openjdk.org/jdk/pull/26880/files/20147777..436f3e07 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26880&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26880&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26880.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26880/head:pull/26880 PR: https://git.openjdk.org/jdk/pull/26880 From ghan at openjdk.org Mon Sep 1 04:48:28 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Mon, 1 Sep 2025 04:48:28 GMT Subject: RFR: 8352969: G1: Improve testability of optional collections [v6] In-Reply-To: References: Message-ID: > This PR introduces a new diagnostic flag EvacuateAllOptionalRegions to force G1 GC to evacuate all optional regions regardless of the predicted pause time. The motivation is to allow testing and validation of optional region evacuation behavior without being constrained by the remaining pause time. Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: fix format error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26880/files - new: https://git.openjdk.org/jdk/pull/26880/files/436f3e07..644d6d47 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26880&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26880&range=04-05 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/26880.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26880/head:pull/26880 PR: https://git.openjdk.org/jdk/pull/26880 From duke at openjdk.org Mon Sep 1 06:37:52 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 1 Sep 2025 06:37:52 GMT Subject: Integrated: 8366157: Clarify in man pages that only G1 and Parallel supports MaxGCPauseMillis In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 11:25:17 GMT, Jonas Norlinder wrote: > Hi all, > > This patch clarifies the description of `MaxGCPauseMillis`. This pull request has now been integrated. Changeset: 86f48ab5 Author: Jonas Norlinder Committer: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/86f48ab559bb1749109217aaecd1203209a5be19 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod 8366157: Clarify in man pages that only G1 and Parallel supports MaxGCPauseMillis Reviewed-by: tschatzl, sjohanss ------------- PR: https://git.openjdk.org/jdk/pull/26940 From eosterlund at openjdk.org Mon Sep 1 07:50:52 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 1 Sep 2025 07:50:52 GMT Subject: RFR: 8366462: Test gc/z/TestCommitFailure.java#Normal failed: expected output missing In-Reply-To: References: Message-ID: <2Gbp4L8Ezj-9grLwsB3-TJ4qQmnVP1n24cnSbbmyTLs=.26bef7bf-b15f-45a9-8969-bf04aad6d164@github.com> On Sun, 31 Aug 2025 10:26:28 GMT, Axel Boldt-Christmas wrote: > The newly introduced test is intermittently failing where it tries to verify that we got a commit failure. I suggest we simply remove this verification as an initial fix. > > Trying to reproduce these failure paths reliably with a blackbox test is probably not possible. So we would have to extend the JVM with whitebox hooks for doing exactly what we want. I think we need to be very careful in such a design to not affect the maintainability and readability to the code. > > For now it is enough that this test intermittently exercises the commit failure paths and intermittently would reproduce any regressions. > > The risk is having to be more diligent in the future with checking that this test still works when changing ZPageAllocator policies or implementation details. Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27023#pullrequestreview-3172488696 From aboldtch at openjdk.org Mon Sep 1 07:50:52 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 1 Sep 2025 07:50:52 GMT Subject: RFR: 8366462: Test gc/z/TestCommitFailure.java#Normal failed: expected output missing In-Reply-To: References: Message-ID: On Sun, 31 Aug 2025 10:26:28 GMT, Axel Boldt-Christmas wrote: > The newly introduced test is intermittently failing where it tries to verify that we got a commit failure. I suggest we simply remove this verification as an initial fix. > > Trying to reproduce these failure paths reliably with a blackbox test is probably not possible. So we would have to extend the JVM with whitebox hooks for doing exactly what we want. I think we need to be very careful in such a design to not affect the maintainability and readability to the code. > > For now it is enough that this test intermittently exercises the commit failure paths and intermittently would reproduce any regressions. > > The risk is having to be more diligent in the future with checking that this test still works when changing ZPageAllocator policies or implementation details. Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27023#issuecomment-3241241352 From aboldtch at openjdk.org Mon Sep 1 07:50:53 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 1 Sep 2025 07:50:53 GMT Subject: Integrated: 8366462: Test gc/z/TestCommitFailure.java#Normal failed: expected output missing In-Reply-To: References: Message-ID: <0LcisvyYkor8eKSKqhIsxwLSMPPikXqQ9xEbPfwqSYg=.8083ae05-2ae8-4372-8279-41eb45c4aa94@github.com> On Sun, 31 Aug 2025 10:26:28 GMT, Axel Boldt-Christmas wrote: > The newly introduced test is intermittently failing where it tries to verify that we got a commit failure. I suggest we simply remove this verification as an initial fix. > > Trying to reproduce these failure paths reliably with a blackbox test is probably not possible. So we would have to extend the JVM with whitebox hooks for doing exactly what we want. I think we need to be very careful in such a design to not affect the maintainability and readability to the code. > > For now it is enough that this test intermittently exercises the commit failure paths and intermittently would reproduce any regressions. > > The risk is having to be more diligent in the future with checking that this test still works when changing ZPageAllocator policies or implementation details. This pull request has now been integrated. Changeset: a9f3cb23 Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/a9f3cb23d1802ef3d3042a7f521a0747f70bc732 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8366462: Test gc/z/TestCommitFailure.java#Normal failed: expected output missing Reviewed-by: dholmes, eosterlund ------------- PR: https://git.openjdk.org/jdk/pull/27023 From jsikstro at openjdk.org Mon Sep 1 08:50:59 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Mon, 1 Sep 2025 08:50:59 GMT Subject: RFR: 8359683: ZGC: NUMA-Aware Relocation [v6] In-Reply-To: References: <_SnXFrT1StlCj4JYdTfY-S6tPa6dsi-p6VfMl01te7k=.1cabcd48-3709-4b3c-9ea8-3fc122c505fe@github.com> Message-ID: On Sat, 30 Aug 2025 05:02:00 GMT, SendaoYan wrote: >> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix grammar for iterator destruction comment > > After this PR, on my linux-x64(224 cpu threads), fastdebug build cannot start jvm with -Xmx16M sometimes. > > Does it's by designed, or it's a regress > > > ./build/linux-x86_64-server-fastdebug/images/jdk/bin/java -XX:+UseZGC -Xmx16M -version > Error occurred during initialization of VM > java.lang.OutOfMemoryError: Java heap space > at java.lang.System.initPhase2(java.base at 26-internal/System.java:1934) @sendaoYan Yes, this is a difference in behavior after this PR. Let's continue this discussion in the issue you filed at [JDK-8366476](https://bugs.openjdk.org/browse/JDK-8366476). ------------- PR Comment: https://git.openjdk.org/jdk/pull/26898#issuecomment-3241463733 From shade at openjdk.org Mon Sep 1 09:06:45 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 1 Sep 2025 09:06:45 GMT Subject: RFR: 8357188: Remove the field MemAllocator::Allocation::_overhead_limit_exceeded and the related code [v2] In-Reply-To: <4suEaL8ElbI5gbPNk1Sq0hO4j5v3SvHUemCfLDbERiY=.1d0d93ff-15f7-4f04-8cb5-a705fc2ddfce@github.com> References: <0qHdlghXGyq966nZz5mrxkDrTLtN-FNb7zqRSewz92o=.84d3673c-7526-4ad7-a37d-17c3637ce918@github.com> <4suEaL8ElbI5gbPNk1Sq0hO4j5v3SvHUemCfLDbERiY=.1d0d93ff-15f7-4f04-8cb5-a705fc2ddfce@github.com> Message-ID: On Sun, 31 Aug 2025 11:31:32 GMT, Guoxiong Li wrote: >> Hi all, >> >> After JDK-8338977 [1], the field `MemAllocator::Allocation::_overhead_limit_exceeded` and the parameter `gc_overhead_limit_was_exceeded` of the method `CollectedHeap::mem_allocate` are not used by any GC. This patch removes them. >> >> Test: >> All the tests of the command `make test TEST="hotspot:hotspot_gc"` passed locally (linux, x86_64, release build). >> >> Best Regards, >> -- Guoxiong >> >> [1] https://bugs.openjdk.org/browse/JDK-8338977 > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Remove outdated comments. Looks okay. Do we need to track down where was the last use of it? ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27020#pullrequestreview-3172785985 From ghan at openjdk.org Mon Sep 1 09:07:47 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Mon, 1 Sep 2025 09:07:47 GMT Subject: RFR: 8352969: G1: Improve testability of optional collections [v3] In-Reply-To: References: <1fNzfZ2HlfWuS2tMoENBL5Xp3wZH8XUxiXB-soC85r0=.915bb437-5655-4b21-89c4-f0a07b70c072@github.com> Message-ID: <80P3A0K986F1242p7kT448smBRWj1lhTMykAkvaGWvI=.a9d5a67c-7c63-47b6-ab84-fe158da79d70@github.com> On Wed, 27 Aug 2025 09:22:53 GMT, Thomas Schatzl wrote: >> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: >> >> Update g1YoungCollector.cpp >> >> format fix > > Changes requested by tschatzl (Reviewer). Hi @tschatzl , thank you for your comments. I've updated the PR and added a regression test. Please take a look when you have time. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26880#issuecomment-3241523625 From duke at openjdk.org Mon Sep 1 09:20:42 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 1 Sep 2025 09:20:42 GMT Subject: RFR: 8366155: Serial: Obsolete PretenureSizeThreshold In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 11:44:35 GMT, Albert Mingkun Yang wrote: > Remove obj-size checking before young/old-gen allocation -- an allocation succeeds iff there is enough free space. > > This simplifies the allocation logic: > 1. before attempting gc: `mem_allocate_work` does young-gen allocation then old-gen-no-expansion allocation > 2. after gc (still inside gc safepoint): `satisfy_failed_allocation` does young-gen allocation old-gen-with-expansion allocation > > Test: tier1-3 Marked as reviewed by fandreuz at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/26941#pullrequestreview-3172831747 From thomas.schatzl at oracle.com Mon Sep 1 09:26:37 2025 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 1 Sep 2025 11:26:37 +0200 Subject: JEP 522 performance regression with large pages In-Reply-To: <1b4d1e9b-f87d-4ef4-8eb1-8ef1706adfe8@gmail.com> References: <841c7254-6b39-476d-8fa0-22fe7506d80a@gmail.com> <1b4d1e9b-f87d-4ef4-8eb1-8ef1706adfe8@gmail.com> Message-ID: <2eb9945b-80e1-4f98-a8f6-073ca221191f@oracle.com> Hi Brian, On 28.08.25 23:49, Brian S O'Neill wrote: > Okay... > > sysctl -w vm.nr_hugepages=2048 > > java -XX:+UseG1GC --enable-native-access=ALL-UNNAMED --add-exports > java.base/jdk.internal.misc=ALL-UNNAMED --enable-native-access=ALL- > UNNAMED --add-opens java.base/jdk.internal.misc=ALL-UNNAMED -Xms3g - > Xmx3g -XX:+UseLargePages -XX:-UseTransparentHugePages
> > G1GC:???????? 234.7 seconds > G1GC JEP 522: 230.7 seconds > > So, it seems that regression is with THP. given your report about THP issues, a colleague looked into the THP code, and it seems that THP is somewhat broken for JDK 25. This is currently under investigation in https://bugs.openjdk.org/browse/JDK-8366434. Not sure if it helps here, because in both baseline and changed code the error is probably present. Hth, Thomas From stefan.johansson at oracle.com Mon Sep 1 09:51:05 2025 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Mon, 1 Sep 2025 11:51:05 +0200 Subject: JEP 522 performance regression with large pages In-Reply-To: <2eb9945b-80e1-4f98-a8f6-073ca221191f@oracle.com> References: <841c7254-6b39-476d-8fa0-22fe7506d80a@gmail.com> <1b4d1e9b-f87d-4ef4-8eb1-8ef1706adfe8@gmail.com> <2eb9945b-80e1-4f98-a8f6-073ca221191f@oracle.com> Message-ID: Hi Brian, As Thomas mentioned you uncovered a problem with THP in JDK 25. I guess the reason that you don't see the regression in your baseline is because you compare JEP 522 against JDK 24 (which is not affected by the regression), is that correct? The workaround for using THP with G1 in JDK 25 is to configure the THP mode to 'always' instead of 'madvise'. Hope this helps, Stefan On 2025-09-01 11:26, Thomas Schatzl wrote: > Hi Brian, > > On 28.08.25 23:49, Brian S O'Neill wrote: >> Okay... >> >> sysctl -w vm.nr_hugepages=2048 >> >> java -XX:+UseG1GC --enable-native-access=ALL-UNNAMED --add-exports >> java.base/jdk.internal.misc=ALL-UNNAMED --enable-native-access=ALL- >> UNNAMED --add-opens java.base/jdk.internal.misc=ALL-UNNAMED -Xms3g - >> Xmx3g -XX:+UseLargePages -XX:-UseTransparentHugePages
>> >> G1GC:???????? 234.7 seconds >> G1GC JEP 522: 230.7 seconds >> >> So, it seems that regression is with THP. > > ? given your report about THP issues, a colleague looked into the THP > code, and it seems that THP is somewhat broken for JDK 25. > > This is currently under investigation in > https://bugs.openjdk.org/browse/JDK-8366434. > > Not sure if it helps here, because in both baseline and changed code > the error is probably present. > > Hth, > ? Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aboldtch at openjdk.org Mon Sep 1 10:22:44 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 1 Sep 2025 10:22:44 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer In-Reply-To: References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> <-Ct2yCIbRn7bSazmFKxlMPMeP85zAZk3kUfP9ele4so=.78e5ec0f-2d17-45e6-a68d-9fff149577c1@github.com> Message-ID: On Fri, 29 Aug 2025 10:14:22 GMT, Afshin Zafari wrote: > To answer 'when/how does this happen?', this issue can be reproduced by running `runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java`, in which invalid values of options will be tested, particularly here `0` for `HeapBaseMinAddress`. Yeah I as I mentioned I figured that part out, it occurs when `MaxHeapSize` is not default set. I am not sure that `0` is an invalid value for `HeapBaseMinAddress` nor that it is what the test is testing. It tests both valid and invalid values. As mentioned when manually checking extreme values in `HeapBaseMinAddress` I could provoke an arithmetic overflow cause crash. `TestOptionsWithRanges.java` fails to capture this because of limitations in our `PrintFlagsRanges` option, which does not capture constraints. It prints: size_t HeapBaseMinAddress [ 0 ... 18446744073709551615 ] But on my machine (running with G1) the actual upper limit is `18446744072635809792` And running `./images/jdk/bin/java -XX:HeapBaseMinAddress=18446744072635809792 -Xmx1g --version` results in: # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (src/hotspot/share/utilities/globalDefinitions.hpp:440), pid=1726885, tid=1726886 # assert(left >= right) failed: avoid underflow - left: 0x00000000c0000000 right: 0xffffffffc0000000 ------------- PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3241790796 From gli at openjdk.org Mon Sep 1 10:53:41 2025 From: gli at openjdk.org (Guoxiong Li) Date: Mon, 1 Sep 2025 10:53:41 GMT Subject: RFR: 8357188: Remove the field MemAllocator::Allocation::_overhead_limit_exceeded and the related code [v2] In-Reply-To: References: <0qHdlghXGyq966nZz5mrxkDrTLtN-FNb7zqRSewz92o=.84d3673c-7526-4ad7-a37d-17c3637ce918@github.com> <4suEaL8ElbI5gbPNk1Sq0hO4j5v3SvHUemCfLDbERiY=.1d0d93ff-15f7-4f04-8cb5-a705fc2ddfce@github.com> Message-ID: On Mon, 1 Sep 2025 09:04:01 GMT, Aleksey Shipilev wrote: > Do we need to track down where was the last use of it? Please read the patch of JDK-8338977 [1] [2], I think the change in `parallelScavengeHeap.cpp#L327-L349` was the last use of it. [1] https://bugs.openjdk.org/browse/JDK-8338977 [2] https://github.com/openjdk/jdk/commit/ad510fb25e47098d136515c355164e5177c5b419 ------------- PR Comment: https://git.openjdk.org/jdk/pull/27020#issuecomment-3241909483 From ayang at openjdk.org Mon Sep 1 11:24:26 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 1 Sep 2025 11:24:26 GMT Subject: RFR: 8366543: Clean up include headers in numberSeq Message-ID: Trivial changing to use the correct includes in `numberSeq.hpp/cpp`. Test: tier1 ------------- Commit messages: - num-seq-header Changes: https://git.openjdk.org/jdk/pull/27031/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27031&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366543 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27031.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27031/head:pull/27031 PR: https://git.openjdk.org/jdk/pull/27031 From ayang at openjdk.org Mon Sep 1 11:33:18 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 1 Sep 2025 11:33:18 GMT Subject: RFR: 8366544: Parallel: Inline PSParallelCompact::invoke_no_policy Message-ID: <_C0xUO9ksmh-i4a1u-IcPaz5LhrLk6YhI1Qh5tS5RBM=.5af5a607-a315-4474-8f09-504d58e326a4@github.com> Trivial inlining a method to its single caller. Test: tier1 ------------- Commit messages: - pgc-trivial-inline Changes: https://git.openjdk.org/jdk/pull/27032/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27032&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366544 Stats: 11 lines in 2 files changed: 1 ins; 10 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27032.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27032/head:pull/27032 PR: https://git.openjdk.org/jdk/pull/27032 From tschatzl at openjdk.org Mon Sep 1 11:49:44 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 1 Sep 2025 11:49:44 GMT Subject: RFR: 8365922: Parallel: Group uses of GCTimeRatio to a single location [v2] In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 09:56:01 GMT, Albert Mingkun Yang wrote: >> Unify all accesses of `GCTimeRatio` to a single place so that Parallel gets a coherence view of its value within the pause, if the global variable's value is ever changed. >> >> Test: tier1-3 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - review > - Merge branch 'master' into pgc-gc-time-ratio-prepare-management > - pgc-gc-time-ratio-prepare-management Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26881#pullrequestreview-3173331324 From tschatzl at openjdk.org Mon Sep 1 12:29:42 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 1 Sep 2025 12:29:42 GMT Subject: RFR: 8366544: Parallel: Inline PSParallelCompact::invoke_no_policy In-Reply-To: <_C0xUO9ksmh-i4a1u-IcPaz5LhrLk6YhI1Qh5tS5RBM=.5af5a607-a315-4474-8f09-504d58e326a4@github.com> References: <_C0xUO9ksmh-i4a1u-IcPaz5LhrLk6YhI1Qh5tS5RBM=.5af5a607-a315-4474-8f09-504d58e326a4@github.com> Message-ID: On Mon, 1 Sep 2025 11:27:24 GMT, Albert Mingkun Yang wrote: > Trivial inlining a method to its single caller. > > Test: tier1 trivial ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27032#pullrequestreview-3173446729 From tschatzl at openjdk.org Mon Sep 1 12:41:43 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 1 Sep 2025 12:41:43 GMT Subject: RFR: 8366543: Clean up include headers in numberSeq In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 11:18:06 GMT, Albert Mingkun Yang wrote: > Trivial changing to use the correct includes in `numberSeq.hpp/cpp`. > > Test: tier1 Changes requested by tschatzl (Reviewer). src/hotspot/share/utilities/numberSeq.cpp line 25: > 23: */ > 24: > 25: #include "memory/allocation.hpp" My rule is if there is a `.inline.hpp` file, always include it instead of the `.hpp` file in the `.cpp` to be sure to catch everything (the inline.hpp always includes the .hpp); and the allocation.hpp must already be included in `numberSeq.hpp`. This just gives headaches imo when more code is moved to the `.inline.hpp` file. It works this time because nothing from `CHeapObj` is in the `inline.hpp` file, so technically the removal of this include entirely works (as mentioned in the other comment, `numberSeq.hpp` needs to include `allocation.hpp`). src/hotspot/share/utilities/numberSeq.hpp line 28: > 26: #define SHARE_UTILITIES_NUMBERSEQ_HPP > 27: > 28: #include "utilities/ostream.hpp" `CHeapObj` is from allocation.hpp. So the original include is correct. Instead of including the other header just for `outputStream`, better forward-declare it in the .hpp file here and include it in the cpp file. ------------- PR Review: https://git.openjdk.org/jdk/pull/27031#pullrequestreview-3173451879 PR Review Comment: https://git.openjdk.org/jdk/pull/27031#discussion_r2313831992 PR Review Comment: https://git.openjdk.org/jdk/pull/27031#discussion_r2313820966 From tschatzl at openjdk.org Mon Sep 1 12:59:41 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 1 Sep 2025 12:59:41 GMT Subject: RFR: 8366155: Serial: Obsolete PretenureSizeThreshold In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 11:44:35 GMT, Albert Mingkun Yang wrote: > Remove obj-size checking before young/old-gen allocation -- an allocation succeeds iff there is enough free space. > > This simplifies the allocation logic: > 1. before attempting gc: `mem_allocate_work` does young-gen allocation then old-gen-no-expansion allocation > 2. after gc (still inside gc safepoint): `satisfy_failed_allocation` does young-gen allocation old-gen-with-expansion allocation > > Test: tier1-3 Seems good. ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26941#pullrequestreview-3173572869 From ayang at openjdk.org Mon Sep 1 13:04:28 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 1 Sep 2025 13:04:28 GMT Subject: RFR: 8366543: Clean up include headers in numberSeq [v2] In-Reply-To: References: Message-ID: > Trivial changing to use the correct includes in `numberSeq.hpp/cpp`. > > Test: tier1 Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27031/files - new: https://git.openjdk.org/jdk/pull/27031/files/d45e5471..792f98e3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27031&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27031&range=00-01 Stats: 2 lines in 2 files changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27031.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27031/head:pull/27031 PR: https://git.openjdk.org/jdk/pull/27031 From ayang at openjdk.org Mon Sep 1 13:11:55 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 1 Sep 2025 13:11:55 GMT Subject: RFR: 8365922: Parallel: Group uses of GCTimeRatio to a single location [v2] In-Reply-To: References: Message-ID: <4AB6W_8YOf4rBe0G1-JTR6X77ETVOZMzVBUzlA44V1Y=.26ca7f40-c50c-4ab1-84ec-cd05eb7fb989@github.com> On Wed, 27 Aug 2025 09:56:01 GMT, Albert Mingkun Yang wrote: >> Unify all accesses of `GCTimeRatio` to a single place so that Parallel gets a coherence view of its value within the pause, if the global variable's value is ever changed. >> >> Test: tier1-3 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - review > - Merge branch 'master' into pgc-gc-time-ratio-prepare-management > - pgc-gc-time-ratio-prepare-management Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26881#issuecomment-3242310874 From ayang at openjdk.org Mon Sep 1 13:11:56 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 1 Sep 2025 13:11:56 GMT Subject: Integrated: 8365922: Parallel: Group uses of GCTimeRatio to a single location In-Reply-To: References: Message-ID: <_W5lcjkSOy0OAfsX5GMSs1_sRVcxy0JsN1yMcfhI8EU=.f72e9f30-1a9f-4c80-a1d6-b27103fec9ce@github.com> On Thu, 21 Aug 2025 10:55:23 GMT, Albert Mingkun Yang wrote: > Unify all accesses of `GCTimeRatio` to a single place so that Parallel gets a coherence view of its value within the pause, if the global variable's value is ever changed. > > Test: tier1-3 This pull request has now been integrated. Changeset: 5110d54d Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/5110d54d938b7afbdf9cfbc4501674ef7bc1d518 Stats: 42 lines in 5 files changed: 14 ins; 18 del; 10 mod 8365922: Parallel: Group uses of GCTimeRatio to a single location Reviewed-by: tschatzl, phh ------------- PR: https://git.openjdk.org/jdk/pull/26881 From ayang at openjdk.org Mon Sep 1 13:21:54 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 1 Sep 2025 13:21:54 GMT Subject: RFR: 8352969: G1: Improve testability of optional collections [v6] In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 04:48:28 GMT, Guanqiang Han wrote: >> This PR introduces a new diagnostic flag EvacuateAllOptionalRegions to force G1 GC to evacuate all optional regions regardless of the predicted pause time. The motivation is to allow testing and validation of optional region evacuation behavior without being constrained by the remaining pause time. > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > fix format error src/hotspot/share/gc/g1/g1_globals.hpp line 373: > 371: "the same or more than this number of code roots to be used.") \ > 372: \ > 373: develop(bool, EvacuateAllOptionalRegions, false, \ Since the neighboring flags all have `G1` prefix, I suggesting doing the same for this flag as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26880#discussion_r2313944193 From tschatzl at openjdk.org Mon Sep 1 13:24:37 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 1 Sep 2025 13:24:37 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v51] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 68 commits: - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * fix merge error - * forgot to actually save the files - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * remove unused G1DetachedRefinementStats_lock - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - ... and 58 more: https://git.openjdk.org/jdk/compare/98af1892...4a41b40b ------------- Changes: https://git.openjdk.org/jdk/pull/23739/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=50 Stats: 7100 lines in 112 files changed: 2584 ins; 3578 del; 938 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From syan at openjdk.org Mon Sep 1 13:51:29 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 1 Sep 2025 13:51:29 GMT Subject: RFR: 8366476: Test gc/z/TestSmallHeap.java fails OOM Message-ID: <8LyuPbOOA31cjSx6aajC62-hTnyxlWvn7xqf4pVr9Ok=.8108a15a-70d2-4d54-a1ed-a472bc406466@github.com> Hi all, The PR [JDK-8359683](https://bugs.openjdk.org/browse/JDK-8359683) added NUMA-Aware Relocation for ZGC, it's optimized for the majority of NUMA workloads, but the cost is requiring more headroom in terms of heap memory. This PR add extra JVM option "-XX:-UseNUMA" to make this test run normally. Test-fix only, change has been verified locally, no risk. ------------- Commit messages: - Add -XX:-UseNUMA to avoid OOM after JDK-8359683 - 8366476: Test gc/z/TestSmallHeap.java fails OOM Changes: https://git.openjdk.org/jdk/pull/27019/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27019&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366476 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27019.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27019/head:pull/27019 PR: https://git.openjdk.org/jdk/pull/27019 From tschatzl at openjdk.org Mon Sep 1 14:24:34 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 1 Sep 2025 14:24:34 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v52] In-Reply-To: References: Message-ID: <8ppqEuxHuhM5tXXssVXaq-uQlixvWerkx3UxT-XYTmg=.b6a5ee73-33f0-4f58-b14d-808895da6347@github.com> > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * commit merge changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23739/files - new: https://git.openjdk.org/jdk/pull/23739/files/4a41b40b..b3873d66 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=51 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=50-51 Stats: 11 lines in 2 files changed: 0 ins; 11 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From jsikstro at openjdk.org Mon Sep 1 15:32:42 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Mon, 1 Sep 2025 15:32:42 GMT Subject: RFR: 8366476: Test gc/z/TestSmallHeap.java fails OOM with many NUMA nodes In-Reply-To: <8LyuPbOOA31cjSx6aajC62-hTnyxlWvn7xqf4pVr9Ok=.8108a15a-70d2-4d54-a1ed-a472bc406466@github.com> References: <8LyuPbOOA31cjSx6aajC62-hTnyxlWvn7xqf4pVr9Ok=.8108a15a-70d2-4d54-a1ed-a472bc406466@github.com> Message-ID: On Sat, 30 Aug 2025 05:47:46 GMT, SendaoYan wrote: > Hi all, > > The PR [JDK-8359683](https://bugs.openjdk.org/browse/JDK-8359683) added NUMA-Aware Relocation for ZGC, it's optimized for the majority of NUMA workloads, but the cost is requiring more headroom in terms of heap memory. This PR add extra JVM option "-XX:-UseNUMA" to make this test run normally. > > Test-fix only, change has been verified locally, no risk. Thank you for this! I think this is a good compromise. With [JDK-8359683](https://bugs.openjdk.org/browse/JDK-8359683), the heap memory overhead now scales with the number of NUMA nodes, which means small heaps now play less nice on a machine with many NUMA nodes. test/hotspot/jtreg/gc/z/TestSmallHeap.java line 57: > 55: for (var maxCapacity: args) { > 56: ProcessTools.executeTestJava( > 57: // Disable NUMA to avoid OOM with -Xmx16M after JDK-8359683 We might fail with a larger heap on a machine with more NUMA nodes, so I'd change this to be more general. Suggestion: // Disable NUMA to avoid potential OOM after JDK-8359683 ------------- PR Review: https://git.openjdk.org/jdk/pull/27019#pullrequestreview-3174055252 PR Review Comment: https://git.openjdk.org/jdk/pull/27019#discussion_r2314234900 From ghan at openjdk.org Mon Sep 1 15:38:18 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Mon, 1 Sep 2025 15:38:18 GMT Subject: RFR: 8352969: G1: Improve testability of optional collections [v7] In-Reply-To: References: Message-ID: > This PR introduces a new diagnostic flag EvacuateAllOptionalRegions to force G1 GC to evacuate all optional regions regardless of the predicted pause time. The motivation is to allow testing and validation of optional region evacuation behavior without being constrained by the remaining pause time. Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - change flag name - Merge remote-tracking branch 'upstream/master' into 8352969 - fix format error - format fix - Optimize implementation and add regression test - Merge remote-tracking branch 'upstream/master' into 8352969 - Update g1YoungCollector.cpp format fix - Simplified implementation - add default value - Implement JDK-8352969 ------------- Changes: https://git.openjdk.org/jdk/pull/26880/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26880&range=06 Stats: 126 lines in 4 files changed: 123 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26880.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26880/head:pull/26880 PR: https://git.openjdk.org/jdk/pull/26880 From bronee at gmail.com Mon Sep 1 15:39:30 2025 From: bronee at gmail.com (Brian S O'Neill) Date: Mon, 1 Sep 2025 08:39:30 -0700 Subject: JEP 522 performance regression with large pages In-Reply-To: References: <841c7254-6b39-476d-8fa0-22fe7506d80a@gmail.com> <1b4d1e9b-f87d-4ef4-8eb1-8ef1706adfe8@gmail.com> <2eb9945b-80e1-4f98-a8f6-073ca221191f@oracle.com> Message-ID: <8073ce94-0a53-4d1d-8d67-e84521a7057a@gmail.com> Yes, I was testing with JDK 24 as the baseline. When testing with JDK 25 as the baseline, I see the same performance regression. Using 'always' instead of 'madvise' does appear to resolve the issue, but this isn't that great of a workaround. I assume it's too late for the fix to be made in time for JDK 25, and so a release note is necessary instead? When is JDK 25 u1 due to be released? On 2025-09-01 02:51 AM, Stefan Johansson wrote: > Hi Brian, > > As Thomas mentioned you uncovered a problem with THP in JDK 25. > > I guess the reason that you don't see the regression in your baseline is > because you compare JEP 522 against JDK 24 (which is not affected by the > regression), is that correct? > > The workaround for using THP with G1 in JDK 25 is to configure the THP > mode to 'always' instead of 'madvise'. > > Hope this helps, > Stefan > From ghan at openjdk.org Mon Sep 1 15:42:42 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Mon, 1 Sep 2025 15:42:42 GMT Subject: RFR: 8352969: G1: Improve testability of optional collections [v6] In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 13:18:47 GMT, Albert Mingkun Yang wrote: >> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: >> >> fix format error > > src/hotspot/share/gc/g1/g1_globals.hpp line 373: > >> 371: "the same or more than this number of code roots to be used.") \ >> 372: \ >> 373: develop(bool, EvacuateAllOptionalRegions, false, \ > > Since the neighboring flags all have `G1` prefix, I suggesting doing the same for this flag as well. Hi @albertnetymk , thanks ? fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26880#discussion_r2314251890 From syan at openjdk.org Tue Sep 2 01:44:33 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 2 Sep 2025 01:44:33 GMT Subject: RFR: 8366476: Test gc/z/TestSmallHeap.java fails OOM with many NUMA nodes [v2] In-Reply-To: <8LyuPbOOA31cjSx6aajC62-hTnyxlWvn7xqf4pVr9Ok=.8108a15a-70d2-4d54-a1ed-a472bc406466@github.com> References: <8LyuPbOOA31cjSx6aajC62-hTnyxlWvn7xqf4pVr9Ok=.8108a15a-70d2-4d54-a1ed-a472bc406466@github.com> Message-ID: > Hi all, > > The PR [JDK-8359683](https://bugs.openjdk.org/browse/JDK-8359683) added NUMA-Aware Relocation for ZGC, it's optimized for the majority of NUMA workloads, but the cost is requiring more headroom in terms of heap memory. This PR add extra JVM option "-XX:-UseNUMA" to make this test run normally. > > Test-fix only, change has been verified locally, no risk. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: update comment "Disable NUMA to avoid potential OOM after JDK-8359683" ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27019/files - new: https://git.openjdk.org/jdk/pull/27019/files/79333670..0be01611 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27019&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27019&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27019.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27019/head:pull/27019 PR: https://git.openjdk.org/jdk/pull/27019 From syan at openjdk.org Tue Sep 2 01:44:34 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 2 Sep 2025 01:44:34 GMT Subject: RFR: 8366476: Test gc/z/TestSmallHeap.java fails OOM with many NUMA nodes [v2] In-Reply-To: References: <8LyuPbOOA31cjSx6aajC62-hTnyxlWvn7xqf4pVr9Ok=.8108a15a-70d2-4d54-a1ed-a472bc406466@github.com> Message-ID: On Mon, 1 Sep 2025 15:29:38 GMT, Joel Sikstr?m wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> update comment "Disable NUMA to avoid potential OOM after JDK-8359683" > > test/hotspot/jtreg/gc/z/TestSmallHeap.java line 57: > >> 55: for (var maxCapacity: args) { >> 56: ProcessTools.executeTestJava( >> 57: // Disable NUMA to avoid OOM with -Xmx16M after JDK-8359683 > > We might fail with a larger heap on a machine with more NUMA nodes, so I'd change this to be more general. > Suggestion: > > // Disable NUMA to avoid potential OOM after JDK-8359683 Thanks, the comment has been updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27019#discussion_r2314740869 From jsikstro at openjdk.org Tue Sep 2 06:59:42 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Tue, 2 Sep 2025 06:59:42 GMT Subject: RFR: 8366476: Test gc/z/TestSmallHeap.java fails OOM with many NUMA nodes [v2] In-Reply-To: References: <8LyuPbOOA31cjSx6aajC62-hTnyxlWvn7xqf4pVr9Ok=.8108a15a-70d2-4d54-a1ed-a472bc406466@github.com> Message-ID: <4EuGOsqxCkrLVG3iTMIBbaocB5wjdDiuFl1Y7imKOSw=.ea88d501-1905-44fc-8484-e88a10a1006b@github.com> On Tue, 2 Sep 2025 01:44:33 GMT, SendaoYan wrote: >> Hi all, >> >> The PR [JDK-8359683](https://bugs.openjdk.org/browse/JDK-8359683) added NUMA-Aware Relocation for ZGC, it's optimized for the majority of NUMA workloads, but the cost is requiring more headroom in terms of heap memory. This PR add extra JVM option "-XX:-UseNUMA" to make this test run normally. >> >> Test-fix only, change has been verified locally, no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > update comment "Disable NUMA to avoid potential OOM after JDK-8359683" Marked as reviewed by jsikstro (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27019#pullrequestreview-3175130946 From ayang at openjdk.org Tue Sep 2 07:57:53 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 2 Sep 2025 07:57:53 GMT Subject: RFR: 8366544: Parallel: Inline PSParallelCompact::invoke_no_policy In-Reply-To: <_C0xUO9ksmh-i4a1u-IcPaz5LhrLk6YhI1Qh5tS5RBM=.5af5a607-a315-4474-8f09-504d58e326a4@github.com> References: <_C0xUO9ksmh-i4a1u-IcPaz5LhrLk6YhI1Qh5tS5RBM=.5af5a607-a315-4474-8f09-504d58e326a4@github.com> Message-ID: <9Xwss5D-JrrQ0iFOl6vnOruztUI8C32ibm6AUvTttNM=.5ff194a7-9aeb-483d-a73a-dce44628c8d7@github.com> On Mon, 1 Sep 2025 11:27:24 GMT, Albert Mingkun Yang wrote: > Trivial inlining a method to its single caller. > > Test: tier1 Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27032#issuecomment-3244205228 From ayang at openjdk.org Tue Sep 2 07:57:53 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 2 Sep 2025 07:57:53 GMT Subject: Integrated: 8366544: Parallel: Inline PSParallelCompact::invoke_no_policy In-Reply-To: <_C0xUO9ksmh-i4a1u-IcPaz5LhrLk6YhI1Qh5tS5RBM=.5af5a607-a315-4474-8f09-504d58e326a4@github.com> References: <_C0xUO9ksmh-i4a1u-IcPaz5LhrLk6YhI1Qh5tS5RBM=.5af5a607-a315-4474-8f09-504d58e326a4@github.com> Message-ID: On Mon, 1 Sep 2025 11:27:24 GMT, Albert Mingkun Yang wrote: > Trivial inlining a method to its single caller. > > Test: tier1 This pull request has now been integrated. Changeset: 3fb9246a Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/3fb9246af9a006c0b3a1f9c41d60dff74f7bf140 Stats: 11 lines in 2 files changed: 1 ins; 10 del; 0 mod 8366544: Parallel: Inline PSParallelCompact::invoke_no_policy Reviewed-by: tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/27032 From aboldtch at openjdk.org Tue Sep 2 08:06:47 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 2 Sep 2025 08:06:47 GMT Subject: RFR: 8366476: Test gc/z/TestSmallHeap.java fails OOM with many NUMA nodes [v2] In-Reply-To: References: <8LyuPbOOA31cjSx6aajC62-hTnyxlWvn7xqf4pVr9Ok=.8108a15a-70d2-4d54-a1ed-a472bc406466@github.com> Message-ID: <_4D9FGVauawm9ig78lVwLu3sqtBNZxtY9cxc06sZ0S8=.29aa3ef2-6e65-482e-b252-443cff3ac09a@github.com> On Tue, 2 Sep 2025 01:44:33 GMT, SendaoYan wrote: >> Hi all, >> >> The PR [JDK-8359683](https://bugs.openjdk.org/browse/JDK-8359683) added NUMA-Aware Relocation for ZGC, it's optimized for the majority of NUMA workloads, but the cost is requiring more headroom in terms of heap memory. This PR add extra JVM option "-XX:-UseNUMA" to make this test run normally. >> >> Test-fix only, change has been verified locally, no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > update comment "Disable NUMA to avoid potential OOM after JDK-8359683" lgtm. ------------- Marked as reviewed by aboldtch (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27019#pullrequestreview-3175341594 From shade at openjdk.org Tue Sep 2 08:50:09 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 2 Sep 2025 08:50:09 GMT Subject: RFR: 8231269: CompileTask::is_unloaded is slow due to JNIHandles type checks [v24] In-Reply-To: References: Message-ID: > [JDK-8163511](https://bugs.openjdk.org/browse/JDK-8163511) made the `CompileTask` improvement to avoid blocking class unloading if a relevant compile task is in queue. Current code does a sleight-of-hand to make sure the the `method*` in `CompileTask` are still valid before using them. Still a noble goal, so we keep trying to do this. > > The code tries to switch weak JNI handle with a strong one when it wants to capture the holder to block unloading. Since we are reusing the same field, we have to do type checks like `JNIHandles::is_weak_global_handle(_method_holder)`. Unfortunately, that type-check goes all the way to `OopStorage` allocation code to verify the handle is really allocated in the relevant `OopStorage`. This takes internal `OopStorage` locks, and thus is slow. > > This issue is clearly visible in Leyden, when there are lots of `CompileTask`-s in the queue, dumped by AOT code loader. It also does not help that `CompileTask::select_task` is effectively quadratic in number of methods in queue, so we end up calling `CompileTask::is_unloaded` very often. > > It is possible to mitigate this issue by splitting the related fields into weak and strong ones. But as Kim mentions in the bug, we should not be using JNI handles here at all, and instead go directly for relevant `OopStorage`-s. This is what this PR does, among other things that should hopefully make the whole mechanics clearer. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `compiler/classUnloading`, 100x still passes; these tests are sensitive to bugs in this code > - [x] Linux x86_64 server fastdebug, `all` > - [x] Linux AArch64 server fastdebug, `all` Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits: - Fix build failure - Merge branch 'master' into JDK-8231269-compile-task-weaks - Docs touchup - Use enum class - Further simplify the API - Tune up for release builds - Move release() to destructor - Deal with things without spinlocks - Merge branch 'master' into JDK-8231269-compile-task-weaks - Merge branch 'master' into JDK-8231269-compile-task-weaks - ... and 35 more: https://git.openjdk.org/jdk/compare/af532cc1...ed7aef7e ------------- Changes: https://git.openjdk.org/jdk/pull/24018/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24018&range=23 Stats: 376 lines in 14 files changed: 332 ins; 23 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/24018.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24018/head:pull/24018 PR: https://git.openjdk.org/jdk/pull/24018 From ayang at openjdk.org Tue Sep 2 09:55:59 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 2 Sep 2025 09:55:59 GMT Subject: RFR: 8366063: Parallel: Refactor copy_unmarked_to_survivor_space [v2] In-Reply-To: References: Message-ID: <5xuytARXePUU3EpnmbVQh0xTCLwkjJsv_oVLtOnIBWw=.57436e14-ca00-4fd1-b216-99f7a65d2f07@github.com> > Extract out young/old generation allocation logic so that the evacuation method flow becomes clear and easier to follow. > > Test: tier1-5; perf neutral for specjvm2008, dacapo and some synthetic bms. Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into pgc-young-gc-alloc-refactor - pgc-young-gc-alloc-refactor ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26922/files - new: https://git.openjdk.org/jdk/pull/26922/files/4127e40d..ec6f3b8f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26922&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26922&range=00-01 Stats: 17491 lines in 832 files changed: 13013 ins; 1815 del; 2663 mod Patch: https://git.openjdk.org/jdk/pull/26922.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26922/head:pull/26922 PR: https://git.openjdk.org/jdk/pull/26922 From ayang at openjdk.org Tue Sep 2 09:56:27 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 2 Sep 2025 09:56:27 GMT Subject: RFR: 8365557: Parallel: Refactor ParallelScavengeHeap::mem_allocate_work [v2] In-Reply-To: References: Message-ID: > Extract out multi-thread-safe old-gen allocation API call outside the critical-region to streamline the flow in `mem_allocate_work`. > > Test: tier1-3 Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into pgc-mem-allocate-refactor - pgc-mem-allocate-refactor ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26779/files - new: https://git.openjdk.org/jdk/pull/26779/files/d738b1e4..1160f143 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26779&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26779&range=00-01 Stats: 32243 lines in 1317 files changed: 21682 ins; 5780 del; 4781 mod Patch: https://git.openjdk.org/jdk/pull/26779.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26779/head:pull/26779 PR: https://git.openjdk.org/jdk/pull/26779 From tschatzl at openjdk.org Tue Sep 2 10:09:58 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 2 Sep 2025 10:09:58 GMT Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods [v7] In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 05:53:48 GMT, Monica Beckwith wrote: >> **Implements:** https://bugs.openjdk.org/browse/JDK-8357445 >> >> Implement time-based heap uncommit for G1 during idle periods. >> >> Key changes: >> - Added G1HeapEvaluationTask for periodic heap evaluation >> - Switch from G1ServiceTask to PeriodicTask for improved scheduling >> - Implemented time-based heap sizing policy with configurable uncommit delay >> - Added region activity tracking with last access timestamps >> - Integrated VM_G1ShrinkHeap operation for safe heap shrinking >> - Added new G1 flags: G1UseTimeBasedHeapSizing, G1TimeBasedEvaluationIntervalMillis, G1UncommitDelayMillis, G1MinRegionsToUncommit >> - Added 'sizing' log tag for heap sizing operations >> >> Comprehensive Test Coverage: >> - Enhanced TestG1RegionUncommit: minimum heap boundaries, concurrent allocation/uncommit scenarios >> - Enhanced TestTimeBasedHeapSizing: humongous object handling, rapid allocation cycles, edge cases >> - Enhanced TestTimeBasedRegionTracking: concurrent region access, lifecycle transition validation >> - Enhanced TestTimeBasedHeapConfig: parameter boundary values, small heap configurations >> >> This ensures time-based heap uncommit works correctly while maintaining all safety guarantees and test expectations. > > Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused static _uncommit_delay member and accessor I did not look through the tests yet, there are quite a few areas that need fixes first. src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1075: > 1073: > 1074: log_debug(gc, ergo, heap)("Heap resize. Requested shrinking amount: %zuB actual shrinking amount: %zuB (%u regions)", > 1075: shrink_bytes, shrunk_bytes, num_regions_removed); Suggestion: shrink_bytes, shrunk_bytes, num_regions_removed); src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1138: > 1136: return true; // We did something. > 1137: } > 1138: Where is that path actually taken? This seems very dangerous because the code apparently does not synchronize with GC operations, and this may be true if this thread is somehow activated during a GC in progress. A VM GC operation might start just before above check. src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1510: > 1508: } else { > 1509: assert(_heap_evaluation_task == nullptr, "pre-condition"); > 1510: } If the flag is manageable, it changes, so we can't not initialize the task at startup. src/hotspot/share/gc/g1/g1HeapEvaluationTask.cpp line 37: > 35: > 36: G1HeapEvaluationTask::G1HeapEvaluationTask(G1CollectedHeap* g1h, G1HeapSizingPolicy* heap_sizing_policy) : > 37: PeriodicTask(G1TimeBasedEvaluationIntervalMillis), // Use PeriodicTask with interval Periodic tasks do not have a flexible interval. So making `G1TimeBasedEvaluationIntervalMillis` manageable and changing it will have no effect (and `PeriodicTask` does not support changing intervals). src/hotspot/share/gc/g1/g1HeapEvaluationTask.cpp line 48: > 46: if (!G1UseTimeBasedHeapSizing) { > 47: return; > 48: } The task should not start if disabled. (Assuming not manageable) src/hotspot/share/gc/g1/g1HeapEvaluationTask.cpp line 54: > 52: log_trace(gc, sizing)("GC active, skipping uncommit evaluation"); > 53: return; > 54: } This is sketchy. Unless you manually sync, there is no guarantee this is valid. Also since the code is running in a separate thread that might not be stopped during GC, the GC VM operation might just start after this check. src/hotspot/share/gc/g1/g1HeapEvaluationTask.cpp line 56: > 54: } > 55: > 56: ResourceMark rm; // Ensure temporary resources are released `evaluate_heap_resize()` already does that internally. Is this one necessary? src/hotspot/share/gc/g1/g1HeapEvaluationTask.cpp line 66: > 64: log_warning(gc, sizing)("Uncommit evaluation: unexpected expansion request ignored (resize_amount=%zuB)", resize_amount); > 65: // This should not happen since uncommit-based policy only handles shrinking > 66: assert(false, "Uncommit-based heap sizing should never request expansion"); Just fail? Not sure if `evaluate_heap_resize` should have that parameter at all. src/hotspot/share/gc/g1/g1HeapEvaluationTask.cpp line 68: > 66: assert(false, "Uncommit-based heap sizing should never request expansion"); > 67: } else { > 68: log_info(gc, sizing)("Uncommit evaluation: shrinking heap by %zuMB", resize_amount / M); I am not convinced about all these `log_info` level messages. With `-Xlog:gc*` which is kind of one would use by default, one may get an awful lot of these unnecessarily (below limit to do that only every 10th attempt indicates that to me at least). src/hotspot/share/gc/g1/g1HeapRegion.cpp line 253: > 251: _age_index(G1SurvRateGroup::InvalidAgeIndex), > 252: _node_index(G1NUMA::UnknownNodeIndex), > 253: _last_access_timestamp(Ticks::now()), // Initialize timestamp with current time Since `G1HeapRegion::initialize()` is called on this region just a bit later, I recommend not wasting the time to call `Ticks::now()` for no gain. Just initialize to a high value(?) and things should work out I think if the code ever comes across such a badly initialized method. src/hotspot/share/gc/g1/g1HeapRegion.hpp line 76: > 74: class G1HeapRegion : public CHeapObj { > 75: friend class VMStructs; > 76: friend class G1Allocator; // For access to record_activity() `G1Allocator` does not access `record_activity()` at all? src/hotspot/share/gc/g1/g1HeapRegion.hpp line 257: > 255: uint _node_index; > 256: > 257: // Time-based heap sizing: tracks last allocation/access time Suggestion: // Time-based heap sizing: tracks last allocation/access time. src/hotspot/share/gc/g1/g1HeapRegion.hpp line 561: > 559: void set_node_index(uint node_index) { _node_index = node_index; } > 560: > 561: // Time-based heap sizing methods Suggestion: // Time-based heap sizing methods. src/hotspot/share/gc/g1/g1HeapRegion.hpp line 564: > 562: void record_activity() { > 563: _last_access_timestamp = Ticks::now(); > 564: } Does not seem to be used outside `G1HeapRegion`. Remove, or better just inline since it only seems to be used once. Or put the implementation into the cpp file (and make `private`). src/hotspot/share/gc/g1/g1HeapRegion.hpp line 578: > 576: Tickspan elapsed = current_time - _last_access_timestamp; > 577: return elapsed > delay; > 578: } Does not seem to be used? In general, I would tend to avoid putting policy stuff into `G1HeapRegion` which should just be a container for region state members. Also, this method is too complex imho to put into the `.hpp` file directly (should be in `.inline.hpp`), but since this method should be removed anyway.... src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 454: > 452: class UncommitCandidatesClosure : public G1HeapRegionClosure { > 453: GrowableArray* _candidates; > 454: uint* _inactive_regions; Taking a reference here (`uint& _inactive_regions`) might avoid the manual dereferences. But this value seems to be the same as the current number of elements in the `_candidates` array? Seems superfluous. src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 456: > 454: uint* _inactive_regions; > 455: const G1HeapSizingPolicy* _policy; > 456: public: Suggestion: public: src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 465: > 463: > 464: virtual bool do_heap_region(G1HeapRegion* r) { > 465: if (r->is_empty() && _policy->should_uncommit_region(r)) { This should be `r->is_free()`. Any region may be empty (like a pinned old region that only has references from native code), but not `Free`. I think all uses of `is_empty()` are wrong in this change. src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 483: > 481: log_debug(gc, sizing)("Full region scan: found %u inactive regions out of %u total regions", > 482: inactive_regions, > 483: _g1h->max_num_regions()); Note that "inactive" is already used in region management - regions that G1 only queued for actual uncommit. I do not think it is necessary to use this adjective at all in the messages, so no need to think of something else here. Maybe something like "idle-free"/"idle" or so. Should also integrate with the `G1HeapRegionPrinter` (otoh since we are not guaranteed to remove exactly these regions, probably it's better to not do that). src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 488: > 486: bool G1HeapSizingPolicy::should_uncommit_region(G1HeapRegion* hr) const { > 487: // Note: Caller already guarantees hr->is_empty() is true > 488: // Empty regions should always be free and not in collection set in normal operation Sentences should end with a full stop in comments (I am stopping commenting on this here, but there are quite a few of those). src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 507: > 505: } > 506: > 507: size_t G1HeapSizingPolicy::evaluate_heap_resize(bool& expand) { Should be renamed to better indicate that this is about getting idle free regions. src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 517: > 515: if (_g1h->is_stw_gc_active()) { > 516: return 0; > 517: } This check seems superfluous. The code takes the heap lock anyway which the GC also needs to take. The only caller also already does that. And as mentioned there, this check is not sufficient to guarantee what you want. src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 521: > 519: // Must hold Heap_lock during heap resizing > 520: MutexLocker ml(Heap_lock); > 521: Since this can be entered right after a garbage collection, maybe the evaluation should be immediately exited in that case? Garbage collection already found the "right" heap size, no need for idle calculation. Otoh, `get_uncommit_candidates()` should find nothing in this case. src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 526: > 524: // Find regions eligible for uncommit > 525: GrowableArray candidates; > 526: get_uncommit_candidates(&candidates); There does not seem to be a point in collecting the actual regions in that array at all as far as I can tell. It's not used further down the code. If we do not do that, it should be removed. src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 531: > 529: uint total_regions = _g1h->max_num_regions(); > 530: > 531: // Need minimum number of inactive regions to proceed Please call them "idle-free"/"idle" or something else due to the concerns mentioned above. This needs to be changed throughout. src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 535: > 533: size_t region_size = G1HeapRegion::GrainBytes; > 534: size_t current_heap = _g1h->capacity(); > 535: size_t min_heap = MAX2((size_t)InitialHeapSize, MinHeapSize); // Never go below initial size `InitialHeapSize` is already a `size_t`. src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 550: > 548: // 1. No more than 25% of inactive regions > 549: // 2. No more than 10% of total committed regions > 550: // 3. No more than max_shrink_bytes worth of regions This policy sounds like `Min/MaxHeapFreeRatio` that are known to be not useful. Do not have a better idea right now either. Maybe look at what ZGC did at some point. src/hotspot/share/gc/g1/g1VMOperations.cpp line 175: > 173: > 174: void VM_G1ShrinkHeap::doit() { > 175: _g1h->shrink(_bytes); I strongly believe that the shrink amount needs to be re-evaluated in the shrink pause again (ideally it would not need a VM operation, but I think this is not necessary for now). Between posting the VM operation and actual execution there can be any number of more (GC) VM operations that can change the shape of the heap, so the amount of necessary shrinking can change substantially. Also, there needs to be some synchronization between the selection of regions made during determining that we should do this and the actual shrinking. There is the risk that the region selection bases its decision based on e.g. region A, B, C being too old, and then uncommits regions D, E, and F here. Next time the idleness will be evaluated, regions A, B, and C will be found again as too old, so keeping on shrinking until eventually A, B, and C are uncommitted. However the original goal of the method would have been to _only_ uncommit A, B and C. Which means this mechanism uncommitted way too many regions. ------------- Changes requested by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26240#pullrequestreview-3159175723 PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2303486703 PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2303843005 PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2303644365 PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2315588705 PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2303631395 PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2303635137 PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2303737631 PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2303633302 PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2303689194 PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2303677389 PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2303712006 PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2303678087 PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2303678493 PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2303711237 PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2303705218 PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2303742062 PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2303742530 PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2303747516 PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2303755891 PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2303724705 PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2303781225 PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2303736334 PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2303789544 PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2303775808 PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2303790596 PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2303798443 PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2315512135 PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2315522764 From tschatzl at openjdk.org Tue Sep 2 10:09:59 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 2 Sep 2025 10:09:59 GMT Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods [v7] In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 11:20:36 GMT, Thomas Schatzl wrote: >> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unused static _uncommit_delay member and accessor > > src/hotspot/share/gc/g1/g1HeapEvaluationTask.cpp line 54: > >> 52: log_trace(gc, sizing)("GC active, skipping uncommit evaluation"); >> 53: return; >> 54: } > > This is sketchy. Unless you manually sync, there is no guarantee this is valid. Also since the code is running in a separate thread that might not be stopped during GC, the GC VM operation might just start after this check. I.e. use `SuspendibleThreadSetJoiner` etc. > src/hotspot/share/gc/g1/g1HeapRegion.cpp line 253: > >> 251: _age_index(G1SurvRateGroup::InvalidAgeIndex), >> 252: _node_index(G1NUMA::UnknownNodeIndex), >> 253: _last_access_timestamp(Ticks::now()), // Initialize timestamp with current time > > Since `G1HeapRegion::initialize()` is called on this region just a bit later, I recommend not wasting the time to call `Ticks::now()` for no gain. Just initialize to a high value(?) and things should work out I think if the code ever comes across such a badly initialized method. Fwiw, to avoid startup delays (calling `Ticks::now()` on thousands of regions is expensive - I did not test, but it seems reasonable and should be measured), it might be useful to do that initialization lazily (first time the background thread executes). > src/hotspot/share/gc/g1/g1HeapRegion.hpp line 257: > >> 255: uint _node_index; >> 256: >> 257: // Time-based heap sizing: tracks last allocation/access time > > Suggestion: > > // Time-based heap sizing: tracks last allocation/access time. The comment is wrong/outdated too, only tracks last freeing (clearing) time. Maybe there is a better name than `_last_access_time` for the member too. > src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 550: > >> 548: // 1. No more than 25% of inactive regions >> 549: // 2. No more than 10% of total committed regions >> 550: // 3. No more than max_shrink_bytes worth of regions > > This policy sounds like `Min/MaxHeapFreeRatio` that are known to be not useful. Do not have a better idea right now either. Maybe look at what ZGC did at some point. I also do not think this mechanism should ever uncommit the free regions reserved for the current young gen (without GC/recalculating the needed young gen) and potentially the survivor/old regions. There does not seem to be a limit here. Otherwise the next GC (or just continuing work) will be riddled with in-pause commits. Or it will probably do a premature GC, I did not check. Maybe this change should only madvise these regions as MADV_DONTNEED? (Not sure it does anything though). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2303669369 PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2303701876 PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2303714473 PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2315538730 From tschatzl at openjdk.org Tue Sep 2 10:10:01 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 2 Sep 2025 10:10:01 GMT Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods [v4] In-Reply-To: References: Message-ID: On Thu, 17 Jul 2025 12:37:11 GMT, Ivan Walulya wrote: >> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: >> >> 8357445: Remove redundant record_activity calls and leftover initialize call >> >> - Remove record_activity() from retirement methods as hr_clear() is always last >> - Remove leftover initialize() call since initialization moved to constructor >> - Remove unused G1 includes from vmOperations after moving VM_G1ShrinkHeap > > src/hotspot/share/gc/g1/g1HeapEvaluationTask.hpp line 36: > >> 34: // Time-based heap evaluation task that runs during idle periods. >> 35: // Uses PeriodicTask rather than G1ServiceTask due to build compatibility issues >> 36: // in JDK 25+. PeriodicTask's 10ms granularity is adequate for heap evaluation > > Can you please elaborate on these "compatibility issues" +1. I would absolutely try to avoid subscribing to `PeriodicTask`. Is there something missing with `G1ServiceTask`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2303638363 From tschatzl at openjdk.org Tue Sep 2 10:10:02 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 2 Sep 2025 10:10:02 GMT Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods [v7] In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 11:53:17 GMT, Thomas Schatzl wrote: >> src/hotspot/share/gc/g1/g1HeapRegion.cpp line 253: >> >>> 251: _age_index(G1SurvRateGroup::InvalidAgeIndex), >>> 252: _node_index(G1NUMA::UnknownNodeIndex), >>> 253: _last_access_timestamp(Ticks::now()), // Initialize timestamp with current time >> >> Since `G1HeapRegion::initialize()` is called on this region just a bit later, I recommend not wasting the time to call `Ticks::now()` for no gain. Just initialize to a high value(?) and things should work out I think if the code ever comes across such a badly initialized method. > > Fwiw, to avoid startup delays (calling `Ticks::now()` on thousands of regions is expensive - I did not test, but it seems reasonable and should be measured), it might be useful to do that initialization lazily (first time the background thread executes). There is potentially the same issue about calling `Ticks::now()` for thousands of freed regions during GC. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2303716836 From tschatzl at openjdk.org Tue Sep 2 10:10:02 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 2 Sep 2025 10:10:02 GMT Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods [v4] In-Reply-To: References: <2AgG77y3-6NXn1ztkmUWgSLk7ldhKq5Pd1EfAV9cAO4=.d463af22-5fd0-4d47-a758-1e5319af1955@github.com> Message-ID: On Thu, 31 Jul 2025 21:13:37 GMT, Monica Beckwith wrote: >> One reason why I do not see the need for these flags to be manageable is that this heap shrinking is a supportive function if the application is "idle". Main heap sizing should be done by the existing heap sizing/AHS at GC events. >> >> From the CR text: >>> Doing heap sizing based on garbage collections has a big disadvantage: if there are no garbage collections (due to no application activity) there is a risk that a large amount of heap is kept committed unnecessarily *for a long time*. >> (emphasis mine) >> >> If we are talking about "a long time", so there does not seem to be a need for changing it during runtime (or change it at all). It should not matter if that "long time" is "long time +- small epsilon", and so, allowing dynamic change of "a long time" to another "long time" seems unnecessary without a very good use case. >> >> Please consider not necessarily the current situation, but with "full" AHS. >> >> Another question is whether you had thoughts about the interaction with (JDK-8213198)[https://bugs.openjdk.org/browse/JDK-8213198], as this change seems to be a subset of the other. (That's just curiosity from me, I think this feature is useful as is, and if the other ever materializes, we can always reconsider). >> >> Otoh decreasing the heap by this mechanism will eventually trigger a marking. > > @tschatzl Thanks for the detailed feedback! > Flag Changes (per your feedback): > > - G1UseTimeBasedHeapSizing is now diagnostic and enabled by default (was experimental/disabled). > - G1MinRegionsToUncommit is now diagnostic (was experimental). > - Timing flags (G1UncommitDelayMillis, G1TimeBasedEvaluationIntervalMillis) remain manageable to support operational use cases. > > > ## Manageable Flag Use Cases > I can see 3 scenarios where runtime adjustment is valuable: > > **High-Availability Services** > - 24/7 operations cannot restart for tuning adjustments > - Memory pressure events require immediate response > - Cost optimization demands dynamic resource adaptation > > **Cloud & Container Platforms** > - Resource limits change dynamically (auto-scaling) > - Multi-tenancy requires per-workload optimization > - Cost efficiency drives aggressive memory reclaim > > **DevOps & SRE Teams** > - Incident response needs immediate memory reclaim > - Performance testing requires runtime comparison of settings > - Capacity planning benefits from live tuning experiments > > ## "Long Time" Consideration > While the feature targets 'long idle periods,' production shows varied patterns where the difference between 5 minutes vs 30 seconds becomes critical - especially in container environments where exceeding memory limits means process termination, not just performance degradation. > > ## JDK-8213198 Interaction > After reviewing that issue, I see they address **orthogonal problems**: > > **JDK-8213198**: Active application, young GCs happening, needs mixed GCs for string table cleanup > **JDK-8357445**: Idle application, no GCs happening, needs memory uncommit > > **Operational States:** > - String table issue: Active allocation + insufficient mixed GCs > - Time-based uncommit: Complete inactivity + no allocations > > **Complementary Solutions:** > - JDK-8213198: Triggers concurrent cycles when string table grows > - JDK-8357445: Uncommits memory during idle periods > - Future full AHS: Would orchestrate both mechanisms > > The manageable flags become critical in the idle scenario where container memory limits create immediate pressure, unlike the string table scenario where growth can be tolerated for longer periods. > > Would this clarification help with the flag classification decision? > I can see 3 scenarios where runtime adjustment is valuable: > >High-Availability Services > > 24/7 operations cannot restart for tuning adjustments > Cost optimization demands dynamic resource adaptation > Memory pressure events require immediate response Observing and reacting to outside memory pressure events is the purpose of the AHS JEP implementation PR. We should not introduce duplicate functionality and additional shared responsibilities (i.e. between end user and the AHS system) if possible. The end user can always change reactivity via the `*GCIntensity` flags and/or `GCTimeRatio`/`SoftMaxHeapSize`. I do not see a point adding another layer of complexity here. Let's first determine that the existing measures are insufficient before adding new knobs that are very hard to remove. It's easier to make things manageable later. > >Cloud & Container Platforms > > Resource limits change dynamically (auto-scaling) That's covered by the AHS change. > Multi-tenancy requires per-workload optimization > Cost efficiency drives aggressive memory reclaim The AHS change/existing flags should cover that. Use different GCIntensity/GCTimeRatio/SoftMaxHeapSize. > >DevOps & SRE Teams > > Incident response needs immediate memory reclaim Use `jmap` and trigger a (concurrent) full gc. That's much more immediate and responsive. This functionality is not even guaranteed to free anything ever. > Performance testing requires runtime comparison of settings > Capacity planning benefits from live tuning experiments If one only considers this change in isolation this is true. However the plan is to make this work in conjunction with "full" AHS, which has its own knobs. > >"Long Time" Consideration > >While the feature targets 'long idle periods,' production shows varied patterns where the difference between 5 >minutes vs 30 seconds becomes critical - especially in container environments where exceeding memory limits >means process termination, not just performance degradation. AHS will continuously monitor free memory and container limits and adjust gc aggressiveness. One if its measures are uncommitting free regions. >JDK-8213198 Interaction > >After reviewing that issue, I see they address orthogonal problems: > >JDK-8213198: Active application, young GCs happening, needs mixed GCs for string table cleanup >JDK-8357445: Idle application, no GCs happening, needs memory uncommit > >Operational States: > > String table issue: Active allocation + insufficient mixed GCs > Time-based uncommit: Complete inactivity + no allocations They may not be completely related, but the string table issue (and in general non-java heap resources) require some form of garbage collection. Any garbage collection now triggers re-evaluation of heap sizes. So they are equal in the impact (they adjust the heap) - JDK-8213198 subsumes this one in practice. Actually, you will get better results with JDK-8213198 because it can easily happen that the application is idle with very few free regions left. In this case this change will do nothing. Also, for the pure idle case, there is the existing periodic gc functionality. >Complementary Solutions: > > JDK-8213198: Triggers concurrent cycles when string table grows Yeah, I think that CR is defined too tightly for this use case. Together with [JDK-8317755](https://bugs.openjdk.org/browse/JDK-8317755) "G1: Periodic GC interval should test for the last whole heap GC", they show that there is a general problem with resource management on idle or close-to-idle machines. If one takes that second issue into account, it becomes clear that JDK-8213198 should be about fixing letting collectable memory in general hanging around, not just the string table (and clearing the string table requires a GC which resizes the heap; if the machine is idle it will most likely shrink it). Actually the more I think about this change, it becomes more and more attractive to implement JDK-8317755/JDK-8213198 to me as a more well-rounded solution; for costs, we are talking about an extra GC every "long idle time", with presumably much less code complexity (piggybacking on existing periodic gcs), and higher gains in footprint. While this change is interesting because it is a very low-cost way of freeing unused memory, it is insufficient. > JDK-8357445: Uncommits memory during idle periods > Future full AHS: Would orchestrate both mechanisms > >The manageable flags become critical in the idle scenario where container memory limits create immediate >pressure, unlike the string table scenario where growth can be tolerated for longer periods. * This change does not guarantee any shrinking. * AHS will continuously monitor free memory; if that changes by any means (additional allocation, change of container limits), it needs to and will react regardless of idle state or not. Freeing free regions like this is one option it has. > >Would this clarification help with the flag classification decision? The problem is that future full AHS is right around the corner according to the planning, either this or next release, and so adding lots of legacy functionality that takes multiple releases to remove is not something I would like to introduce. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2315496095 From tschatzl at openjdk.org Tue Sep 2 10:19:51 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 2 Sep 2025 10:19:51 GMT Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods [v7] In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 05:53:48 GMT, Monica Beckwith wrote: >> **Implements:** https://bugs.openjdk.org/browse/JDK-8357445 >> >> Implement time-based heap uncommit for G1 during idle periods. >> >> Key changes: >> - Added G1HeapEvaluationTask for periodic heap evaluation >> - Switch from G1ServiceTask to PeriodicTask for improved scheduling >> - Implemented time-based heap sizing policy with configurable uncommit delay >> - Added region activity tracking with last access timestamps >> - Integrated VM_G1ShrinkHeap operation for safe heap shrinking >> - Added new G1 flags: G1UseTimeBasedHeapSizing, G1TimeBasedEvaluationIntervalMillis, G1UncommitDelayMillis, G1MinRegionsToUncommit >> - Added 'sizing' log tag for heap sizing operations >> >> Comprehensive Test Coverage: >> - Enhanced TestG1RegionUncommit: minimum heap boundaries, concurrent allocation/uncommit scenarios >> - Enhanced TestTimeBasedHeapSizing: humongous object handling, rapid allocation cycles, edge cases >> - Enhanced TestTimeBasedRegionTracking: concurrent region access, lifecycle transition validation >> - Enhanced TestTimeBasedHeapConfig: parameter boundary values, small heap configurations >> >> This ensures time-based heap uncommit works correctly while maintaining all safety guarantees and test expectations. > > Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused static _uncommit_delay member and accessor Also, garbage collections and the `VM_G1ShrinkHeap` operation need to reset the timestamp for all (free) regions too. Otherwise the mechanism will try to uncommit the wrong amount of regions, similar to the issue I described in `VM_G1ShrinkHeap`. E.g. Regions A, B, C are free for a long time, GC happens that keeps A, B, C for various reasons, now idle-evaluation happens, and A, B, C are determined idle in addition to the other regions if their timestamp is not reset. So the idle uncommit will free too many regions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26240#issuecomment-3244703382 From tschatzl at openjdk.org Tue Sep 2 10:19:52 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 2 Sep 2025 10:19:52 GMT Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods [v7] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 09:44:25 GMT, Thomas Schatzl wrote: >> src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 550: >> >>> 548: // 1. No more than 25% of inactive regions >>> 549: // 2. No more than 10% of total committed regions >>> 550: // 3. No more than max_shrink_bytes worth of regions >> >> This policy sounds like `Min/MaxHeapFreeRatio` that are known to be not useful. Do not have a better idea right now either. Maybe look at what ZGC did at some point. > > I also do not think this mechanism should ever uncommit the free regions reserved for the current young gen (without GC/recalculating the needed young gen) and potentially the survivor/old regions. There does not seem to be a limit here. > > Otherwise the next GC (or just continuing work) will be riddled with in-pause commits. Or it will probably do a premature GC, I did not check. > > Maybe this change should only madvise these regions as MADV_DONTNEED? (Not sure it does anything though). Also there should potentially be a buffer for humongous object allocation, otherwise they will cause immediate garbage collections. I.e.: err on the conservative side. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2315622132 From iwalulya at openjdk.org Tue Sep 2 10:35:44 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 2 Sep 2025 10:35:44 GMT Subject: RFR: 8365557: Parallel: Refactor ParallelScavengeHeap::mem_allocate_work [v2] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 09:56:27 GMT, Albert Mingkun Yang wrote: >> Extract out multi-thread-safe old-gen allocation API call outside the critical-region to streamline the flow in `mem_allocate_work`. >> >> Test: tier1-3 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into pgc-mem-allocate-refactor > - pgc-mem-allocate-refactor Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26779#pullrequestreview-3175932103 From iwalulya at openjdk.org Tue Sep 2 10:38:43 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 2 Sep 2025 10:38:43 GMT Subject: RFR: 8366063: Parallel: Refactor copy_unmarked_to_survivor_space [v2] In-Reply-To: <5xuytARXePUU3EpnmbVQh0xTCLwkjJsv_oVLtOnIBWw=.57436e14-ca00-4fd1-b216-99f7a65d2f07@github.com> References: <5xuytARXePUU3EpnmbVQh0xTCLwkjJsv_oVLtOnIBWw=.57436e14-ca00-4fd1-b216-99f7a65d2f07@github.com> Message-ID: On Tue, 2 Sep 2025 09:55:59 GMT, Albert Mingkun Yang wrote: >> Extract out young/old generation allocation logic so that the evacuation method flow becomes clear and easier to follow. >> >> Test: tier1-5; perf neutral for specjvm2008, dacapo and some synthetic bms. > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into pgc-young-gc-alloc-refactor > - pgc-young-gc-alloc-refactor Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26922#pullrequestreview-3175951083 From tschatzl at openjdk.org Tue Sep 2 12:49:27 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 2 Sep 2025 12:49:27 GMT Subject: RFR: 8366688: G1: Rename G1HeapRegionRemSet::is_added_to_cset_group() to has_cset_group() Message-ID: Hi all, please review this trivial renaming of `G1HHRS::is_added_to_cset_group` - it's just misnamed, we never add G1HRRS to the cset groups. Testing: gha, local compilation Thanks, Thomas ------------- Commit messages: - * copyright update - 8366688 Changes: https://git.openjdk.org/jdk/pull/27048/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27048&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366688 Stats: 18 lines in 8 files changed: 0 ins; 0 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/27048.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27048/head:pull/27048 PR: https://git.openjdk.org/jdk/pull/27048 From ayang at openjdk.org Tue Sep 2 12:49:54 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 2 Sep 2025 12:49:54 GMT Subject: RFR: 8365557: Parallel: Refactor ParallelScavengeHeap::mem_allocate_work [v2] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 09:56:27 GMT, Albert Mingkun Yang wrote: >> Extract out multi-thread-safe old-gen allocation API call outside the critical-region to streamline the flow in `mem_allocate_work`. >> >> Test: tier1-3 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into pgc-mem-allocate-refactor > - pgc-mem-allocate-refactor Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26779#issuecomment-3245180559 From ayang at openjdk.org Tue Sep 2 12:49:55 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 2 Sep 2025 12:49:55 GMT Subject: Integrated: 8365557: Parallel: Refactor ParallelScavengeHeap::mem_allocate_work In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 14:48:17 GMT, Albert Mingkun Yang wrote: > Extract out multi-thread-safe old-gen allocation API call outside the critical-region to streamline the flow in `mem_allocate_work`. > > Test: tier1-3 This pull request has now been integrated. Changeset: 1feb9bd5 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/1feb9bd55946cad8a37745b0c9ceef16f408afd8 Stats: 47 lines in 2 files changed: 14 ins; 27 del; 6 mod 8365557: Parallel: Refactor ParallelScavengeHeap::mem_allocate_work Reviewed-by: tschatzl, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/26779 From shade at openjdk.org Tue Sep 2 12:57:47 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 2 Sep 2025 12:57:47 GMT Subject: RFR: 8348278: Trim InitialRAMPercentage to improve startup in default modes [v4] In-Reply-To: References: Message-ID: > See bug for discussion. This is the code change, which is simple. What is not simple is deciding what the new value should be. The change would probably require CSR, which I can file after we agree on the value. > > I think cutting to 0.2% of RAM size gets us into good sweet spot: > - On huge 1024G machine, this yields 2G initial heap > - On reasonably sized 128G machine, this gives 256M initial heap > - On smaller 1G container, this gives 2M initial heap > > Additional testing: > - [x] Linux AArch64 server fastdebug, `all` Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Also man page - Fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23262/files - new: https://git.openjdk.org/jdk/pull/23262/files/6a6c3ab8..533514fd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23262&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23262&range=02-03 Stats: 618713 lines in 8034 files changed: 284585 ins; 282059 del; 52069 mod Patch: https://git.openjdk.org/jdk/pull/23262.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23262/head:pull/23262 PR: https://git.openjdk.org/jdk/pull/23262 From ayang at openjdk.org Tue Sep 2 13:08:48 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 2 Sep 2025 13:08:48 GMT Subject: RFR: 8366688: G1: Rename G1HeapRegionRemSet::is_added_to_cset_group() to has_cset_group() In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 12:41:40 GMT, Thomas Schatzl wrote: > Hi all, > > please review this trivial renaming of `G1HHRS::is_added_to_cset_group` - it's just misnamed, we never add G1HRRS to the cset groups. > > Testing: gha, local compilation > > Thanks, > Thomas I can sort of understand why it's named "added_to", because conceptually, the api answers whether the per-region remset belongs to a cset group, instead of a unique one. The name "has_cset_group" is odd, IMO, since it implies ownership, which is wrong. The new name makes more sense on a heap-region -- a region possesses a cset group, shared with other regions potentially. YMMV. ------------- Marked as reviewed by ayang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27048#pullrequestreview-3176481263 From ayang at openjdk.org Tue Sep 2 13:13:49 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 2 Sep 2025 13:13:49 GMT Subject: RFR: 8366063: Parallel: Refactor copy_unmarked_to_survivor_space [v2] In-Reply-To: <5xuytARXePUU3EpnmbVQh0xTCLwkjJsv_oVLtOnIBWw=.57436e14-ca00-4fd1-b216-99f7a65d2f07@github.com> References: <5xuytARXePUU3EpnmbVQh0xTCLwkjJsv_oVLtOnIBWw=.57436e14-ca00-4fd1-b216-99f7a65d2f07@github.com> Message-ID: On Tue, 2 Sep 2025 09:55:59 GMT, Albert Mingkun Yang wrote: >> Extract out young/old generation allocation logic so that the evacuation method flow becomes clear and easier to follow. >> >> Test: tier1-5; perf neutral for specjvm2008, dacapo and some synthetic bms. > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into pgc-young-gc-alloc-refactor > - pgc-young-gc-alloc-refactor Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26922#issuecomment-3245266950 From ayang at openjdk.org Tue Sep 2 13:13:50 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 2 Sep 2025 13:13:50 GMT Subject: Integrated: 8366063: Parallel: Refactor copy_unmarked_to_survivor_space In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 08:52:05 GMT, Albert Mingkun Yang wrote: > Extract out young/old generation allocation logic so that the evacuation method flow becomes clear and easier to follow. > > Test: tier1-5; perf neutral for specjvm2008, dacapo and some synthetic bms. This pull request has now been integrated. Changeset: 71035436 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/710354369e0131e900afc4ced706a9ed0e23ab9c Stats: 149 lines in 2 files changed: 81 ins; 62 del; 6 mod 8366063: Parallel: Refactor copy_unmarked_to_survivor_space Reviewed-by: tschatzl, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/26922 From syan at openjdk.org Tue Sep 2 14:28:56 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 2 Sep 2025 14:28:56 GMT Subject: RFR: 8366692: Several gc/shenandoah tests timed out Message-ID: Hi all, After JDK-8260555 set the default jtreg timeout factor to 1, then several gc/shenandoah tests run timed out with jtreg options -timeoutFactor:1. So I think it's necessary to increase the timeout value set in tests to make test run normally. The actual run time consumed on my linux-x64 machine with 224 CPU core threads shows in [JDK-8366692](https://bugs.openjdk.org/browse/JDK-8366692). Accodring the time statistics, the test test/hotspot/jtreg/gc/shenandoah/TestSieveObjects.java only change the second `@run` at the `@test id=generational` and `@test id=aggressive`, other tests do not need to change. And all the `@run` in test test/hotspot/jtreg/gc/shenandoah/jni/TestJNIGlobalRefs.java changed from 120(default value) to 240. Change has been verified locally on linux-x64, test-fix only, no risk. ------------- Commit messages: - add timeout value for @aggressive - 8366692: Several gc/shenandoah tests timed out Changes: https://git.openjdk.org/jdk/pull/27052/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27052&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366692 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27052.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27052/head:pull/27052 PR: https://git.openjdk.org/jdk/pull/27052 From shade at openjdk.org Tue Sep 2 15:07:43 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 2 Sep 2025 15:07:43 GMT Subject: RFR: 8366692: Several gc/shenandoah tests timed out In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 13:58:46 GMT, SendaoYan wrote: > Hi all, > > After JDK-8260555 set the default jtreg timeout factor to 1, then several gc/shenandoah tests run timed out with jtreg options -timeoutFactor:1. So I think it's necessary to increase the timeout value set in tests to make test run normally. > > The actual run time consumed on my linux-x64 machine with 224 CPU core threads shows in [JDK-8366692](https://bugs.openjdk.org/browse/JDK-8366692). > > Accodring the time statistics, the test test/hotspot/jtreg/gc/shenandoah/TestSieveObjects.java only change the second `@run` at the `@test id=generational` and `@test id=aggressive`, other tests do not need to change. And all the `@run` in test test/hotspot/jtreg/gc/shenandoah/jni/TestJNIGlobalRefs.java changed from 120(default value) to 240. > > Change has been verified locally on linux-x64, test-fix only, no risk. Yeah, it makes sense that tests under verifier are slow. The fix looks fine. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27052#pullrequestreview-3176982444 From tschatzl at openjdk.org Tue Sep 2 15:25:43 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 2 Sep 2025 15:25:43 GMT Subject: RFR: 8366688: G1: Rename G1HeapRegionRemSet::is_added_to_cset_group() to has_cset_group() In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 13:06:15 GMT, Albert Mingkun Yang wrote: > I can sort of understand why it's named "added_to", because conceptually, the api answers whether the per-region remset belongs to a cset group, instead of a unique one. I think there is some confusion about the naming of cset groups. Cset groups are nothing but a card set covering the cards of a set of regions. Previously the card set has been part of the HRRS ("all the information to evacuate a region", i.e. the region's remset), the change has been that the card set part of the HRRS is shared. [Unfortunately it would be a bit awkward to have the HRRS itself be shared across regions right now - the problem is the code root set. If g1 shared the code root set, and drop the HRRS, then g1 could never evacuate that region any more as we never rebuild that one. Could be added though.] > > The name "has_cset_group" is odd, IMO, since it implies ownership, which is wrong. The new name makes more sense on a heap-region -- a region possesses a cset group, shared with other regions potentially. > I see your point - what if the cset group would be called something like "cardset group" (I have no good name, maybe shared-cardset, but otoh it also contains some information related to evacuation like gc-efficiency of the group of regions, so it is related to collection set candidates), would that make understanding the reason for this name? Then it makes sense that one can ask the question whether the heap region's remset (the hrrs) "has" a card based remembered set (attached). Maybe there is a better term here, like the suggested `has_cset_group_attached/assigned()` or so? I think the shorthand suggested in this PR is acceptable. What do you think? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27048#issuecomment-3245803826 From iwalulya at openjdk.org Tue Sep 2 17:29:41 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 2 Sep 2025 17:29:41 GMT Subject: RFR: 8366688: G1: Rename G1HeapRegionRemSet::is_added_to_cset_group() to has_cset_group() In-Reply-To: References: Message-ID: <4rjPtppuZp2ZTPA99VUBtbhJZGxWAJAMLL91f0IBERA=.91acb0ec-4564-4a13-b207-457f5c279bdf@github.com> On Tue, 2 Sep 2025 12:41:40 GMT, Thomas Schatzl wrote: > Hi all, > > please review this trivial renaming of `G1HHRS::is_added_to_cset_group` - it's just misnamed, we never add G1HRRS to the cset groups. > > Testing: gha, local compilation > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27048#pullrequestreview-3177507404 From wkemper at openjdk.org Tue Sep 2 18:23:44 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 2 Sep 2025 18:23:44 GMT Subject: RFR: 8366692: Several gc/shenandoah tests timed out In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 13:58:46 GMT, SendaoYan wrote: > Hi all, > > After JDK-8260555 set the default jtreg timeout factor to 1, then several gc/shenandoah tests run timed out with jtreg options -timeoutFactor:1. So I think it's necessary to increase the timeout value set in tests to make test run normally. > > The actual run time consumed on my linux-x64 machine with 224 CPU core threads shows in [JDK-8366692](https://bugs.openjdk.org/browse/JDK-8366692). > > Accodring the time statistics, the test test/hotspot/jtreg/gc/shenandoah/TestSieveObjects.java only change the second `@run` at the `@test id=generational` and `@test id=aggressive`, other tests do not need to change. And all the `@run` in test test/hotspot/jtreg/gc/shenandoah/jni/TestJNIGlobalRefs.java changed from 120(default value) to 240. > > Change has been verified locally on linux-x64, test-fix only, no risk. Seems there is some unrelated build breakage. Can we merge from `master` again before integrating? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27052#issuecomment-3246356701 From kdnilsen at openjdk.org Tue Sep 2 18:38:49 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 2 Sep 2025 18:38:49 GMT Subject: RFR: 8342640: GenShen: Silently ignoring ShenandoahGCHeuristics considered poor user-experience [v2] In-Reply-To: <-G7AGJRPOYIhjHRPhx8fyuinCe-nLXZfbZO3Sz5Y7iM=.0b6d63d6-24e6-4618-9fa0-106dde9fa2f7@github.com> References: <-G7AGJRPOYIhjHRPhx8fyuinCe-nLXZfbZO3Sz5Y7iM=.0b6d63d6-24e6-4618-9fa0-106dde9fa2f7@github.com> Message-ID: <-mwUFNkv8imkFbHfvj9GQyXWFiGg1oZ9aIKUPFV3ZXA=.bf85a1f5-2d69-415f-8b00-c9f189c53a5c@github.com> On Wed, 27 Aug 2025 22:47:58 GMT, Rui Li wrote: >> When generational shenandoah is enabled, it ignores the value of ShenandoahGCHeuristics input silently: >> >> java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:ShenandoahGCHeuristics=junk -version >> openjdk version "25" 2025-09-16 LTS >> OpenJDK Runtime Environment Corretto-25.0.0.36.1 (build 25+36-LTS) >> OpenJDK 64-Bit Server VM Corretto-25.0.0.36.1 (build 25+36-LTS, mixed mode, sharing) >> >> >> Adding additional guard rail to gen shen is not an option - it is actually by design that gen shen does not support non adaptive heuristics due to the complexity brought by generational design. >> >> So print out a warning to users to indicate that their `ShenandoahGCHeuristics` input is ignored. >> >> >> x64 (8342640) % java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:ShenandoahGCHeuristics=static -version >> [0.001s][warning][gc] Ignoring -XX:ShenandoahGCHeuristics input: static, because generational shenandoah only supports adaptive heuristics >> openjdk version "26" 2026-03-17 >> OpenJDK Runtime Environment Corretto-26.0.2.1.1 (slowdebug build 26+2-FR) >> OpenJDK 64-Bit Server VM Corretto-26.0.2.1.1 (slowdebug build 26+2-FR, mixed mode) >> >> x64 (8342640) % java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:ShenandoahGCHeuristics=junk -version >> [0.001s][warning][gc] Ignoring -XX:ShenandoahGCHeuristics input: junk, because generational shenandoah only supports adaptive heuristics >> openjdk version "26" 2026-03-17 >> OpenJDK Runtime Environment Corretto-26.0.2.1.1 (slowdebug build 26+2-FR) >> OpenJDK 64-Bit Server VM Corretto-26.0.2.1.1 (slowdebug build 26+2-FR, mixed mode) >> >> x64 (8342640) % java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:ShenandoahGCHeuristics=adaptive -version >> openjdk version "26" 2026-03-17 >> OpenJDK Runtime Environment Corretto-26.0.2.1.1 (slowdebug build 26+2-FR) >> OpenJDK 64-Bit Server VM Corretto-26.0.2.1.1 (slowdebug build 26+2-FR, mixed mode) >> >> x64 (8342640) % java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -version >> openjdk version "26" 2026-03-17 >> OpenJDK Runtime Environment Corretto-26.0.2.1.1 (slowdebug build 26+2-FR) >> OpenJDK 64-Bit Server VM Corretto-26.0.2.1.1 (slowdebug build 26+2-FR, mixed mode) > > Rui Li has updated the pull request incrementally with one additional commit since the last revision: > > Update Thanks for this fix. ------------- PR Review: https://git.openjdk.org/jdk/pull/26968#pullrequestreview-3177697913 From duke at openjdk.org Tue Sep 2 21:06:59 2025 From: duke at openjdk.org (jonghoonpark) Date: Tue, 2 Sep 2025 21:06:59 GMT Subject: RFR: 8364927: Add @requires annotation to TestReclaimStringsLeaksMemory.java Message-ID: <4aT8v-HYcfSoxEEDZZWhw2JjNXxvE1WUDDsYgV7n0I8=.1aef56d4-5a50-4be3-90bf-d57e5a54118b@github.com> This change updates `TestReclaimStringsLeaksMemory.java` to properly guard against unsupported GC arguments. Previously, the test only checked `@requires vm.gc == "null"`. The fix separates the tests and adds explicit `@requires` clauses for each GC configuration to ensure the test only runs when supported. This prevents test failures on VMs that do not support the specified GC. (This is my first contribution to the JDK. Thank you for your review and guidance.) ------------- Commit messages: - 8364927: Add @requires annotation to TestReclaimStringsLeaksMemory.java Changes: https://git.openjdk.org/jdk/pull/26766/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26766&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364927 Stats: 30 lines in 1 file changed: 30 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26766.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26766/head:pull/26766 PR: https://git.openjdk.org/jdk/pull/26766 From duke at openjdk.org Tue Sep 2 21:06:59 2025 From: duke at openjdk.org (jonghoonpark) Date: Tue, 2 Sep 2025 21:06:59 GMT Subject: RFR: 8364927: Add @requires annotation to TestReclaimStringsLeaksMemory.java In-Reply-To: <4aT8v-HYcfSoxEEDZZWhw2JjNXxvE1WUDDsYgV7n0I8=.1aef56d4-5a50-4be3-90bf-d57e5a54118b@github.com> References: <4aT8v-HYcfSoxEEDZZWhw2JjNXxvE1WUDDsYgV7n0I8=.1aef56d4-5a50-4be3-90bf-d57e5a54118b@github.com> Message-ID: On Wed, 13 Aug 2025 19:11:25 GMT, jonghoonpark wrote: > This change updates `TestReclaimStringsLeaksMemory.java` to properly guard against unsupported GC arguments. > Previously, the test only checked `@requires vm.gc == "null"`. > > The fix separates the tests and adds explicit `@requires` clauses for each GC configuration to ensure the test only runs when supported. > > This prevents test failures on VMs that do not support the specified GC. > > (This is my first contribution to the JDK. Thank you for your review and guidance.) image I previously signed the OCA and have already contributed to Graal. However, the GitHub Actions checks are not passing. Is there anything else I need to do? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26766#issuecomment-3185242360 From duke at openjdk.org Tue Sep 2 21:57:17 2025 From: duke at openjdk.org (jonghoonpark) Date: Tue, 2 Sep 2025 21:57:17 GMT Subject: RFR: 8364927: Add @requires annotation to TestReclaimStringsLeaksMemory.java [v2] In-Reply-To: <4aT8v-HYcfSoxEEDZZWhw2JjNXxvE1WUDDsYgV7n0I8=.1aef56d4-5a50-4be3-90bf-d57e5a54118b@github.com> References: <4aT8v-HYcfSoxEEDZZWhw2JjNXxvE1WUDDsYgV7n0I8=.1aef56d4-5a50-4be3-90bf-d57e5a54118b@github.com> Message-ID: > This change updates `TestReclaimStringsLeaksMemory.java` to properly guard against unsupported GC arguments. > Previously, the test only checked `@requires vm.gc == "null"`. > > The fix separates the tests and adds explicit `@requires` clauses for each GC configuration to ensure the test only runs when supported. > > This prevents test failures on VMs that do not support the specified GC. > > (This is my first contribution to the JDK. Thank you for your review and guidance.) jonghoonpark has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8364927-add-requires-annotation - 8364927: Add @requires annotation to TestReclaimStringsLeaksMemory.java Signed-off-by: jonghoonpark ------------- Changes: https://git.openjdk.org/jdk/pull/26766/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26766&range=01 Stats: 30 lines in 1 file changed: 30 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26766.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26766/head:pull/26766 PR: https://git.openjdk.org/jdk/pull/26766 From syan at openjdk.org Wed Sep 3 01:00:49 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 3 Sep 2025 01:00:49 GMT Subject: RFR: 8366476: Test gc/z/TestSmallHeap.java fails OOM with many NUMA nodes [v2] In-Reply-To: <_4D9FGVauawm9ig78lVwLu3sqtBNZxtY9cxc06sZ0S8=.29aa3ef2-6e65-482e-b252-443cff3ac09a@github.com> References: <8LyuPbOOA31cjSx6aajC62-hTnyxlWvn7xqf4pVr9Ok=.8108a15a-70d2-4d54-a1ed-a472bc406466@github.com> <_4D9FGVauawm9ig78lVwLu3sqtBNZxtY9cxc06sZ0S8=.29aa3ef2-6e65-482e-b252-443cff3ac09a@github.com> Message-ID: On Tue, 2 Sep 2025 08:03:49 GMT, Axel Boldt-Christmas wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> update comment "Disable NUMA to avoid potential OOM after JDK-8359683" > > lgtm. Thanks for the reviews @xmas92 @jsikstro ------------- PR Comment: https://git.openjdk.org/jdk/pull/27019#issuecomment-3247287918 From syan at openjdk.org Wed Sep 3 01:00:50 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 3 Sep 2025 01:00:50 GMT Subject: Integrated: 8366476: Test gc/z/TestSmallHeap.java fails OOM with many NUMA nodes In-Reply-To: <8LyuPbOOA31cjSx6aajC62-hTnyxlWvn7xqf4pVr9Ok=.8108a15a-70d2-4d54-a1ed-a472bc406466@github.com> References: <8LyuPbOOA31cjSx6aajC62-hTnyxlWvn7xqf4pVr9Ok=.8108a15a-70d2-4d54-a1ed-a472bc406466@github.com> Message-ID: On Sat, 30 Aug 2025 05:47:46 GMT, SendaoYan wrote: > Hi all, > > The PR [JDK-8359683](https://bugs.openjdk.org/browse/JDK-8359683) added NUMA-Aware Relocation for ZGC, it's optimized for the majority of NUMA workloads, but the cost is requiring more headroom in terms of heap memory. This PR add extra JVM option "-XX:-UseNUMA" to make this test run normally. > > Test-fix only, change has been verified locally, no risk. This pull request has now been integrated. Changeset: e268563a Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/e268563a10b67bdcb3c030743ed3e2b3b7dfd0f7 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8366476: Test gc/z/TestSmallHeap.java fails OOM with many NUMA nodes Reviewed-by: jsikstro, aboldtch ------------- PR: https://git.openjdk.org/jdk/pull/27019 From syan at openjdk.org Wed Sep 3 02:00:24 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 3 Sep 2025 02:00:24 GMT Subject: RFR: 8366692: Several gc/shenandoah tests timed out [v2] In-Reply-To: References: Message-ID: > Hi all, > > After JDK-8260555 set the default jtreg timeout factor to 1, then several gc/shenandoah tests run timed out with jtreg options -timeoutFactor:1. So I think it's necessary to increase the timeout value set in tests to make test run normally. > > The actual run time consumed on my linux-x64 machine with 224 CPU core threads shows in [JDK-8366692](https://bugs.openjdk.org/browse/JDK-8366692). > > Accodring the time statistics, the test test/hotspot/jtreg/gc/shenandoah/TestSieveObjects.java only change the second `@run` at the `@test id=generational` and `@test id=aggressive`, other tests do not need to change. And all the `@run` in test test/hotspot/jtreg/gc/shenandoah/jni/TestJNIGlobalRefs.java changed from 120(default value) to 240. > > Change has been verified locally on linux-x64, test-fix only, no risk. SendaoYan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'openjdk:master' into jbs8366692 - add timeout value for @aggressive - 8366692: Several gc/shenandoah tests timed out ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27052/files - new: https://git.openjdk.org/jdk/pull/27052/files/4d8a9601..c5e3ab20 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27052&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27052&range=00-01 Stats: 831 lines in 41 files changed: 270 ins; 348 del; 213 mod Patch: https://git.openjdk.org/jdk/pull/27052.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27052/head:pull/27052 PR: https://git.openjdk.org/jdk/pull/27052 From syan at openjdk.org Wed Sep 3 02:00:24 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 3 Sep 2025 02:00:24 GMT Subject: RFR: 8366692: Several gc/shenandoah tests timed out In-Reply-To: References: Message-ID: <673cwRRzBoBr9kRvan06XxfDt7HivhqtS8JbpLILKIU=.94b525a1-be3a-4ade-852a-8e0ccae787bb@github.com> On Tue, 2 Sep 2025 18:21:14 GMT, William Kemper wrote: > Seems there is some unrelated build breakage. Can we merge from `master` again before integrating? I noticed the build breakage also. I have merge from master just now. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27052#issuecomment-3247419008 From syan at openjdk.org Wed Sep 3 03:59:46 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 3 Sep 2025 03:59:46 GMT Subject: RFR: 8366692: Several gc/shenandoah tests timed out [v2] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 02:00:24 GMT, SendaoYan wrote: >> Hi all, >> >> After JDK-8260555 set the default jtreg timeout factor to 1, then several gc/shenandoah tests run timed out with jtreg options -timeoutFactor:1. So I think it's necessary to increase the timeout value set in tests to make test run normally. >> >> The actual run time consumed on my linux-x64 machine with 224 CPU core threads shows in [JDK-8366692](https://bugs.openjdk.org/browse/JDK-8366692). >> >> Accodring the time statistics, the test test/hotspot/jtreg/gc/shenandoah/TestSieveObjects.java only change the second `@run` at the `@test id=generational` and `@test id=aggressive`, other tests do not need to change. And all the `@run` in test test/hotspot/jtreg/gc/shenandoah/jni/TestJNIGlobalRefs.java changed from 120(default value) to 240. >> >> Change has been verified locally on linux-x64, test-fix only, no risk. > > SendaoYan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'openjdk:master' into jbs8366692 > - add timeout value for @aggressive > - 8366692: Several gc/shenandoah tests timed out Sorry, I missed the another timed out test gc/shenandoah/TestAllocObjects.java#aggressive. The time statistics show that the first two '@run' consume time about 145.316 and 260.58. So I think we should change the timed out value to 240 and 480. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27052#issuecomment-3247600638 From syan at openjdk.org Wed Sep 3 04:47:18 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 3 Sep 2025 04:47:18 GMT Subject: RFR: 8366692: Several gc/shenandoah tests timed out [v3] In-Reply-To: References: Message-ID: > Hi all, > > After JDK-8260555 set the default jtreg timeout factor to 1, then several gc/shenandoah tests run timed out with jtreg options -timeoutFactor:1. So I think it's necessary to increase the timeout value set in tests to make test run normally. > > The actual run time consumed on my linux-x64 machine with 224 CPU core threads shows in [JDK-8366692](https://bugs.openjdk.org/browse/JDK-8366692). > > Accodring the time statistics, the test test/hotspot/jtreg/gc/shenandoah/TestSieveObjects.java only change the second `@run` at the `@test id=generational` and `@test id=aggressive`, other tests do not need to change. And all the `@run` in test test/hotspot/jtreg/gc/shenandoah/jni/TestJNIGlobalRefs.java changed from 120(default value) to 240. > > Change has been verified locally on linux-x64, test-fix only, no risk. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Update gc/shenandoah/TestAllocObjects.java#aggressive ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27052/files - new: https://git.openjdk.org/jdk/pull/27052/files/c5e3ab20..8b193acb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27052&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27052&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27052.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27052/head:pull/27052 PR: https://git.openjdk.org/jdk/pull/27052 From shade at openjdk.org Wed Sep 3 04:47:18 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 3 Sep 2025 04:47:18 GMT Subject: RFR: 8366692: Several gc/shenandoah tests timed out [v3] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 04:43:57 GMT, SendaoYan wrote: >> Hi all, >> >> After JDK-8260555 set the default jtreg timeout factor to 1, then several gc/shenandoah tests run timed out with jtreg options -timeoutFactor:1. So I think it's necessary to increase the timeout value set in tests to make test run normally. >> >> The actual run time consumed on my linux-x64 machine with 224 CPU core threads shows in [JDK-8366692](https://bugs.openjdk.org/browse/JDK-8366692). >> >> Accodring the time statistics, the test test/hotspot/jtreg/gc/shenandoah/TestSieveObjects.java only change the second `@run` at the `@test id=generational` and `@test id=aggressive`, other tests do not need to change. And all the `@run` in test test/hotspot/jtreg/gc/shenandoah/jni/TestJNIGlobalRefs.java changed from 120(default value) to 240. >> >> Change has been verified locally on linux-x64, test-fix only, no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Update gc/shenandoah/TestAllocObjects.java#aggressive Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27052#pullrequestreview-3178926540 From tschatzl at openjdk.org Wed Sep 3 06:52:47 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 3 Sep 2025 06:52:47 GMT Subject: RFR: 8364927: Add @requires annotation to TestReclaimStringsLeaksMemory.java [v2] In-Reply-To: References: <4aT8v-HYcfSoxEEDZZWhw2JjNXxvE1WUDDsYgV7n0I8=.1aef56d4-5a50-4be3-90bf-d57e5a54118b@github.com> Message-ID: <_K-oP4afua1RqDRKU-oZclLyCXT-QMSDw3RQa9KPyp0=.e8ca1763-e440-47b0-9b41-24def97b0e7e@github.com> On Tue, 2 Sep 2025 21:57:17 GMT, jonghoonpark wrote: >> This change updates `TestReclaimStringsLeaksMemory.java` to properly guard against unsupported GC arguments. >> Previously, the test only checked `@requires vm.gc == "null"`. >> >> The fix separates the tests and adds explicit `@requires` clauses for each GC configuration to ensure the test only runs when supported. >> >> This prevents test failures on VMs that do not support the specified GC. >> >> (This is my first contribution to the JDK. Thank you for your review and guidance.) > > jonghoonpark has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8364927-add-requires-annotation > - 8364927: Add @requires annotation to TestReclaimStringsLeaksMemory.java > > Signed-off-by: jonghoonpark Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26766#pullrequestreview-3179179616 From tschatzl at openjdk.org Wed Sep 3 06:56:42 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 3 Sep 2025 06:56:42 GMT Subject: RFR: 8366543: Clean up include headers in numberSeq [v2] In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 13:04:28 GMT, Albert Mingkun Yang wrote: >> Trivial changing to use the correct includes in `numberSeq.hpp/cpp`. >> >> Test: tier1 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27031#pullrequestreview-3179188816 From stefank at openjdk.org Wed Sep 3 07:12:45 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 3 Sep 2025 07:12:45 GMT Subject: RFR: 8364927: Add @requires annotation to TestReclaimStringsLeaksMemory.java [v2] In-Reply-To: References: <4aT8v-HYcfSoxEEDZZWhw2JjNXxvE1WUDDsYgV7n0I8=.1aef56d4-5a50-4be3-90bf-d57e5a54118b@github.com> Message-ID: On Tue, 2 Sep 2025 21:57:17 GMT, jonghoonpark wrote: >> This change updates `TestReclaimStringsLeaksMemory.java` to properly guard against unsupported GC arguments. >> Previously, the test only checked `@requires vm.gc == "null"`. >> >> The fix separates the tests and adds explicit `@requires` clauses for each GC configuration to ensure the test only runs when supported. >> >> This prevents test failures on VMs that do not support the specified GC. >> >> (This is my first contribution to the JDK. Thank you for your review and guidance.) > > jonghoonpark has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8364927-add-requires-annotation > - 8364927: Add @requires annotation to TestReclaimStringsLeaksMemory.java > > Signed-off-by: jonghoonpark test/hotspot/jtreg/gc/stress/TestReclaimStringsLeaksMemory.java line 38: > 36: > 37: /* > 38: * @test TestReclaimStringsLeaksMemorySerial In other tests we set the id instead. For example, in the TestSystemGC we have: * @test id=Serial Maybe do the same for this test? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26766#discussion_r2317984317 From ayang at openjdk.org Wed Sep 3 07:55:52 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 3 Sep 2025 07:55:52 GMT Subject: RFR: 8366543: Clean up include headers in numberSeq [v2] In-Reply-To: References: Message-ID: <1D_0HGdh1du8xqdE2lnxTEvyhDylLDliOhYx0sadudA=.562bbcc4-df36-4666-8f07-49978d95ff5d@github.com> On Mon, 1 Sep 2025 13:04:28 GMT, Albert Mingkun Yang wrote: >> Trivial changing to use the correct includes in `numberSeq.hpp/cpp`. >> >> Test: tier1 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27031#issuecomment-3248097128 From ayang at openjdk.org Wed Sep 3 07:55:53 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 3 Sep 2025 07:55:53 GMT Subject: Integrated: 8366543: Clean up include headers in numberSeq In-Reply-To: References: Message-ID: <4qg5wD0nd2S7hthCzdPyaHgxEuKu0Ij4Xf8db2_BqlM=.51e09862-224e-42ce-bd04-781fa7352105@github.com> On Mon, 1 Sep 2025 11:18:06 GMT, Albert Mingkun Yang wrote: > Trivial changing to use the correct includes in `numberSeq.hpp/cpp`. > > Test: tier1 This pull request has now been integrated. Changeset: 6dda2f6f Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/6dda2f6fad5cae95057fbdfa672e3b51aff61af7 Stats: 2 lines in 2 files changed: 1 ins; 1 del; 0 mod 8366543: Clean up include headers in numberSeq Reviewed-by: tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/27031 From duke at openjdk.org Wed Sep 3 08:02:46 2025 From: duke at openjdk.org (jonghoonpark) Date: Wed, 3 Sep 2025 08:02:46 GMT Subject: RFR: 8364927: Add @requires annotation to TestReclaimStringsLeaksMemory.java [v2] In-Reply-To: References: <4aT8v-HYcfSoxEEDZZWhw2JjNXxvE1WUDDsYgV7n0I8=.1aef56d4-5a50-4be3-90bf-d57e5a54118b@github.com> Message-ID: <-Tb2UUwG8l2tuLi9Zg9QgzgGVWlNBeDRBi-CXqzUF50=.cbe0b71c-56ae-4195-95b2-95951364e9d9@github.com> On Wed, 3 Sep 2025 07:09:36 GMT, Stefan Karlsson wrote: >> jonghoonpark has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: >> >> - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8364927-add-requires-annotation >> - 8364927: Add @requires annotation to TestReclaimStringsLeaksMemory.java >> >> Signed-off-by: jonghoonpark > > test/hotspot/jtreg/gc/stress/TestReclaimStringsLeaksMemory.java line 38: > >> 36: >> 37: /* >> 38: * @test TestReclaimStringsLeaksMemorySerial > > In other tests we set the id instead. For example, in the TestSystemGC we have: > > * @test id=Serial > > > Maybe do the same for this test? Thank you for your feedback. Then, would modifying the code as shown below be acceptable? /* * @test TestReclaimStringsLeaksMemory * ... * @run driver/timeout=480 gc.stress.TestReclaimStringsLeaksMemory */ /* * @test id=Serial * ... * @run driver/timeout=480 gc.stress.TestReclaimStringsLeaksMemory -XX:+UseSerialGC */ /* * @test id=Parallel * ... * @run driver/timeout=480 gc.stress.TestReclaimStringsLeaksMemory -XX:+UseParallelGC */ /* * @test id=G1 * ... * @run driver/timeout=480 gc.stress.TestReclaimStringsLeaksMemory -XX:+UseG1GC */ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26766#discussion_r2318120781 From stefank at openjdk.org Wed Sep 3 09:50:44 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 3 Sep 2025 09:50:44 GMT Subject: RFR: 8364927: Add @requires annotation to TestReclaimStringsLeaksMemory.java [v2] In-Reply-To: <-Tb2UUwG8l2tuLi9Zg9QgzgGVWlNBeDRBi-CXqzUF50=.cbe0b71c-56ae-4195-95b2-95951364e9d9@github.com> References: <4aT8v-HYcfSoxEEDZZWhw2JjNXxvE1WUDDsYgV7n0I8=.1aef56d4-5a50-4be3-90bf-d57e5a54118b@github.com> <-Tb2UUwG8l2tuLi9Zg9QgzgGVWlNBeDRBi-CXqzUF50=.cbe0b71c-56ae-4195-95b2-95951364e9d9@github.com> Message-ID: On Wed, 3 Sep 2025 08:00:06 GMT, jonghoonpark wrote: >> test/hotspot/jtreg/gc/stress/TestReclaimStringsLeaksMemory.java line 38: >> >>> 36: >>> 37: /* >>> 38: * @test TestReclaimStringsLeaksMemorySerial >> >> In other tests we set the id instead. For example, in the TestSystemGC we have: >> >> * @test id=Serial >> >> >> Maybe do the same for this test? > > Thank you for your feedback. > > Then, would modifying the code as shown below be acceptable? > > > /* > * @test TestReclaimStringsLeaksMemory > * ... > * @run driver/timeout=480 gc.stress.TestReclaimStringsLeaksMemory > */ > > /* > * @test id=Serial > * ... > * @run driver/timeout=480 gc.stress.TestReclaimStringsLeaksMemory -XX:+UseSerialGC > */ > > /* > * @test id=Parallel > * ... > * @run driver/timeout=480 gc.stress.TestReclaimStringsLeaksMemory -XX:+UseParallelGC > */ > > /* > * @test id=G1 > * ... > * @run driver/timeout=480 gc.stress.TestReclaimStringsLeaksMemory -XX:+UseG1GC > */ Do you really need the first one? It will cause us to run G1 twice. If you really need it I would prefer if you used id= and gave it a proper id. Otherwise the run will just say TestReclaimStringsLeaksMemory#id0 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26766#discussion_r2318419744 From ayang at openjdk.org Wed Sep 3 10:05:19 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 3 Sep 2025 10:05:19 GMT Subject: RFR: 8366781: Parallel: Include OS free memory in GC selection heuristics Message-ID: Add a new condition checking if OS has enough free memory to commit/expand old-gen, which determines whether the upcoming GC should be young or full. Test: tier1-3 ------------- Commit messages: - pgc-os-free-mem Changes: https://git.openjdk.org/jdk/pull/27068/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27068&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366781 Stats: 31 lines in 1 file changed: 20 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/27068.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27068/head:pull/27068 PR: https://git.openjdk.org/jdk/pull/27068 From shade at openjdk.org Wed Sep 3 10:08:49 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 3 Sep 2025 10:08:49 GMT Subject: RFR: 8348278: Trim InitialRAMPercentage to improve startup in default modes [v4] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 12:57:47 GMT, Aleksey Shipilev wrote: >> See bug for discussion. This is the code change, which is simple. What is not simple is deciding what the new value should be. The change would probably require CSR, which I can file after we agree on the value. >> >> I think cutting to 0.2% of RAM size gets us into good sweet spot: >> - On huge 1024G machine, this yields 2G initial heap >> - On reasonably sized 128G machine, this gives 256M initial heap >> - On smaller 1G container, this gives 2M initial heap >> >> Additional testing: >> - [x] Linux AArch64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Also man page > - Fix CSR is approved. This now need reviews. Please take a look! @fisk -- pinging you, since you reviewed the CSR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23262#issuecomment-3248583741 From duke at openjdk.org Wed Sep 3 11:28:46 2025 From: duke at openjdk.org (jonghoonpark) Date: Wed, 3 Sep 2025 11:28:46 GMT Subject: RFR: 8364927: Add @requires annotation to TestReclaimStringsLeaksMemory.java [v2] In-Reply-To: References: <4aT8v-HYcfSoxEEDZZWhw2JjNXxvE1WUDDsYgV7n0I8=.1aef56d4-5a50-4be3-90bf-d57e5a54118b@github.com> <-Tb2UUwG8l2tuLi9Zg9QgzgGVWlNBeDRBi-CXqzUF50=.cbe0b71c-56ae-4195-95b2-95951364e9d9@github.com> Message-ID: On Wed, 3 Sep 2025 09:47:51 GMT, Stefan Karlsson wrote: >> Thank you for your feedback. >> >> Then, would modifying the code as shown below be acceptable? >> >> >> /* >> * @test TestReclaimStringsLeaksMemory >> * ... >> * @run driver/timeout=480 gc.stress.TestReclaimStringsLeaksMemory >> */ >> >> /* >> * @test id=Serial >> * ... >> * @run driver/timeout=480 gc.stress.TestReclaimStringsLeaksMemory -XX:+UseSerialGC >> */ >> >> /* >> * @test id=Parallel >> * ... >> * @run driver/timeout=480 gc.stress.TestReclaimStringsLeaksMemory -XX:+UseParallelGC >> */ >> >> /* >> * @test id=G1 >> * ... >> * @run driver/timeout=480 gc.stress.TestReclaimStringsLeaksMemory -XX:+UseG1GC >> */ > > Do you really need the first one? It will cause us to run G1 twice. If you really need it I would prefer if you used id= and gave it a proper id. Otherwise the run will just say TestReclaimStringsLeaksMemory#id0 I included that part because it was already present in the original code. I thought it was there to test the case where a GC other than SerialGC, ParallelGC, or G1GC might be used as the default. However, after reviewing your feedback, I realized that the other tests clearly focus only on the specific GCs that are actually required. Then, would it be better to remove the first test and add tests for other GCs later only if they turn out to be necessary? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26766#discussion_r2318666522 From stefank at openjdk.org Wed Sep 3 11:51:42 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 3 Sep 2025 11:51:42 GMT Subject: RFR: 8364927: Add @requires annotation to TestReclaimStringsLeaksMemory.java [v2] In-Reply-To: References: <4aT8v-HYcfSoxEEDZZWhw2JjNXxvE1WUDDsYgV7n0I8=.1aef56d4-5a50-4be3-90bf-d57e5a54118b@github.com> <-Tb2UUwG8l2tuLi9Zg9QgzgGVWlNBeDRBi-CXqzUF50=.cbe0b71c-56ae-4195-95b2-95951364e9d9@github.com> Message-ID: On Wed, 3 Sep 2025 11:26:23 GMT, jonghoonpark wrote: >I thought it was there to test the case where a GC other than SerialGC, ParallelGC, or G1GC might be used as the default. That could be the case. However, I think that most of our tests don't care about that and instead follow the pattern in TestSystemGC.java > Then, would it be better to remove the first test and add tests for other GCs later only if they turn out to be necessary? I think so. Do you know if ZGC and Shenandoah works with this test? If they do you could also consider adding them. Though that requires you to verify that they actually do pass the test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26766#discussion_r2318715650 From duke at openjdk.org Wed Sep 3 13:24:43 2025 From: duke at openjdk.org (jonghoonpark) Date: Wed, 3 Sep 2025 13:24:43 GMT Subject: RFR: 8364927: Add @requires annotation to TestReclaimStringsLeaksMemory.java [v2] In-Reply-To: References: <4aT8v-HYcfSoxEEDZZWhw2JjNXxvE1WUDDsYgV7n0I8=.1aef56d4-5a50-4be3-90bf-d57e5a54118b@github.com> <-Tb2UUwG8l2tuLi9Zg9QgzgGVWlNBeDRBi-CXqzUF50=.cbe0b71c-56ae-4195-95b2-95951364e9d9@github.com> Message-ID: <65bw-qHodMosRcuZ99DeohHY_5k-5KI5apf12mqjMlI=.5e4e9c1e-c8e5-4263-8d45-b633a1670d7d@github.com> On Wed, 3 Sep 2025 11:48:46 GMT, Stefan Karlsson wrote: >> I included that part because it was already present in the original code. >> I thought it was there to test the case where a GC other than SerialGC, ParallelGC, or G1GC might be used as the default. >> >> However, after reviewing your feedback, I realized that the other tests clearly focus only on the specific GCs that are actually required. >> >> Then, would it be better to remove the first test and add tests for other GCs later only if they turn out to be necessary? > >>I thought it was there to test the case where a GC other than SerialGC, ParallelGC, or G1GC might be used as the default. > > That could be the case. However, I think that most of our tests don't care about that and instead follow the pattern in TestSystemGC.java > >> Then, would it be better to remove the first test and add tests for other GCs later only if they turn out to be necessary? > > I think so. > > Do you know if ZGC and Shenandoah works with this test? If they do you could also consider adding them. Though that requires you to verify that they actually do pass the test. I have confirmed that both ZGC and Shenandoah GC pass the test. Then I?ll update the PR by removing the first test item and including them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26766#discussion_r2318961928 From duke at openjdk.org Wed Sep 3 13:35:40 2025 From: duke at openjdk.org (jonghoonpark) Date: Wed, 3 Sep 2025 13:35:40 GMT Subject: RFR: 8364927: Add @requires annotation to TestReclaimStringsLeaksMemory.java [v3] In-Reply-To: <4aT8v-HYcfSoxEEDZZWhw2JjNXxvE1WUDDsYgV7n0I8=.1aef56d4-5a50-4be3-90bf-d57e5a54118b@github.com> References: <4aT8v-HYcfSoxEEDZZWhw2JjNXxvE1WUDDsYgV7n0I8=.1aef56d4-5a50-4be3-90bf-d57e5a54118b@github.com> Message-ID: > This change updates `TestReclaimStringsLeaksMemory.java` to properly guard against unsupported GC arguments. > Previously, the test only checked `@requires vm.gc == "null"`. > > The fix separates the tests and adds explicit `@requires` clauses for each GC configuration to ensure the test only runs when supported. > > This prevents test failures on VMs that do not support the specified GC. > > (This is my first contribution to the JDK. Thank you for your review and guidance.) jonghoonpark has updated the pull request incrementally with one additional commit since the last revision: remove non-specific GC test item and include ZGC and Shenandoah Signed-off-by: jonghoonpark ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26766/files - new: https://git.openjdk.org/jdk/pull/26766/files/e3d7fa54..1002b183 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26766&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26766&range=01-02 Stats: 36 lines in 1 file changed: 22 ins; 11 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26766.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26766/head:pull/26766 PR: https://git.openjdk.org/jdk/pull/26766 From stefank at openjdk.org Wed Sep 3 13:35:40 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 3 Sep 2025 13:35:40 GMT Subject: RFR: 8364927: Add @requires annotation to TestReclaimStringsLeaksMemory.java [v2] In-Reply-To: <65bw-qHodMosRcuZ99DeohHY_5k-5KI5apf12mqjMlI=.5e4e9c1e-c8e5-4263-8d45-b633a1670d7d@github.com> References: <4aT8v-HYcfSoxEEDZZWhw2JjNXxvE1WUDDsYgV7n0I8=.1aef56d4-5a50-4be3-90bf-d57e5a54118b@github.com> <-Tb2UUwG8l2tuLi9Zg9QgzgGVWlNBeDRBi-CXqzUF50=.cbe0b71c-56ae-4195-95b2-95951364e9d9@github.com> <65bw-qHodMosRcuZ99DeohHY_5k-5KI5apf12mqjMlI=.5e4e9c1e-c8e5-4263-8d45-b633a1670d7d@github.com> Message-ID: On Wed, 3 Sep 2025 13:20:12 GMT, jonghoonpark wrote: >>>I thought it was there to test the case where a GC other than SerialGC, ParallelGC, or G1GC might be used as the default. >> >> That could be the case. However, I think that most of our tests don't care about that and instead follow the pattern in TestSystemGC.java >> >>> Then, would it be better to remove the first test and add tests for other GCs later only if they turn out to be necessary? >> >> I think so. >> >> Do you know if ZGC and Shenandoah works with this test? If they do you could also consider adding them. Though that requires you to verify that they actually do pass the test. > > I have confirmed that both ZGC and Shenandoah GC pass the test. > > Then I?ll update the PR by removing the first test item and including them. Yes, please. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26766#discussion_r2318990140 From eosterlund at openjdk.org Wed Sep 3 13:41:49 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 3 Sep 2025 13:41:49 GMT Subject: RFR: 8348278: Trim InitialRAMPercentage to improve startup in default modes [v4] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 12:57:47 GMT, Aleksey Shipilev wrote: >> See bug for discussion. This is the code change, which is simple. What is not simple is deciding what the new value should be. The change would probably require CSR, which I can file after we agree on the value. >> >> I think cutting to 0.2% of RAM size gets us into good sweet spot: >> - On huge 1024G machine, this yields 2G initial heap >> - On reasonably sized 128G machine, this gives 256M initial heap >> - On smaller 1G container, this gives 2M initial heap >> >> Additional testing: >> - [x] Linux AArch64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Also man page > - Fix Looks good! ------------- Marked as reviewed by eosterlund (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23262#pullrequestreview-3180721723 From shade at openjdk.org Wed Sep 3 15:06:44 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 3 Sep 2025 15:06:44 GMT Subject: RFR: 8348278: Trim InitialRAMPercentage to improve startup in default modes [v4] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 12:57:47 GMT, Aleksey Shipilev wrote: >> See bug for discussion. This is the code change, which is simple. What is not simple is deciding what the new value should be. The change would probably require CSR, which I can file after we agree on the value. >> >> I think cutting to 0.2% of RAM size gets us into good sweet spot: >> - On huge 1024G machine, this yields 2G initial heap >> - On reasonably sized 128G machine, this gives 256M initial heap >> - On smaller 1G container, this gives 2M initial heap >> >> Additional testing: >> - [x] Linux AArch64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Also man page > - Fix @tschatzl, are you good with this? Feel free to ping more GC people, if you know they are interested. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23262#issuecomment-3249638622 From stefank at openjdk.org Wed Sep 3 15:26:46 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 3 Sep 2025 15:26:46 GMT Subject: RFR: 8364927: Add @requires annotation to TestReclaimStringsLeaksMemory.java [v3] In-Reply-To: References: <4aT8v-HYcfSoxEEDZZWhw2JjNXxvE1WUDDsYgV7n0I8=.1aef56d4-5a50-4be3-90bf-d57e5a54118b@github.com> Message-ID: On Wed, 3 Sep 2025 13:35:40 GMT, jonghoonpark wrote: >> This change updates `TestReclaimStringsLeaksMemory.java` to properly guard against unsupported GC arguments. >> Previously, the test only checked `@requires vm.gc == "null"`. >> >> The fix separates the tests and adds explicit `@requires` clauses for each GC configuration to ensure the test only runs when supported. >> >> This prevents test failures on VMs that do not support the specified GC. >> >> (This is my first contribution to the JDK. Thank you for your review and guidance.) > > jonghoonpark has updated the pull request incrementally with one additional commit since the last revision: > > remove non-specific GC test item and include ZGC and Shenandoah > > Signed-off-by: jonghoonpark Looks good to me. HotSpot reviews require two reviewers to approve the change so make sure to get a second approval of your latest change. ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26766#pullrequestreview-3181192670 From ayang at openjdk.org Wed Sep 3 16:49:46 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 3 Sep 2025 16:49:46 GMT Subject: RFR: 8364927: Add @requires annotation to TestReclaimStringsLeaksMemory.java [v3] In-Reply-To: References: <4aT8v-HYcfSoxEEDZZWhw2JjNXxvE1WUDDsYgV7n0I8=.1aef56d4-5a50-4be3-90bf-d57e5a54118b@github.com> Message-ID: On Wed, 3 Sep 2025 13:35:40 GMT, jonghoonpark wrote: >> This change updates `TestReclaimStringsLeaksMemory.java` to properly guard against unsupported GC arguments. >> Previously, the test only checked `@requires vm.gc == "null"`. >> >> The fix separates the tests and adds explicit `@requires` clauses for each GC configuration to ensure the test only runs when supported. >> >> This prevents test failures on VMs that do not support the specified GC. >> >> (This is my first contribution to the JDK. Thank you for your review and guidance.) > > jonghoonpark has updated the pull request incrementally with one additional commit since the last revision: > > remove non-specific GC test item and include ZGC and Shenandoah > > Signed-off-by: jonghoonpark Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26766#pullrequestreview-3181474447 From ayang at openjdk.org Wed Sep 3 18:50:48 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 3 Sep 2025 18:50:48 GMT Subject: RFR: 8366155: Serial: Obsolete PretenureSizeThreshold In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 11:44:35 GMT, Albert Mingkun Yang wrote: > Remove obj-size checking before young/old-gen allocation -- an allocation succeeds iff there is enough free space. > > This simplifies the allocation logic: > 1. before attempting gc: `mem_allocate_work` does young-gen allocation then old-gen-no-expansion allocation > 2. after gc (still inside gc safepoint): `satisfy_failed_allocation` does young-gen allocation old-gen-with-expansion allocation > > Test: tier1-3 Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26941#issuecomment-3250368237 From ayang at openjdk.org Wed Sep 3 18:50:49 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 3 Sep 2025 18:50:49 GMT Subject: Integrated: 8366155: Serial: Obsolete PretenureSizeThreshold In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 11:44:35 GMT, Albert Mingkun Yang wrote: > Remove obj-size checking before young/old-gen allocation -- an allocation succeeds iff there is enough free space. > > This simplifies the allocation logic: > 1. before attempting gc: `mem_allocate_work` does young-gen allocation then old-gen-no-expansion allocation > 2. after gc (still inside gc safepoint): `satisfy_failed_allocation` does young-gen allocation old-gen-with-expansion allocation > > Test: tier1-3 This pull request has now been integrated. Changeset: 8d236615 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/8d236615b7db2bd5a2a59002b79e59cf4e6a308a Stats: 86 lines in 7 files changed: 3 ins; 75 del; 8 mod 8366155: Serial: Obsolete PretenureSizeThreshold Reviewed-by: tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/26941 From wkemper at openjdk.org Wed Sep 3 20:15:43 2025 From: wkemper at openjdk.org (William Kemper) Date: Wed, 3 Sep 2025 20:15:43 GMT Subject: RFR: 8366692: Several gc/shenandoah tests timed out [v3] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 04:47:18 GMT, SendaoYan wrote: >> Hi all, >> >> After JDK-8260555 set the default jtreg timeout factor to 1, then several gc/shenandoah tests run timed out with jtreg options -timeoutFactor:1. So I think it's necessary to increase the timeout value set in tests to make test run normally. >> >> The actual run time consumed on my linux-x64 machine with 224 CPU core threads shows in [JDK-8366692](https://bugs.openjdk.org/browse/JDK-8366692). >> >> Accodring the time statistics, the test test/hotspot/jtreg/gc/shenandoah/TestSieveObjects.java only change the second `@run` at the `@test id=generational` and `@test id=aggressive`, other tests do not need to change. And all the `@run` in test test/hotspot/jtreg/gc/shenandoah/jni/TestJNIGlobalRefs.java changed from 120(default value) to 240. >> >> Change has been verified locally on linux-x64, test-fix only, no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Update gc/shenandoah/TestAllocObjects.java#aggressive Thank you! ------------- Marked as reviewed by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27052#pullrequestreview-3182282872 From syan at openjdk.org Thu Sep 4 01:30:50 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 4 Sep 2025 01:30:50 GMT Subject: RFR: 8366692: Several gc/shenandoah tests timed out In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 18:21:14 GMT, William Kemper wrote: >> Hi all, >> >> After JDK-8260555 set the default jtreg timeout factor to 1, then several gc/shenandoah tests run timed out with jtreg options -timeoutFactor:1. So I think it's necessary to increase the timeout value set in tests to make test run normally. >> >> The actual run time consumed on my linux-x64 machine with 224 CPU core threads shows in [JDK-8366692](https://bugs.openjdk.org/browse/JDK-8366692). >> >> Accodring the time statistics, the test test/hotspot/jtreg/gc/shenandoah/TestSieveObjects.java only change the second `@run` at the `@test id=generational` and `@test id=aggressive`, other tests do not need to change. And all the `@run` in test test/hotspot/jtreg/gc/shenandoah/jni/TestJNIGlobalRefs.java changed from 120(default value) to 240. >> >> Change has been verified locally on linux-x64, test-fix only, no risk. > > Seems there is some unrelated build breakage. Can we merge from `master` again before integrating? Thanks for the reviews @earthling-amzn @shipilev ------------- PR Comment: https://git.openjdk.org/jdk/pull/27052#issuecomment-3251359877 From syan at openjdk.org Thu Sep 4 01:30:51 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 4 Sep 2025 01:30:51 GMT Subject: Integrated: 8366692: Several gc/shenandoah tests timed out In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 13:58:46 GMT, SendaoYan wrote: > Hi all, > > After JDK-8260555 set the default jtreg timeout factor to 1, then several gc/shenandoah tests run timed out with jtreg options -timeoutFactor:1. So I think it's necessary to increase the timeout value set in tests to make test run normally. > > The actual run time consumed on my linux-x64 machine with 224 CPU core threads shows in [JDK-8366692](https://bugs.openjdk.org/browse/JDK-8366692). > > Accodring the time statistics, the test test/hotspot/jtreg/gc/shenandoah/TestSieveObjects.java only change the second `@run` at the `@test id=generational` and `@test id=aggressive`, other tests do not need to change. And all the `@run` in test test/hotspot/jtreg/gc/shenandoah/jni/TestJNIGlobalRefs.java changed from 120(default value) to 240. > > Change has been verified locally on linux-x64, test-fix only, no risk. This pull request has now been integrated. Changeset: 02dd2119 Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/02dd21196ed27289a6fad92c4881af484ce9c258 Stats: 8 lines in 3 files changed: 0 ins; 0 del; 8 mod 8366692: Several gc/shenandoah tests timed out Reviewed-by: shade, wkemper ------------- PR: https://git.openjdk.org/jdk/pull/27052 From gli at openjdk.org Thu Sep 4 05:12:32 2025 From: gli at openjdk.org (Guoxiong Li) Date: Thu, 4 Sep 2025 05:12:32 GMT Subject: RFR: 8357188: Remove the field MemAllocator::Allocation::_overhead_limit_exceeded and the related code [v3] In-Reply-To: <0qHdlghXGyq966nZz5mrxkDrTLtN-FNb7zqRSewz92o=.84d3673c-7526-4ad7-a37d-17c3637ce918@github.com> References: <0qHdlghXGyq966nZz5mrxkDrTLtN-FNb7zqRSewz92o=.84d3673c-7526-4ad7-a37d-17c3637ce918@github.com> Message-ID: > Hi all, > > After JDK-8338977 [1], the field `MemAllocator::Allocation::_overhead_limit_exceeded` and the parameter `gc_overhead_limit_was_exceeded` of the method `CollectedHeap::mem_allocate` are not used by any GC. This patch removes them. > > Test: > All the tests of the command `make test TEST="hotspot:hotspot_gc"` passed locally (linux, x86_64, release build). > > Best Regards, > -- Guoxiong > > [1] https://bugs.openjdk.org/browse/JDK-8338977 Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' into REMOVE_UNUSED_FIELD - Remove outdated comments. - JDK-8357188 ------------- Changes: https://git.openjdk.org/jdk/pull/27020/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27020&range=02 Stats: 43 lines in 14 files changed: 0 ins; 22 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/27020.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27020/head:pull/27020 PR: https://git.openjdk.org/jdk/pull/27020 From tschatzl at openjdk.org Thu Sep 4 07:06:47 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 4 Sep 2025 07:06:47 GMT Subject: RFR: 8366688: G1: Rename G1HeapRegionRemSet::is_added_to_cset_group() to has_cset_group() In-Reply-To: <4rjPtppuZp2ZTPA99VUBtbhJZGxWAJAMLL91f0IBERA=.91acb0ec-4564-4a13-b207-457f5c279bdf@github.com> References: <4rjPtppuZp2ZTPA99VUBtbhJZGxWAJAMLL91f0IBERA=.91acb0ec-4564-4a13-b207-457f5c279bdf@github.com> Message-ID: On Tue, 2 Sep 2025 17:27:17 GMT, Ivan Walulya wrote: >> Hi all, >> >> please review this trivial renaming of `G1HHRS::is_added_to_cset_group` - it's just misnamed, we never add G1HRRS to the cset groups. >> >> Testing: gha, local compilation >> >> Thanks, >> Thomas > > Marked as reviewed by iwalulya (Reviewer). Thanks @walulyai @albertnetymk for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/27048#issuecomment-3252210348 From tschatzl at openjdk.org Thu Sep 4 07:06:48 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 4 Sep 2025 07:06:48 GMT Subject: Integrated: 8366688: G1: Rename G1HeapRegionRemSet::is_added_to_cset_group() to has_cset_group() In-Reply-To: References: Message-ID: <7gm0XG8DtlyRO-q1PSqhzLj9IMYcbqb1bRiRSy0tO8Y=.d82a0801-753c-47a6-8354-e29b8c874cb3@github.com> On Tue, 2 Sep 2025 12:41:40 GMT, Thomas Schatzl wrote: > Hi all, > > please review this trivial renaming of `G1HHRS::is_added_to_cset_group` - it's just misnamed, we never add G1HRRS to the cset groups. > > Testing: gha, local compilation > > Thanks, > Thomas This pull request has now been integrated. Changeset: 222ae365 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/222ae365c89e7bcd2cd920f60aa34eebee2c83b6 Stats: 18 lines in 8 files changed: 0 ins; 0 del; 18 mod 8366688: G1: Rename G1HeapRegionRemSet::is_added_to_cset_group() to has_cset_group() Reviewed-by: ayang, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/27048 From iwalulya at openjdk.org Thu Sep 4 08:00:32 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 4 Sep 2025 08:00:32 GMT Subject: RFR: 8366328: G1: Crash on reading os::thread_cpu_time Message-ID: Hi, Please review this patch to ensure that we do not attempt to read CPU time for GC threads that have already been terminated. Testing: Tier 1-3. ------------- Commit messages: - guard Changes: https://git.openjdk.org/jdk/pull/27087/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27087&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366328 Stats: 27 lines in 6 files changed: 13 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/27087.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27087/head:pull/27087 PR: https://git.openjdk.org/jdk/pull/27087 From stefank at openjdk.org Thu Sep 4 08:30:43 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 4 Sep 2025 08:30:43 GMT Subject: RFR: 8366328: G1: Crash on reading os::thread_cpu_time In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 07:48:11 GMT, Ivan Walulya wrote: > Hi, > > Please review this patch to ensure that we do not attempt to read CPU time for GC threads that have already been terminated. > > Testing: Tier 1-3. Did you consider the alternative to prevent the GC from starting a GC pause if the JVM is shutting down? Is it correct that CollectedHeap::stop() can only be called when no STW safepoint operation is executing? ------------- PR Review: https://git.openjdk.org/jdk/pull/27087#pullrequestreview-3184025533 From tschatzl at openjdk.org Thu Sep 4 08:30:44 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 4 Sep 2025 08:30:44 GMT Subject: RFR: 8366328: G1: Crash on reading os::thread_cpu_time In-Reply-To: References: Message-ID: <-mQIRyeN_zpbFtQLAGfE6kQMK_a5ArJRDcFPWvRmEMQ=.e768d023-8345-4327-9565-1ff278fc7298@github.com> On Thu, 4 Sep 2025 07:48:11 GMT, Ivan Walulya wrote: > Hi, > > Please review this patch to ensure that we do not attempt to read CPU time for GC threads that have already been terminated. > > Testing: Tier 1-3. Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27087#pullrequestreview-3184029068 From duke at openjdk.org Thu Sep 4 08:30:45 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Thu, 4 Sep 2025 08:30:45 GMT Subject: RFR: 8366328: G1: Crash on reading os::thread_cpu_time In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 07:48:11 GMT, Ivan Walulya wrote: > Hi, > > Please review this patch to ensure that we do not attempt to read CPU time for GC threads that have already been terminated. > > Testing: Tier 1-3. I wonder if the logic and `_is_shutting_down` should be lifted to `CollectedHeap`. It seems to me that it would useful to support this for all collectors. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27087#issuecomment-3252488472 From iwalulya at openjdk.org Thu Sep 4 09:30:43 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 4 Sep 2025 09:30:43 GMT Subject: RFR: 8366328: G1: Crash on reading os::thread_cpu_time In-Reply-To: References: Message-ID: <8n9DWlWt5mAAkCyJ2hrXCQYCAoeuuOQBf2PbPOby7YI=.6ee7729d-3b6f-47bd-bb3a-7def87a8c0cf@github.com> On Thu, 4 Sep 2025 08:27:27 GMT, Stefan Karlsson wrote: > Did you consider the alternative to prevent the GC from starting a GC pause if the JVM is shutting down? I have filed [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865) to continue with that investigation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27087#issuecomment-3252764452 From azafari at openjdk.org Thu Sep 4 09:34:04 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 4 Sep 2025 09:34:04 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v2] In-Reply-To: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> Message-ID: <54aw-ITOpenp_g9jFUvd1T0FCmh_2gA8d6s-npYNbD8=.60e7920d-2cc4-4281-97bb-afed33ce89e6@github.com> > The minimum acceptable value was 0 where using it as address was problematic according to UBSAN. > The acceptable value is changed to 64K. > > Tests: > linux-x64 tier1 Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: first round of fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26955/files - new: https://git.openjdk.org/jdk/pull/26955/files/2c2a2b94..239df39b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26955&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26955&range=00-01 Stats: 24 lines in 3 files changed: 10 ins; 2 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/26955.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26955/head:pull/26955 PR: https://git.openjdk.org/jdk/pull/26955 From iwalulya at openjdk.org Thu Sep 4 09:36:41 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 4 Sep 2025 09:36:41 GMT Subject: RFR: 8366328: G1: Crash on reading os::thread_cpu_time In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 08:27:58 GMT, Jonas Norlinder wrote: > I wonder if the logic and `_is_shutting_down` should be lifted to `CollectedHeap`. It seems to me that it would useful to support this for all collectors. Other collectors already have similar logic, named differently e.g. `Zabort`, `ShenandoahCollectorPolicy::record_shutdown` ------------- PR Comment: https://git.openjdk.org/jdk/pull/27087#issuecomment-3252805100 From azafari at openjdk.org Thu Sep 4 09:38:41 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 4 Sep 2025 09:38:41 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v2] In-Reply-To: <54aw-ITOpenp_g9jFUvd1T0FCmh_2gA8d6s-npYNbD8=.60e7920d-2cc4-4281-97bb-afed33ce89e6@github.com> References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> <54aw-ITOpenp_g9jFUvd1T0FCmh_2gA8d6s-npYNbD8=.60e7920d-2cc4-4281-97bb-afed33ce89e6@github.com> Message-ID: On Thu, 4 Sep 2025 09:34:04 GMT, Afshin Zafari wrote: >> The minimum acceptable value was 0 where using it as address was problematic according to UBSAN. >> The acceptable value is changed to 64K. >> >> Tests: >> linux-x64 tier1 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > first round of fixes I preferred to do the refactoring here in this PR. With the fixes, the assertion `lowest_start < highest_start` raises(fails) in 3 jtreg tests in tier1: runtime/os/TestTracePageSizes_explicit-large-page-size.java runtime/CompressedOops/CompressedClassPointers.java gc/g1/Test2GbHeap.java In all 3 cases, lowest is the same as the highest start which is a corner case. Are they bugs? Fixed here or file a separate issue? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3252815844 From tschatzl at openjdk.org Thu Sep 4 09:41:44 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 4 Sep 2025 09:41:44 GMT Subject: RFR: 8366328: G1: Crash on reading os::thread_cpu_time In-Reply-To: <8n9DWlWt5mAAkCyJ2hrXCQYCAoeuuOQBf2PbPOby7YI=.6ee7729d-3b6f-47bd-bb3a-7def87a8c0cf@github.com> References: <8n9DWlWt5mAAkCyJ2hrXCQYCAoeuuOQBf2PbPOby7YI=.6ee7729d-3b6f-47bd-bb3a-7def87a8c0cf@github.com> Message-ID: On Thu, 4 Sep 2025 09:28:11 GMT, Ivan Walulya wrote: > > Did you consider the alternative to prevent the GC from starting a GC pause if the JVM is shutting down? > > I have filed [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865) to continue with that investigation. Ivan and me talked about this briefly, but the difference in how the STW collectors request GCs does not allow simple blocking like for ZGC and Shenandoah. In these collectors, Java threads send a request to a director thread that can delay the completion of these (GC) requests easily. In the other collectors, the allocating threads directly enqueue the VM operations which means blocking is not possible as is. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27087#issuecomment-3252827916 From ayang at openjdk.org Thu Sep 4 10:12:41 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 4 Sep 2025 10:12:41 GMT Subject: RFR: 8366328: G1: Crash on reading os::thread_cpu_time In-Reply-To: References: Message-ID: <7Jc1tSsgn0MuDVwBJDttqKA4PqVrGofzXcin7Ra8ywQ=.8ba7928a-0240-49ec-b992-e1f0c179df4c@github.com> On Thu, 4 Sep 2025 07:48:11 GMT, Ivan Walulya wrote: > Hi, > > Please review this patch to ensure that we do not attempt to read CPU time for GC threads that have already been terminated. > > Testing: Tier 1-3. src/hotspot/share/gc/g1/g1Policy.cpp line 672: > 670: // Only compute concurrent GC CPU time if the VM is not in the process of shutting down. > 671: double concurrent_gc_cpu_time_ms = 0.0; > 672: if (!_g1h->is_shutting_down()) { Why is `is_shutting_down` checked here? Can its caller ensure we are not in shutdown, e.g. `G1CollectedHeap::do_collection_pause_at_safepoint`? The current method name kind of suggests that we are in normal gc-pause, not shutdown process, IMO. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27087#discussion_r2321523520 From duke at openjdk.org Thu Sep 4 10:26:41 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Thu, 4 Sep 2025 10:26:41 GMT Subject: RFR: 8366328: G1: Crash on reading os::thread_cpu_time In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 09:33:57 GMT, Ivan Walulya wrote: > I wonder if the logic and _is_shutting_down should be lifted to CollectedHeap. It seems to me that it would useful to support this for all collectors. > Other collectors already have similar logic, named differently e.g. Zabort, ShenandoahCollectorPolicy::record_shutdown Then I think this would be a good opportunity to consolidate this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27087#issuecomment-3252977409 From gli at openjdk.org Thu Sep 4 11:02:43 2025 From: gli at openjdk.org (Guoxiong Li) Date: Thu, 4 Sep 2025 11:02:43 GMT Subject: RFR: 8357188: Remove the field MemAllocator::Allocation::_overhead_limit_exceeded and the related code [v3] In-Reply-To: References: <0qHdlghXGyq966nZz5mrxkDrTLtN-FNb7zqRSewz92o=.84d3673c-7526-4ad7-a37d-17c3637ce918@github.com> Message-ID: On Thu, 4 Sep 2025 05:12:32 GMT, Guoxiong Li wrote: >> Hi all, >> >> After JDK-8338977 [1], the field `MemAllocator::Allocation::_overhead_limit_exceeded` and the parameter `gc_overhead_limit_was_exceeded` of the method `CollectedHeap::mem_allocate` are not used by any GC. This patch removes them. >> >> Test: >> All the tests of the command `make test TEST="hotspot:hotspot_gc"` passed locally (linux, x86_64, release build). >> >> Best Regards, >> -- Guoxiong >> >> [1] https://bugs.openjdk.org/browse/JDK-8338977 > > Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' into REMOVE_UNUSED_FIELD > - Remove outdated comments. > - JDK-8357188 I merged the `master` branch in order to solve the code conflict. Could you help review this patch again? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27020#issuecomment-3253128894 From ayang at openjdk.org Thu Sep 4 11:10:45 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 4 Sep 2025 11:10:45 GMT Subject: RFR: 8357188: Remove the field MemAllocator::Allocation::_overhead_limit_exceeded and the related code [v3] In-Reply-To: References: <0qHdlghXGyq966nZz5mrxkDrTLtN-FNb7zqRSewz92o=.84d3673c-7526-4ad7-a37d-17c3637ce918@github.com> Message-ID: On Thu, 4 Sep 2025 05:12:32 GMT, Guoxiong Li wrote: >> Hi all, >> >> After JDK-8338977 [1], the field `MemAllocator::Allocation::_overhead_limit_exceeded` and the parameter `gc_overhead_limit_was_exceeded` of the method `CollectedHeap::mem_allocate` are not used by any GC. This patch removes them. >> >> Test: >> All the tests of the command `make test TEST="hotspot:hotspot_gc"` passed locally (linux, x86_64, release build). >> >> Best Regards, >> -- Guoxiong >> >> [1] https://bugs.openjdk.org/browse/JDK-8338977 > > Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' into REMOVE_UNUSED_FIELD > - Remove outdated comments. > - JDK-8357188 Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27020#pullrequestreview-3184638351 From jsikstro at openjdk.org Thu Sep 4 11:38:52 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Thu, 4 Sep 2025 11:38:52 GMT Subject: RFR: 8366874: Test gc/arguments/TestParallelGCErgo.java fails with UseTransparentHugePages Message-ID: <3g0iOq_Q3qgbuObzB-DmA2ngAnwD9V63yYPGZ5hMaSE=.a27ba6cc-d01e-40f1-8dee-cab774d990ca@github.com> Hello, I found this test issue when running all GC tests with THP enabled (always or madvise mode) and using the `-XX:+UseTransparentHugePages` flag. The `@requires` flag was added in [JDK-8333306](https://bugs.openjdk.org/browse/JDK-8333306) to prevent the test from being invoked with explicit large pages (HugeTLBfs) enabled. The test also doesn't work with `-XX:+UseTransparentHugePages`. Changing the `@requires`-line to check if `UseLargePages` is evaluated to false in the VM prevents the test from being run when either setting `-XX:+UseLargePages` or `-XX:+UseTransparentHugePages`. I've tested locally that the test no longer runs with the `-XX:+UseTransparentHugePages` or `-XX:+UseLargePages` flags. Without either of the flags, the test runs fine. ------------- Commit messages: - 8366874: Test gc/arguments/TestParallelGCErgo.java fails with UseTransparentHugePages Changes: https://git.openjdk.org/jdk/pull/27090/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27090&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366874 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27090.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27090/head:pull/27090 PR: https://git.openjdk.org/jdk/pull/27090 From ayang at openjdk.org Thu Sep 4 11:42:43 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 4 Sep 2025 11:42:43 GMT Subject: RFR: 8366874: Test gc/arguments/TestParallelGCErgo.java fails with UseTransparentHugePages In-Reply-To: <3g0iOq_Q3qgbuObzB-DmA2ngAnwD9V63yYPGZ5hMaSE=.a27ba6cc-d01e-40f1-8dee-cab774d990ca@github.com> References: <3g0iOq_Q3qgbuObzB-DmA2ngAnwD9V63yYPGZ5hMaSE=.a27ba6cc-d01e-40f1-8dee-cab774d990ca@github.com> Message-ID: On Thu, 4 Sep 2025 11:33:44 GMT, Joel Sikstr?m wrote: > Hello, > > I found this test issue when running all GC tests with THP enabled (always or madvise mode) and using the `-XX:+UseTransparentHugePages` flag. The `@requires` flag was added in [JDK-8333306](https://bugs.openjdk.org/browse/JDK-8333306) to prevent the test from being invoked with explicit large pages (HugeTLBfs) enabled. The test also doesn't work with `-XX:+UseTransparentHugePages`. > > Changing the `@requires`-line to check if `UseLargePages` is evaluated to false in the VM prevents the test from being run when either setting `-XX:+UseLargePages` or `-XX:+UseTransparentHugePages`. > > I've tested locally that the test no longer runs with the `-XX:+UseTransparentHugePages` or `-XX:+UseLargePages` flags. Without either of the flags, the test runs fine. Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27090#pullrequestreview-3184763123 From shade at openjdk.org Thu Sep 4 13:18:45 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 4 Sep 2025 13:18:45 GMT Subject: RFR: 8366874: Test gc/arguments/TestParallelGCErgo.java fails with UseTransparentHugePages In-Reply-To: <3g0iOq_Q3qgbuObzB-DmA2ngAnwD9V63yYPGZ5hMaSE=.a27ba6cc-d01e-40f1-8dee-cab774d990ca@github.com> References: <3g0iOq_Q3qgbuObzB-DmA2ngAnwD9V63yYPGZ5hMaSE=.a27ba6cc-d01e-40f1-8dee-cab774d990ca@github.com> Message-ID: On Thu, 4 Sep 2025 11:33:44 GMT, Joel Sikstr?m wrote: > Hello, > > I found this test issue when running all GC tests with THP enabled (always or madvise mode) and using the `-XX:+UseTransparentHugePages` flag. The `@requires` flag was added in [JDK-8333306](https://bugs.openjdk.org/browse/JDK-8333306) to prevent the test from being invoked with explicit large pages (HugeTLBfs) enabled. The test also doesn't work with `-XX:+UseTransparentHugePages`. > > Changing the `@requires`-line to check if `UseLargePages` is evaluated to false in the VM prevents the test from being run when either setting `-XX:+UseLargePages` or `-XX:+UseTransparentHugePages`. > > I've tested locally that the test no longer runs with the `-XX:+UseTransparentHugePages` or `-XX:+UseLargePages` flags. Without either of the flags, the test runs fine. Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27090#pullrequestreview-3185234819 From stefank at openjdk.org Thu Sep 4 13:35:41 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 4 Sep 2025 13:35:41 GMT Subject: RFR: 8366874: Test gc/arguments/TestParallelGCErgo.java fails with UseTransparentHugePages In-Reply-To: <3g0iOq_Q3qgbuObzB-DmA2ngAnwD9V63yYPGZ5hMaSE=.a27ba6cc-d01e-40f1-8dee-cab774d990ca@github.com> References: <3g0iOq_Q3qgbuObzB-DmA2ngAnwD9V63yYPGZ5hMaSE=.a27ba6cc-d01e-40f1-8dee-cab774d990ca@github.com> Message-ID: On Thu, 4 Sep 2025 11:33:44 GMT, Joel Sikstr?m wrote: > Hello, > > I found this test issue when running all GC tests with THP enabled (always or madvise mode) and using the `-XX:+UseTransparentHugePages` flag. The `@requires` flag was added in [JDK-8333306](https://bugs.openjdk.org/browse/JDK-8333306) to prevent the test from being invoked with explicit large pages (HugeTLBfs) enabled. The test also doesn't work with `-XX:+UseTransparentHugePages`. > > Changing the `@requires`-line to check if `UseLargePages` is evaluated to false in the VM prevents the test from being run when either setting `-XX:+UseLargePages` or `-XX:+UseTransparentHugePages`. > > I've tested locally that the test no longer runs with the `-XX:+UseTransparentHugePages` or `-XX:+UseLargePages` flags. Without either of the flags, the test runs fine. Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27090#pullrequestreview-3185337401 From mli at openjdk.org Thu Sep 4 13:49:44 2025 From: mli at openjdk.org (Hamlin Li) Date: Thu, 4 Sep 2025 13:49:44 GMT Subject: RFR: 8366328: G1: Crash on reading os::thread_cpu_time In-Reply-To: <7Jc1tSsgn0MuDVwBJDttqKA4PqVrGofzXcin7Ra8ywQ=.8ba7928a-0240-49ec-b992-e1f0c179df4c@github.com> References: <7Jc1tSsgn0MuDVwBJDttqKA4PqVrGofzXcin7Ra8ywQ=.8ba7928a-0240-49ec-b992-e1f0c179df4c@github.com> Message-ID: On Thu, 4 Sep 2025 10:10:16 GMT, Albert Mingkun Yang wrote: >> Hi, >> >> Please review this patch to ensure that we do not attempt to read CPU time for GC threads that have already been terminated. >> >> Testing: Tier 1-3. > > src/hotspot/share/gc/g1/g1Policy.cpp line 672: > >> 670: // Only compute concurrent GC CPU time if the VM is not in the process of shutting down. >> 671: double concurrent_gc_cpu_time_ms = 0.0; >> 672: if (!_g1h->is_shutting_down()) { > > Why is `is_shutting_down` checked here? Can its caller ensure we are not in shutdown, e.g. `G1CollectedHeap::do_collection_pause_at_safepoint`? > > The current method name kind of suggests that we are in normal gc-pause, not shutdown process, IMO. Is it possible for following a situation to occur? 1. thread A run to here 2. thread B call G1CollectedHeap::stop() 3. then after a while, thread A execute following 2 lines. If it's possible, could it still cause the similar crash in some extreme situation? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27087#discussion_r2322237509 From iwalulya at openjdk.org Thu Sep 4 14:27:42 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 4 Sep 2025 14:27:42 GMT Subject: RFR: 8366328: G1: Crash on reading os::thread_cpu_time In-Reply-To: References: <7Jc1tSsgn0MuDVwBJDttqKA4PqVrGofzXcin7Ra8ywQ=.8ba7928a-0240-49ec-b992-e1f0c179df4c@github.com> Message-ID: On Thu, 4 Sep 2025 13:47:29 GMT, Hamlin Li wrote: >> src/hotspot/share/gc/g1/g1Policy.cpp line 672: >> >>> 670: // Only compute concurrent GC CPU time if the VM is not in the process of shutting down. >>> 671: double concurrent_gc_cpu_time_ms = 0.0; >>> 672: if (!_g1h->is_shutting_down()) { >> >> Why is `is_shutting_down` checked here? Can its caller ensure we are not in shutdown, e.g. `G1CollectedHeap::do_collection_pause_at_safepoint`? >> >> The current method name kind of suggests that we are in normal gc-pause, not shutdown process, IMO. > > Is it possible for following a situation to occur? > 1. thread A run to here > 2. thread B call G1CollectedHeap::stop() > 3. then after a while, thread A execute following 2 lines. > > If it's possible, could it still cause the similar crash in some extreme situation? The assumption is that thread B is at a safepoint if thread A is executing `record_pause_start_time()`. So this interleaving is not possible. iiuc ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27087#discussion_r2322382826 From tschatzl at openjdk.org Thu Sep 4 15:08:53 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 4 Sep 2025 15:08:53 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v53] In-Reply-To: References: Message-ID: <-6I6w_xqk0J13gqMX8ZQel4elME1K0ZYs55Li2lmgd8=.fdd1d6fb-eaae-4d93-a2ac-74b03d3f4212@github.com> > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 71 commits: - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * improve logging for refinement, making it similar to marking logging - * commit merge changes - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * fix merge error - * forgot to actually save the files - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - ... and 61 more: https://git.openjdk.org/jdk/compare/e1903557...2a614a2c ------------- Changes: https://git.openjdk.org/jdk/pull/23739/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=52 Stats: 7117 lines in 112 files changed: 2592 ins; 3585 del; 940 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From tschatzl at openjdk.org Fri Sep 5 08:24:11 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 5 Sep 2025 08:24:11 GMT Subject: RFR: 8366874: Test gc/arguments/TestParallelGCErgo.java fails with UseTransparentHugePages In-Reply-To: <3g0iOq_Q3qgbuObzB-DmA2ngAnwD9V63yYPGZ5hMaSE=.a27ba6cc-d01e-40f1-8dee-cab774d990ca@github.com> References: <3g0iOq_Q3qgbuObzB-DmA2ngAnwD9V63yYPGZ5hMaSE=.a27ba6cc-d01e-40f1-8dee-cab774d990ca@github.com> Message-ID: <-olQ4GscMtFD0JOHxfzXaVeK11O0xiwWd4NSpNNlDCI=.eff4689b-7448-4dfb-8686-043aa48babff@github.com> On Thu, 4 Sep 2025 11:33:44 GMT, Joel Sikstr?m wrote: > Hello, > > I found this test issue when running all GC tests with THP enabled (always or madvise mode) and using the `-XX:+UseTransparentHugePages` flag. The `@requires` flag was added in [JDK-8333306](https://bugs.openjdk.org/browse/JDK-8333306) to prevent the test from being invoked with explicit large pages (HugeTLBfs) enabled. The test also doesn't work with `-XX:+UseTransparentHugePages`. > > Changing the `@requires`-line to check if `UseLargePages` is evaluated to false in the VM prevents the test from being run when either setting `-XX:+UseLargePages` or `-XX:+UseTransparentHugePages`. > > I've tested locally that the test no longer runs with the `-XX:+UseTransparentHugePages` or `-XX:+UseLargePages` flags. Without either of the flags, the test runs fine. Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27090#pullrequestreview-3188449775 From iwalulya at openjdk.org Fri Sep 5 09:30:52 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Fri, 5 Sep 2025 09:30:52 GMT Subject: RFR: 8366881: Parallel: Obsolete HeapMaximumCompactionInterval [v2] In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 09:30:45 GMT, Albert Mingkun Yang wrote: >> Remove a produce flag that controls maximum-compaction during a full-gc. The existing criteria, such as heap usage, old-gen density, are enough for deciding maximum-compaction. >> >> Test: tier1-3 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - review > - Merge branch 'master' into pgc-max-compaction-obsolete > - pgc-max-compaction-obsolete Looks good! ------------- Marked as reviewed by iwalulya (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27091#pullrequestreview-3188643316 From ayang at openjdk.org Fri Sep 5 09:30:45 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 5 Sep 2025 09:30:45 GMT Subject: RFR: 8366881: Parallel: Obsolete HeapMaximumCompactionInterval [v2] In-Reply-To: References: Message-ID: > Remove a produce flag that controls maximum-compaction during a full-gc. The existing criteria, such as heap usage, old-gen density, are enough for deciding maximum-compaction. > > Test: tier1-3 Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - review - Merge branch 'master' into pgc-max-compaction-obsolete - pgc-max-compaction-obsolete ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27091/files - new: https://git.openjdk.org/jdk/pull/27091/files/d764377f..5f7fed4c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27091&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27091&range=00-01 Stats: 1996 lines in 93 files changed: 1199 ins; 205 del; 592 mod Patch: https://git.openjdk.org/jdk/pull/27091.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27091/head:pull/27091 PR: https://git.openjdk.org/jdk/pull/27091 From duke at openjdk.org Fri Sep 5 10:18:26 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Fri, 5 Sep 2025 10:18:26 GMT Subject: RFR: 8366970: CPUTimeUsage: Add comment about usage during VM exit Message-ID: Some of the methods in CPUTimeUsage make a query on the underlying threads. Calling those methods during VM exit is therefore unsafe. This PR adds a comment to provide clarification. ------------- Commit messages: - Add comment Changes: https://git.openjdk.org/jdk/pull/27115/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27115&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366970 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27115.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27115/head:pull/27115 PR: https://git.openjdk.org/jdk/pull/27115 From azafari at openjdk.org Fri Sep 5 11:02:32 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 5 Sep 2025 11:02:32 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v3] In-Reply-To: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> Message-ID: <-eWIUjA4RqIgcpvFSyFxuiuganZpBqkMIdKSOVhnuMo=.79db2c26-5547-42fa-84d9-9bf5746728cf@github.com> > The minimum acceptable value was 0 where using it as address was problematic according to UBSAN. > The acceptable value is changed to 64K. > > Tests: > linux-x64 tier1 Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: lowest can be equal to highest ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26955/files - new: https://git.openjdk.org/jdk/pull/26955/files/239df39b..76cf950e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26955&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26955&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26955.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26955/head:pull/26955 PR: https://git.openjdk.org/jdk/pull/26955 From gli at openjdk.org Fri Sep 5 13:37:21 2025 From: gli at openjdk.org (Guoxiong Li) Date: Fri, 5 Sep 2025 13:37:21 GMT Subject: RFR: 8357188: Remove the field MemAllocator::Allocation::_overhead_limit_exceeded and the related code [v3] In-Reply-To: References: <0qHdlghXGyq966nZz5mrxkDrTLtN-FNb7zqRSewz92o=.84d3673c-7526-4ad7-a37d-17c3637ce918@github.com> Message-ID: On Thu, 4 Sep 2025 05:12:32 GMT, Guoxiong Li wrote: >> Hi all, >> >> After JDK-8338977 [1], the field `MemAllocator::Allocation::_overhead_limit_exceeded` and the parameter `gc_overhead_limit_was_exceeded` of the method `CollectedHeap::mem_allocate` are not used by any GC. This patch removes them. >> >> Test: >> All the tests of the command `make test TEST="hotspot:hotspot_gc"` passed locally (linux, x86_64, release build). >> >> Best Regards, >> -- Guoxiong >> >> [1] https://bugs.openjdk.org/browse/JDK-8338977 > > Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' into REMOVE_UNUSED_FIELD > - Remove outdated comments. > - JDK-8357188 Thanks for your reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27020#issuecomment-3258374018 From gli at openjdk.org Fri Sep 5 13:37:22 2025 From: gli at openjdk.org (Guoxiong Li) Date: Fri, 5 Sep 2025 13:37:22 GMT Subject: Integrated: 8357188: Remove the field MemAllocator::Allocation::_overhead_limit_exceeded and the related code In-Reply-To: <0qHdlghXGyq966nZz5mrxkDrTLtN-FNb7zqRSewz92o=.84d3673c-7526-4ad7-a37d-17c3637ce918@github.com> References: <0qHdlghXGyq966nZz5mrxkDrTLtN-FNb7zqRSewz92o=.84d3673c-7526-4ad7-a37d-17c3637ce918@github.com> Message-ID: On Sat, 30 Aug 2025 10:49:45 GMT, Guoxiong Li wrote: > Hi all, > > After JDK-8338977 [1], the field `MemAllocator::Allocation::_overhead_limit_exceeded` and the parameter `gc_overhead_limit_was_exceeded` of the method `CollectedHeap::mem_allocate` are not used by any GC. This patch removes them. > > Test: > All the tests of the command `make test TEST="hotspot:hotspot_gc"` passed locally (linux, x86_64, release build). > > Best Regards, > -- Guoxiong > > [1] https://bugs.openjdk.org/browse/JDK-8338977 This pull request has now been integrated. Changeset: 33794d16 Author: Guoxiong Li URL: https://git.openjdk.org/jdk/commit/33794d161467635eb32591fee189e5409cd2d114 Stats: 43 lines in 14 files changed: 0 ins; 22 del; 21 mod 8357188: Remove the field MemAllocator::Allocation::_overhead_limit_exceeded and the related code Reviewed-by: ayang, shade ------------- PR: https://git.openjdk.org/jdk/pull/27020 From tschatzl at openjdk.org Fri Sep 5 14:12:11 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 5 Sep 2025 14:12:11 GMT Subject: RFR: 8366970: CPUTimeUsage: Add comment about usage during VM exit In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 10:06:32 GMT, Jonas Norlinder wrote: > Some of the methods in CPUTimeUsage make a query on the underlying threads. Calling those methods during VM exit is therefore unsafe. This PR adds a comment to provide clarification. Looks good, but maybe it makes sense to add an assert-flag to the `Thread` that indicates whether the `Thread` has been terminated, and fail here. (My change request is purely about the additional newline, the suggestion above is just something that is possible. Not sure it is worth). src/hotspot/share/services/cpuTimeUsage.hpp line 33: > 31: // It may be unsafe to call these methods during VM exit > 32: // as threads are terminating > 33: Suggestion: Proper sentences need a full stop at the end too. ------------- Changes requested by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27115#pullrequestreview-3189526429 PR Review Comment: https://git.openjdk.org/jdk/pull/27115#discussion_r2325203856 From ghan at openjdk.org Mon Sep 8 00:02:06 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Mon, 8 Sep 2025 00:02:06 GMT Subject: RFR: 8367025: zIndexDistributor.hpp uses angle-bracket inclusion of globalDefinitions.hpp Message-ID: trivial change ------------- Commit messages: - Update zIndexDistributor.hpp Changes: https://git.openjdk.org/jdk/pull/27133/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27133&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367025 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27133.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27133/head:pull/27133 PR: https://git.openjdk.org/jdk/pull/27133 From aboldtch at openjdk.org Mon Sep 8 05:10:19 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 8 Sep 2025 05:10:19 GMT Subject: RFR: 8367025: zIndexDistributor.hpp uses angle-bracket inclusion of globalDefinitions.hpp In-Reply-To: References: Message-ID: On Sun, 7 Sep 2025 23:56:15 GMT, Guanqiang Han wrote: > trivial change Looks good and trivial. ------------- Marked as reviewed by aboldtch (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27133#pullrequestreview-3194976430 From aboldtch at openjdk.org Mon Sep 8 05:16:21 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 8 Sep 2025 05:16:21 GMT Subject: RFR: 8366065: ZGC: Differentiate Young Collection type strings in statistics In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 12:21:46 GMT, Joel Sikstr?m wrote: > Hello, > > Currently, two different Young Collection (YC) types print identical strings in the GC statistics at the end of `-Xlog:gc*`. This makes it difficult to distinguish statistics for specific YC types when analyzing logs for performance issues. This PR updates the strings to match the `ZYoungType` enum names, improving traceability and making logs clearer. > > Relevant enum for reference: > ```c++ > enum class ZYoungType { > minor, > major_full_preclean, > major_full_roots, > major_partial_roots, > none > }; > > > Testing: > * GHA Very nice to be able to differentiate the stats logging for the major and minor GC. We have some mixed terminology already with regards to `prelcean` and `promote all`. I think this change is fine and brings the logging in line with the terms used for `ZYoungType`. ------------- Marked as reviewed by aboldtch (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26986#pullrequestreview-3194985172 From jsikstro at openjdk.org Mon Sep 8 06:36:19 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Mon, 8 Sep 2025 06:36:19 GMT Subject: RFR: 8366874: Test gc/arguments/TestParallelGCErgo.java fails with UseTransparentHugePages In-Reply-To: <3g0iOq_Q3qgbuObzB-DmA2ngAnwD9V63yYPGZ5hMaSE=.a27ba6cc-d01e-40f1-8dee-cab774d990ca@github.com> References: <3g0iOq_Q3qgbuObzB-DmA2ngAnwD9V63yYPGZ5hMaSE=.a27ba6cc-d01e-40f1-8dee-cab774d990ca@github.com> Message-ID: On Thu, 4 Sep 2025 11:33:44 GMT, Joel Sikstr?m wrote: > Hello, > > I found this test issue when running all GC tests with THP enabled (always or madvise mode) and using the `-XX:+UseTransparentHugePages` flag. The `@requires` flag was added in [JDK-8333306](https://bugs.openjdk.org/browse/JDK-8333306) to prevent the test from being invoked with explicit large pages (HugeTLBfs) enabled. The test also doesn't work with `-XX:+UseTransparentHugePages`. > > Changing the `@requires`-line to check if `UseLargePages` is evaluated to false in the VM prevents the test from being run when either setting `-XX:+UseLargePages` or `-XX:+UseTransparentHugePages`. > > I've tested locally that the test no longer runs with the `-XX:+UseTransparentHugePages` or `-XX:+UseLargePages` flags. Without either of the flags, the test runs fine. Thank you for the reviews everyone! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27090#issuecomment-3264802408 From jsikstro at openjdk.org Mon Sep 8 06:36:20 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Mon, 8 Sep 2025 06:36:20 GMT Subject: Integrated: 8366874: Test gc/arguments/TestParallelGCErgo.java fails with UseTransparentHugePages In-Reply-To: <3g0iOq_Q3qgbuObzB-DmA2ngAnwD9V63yYPGZ5hMaSE=.a27ba6cc-d01e-40f1-8dee-cab774d990ca@github.com> References: <3g0iOq_Q3qgbuObzB-DmA2ngAnwD9V63yYPGZ5hMaSE=.a27ba6cc-d01e-40f1-8dee-cab774d990ca@github.com> Message-ID: On Thu, 4 Sep 2025 11:33:44 GMT, Joel Sikstr?m wrote: > Hello, > > I found this test issue when running all GC tests with THP enabled (always or madvise mode) and using the `-XX:+UseTransparentHugePages` flag. The `@requires` flag was added in [JDK-8333306](https://bugs.openjdk.org/browse/JDK-8333306) to prevent the test from being invoked with explicit large pages (HugeTLBfs) enabled. The test also doesn't work with `-XX:+UseTransparentHugePages`. > > Changing the `@requires`-line to check if `UseLargePages` is evaluated to false in the VM prevents the test from being run when either setting `-XX:+UseLargePages` or `-XX:+UseTransparentHugePages`. > > I've tested locally that the test no longer runs with the `-XX:+UseTransparentHugePages` or `-XX:+UseLargePages` flags. Without either of the flags, the test runs fine. This pull request has now been integrated. Changeset: fb1924d2 Author: Joel Sikstr?m URL: https://git.openjdk.org/jdk/commit/fb1924d2e34f77dc834094485dccb1751bc5b3b6 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8366874: Test gc/arguments/TestParallelGCErgo.java fails with UseTransparentHugePages Reviewed-by: ayang, shade, stefank, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/27090 From tschatzl at openjdk.org Mon Sep 8 06:59:09 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 8 Sep 2025 06:59:09 GMT Subject: RFR: 8367025: zIndexDistributor.hpp uses angle-bracket inclusion of globalDefinitions.hpp In-Reply-To: References: Message-ID: On Sun, 7 Sep 2025 23:56:15 GMT, Guanqiang Han wrote: > trivial change trivial ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27133#pullrequestreview-3195197875 From dholmes at openjdk.org Mon Sep 8 07:15:12 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 8 Sep 2025 07:15:12 GMT Subject: RFR: 8366970: CPUTimeUsage: Add comment about usage during VM exit In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 10:06:32 GMT, Jonas Norlinder wrote: > Some of the methods in CPUTimeUsage make a query on the underlying threads. Calling those methods during VM exit is therefore unsafe. This PR adds a comment to provide clarification. If the methods could be unsafe surely they should be checking for that, or else ensuring they are not used in unsafe contexts. ------------- PR Review: https://git.openjdk.org/jdk/pull/27115#pullrequestreview-3195241431 From duke at openjdk.org Mon Sep 8 07:40:15 2025 From: duke at openjdk.org (duke) Date: Mon, 8 Sep 2025 07:40:15 GMT Subject: RFR: 8367025: zIndexDistributor.hpp uses angle-bracket inclusion of globalDefinitions.hpp In-Reply-To: References: Message-ID: On Sun, 7 Sep 2025 23:56:15 GMT, Guanqiang Han wrote: > trivial change @hgqxjj Your change (at version 6e883cc256e0ea4ef8cb78aca34987b1066d13cf) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27133#issuecomment-3264988268 From ghan at openjdk.org Mon Sep 8 07:40:16 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Mon, 8 Sep 2025 07:40:16 GMT Subject: RFR: 8367025: zIndexDistributor.hpp uses angle-bracket inclusion of globalDefinitions.hpp In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 05:07:57 GMT, Axel Boldt-Christmas wrote: >> trivial change > > Looks good and trivial. @xmas92 @tschatzl Thank you for the reviews. I have integrated this PR. Could you please sponsor it? Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27133#issuecomment-3264995202 From ghan at openjdk.org Mon Sep 8 07:42:11 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Mon, 8 Sep 2025 07:42:11 GMT Subject: RFR: 8352969: G1: Improve testability of optional collections [v3] In-Reply-To: References: <1fNzfZ2HlfWuS2tMoENBL5Xp3wZH8XUxiXB-soC85r0=.915bb437-5655-4b21-89c4-f0a07b70c072@github.com> Message-ID: On Wed, 27 Aug 2025 09:22:53 GMT, Thomas Schatzl wrote: >> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: >> >> Update g1YoungCollector.cpp >> >> format fix > > Changes requested by tschatzl (Reviewer). Hi @tschatzl I've addressed all the feedback in this PR. Please take another look. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26880#issuecomment-3265001485 From ayang at openjdk.org Mon Sep 8 08:36:08 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 8 Sep 2025 08:36:08 GMT Subject: RFR: 8346005: Parallel: Incorrect page size calculation with UseLargePages [v4] In-Reply-To: References: Message-ID: > Refactor the heap-space and OS memory interface code to clearly separate two related but distinct concepts: `alignment` and `os-page-size`. These are now represented as two fields in `PSVirtualSpace`. > > The parallel heap consists of four spaces: old, eden, from, and to. The first belongs to the old generation, while the latter three belong to the young generation. > > The size of any space is always aligned to `alignment`, which also determines the unit for resizing. To keep the implementation simple while allowing flexible per-space commit and uncommit operations, each space must contain at least one OS page. As a result, `alignment` is always greater than or equal to `os-page-size`. > > When using explicit large pages -- which require pre-allocating large pages before the VM starts -- the actual OS page size is not known until the heap has been reserved. The additional logic in `ParallelScavengeHeap::initialize` detects the OS page size in use and adjusts `alignment` if necessary. > > Test: tier1?8 Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - page-size - Merge branch 'master' into pgc-largepage - Merge branch 'master' into pgc-largepage - Merge branch 'master' into pgc-largepage - pgc-largepage ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26700/files - new: https://git.openjdk.org/jdk/pull/26700/files/88702f07..74d4fa3c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26700&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26700&range=02-03 Stats: 23374 lines in 1065 files changed: 16423 ins; 3065 del; 3886 mod Patch: https://git.openjdk.org/jdk/pull/26700.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26700/head:pull/26700 PR: https://git.openjdk.org/jdk/pull/26700 From ayang at openjdk.org Mon Sep 8 08:42:18 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 8 Sep 2025 08:42:18 GMT Subject: RFR: 8346005: Parallel: Incorrect page size calculation with UseLargePages [v4] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 08:36:08 GMT, Albert Mingkun Yang wrote: >> Refactor the heap-space and OS memory interface code to clearly separate two related but distinct concepts: `alignment` and `os-page-size`. These are now represented as two fields in `PSVirtualSpace`. >> >> The parallel heap consists of four spaces: old, eden, from, and to. The first belongs to the old generation, while the latter three belong to the young generation. >> >> The size of any space is always aligned to `alignment`, which also determines the unit for resizing. To keep the implementation simple while allowing flexible per-space commit and uncommit operations, each space must contain at least one OS page. As a result, `alignment` is always greater than or equal to `os-page-size`. >> >> When using explicit large pages -- which require pre-allocating large pages before the VM starts -- the actual OS page size is not known until the heap has been reserved. The additional logic in `ParallelScavengeHeap::initialize` detects the OS page size in use and adjusts `alignment` if necessary. >> >> Test: tier1?8 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - page-size > - Merge branch 'master' into pgc-largepage > - Merge branch 'master' into pgc-largepage > - Merge branch 'master' into pgc-largepage > - pgc-largepage Minor updates after [JDK-8366434](https://bugs.openjdk.org/browse/JDK-8366434), as the page-size of reserved-memory reflects the intended/actual OS page-size, when using transparent huge pages. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26700#issuecomment-3265204916 From ayang at openjdk.org Mon Sep 8 08:49:53 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 8 Sep 2025 08:49:53 GMT Subject: RFR: 8366781: Parallel: Include OS free memory in GC selection heuristics [v2] In-Reply-To: References: Message-ID: > Add a new condition checking if OS has enough free memory to commit/expand old-gen, which determines whether the upcoming GC should be young or full. > > Test: tier1-3 Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - review - Merge branch 'master' into pgc-os-free-mem - pgc-os-free-mem ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27068/files - new: https://git.openjdk.org/jdk/pull/27068/files/b435c949..f8449f31 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27068&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27068&range=00-01 Stats: 11459 lines in 461 files changed: 6125 ins; 3001 del; 2333 mod Patch: https://git.openjdk.org/jdk/pull/27068.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27068/head:pull/27068 PR: https://git.openjdk.org/jdk/pull/27068 From tschatzl at openjdk.org Mon Sep 8 09:09:49 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 8 Sep 2025 09:09:49 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * sort includes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23739/files - new: https://git.openjdk.org/jdk/pull/23739/files/2a614a2c..4601bf88 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=53 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=52-53 Stats: 7 lines in 4 files changed: 4 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From shade at openjdk.org Mon Sep 8 09:17:15 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 8 Sep 2025 09:17:15 GMT Subject: RFR: 8348278: Trim InitialRAMPercentage to improve startup in default modes [v4] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 12:57:47 GMT, Aleksey Shipilev wrote: >> See bug for discussion. This is the code change, which is simple. What is not simple is deciding what the new value should be. The change would probably require CSR, which I can file after we agree on the value. >> >> I think cutting to 0.2% of RAM size gets us into good sweet spot: >> - On huge 1024G machine, this yields 2G initial heap >> - On reasonably sized 128G machine, this gives 256M initial heap >> - On smaller 1G container, this gives 2M initial heap >> >> Additional testing: >> - [x] Linux AArch64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Also man page > - Fix Friendly reminder :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23262#issuecomment-3265355024 From jwaters at openjdk.org Mon Sep 8 09:37:11 2025 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 8 Sep 2025 09:37:11 GMT Subject: RFR: 8367025: zIndexDistributor.hpp uses angle-bracket inclusion of globalDefinitions.hpp In-Reply-To: References: Message-ID: On Sun, 7 Sep 2025 23:56:15 GMT, Guanqiang Han wrote: > trivial change Marked as reviewed by jwaters (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27133#pullrequestreview-3195739571 From ghan at openjdk.org Mon Sep 8 09:40:20 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Mon, 8 Sep 2025 09:40:20 GMT Subject: Integrated: 8367025: zIndexDistributor.hpp uses angle-bracket inclusion of globalDefinitions.hpp In-Reply-To: References: Message-ID: On Sun, 7 Sep 2025 23:56:15 GMT, Guanqiang Han wrote: > trivial change This pull request has now been integrated. Changeset: 5e423e03 Author: Guanqiang Han Committer: Julian Waters URL: https://git.openjdk.org/jdk/commit/5e423e034f1f077ce9c17cfe9b0d838a4cf9365e Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8367025: zIndexDistributor.hpp uses angle-bracket inclusion of globalDefinitions.hpp Reviewed-by: aboldtch, tschatzl, jwaters ------------- PR: https://git.openjdk.org/jdk/pull/27133 From ghan at openjdk.org Mon Sep 8 09:47:22 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Mon, 8 Sep 2025 09:47:22 GMT Subject: RFR: 8367025: zIndexDistributor.hpp uses angle-bracket inclusion of globalDefinitions.hpp In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 09:34:58 GMT, Julian Waters wrote: >> trivial change > > Marked as reviewed by jwaters (Committer). @TheShermanTanker Thanks a lot! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27133#issuecomment-3265466121 From tschatzl at openjdk.org Mon Sep 8 09:50:19 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 8 Sep 2025 09:50:19 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 09:09:49 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * sort includes We would like to finally wrap up this PR as we are about to Propose To Target [JEP 522](openjdk.org/jeps/522) to JDK 26, so it would be nice to get re-reviews from the reviewers that already signed it off if you think it is useful. Nothing much changed actually for months now, particularly in the area of target-specific support, but maybe one more rerun on the more exotic platforms (AIX/PPC, RISC-V) just in case would be fine. Internally it went through Oracle's tier1-8 without any issue again (that is revision https://github.com/openjdk/jdk/pull/23739/commits/b3873d66cd43518d5dc71e060fc52a13372dbfa5, but the changes since then were very cosmetic). ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3265474466 From stefank at openjdk.org Mon Sep 8 12:39:51 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 8 Sep 2025 12:39:51 GMT Subject: RFR: 8366980: TestTransparentHugePagesHeap.java fails when run with -UseCompressedOops Message-ID: The new test TestTransparentHugePagesHeap.java added in [JDK-8366434](https://bugs.openjdk.org/browse/JDK-8366434) fails when run with -UseCompressedOops. The reason for this is that the address printed as the start of the heap in the pagesize logging is not the start of the mapping. So we fail to find the mapping when scanning the SMAPS file. There reason why this happens is that Linux has merged the memory area for the heap with some other memory. Sometimes it is the marking bitmaps and sometimes it's just malloc that mapped some memory. I propose that we change the test to find the smaps memory area that contains the start address of the heap and verify that that area is THP eligible. I'm using BigInteger to represent the parsed addresses to skip having to deal with negative values in longs. Tested locally with the reproducer. I'm also testing with tier1 and the tier that found this issue. The fix is localized in TestTransparentHugePagesHeap.java so that it can easily be incorporated into a backport of JDK-8366434. ------------- Commit messages: - Simplify - Match overlapping ranges Changes: https://git.openjdk.org/jdk/pull/27143/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27143&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366980 Stats: 49 lines in 1 file changed: 27 ins; 2 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/27143.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27143/head:pull/27143 PR: https://git.openjdk.org/jdk/pull/27143 From stefank at openjdk.org Mon Sep 8 13:12:46 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 8 Sep 2025 13:12:46 GMT Subject: RFR: 8366980: TestTransparentHugePagesHeap.java fails when run with -UseCompressedOops [v2] In-Reply-To: References: Message-ID: > The new test TestTransparentHugePagesHeap.java added in [JDK-8366434](https://bugs.openjdk.org/browse/JDK-8366434) fails when run with -UseCompressedOops. > > The reason for this is that the address printed as the start of the heap in the pagesize logging is not the start of the mapping. So we fail to find the mapping when scanning the SMAPS file. > > There reason why this happens is that Linux has merged the memory area for the heap with some other memory. Sometimes it is the marking bitmaps and sometimes it's just malloc that mapped some memory. > > I propose that we change the test to find the smaps memory area that contains the start address of the heap and verify that that area is THP eligible. > > I'm using BigInteger to represent the parsed addresses to skip having to deal with negative values in longs. > > Tested locally with the reproducer. I'm also testing with tier1 and the tier that found this issue. > > The fix is localized in TestTransparentHugePagesHeap.java so that it can easily be incorporated into a backport of JDK-8366434. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Early-return in contains check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27143/files - new: https://git.openjdk.org/jdk/pull/27143/files/d399416d..97187a81 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27143&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27143&range=00-01 Stats: 31 lines in 1 file changed: 12 ins; 8 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/27143.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27143/head:pull/27143 PR: https://git.openjdk.org/jdk/pull/27143 From ayang at openjdk.org Mon Sep 8 13:16:58 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 8 Sep 2025 13:16:58 GMT Subject: RFR: 8367101: Remove unused includes in cardTable.cpp Message-ID: Trivial removing unused includes. Test: tier1 ------------- Commit messages: - card-table-trivial Changes: https://git.openjdk.org/jdk/pull/27144/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27144&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367101 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27144.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27144/head:pull/27144 PR: https://git.openjdk.org/jdk/pull/27144 From stefank at openjdk.org Mon Sep 8 13:23:11 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 8 Sep 2025 13:23:11 GMT Subject: RFR: 8367101: Remove unused includes in cardTable.cpp In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 13:10:54 GMT, Albert Mingkun Yang wrote: > Trivial removing unused includes. > > Test: tier1 Looks good and I agree that this can be considered trivial (as long as it compiles in tier1). ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27144#pullrequestreview-3196510309 From aboldtch at openjdk.org Mon Sep 8 13:44:15 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 8 Sep 2025 13:44:15 GMT Subject: RFR: 8366980: TestTransparentHugePagesHeap.java fails when run with -UseCompressedOops [v2] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 13:12:46 GMT, Stefan Karlsson wrote: >> The new test TestTransparentHugePagesHeap.java added in [JDK-8366434](https://bugs.openjdk.org/browse/JDK-8366434) fails when run with -UseCompressedOops. >> >> The reason for this is that the address printed as the start of the heap in the pagesize logging is not the start of the mapping. So we fail to find the mapping when scanning the SMAPS file. >> >> There reason why this happens is that Linux has merged the memory area for the heap with some other memory. Sometimes it is the marking bitmaps and sometimes it's just malloc that mapped some memory. >> >> I propose that we change the test to find the smaps memory area that contains the start address of the heap and verify that that area is THP eligible. >> >> I'm using BigInteger to represent the parsed addresses to skip having to deal with negative values in longs. >> >> Tested locally with the reproducer. I'm also testing with tier1 and the tier that found this issue. >> >> The fix is localized in TestTransparentHugePagesHeap.java so that it can easily be incorporated into a backport of JDK-8366434. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Early-return in contains check lgtm. ------------- Marked as reviewed by aboldtch (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27143#pullrequestreview-3196611148 From jwaters at openjdk.org Mon Sep 8 13:59:18 2025 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 8 Sep 2025 13:59:18 GMT Subject: RFR: 8367025: zIndexDistributor.hpp uses angle-bracket inclusion of globalDefinitions.hpp In-Reply-To: References: Message-ID: On Sun, 7 Sep 2025 23:56:15 GMT, Guanqiang Han wrote: > trivial change No problem! :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27133#issuecomment-3266460320 From duke at openjdk.org Mon Sep 8 14:45:15 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 8 Sep 2025 14:45:15 GMT Subject: RFR: 8366881: Parallel: Obsolete HeapMaximumCompactionInterval [v2] In-Reply-To: References: Message-ID: <0rPxUVUGqNpsWYVJAbnMPAifk6vwVu5G7Zm_rXzLZio=.0e1afb81-5486-4baf-865c-a4382421381a@github.com> On Fri, 5 Sep 2025 09:30:45 GMT, Albert Mingkun Yang wrote: >> Remove a produce flag that controls maximum-compaction during a full-gc. The existing criteria, such as heap usage, old-gen density, are enough for deciding maximum-compaction. >> >> Test: tier1-3 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - review > - Merge branch 'master' into pgc-max-compaction-obsolete > - pgc-max-compaction-obsolete src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 342: > 340: // No need for max-compaction in this context. > 341: const bool should_do_max_compaction = false; > 342: PSParallelCompact::invoke(clear_all_soft_refs, should_do_max_compaction); Perhaps this might do too, without the need for an additional variable? Suggestion: PSParallelCompact::invoke(clear_all_soft_refs, false /* should_do_max_compaction */); src/hotspot/share/runtime/arguments.cpp line 571: > 569: > 570: { "PretenureSizeThreshold", JDK_Version::undefined(), JDK_Version::jdk(26), JDK_Version::jdk(27) }, > 571: { "HeapMaximumCompactionInterval",JDK_Version::undefined(), JDK_Version::jdk(26), JDK_Version::jdk(27) }, Maybe add a space? Suggestion: { "HeapMaximumCompactionInterval", JDK_Version::undefined(), JDK_Version::jdk(26), JDK_Version::jdk(27) }, ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27091#discussion_r2330468557 PR Review Comment: https://git.openjdk.org/jdk/pull/27091#discussion_r2330473880 From duke at openjdk.org Mon Sep 8 14:50:14 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 8 Sep 2025 14:50:14 GMT Subject: RFR: 8366881: Parallel: Obsolete HeapMaximumCompactionInterval [v2] In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 09:30:45 GMT, Albert Mingkun Yang wrote: >> Remove a produce flag that controls maximum-compaction during a full-gc. The existing criteria, such as heap usage, old-gen density, are enough for deciding maximum-compaction. >> >> Test: tier1-3 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - review > - Merge branch 'master' into pgc-max-compaction-obsolete > - pgc-max-compaction-obsolete src/hotspot/share/gc/parallel/psParallelCompact.cpp line 829: > 827: } > 828: > 829: bool PSParallelCompact::check_maximum_compaction(bool should_do_max_compaction, I'd expect this method not to have any side effect, does it? If that's the case, you could consider not having `should_do_max_compaction` as a parameter, and replace calls to `check_maximum_compaction` with `should_do_max_compaction || check_maximum_compaction(...)`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27091#discussion_r2330487908 From ayang at openjdk.org Mon Sep 8 14:59:13 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 8 Sep 2025 14:59:13 GMT Subject: RFR: 8366881: Parallel: Obsolete HeapMaximumCompactionInterval [v2] In-Reply-To: <0rPxUVUGqNpsWYVJAbnMPAifk6vwVu5G7Zm_rXzLZio=.0e1afb81-5486-4baf-865c-a4382421381a@github.com> References: <0rPxUVUGqNpsWYVJAbnMPAifk6vwVu5G7Zm_rXzLZio=.0e1afb81-5486-4baf-865c-a4382421381a@github.com> Message-ID: On Mon, 8 Sep 2025 14:40:28 GMT, Francesco Andreuzzi wrote: >> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - review >> - Merge branch 'master' into pgc-max-compaction-obsolete >> - pgc-max-compaction-obsolete > > src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 342: > >> 340: // No need for max-compaction in this context. >> 341: const bool should_do_max_compaction = false; >> 342: PSParallelCompact::invoke(clear_all_soft_refs, should_do_max_compaction); > > Perhaps this might do too, without the need for an additional variable? > Suggestion: > > PSParallelCompact::invoke(clear_all_soft_refs, false /* should_do_max_compaction */); True; I chose this way mostly for consistency -- `satisfy_failed_allocation` uses local var instead of comment. > src/hotspot/share/gc/parallel/psParallelCompact.cpp line 829: > >> 827: } >> 828: >> 829: bool PSParallelCompact::check_maximum_compaction(bool should_do_max_compaction, > > I'd expect this method not to have any side effect, does it? > > If that's the case, you could consider not having `should_do_max_compaction` as a parameter, and replace calls to `check_maximum_compaction` with `should_do_max_compaction || check_maximum_compaction(...)`. This method is side-effect free. I chose this style so that all criteria on deciding max-compaction are grouped in a single location. > src/hotspot/share/runtime/arguments.cpp line 571: > >> 569: >> 570: { "PretenureSizeThreshold", JDK_Version::undefined(), JDK_Version::jdk(26), JDK_Version::jdk(27) }, >> 571: { "HeapMaximumCompactionInterval",JDK_Version::undefined(), JDK_Version::jdk(26), JDK_Version::jdk(27) }, > > Maybe add a space? > Suggestion: > > { "HeapMaximumCompactionInterval", JDK_Version::undefined(), JDK_Version::jdk(26), JDK_Version::jdk(27) }, That did cross my mind. However, I went for the current version as I feel aligning with previous line (identical obsolete/expire version) is more important. WDYT? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27091#discussion_r2330489484 PR Review Comment: https://git.openjdk.org/jdk/pull/27091#discussion_r2330497252 PR Review Comment: https://git.openjdk.org/jdk/pull/27091#discussion_r2330503549 From duke at openjdk.org Mon Sep 8 15:04:28 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 8 Sep 2025 15:04:28 GMT Subject: RFR: 8366881: Parallel: Obsolete HeapMaximumCompactionInterval [v2] In-Reply-To: References: Message-ID: <5w5yRX_uPXBgAiZ-_gIfj1RG_PmM9NiDn_VcWHpapz8=.2944fcab-bc79-4b14-a6ea-0d6b440b3540@github.com> On Fri, 5 Sep 2025 09:30:45 GMT, Albert Mingkun Yang wrote: >> Remove a produce flag that controls maximum-compaction during a full-gc. The existing criteria, such as heap usage, old-gen density, are enough for deciding maximum-compaction. >> >> Test: tier1-3 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - review > - Merge branch 'master' into pgc-max-compaction-obsolete > - pgc-max-compaction-obsolete Marked as reviewed by fandreuz at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/27091#pullrequestreview-3196945742 From duke at openjdk.org Mon Sep 8 15:04:30 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 8 Sep 2025 15:04:30 GMT Subject: RFR: 8366881: Parallel: Obsolete HeapMaximumCompactionInterval [v2] In-Reply-To: References: <0rPxUVUGqNpsWYVJAbnMPAifk6vwVu5G7Zm_rXzLZio=.0e1afb81-5486-4baf-865c-a4382421381a@github.com> Message-ID: On Mon, 8 Sep 2025 14:53:16 GMT, Albert Mingkun Yang wrote: >> src/hotspot/share/runtime/arguments.cpp line 571: >> >>> 569: >>> 570: { "PretenureSizeThreshold", JDK_Version::undefined(), JDK_Version::jdk(26), JDK_Version::jdk(27) }, >>> 571: { "HeapMaximumCompactionInterval",JDK_Version::undefined(), JDK_Version::jdk(26), JDK_Version::jdk(27) }, >> >> Maybe add a space? >> Suggestion: >> >> { "HeapMaximumCompactionInterval", JDK_Version::undefined(), JDK_Version::jdk(26), JDK_Version::jdk(27) }, > > That did cross my mind. However, I went for the current version as I feel aligning with previous line (identical obsolete/expire version) is more important. > > WDYT? What I would do in this case is to make L571 look nice and adapt the alignment of L570 accordingly, but I'm not sure if there's anything about this in the style guide. Feel free to ignore the comment ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27091#discussion_r2330523844 From ayang at openjdk.org Mon Sep 8 18:29:12 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 8 Sep 2025 18:29:12 GMT Subject: RFR: 8367101: Remove unused includes in cardTable.cpp In-Reply-To: References: Message-ID: <0d3ETtlOKBivyW1IDJIY9jkTN6i1GspweEqKg8GdB30=.2f83038d-06de-406c-82a6-884d98ab9af6@github.com> On Mon, 8 Sep 2025 13:10:54 GMT, Albert Mingkun Yang wrote: > Trivial removing unused includes. > > Test: tier1 Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27144#issuecomment-3267323719 From ayang at openjdk.org Mon Sep 8 18:35:21 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 8 Sep 2025 18:35:21 GMT Subject: Integrated: 8367101: Remove unused includes in cardTable.cpp In-Reply-To: References: Message-ID: <9knxB7OCdUbQgczJ1vXjZjMcYmsw-s-Oz4JY8RC-hvI=.483cde7b-0aef-4875-a665-d3e250f80709@github.com> On Mon, 8 Sep 2025 13:10:54 GMT, Albert Mingkun Yang wrote: > Trivial removing unused includes. > > Test: tier1 This pull request has now been integrated. Changeset: 85441cec Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/85441cec3558f76ffa2a785c959397333503d556 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod 8367101: Remove unused includes in cardTable.cpp Reviewed-by: stefank ------------- PR: https://git.openjdk.org/jdk/pull/27144 From ayang at openjdk.org Mon Sep 8 19:17:17 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 8 Sep 2025 19:17:17 GMT Subject: RFR: 8366881: Parallel: Obsolete HeapMaximumCompactionInterval [v2] In-Reply-To: References: Message-ID: <3yMnY4hQ6tIgs5zhEta6LwtdHN5rarpjn_2Rp3mrizE=.c1d9efb0-a3fb-417e-972d-a6af29500e0e@github.com> On Fri, 5 Sep 2025 09:30:45 GMT, Albert Mingkun Yang wrote: >> Remove a produce flag that controls maximum-compaction during a full-gc. The existing criteria, such as heap usage, old-gen density, are enough for deciding maximum-compaction. >> >> Test: tier1-3 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - review > - Merge branch 'master' into pgc-max-compaction-obsolete > - pgc-max-compaction-obsolete Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27091#issuecomment-3267611323 From ayang at openjdk.org Mon Sep 8 19:17:18 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 8 Sep 2025 19:17:18 GMT Subject: Integrated: 8366881: Parallel: Obsolete HeapMaximumCompactionInterval In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 12:16:28 GMT, Albert Mingkun Yang wrote: > Remove a produce flag that controls maximum-compaction during a full-gc. The existing criteria, such as heap usage, old-gen density, are enough for deciding maximum-compaction. > > Test: tier1-3 This pull request has now been integrated. Changeset: 3e68d7d9 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/3e68d7d99fcf3039395ba94234ecbebe8e98c754 Stats: 57 lines in 5 files changed: 10 ins; 27 del; 20 mod 8366881: Parallel: Obsolete HeapMaximumCompactionInterval Reviewed-by: iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/27091 From duke at openjdk.org Mon Sep 8 22:52:19 2025 From: duke at openjdk.org (jonghoonpark) Date: Mon, 8 Sep 2025 22:52:19 GMT Subject: RFR: 8364927: Add @requires annotation to TestReclaimStringsLeaksMemory.java [v4] In-Reply-To: <4aT8v-HYcfSoxEEDZZWhw2JjNXxvE1WUDDsYgV7n0I8=.1aef56d4-5a50-4be3-90bf-d57e5a54118b@github.com> References: <4aT8v-HYcfSoxEEDZZWhw2JjNXxvE1WUDDsYgV7n0I8=.1aef56d4-5a50-4be3-90bf-d57e5a54118b@github.com> Message-ID: > This change updates `TestReclaimStringsLeaksMemory.java` to properly guard against unsupported GC arguments. > Previously, the test only checked `@requires vm.gc == "null"`. > > The fix separates the tests and adds explicit `@requires` clauses for each GC configuration to ensure the test only runs when supported. > > This prevents test failures on VMs that do not support the specified GC. > > (This is my first contribution to the JDK. Thank you for your review and guidance.) jonghoonpark has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge branch 'openjdk:master' into JDK-8364927-add-requires-annotation - remove non-specific GC test item and include ZGC and Shenandoah Signed-off-by: jonghoonpark - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8364927-add-requires-annotation - 8364927: Add @requires annotation to TestReclaimStringsLeaksMemory.java Signed-off-by: jonghoonpark ------------- Changes: https://git.openjdk.org/jdk/pull/26766/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26766&range=03 Stats: 46 lines in 1 file changed: 42 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26766.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26766/head:pull/26766 PR: https://git.openjdk.org/jdk/pull/26766 From dlong at openjdk.org Mon Sep 8 23:27:48 2025 From: dlong at openjdk.org (Dean Long) Date: Mon, 8 Sep 2025 23:27:48 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v5] In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 21:26:22 GMT, Dean Long wrote: >> This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value. Further, it takes a fast-path that uses the previous direct store when at a safepoint. Combined, these changes should get us back to almost where we were before in terms of overhead. If necessary, we could go even further and allow make_not_entrant() to perform a direct byte store, leaving 24 bits for the guard value. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > one unconditional release should be enough I need another review for this. Any volunteers? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26399#issuecomment-3268323422 From fyang at openjdk.org Tue Sep 9 04:09:26 2025 From: fyang at openjdk.org (Fei Yang) Date: Tue, 9 Sep 2025 04:09:26 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 09:09:49 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * sort includes > We would like to finally wrap up this PR as we are about to Propose To Target [JEP 522](openjdk.org/jeps/522) to JDK 26, so it would be nice to get re-reviews from the reviewers that already signed it off if you think it is useful. > > Nothing much changed actually for months now, particularly in the area of target-specific support, but maybe one more rerun on the more exotic platforms (AIX/PPC, RISC-V) just in case would be fine. > > Internally it went through Oracle's tier1-8 without any issue again (that is revision [b3873d6](https://github.com/openjdk/jdk/commit/b3873d66cd43518d5dc71e060fc52a13372dbfa5), but the changes since then were very cosmetic). Hi @tschatzl : I witnessed some conflicts when applying this on latest jdk head. Maybe you can do another merge and rebase? I can help rerun the tests on RISC-V. (Note that there is one failing test: `test/hotspot/jtreg/gtest/GTestWrapper.java` if I use the same base as in your repo, and that issue has been resolved by [JDK-8366897](https://bugs.openjdk.org/browse/JDK-8366897)) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3268789193 From tschatzl at openjdk.org Tue Sep 9 06:11:10 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 9 Sep 2025 06:11:10 GMT Subject: RFR: 8366980: TestTransparentHugePagesHeap.java fails when run with -UseCompressedOops [v2] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 13:12:46 GMT, Stefan Karlsson wrote: >> The new test TestTransparentHugePagesHeap.java added in [JDK-8366434](https://bugs.openjdk.org/browse/JDK-8366434) fails when run with -UseCompressedOops. >> >> The reason for this is that the address printed as the start of the heap in the pagesize logging is not the start of the mapping. So we fail to find the mapping when scanning the SMAPS file. >> >> There reason why this happens is that Linux has merged the memory area for the heap with some other memory. Sometimes it is the marking bitmaps and sometimes it's just malloc that mapped some memory. >> >> I propose that we change the test to find the smaps memory area that contains the start address of the heap and verify that that area is THP eligible. >> >> I'm using BigInteger to represent the parsed addresses to skip having to deal with negative values in longs. >> >> Tested locally with the reproducer. I'm also testing with tier1 and the tier that found this issue. >> >> The fix is localized in TestTransparentHugePagesHeap.java so that it can easily be incorporated into a backport of JDK-8366434. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Early-return in contains check Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27143#pullrequestreview-3199468894 From epeter at openjdk.org Tue Sep 9 07:49:38 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 9 Sep 2025 07:49:38 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 09:09:49 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * sort includes test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestIRMatching.java line 1489: > 1487: @Test > 1488: @IR(failOn = IRNode.ALLOC) > 1489: @IR(counts = {IRNode.COUNTED_LOOP, ">1"}) // not fail Can you explain what led to the difference? Can you also set an upper bound? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2332346985 From rcastanedalo at openjdk.org Tue Sep 9 07:55:59 2025 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Tue, 9 Sep 2025 07:55:59 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: <_sI2w99vG5BN7dhrgs-LabreQQG3r-7RaP6ejUls1_w=.ae0c7c90-87db-4136-b96f-d8b29ce8bdcf@github.com> On Mon, 8 Sep 2025 09:09:49 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * sort includes The compiler changes (including the x64 and aarch64 platform-specific code) still look good, thanks for this work! ------------- Marked as reviewed by rcastanedalo (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23739#pullrequestreview-3199884440 From aph at openjdk.org Tue Sep 9 07:58:11 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 9 Sep 2025 07:58:11 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v5] In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 21:26:22 GMT, Dean Long wrote: >> This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value. Further, it takes a fast-path that uses the previous direct store when at a safepoint. Combined, these changes should get us back to almost where we were before in terms of overhead. If necessary, we could go even further and allow make_not_entrant() to perform a direct byte store, leaving 24 bits for the guard value. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > one unconditional release should be enough That looks like a nice improvement. Thanks. ------------- Marked as reviewed by aph (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26399#pullrequestreview-3199895559 From ayang at openjdk.org Tue Sep 9 09:06:57 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 9 Sep 2025 09:06:57 GMT Subject: RFR: 8367240: Parallel: Refactor PSScavengeCLDClosure Message-ID: Refactor `PSScavengeCLDClosure` and its "enclosing" `PSScavengeFromCLDClosure` so that all CLD logic is encapsulated in the CLD closure, without polluting the oop closure. Test: tier1-3 ------------- Commit messages: - pgc-cld Changes: https://git.openjdk.org/jdk/pull/27165/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27165&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367240 Stats: 68 lines in 1 file changed: 25 ins; 36 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27165.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27165/head:pull/27165 PR: https://git.openjdk.org/jdk/pull/27165 From stefank at openjdk.org Tue Sep 9 11:01:06 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 9 Sep 2025 11:01:06 GMT Subject: RFR: 8364927: Add @requires annotation to TestReclaimStringsLeaksMemory.java [v4] In-Reply-To: References: <4aT8v-HYcfSoxEEDZZWhw2JjNXxvE1WUDDsYgV7n0I8=.1aef56d4-5a50-4be3-90bf-d57e5a54118b@github.com> Message-ID: On Mon, 8 Sep 2025 22:52:19 GMT, jonghoonpark wrote: >> This change updates `TestReclaimStringsLeaksMemory.java` to properly guard against unsupported GC arguments. >> Previously, the test only checked `@requires vm.gc == "null"`. >> >> The fix separates the tests and adds explicit `@requires` clauses for each GC configuration to ensure the test only runs when supported. >> >> This prevents test failures on VMs that do not support the specified GC. >> >> (This is my first contribution to the JDK. Thank you for your review and guidance.) > > jonghoonpark has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Merge branch 'openjdk:master' into JDK-8364927-add-requires-annotation > - remove non-specific GC test item and include ZGC and Shenandoah > > Signed-off-by: jonghoonpark > - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8364927-add-requires-annotation > - 8364927: Add @requires annotation to TestReclaimStringsLeaksMemory.java > > Signed-off-by: jonghoonpark Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26766#pullrequestreview-3200904713 From stefank at openjdk.org Tue Sep 9 11:17:56 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 9 Sep 2025 11:17:56 GMT Subject: RFR: 8367240: Parallel: Refactor PSScavengeCLDClosure In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 08:59:10 GMT, Albert Mingkun Yang wrote: > Refactor `PSScavengeCLDClosure` and its "enclosing" `PSScavengeFromCLDClosure` so that all CLD logic is encapsulated in the CLD closure, without polluting the oop closure. > > Test: tier1-3 src/hotspot/share/gc/parallel/psClosure.inline.hpp line 118: > 116: if (cld->has_modified_oops()) { > 117: // Reset before iterating oops. > 118: _oop_closure._has_oop_into_young_gen = false; I wonder if this wouldn't be cleaner if you set up a new `PSScavengeFromCLDClosure` here instead. Then you wouldn't have to explicitly reset _has_oop_into_young_gen here. if (cld->has_modified_oops()) { PSScavengeFromCLDClosure oop_closure(_pm); // Clean the cld since we're going to scavenge all the metadata. cld->oops_do(&oop_closure, ClassLoaderData::_claim_none, /*clear_modified_oops*/true); if (oop_closure.has_oops_into_young_gen()) { cld->record_modified_oops(); } } Maybe you don't have to hide `PSScavengeFromCLDClosure` inside `PSScavengeCLDClosure`. I find it more distracting that what we had before. If you don't agree with that, maybe the PSScavengeCLDClosure name could be changed so that we don't repeat the PSScavenge prefix for the internal class. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27165#discussion_r2333135554 From ayang at openjdk.org Tue Sep 9 11:48:03 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 9 Sep 2025 11:48:03 GMT Subject: RFR: 8367240: Parallel: Refactor PSScavengeCLDClosure [v2] In-Reply-To: References: Message-ID: <41Ln879m04odKDVXftHaxlhPMI5S5hKQGHQ3MbFS-bM=.53bbbeda-95ac-46ef-aba3-93048bc3e690@github.com> On Tue, 9 Sep 2025 11:15:15 GMT, Stefan Karlsson wrote: >> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> review > > src/hotspot/share/gc/parallel/psClosure.inline.hpp line 118: > >> 116: if (cld->has_modified_oops()) { >> 117: // Reset before iterating oops. >> 118: _oop_closure._has_oop_into_young_gen = false; > > I wonder if this wouldn't be cleaner if you set up a new `PSScavengeFromCLDClosure` here instead. Then you wouldn't have to explicitly reset _has_oop_into_young_gen here. > > if (cld->has_modified_oops()) { > PSScavengeFromCLDClosure oop_closure(_pm); > > // Clean the cld since we're going to scavenge all the metadata. > cld->oops_do(&oop_closure, ClassLoaderData::_claim_none, /*clear_modified_oops*/true); > > if (oop_closure.has_oops_into_young_gen()) { > cld->record_modified_oops(); > } > } > > > Maybe you don't have to hide `PSScavengeFromCLDClosure` inside `PSScavengeCLDClosure`. I find it more distracting that what we had before. If you don't agree with that, maybe the PSScavengeCLDClosure name could be changed so that we don't repeat the PSScavenge prefix for the internal class. I have simplified the class name and moved it inside the `do_cld` method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27165#discussion_r2333211266 From ayang at openjdk.org Tue Sep 9 11:48:01 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 9 Sep 2025 11:48:01 GMT Subject: RFR: 8367240: Parallel: Refactor PSScavengeCLDClosure [v2] In-Reply-To: References: Message-ID: > Refactor `PSScavengeCLDClosure` and its "enclosing" `PSScavengeFromCLDClosure` so that all CLD logic is encapsulated in the CLD closure, without polluting the oop closure. > > Test: tier1-3 Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27165/files - new: https://git.openjdk.org/jdk/pull/27165/files/79c03184..33fb3332 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27165&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27165&range=00-01 Stats: 67 lines in 1 file changed: 28 ins; 28 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/27165.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27165/head:pull/27165 PR: https://git.openjdk.org/jdk/pull/27165 From tschatzl at openjdk.org Tue Sep 9 13:36:27 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 9 Sep 2025 13:36:27 GMT Subject: RFR: 8352969: G1: Improve testability of optional collections [v7] In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 15:38:18 GMT, Guanqiang Han wrote: >> This PR introduces a new diagnostic flag EvacuateAllOptionalRegions to force G1 GC to evacuate all optional regions regardless of the predicted pause time. The motivation is to allow testing and validation of optional region evacuation behavior without being constrained by the remaining pause time. > > Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - change flag name > - Merge remote-tracking branch 'upstream/master' into 8352969 > - fix format error > - format fix > - Optimize implementation and add regression test > - Merge remote-tracking branch 'upstream/master' into 8352969 > - Update g1YoungCollector.cpp > > format fix > - Simplified implementation > - add default value > - Implement JDK-8352969 Changes requested by tschatzl (Reviewer). src/hotspot/share/gc/g1/g1CollectionSet.cpp line 407: > 405: G1CSetCandidateGroupList* from_marking_groups = &candidates()->from_marking_groups(); > 406: > 407: #ifndef PRODUCT The correct ifdef to use is `#ifdef ASSERT` for `develop` flags. The `optimized` build (actually not sure it still exists) does not define either PRODUCT or ASSERT src/hotspot/share/gc/g1/g1CollectionSet.cpp line 408: > 406: > 407: #ifndef PRODUCT > 408: bool add_at_least_one_optional_region = G1EvacuateAllOptionalRegions; Maybe: Suggestion: bool make_first_group_optional = G1EvacuateAllOptionalRegions; src/hotspot/share/gc/g1/g1CollectionSet.cpp line 431: > 429: _optional_groups.append(group); > 430: prepare_optional_group(group, num_optional_regions); > 431: num_optional_regions += group->length(); Please factor out this code with the one below adding optional groups. This also seems to be missing the timing update. src/hotspot/share/gc/g1/g1CollectionSet.cpp line 666: > 664: if (G1EvacuateAllOptionalRegions && num_regions_selected == optional_regions_count) { > 665: log_debug(gc, ergo, cset)("All optional regions are scheduled to be evacuated"); > 666: } Isn't it that "all selected regions are optional regions"? I am not sure we need this message, this content can be deduced from above. I understand that it is easier to check for in the test, but doing a regexp and comparing the values is only slightly more complicated imo. src/hotspot/share/gc/g1/g1_globals.hpp line 375: > 373: develop(bool, G1EvacuateAllOptionalRegions, false, \ > 374: "Force to evacuate all optional regions.") \ > 375: \ Suggestion: develop(bool, G1ForceOptionalEvacuation, false, \ "Force optional evacuation for all GCs where there are old gen collection set candidates. Also schedule all available optional groups for evacuation regardless of timing.") \ \ (Please distribute the new comment properly over multiple lines) I think we should move away from optional "regions" because the unit of evacuation is always groups now (even if they only contain one region). test/hotspot/jtreg/gc/g1/TestOptionalRegionGC.java line 27: > 25: * @bug 8352969 > 26: * @summary Verify that the G1EvacuateAllOptionalRegions flag forces G1 > 27: * to evacuate all of optional regions, improving testability. Suggestion: * @summary Verify that the G1EvacuateAllOptionalRegions flag forces G1 * to evacuate all of optional regions. Or just: "Tests optional evacuation." For the same reasons as indicated for the flag name, it should not contain the term "regions". test/hotspot/jtreg/gc/g1/TestOptionalRegionGC.java line 56: > 54: "-XX:+UseG1GC", > 55: "-XX:MaxTenuringThreshold=1", > 56: "-Xlog:gc+ergo+cset=trace", I would add a `-XX:+VerifyAfterGC` here to make sure the optional evacuation leaves the heap in a correct state. test/hotspot/jtreg/gc/g1/TestOptionalRegionGC.java line 85: > 83: wb.youngGC(); > 84: // Clear certain references for mixed GC. > 85: for (int i = 0; i < NUM_OBJECTS; i=i+2) { Suggestion: for (int i = 0; i < NUM_OBJECTS; i+=2) { (Or just spaces about the operator and `=`) ------------- PR Review: https://git.openjdk.org/jdk/pull/26880#pullrequestreview-3201495820 PR Review Comment: https://git.openjdk.org/jdk/pull/26880#discussion_r2333529097 PR Review Comment: https://git.openjdk.org/jdk/pull/26880#discussion_r2333592238 PR Review Comment: https://git.openjdk.org/jdk/pull/26880#discussion_r2333537363 PR Review Comment: https://git.openjdk.org/jdk/pull/26880#discussion_r2333542748 PR Review Comment: https://git.openjdk.org/jdk/pull/26880#discussion_r2333616489 PR Review Comment: https://git.openjdk.org/jdk/pull/26880#discussion_r2333559784 PR Review Comment: https://git.openjdk.org/jdk/pull/26880#discussion_r2333563725 PR Review Comment: https://git.openjdk.org/jdk/pull/26880#discussion_r2333571110 From tschatzl at openjdk.org Tue Sep 9 13:36:29 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 9 Sep 2025 13:36:29 GMT Subject: RFR: 8352969: G1: Improve testability of optional collections [v7] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 13:17:24 GMT, Thomas Schatzl wrote: >> Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: >> >> - change flag name >> - Merge remote-tracking branch 'upstream/master' into 8352969 >> - fix format error >> - format fix >> - Optimize implementation and add regression test >> - Merge remote-tracking branch 'upstream/master' into 8352969 >> - Update g1YoungCollector.cpp >> >> format fix >> - Simplified implementation >> - add default value >> - Implement JDK-8352969 > > test/hotspot/jtreg/gc/g1/TestOptionalRegionGC.java line 56: > >> 54: "-XX:+UseG1GC", >> 55: "-XX:MaxTenuringThreshold=1", >> 56: "-Xlog:gc+ergo+cset=trace", > > I would add a `-XX:+VerifyAfterGC` here to make sure the optional evacuation leaves the heap in a correct state. If you are concerned, only do the verification after mixed gc, i.e. add `-XX:VerifyGCType=mixed`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26880#discussion_r2333634492 From mdoerr at openjdk.org Tue Sep 9 14:06:25 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 9 Sep 2025 14:06:25 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: <3t1NXG7f_TsOxvst83-A9dDPQ9ZOyl5ybNJDtpkhvAk=.671d5ae9-e32c-42de-a519-f52929495100@github.com> On Mon, 8 Sep 2025 09:09:49 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * sort includes Still works fine on SAP supported platforms (including PPC64). @RealFYang: Three way merge succeded. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3270891086 From stefank at openjdk.org Tue Sep 9 15:20:05 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 9 Sep 2025 15:20:05 GMT Subject: RFR: 8367240: Parallel: Refactor PSScavengeCLDClosure [v2] In-Reply-To: References: Message-ID: <0IndBYRCJCMty8rL5azwcymuZLSF7z7eE-9CHhpMbe0=.041e0770-9b43-425a-8c62-d185caf79346@github.com> On Tue, 9 Sep 2025 11:48:01 GMT, Albert Mingkun Yang wrote: >> Refactor `PSScavengeCLDClosure` and its "enclosing" `PSScavengeFromCLDClosure` so that all CLD logic is encapsulated in the CLD closure, without polluting the oop closure. >> >> Test: tier1-3 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Changes requested by stefank (Reviewer). src/hotspot/share/gc/parallel/psClosure.inline.hpp line 94: > 92: > 93: // Scavenges a single oop in a ClassLoaderData. > 94: class CLDOopClosure : public OopClosure { This makes the do_cld function much harder to read, IMHO. So, three alternatives: 1) Keep the class outside PSScavengeCLDClosure, just like it was before this patch. 2) Have the class inside PSScavengeCLDClosure, but not in a function 3) Have the class inside a function inside PSScavengeCLDClosure. I prefer (1) because it allows you to look at PSScavengeCLDClosure without having to see the details about the second class. I'm OK with (2) and like that it encapsulates the other class. I don't think we should do (3) because it significantly hurts the readability of do_cld. src/hotspot/share/gc/parallel/psClosure.inline.hpp line 99: > 97: public: > 98: // Records whether this CLD contains oops pointing into young-gen after scavenging. > 99: bool _has_oop_into_young_gen; Comment says oops but name says oop. Maybe use _has_oops_into_young_gen? ------------- PR Review: https://git.openjdk.org/jdk/pull/27165#pullrequestreview-3202095030 PR Review Comment: https://git.openjdk.org/jdk/pull/27165#discussion_r2333984554 PR Review Comment: https://git.openjdk.org/jdk/pull/27165#discussion_r2333965840 From ayang at openjdk.org Tue Sep 9 15:28:12 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 9 Sep 2025 15:28:12 GMT Subject: RFR: 8367240: Parallel: Refactor PSScavengeCLDClosure [v3] In-Reply-To: References: Message-ID: > Refactor `PSScavengeCLDClosure` and its "enclosing" `PSScavengeFromCLDClosure` so that all CLD logic is encapsulated in the CLD closure, without polluting the oop closure. > > Test: tier1-3 Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - review - Merge branch 'master' into pgc-cld - review - pgc-cld ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27165/files - new: https://git.openjdk.org/jdk/pull/27165/files/33fb3332..836002b8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27165&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27165&range=01-02 Stats: 568 lines in 27 files changed: 356 ins; 144 del; 68 mod Patch: https://git.openjdk.org/jdk/pull/27165.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27165/head:pull/27165 PR: https://git.openjdk.org/jdk/pull/27165 From ayang at openjdk.org Tue Sep 9 15:28:15 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 9 Sep 2025 15:28:15 GMT Subject: RFR: 8367240: Parallel: Refactor PSScavengeCLDClosure [v2] In-Reply-To: <0IndBYRCJCMty8rL5azwcymuZLSF7z7eE-9CHhpMbe0=.041e0770-9b43-425a-8c62-d185caf79346@github.com> References: <0IndBYRCJCMty8rL5azwcymuZLSF7z7eE-9CHhpMbe0=.041e0770-9b43-425a-8c62-d185caf79346@github.com> Message-ID: On Tue, 9 Sep 2025 15:16:55 GMT, Stefan Karlsson wrote: >> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> review > > src/hotspot/share/gc/parallel/psClosure.inline.hpp line 94: > >> 92: >> 93: // Scavenges a single oop in a ClassLoaderData. >> 94: class CLDOopClosure : public OopClosure { > > This makes the do_cld function much harder to read, IMHO. So, three alternatives: > 1) Keep the class outside PSScavengeCLDClosure, just like it was before this patch. > 2) Have the class inside PSScavengeCLDClosure, but not in a function > 3) Have the class inside a function inside PSScavengeCLDClosure. > > I prefer (1) because it allows you to look at PSScavengeCLDClosure without having to see the details about the second class. I'm OK with (2) and like that it encapsulates the other class. I don't think we should do (3) because it significantly hurts the readability of do_cld. I have moved the oop-closure class def outside. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27165#discussion_r2334009517 From stefank at openjdk.org Tue Sep 9 15:44:27 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 9 Sep 2025 15:44:27 GMT Subject: RFR: 8367240: Parallel: Refactor PSScavengeCLDClosure [v3] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 15:28:12 GMT, Albert Mingkun Yang wrote: >> Refactor `PSScavengeCLDClosure` and its "enclosing" `PSScavengeFromCLDClosure` so that all CLD logic is encapsulated in the CLD closure, without polluting the oop closure. >> >> Test: tier1-3 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - review > - Merge branch 'master' into pgc-cld > - review > - pgc-cld Thanks for fixing the style. I've added two small nits, but otherwise I've approved the PR. src/hotspot/share/gc/parallel/psClosure.inline.hpp line 80: > 78: typedef PSRootsClosure PSPromoteRootsClosure; > 79: > 80: Suggestion: src/hotspot/share/gc/parallel/psClosure.inline.hpp line 111: > 109: // Scavenges the oop in a ClassLoaderData. > 110: class PSScavengeCLDClosure: public CLDClosure { > 111: PSPromotionManager* _pm; To make the two classes consistent w.r.t. newlines. Suggestion: PSPromotionManager* _pm; ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27165#pullrequestreview-3202203055 PR Review Comment: https://git.openjdk.org/jdk/pull/27165#discussion_r2334042227 PR Review Comment: https://git.openjdk.org/jdk/pull/27165#discussion_r2334050782 From ayang at openjdk.org Tue Sep 9 15:49:51 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 9 Sep 2025 15:49:51 GMT Subject: RFR: 8367240: Parallel: Refactor PSScavengeCLDClosure [v4] In-Reply-To: References: Message-ID: > Refactor `PSScavengeCLDClosure` and its "enclosing" `PSScavengeFromCLDClosure` so that all CLD logic is encapsulated in the CLD closure, without polluting the oop closure. > > Test: tier1-3 Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27165/files - new: https://git.openjdk.org/jdk/pull/27165/files/836002b8..0b3f6136 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27165&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27165&range=02-03 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27165.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27165/head:pull/27165 PR: https://git.openjdk.org/jdk/pull/27165 From stefank at openjdk.org Tue Sep 9 15:54:33 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 9 Sep 2025 15:54:33 GMT Subject: RFR: 8367240: Parallel: Refactor PSScavengeCLDClosure [v4] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 15:49:51 GMT, Albert Mingkun Yang wrote: >> Refactor `PSScavengeCLDClosure` and its "enclosing" `PSScavengeFromCLDClosure` so that all CLD logic is encapsulated in the CLD closure, without polluting the oop closure. >> >> Test: tier1-3 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27165#pullrequestreview-3202268260 From mark.reinhold at oracle.com Tue Sep 9 17:30:55 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Tue, 9 Sep 2025 17:30:55 +0000 Subject: New candidate JEP: 523: Make G1 the Default Garbage Collector in All Environments Message-ID: <20250909172959.EF26F2A0@naskeag.niobe.net> https://openjdk.org/jeps/523 Summary: Make the Garbage-First (G1) garbage collector the default collector in all environments, rather than just server environments. - Mark From eosterlund at openjdk.org Tue Sep 9 19:37:31 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 9 Sep 2025 19:37:31 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v5] In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 21:26:22 GMT, Dean Long wrote: >> This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value. Further, it takes a fast-path that uses the previous direct store when at a safepoint. Combined, these changes should get us back to almost where we were before in terms of overhead. If necessary, we could go even further and allow make_not_entrant() to perform a direct byte store, leaving 24 bits for the guard value. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > one unconditional release should be enough Sorry for the delay. Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26399#pullrequestreview-3203004583 From kdnilsen at openjdk.org Tue Sep 9 20:05:02 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 9 Sep 2025 20:05:02 GMT Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in ShenandoahFreeSet Message-ID: This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet. In the new code, we keep a single tally of relevant information within ShenandoahFreeSet. Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet. This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies. These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms. The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books. ------------- Commit messages: - Fix ShenandoahAllocationRate::sample() and remove debug scaffolding - Remove debug instrumentation - Cleanup make_all_regions_unavailable() - Remove RENAISSANCE debugging instrumentation - Replace MEMORY_USAGE debugging with assertions - Zero [empty_]region_counts in make_all_regions_unavailable plus lots of debug instrumentation - fix white space - more fixes to pip accounting - Fix accounting for pip regions - Initialize _mutator_bytes_allocated_since_gc-start - ... and 102 more: https://git.openjdk.org/jdk/compare/05da2137...87e26b37 Changes: https://git.openjdk.org/jdk/pull/26867/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365880 Stats: 3113 lines in 35 files changed: 1977 ins; 542 del; 594 mod Patch: https://git.openjdk.org/jdk/pull/26867.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26867/head:pull/26867 PR: https://git.openjdk.org/jdk/pull/26867 From kdnilsen at openjdk.org Tue Sep 9 21:02:15 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 9 Sep 2025 21:02:15 GMT Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in ShenandoahFreeSet In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 19:17:48 GMT, Kelvin Nilsen wrote: > This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet. In the new code, we keep a single tally of relevant information within ShenandoahFreeSet. > Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet. > > This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies. These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms. > > The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books. This code now passes all internal CI tests. The attached shows some performance results on a SpecJBB workload for Generational Shenandoah and Traditional Shenandoah. We see general improvements. This presumably results from not having to maintain two synchronization mechanisms for two separate sets of "books". Screenshot 2025-09-09 at 1 53 53?PM Screenshot 2025-09-09 at 1 55 06?PM We also see general improvement running an Extremem workload. Screenshot 2025-09-09 at 1 56 02?PM Analysis of these results has revealed a shortcoming in the Generational version of Final Update Refs safepoint, which accounts for the higher p99.999 and p100 latencies of GenShen compared to Shen. In a separate PR, we will be moving the Flush SATB buffer action out of the safepoint, performing this work in a handshake instead. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26867#issuecomment-3272248200 From kdnilsen at openjdk.org Tue Sep 9 21:10:01 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 9 Sep 2025 21:10:01 GMT Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in ShenandoahFreeSet [v2] In-Reply-To: References: Message-ID: > This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet. In the new code, we keep a single tally of relevant information within ShenandoahFreeSet. > Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet. > > This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies. These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms. > > The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Add include file for missing declaration ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26867/files - new: https://git.openjdk.org/jdk/pull/26867/files/87e26b37..a77eb75d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26867.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26867/head:pull/26867 PR: https://git.openjdk.org/jdk/pull/26867 From kdnilsen at openjdk.org Tue Sep 9 22:07:11 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 9 Sep 2025 22:07:11 GMT Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in ShenandoahFreeSet [v3] In-Reply-To: References: Message-ID: > This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet. In the new code, we keep a single tally of relevant information within ShenandoahFreeSet. > Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet. > > This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies. These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms. > > The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: another tweak to make GHA gtest happy ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26867/files - new: https://git.openjdk.org/jdk/pull/26867/files/a77eb75d..cd9522af Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=01-02 Stats: 9 lines in 1 file changed: 0 ins; 1 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/26867.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26867/head:pull/26867 PR: https://git.openjdk.org/jdk/pull/26867 From wkemper at openjdk.org Tue Sep 9 22:09:02 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 9 Sep 2025 22:09:02 GMT Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may raise threshold prematurely [v5] In-Reply-To: References: Message-ID: > The adaptive tenuring algorithm has been modified to begin its evaluation of mortality rates from the current tenuring threshold. To compliment this change, objects must also now be strictly above the tenuring threshold to be promoted (instead of greater-than-or-equal). William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision: - Fix include order - Add missing newline - Fix typo - Merge tag 'jdk-26+14' into adaptive-tenuring-threshold Added tag jdk-26+14 for changeset ab9f70dd - Do not require objects to be strictly older than the tenuring threshold - Log updated tenuring age at info, log age table at debug - Be consistent when comparing tenuring threshold with ages - Fix windows build - Fix release build - Revert unintended change - ... and 10 more: https://git.openjdk.org/jdk/compare/557d3a94...0ffa89c5 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26906/files - new: https://git.openjdk.org/jdk/pull/26906/files/658f76f7..0ffa89c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26906&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26906&range=03-04 Stats: 24118 lines in 1089 files changed: 16766 ins; 3687 del; 3665 mod Patch: https://git.openjdk.org/jdk/pull/26906.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26906/head:pull/26906 PR: https://git.openjdk.org/jdk/pull/26906 From wkemper at openjdk.org Tue Sep 9 22:09:04 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 9 Sep 2025 22:09:04 GMT Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may raise threshold prematurely [v3] In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 01:06:19 GMT, Y. Srinivas Ramakrishna wrote: >> William Kemper has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix windows build > > Also, are there any comparative performance numbers to share yet? @ysramakrishna - no appreciable changes in our performance benchmarks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26906#issuecomment-3272425061 From kdnilsen at openjdk.org Tue Sep 9 22:34:33 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 9 Sep 2025 22:34:33 GMT Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may raise threshold prematurely [v5] In-Reply-To: References: Message-ID: <6-E3njfrTUmO1C2fV6L9OFG2av0Ct5bpf8gvjcwAPyo=.a3847570-8ccf-4871-9abc-6c264718d70e@github.com> On Tue, 9 Sep 2025 22:09:02 GMT, William Kemper wrote: >> The adaptive tenuring algorithm has been modified to begin its evaluation of mortality rates from the current tenuring threshold. To compliment this change, objects must also now be strictly above the tenuring threshold to be promoted (instead of greater-than-or-equal). > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision: > > - Fix include order > - Add missing newline > - Fix typo > - Merge tag 'jdk-26+14' into adaptive-tenuring-threshold > > Added tag jdk-26+14 for changeset ab9f70dd > - Do not require objects to be strictly older than the tenuring threshold > - Log updated tenuring age at info, log age table at debug > - Be consistent when comparing tenuring threshold with ages > - Fix windows build > - Fix release build > - Revert unintended change > - ... and 10 more: https://git.openjdk.org/jdk/compare/2b231502...0ffa89c5 Thanks for chasing down the performance regression. Looks good. src/hotspot/share/gc/shenandoah/shenandoahAgeCensus.hpp line 186: > 184: > 185: // Return true if this age is at or above the tenuring threshold. > 186: bool is_tenurable(uint age) const { might want to mark this as inline. (if in-lined, this might be the right way to check whether individual objects should be promoted. But I don't want to delay integration of this PR, so maybe that could be done in a different PR if we think it worthwhile.) ------------- Marked as reviewed by kdnilsen (Committer). PR Review: https://git.openjdk.org/jdk/pull/26906#pullrequestreview-3203541920 PR Review Comment: https://git.openjdk.org/jdk/pull/26906#discussion_r2334950649 From kdnilsen at openjdk.org Tue Sep 9 22:34:34 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 9 Sep 2025 22:34:34 GMT Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may raise threshold prematurely [v5] In-Reply-To: <6-E3njfrTUmO1C2fV6L9OFG2av0Ct5bpf8gvjcwAPyo=.a3847570-8ccf-4871-9abc-6c264718d70e@github.com> References: <6-E3njfrTUmO1C2fV6L9OFG2av0Ct5bpf8gvjcwAPyo=.a3847570-8ccf-4871-9abc-6c264718d70e@github.com> Message-ID: On Tue, 9 Sep 2025 22:24:41 GMT, Kelvin Nilsen wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision: >> >> - Fix include order >> - Add missing newline >> - Fix typo >> - Merge tag 'jdk-26+14' into adaptive-tenuring-threshold >> >> Added tag jdk-26+14 for changeset ab9f70dd >> - Do not require objects to be strictly older than the tenuring threshold >> - Log updated tenuring age at info, log age table at debug >> - Be consistent when comparing tenuring threshold with ages >> - Fix windows build >> - Fix release build >> - Revert unintended change >> - ... and 10 more: https://git.openjdk.org/jdk/compare/2b231502...0ffa89c5 > > src/hotspot/share/gc/shenandoah/shenandoahAgeCensus.hpp line 186: > >> 184: >> 185: // Return true if this age is at or above the tenuring threshold. >> 186: bool is_tenurable(uint age) const { > > might want to mark this as inline. (if in-lined, this might be the right way to check whether individual objects should be promoted. But I don't want to delay integration of this PR, so maybe that could be done in a different PR if we think it worthwhile.) Ok. I see that ShenandoahGenerationalHeap::is_tenurable() is in-lined. That's probably the one that matters the most. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26906#discussion_r2334963712 From dlong at openjdk.org Tue Sep 9 23:31:01 2025 From: dlong at openjdk.org (Dean Long) Date: Tue, 9 Sep 2025 23:31:01 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v5] In-Reply-To: <-MqvO74Up2R0qmEDtgyGY-yScxZ-v6ZQWxDtSxpKO_g=.56d4eeca-670d-41e4-9e96-ba20b1b44100@github.com> References: <-MqvO74Up2R0qmEDtgyGY-yScxZ-v6ZQWxDtSxpKO_g=.56d4eeca-670d-41e4-9e96-ba20b1b44100@github.com> Message-ID: On Wed, 27 Aug 2025 20:17:07 GMT, Erik ?sterlund wrote: >> @fisk , can I get you to review this? > >> @fisk , can I get you to review this? > > Sure! Based on the symptoms you described, my main comment is that we might be looking at the wrong places. I don't know if this is really about lock contention. Perhaps it is indirectly. But you mention there is still so e regression with ZGC. > > My hypothesis would be that it is the unnecessary incrementing of the global patching epoch that causes the regression when using ZGC. It is only really needed when disarming the nmethod - in orher words when the guard value is set to the good value. > > The point of incrementing the patching epoch is to protect other threads from entering the nmethod without executing an instruction cross modication fence. And all other threads will have to do that. > > Only ZGC uses the mode of nmethod entry barriers that does this due to being the only GC that updates instructions in a concurrent phase on AArch64. We are conservative on AArch64 and ensure the use of appropriate synchronous cross modifying code. But that's not needed when arming, which is what we do when making the bmethod not entrant. Thanks @fisk and @theRealAph . ------------- PR Comment: https://git.openjdk.org/jdk/pull/26399#issuecomment-3272594352 From dlong at openjdk.org Tue Sep 9 23:31:03 2025 From: dlong at openjdk.org (Dean Long) Date: Tue, 9 Sep 2025 23:31:03 GMT Subject: Integrated: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 In-Reply-To: References: Message-ID: On Sat, 19 Jul 2025 01:39:12 GMT, Dean Long wrote: > This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value. Further, it takes a fast-path that uses the previous direct store when at a safepoint. Combined, these changes should get us back to almost where we were before in terms of overhead. If necessary, we could go even further and allow make_not_entrant() to perform a direct byte store, leaving 24 bits for the guard value. This pull request has now been integrated. Changeset: f9640398 Author: Dean Long URL: https://git.openjdk.org/jdk/commit/f96403986b99008593e025c4991ee865fce59bb1 Stats: 240 lines in 15 files changed: 128 ins; 71 del; 41 mod 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 Co-authored-by: Martin Doerr Reviewed-by: mdoerr, aph, eosterlund ------------- PR: https://git.openjdk.org/jdk/pull/26399 From wkemper at openjdk.org Tue Sep 9 23:48:14 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 9 Sep 2025 23:48:14 GMT Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may raise threshold prematurely [v5] In-Reply-To: References: <6-E3njfrTUmO1C2fV6L9OFG2av0Ct5bpf8gvjcwAPyo=.a3847570-8ccf-4871-9abc-6c264718d70e@github.com> Message-ID: On Tue, 9 Sep 2025 22:31:19 GMT, Kelvin Nilsen wrote: >> src/hotspot/share/gc/shenandoah/shenandoahAgeCensus.hpp line 186: >> >>> 184: >>> 185: // Return true if this age is at or above the tenuring threshold. >>> 186: bool is_tenurable(uint age) const { >> >> might want to mark this as inline. (if in-lined, this might be the right way to check whether individual objects should be promoted. But I don't want to delay integration of this PR, so maybe that could be done in a different PR if we think it worthwhile.) > > Ok. I see that ShenandoahGenerationalHeap::is_tenurable() is in-lined. That's probably the one that matters the most. Anything defined in the header is implicitly inlined. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26906#discussion_r2335110857 From dholmes at openjdk.org Wed Sep 10 05:45:11 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 10 Sep 2025 05:45:11 GMT Subject: RFR: 8366328: G1: Crash on reading os::thread_cpu_time In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 07:48:11 GMT, Ivan Walulya wrote: > Hi, > > Please review this patch to ensure that we do not attempt to read CPU time for GC threads that have already been terminated. > > Testing: Tier 1-3. Can you not use `VMThread::is_terminated()` to check for shutdown? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27087#issuecomment-3273397170 From aboldtch at openjdk.org Wed Sep 10 06:05:47 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 10 Sep 2025 06:05:47 GMT Subject: RFR: 8367298: ZGC: Enhance zaddress type system's assert messages Message-ID: ZGC uses a family of strongly type integral types to test and verify invariants for addresses, offset, indices and colored pointers within the heap. It is usually the first place we hit an assert if something goes wrong, and looking at the actual value is often enough to identify if it is memory corruption, a broken color invariant or a mistake in the use of the type system. Unfortunately not all asserts print the value in the assert message, requiring more extensive investigation to even identify the nature of the problem. I propose we enhance all our zaddress assert printing to always include the invariant breaking value. _While I chose to print the max values in the assert message of the offset and indices checks, I did not print the colors in the zpointer checks. Both colors and the max values are easily available in the error report, so it would only really be a problem if a hs_err file is missing._ We should probably also see if we can enhance all the rest of our asserts in ZGC similarly. I do not think I have ever seen a failed invariant check and thought "Why are we printing the invariant breaking value", but often feel that it is unfortunate that we did not print the actual value. ------------- Commit messages: - 8367298: ZGC: Enhance zaddress type system's assert messages Changes: https://git.openjdk.org/jdk/pull/27184/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27184&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367298 Stats: 19 lines in 1 file changed: 0 ins; 0 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/27184.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27184/head:pull/27184 PR: https://git.openjdk.org/jdk/pull/27184 From fyang at openjdk.org Wed Sep 10 07:35:02 2025 From: fyang at openjdk.org (Fei Yang) Date: Wed, 10 Sep 2025 07:35:02 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 09:09:49 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * sort includes Just FYI: My local tier1-tier3 tests on linux-riscv64 platform are still good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3273695581 From tschatzl at openjdk.org Wed Sep 10 07:56:42 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 07:56:42 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v55] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 74 commits: - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * iwalulya: remove confusing comment - * sort includes - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * improve logging for refinement, making it similar to marking logging - * commit merge changes - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * fix merge error - * forgot to actually save the files - Merge branch 'master' into 8342382-card-table-instead-of-dcq - ... and 64 more: https://git.openjdk.org/jdk/compare/9e3fa321...e7c3a067 ------------- Changes: https://git.openjdk.org/jdk/pull/23739/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=54 Stats: 7114 lines in 112 files changed: 2590 ins; 3583 del; 941 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From tschatzl at openjdk.org Wed Sep 10 07:56:44 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 07:56:44 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 09:47:10 GMT, Thomas Schatzl wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * sort includes > > We would like to finally wrap up this PR as we are about to Propose To Target [JEP 522](openjdk.org/jeps/522) to JDK 26, so it would be nice to get re-reviews from the reviewers that already signed it off if you think it is useful. > > Nothing much changed actually for months now, particularly in the area of target-specific support, but maybe one more rerun on the more exotic platforms (AIX/PPC, RISC-V) just in case would be fine. > > Internally it went through Oracle's tier1-8 without any issue again (that is revision https://github.com/openjdk/jdk/pull/23739/commits/b3873d66cd43518d5dc71e060fc52a13372dbfa5, but the changes since then were very cosmetic). > Hi @tschatzl : I witnessed some conflicts when applying this on latest jdk head. Maybe you can do another merge and rebase? I can help rerun the tests on RISC-V. (Note that there is one failing test: `test/hotspot/jtreg/gtest/GTestWrapper.java` if I use the same base as in your repo, and that issue has been resolved by [JDK-8366897](https://bugs.openjdk.org/browse/JDK-8366897)) Merged. Thanks for another round of testing (also to @TheRealMDoerr). ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3273765120 From iwalulya at openjdk.org Wed Sep 10 08:01:00 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 10 Sep 2025 08:01:00 GMT Subject: RFR: 8366328: G1: Crash on reading os::thread_cpu_time In-Reply-To: References: Message-ID: <-GY3zWT-Xjc7Utjyf20sdI5WuWtNXkjivZOcSQAPhOY=.9188b968-d9e4-45df-9237-96c74d30b46f@github.com> On Wed, 10 Sep 2025 05:42:50 GMT, David Holmes wrote: > Can you not use VMThread::is_terminated() to check for shutdown? `before_exit(thread)` happens before `VMThread::wait_for_vm_thread_exit();` which sets the `_is_terminated`, so it too late since we terminate the concurrent GC threads at `before_exit`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27087#issuecomment-3273777897 From tschatzl at openjdk.org Wed Sep 10 08:21:59 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 08:21:59 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 07:47:00 GMT, Emanuel Peter wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * sort includes > > test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestIRMatching.java line 1489: > >> 1487: @Test >> 1488: @IR(failOn = IRNode.ALLOC) >> 1489: @IR(counts = {IRNode.COUNTED_LOOP, ">1"}) // not fail > > Can you explain what led to the difference? Can you also set an upper bound? With the decreased complexity of the barrier, C2 started unrolling that loop. I do not know how to determine a bound here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2335959266 From epeter at openjdk.org Wed Sep 10 08:31:57 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 10 Sep 2025 08:31:57 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 08:19:15 GMT, Thomas Schatzl wrote: >> test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestIRMatching.java line 1489: >> >>> 1487: @Test >>> 1488: @IR(failOn = IRNode.ALLOC) >>> 1489: @IR(counts = {IRNode.COUNTED_LOOP, ">1"}) // not fail >> >> Can you explain what led to the difference? Can you also set an upper bound? > > With the decreased complexity of the barrier, C2 started unrolling that loop. I do not know how to determine a bound here. Is this going to be GC independent? What if the VM swaps to another GC ergonomically? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2335985122 From chagedorn at openjdk.org Wed Sep 10 08:58:52 2025 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Wed, 10 Sep 2025 08:58:52 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 08:28:26 GMT, Emanuel Peter wrote: >> With the decreased complexity of the barrier, C2 started unrolling that loop. I do not know how to determine a bound here. > > Is this going to be GC independent? What if the VM swaps to another GC ergonomically? The test runs with `vm.flagless`. But I suggest to just go with `>= 1` instead to be on the safe side. The purpose of this IR rule in the context of this test is really just that it does not fail and not about catching real issues/verifying the IR. If we still want to test the improved loop unrolling opportunities, I suggest to create a separate IR test for it, possibly in a separate RFE. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2336052099 From amitkumar at openjdk.org Wed Sep 10 09:22:33 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 10 Sep 2025 09:22:33 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 07:53:15 GMT, Thomas Schatzl wrote: >> We would like to finally wrap up this PR as we are about to Propose To Target [JEP 522](openjdk.org/jeps/522) to JDK 26, so it would be nice to get re-reviews from the reviewers that already signed it off if you think it is useful. >> >> Nothing much changed actually for months now, particularly in the area of target-specific support, but maybe one more rerun on the more exotic platforms (AIX/PPC, RISC-V) just in case would be fine. >> >> Internally it went through Oracle's tier1-8 without any issue again (that is revision https://github.com/openjdk/jdk/pull/23739/commits/b3873d66cd43518d5dc71e060fc52a13372dbfa5, but the changes since then were very cosmetic). > >> Hi @tschatzl : I witnessed some conflicts when applying this on latest jdk head. Maybe you can do another merge and rebase? I can help rerun the tests on RISC-V. (Note that there is one failing test: `test/hotspot/jtreg/gtest/GTestWrapper.java` if I use the same base as in your repo, and that issue has been resolved by [JDK-8366897](https://bugs.openjdk.org/browse/JDK-8366897)) > > Merged. Thanks for another round of testing (also to @TheRealMDoerr). Hi @tschatzl, I see one build failure on s390x, # # A fatal error has been detected by the Java Runtime Environment: # # SIGILL (0x4) at pc=0x000003ffaad14a42, pid=1801882, tid=1801914 # # JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.amit.jdk) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.amit.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-s390x) # Problematic frame: # V [libjvm.so+0x414a46] BarrierSetNMethod::set_guard_value(nmethod*, int, int)+0xfe # # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -F%F -- %E" (or dumping to /home/amit/jdk/make/core.1801882) I am working on this on priority, but just in case you want to merge it, I will open another issue and push the fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3274080889 From stefank at openjdk.org Wed Sep 10 09:34:29 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 10 Sep 2025 09:34:29 GMT Subject: RFR: 8367298: ZGC: Enhance zaddress type system's assert messages In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 05:55:42 GMT, Axel Boldt-Christmas wrote: > ZGC uses a family of strongly type integral types to test and verify invariants for addresses, offset, indices and colored pointers within the heap. It is usually the first place we hit an assert if something goes wrong, and looking at the actual value is often enough to identify if it is memory corruption, a broken color invariant or a mistake in the use of the type system. > > Unfortunately not all asserts print the value in the assert message, requiring more extensive investigation to even identify the nature of the problem. > > I propose we enhance all our zaddress assert printing to always include the invariant breaking value. > > _While I chose to print the max values in the assert message of the offset and indices checks, I did not print the colors in the zpointer checks. Both colors and the max values are easily available in the error report, so it would only really be a problem if a hs_err file is missing._ > > We should probably also see if we can enhance all the rest of our asserts in ZGC similarly. I do not think I have ever seen a failed invariant check and thought "Why are we printing the invariant breaking value", but often feel that it is unfortunate that we did not print the actual value. Marked as reviewed by stefank (Reviewer). src/hotspot/share/gc/z/zAddress.inline.hpp line 290: > 288: inline zbacking_index to_zbacking_index(zbacking_offset offset) { > 289: const uintptr_t value = untype(offset); > 290: assert(is_aligned(value, ZGranuleSize), "Must be granule aligned (" PTR_FORMAT ")", value); Maybe change to this to be consistent with the changes below Suggestion: assert(is_aligned(value, ZGranuleSize), "Must be granule aligned: " PTR_FORMAT, value); ------------- PR Review: https://git.openjdk.org/jdk/pull/27184#pullrequestreview-3205308038 PR Review Comment: https://git.openjdk.org/jdk/pull/27184#discussion_r2336161585 From aph at openjdk.org Wed Sep 10 09:36:49 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 10 Sep 2025 09:36:49 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v55] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 07:56:42 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 74 commits: > > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - * iwalulya: remove confusing comment > - * sort includes > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - * improve logging for refinement, making it similar to marking logging > - * commit merge changes > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - * fix merge error > - * forgot to actually save the files > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - ... and 64 more: https://git.openjdk.org/jdk/compare/9e3fa321...e7c3a067 src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp line 95: > 93: Label loop; > 94: Label next; > 95: const Register end = count; This aliasing of register names is tricky and confusing. A trap for maintainers, of the kind that people have fallen into already. src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp line 104: > 102: __ lsr(start, start, CardTable::card_shift()); > 103: __ lsr(end, end, CardTable::card_shift()); > 104: __ sub(count, end, start); // Number of bytes to mark Because `end` is inclusive, `count` here is the number of bytes to mark - 1. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2336167617 PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2336164656 From duke at openjdk.org Wed Sep 10 09:48:17 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Wed, 10 Sep 2025 09:48:17 GMT Subject: RFR: 8367240: Parallel: Refactor PSScavengeCLDClosure [v4] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 15:49:51 GMT, Albert Mingkun Yang wrote: >> Refactor `PSScavengeCLDClosure` and its "enclosing" `PSScavengeFromCLDClosure` so that all CLD logic is encapsulated in the CLD closure, without polluting the oop closure. >> >> Test: tier1-3 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review src/hotspot/share/gc/parallel/psClosure.inline.hpp line 101: > 99: RawAccess::oop_store(p, new_obj); > 100: > 101: if (PSScavenge::is_obj_in_young(new_obj) && !_has_oops_into_young_gen) { Why do you need to check `!_has_oops_into_young_gen` ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27165#discussion_r2336199653 From ayang at openjdk.org Wed Sep 10 10:24:27 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 10 Sep 2025 10:24:27 GMT Subject: RFR: 8367240: Parallel: Refactor PSScavengeCLDClosure [v4] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 09:45:41 GMT, Francesco Andreuzzi wrote: >> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> review > > src/hotspot/share/gc/parallel/psClosure.inline.hpp line 101: > >> 99: RawAccess::oop_store(p, new_obj); >> 100: >> 101: if (PSScavenge::is_obj_in_young(new_obj) && !_has_oops_into_young_gen) { > > Why do you need to check `!_has_oops_into_young_gen` ? It's to avoid writing `_has_oops_into_young_gen` multiple times, if it's already `true`. (Both versions are correct though.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27165#discussion_r2336289581 From duke at openjdk.org Wed Sep 10 10:28:31 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Wed, 10 Sep 2025 10:28:31 GMT Subject: RFR: 8367240: Parallel: Refactor PSScavengeCLDClosure [v4] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 10:21:57 GMT, Albert Mingkun Yang wrote: >> src/hotspot/share/gc/parallel/psClosure.inline.hpp line 101: >> >>> 99: RawAccess::oop_store(p, new_obj); >>> 100: >>> 101: if (PSScavenge::is_obj_in_young(new_obj) && !_has_oops_into_young_gen) { >> >> Why do you need to check `!_has_oops_into_young_gen` ? > > It's to avoid writing `_has_oops_into_young_gen` multiple times, if it's already `true`. (Both versions are correct though.) Yeah, I was curious why it's needed. What's the problem with just writing `true` if it's already `true`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27165#discussion_r2336299129 From ayang at openjdk.org Wed Sep 10 10:34:35 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 10 Sep 2025 10:34:35 GMT Subject: RFR: 8367240: Parallel: Refactor PSScavengeCLDClosure [v4] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 10:25:56 GMT, Francesco Andreuzzi wrote: >> It's to avoid writing `_has_oops_into_young_gen` multiple times, if it's already `true`. (Both versions are correct though.) > > Yeah, I was curious why it's needed. What's the problem with just writing `true` if it's already `true`? There is no problem; just redundant work. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27165#discussion_r2336312075 From duke at openjdk.org Wed Sep 10 10:36:50 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Wed, 10 Sep 2025 10:36:50 GMT Subject: RFR: 8367240: Parallel: Refactor PSScavengeCLDClosure [v4] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 15:49:51 GMT, Albert Mingkun Yang wrote: >> Refactor `PSScavengeCLDClosure` and its "enclosing" `PSScavengeFromCLDClosure` so that all CLD logic is encapsulated in the CLD closure, without polluting the oop closure. >> >> Test: tier1-3 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Marked as reviewed by fandreuz at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/27165#pullrequestreview-3205530580 From amitkumar at openjdk.org Wed Sep 10 11:10:00 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 10 Sep 2025 11:10:00 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 07:53:15 GMT, Thomas Schatzl wrote: >> We would like to finally wrap up this PR as we are about to Propose To Target [JEP 522](openjdk.org/jeps/522) to JDK 26, so it would be nice to get re-reviews from the reviewers that already signed it off if you think it is useful. >> >> Nothing much changed actually for months now, particularly in the area of target-specific support, but maybe one more rerun on the more exotic platforms (AIX/PPC, RISC-V) just in case would be fine. >> >> Internally it went through Oracle's tier1-8 without any issue again (that is revision https://github.com/openjdk/jdk/pull/23739/commits/b3873d66cd43518d5dc71e060fc52a13372dbfa5, but the changes since then were very cosmetic). > >> Hi @tschatzl : I witnessed some conflicts when applying this on latest jdk head. Maybe you can do another merge and rebase? I can help rerun the tests on RISC-V. (Note that there is one failing test: `test/hotspot/jtreg/gtest/GTestWrapper.java` if I use the same base as in your repo, and that issue has been resolved by [JDK-8366897](https://bugs.openjdk.org/browse/JDK-8366897)) > > Merged. Thanks for another round of testing (also to @TheRealMDoerr). > Hi @tschatzl, I see one build failure on s390x, > > ``` > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGILL (0x4) at pc=0x000003ffaad14a42, pid=1801882, tid=1801914 > # > # JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.amit.jdk) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.amit.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-s390x) > # Problematic frame: > # V [libjvm.so+0x414a46] BarrierSetNMethod::set_guard_value(nmethod*, int, int)+0xfe > # > # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -F%F -- %E" (or dumping to /home/amit/jdk/make/core.1801882) > ``` > > I am working on this on priority, but just in case you want to merge it, I will open another issue and push the fix. Seems like build failure came from one change merged yesterday- https://github.com/openjdk/jdk/pull/26399, I am working on it and created https://bugs.openjdk.org/browse/JDK-8367325 ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3274462944 From tschatzl at openjdk.org Wed Sep 10 11:31:24 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 11:31:24 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 07:53:15 GMT, Thomas Schatzl wrote: >> We would like to finally wrap up this PR as we are about to Propose To Target [JEP 522](openjdk.org/jeps/522) to JDK 26, so it would be nice to get re-reviews from the reviewers that already signed it off if you think it is useful. >> >> Nothing much changed actually for months now, particularly in the area of target-specific support, but maybe one more rerun on the more exotic platforms (AIX/PPC, RISC-V) just in case would be fine. >> >> Internally it went through Oracle's tier1-8 without any issue again (that is revision https://github.com/openjdk/jdk/pull/23739/commits/b3873d66cd43518d5dc71e060fc52a13372dbfa5, but the changes since then were very cosmetic). > >> Hi @tschatzl : I witnessed some conflicts when applying this on latest jdk head. Maybe you can do another merge and rebase? I can help rerun the tests on RISC-V. (Note that there is one failing test: `test/hotspot/jtreg/gtest/GTestWrapper.java` if I use the same base as in your repo, and that issue has been resolved by [JDK-8366897](https://bugs.openjdk.org/browse/JDK-8366897)) > > Merged. Thanks for another round of testing (also to @TheRealMDoerr). > > Hi @tschatzl, I see one build failure on s390x, > > ``` > > # > > # A fatal error has been detected by the Java Runtime Environment: > > # > > # SIGILL (0x4) at pc=0x000003ffaad14a42, pid=1801882, tid=1801914 > > # > > # JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.amit.jdk) > > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.amit.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-s390x) > > # Problematic frame: > > # V [libjvm.so+0x414a46] BarrierSetNMethod::set_guard_value(nmethod*, int, int)+0xfe [...] > > > > I am working on this on priority, but just in case you want to merge it, I will open another issue and push the fix. > > Seems like build failure came from one change merged yesterday- #26399, I am working on it and created https://bugs.openjdk.org/browse/JDK-8367325 This should definitely be caused by that other change. Apologies for the trouble. Thank you for working on this. Thomas ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3274535127 From tschatzl at openjdk.org Wed Sep 10 11:36:26 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 11:36:26 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v56] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 75 commits: - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * iwalulya: remove confusing comment - * sort includes - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * improve logging for refinement, making it similar to marking logging - * commit merge changes - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * fix merge error - * forgot to actually save the files - ... and 65 more: https://git.openjdk.org/jdk/compare/edae355e...de1469d6 ------------- Changes: https://git.openjdk.org/jdk/pull/23739/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=55 Stats: 7114 lines in 112 files changed: 2590 ins; 3583 del; 941 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From tschatzl at openjdk.org Wed Sep 10 11:36:29 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 11:36:29 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v55] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 07:56:42 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 74 commits: > > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - * iwalulya: remove confusing comment > - * sort includes > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - * improve logging for refinement, making it similar to marking logging > - * commit merge changes > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - * fix merge error > - * forgot to actually save the files > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - ... and 64 more: https://git.openjdk.org/jdk/compare/9e3fa321...e7c3a067 That windows-x64 failure also seems to be an issue caused by another change merged in today :( Already fixed in [JDK-8367309](https://bugs.openjdk.org/browse/JDK-8367309). ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3274545641 From tschatzl at openjdk.org Wed Sep 10 11:44:30 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 11:44:30 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v57] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * aph review, fix some comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23739/files - new: https://git.openjdk.org/jdk/pull/23739/files/de1469d6..d0ca9062 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=56 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=55-56 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From tschatzl at openjdk.org Wed Sep 10 11:44:34 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 11:44:34 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v55] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 09:33:42 GMT, Andrew Haley wrote: >> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 74 commits: >> >> - Merge branch 'master' into 8342382-card-table-instead-of-dcq >> - * iwalulya: remove confusing comment >> - * sort includes >> - Merge branch 'master' into 8342382-card-table-instead-of-dcq >> - * improve logging for refinement, making it similar to marking logging >> - * commit merge changes >> - Merge branch 'master' into 8342382-card-table-instead-of-dcq >> - * fix merge error >> - * forgot to actually save the files >> - Merge branch 'master' into 8342382-card-table-instead-of-dcq >> - ... and 64 more: https://git.openjdk.org/jdk/compare/9e3fa321...e7c3a067 > > src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp line 95: > >> 93: Label loop; >> 94: Label next; >> 95: const Register end = count; > > This aliasing of register names is tricky and confusing. A trap for maintainers, of the kind that people have fallen into already. I can argue I was following precedence :) I see your point though. What do you suggest to do here? Use `count` throughout instead? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2336468727 From stefank at openjdk.org Wed Sep 10 11:58:46 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 10 Sep 2025 11:58:46 GMT Subject: RFR: 8366980: TestTransparentHugePagesHeap.java fails when run with -UseCompressedOops [v2] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 13:12:46 GMT, Stefan Karlsson wrote: >> The new test TestTransparentHugePagesHeap.java added in [JDK-8366434](https://bugs.openjdk.org/browse/JDK-8366434) fails when run with -UseCompressedOops. >> >> The reason for this is that the address printed as the start of the heap in the pagesize logging is not the start of the mapping. So we fail to find the mapping when scanning the SMAPS file. >> >> There reason why this happens is that Linux has merged the memory area for the heap with some other memory. Sometimes it is the marking bitmaps and sometimes it's just malloc that mapped some memory. >> >> I propose that we change the test to find the smaps memory area that contains the start address of the heap and verify that that area is THP eligible. >> >> I'm using BigInteger to represent the parsed addresses to skip having to deal with negative values in longs. >> >> Tested locally with the reproducer. I'm also testing with tier1 and the tier that found this issue. >> >> The fix is localized in TestTransparentHugePagesHeap.java so that it can easily be incorporated into a backport of JDK-8366434. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Early-return in contains check Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27143#issuecomment-3274613765 From stefank at openjdk.org Wed Sep 10 11:58:47 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 10 Sep 2025 11:58:47 GMT Subject: Integrated: 8366980: TestTransparentHugePagesHeap.java fails when run with -UseCompressedOops In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 12:34:33 GMT, Stefan Karlsson wrote: > The new test TestTransparentHugePagesHeap.java added in [JDK-8366434](https://bugs.openjdk.org/browse/JDK-8366434) fails when run with -UseCompressedOops. > > The reason for this is that the address printed as the start of the heap in the pagesize logging is not the start of the mapping. So we fail to find the mapping when scanning the SMAPS file. > > There reason why this happens is that Linux has merged the memory area for the heap with some other memory. Sometimes it is the marking bitmaps and sometimes it's just malloc that mapped some memory. > > I propose that we change the test to find the smaps memory area that contains the start address of the heap and verify that that area is THP eligible. > > I'm using BigInteger to represent the parsed addresses to skip having to deal with negative values in longs. > > Tested locally with the reproducer. I'm also testing with tier1 and the tier that found this issue. > > The fix is localized in TestTransparentHugePagesHeap.java so that it can easily be incorporated into a backport of JDK-8366434. This pull request has now been integrated. Changeset: 703d930e Author: Stefan Karlsson URL: https://git.openjdk.org/jdk/commit/703d930e4d52a6f9741cf9affee8caade550e67b Stats: 56 lines in 1 file changed: 31 ins; 2 del; 23 mod 8366980: TestTransparentHugePagesHeap.java fails when run with -UseCompressedOops Reviewed-by: aboldtch, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/27143 From iwalulya at openjdk.org Wed Sep 10 12:03:42 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 10 Sep 2025 12:03:42 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v57] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 11:44:30 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * aph review, fix some comment Changes requested by iwalulya (Reviewer). src/hotspot/share/gc/g1/g1ConcurrentRefine.hpp line 154: > 152: void assert_state(State expected); > 153: > 154: static void snapshot_heap_into(G1CardTableClaimTable* sweep_table); Any reason why this is static? Don't need to send `_sweep_table` as an argument if it wasn't static. ------------- PR Review: https://git.openjdk.org/jdk/pull/23739#pullrequestreview-3200132750 PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2336517161 From iwalulya at openjdk.org Wed Sep 10 12:03:47 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 10 Sep 2025 12:03:47 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 09:09:49 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * sort includes src/hotspot/share/gc/g1/g1Arguments.cpp line 250: > 248: // Verify that the maximum parallelism isn't too high to eventually overflow > 249: // the refcount in G1CardSetContainer. > 250: uint max_parallel_refinement_threads = G1ConcRefinementThreads; Don't need to local variable `max_parallel_refinement_threads` any more, can use G1ConcRefinementThreads directly. src/hotspot/share/gc/g1/g1CardTableClaimTable.inline.hpp line 95: > 93: i_card++; > 94: } > 95: assert(false, "should have early-returned"); maybe use `ShouldNotReachHere();` src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 216: > 214: class G1SwapThreadCardTableClosure : public HandshakeClosure { > 215: public: > 216: G1SwapThreadCardTableClosure() : HandshakeClosure("G1 Swap JT card table") { } Above on L206 we use "Refine Java Thread CT", here we use "Swap JT card table" not sure which is better "Java Thread CT" vs. "JT card table", but lets pick one. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2332539864 PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2332881834 PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2333281435 From iwalulya at openjdk.org Wed Sep 10 12:03:51 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 10 Sep 2025 12:03:51 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v55] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 07:56:42 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 74 commits: > > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - * iwalulya: remove confusing comment > - * sort includes > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - * improve logging for refinement, making it similar to marking logging > - * commit merge changes > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - * fix merge error > - * forgot to actually save the files > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - ... and 64 more: https://git.openjdk.org/jdk/compare/9e3fa321...e7c3a067 src/hotspot/share/gc/g1/g1CardTableClaimTable.hpp line 43: > 41: // Claiming works on full region (all cards in region) or a range of contiguous cards > 42: // (chunk). Chunk size is given at construction time. > 43: class G1CardTableClaimTable : public CHeapObj { Do we need the `Table` in the `G1CardTableClaimTable` or can just calling it `G1CardTableClaimer` suffice? src/hotspot/share/gc/g1/g1ConcurrentRefine.hpp line 301: > 299: // Indicate that last refinement adjustment had been deferred due to not > 300: // obtaining the heap lock. > 301: bool wait_for_heap_lock() const { return _heap_was_locked; } `wait_for_heap_lock()` does not do any waiting, maybe just maintain `heap_was_locked` as the method name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2336340738 PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2336332933 From tschatzl at openjdk.org Wed Sep 10 12:21:33 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 12:21:33 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v55] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 10:44:20 GMT, Ivan Walulya wrote: >> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 74 commits: >> >> - Merge branch 'master' into 8342382-card-table-instead-of-dcq >> - * iwalulya: remove confusing comment >> - * sort includes >> - Merge branch 'master' into 8342382-card-table-instead-of-dcq >> - * improve logging for refinement, making it similar to marking logging >> - * commit merge changes >> - Merge branch 'master' into 8342382-card-table-instead-of-dcq >> - * fix merge error >> - * forgot to actually save the files >> - Merge branch 'master' into 8342382-card-table-instead-of-dcq >> - ... and 64 more: https://git.openjdk.org/jdk/compare/9e3fa321...e7c3a067 > > src/hotspot/share/gc/g1/g1CardTableClaimTable.hpp line 43: > >> 41: // Claiming works on full region (all cards in region) or a range of contiguous cards >> 42: // (chunk). Chunk size is given at construction time. >> 43: class G1CardTableClaimTable : public CHeapObj { > > Do we need the `Table` in the `G1CardTableClaimTable` or can just calling it `G1CardTableClaimer` suffice? This is the table the claimer below works on. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2336568870 From tschatzl at openjdk.org Wed Sep 10 12:40:11 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 12:40:11 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v58] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * walulyai review * tried to remove "logged card" terminology for the current "pending card" one ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23739/files - new: https://git.openjdk.org/jdk/pull/23739/files/d0ca9062..b47c7b01 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=57 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=56-57 Stats: 55 lines in 11 files changed: 0 ins; 1 del; 54 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From ayang at openjdk.org Wed Sep 10 12:53:25 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 10 Sep 2025 12:53:25 GMT Subject: RFR: 8367240: Parallel: Refactor PSScavengeCLDClosure [v4] In-Reply-To: References: Message-ID: <_gL-uKc8t-rT0Ak19TWFREbdVpA3HU-1PBpCVCnkEoE=.fc51c98f-eafc-46b3-a3c5-78899a941d6c@github.com> On Tue, 9 Sep 2025 15:49:51 GMT, Albert Mingkun Yang wrote: >> Refactor `PSScavengeCLDClosure` and its "enclosing" `PSScavengeFromCLDClosure` so that all CLD logic is encapsulated in the CLD closure, without polluting the oop closure. >> >> Test: tier1-3 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27165#issuecomment-3274838621 From ayang at openjdk.org Wed Sep 10 12:53:26 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 10 Sep 2025 12:53:26 GMT Subject: Integrated: 8367240: Parallel: Refactor PSScavengeCLDClosure In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 08:59:10 GMT, Albert Mingkun Yang wrote: > Refactor `PSScavengeCLDClosure` and its "enclosing" `PSScavengeFromCLDClosure` so that all CLD logic is encapsulated in the CLD closure, without polluting the oop closure. > > Test: tier1-3 This pull request has now been integrated. Changeset: 385c1329 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/385c13298932f1de16e6161652be35d966d822ec Stats: 41 lines in 1 file changed: 8 ins; 17 del; 16 mod 8367240: Parallel: Refactor PSScavengeCLDClosure Reviewed-by: stefank ------------- PR: https://git.openjdk.org/jdk/pull/27165 From epeter at openjdk.org Wed Sep 10 12:55:29 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 10 Sep 2025 12:55:29 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 08:53:13 GMT, Christian Hagedorn wrote: >> Is this going to be GC independent? What if the VM swaps to another GC ergonomically? > > The test runs with `vm.flagless`. But I suggest to just go with `>= 1` instead to be on the safe side. The purpose of this IR rule in the context of this test is really just that it does not fail and not about catching real issues/verifying the IR. > > If we still want to test the improved loop unrolling opportunities, I suggest to create a separate IR test for it, possibly in a separate RFE. I suppose that's probably not possible, as far as I know we always run with G1GC, so it should be fine :) We could put an upper bound of 3, maybe 4 here though. Just see what passes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2336663260 From ayang at openjdk.org Wed Sep 10 13:59:57 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 10 Sep 2025 13:59:57 GMT Subject: RFR: 8366865: G1: Allocation GC Pauses Triggered after JVM has started shutdown In-Reply-To: References: Message-ID: <04Lru322UkYz11DPPFo3alqoYCd7pSEsPSkpW4Z0_bQ=.d536246e-a5bb-4594-8966-52936927e117@github.com> On Wed, 10 Sep 2025 09:57:18 GMT, Ivan Walulya wrote: > Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. > > Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. > > Testing: Tier 1-7 The PR title shouldn't have `G1:` prefix, as it changes other GCs as well. src/hotspot/share/gc/shared/collectedHeap.cpp line 617: > 615: // To avoid returning nullptr (which could cause premature OOME), we stall > 616: // allocation requests here until the VM shutdown is complete. > 617: MonitorLocker ml(VMExit_lock); I wonder if an always-zero-`Semaphore` works. src/hotspot/share/gc/shared/gcVMOperations.cpp line 115: > 113: > 114: // Check invocations > 115: if (skip_operation() || Universe::heap()->is_shutting_down()) { Can the new condition be inlined inside `skip_operation()`? ------------- PR Review: https://git.openjdk.org/jdk/pull/27190#pullrequestreview-3206275122 PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2336838170 PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2336842785 From iwalulya at openjdk.org Wed Sep 10 13:59:58 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 10 Sep 2025 13:59:58 GMT Subject: RFR: 8366865: G1: Allocation GC Pauses Triggered after JVM has started shutdown In-Reply-To: <04Lru322UkYz11DPPFo3alqoYCd7pSEsPSkpW4Z0_bQ=.d536246e-a5bb-4594-8966-52936927e117@github.com> References: <04Lru322UkYz11DPPFo3alqoYCd7pSEsPSkpW4Z0_bQ=.d536246e-a5bb-4594-8966-52936927e117@github.com> Message-ID: On Wed, 10 Sep 2025 13:51:50 GMT, Albert Mingkun Yang wrote: >> Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. >> >> Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. >> >> Testing: Tier 1-7 > > src/hotspot/share/gc/shared/gcVMOperations.cpp line 115: > >> 113: >> 114: // Check invocations >> 115: if (skip_operation() || Universe::heap()->is_shutting_down()) { > > Can the new condition be inlined inside `skip_operation()`? In the first iteration I had it inlined, but then decided to make it more explicit. I can change it back if you prefer ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2336854910 From ayang at openjdk.org Wed Sep 10 14:11:29 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 10 Sep 2025 14:11:29 GMT Subject: RFR: 8367339: Parallel: Remove PSScavenge::should_scavenge Message-ID: Removing (inlining) a compound method that performs two independent things, loading the obj from a location and checking whether the object belongs to young-gen. Existing callers are changed to use more fine-grained methods, which are more transparent and readable in their context. Test: tier1-3 ------------- Commit messages: - pgc-remove-should-scavenge Changes: https://git.openjdk.org/jdk/pull/27193/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27193&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367339 Stats: 104 lines in 8 files changed: 4 ins; 91 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/27193.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27193/head:pull/27193 PR: https://git.openjdk.org/jdk/pull/27193 From iwalulya at openjdk.org Wed Sep 10 14:54:29 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 10 Sep 2025 14:54:29 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v58] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 12:40:11 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * walulyai review > * tried to remove "logged card" terminology for the current "pending card" one src/hotspot/share/gc/g1/g1ConcurrentRefineThread.hpp line 36: > 34: class G1ConcurrentRefine; > 35: > 36: // Concurrent refinement control thread watching card mark accrual on the card Suggestion: // Concurrent refinement control thread watching card mark accrual on the card table src/hotspot/share/gc/g1/g1GCPhaseTimes.hpp line 182: > 180: double _cur_optional_merge_heap_roots_time_ms; > 181: // Included in above merge and optional-merge time. > 182: double _cur_distribute_log_buffers_time_ms; No longer used. src/hotspot/share/gc/g1/g1HeapRegion.hpp line 41: > 39: class G1CardSet; > 40: class G1CardSetConfiguration; > 41: class G1CardTable; Do we need the Forward declaration here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2336962845 PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2336992289 PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2337004685 From ghan at openjdk.org Wed Sep 10 14:59:24 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Wed, 10 Sep 2025 14:59:24 GMT Subject: RFR: 8352969: G1: Improve testability of optional collections [v8] In-Reply-To: References: Message-ID: <0TfWVc7GGe5zlRLObpOGjuiGpqRy1QL7TzwtSPu6eB4=.8351bb27-d3a6-4dcb-a24b-920e6180c032@github.com> > This PR introduces a new diagnostic flag EvacuateAllOptionalRegions to force G1 GC to evacuate all optional regions regardless of the predicted pause time. The motivation is to allow testing and validation of optional region evacuation behavior without being constrained by the remaining pause time. Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - fix format error. - optimize implementation - Merge remote-tracking branch 'upstream/master' into 8352969 - change flag name - Merge remote-tracking branch 'upstream/master' into 8352969 - fix format error - format fix - Optimize implementation and add regression test - Merge remote-tracking branch 'upstream/master' into 8352969 - Update g1YoungCollector.cpp format fix - ... and 3 more: https://git.openjdk.org/jdk/compare/c968a672...725f642e ------------- Changes: https://git.openjdk.org/jdk/pull/26880/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26880&range=07 Stats: 161 lines in 5 files changed: 150 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/26880.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26880/head:pull/26880 PR: https://git.openjdk.org/jdk/pull/26880 From ghan at openjdk.org Wed Sep 10 15:05:33 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Wed, 10 Sep 2025 15:05:33 GMT Subject: RFR: 8352969: G1: Improve testability of optional collections [v9] In-Reply-To: References: Message-ID: > This PR introduces a new diagnostic flag EvacuateAllOptionalRegions to force G1 GC to evacuate all optional regions regardless of the predicted pause time. The motivation is to allow testing and validation of optional region evacuation behavior without being constrained by the remaining pause time. Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: fix a small error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26880/files - new: https://git.openjdk.org/jdk/pull/26880/files/725f642e..05c57c27 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26880&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26880&range=07-08 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26880.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26880/head:pull/26880 PR: https://git.openjdk.org/jdk/pull/26880 From tschatzl at openjdk.org Wed Sep 10 15:24:39 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 15:24:39 GMT Subject: RFR: 8352969: G1: Improve testability of optional collections [v9] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 15:05:33 GMT, Guanqiang Han wrote: >> This PR introduces a new diagnostic flag EvacuateAllOptionalRegions to force G1 GC to evacuate all optional regions regardless of the predicted pause time. The motivation is to allow testing and validation of optional region evacuation behavior without being constrained by the remaining pause time. > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > fix a small error Looks good apart from that spacing in the test. test/hotspot/jtreg/gc/g1/TestOptionalRegionGC.java line 74: > 72: String selectedNum = matcher.group(1); > 73: String totalNum = matcher.group(2); > 74: Asserts.assertTrue(Objects.equals(selectedNum,totalNum),"Error info: "+selectedNum+","+totalNum); Suggestion: Asserts.assertTrue(Objects.equals(selectedNum, totalNum),"Error info: " + selectedNum + ", " + totalNum); ------------- Changes requested by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26880#pullrequestreview-3206677840 PR Review Comment: https://git.openjdk.org/jdk/pull/26880#discussion_r2337118523 From tschatzl at openjdk.org Wed Sep 10 15:28:39 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 15:28:39 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v59] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * walulyai review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23739/files - new: https://git.openjdk.org/jdk/pull/23739/files/b47c7b01..c469c137 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=58 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=57-58 Stats: 9 lines in 3 files changed: 0 ins; 8 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From ghan at openjdk.org Wed Sep 10 15:53:28 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Wed, 10 Sep 2025 15:53:28 GMT Subject: RFR: 8352969: G1: Improve testability of optional collections [v10] In-Reply-To: References: Message-ID: > This PR introduces a new diagnostic flag EvacuateAllOptionalRegions to force G1 GC to evacuate all optional regions regardless of the predicted pause time. The motivation is to allow testing and validation of optional region evacuation behavior without being constrained by the remaining pause time. Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: Update TestOptionalRegionGC.java Correct the formatting errors ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26880/files - new: https://git.openjdk.org/jdk/pull/26880/files/05c57c27..857b5a1e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26880&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26880&range=08-09 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26880.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26880/head:pull/26880 PR: https://git.openjdk.org/jdk/pull/26880 From ghan at openjdk.org Wed Sep 10 15:57:51 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Wed, 10 Sep 2025 15:57:51 GMT Subject: RFR: 8352969: G1: Improve testability of optional collections [v9] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 15:20:20 GMT, Thomas Schatzl wrote: >> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: >> >> fix a small error > > Looks good apart from that spacing in the test. @tschatzl Thank you very much for your valuable comments. I?ve updated this PR accordingly. Could you please take another look. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26880#issuecomment-3275566396 From duke at openjdk.org Wed Sep 10 16:34:13 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Wed, 10 Sep 2025 16:34:13 GMT Subject: RFR: 8367347: Serial: Refactor CLDScanClosure Message-ID: <36NKvKwcEPTW67nS84mxTb7a_QgYQ-0eZOwAm1nCGxk=.2adf928d-7511-45fd-9518-9ac5f411528c@github.com> Refactor `CLDScanClosure` so that all CLD logic is encapsulated in the CLD closure, without polluting the oop closure. Test: tier1-2, running tier3 ------------- Commit messages: - double space - refactor Changes: https://git.openjdk.org/jdk/pull/27199/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27199&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367347 Stats: 21 lines in 1 file changed: 3 ins; 4 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/27199.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27199/head:pull/27199 PR: https://git.openjdk.org/jdk/pull/27199 From duke at openjdk.org Wed Sep 10 16:41:11 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Wed, 10 Sep 2025 16:41:11 GMT Subject: Withdrawn: 8367347: Serial: Refactor CLDScanClosure In-Reply-To: <36NKvKwcEPTW67nS84mxTb7a_QgYQ-0eZOwAm1nCGxk=.2adf928d-7511-45fd-9518-9ac5f411528c@github.com> References: <36NKvKwcEPTW67nS84mxTb7a_QgYQ-0eZOwAm1nCGxk=.2adf928d-7511-45fd-9518-9ac5f411528c@github.com> Message-ID: On Wed, 10 Sep 2025 16:26:39 GMT, Francesco Andreuzzi wrote: > Refactor `CLDScanClosure` so that all CLD logic is encapsulated in the CLD closure, without polluting the oop closure. > > Test: tier1-2, running tier3 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27199 From wkemper at openjdk.org Wed Sep 10 18:06:40 2025 From: wkemper at openjdk.org (William Kemper) Date: Wed, 10 Sep 2025 18:06:40 GMT Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may raise threshold prematurely [v5] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 22:09:02 GMT, William Kemper wrote: >> The adaptive tenuring algorithm has been modified to begin its evaluation of mortality rates from the current tenuring threshold. To compliment this change, objects must also now be strictly above the tenuring threshold to be promoted (instead of greater-than-or-equal). > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision: > > - Fix include order > - Add missing newline > - Fix typo > - Merge tag 'jdk-26+14' into adaptive-tenuring-threshold > > Added tag jdk-26+14 for changeset ab9f70dd > - Do not require objects to be strictly older than the tenuring threshold > - Log updated tenuring age at info, log age table at debug > - Be consistent when comparing tenuring threshold with ages > - Fix windows build > - Fix release build > - Revert unintended change > - ... and 10 more: https://git.openjdk.org/jdk/compare/a4290181...0ffa89c5 Test failures do not look related to these changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26906#issuecomment-3275987994 From fandreuzzi at openjdk.org Wed Sep 10 18:54:59 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 10 Sep 2025 18:54:59 GMT Subject: RFR: 8367347: Serial: Refactor CLDScanClosure [v2] In-Reply-To: <36NKvKwcEPTW67nS84mxTb7a_QgYQ-0eZOwAm1nCGxk=.2adf928d-7511-45fd-9518-9ac5f411528c@github.com> References: <36NKvKwcEPTW67nS84mxTb7a_QgYQ-0eZOwAm1nCGxk=.2adf928d-7511-45fd-9518-9ac5f411528c@github.com> Message-ID: <6gScG_Z1GBADg9iYT6y26LQU1_PIT9IQM0ocmmRepC8=.7789fc61-326f-46dc-85c0-854bf6620045@github.com> > Refactor `CLDScanClosure` so that all CLD logic is encapsulated in the CLD closure, without polluting the oop closure. > > Test: tier1-2, running tier3 Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: nn ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27199/files - new: https://git.openjdk.org/jdk/pull/27199/files/f1d6b199..e66301e4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27199&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27199&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27199.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27199/head:pull/27199 PR: https://git.openjdk.org/jdk/pull/27199 From fandreuzzi at openjdk.org Wed Sep 10 18:59:18 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 10 Sep 2025 18:59:18 GMT Subject: RFR: 8367347: Serial: Refactor CLDScanClosure [v3] In-Reply-To: <36NKvKwcEPTW67nS84mxTb7a_QgYQ-0eZOwAm1nCGxk=.2adf928d-7511-45fd-9518-9ac5f411528c@github.com> References: <36NKvKwcEPTW67nS84mxTb7a_QgYQ-0eZOwAm1nCGxk=.2adf928d-7511-45fd-9518-9ac5f411528c@github.com> Message-ID: > Refactor `CLDScanClosure` so that all CLD logic is encapsulated in the CLD closure, without polluting the oop closure. > > Test: tier1-2, running tier3 Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: trigger ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27199/files - new: https://git.openjdk.org/jdk/pull/27199/files/e66301e4..53a6177c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27199&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27199&range=01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27199.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27199/head:pull/27199 PR: https://git.openjdk.org/jdk/pull/27199 From ayang at openjdk.org Wed Sep 10 19:05:30 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 10 Sep 2025 19:05:30 GMT Subject: RFR: 8367347: Serial: Refactor CLDScanClosure [v3] In-Reply-To: References: <36NKvKwcEPTW67nS84mxTb7a_QgYQ-0eZOwAm1nCGxk=.2adf928d-7511-45fd-9518-9ac5f411528c@github.com> Message-ID: <9tqRTcJEjitVnyM4uAukfugFnv9ov2rtObXyN9abchM=.79e59936-2ede-433b-87d7-e28df9507d04@github.com> On Wed, 10 Sep 2025 18:59:18 GMT, Francesco Andreuzzi wrote: >> Refactor `CLDScanClosure` so that all CLD logic is encapsulated in the CLD closure, without polluting the oop closure. >> >> Test: tier1-2, running tier3 > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > trigger Marked as reviewed by ayang (Reviewer). src/hotspot/share/gc/serial/defNewGeneration.cpp line 100: > 98: > 99: template > 100: void do_oop_work(T* p) { Pre-existing: since this method has only a single caller, I suggest inlining it. ------------- PR Review: https://git.openjdk.org/jdk/pull/27199#pullrequestreview-3207464984 PR Review Comment: https://git.openjdk.org/jdk/pull/27199#discussion_r2337652575 From fandreuzzi at openjdk.org Wed Sep 10 19:38:14 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 10 Sep 2025 19:38:14 GMT Subject: RFR: 8367347: Serial: Refactor CLDScanClosure [v4] In-Reply-To: <36NKvKwcEPTW67nS84mxTb7a_QgYQ-0eZOwAm1nCGxk=.2adf928d-7511-45fd-9518-9ac5f411528c@github.com> References: <36NKvKwcEPTW67nS84mxTb7a_QgYQ-0eZOwAm1nCGxk=.2adf928d-7511-45fd-9518-9ac5f411528c@github.com> Message-ID: > Refactor `CLDScanClosure` so that all CLD logic is encapsulated in the CLD closure, without polluting the oop closure. > > Test: tier1-2, running tier3 Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: inline ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27199/files - new: https://git.openjdk.org/jdk/pull/27199/files/53a6177c..a8c79778 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27199&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27199&range=02-03 Stats: 16 lines in 1 file changed: 6 ins; 8 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27199.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27199/head:pull/27199 PR: https://git.openjdk.org/jdk/pull/27199 From fandreuzzi at openjdk.org Wed Sep 10 19:38:16 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 10 Sep 2025 19:38:16 GMT Subject: RFR: 8367347: Serial: Refactor CLDScanClosure [v3] In-Reply-To: <9tqRTcJEjitVnyM4uAukfugFnv9ov2rtObXyN9abchM=.79e59936-2ede-433b-87d7-e28df9507d04@github.com> References: <36NKvKwcEPTW67nS84mxTb7a_QgYQ-0eZOwAm1nCGxk=.2adf928d-7511-45fd-9518-9ac5f411528c@github.com> <9tqRTcJEjitVnyM4uAukfugFnv9ov2rtObXyN9abchM=.79e59936-2ede-433b-87d7-e28df9507d04@github.com> Message-ID: <2kV0BXsRgaLAUVRDgnqG2ma0vmYAtvdVQYR1xOjVBH8=.bcdba3e6-ee5f-4a6b-839a-b318c3343ee6@github.com> On Wed, 10 Sep 2025 19:02:50 GMT, Albert Mingkun Yang wrote: >> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: >> >> trigger > > src/hotspot/share/gc/serial/defNewGeneration.cpp line 100: > >> 98: >> 99: template >> 100: void do_oop_work(T* p) { > > Pre-existing: since this method has only a single caller, I suggest inlining it. a8c79778693e0a22602bf8c9def0f97cde529df4 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27199#discussion_r2337718273 From kdnilsen at openjdk.org Wed Sep 10 20:45:00 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 10 Sep 2025 20:45:00 GMT Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in ShenandoahFreeSet [v3] In-Reply-To: References: Message-ID: <0DIlqJVwgCnx2FvbXZuDySjJ3hz241ag41o3BCHkSuY=.ac51c769-c5c0-4750-99b4-0ff43f864d33@github.com> On Tue, 9 Sep 2025 22:07:11 GMT, Kelvin Nilsen wrote: >> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet. In the new code, we keep a single tally of relevant information within ShenandoahFreeSet. >> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet. >> >> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies. These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms. >> >> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > another tweak to make GHA gtest happy src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 372: > 370: _last_sample_time = now; > 371: _last_sample_value = allocated; > 372: } This was a bug. If we don't update the average, we should not restart the time until next sample and we should not overwrite the value of _last_sample_value. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2337848793 From fandreuzzi at openjdk.org Wed Sep 10 21:01:56 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 10 Sep 2025 21:01:56 GMT Subject: RFR: 8367339: Parallel: Remove PSScavenge::should_scavenge In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 14:03:20 GMT, Albert Mingkun Yang wrote: > Removing (inlining) a compound method that performs two independent things, loading the obj from a location and checking whether the object belongs to young-gen. Existing callers are changed to use more fine-grained methods, which are more transparent and readable in their context. > > Test: tier1-3 src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp line 337: > 335: inline void PSPromotionManager::copy_and_push_safe_barrier(T* p) { > 336: assert(ParallelScavengeHeap::heap()->is_in_reserved(p), "precondition"); > 337: assert(should_scavenge(p, true), "revisiting object?"); This method is `public`, is it safe to remove the assertion? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27193#discussion_r2337901467 From phh at openjdk.org Wed Sep 10 22:05:58 2025 From: phh at openjdk.org (Paul Hohensee) Date: Wed, 10 Sep 2025 22:05:58 GMT Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may raise threshold prematurely [v5] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 22:09:02 GMT, William Kemper wrote: >> The adaptive tenuring algorithm has been modified to begin its evaluation of mortality rates from the current tenuring threshold. To compliment this change, objects must also now be strictly above the tenuring threshold to be promoted (instead of greater-than-or-equal). > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision: > > - Fix include order > - Add missing newline > - Fix typo > - Merge tag 'jdk-26+14' into adaptive-tenuring-threshold > > Added tag jdk-26+14 for changeset ab9f70dd > - Do not require objects to be strictly older than the tenuring threshold > - Log updated tenuring age at info, log age table at debug > - Be consistent when comparing tenuring threshold with ages > - Fix windows build > - Fix release build > - Revert unintended change > - ... and 10 more: https://git.openjdk.org/jdk/compare/a2c26721...0ffa89c5 Looks good from a sw engineering pov (the vast majority of the changes are that). I can't definitively say that the functionality change is the right thing, but seems reasonable. I'll go by Ramki's judgement. ------------- Marked as reviewed by phh (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26906#pullrequestreview-3207975609 From wkemper at openjdk.org Wed Sep 10 22:14:59 2025 From: wkemper at openjdk.org (William Kemper) Date: Wed, 10 Sep 2025 22:14:59 GMT Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may raise threshold prematurely [v5] In-Reply-To: References: Message-ID: <2LxUvCMZ3k_Z0pzeJTs4kMF3FUjwexh8oj208skeP60=.ca96561e-6200-42b3-b1be-da295a88dd89@github.com> On Wed, 10 Sep 2025 22:03:08 GMT, Paul Hohensee wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision: >> >> - Fix include order >> - Add missing newline >> - Fix typo >> - Merge tag 'jdk-26+14' into adaptive-tenuring-threshold >> >> Added tag jdk-26+14 for changeset ab9f70dd >> - Do not require objects to be strictly older than the tenuring threshold >> - Log updated tenuring age at info, log age table at debug >> - Be consistent when comparing tenuring threshold with ages >> - Fix windows build >> - Fix release build >> - Revert unintended change >> - ... and 10 more: https://git.openjdk.org/jdk/compare/f4bf1efb...0ffa89c5 > > Looks good from a sw engineering pov (the vast majority of the changes are that). I can't definitively say that the functionality change is the right thing, but seems reasonable. I'll go by Ramki's judgement. Thanks @phohensee . The change is sort of subtle and won't be noticed on every workload. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26906#issuecomment-3276702155 From wkemper at openjdk.org Wed Sep 10 22:15:00 2025 From: wkemper at openjdk.org (William Kemper) Date: Wed, 10 Sep 2025 22:15:00 GMT Subject: Integrated: 8365956: GenShen: Adaptive tenuring threshold algorithm may raise threshold prematurely In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 18:24:12 GMT, William Kemper wrote: > The adaptive tenuring algorithm has been modified to begin its evaluation of mortality rates from the current tenuring threshold. To compliment this change, objects must also now be strictly above the tenuring threshold to be promoted (instead of greater-than-or-equal). This pull request has now been integrated. Changeset: 7fcce270 Author: William Kemper URL: https://git.openjdk.org/jdk/commit/7fcce27096605a27ca3b74349d1012bb0bd5963d Stats: 347 lines in 15 files changed: 253 ins; 29 del; 65 mod 8365956: GenShen: Adaptive tenuring threshold algorithm may raise threshold prematurely Reviewed-by: kdnilsen, phh ------------- PR: https://git.openjdk.org/jdk/pull/26906 From dholmes at openjdk.org Thu Sep 11 01:23:09 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 11 Sep 2025 01:23:09 GMT Subject: RFR: 8366328: G1: Crash on reading os::thread_cpu_time In-Reply-To: <-GY3zWT-Xjc7Utjyf20sdI5WuWtNXkjivZOcSQAPhOY=.9188b968-d9e4-45df-9237-96c74d30b46f@github.com> References: <-GY3zWT-Xjc7Utjyf20sdI5WuWtNXkjivZOcSQAPhOY=.9188b968-d9e4-45df-9237-96c74d30b46f@github.com> Message-ID: On Wed, 10 Sep 2025 07:57:10 GMT, Ivan Walulya wrote: > > Can you not use VMThread::is_terminated() to check for shutdown? > > `before_exit(thread)` happens before `VMThread::wait_for_vm_thread_exit();` which sets the `_is_terminated`, so it too late since we terminate the concurrent GC threads at `before_exit`. Okay, I'm a little surprised we don't have a pre-existing global indicator of the fact we have started shutting down via `before_exit`. Makes me think though that this G1 specific flag should be at the level of `heap()` or even `Universe`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27087#issuecomment-3277045064 From dholmes at openjdk.org Thu Sep 11 01:47:11 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 11 Sep 2025 01:47:11 GMT Subject: RFR: 8366865: G1: Allocation GC Pauses Triggered after JVM has started shutdown In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 09:57:18 GMT, Ivan Walulya wrote: > Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. > > Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. > > Testing: Tier 1-7 src/hotspot/share/gc/shared/collectedHeap.cpp line 616: > 614: // If the VM is shutting down, we may have skipped VM_CollectForAllocation. > 615: // To avoid returning nullptr (which could cause premature OOME), we stall > 616: // allocation requests here until the VM shutdown is complete. If I understand the shutdown sequence correctly, I don't think you can do this without risking a hang. The thread doing the shutdown can potentially execute code that requires allocation after `is_shutting_down()` returns true. This is due to the JVMTI events posted from `before_exit`: if (JvmtiExport::should_post_thread_life()) { JvmtiExport::post_thread_end(thread); } // Always call even when there are not JVMTI environments yet, since environments // may be attached late and JVMTI must track phases of VM execution JvmtiExport::post_vm_death(); I think if you can't GC during shutdown then you have to simply let the allocation fail. src/hotspot/share/runtime/mutexLocker.cpp line 85: > 83: Monitor* InitCompleted_lock = nullptr; > 84: Monitor* BeforeExit_lock = nullptr; > 85: Monitor* VMExit_lock = nullptr; It is unfortunate that we need yet-another exit related mutex. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2338299593 PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2338286600 From aboldtch at openjdk.org Thu Sep 11 05:18:14 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 11 Sep 2025 05:18:14 GMT Subject: RFR: 8367298: ZGC: Enhance zaddress type system's assert messages [v2] In-Reply-To: References: Message-ID: > ZGC uses a family of strongly type integral types to test and verify invariants for addresses, offset, indices and colored pointers within the heap. It is usually the first place we hit an assert if something goes wrong, and looking at the actual value is often enough to identify if it is memory corruption, a broken color invariant or a mistake in the use of the type system. > > Unfortunately not all asserts print the value in the assert message, requiring more extensive investigation to even identify the nature of the problem. > > I propose we enhance all our zaddress assert printing to always include the invariant breaking value. > > _While I chose to print the max values in the assert message of the offset and indices checks, I did not print the colors in the zpointer checks. Both colors and the max values are easily available in the error report, so it would only really be a problem if a hs_err file is missing._ > > We should probably also see if we can enhance all the rest of our asserts in ZGC similarly. I do not think I have ever seen a failed invariant check and thought "Why are we printing the invariant breaking value", but often feel that it is unfortunate that we did not print the actual value. Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/share/gc/z/zAddress.inline.hpp Co-authored-by: Stefan Karlsson ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27184/files - new: https://git.openjdk.org/jdk/pull/27184/files/45ea9f0b..e67ada3a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27184&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27184&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27184.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27184/head:pull/27184 PR: https://git.openjdk.org/jdk/pull/27184 From aboldtch at openjdk.org Thu Sep 11 05:20:29 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 11 Sep 2025 05:20:29 GMT Subject: RFR: 8367317: ZGC: ZVirtualMemoryReserver::force_reserve_discontiguous arithmetic underflow Message-ID: ZVirtualMemoryReserver::force_reserve_discontiguous is a debug only API used to simulate and test a discontinuous heap. The loop variable `end` is incorrectly checked which may lead to an underflow. In our normal testing we never observe this as the address space is always available. We observed this issue when running a hardened build (like ASAN) which had already mmapped the address space we tried to reserve. Rather than always jump two reserve sizes in its search, it searches every reserve size, moving an extra reserve size every time it succeeds with a reservation (so that there always is a gap). Searching in reserve sized steps is not really a requirement here, we could have just used a granule sized step. ------------- Commit messages: - 8367317: ZGC: ZVirtualMemoryReserver::force_reserve_discontiguous arithmetic underflow Changes: https://git.openjdk.org/jdk/pull/27207/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27207&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367317 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27207.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27207/head:pull/27207 PR: https://git.openjdk.org/jdk/pull/27207 From stefank at openjdk.org Thu Sep 11 06:13:21 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 11 Sep 2025 06:13:21 GMT Subject: RFR: 8367298: ZGC: Enhance zaddress type system's assert messages [v2] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 05:18:14 GMT, Axel Boldt-Christmas wrote: >> ZGC uses a family of strongly type integral types to test and verify invariants for addresses, offset, indices and colored pointers within the heap. It is usually the first place we hit an assert if something goes wrong, and looking at the actual value is often enough to identify if it is memory corruption, a broken color invariant or a mistake in the use of the type system. >> >> Unfortunately not all asserts print the value in the assert message, requiring more extensive investigation to even identify the nature of the problem. >> >> I propose we enhance all our zaddress assert printing to always include the invariant breaking value. >> >> _While I chose to print the max values in the assert message of the offset and indices checks, I did not print the colors in the zpointer checks. Both colors and the max values are easily available in the error report, so it would only really be a problem if a hs_err file is missing._ >> >> We should probably also see if we can enhance all the rest of our asserts in ZGC similarly. I do not think I have ever seen a failed invariant check and thought "Why are we printing the invariant breaking value", but often feel that it is unfortunate that we did not print the actual value. > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/share/gc/z/zAddress.inline.hpp > > Co-authored-by: Stefan Karlsson Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27184#pullrequestreview-3209040274 From stefank at openjdk.org Thu Sep 11 06:35:42 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 11 Sep 2025 06:35:42 GMT Subject: RFR: 8367347: Serial: Refactor CLDScanClosure [v4] In-Reply-To: References: <36NKvKwcEPTW67nS84mxTb7a_QgYQ-0eZOwAm1nCGxk=.2adf928d-7511-45fd-9518-9ac5f411528c@github.com> Message-ID: On Wed, 10 Sep 2025 19:38:14 GMT, Francesco Andreuzzi wrote: >> Refactor `CLDScanClosure` so that all CLD logic is encapsulated in the CLD closure, without polluting the oop closure. >> >> Test: tier1-2, running tier3 > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > inline Looks good to me. FWIW, in this and in Albert's previous patch I had to check `is_in_young_gen` to see if it was a trivial check and not something complicated. We could make it easier for the readers if this code: if (is_in_young_gen(new_obj) && !_has_oops_into_young_gen) { _has_oops_into_young_gen = true; } to: if (!_has_oops_into_young_gen && is_in_young_gen(new_obj)) { _has_oops_into_young_gen = true; } It might also be nicer to the branch predictor. ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27199#pullrequestreview-3209146296 From tschatzl at openjdk.org Thu Sep 11 07:20:27 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 11 Sep 2025 07:20:27 GMT Subject: RFR: 8352969: G1: Improve testability of optional collections [v10] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 15:53:28 GMT, Guanqiang Han wrote: >> This PR introduces a new diagnostic flag EvacuateAllOptionalRegions to force G1 GC to evacuate all optional regions regardless of the predicted pause time. The motivation is to allow testing and validation of optional region evacuation behavior without being constrained by the remaining pause time. > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > Update TestOptionalRegionGC.java > > Correct the formatting errors Good. ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26880#pullrequestreview-3209399853 From tschatzl at openjdk.org Thu Sep 11 07:26:25 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 11 Sep 2025 07:26:25 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v59] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 15:28:39 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * walulyai review That test failure in windows-x64 is a shenandoah timeout that looks unrelated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3278828076 From tschatzl at openjdk.org Thu Sep 11 07:39:29 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 11 Sep 2025 07:39:29 GMT Subject: RFR: 8367347: Serial: Refactor CLDScanClosure [v4] In-Reply-To: References: <36NKvKwcEPTW67nS84mxTb7a_QgYQ-0eZOwAm1nCGxk=.2adf928d-7511-45fd-9518-9ac5f411528c@github.com> Message-ID: <2AYyU80wD87V-Ruo4E3gfbXaQCFkX7MZ3qabIdtv5mM=.5eaba215-dbae-4ef0-b61f-58d1feac4f0b@github.com> On Wed, 10 Sep 2025 19:38:14 GMT, Francesco Andreuzzi wrote: >> Refactor `CLDScanClosure` so that all CLD logic is encapsulated in the CLD closure, without polluting the oop closure. >> >> Test: tier1-2, running tier3 > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > inline Changes requested by tschatzl (Reviewer). src/hotspot/share/gc/serial/defNewGeneration.cpp line 98: > 96: class CLDOopClosure : public OffHeapScanClosure { > 97: DefNewGeneration* _g; > 98: Suggestion: `_g` is never referenced anywhere in `CLDOopClosure`. ------------- PR Review: https://git.openjdk.org/jdk/pull/27199#pullrequestreview-3209470365 PR Review Comment: https://git.openjdk.org/jdk/pull/27199#discussion_r2339136155 From duke at openjdk.org Thu Sep 11 07:45:20 2025 From: duke at openjdk.org (duke) Date: Thu, 11 Sep 2025 07:45:20 GMT Subject: RFR: 8352969: G1: Improve testability of optional collections [v10] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 15:53:28 GMT, Guanqiang Han wrote: >> This PR introduces a new diagnostic flag EvacuateAllOptionalRegions to force G1 GC to evacuate all optional regions regardless of the predicted pause time. The motivation is to allow testing and validation of optional region evacuation behavior without being constrained by the remaining pause time. > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > Update TestOptionalRegionGC.java > > Correct the formatting errors @hgqxjj Your change (at version 857b5a1ee23f761a734ce5faa74d654fc493a576) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26880#issuecomment-3278927993 From ghan at openjdk.org Thu Sep 11 07:45:21 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 11 Sep 2025 07:45:21 GMT Subject: RFR: 8352969: G1: Improve testability of optional collections [v10] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 07:17:57 GMT, Thomas Schatzl wrote: >> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: >> >> Update TestOptionalRegionGC.java >> >> Correct the formatting errors > > Good. @tschatzl Thank you for the approval. I?ve integrated this PR. Could you please sponsor it? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26880#issuecomment-3278932459 From tschatzl at openjdk.org Thu Sep 11 08:01:15 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 11 Sep 2025 08:01:15 GMT Subject: RFR: 8352969: G1: Improve testability of optional collections [v10] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 15:53:28 GMT, Guanqiang Han wrote: >> This PR introduces a new diagnostic flag EvacuateAllOptionalRegions to force G1 GC to evacuate all optional regions regardless of the predicted pause time. The motivation is to allow testing and validation of optional region evacuation behavior without being constrained by the remaining pause time. > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > Update TestOptionalRegionGC.java > > Correct the formatting errors Hotspot (gc) PRs need a second reviewer per internal rule to distribute knowledge unless "trivial". No worries, the second review is typically faster... ------------- PR Comment: https://git.openjdk.org/jdk/pull/26880#issuecomment-3279019764 From ghan at openjdk.org Thu Sep 11 08:08:00 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 11 Sep 2025 08:08:00 GMT Subject: RFR: 8352969: G1: Improve testability of optional collections [v10] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 07:57:30 GMT, Thomas Schatzl wrote: >> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: >> >> Update TestOptionalRegionGC.java >> >> Correct the formatting errors > > Hotspot (gc) PRs need a second reviewer per internal rule to distribute knowledge unless "trivial". No worries, the second review is typically faster... @tschatzl Got it, thanks for the clarification! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26880#issuecomment-3279054702 From fandreuzzi at openjdk.org Thu Sep 11 08:13:56 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 11 Sep 2025 08:13:56 GMT Subject: RFR: 8367347: Serial: Refactor CLDScanClosure [v5] In-Reply-To: <36NKvKwcEPTW67nS84mxTb7a_QgYQ-0eZOwAm1nCGxk=.2adf928d-7511-45fd-9518-9ac5f411528c@github.com> References: <36NKvKwcEPTW67nS84mxTb7a_QgYQ-0eZOwAm1nCGxk=.2adf928d-7511-45fd-9518-9ac5f411528c@github.com> Message-ID: > Refactor `CLDScanClosure` so that all CLD logic is encapsulated in the CLD closure, without polluting the oop closure. > > Test: tier1-2, running tier3 Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: _g unused Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27199/files - new: https://git.openjdk.org/jdk/pull/27199/files/a8c79778..b8b537e8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27199&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27199&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27199.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27199/head:pull/27199 PR: https://git.openjdk.org/jdk/pull/27199 From iwalulya at openjdk.org Thu Sep 11 08:22:52 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 11 Sep 2025 08:22:52 GMT Subject: RFR: 8366865: G1: Allocation GC Pauses Triggered after JVM has started shutdown In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 01:41:46 GMT, David Holmes wrote: >> Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. >> >> Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. >> >> Testing: Tier 1-7 > > src/hotspot/share/gc/shared/collectedHeap.cpp line 616: > >> 614: // If the VM is shutting down, we may have skipped VM_CollectForAllocation. >> 615: // To avoid returning nullptr (which could cause premature OOME), we stall >> 616: // allocation requests here until the VM shutdown is complete. > > If I understand the shutdown sequence correctly, I don't think you can do this without risking a hang. The thread doing the shutdown can potentially execute code that requires allocation after `is_shutting_down()` returns true. This is due to the JVMTI events posted from `before_exit`: > > if (JvmtiExport::should_post_thread_life()) { > JvmtiExport::post_thread_end(thread); > } > > // Always call even when there are not JVMTI environments yet, since environments > // may be attached late and JVMTI must track phases of VM execution > JvmtiExport::post_vm_death(); > > I think if you can't GC during shutdown then you have to simply let the allocation fail. Thanks, I completely overlooked the JVMTI callbacks. It?s probably better to stall with a timeout and then return an allocation failure. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2339377413 From ayang at openjdk.org Thu Sep 11 08:47:57 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 11 Sep 2025 08:47:57 GMT Subject: RFR: 8367347: Serial: Refactor CLDScanClosure [v5] In-Reply-To: References: <36NKvKwcEPTW67nS84mxTb7a_QgYQ-0eZOwAm1nCGxk=.2adf928d-7511-45fd-9518-9ac5f411528c@github.com> Message-ID: On Thu, 11 Sep 2025 08:13:56 GMT, Francesco Andreuzzi wrote: >> Refactor `CLDScanClosure` so that all CLD logic is encapsulated in the CLD closure, without polluting the oop closure. >> >> Test: tier1-2, running tier3 > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > _g unused > > Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com> I think placing the bool-var at the first reads better. ------------- Marked as reviewed by ayang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27199#pullrequestreview-3209911014 From tschatzl at openjdk.org Thu Sep 11 08:49:07 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 11 Sep 2025 08:49:07 GMT Subject: RFR: 8366065: ZGC: Differentiate Young Collection type strings in statistics In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 12:21:46 GMT, Joel Sikstr?m wrote: > Hello, > > Currently, two different Young Collection (YC) types print identical strings in the GC statistics at the end of `-Xlog:gc*`. This makes it difficult to distinguish statistics for specific YC types when analyzing logs for performance issues. This PR updates the strings to match the `ZYoungType` enum names, improving traceability and making logs clearer. > > Relevant enum for reference: > ```c++ > enum class ZYoungType { > minor, > major_full_preclean, > major_full_roots, > major_partial_roots, > none > }; > > > Testing: > * GHA Seems good to me. ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26986#pullrequestreview-3209916069 From tschatzl at openjdk.org Thu Sep 11 08:51:00 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 11 Sep 2025 08:51:00 GMT Subject: RFR: 8367339: Parallel: Remove PSScavenge::should_scavenge In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 14:03:20 GMT, Albert Mingkun Yang wrote: > Removing (inlining) a compound method that performs two independent things, loading the obj from a location and checking whether the object belongs to young-gen. Existing callers are changed to use more fine-grained methods, which are more transparent and readable in their context. > > Test: tier1-3 Seems good. ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27193#pullrequestreview-3209934835 From ayang at openjdk.org Thu Sep 11 08:51:02 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 11 Sep 2025 08:51:02 GMT Subject: RFR: 8367339: Parallel: Remove PSScavenge::should_scavenge In-Reply-To: References: Message-ID: <-KSvOarRZaZwN3WzowBf41D6rx-_WCQPKT1-Fa6YxAg=.e6e90e68-8498-4ac3-b1bb-a9ab20ba1c1c@github.com> On Wed, 10 Sep 2025 20:59:16 GMT, Francesco Andreuzzi wrote: >> Removing (inlining) a compound method that performs two independent things, loading the obj from a location and checking whether the object belongs to young-gen. Existing callers are changed to use more fine-grained methods, which are more transparent and readable in their context. >> >> Test: tier1-3 > > src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp line 337: > >> 335: inline void PSPromotionManager::copy_and_push_safe_barrier(T* p) { >> 336: assert(ParallelScavengeHeap::heap()->is_in_reserved(p), "precondition"); >> 337: assert(should_scavenge(p, true), "revisiting object?"); > > This method is `public`, is it safe to remove the assertion? The same assert is repeated inside `PSPromotionManager::copy_to_survivor_space`, which is called a few lines below, so I removed this one. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27193#discussion_r2339514817 From fandreuzzi at openjdk.org Thu Sep 11 08:56:07 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 11 Sep 2025 08:56:07 GMT Subject: RFR: 8367339: Parallel: Remove PSScavenge::should_scavenge In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 14:03:20 GMT, Albert Mingkun Yang wrote: > Removing (inlining) a compound method that performs two independent things, loading the obj from a location and checking whether the object belongs to young-gen. Existing callers are changed to use more fine-grained methods, which are more transparent and readable in their context. > > Test: tier1-3 Marked as reviewed by fandreuzzi (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/27193#pullrequestreview-3209969516 From ayang at openjdk.org Thu Sep 11 08:57:40 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 11 Sep 2025 08:57:40 GMT Subject: RFR: 8367401: Parallel: Remove unused field in PSKeepAliveClosure Message-ID: Trivial removing dead code. Test: tier1 ------------- Commit messages: - src/hotspot/share/gc/parallel/psScavenge.cpp Changes: https://git.openjdk.org/jdk/pull/27210/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27210&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367401 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27210.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27210/head:pull/27210 PR: https://git.openjdk.org/jdk/pull/27210 From tschatzl at openjdk.org Thu Sep 11 09:06:56 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 11 Sep 2025 09:06:56 GMT Subject: RFR: 8367347: Serial: Refactor CLDScanClosure [v5] In-Reply-To: References: <36NKvKwcEPTW67nS84mxTb7a_QgYQ-0eZOwAm1nCGxk=.2adf928d-7511-45fd-9518-9ac5f411528c@github.com> Message-ID: On Thu, 11 Sep 2025 08:13:56 GMT, Francesco Andreuzzi wrote: >> Refactor `CLDScanClosure` so that all CLD logic is encapsulated in the CLD closure, without polluting the oop closure. >> >> Test: tier1-2, running tier3 > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > _g unused > > Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com> Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27199#pullrequestreview-3210044862 From stefank at openjdk.org Thu Sep 11 09:16:54 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 11 Sep 2025 09:16:54 GMT Subject: RFR: 8367401: Parallel: Remove unused field in PSKeepAliveClosure In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 08:50:51 GMT, Albert Mingkun Yang wrote: > Trivial removing dead code. > > Test: tier1 Looks good. I wouldn't mind if you also removed the: assert(_promotion_manager != nullptr, "Sanity"); ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27210#pullrequestreview-3210116886 From ayang at openjdk.org Thu Sep 11 09:26:46 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 11 Sep 2025 09:26:46 GMT Subject: RFR: 8367401: Parallel: Remove unused field in PSKeepAliveClosure In-Reply-To: References: Message-ID: <4AN2MzNMM0xpt9L_Rv6C1VX1biQqnNrg8VRhciBYgVM=.6c2d7d8a-4fb8-4d67-b99a-e86d545b2608@github.com> On Thu, 11 Sep 2025 09:13:56 GMT, Stefan Karlsson wrote: > Looks good. I wouldn't mind if you also removed the: > > ``` > assert(_promotion_manager != nullptr, "Sanity"); > ``` It's to ensure the passed-in arg is not null. There is only one caller, which does provide a valid arg, but for catching misuse more promptly, I'd keep it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27210#issuecomment-3279447585 From fandreuzzi at openjdk.org Thu Sep 11 09:31:57 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 11 Sep 2025 09:31:57 GMT Subject: RFR: 8367401: Parallel: Remove unused field in PSKeepAliveClosure In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 08:50:51 GMT, Albert Mingkun Yang wrote: > Trivial removing dead code. > > Test: tier1 Marked as reviewed by fandreuzzi (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/27210#pullrequestreview-3210209933 From oh.sato at ntt.com Thu Sep 11 09:58:05 2025 From: oh.sato at ntt.com (O Sato) Date: Thu, 11 Sep 2025 09:58:05 +0000 Subject: [Question][ZGC] handshakeAllThreads vs. Per-Thread Handshakes During Mark Phase Termination Message-ID: Hello everyone, I?m trying to better understand how ZGC performs thread coordination at the end of the marking phase. My questions are: * Is handshakeAllThreads used at the end of the mark phase in ZGC? * If so, what is the difference between thread-local handshakes (i.e., handshaking with one thread at a time) and handshakeAllThreads? * Are thread-local handshaking and handshakeAllThreads fundamentally different mechanisms, or just variations of the same mechanism? * What are the trade-offs or reasons for choosing one over the other in this context? Background and observations: While reading the latest ZGC source code, I came across the following call chain near the end of the mark phase: https://github.com/openjdk/jdk/blob/f4d73d2a3dbeccfd04d49c0cfd690086edd0544f/src/hotspot/share/gc/z/zRemembered.cpp#L561C1-L561C49 ZRemembered::scan_and_follow(ZMark* mark) ? ZMark::try_terminate_flush() ? ZMark::flush() ? Handshake::execute() This led me to notice that handshakeAllThreads appears to be used during this process. I was curious about this, as I wondered whether using a global handshake (with all threads) might contribute to observable latency in some cases-although I?m not sure how significant this might be in practice. In contrast, in the following paper: Albert Mingkun Yang and Tobias Wrigstad, ?Deep Dive into ZGC: A Modern Garbage Collector in OpenJDK?, Proceedings of the 33rd ACM SIGPLAN International Conference on Compiler Construction, 2022. https://dl.acm.org/doi/10.1145/3538532 It is stated in Section 3.4 (STW2: The End of the Marking Phase) that: "... thread-local handshaking with each mutator (one mutator at a time) is performed to check for the presence of any to-be-marked objects before attempting an STW pause; this reduces the probability of entering STW2 prematurely." This seems to suggest a more incremental approach (per-thread handshaking), which could be helpful in minimizing pauses. Hence my questions above - I?d appreciate any clarification about the actual behavior and the design decisions behind the use of handshakeAllThreads vs. thread-local handshakes. Thank you! ================== NTT R&D Oh Sato oh.sato at ntt.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From fandreuzzi at openjdk.org Thu Sep 11 10:14:26 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 11 Sep 2025 10:14:26 GMT Subject: RFR: 8367347: Serial: Refactor CLDScanClosure [v6] In-Reply-To: <36NKvKwcEPTW67nS84mxTb7a_QgYQ-0eZOwAm1nCGxk=.2adf928d-7511-45fd-9518-9ac5f411528c@github.com> References: <36NKvKwcEPTW67nS84mxTb7a_QgYQ-0eZOwAm1nCGxk=.2adf928d-7511-45fd-9518-9ac5f411528c@github.com> Message-ID: > Refactor `CLDScanClosure` so that all CLD logic is encapsulated in the CLD closure, without polluting the oop closure. > > Test: tier1-2 Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: bool check early ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27199/files - new: https://git.openjdk.org/jdk/pull/27199/files/b8b537e8..959f9324 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27199&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27199&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27199.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27199/head:pull/27199 PR: https://git.openjdk.org/jdk/pull/27199 From fandreuzzi at openjdk.org Thu Sep 11 10:14:27 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 11 Sep 2025 10:14:27 GMT Subject: RFR: 8367347: Serial: Refactor CLDScanClosure [v4] In-Reply-To: References: <36NKvKwcEPTW67nS84mxTb7a_QgYQ-0eZOwAm1nCGxk=.2adf928d-7511-45fd-9518-9ac5f411528c@github.com> Message-ID: On Thu, 11 Sep 2025 06:32:39 GMT, Stefan Karlsson wrote: > Looks good to me. FWIW, in this and in Albert's previous patch I had to check `is_in_young_gen` to see if it was a trivial check and not something complicated. We could make it easier for the readers if this code: > > ``` > if (is_in_young_gen(new_obj) && !_has_oops_into_young_gen) { > _has_oops_into_young_gen = true; > } > ``` > > were changed to: > > ``` > if (!_has_oops_into_young_gen && is_in_young_gen(new_obj)) { > _has_oops_into_young_gen = true; > } > ``` > > It might also be nicer to the branch predictor. Thanks @stefank, I addressed this in 959f932411d28c22ab101138ae9bb2027bdad990 ------------- PR Comment: https://git.openjdk.org/jdk/pull/27199#issuecomment-3279684433 From aph at openjdk.org Thu Sep 11 10:28:16 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 11 Sep 2025 10:28:16 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v55] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 11:38:38 GMT, Thomas Schatzl wrote: > I can argue I was following precedent :) You were, but it's a precedent that needs to die. > I see your point though. What do you suggest to do here? Use `count` throughout instead? Yes, although it might need a couple more comments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2340016401 From albert.m.yang at oracle.com Thu Sep 11 11:08:43 2025 From: albert.m.yang at oracle.com (Albert Yang) Date: Thu, 11 Sep 2025 11:08:43 +0000 Subject: [Question][ZGC] handshakeAllThreads vs. Per-Thread Handshakes During Mark Phase Termination In-Reply-To: References: Message-ID: > If so, what is the difference between thread-local handshakes (i.e., handshaking with one thread at a time) and handshakeAllThreads? I suspect you probably misunderstood `handshakeAllThreads` -- it's performing handshake, one thread at a time, with all threads, NOT, sync with all-threads altogether. The latter would be a safepoint, which is often more expensive than handshake. In `VM_HandshakeAllThreads`, you can see `bool evaluate_at_safepoint() const { return false; }`. More on safepoint in https://www.youtube.com/watch?v=JkbWPPNc4SI from Markus Gr?nlund, just fyi. PS: the paper you mentioned is about non-generational ZGC, which has been removed from the code base via https://bugs.openjdk.org/browse/JDK-8335850. /Albert ________________________________________ From: hotspot-gc-dev on behalf of O Sato Sent: Thursday, September 11, 2025 11:58 To: hotspot-gc-dev at openjdk.org Subject: [Question][ZGC] handshakeAllThreads vs. Per-Thread Handshakes During Mark Phase Termination Hello everyone, I?m trying to better understand how ZGC performs thread coordination at the end of the marking phase. My questions are: * Is handshakeAllThreads used at the end of the mark phase in ZGC? * If so, what is the difference between thread-local handshakes (i.e., handshaking with one thread at a time) and handshakeAllThreads? * Are thread-local handshaking and handshakeAllThreads fundamentally different mechanisms, or just variations of the same mechanism? * What are the trade-offs or reasons for choosing one over the other in this context? Background and observations: While reading the latest ZGC source code, I came across the following call chain near the end of the mark phase: https://github.com/openjdk/jdk/blob/f4d73d2a3dbeccfd04d49c0cfd690086edd0544f/src/hotspot/share/gc/z/zRemembered.cpp#L561C1-L561C49 ZRemembered::scan_and_follow(ZMark* mark) ? ZMark::try_terminate_flush() ? ZMark::flush() ? Handshake::execute() This led me to notice that handshakeAllThreads appears to be used during this process. I was curious about this, as I wondered whether using a global handshake (with all threads) might contribute to observable latency in some cases?although I?m not sure how significant this might be in practice. In contrast, in the following paper: Albert Mingkun Yang and Tobias Wrigstad, ?Deep Dive into ZGC: A Modern Garbage Collector in OpenJDK?, Proceedings of the 33rd ACM SIGPLAN International Conference on Compiler Construction, 2022. https://dl.acm.org/doi/10.1145/3538532 It is stated in Section 3.4 (STW2: The End of the Marking Phase) that: "... thread-local handshaking with each mutator (one mutator at a time) is performed to check for the presence of any to-be-marked objects before attempting an STW pause; this reduces the probability of entering STW2 prematurely." This seems to suggest a more incremental approach (per-thread handshaking), which could be helpful in minimizing pauses. Hence my questions above ? I?d appreciate any clarification about the actual behavior and the design decisions behind the use of handshakeAllThreads vs. thread-local handshakes. Thank you! ================== NTT R&D Oh Sato oh.sato at ntt.com From ayang at openjdk.org Thu Sep 11 11:22:53 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 11 Sep 2025 11:22:53 GMT Subject: RFR: 8352969: G1: Improve testability of optional collections [v10] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 15:53:28 GMT, Guanqiang Han wrote: >> This PR introduces a new diagnostic flag EvacuateAllOptionalRegions to force G1 GC to evacuate all optional regions regardless of the predicted pause time. The motivation is to allow testing and validation of optional region evacuation behavior without being constrained by the remaining pause time. > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > Update TestOptionalRegionGC.java > > Correct the formatting errors src/hotspot/share/gc/g1/g1CollectionSet.cpp line 417: > 415: G1CSetCandidateGroupList* from_marking_groups = &candidates()->from_marking_groups(); > 416: > 417: #ifdef ASSERT I'd suggest removing `#ifdef ASSERT`; the compiler should be able to remove unreachable code in an optimized build. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26880#discussion_r2340268442 From ayang at openjdk.org Thu Sep 11 11:25:47 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 11 Sep 2025 11:25:47 GMT Subject: RFR: 8367401: Parallel: Remove unused field in PSKeepAliveClosure In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 08:50:51 GMT, Albert Mingkun Yang wrote: > Trivial removing dead code. > > Test: tier1 Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27210#issuecomment-3280043058 From ayang at openjdk.org Thu Sep 11 11:25:53 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 11 Sep 2025 11:25:53 GMT Subject: RFR: 8367339: Parallel: Remove PSScavenge::should_scavenge In-Reply-To: References: Message-ID: <8zOqk4UVEwqQPY1Y0JobIF2Dr7XJq9nsvOPa6PicH1M=.d5fbf2e0-bdbb-4ebc-a61f-67cb51c8b6ac@github.com> On Wed, 10 Sep 2025 14:03:20 GMT, Albert Mingkun Yang wrote: > Removing (inlining) a compound method that performs two independent things, loading the obj from a location and checking whether the object belongs to young-gen. Existing callers are changed to use more fine-grained methods, which are more transparent and readable in their context. > > Test: tier1-3 Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27193#issuecomment-3280042024 From ayang at openjdk.org Thu Sep 11 11:25:47 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 11 Sep 2025 11:25:47 GMT Subject: Integrated: 8367401: Parallel: Remove unused field in PSKeepAliveClosure In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 08:50:51 GMT, Albert Mingkun Yang wrote: > Trivial removing dead code. > > Test: tier1 This pull request has now been integrated. Changeset: 063f970f Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/063f970f0f5e851d72dad0112735692761d6ba36 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod 8367401: Parallel: Remove unused field in PSKeepAliveClosure Reviewed-by: stefank, fandreuzzi ------------- PR: https://git.openjdk.org/jdk/pull/27210 From ayang at openjdk.org Thu Sep 11 11:25:54 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 11 Sep 2025 11:25:54 GMT Subject: Integrated: 8367339: Parallel: Remove PSScavenge::should_scavenge In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 14:03:20 GMT, Albert Mingkun Yang wrote: > Removing (inlining) a compound method that performs two independent things, loading the obj from a location and checking whether the object belongs to young-gen. Existing callers are changed to use more fine-grained methods, which are more transparent and readable in their context. > > Test: tier1-3 This pull request has now been integrated. Changeset: a2d272a0 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/a2d272a02a079e2413d10ad2decb04681ce2f961 Stats: 104 lines in 8 files changed: 4 ins; 91 del; 9 mod 8367339: Parallel: Remove PSScavenge::should_scavenge Reviewed-by: tschatzl, fandreuzzi ------------- PR: https://git.openjdk.org/jdk/pull/27193 From tschatzl at openjdk.org Thu Sep 11 12:20:12 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 11 Sep 2025 12:20:12 GMT Subject: RFR: 8367410: ZGC: Remove unused ZNmethodTable::wait_until_iteration_done() Message-ID: <684m0f5ZVkJPEEut-arf_t8mZ22o-5zv4Ub8gekJYbA=.b0b1ccb1-13d0-4c6f-9ae5-b28e97b25eb9@github.com> Hi all, please review this trivial removal of `ZNmethodTable::wait_until_iteration_done()` as it is never used. Testing: local compilation Thanks, Thomas ------------- Commit messages: - 8367410 Changes: https://git.openjdk.org/jdk/pull/27223/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27223&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367410 Stats: 11 lines in 2 files changed: 0 ins; 10 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27223.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27223/head:pull/27223 PR: https://git.openjdk.org/jdk/pull/27223 From tschatzl at openjdk.org Thu Sep 11 12:34:03 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 11 Sep 2025 12:34:03 GMT Subject: RFR: 8367410: ZGC: Remove unused ZNmethodTable::wait_until_iteration_done() [v2] In-Reply-To: <684m0f5ZVkJPEEut-arf_t8mZ22o-5zv4Ub8gekJYbA=.b0b1ccb1-13d0-4c6f-9ae5-b28e97b25eb9@github.com> References: <684m0f5ZVkJPEEut-arf_t8mZ22o-5zv4Ub8gekJYbA=.b0b1ccb1-13d0-4c6f-9ae5-b28e97b25eb9@github.com> Message-ID: > Hi all, > > please review this trivial removal of `ZNmethodTable::wait_until_iteration_done()` as it is never used. > > Testing: local compilation > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * also make ZNmethodTableIteration::in_progress() private ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27223/files - new: https://git.openjdk.org/jdk/pull/27223/files/974db544..398826c9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27223&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27223&range=00-01 Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27223.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27223/head:pull/27223 PR: https://git.openjdk.org/jdk/pull/27223 From stefank at openjdk.org Thu Sep 11 12:34:03 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 11 Sep 2025 12:34:03 GMT Subject: RFR: 8367410: ZGC: Remove unused ZNmethodTable::wait_until_iteration_done() [v2] In-Reply-To: References: <684m0f5ZVkJPEEut-arf_t8mZ22o-5zv4Ub8gekJYbA=.b0b1ccb1-13d0-4c6f-9ae5-b28e97b25eb9@github.com> Message-ID: On Thu, 11 Sep 2025 12:31:31 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this trivial removal of `ZNmethodTable::wait_until_iteration_done()` as it is never used. >> >> Testing: local compilation >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * also make ZNmethodTableIteration::in_progress() private Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27223#pullrequestreview-3211260290 From ghan at openjdk.org Thu Sep 11 12:34:19 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 11 Sep 2025 12:34:19 GMT Subject: RFR: 8352969: G1: Improve testability of optional collections [v10] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 11:19:51 GMT, Albert Mingkun Yang wrote: >> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: >> >> Update TestOptionalRegionGC.java >> >> Correct the formatting errors > > src/hotspot/share/gc/g1/g1CollectionSet.cpp line 417: > >> 415: G1CSetCandidateGroupList* from_marking_groups = &candidates()->from_marking_groups(); >> 416: >> 417: #ifdef ASSERT > > I'd suggest removing `#ifdef ASSERT`; the compiler should be able to remove unreachable code in an optimized build. Hi @albertnetymk , thanks for the suggestion! While the compiler may indeed optimize away unreachable branches, keeping the `#ifdef ASSERT` here makes it clear that this block is intended for development/debugging and also helps with readability and maintainability for future reviewers. I?m happy to adjust if there?s a preferred convention you?d like me to follow. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26880#discussion_r2340608619 From stefank at openjdk.org Thu Sep 11 12:36:38 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 11 Sep 2025 12:36:38 GMT Subject: RFR: 8367401: Parallel: Remove unused field in PSKeepAliveClosure In-Reply-To: <4AN2MzNMM0xpt9L_Rv6C1VX1biQqnNrg8VRhciBYgVM=.6c2d7d8a-4fb8-4d67-b99a-e86d545b2608@github.com> References: <4AN2MzNMM0xpt9L_Rv6C1VX1biQqnNrg8VRhciBYgVM=.6c2d7d8a-4fb8-4d67-b99a-e86d545b2608@github.com> Message-ID: On Thu, 11 Sep 2025 09:24:05 GMT, Albert Mingkun Yang wrote: > > Looks good. I wouldn't mind if you also removed the: > > ``` > > assert(_promotion_manager != nullptr, "Sanity"); > > ``` > > It's to ensure the passed-in arg is not null. There is only one caller, which does provide a valid arg, but for catching misuse more promptly, I'd keep it. Yes, that's obvious. You would crash immediately during development if you ever try to pass in a null object here. And the same goes for thousands of other places in the GC that don't null check the arguments. So, having this one-of null check seems a bit silly to me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27210#issuecomment-3280403461 From ayang at openjdk.org Thu Sep 11 12:53:42 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 11 Sep 2025 12:53:42 GMT Subject: RFR: 8367401: Parallel: Remove unused field in PSKeepAliveClosure In-Reply-To: References: <4AN2MzNMM0xpt9L_Rv6C1VX1biQqnNrg8VRhciBYgVM=.6c2d7d8a-4fb8-4d67-b99a-e86d545b2608@github.com> Message-ID: <4IThM3oO15keBtDu-soKn9hFb6nnWd-er4jy2IzcLmg=.5162a4f6-cf30-43fe-b440-58d1e02e2b34@github.com> On Thu, 11 Sep 2025 12:33:13 GMT, Stefan Karlsson wrote: > You would crash immediately during development if you ever try to pass in a null object here. Not immediately. The actual use of this field is in `do_oop_work`, which might not be invoked, if there are no objs that need to be kept alive. OTOH, the constructor is always invoked during young-gc. Therefore, this `assert` will catch the misuse more promptly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27210#issuecomment-3280488312 From ayang at openjdk.org Thu Sep 11 13:00:04 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 11 Sep 2025 13:00:04 GMT Subject: RFR: 8352969: G1: Improve testability of optional collections [v10] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 12:30:29 GMT, Guanqiang Han wrote: >> src/hotspot/share/gc/g1/g1CollectionSet.cpp line 417: >> >>> 415: G1CSetCandidateGroupList* from_marking_groups = &candidates()->from_marking_groups(); >>> 416: >>> 417: #ifdef ASSERT >> >> I'd suggest removing `#ifdef ASSERT`; the compiler should be able to remove unreachable code in an optimized build. > > Hi @albertnetymk , thanks for the suggestion! While the compiler may indeed optimize away unreachable branches, > keeping the `#ifdef ASSERT` here makes it clear that this block is intended for development/debugging > and also helps with readability and maintainability for future reviewers. > I?m happy to adjust if there?s a preferred convention you?d like me to follow. If the code guarded by `#ifdef` is well isolated from the actual code, I'd agree separating them improves readability. In this case, the debug code is kind of mixed with the real code (especially the one inside the for-loop), having `#ifdef` breaks the contiguity of the flow, IMO. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26880#discussion_r2340730607 From stefank at openjdk.org Thu Sep 11 13:08:16 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 11 Sep 2025 13:08:16 GMT Subject: RFR: 8367401: Parallel: Remove unused field in PSKeepAliveClosure In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 08:50:51 GMT, Albert Mingkun Yang wrote: > Trivial removing dead code. > > Test: tier1 I'm still convinced that you would find this programming error immediately in your local testing, even before you send of a patch for CI testing. Then you could see in your debugger that the filed was null. I think we're holding on to this assert because it was added some time ago, not because it is important to have. I don't think we would have added it if the code was written today. Case in-point, take a look at the rewrite you did in the latest PR: https://github.com/openjdk/jdk/pull/27165 There's no null check of the `_pm` fields there. Anyways, we can keep the check, I just think that it has marginal value here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27210#issuecomment-3280556610 From ayang at openjdk.org Thu Sep 11 13:16:12 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 11 Sep 2025 13:16:12 GMT Subject: RFR: 8367417: Serial: Use NMethodToOopClosure during Young GC Message-ID: <0cxHO0STcFcvdzE2UyoXFQB5Xz3IvGoHX2xb6fr3hW8=.de6c8353-4aea-42bc-bc56-1841a60f2e99@github.com> Change `MarkingNMethodClosure` to `NMethodToOopClosure` in young-gc, because no marking is done during young-gc. After that, `StrongRootsScope` becomes unnecessary as well, it's essentially calling `oops_do_marking_epilogue` to undo the effect of `MarkingNMethodClosure`. Test: tier1-5 ------------- Commit messages: - sgc-nmethod Changes: https://git.openjdk.org/jdk/pull/27226/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27226&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367417 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27226.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27226/head:pull/27226 PR: https://git.openjdk.org/jdk/pull/27226 From jsikstro at openjdk.org Thu Sep 11 13:42:33 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Thu, 11 Sep 2025 13:42:33 GMT Subject: RFR: 8367413: Use size_t instead of julong in runtime/arguments.cpp [v2] In-Reply-To: References: Message-ID: > Hello, > > There are several unnecessary uses of the julong type in arguments.cpp that could use size_t instead to fit in better with surrounding code. Almost all flags that are read in arguments.cpp are size_t, and the os functions it interacts with were changed from julong to size_t in [JDK-8357086](https://bugs.openjdk.org/browse/JDK-8357086) or are already taking in size_t. > > The main usage of julong in runtime/arguments.cpp is in Arguments::set_heap_size() and Arguments::set_aggressive_heap_flags(), where there are a lot of casts from julong types to size_t which could be removed with this change. > > Testing: > * Running through Oracle's tier1-3 on all Oracle supported platforms Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: size_t casts for 32-bit part of test_arguments.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27224/files - new: https://git.openjdk.org/jdk/pull/27224/files/35c6057a..dba2ab46 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27224&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27224&range=00-01 Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/27224.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27224/head:pull/27224 PR: https://git.openjdk.org/jdk/pull/27224 From ayang at openjdk.org Thu Sep 11 13:49:37 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 11 Sep 2025 13:49:37 GMT Subject: RFR: 8367413: Use size_t instead of julong in runtime/arguments.cpp [v2] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 13:42:33 GMT, Joel Sikstr?m wrote: >> Hello, >> >> There are several unnecessary uses of the julong type in arguments.cpp that could use size_t instead to fit in better with surrounding code. Almost all flags that are read in arguments.cpp are size_t, and the os functions it interacts with were changed from julong to size_t in [JDK-8357086](https://bugs.openjdk.org/browse/JDK-8357086) or are already taking in size_t. >> >> The main usage of julong in runtime/arguments.cpp is in Arguments::set_heap_size() and Arguments::set_aggressive_heap_flags(), where there are a lot of casts from julong types to size_t which could be removed with this change. >> >> Testing: >> * Running through Oracle's tier1-3 on all Oracle supported platforms > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > size_t casts for 32-bit part of test_arguments.cpp src/hotspot/share/runtime/arguments.cpp line 1526: > 1524: FLAG_SET_ERGO(MaxRAM, (uint64_t)phys_mem); > 1525: } else { > 1526: phys_mem = (size_t)MaxRAM; Pre-existing: I wonder if this should be `MIN2(MaxRAM, SIZE_MAX)` to handle 32-bit systems. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27224#discussion_r2340949951 From stefank at openjdk.org Thu Sep 11 13:53:24 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 11 Sep 2025 13:53:24 GMT Subject: RFR: 8367347: Serial: Refactor CLDScanClosure [v6] In-Reply-To: References: <36NKvKwcEPTW67nS84mxTb7a_QgYQ-0eZOwAm1nCGxk=.2adf928d-7511-45fd-9518-9ac5f411528c@github.com> Message-ID: On Thu, 11 Sep 2025 10:14:26 GMT, Francesco Andreuzzi wrote: >> Refactor `CLDScanClosure` so that all CLD logic is encapsulated in the CLD closure, without polluting the oop closure. >> >> Test: tier1-2 > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > bool check early Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27199#pullrequestreview-3211730384 From ayang at openjdk.org Thu Sep 11 14:07:54 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 11 Sep 2025 14:07:54 GMT Subject: RFR: 8367422: Parallel: Refactor local varibles names in copy_unmarked_to_survivor_space Message-ID: Trivial "renaming" a local variable and its type to better reflect its semantic and avoid much `HeapWord*`-vs-`oop` conversion. Test: Comparing the generated asm in release build and they are identical. ------------- Commit messages: - pgc-rename Changes: https://git.openjdk.org/jdk/pull/27227/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27227&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367422 Stats: 11 lines in 1 file changed: 1 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/27227.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27227/head:pull/27227 PR: https://git.openjdk.org/jdk/pull/27227 From duke at openjdk.org Thu Sep 11 14:21:44 2025 From: duke at openjdk.org (duke) Date: Thu, 11 Sep 2025 14:21:44 GMT Subject: RFR: 8367347: Serial: Refactor CLDScanClosure [v6] In-Reply-To: References: <36NKvKwcEPTW67nS84mxTb7a_QgYQ-0eZOwAm1nCGxk=.2adf928d-7511-45fd-9518-9ac5f411528c@github.com> Message-ID: On Thu, 11 Sep 2025 10:14:26 GMT, Francesco Andreuzzi wrote: >> Refactor `CLDScanClosure` so that all CLD logic is encapsulated in the CLD closure, without polluting the oop closure. >> >> Test: tier1-2 > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > bool check early @fandreuz Your change (at version 959f932411d28c22ab101138ae9bb2027bdad990) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27199#issuecomment-3281017474 From fandreuzzi at openjdk.org Thu Sep 11 14:25:30 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 11 Sep 2025 14:25:30 GMT Subject: RFR: 8367422: Parallel: Refactor local varibles names in copy_unmarked_to_survivor_space In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 13:59:20 GMT, Albert Mingkun Yang wrote: > Trivial "renaming" a local variable and its type to better reflect its semantic and avoid much `HeapWord*`-vs-`oop` conversion. > > Test: Comparing the generated asm in release build and they are identical. Marked as reviewed by fandreuzzi (Author). @albertnetymk I think you've got a typo in the ticket title ------------- PR Review: https://git.openjdk.org/jdk/pull/27227#pullrequestreview-3211930049 PR Comment: https://git.openjdk.org/jdk/pull/27227#issuecomment-3281020111 From asteiner at openjdk.org Thu Sep 11 14:32:19 2025 From: asteiner at openjdk.org (Andreas Steiner) Date: Thu, 11 Sep 2025 14:32:19 GMT Subject: RFR: 8359104: gc/TestAlwaysPreTouchBehavior.java# fails on Linux [v3] In-Reply-To: References: Message-ID: > Get accurate RSS, from smaps_rollup if available(Linux >= 4.14), because the RSS from status is inaccurate especially on systems with more than 32 CPUs. > > Not sure if all the additional meminfos like the Pss, Pss_dirty, Pss_Anon, Pss_File, Pss_Shmem, Swap and SwapPss are really needed too. But can be perhaps helpful too. > > As the inaccurate memory infos are still used in other methods: > - [print_process_memory_info()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L2393) > - [jfr_report_memory_info()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L2686) > - [trim_native_heap()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L5376) > > one can think about to use the accurate values there too. Andreas Steiner has updated the pull request incrementally with one additional commit since the last revision: Changed num_found and num_values to size_t, do the null-check right after the fopen and return early, eliminated the variable shadowing of info ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27192/files - new: https://git.openjdk.org/jdk/pull/27192/files/97d88b64..6c6fc40e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27192&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27192&range=01-02 Stats: 27 lines in 1 file changed: 5 ins; 3 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/27192.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27192/head:pull/27192 PR: https://git.openjdk.org/jdk/pull/27192 From mbaesken at openjdk.org Thu Sep 11 14:32:19 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 11 Sep 2025 14:32:19 GMT Subject: RFR: 8359104: gc/TestAlwaysPreTouchBehavior.java# fails on Linux [v3] In-Reply-To: References: Message-ID: <5xaY_spQIDWHvpTxxS-aSIezGRG6X6980W9qCZUXvzg=.07b03913-d7a5-46ad-a41e-f77d1d2299e5@github.com> On Thu, 11 Sep 2025 14:29:27 GMT, Andreas Steiner wrote: >> Get accurate RSS, from smaps_rollup if available(Linux >= 4.14), because the RSS from status is inaccurate especially on systems with more than 32 CPUs. >> >> Not sure if all the additional meminfos like the Pss, Pss_dirty, Pss_Anon, Pss_File, Pss_Shmem, Swap and SwapPss are really needed too. But can be perhaps helpful too. >> >> As the inaccurate memory infos are still used in other methods: >> - [print_process_memory_info()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L2393) >> - [jfr_report_memory_info()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L2686) >> - [trim_native_heap()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L5376) >> >> one can think about to use the accurate values there too. > > Andreas Steiner has updated the pull request incrementally with one additional commit since the last revision: > > Changed num_found and num_values to size_t, do the null-check right after the fopen and return early, eliminated the variable shadowing of info Looks still good (and even better than before) ! ------------- Marked as reviewed by mbaesken (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27192#pullrequestreview-3211973683 From asteiner at openjdk.org Thu Sep 11 14:32:22 2025 From: asteiner at openjdk.org (Andreas Steiner) Date: Thu, 11 Sep 2025 14:32:22 GMT Subject: RFR: 8359104: gc/TestAlwaysPreTouchBehavior.java# fails on Linux [v3] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 14:32:54 GMT, Francesco Andreuzzi wrote: >> Andreas Steiner has updated the pull request incrementally with one additional commit since the last revision: >> >> Changed num_found and num_values to size_t, do the null-check right after the fopen and return early, eliminated the variable shadowing of info > > src/hotspot/os/linux/os_linux.cpp line 2377: > >> 2375: bool os::Linux::query_accurate_process_memory_info(os::Linux::accurate_meminfo_t* info) { >> 2376: FILE* f = os::fopen("/proc/self/smaps_rollup", "r"); >> 2377: const int num_values = sizeof(os::Linux::accurate_meminfo_t) / sizeof(size_t); > > Should this and `num_found` be `size_t`? Even this was copied from the existing query_process_memory_info I adapted this now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27192#discussion_r2341147963 From asteiner at openjdk.org Thu Sep 11 14:32:23 2025 From: asteiner at openjdk.org (Andreas Steiner) Date: Thu, 11 Sep 2025 14:32:23 GMT Subject: RFR: 8359104: gc/TestAlwaysPreTouchBehavior.java# fails on Linux [v3] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 12:58:55 GMT, Albert Mingkun Yang wrote: >> src/hotspot/os/linux/os_linux.cpp line 2382: >> >>> 2380: info->rss = info->pss = info->pssdirty = info->pssanon = >>> 2381: info->pssfile = info->pssshmem = info->swap = info->swappss = -1; >>> 2382: if (f != nullptr) { >> >> You could consider inverting this check, and early-return `false` if `f==nullptr`. That would spare one indentation level > > I agree; the null-check should be done right after `fopen` to early-return if sth is wrong. Even this was copied from the existing query_process_memory_info I adapted this now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27192#discussion_r2341149494 From fandreuzzi at openjdk.org Thu Sep 11 14:41:06 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 11 Sep 2025 14:41:06 GMT Subject: Integrated: 8367347: Serial: Refactor CLDScanClosure In-Reply-To: <36NKvKwcEPTW67nS84mxTb7a_QgYQ-0eZOwAm1nCGxk=.2adf928d-7511-45fd-9518-9ac5f411528c@github.com> References: <36NKvKwcEPTW67nS84mxTb7a_QgYQ-0eZOwAm1nCGxk=.2adf928d-7511-45fd-9518-9ac5f411528c@github.com> Message-ID: On Wed, 10 Sep 2025 16:26:39 GMT, Francesco Andreuzzi wrote: > Refactor `CLDScanClosure` so that all CLD logic is encapsulated in the CLD closure, without polluting the oop closure. > > Test: tier1-2 This pull request has now been integrated. Changeset: ec743233 Author: Francesco Andreuzzi Committer: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/ec7432331ba09cc2d257af51abc494aab209d912 Stats: 33 lines in 1 file changed: 8 ins; 14 del; 11 mod 8367347: Serial: Refactor CLDScanClosure Reviewed-by: stefank, ayang, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/27199 From ghan at openjdk.org Thu Sep 11 14:44:33 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 11 Sep 2025 14:44:33 GMT Subject: RFR: 8352969: G1: Improve testability of optional collections [v11] In-Reply-To: References: Message-ID: > This PR introduces a new diagnostic flag EvacuateAllOptionalRegions to force G1 GC to evacuate all optional regions regardless of the predicted pause time. The motivation is to allow testing and validation of optional region evacuation behavior without being constrained by the remaining pause time. Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: - Remove #ifdef ASSERT; compiler will optimize unreachable branches - Merge remote-tracking branch 'upstream/master' into 8352969 - Update TestOptionalRegionGC.java Correct the formatting errors - fix a small error - fix format error. - optimize implementation - Merge remote-tracking branch 'upstream/master' into 8352969 - change flag name - Merge remote-tracking branch 'upstream/master' into 8352969 - fix format error - ... and 7 more: https://git.openjdk.org/jdk/compare/fc3e3e26...1fc245af ------------- Changes: https://git.openjdk.org/jdk/pull/26880/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26880&range=10 Stats: 156 lines in 5 files changed: 146 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/26880.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26880/head:pull/26880 PR: https://git.openjdk.org/jdk/pull/26880 From ayang at openjdk.org Thu Sep 11 14:48:01 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 11 Sep 2025 14:48:01 GMT Subject: RFR: 8359104: gc/TestAlwaysPreTouchBehavior.java# fails on Linux [v3] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 14:32:19 GMT, Andreas Steiner wrote: >> Get accurate RSS, from smaps_rollup if available(Linux >= 4.14), because the RSS from status is inaccurate especially on systems with more than 32 CPUs. >> >> Not sure if all the additional meminfos like the Pss, Pss_dirty, Pss_Anon, Pss_File, Pss_Shmem, Swap and SwapPss are really needed too. But can be perhaps helpful too. >> >> As the inaccurate memory infos are still used in other methods: >> - [print_process_memory_info()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L2393) >> - [jfr_report_memory_info()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L2686) >> - [trim_native_heap()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L5376) >> >> one can think about to use the accurate values there too. > > Andreas Steiner has updated the pull request incrementally with one additional commit since the last revision: > > Changed num_found and num_values to size_t, do the null-check right after the fopen and return early, eliminated the variable shadowing of info Marked as reviewed by ayang (Reviewer). src/hotspot/os/linux/os_linux.cpp line 2395: > 2393: (info->pssshmem == -1 && sscanf(buf, "Pss_Shmem: %zd kB", &info->pssshmem) == 1) || > 2394: (info->swap == -1 && sscanf(buf, "Swap: %zd kB", &info->swap) == 1) || > 2395: (info->swappss == -1 && sscanf(buf, "SwapPss: %zd kB", &info->swappss) == 1) I'd probably align `== -1 &&` and `==1)`. ------------- PR Review: https://git.openjdk.org/jdk/pull/27192#pullrequestreview-3212076914 PR Review Comment: https://git.openjdk.org/jdk/pull/27192#discussion_r2341228607 From ayang at openjdk.org Thu Sep 11 14:49:53 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 11 Sep 2025 14:49:53 GMT Subject: RFR: 8352969: G1: Improve testability of optional collections [v11] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 14:44:33 GMT, Guanqiang Han wrote: >> This PR introduces a new diagnostic flag EvacuateAllOptionalRegions to force G1 GC to evacuate all optional regions regardless of the predicted pause time. The motivation is to allow testing and validation of optional region evacuation behavior without being constrained by the remaining pause time. > > Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: > > - Remove #ifdef ASSERT; compiler will optimize unreachable branches > - Merge remote-tracking branch 'upstream/master' into 8352969 > - Update TestOptionalRegionGC.java > > Correct the formatting errors > - fix a small error > - fix format error. > - optimize implementation > - Merge remote-tracking branch 'upstream/master' into 8352969 > - change flag name > - Merge remote-tracking branch 'upstream/master' into 8352969 > - fix format error > - ... and 7 more: https://git.openjdk.org/jdk/compare/fc3e3e26...1fc245af Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26880#pullrequestreview-3212089205 From ghan at openjdk.org Thu Sep 11 14:49:55 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 11 Sep 2025 14:49:55 GMT Subject: RFR: 8352969: G1: Improve testability of optional collections [v10] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 12:56:53 GMT, Albert Mingkun Yang wrote: >> Hi @albertnetymk , thanks for the suggestion! While the compiler may indeed optimize away unreachable branches, >> keeping the `#ifdef ASSERT` here makes it clear that this block is intended for development/debugging >> and also helps with readability and maintainability for future reviewers. >> I?m happy to adjust if there?s a preferred convention you?d like me to follow. > > If the code guarded by `#ifdef` is well isolated from the actual code, I'd agree separating them improves readability. In this case, the debug code is kind of mixed with the real code (especially the one inside the for-loop), having `#ifdef` breaks the contiguity of the flow, IMO. Hi @albertnetymk , fixed ! Please take a look. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26880#discussion_r2341234884 From ghan at openjdk.org Thu Sep 11 15:11:55 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 11 Sep 2025 15:11:55 GMT Subject: RFR: 8352969: G1: Improve testability of optional collections [v11] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 14:46:45 GMT, Albert Mingkun Yang wrote: >> Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: >> >> - Remove #ifdef ASSERT; compiler will optimize unreachable branches >> - Merge remote-tracking branch 'upstream/master' into 8352969 >> - Update TestOptionalRegionGC.java >> >> Correct the formatting errors >> - fix a small error >> - fix format error. >> - optimize implementation >> - Merge remote-tracking branch 'upstream/master' into 8352969 >> - change flag name >> - Merge remote-tracking branch 'upstream/master' into 8352969 >> - fix format error >> - ... and 7 more: https://git.openjdk.org/jdk/compare/fc3e3e26...1fc245af > > Marked as reviewed by ayang (Reviewer). Hi @albertnetymk, thank you for approval. I?ve integrated this PR. Could you please sponsor it? Thanks! @albertnetymk Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26880#issuecomment-3281296086 PR Comment: https://git.openjdk.org/jdk/pull/26880#issuecomment-3281312599 From ghan at openjdk.org Thu Sep 11 15:11:57 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 11 Sep 2025 15:11:57 GMT Subject: Integrated: 8352969: G1: Improve testability of optional collections In-Reply-To: References: Message-ID: On Thu, 21 Aug 2025 10:10:23 GMT, Guanqiang Han wrote: > This PR introduces a new diagnostic flag EvacuateAllOptionalRegions to force G1 GC to evacuate all optional regions regardless of the predicted pause time. The motivation is to allow testing and validation of optional region evacuation behavior without being constrained by the remaining pause time. This pull request has now been integrated. Changeset: e172e6a4 Author: Guanqiang Han Committer: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/e172e6a4e37cf06afee662625a01193f5528a2b1 Stats: 156 lines in 5 files changed: 146 ins; 0 del; 10 mod 8352969: G1: Improve testability of optional collections Reviewed-by: ayang, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/26880 From ghan at openjdk.org Thu Sep 11 15:38:30 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 11 Sep 2025 15:38:30 GMT Subject: RFR: 8367424: Cleanup unused time_remaining_ms update in G1CollectionSet::select_optional_groups Message-ID: Please review this PR. This is a trivial change that simply removes unused code. ------------- Commit messages: - 8367424: Cleanup unused time_remaining_ms update in G1CollectionSet::select_optional_groups Changes: https://git.openjdk.org/jdk/pull/27229/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27229&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367424 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27229.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27229/head:pull/27229 PR: https://git.openjdk.org/jdk/pull/27229 From fandreuzzi at openjdk.org Thu Sep 11 17:22:00 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 11 Sep 2025 17:22:00 GMT Subject: RFR: 8367410: ZGC: Remove unused ZNmethodTable::wait_until_iteration_done() [v2] In-Reply-To: References: <684m0f5ZVkJPEEut-arf_t8mZ22o-5zv4Ub8gekJYbA=.b0b1ccb1-13d0-4c6f-9ae5-b28e97b25eb9@github.com> Message-ID: On Thu, 11 Sep 2025 12:34:03 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this trivial removal of `ZNmethodTable::wait_until_iteration_done()` as it is never used. >> >> Testing: local compilation >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * also make ZNmethodTableIteration::in_progress() private Marked as reviewed by fandreuzzi (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/27223#pullrequestreview-3212918569 From ssubramaniam at openjdk.org Thu Sep 11 17:26:43 2025 From: ssubramaniam at openjdk.org (Satyen Subramaniam) Date: Thu, 11 Sep 2025 17:26:43 GMT Subject: RFR: 8367372: Test `test/hotspot/jtreg/gc/TestObjectAlignmentCardSize.java` fails on 32 bit systems Message-ID: On 32-bit systems, the `test/hotspot/jtreg/gc/TestObjectAlignmentCardSize.java` uses the `ObjectAlignmentInBytes` flag, which isn't supported on 32 bit systems. I'm adjusting this test to require `vm.bits` is 64 as per similar [tests](https://sim.amazon.com/issues/JDK-14885). Tested on: * 64-bit: with and without change (passes both times) * 32-bit: with and without change (fails before, skips after) Note: seeing some GHA failures, but unrelated to the actual test. ------------- Commit messages: - Adjusting copyright - Requiring 64 bit for TestObjectAlignmentCardSize.java Changes: https://git.openjdk.org/jdk/pull/27230/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27230&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367372 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27230.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27230/head:pull/27230 PR: https://git.openjdk.org/jdk/pull/27230 From stefank at openjdk.org Thu Sep 11 19:05:42 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 11 Sep 2025 19:05:42 GMT Subject: RFR: 8367372: Test `test/hotspot/jtreg/gc/TestObjectAlignmentCardSize.java` fails on 32 bit systems In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 17:18:11 GMT, Satyen Subramaniam wrote: > On 32-bit systems, the `test/hotspot/jtreg/gc/TestObjectAlignmentCardSize.java` uses the `ObjectAlignmentInBytes` flag, which isn't supported on 32 bit systems. I'm adjusting this test to require `vm.bits` is 64 as per similar [tests](https://github.com/openjdk/jdk/blob/85715e1050fa774c3267dbbe2f749717aeeec8ff/test/hotspot/jtreg/runtime/CompressedOops/CompressedKlassPointerAndOops.java#L31). > > Tested on: > * 64-bit: with and without change (passes both times) > * 32-bit: with and without change (fails before, skips after) > Note: seeing some GHA failures, but unrelated to the actual test. Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27230#pullrequestreview-3213266621 From fandreuzzi at openjdk.org Thu Sep 11 20:20:26 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 11 Sep 2025 20:20:26 GMT Subject: RFR: 8367417: Serial: Use NMethodToOopClosure during Young GC In-Reply-To: <0cxHO0STcFcvdzE2UyoXFQB5Xz3IvGoHX2xb6fr3hW8=.de6c8353-4aea-42bc-bc56-1841a60f2e99@github.com> References: <0cxHO0STcFcvdzE2UyoXFQB5Xz3IvGoHX2xb6fr3hW8=.de6c8353-4aea-42bc-bc56-1841a60f2e99@github.com> Message-ID: On Thu, 11 Sep 2025 13:07:11 GMT, Albert Mingkun Yang wrote: > Change `MarkingNMethodClosure` to `NMethodToOopClosure` in young-gc, because no marking is done during young-gc. After that, `StrongRootsScope` becomes unnecessary as well, it's essentially calling `oops_do_marking_epilogue` to undo the effect of `MarkingNMethodClosure`. > > Test: tier1-5 Marked as reviewed by fandreuzzi (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/27226#pullrequestreview-3213491784 From wkemper at openjdk.org Thu Sep 11 20:35:41 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 11 Sep 2025 20:35:41 GMT Subject: RFR: 8367378: GenShen: Missing timing stats when old mark buffers are flushed during final update refs Message-ID: This change adds timing to the 'flush old SATB buffers' subphase of final update refs. Ultimately, we hope to move this phase to a handshake (or not have it all). In the interim, we should at least know how long it takes. The updated phase timings message in the logs has the form: [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats ] Pause Final Update Refs (N) 377 us, workers (us): ---, ---, ---, ---, ---, ---, ---, ---, [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats ] Update Region States 98 us [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats ] Transfer Old From SATB 74 us [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats ] Trash Collection Set 48 us [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats ] Rebuild Free Set 132 us [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats ] Propagate GC State 6 us The `Transfer Old From SATB` is new. ------------- Commit messages: - Add timing for satb purge during update final refs Changes: https://git.openjdk.org/jdk/pull/27234/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27234&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367378 Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27234.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27234/head:pull/27234 PR: https://git.openjdk.org/jdk/pull/27234 From kdnilsen at openjdk.org Thu Sep 11 21:12:38 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 11 Sep 2025 21:12:38 GMT Subject: RFR: 8367378: GenShen: Missing timing stats when old mark buffers are flushed during final update refs In-Reply-To: References: Message-ID: <9Wt0z9OmTgnJ3YQAXWERZHplZxf_KHTa929NtzXdmuQ=.5d635ab0-c379-4b88-8d16-24736a071184@github.com> On Thu, 11 Sep 2025 20:28:08 GMT, William Kemper wrote: > This change adds timing to the 'flush old SATB buffers' subphase of final update refs. Ultimately, we hope to move this phase to a handshake (or not have it all). In the interim, we should at least know how long it takes. The updated phase timings message in the logs has the form: > > [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats ] Pause Final Update Refs (N) 377 us, workers (us): ---, ---, ---, ---, ---, ---, ---, ---, > [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats ] Update Region States 98 us > [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats ] Transfer Old From SATB 74 us > [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats ] Trash Collection Set 48 us > [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats ] Rebuild Free Set 132 us > [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats ] Propagate GC State 6 us > > The `Transfer Old From SATB` is new. Thanks much ------------- Marked as reviewed by kdnilsen (Committer). PR Review: https://git.openjdk.org/jdk/pull/27234#pullrequestreview-3213649690 From wkemper at openjdk.org Thu Sep 11 21:46:44 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 11 Sep 2025 21:46:44 GMT Subject: RFR: 8367450: Shenandoah: Log the composition of the collection set Message-ID: Reuse the same log message from GenShen which details the composition of the live data to be evacuated. In the non-generational modes, all regions are considered young and nothing will be promoted (or old). ------------- Commit messages: - Log the composition of live data within the collection set Changes: https://git.openjdk.org/jdk/pull/27235/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27235&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367450 Stats: 118 lines in 5 files changed: 36 ins; 55 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/27235.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27235/head:pull/27235 PR: https://git.openjdk.org/jdk/pull/27235 From wkemper at openjdk.org Thu Sep 11 22:22:52 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 11 Sep 2025 22:22:52 GMT Subject: RFR: 8367451: GenShen: Remove the option to compute age census during evacuation Message-ID: This experimental option has always defaulted to false. We are working on changes that will make it impractical to maintain this option. We also do not regularly test this configuration. ------------- Commit messages: - Remove the option to compute age census at evacuation Changes: https://git.openjdk.org/jdk/pull/27236/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27236&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367451 Stats: 18 lines in 7 files changed: 0 ins; 5 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/27236.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27236/head:pull/27236 PR: https://git.openjdk.org/jdk/pull/27236 From duke at openjdk.org Thu Sep 11 22:42:26 2025 From: duke at openjdk.org (duke) Date: Thu, 11 Sep 2025 22:42:26 GMT Subject: RFR: 8367372: Test `test/hotspot/jtreg/gc/TestObjectAlignmentCardSize.java` fails on 32 bit systems In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 17:18:11 GMT, Satyen Subramaniam wrote: > On 32-bit systems, the `test/hotspot/jtreg/gc/TestObjectAlignmentCardSize.java` uses the `ObjectAlignmentInBytes` flag, which isn't supported on 32 bit systems. I'm adjusting this test to require `vm.bits` is 64 as per similar [tests](https://github.com/openjdk/jdk/blob/85715e1050fa774c3267dbbe2f749717aeeec8ff/test/hotspot/jtreg/runtime/CompressedOops/CompressedKlassPointerAndOops.java#L31). > > Tested on: > * 64-bit: with and without change (passes both times) > * 32-bit: with and without change (fails before, skips after) > Note: seeing some GHA failures, but unrelated to the actual test. @satyenme Your change (at version 485aac3fb75148cc425515c0f5d0e74f2d231d43) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27230#issuecomment-3282852299 From fandreuzzi at openjdk.org Thu Sep 11 22:44:24 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 11 Sep 2025 22:44:24 GMT Subject: RFR: 8367472: Swap conditions order in PSScavengeCLDOopClosure::do_oop(oop*) Message-ID: In this PR I propose to swap the order of conditions in `PSScavengeCLDOopClosure::do_oop`, as proposed during the review of #27199. This change will move the trivial check first in the `if` clause, which is easier for the reader and potentially for the branch predictor. This will also bring parity with `CLDOopClosure` (Serial). Passes `tier1`. ------------- Commit messages: - swap Changes: https://git.openjdk.org/jdk/pull/27237/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27237&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367472 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27237.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27237/head:pull/27237 PR: https://git.openjdk.org/jdk/pull/27237 From kdnilsen at openjdk.org Thu Sep 11 23:22:18 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 11 Sep 2025 23:22:18 GMT Subject: RFR: 8367451: GenShen: Remove the option to compute age census during evacuation In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 22:16:15 GMT, William Kemper wrote: > This experimental option has always defaulted to false. We are working on changes that will make it impractical to maintain this option. We also do not regularly test this configuration. Thanks. ------------- Marked as reviewed by kdnilsen (Committer). PR Review: https://git.openjdk.org/jdk/pull/27236#pullrequestreview-3213980261 From kdnilsen at openjdk.org Thu Sep 11 23:28:13 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 11 Sep 2025 23:28:13 GMT Subject: RFR: 8367450: Shenandoah: Log the composition of the collection set In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 21:40:50 GMT, William Kemper wrote: > Reuse the same log message from GenShen which details the composition of the live data to be evacuated. In the non-generational modes, all regions are considered young and nothing will be promoted (or old). Thanks. Very nice improvement. ------------- Marked as reviewed by kdnilsen (Committer). PR Review: https://git.openjdk.org/jdk/pull/27235#pullrequestreview-3213992068 From stefank at openjdk.org Fri Sep 12 05:55:16 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 12 Sep 2025 05:55:16 GMT Subject: RFR: 8367472: Swap conditions order in PSScavengeCLDOopClosure::do_oop(oop*) In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 22:36:52 GMT, Francesco Andreuzzi wrote: > In this PR I propose to swap the order of conditions in `PSScavengeCLDOopClosure::do_oop`, as proposed during the review of #27199. This change will move the trivial check first in the `if` clause, which is easier for the reader and potentially for the branch predictor. This will also bring parity with `CLDOopClosure` (Serial). > > Passes `tier1`. Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27237#pullrequestreview-3214758178 From xpeng at openjdk.org Fri Sep 12 06:42:17 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 12 Sep 2025 06:42:17 GMT Subject: RFR: 8367378: GenShen: Missing timing stats when old mark buffers are flushed during final update refs In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 20:28:08 GMT, William Kemper wrote: > This change adds timing to the 'flush old SATB buffers' subphase of final update refs. Ultimately, we hope to move this phase to a handshake (or not have it all). In the interim, we should at least know how long it takes. The updated phase timings message in the logs has the form: > > [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats ] Pause Final Update Refs (N) 377 us, workers (us): ---, ---, ---, ---, ---, ---, ---, ---, > [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats ] Update Region States 98 us > [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats ] Transfer Old From SATB 74 us > [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats ] Trash Collection Set 48 us > [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats ] Rebuild Free Set 132 us > [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats ] Propagate GC State 6 us > > The `Transfer Old From SATB` is new. Marked as reviewed by xpeng (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27234#pullrequestreview-3214888307 From tschatzl at openjdk.org Fri Sep 12 06:44:26 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 12 Sep 2025 06:44:26 GMT Subject: RFR: 8367372: Test `test/hotspot/jtreg/gc/TestObjectAlignmentCardSize.java` fails on 32 bit systems In-Reply-To: References: Message-ID: <2tTYBmOgbcWxB98fVlr2a8G49_FMpNiuFGyLbiT6okA=.3651db9a-2f91-4d19-8ab3-54e3c813c5f0@github.com> On Thu, 11 Sep 2025 17:18:11 GMT, Satyen Subramaniam wrote: > On 32-bit systems, the `test/hotspot/jtreg/gc/TestObjectAlignmentCardSize.java` uses the `ObjectAlignmentInBytes` flag, which isn't supported on 32 bit systems. I'm adjusting this test to require `vm.bits` is 64 as per similar [tests](https://github.com/openjdk/jdk/blob/85715e1050fa774c3267dbbe2f749717aeeec8ff/test/hotspot/jtreg/runtime/CompressedOops/CompressedKlassPointerAndOops.java#L31). > > Tested on: > * 64-bit: with and without change (passes both times) > * 32-bit: with and without change (fails before, skips after) > Note: seeing some GHA failures, but unrelated to the actual test. Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27230#pullrequestreview-3214892496 From xpeng at openjdk.org Fri Sep 12 06:52:23 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 12 Sep 2025 06:52:23 GMT Subject: RFR: 8367451: GenShen: Remove the option to compute age census during evacuation In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 22:16:15 GMT, William Kemper wrote: > This experimental option has always defaulted to false. We are working on changes that will make it impractical to maintain this option. We also do not regularly test this configuration. Looks good, Thanks! ------------- Marked as reviewed by xpeng (Committer). PR Review: https://git.openjdk.org/jdk/pull/27236#pullrequestreview-3214924153 From jsikstro at openjdk.org Fri Sep 12 07:11:24 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Fri, 12 Sep 2025 07:11:24 GMT Subject: RFR: 8367413: Use size_t instead of julong in runtime/arguments.cpp [v2] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 13:46:27 GMT, Albert Mingkun Yang wrote: >> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: >> >> size_t casts for 32-bit part of test_arguments.cpp > > src/hotspot/share/runtime/arguments.cpp line 1526: > >> 1524: FLAG_SET_ERGO(MaxRAM, (uint64_t)phys_mem); >> 1525: } else { >> 1526: phys_mem = (size_t)MaxRAM; > > Pre-existing: I wonder if this should be `MIN2(MaxRAM, SIZE_MAX)` to handle 32-bit systems. >From the discussion surrounding [JDK-8367485](https://bugs.openjdk.org/browse/JDK-8367485), we support this since we could run a 32-bit VM on a 64-bit machine. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27224#discussion_r2343223296 From jsikstro at openjdk.org Fri Sep 12 07:20:28 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Fri, 12 Sep 2025 07:20:28 GMT Subject: RFR: 8367413: Use size_t instead of julong in runtime/arguments.cpp [v2] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 13:42:33 GMT, Joel Sikstr?m wrote: >> Hello, >> >> There are several unnecessary uses of the julong type in arguments.cpp that could use size_t instead to fit in better with surrounding code. Almost all flags that are read in arguments.cpp are size_t, and the os functions it interacts with were changed from julong to size_t in [JDK-8357086](https://bugs.openjdk.org/browse/JDK-8357086) or are already taking in size_t. >> >> The main usage of julong in runtime/arguments.cpp is in Arguments::set_heap_size() and Arguments::set_aggressive_heap_flags(), where there are a lot of casts from julong types to size_t which could be removed with this change. >> >> Testing: >> * Running through Oracle's tier1-3 on all Oracle supported platforms > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > size_t casts for 32-bit part of test_arguments.cpp When looking at this we found some irregularities with the code that is being changed in this PR when running in a 32-bit VM. I think we should hold off on this until there is a solution in place for [JDK-8367485](https://bugs.openjdk.org/browse/JDK-8367485), so I'll move this to a draft in the meantime. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27224#issuecomment-3284069670 From tschatzl at openjdk.org Fri Sep 12 07:26:30 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 12 Sep 2025 07:26:30 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v55] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 10:24:57 GMT, Andrew Haley wrote: >> I can argue I was following precedent :) I see your point though. What do you suggest to do here? Use `count` throughout instead? > >> I can argue I was following precedent :) > > You were, but it's a precedent that needs to die. > >> I see your point though. What do you suggest to do here? Use `count` throughout instead? > > Yes, although it might need a couple more comments. What do you think of https://github.com/openjdk/jdk/commit/74e9240ba275986375d3e6f0ac9bfa4b5fbb78ce ? (not committed in this branch yet because I do not want all the back-and-forth here) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2343254077 From tschatzl at openjdk.org Fri Sep 12 07:55:13 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 12 Sep 2025 07:55:13 GMT Subject: RFR: 8367472: Swap conditions order in PSScavengeCLDOopClosure::do_oop(oop*) In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 22:36:52 GMT, Francesco Andreuzzi wrote: > In this PR I propose to swap the order of conditions in `PSScavengeCLDOopClosure::do_oop`, as proposed during the review of #27199. This change will move the trivial check first in the `if` clause, which is easier for the reader and potentially for the branch predictor. This will also bring parity with `CLDOopClosure` (Serial). > > Passes `tier1`. Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27237#pullrequestreview-3215246802 From tschatzl at openjdk.org Fri Sep 12 07:57:13 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 12 Sep 2025 07:57:13 GMT Subject: RFR: 8367424: Cleanup unused time_remaining_ms update in G1CollectionSet::select_optional_groups In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 15:29:02 GMT, Guanqiang Han wrote: > Please review this PR. This is a trivial change that simply removes unused code. Trivial. ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27229#pullrequestreview-3215249756 From duke at openjdk.org Fri Sep 12 08:02:17 2025 From: duke at openjdk.org (duke) Date: Fri, 12 Sep 2025 08:02:17 GMT Subject: RFR: 8367472: Swap conditions order in PSScavengeCLDOopClosure::do_oop(oop*) In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 22:36:52 GMT, Francesco Andreuzzi wrote: > In this PR I propose to swap the order of conditions in `PSScavengeCLDOopClosure::do_oop`, as proposed during the review of #27199. This change will move the trivial check first in the `if` clause, which is easier for the reader and potentially for the branch predictor. This will also bring parity with `CLDOopClosure` (Serial). > > Passes `tier1`. @fandreuz Your change (at version bdeb3eefd6a5fc037b735cfc634e3679941c0d79) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27237#issuecomment-3284196649 From duke at openjdk.org Fri Sep 12 08:07:00 2025 From: duke at openjdk.org (duke) Date: Fri, 12 Sep 2025 08:07:00 GMT Subject: RFR: 8367424: Cleanup unused time_remaining_ms update in G1CollectionSet::select_optional_groups In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 15:29:02 GMT, Guanqiang Han wrote: > Please review this PR. This is a trivial change that simply removes unused code. @hgqxjj Your change (at version 97f9dfb548c6e371f84ed23010dd80e1fc564bec) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27229#issuecomment-3284209042 From ghan at openjdk.org Fri Sep 12 08:17:16 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Fri, 12 Sep 2025 08:17:16 GMT Subject: RFR: 8367424: Cleanup unused time_remaining_ms update in G1CollectionSet::select_optional_groups In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 07:54:01 GMT, Thomas Schatzl wrote: >> Please review this PR. This is a trivial change that simply removes unused code. > > Trivial. @tschatzl Thank you for the approval. I?ve integrated this PR. Could you kindly sponsor it? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27229#issuecomment-3284239122 From azafari at openjdk.org Fri Sep 12 08:25:15 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 12 Sep 2025 08:25:15 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer In-Reply-To: <-Ct2yCIbRn7bSazmFKxlMPMeP85zAZk3kUfP9ele4so=.78e5ec0f-2d17-45e6-a68d-9fff149577c1@github.com> References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> <-Ct2yCIbRn7bSazmFKxlMPMeP85zAZk3kUfP9ele4so=.78e5ec0f-2d17-45e6-a68d-9fff149577c1@github.com> Message-ID: On Wed, 27 Aug 2025 14:19:23 GMT, Johan Sj?len wrote: >> The minimum acceptable value was 0 where using it as address was problematic according to UBSAN. >> The acceptable value is changed to 64K. >> >> Tests: >> linux-x64 tier1 > > It seems to me like we can fix the ubsan issue by avoiding the cast into pointers and computing through `size_t` as far as possible, and converting into pointer when necessary. > > For example > > ```c++ > size_t aligned_heap_base_min_address = align_up(HeapBaseMinAddress, alignment); > size_t noaccess_prefix = ((aligned_heap_base_min_address + size) > OopEncodingHeapMax) ? noaccess_prefix_size : 0; > > if (!FLAG_IS_DEFAULT(HeapBaseMinAddress)) { > reserved = try_reserve_memory(size + noaccess_prefix, alignment, page_size, static_cast(aligned_heap_base_min_address)); > if (reserved.base() != static_cast(aligned_heap_base_min_address)) { // Enforce this exact address. > release(reserved); > reserved = {}; > } > } > > > The semantics of reserving a `null` base address is still preserved as meaning "don't care where you put it" then. Someone from GC needs to look at this and see whether or not an undefined (implicitly 0?) HeapBaseMinAddress is meant to have that type of meaning. Dear @jdksjolen and @xmas92, your comments are welcome. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3284266029 From tschatzl at openjdk.org Fri Sep 12 08:29:59 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 12 Sep 2025 08:29:59 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v60] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 80 commits: - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * therealaph suggestion for avoiding the register aliasin in gen_write_ref_array_post - * walulyai review - * walulyai review * tried to remove "logged card" terminology for the current "pending card" one - * aph review, fix some comment - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * iwalulya: remove confusing comment - * sort includes - Merge branch 'master' into 8342382-card-table-instead-of-dcq - ... and 70 more: https://git.openjdk.org/jdk/compare/9e843f56...1ced9f98 ------------- Changes: https://git.openjdk.org/jdk/pull/23739/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=59 Stats: 7162 lines in 112 files changed: 2594 ins; 3588 del; 980 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From mdoerr at openjdk.org Fri Sep 12 08:30:01 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 12 Sep 2025 08:30:01 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v55] In-Reply-To: References: Message-ID: <63y80KoZ7oXdnFLRmK28Z8wcOSSAMXHx91akDn0tcLc=.981add6e-0b3f-423f-9b5f-87bb7d9fad9a@github.com> On Fri, 12 Sep 2025 07:23:23 GMT, Thomas Schatzl wrote: >>> I can argue I was following precedent :) >> >> You were, but it's a precedent that needs to die. >> >>> I see your point though. What do you suggest to do here? Use `count` throughout instead? >> >> Yes, although it might need a couple more comments. > > What do you think of https://github.com/openjdk/jdk/commit/74e9240ba275986375d3e6f0ac9bfa4b5fbb78ce ? (not committed in this branch yet because I do not want all the back-and-forth here) Other idea: set count = noreg to prevent usage after it is used under the other name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2343415421 From mli at openjdk.org Fri Sep 12 08:30:29 2025 From: mli at openjdk.org (Hamlin Li) Date: Fri, 12 Sep 2025 08:30:29 GMT Subject: RFR: 8367372: Test `test/hotspot/jtreg/gc/TestObjectAlignmentCardSize.java` fails on 32 bit systems In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 17:18:11 GMT, Satyen Subramaniam wrote: > On 32-bit systems, the `test/hotspot/jtreg/gc/TestObjectAlignmentCardSize.java` uses the `ObjectAlignmentInBytes` flag, which isn't supported on 32 bit systems. I'm adjusting this test to require `vm.bits` is 64 as per similar [tests](https://github.com/openjdk/jdk/blob/85715e1050fa774c3267dbbe2f749717aeeec8ff/test/hotspot/jtreg/runtime/CompressedOops/CompressedKlassPointerAndOops.java#L31). > > Tested on: > * 64-bit: with and without change (passes both times) > * 32-bit: with and without change (fails before, skips after) > Note: seeing some GHA failures, but unrelated to the actual test. Marked as reviewed by mli (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27230#pullrequestreview-3215373122 From mli at openjdk.org Fri Sep 12 08:33:40 2025 From: mli at openjdk.org (Hamlin Li) Date: Fri, 12 Sep 2025 08:33:40 GMT Subject: RFR: 8367472: Swap conditions order in PSScavengeCLDOopClosure::do_oop(oop*) In-Reply-To: References: Message-ID: <7K8feQ2bipi9GEnxJaaQotd7R_IDnK2S1CQr3brlZIM=.d98302c1-98a7-42f9-9638-518da3426e9d@github.com> On Thu, 11 Sep 2025 22:36:52 GMT, Francesco Andreuzzi wrote: > In this PR I propose to swap the order of conditions in `PSScavengeCLDOopClosure::do_oop`, as proposed during the review of #27199. This change will move the trivial check first in the `if` clause, which is easier for the reader and potentially for the branch predictor. This will also bring parity with `CLDOopClosure` (Serial). > > Passes `tier1`. Marked as reviewed by mli (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27237#pullrequestreview-3215390294 From ssubramaniam at openjdk.org Fri Sep 12 08:33:56 2025 From: ssubramaniam at openjdk.org (Satyen Subramaniam) Date: Fri, 12 Sep 2025 08:33:56 GMT Subject: Integrated: 8367372: Test `test/hotspot/jtreg/gc/TestObjectAlignmentCardSize.java` fails on 32 bit systems In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 17:18:11 GMT, Satyen Subramaniam wrote: > On 32-bit systems, the `test/hotspot/jtreg/gc/TestObjectAlignmentCardSize.java` uses the `ObjectAlignmentInBytes` flag, which isn't supported on 32 bit systems. I'm adjusting this test to require `vm.bits` is 64 as per similar [tests](https://github.com/openjdk/jdk/blob/85715e1050fa774c3267dbbe2f749717aeeec8ff/test/hotspot/jtreg/runtime/CompressedOops/CompressedKlassPointerAndOops.java#L31). > > Tested on: > * 64-bit: with and without change (passes both times) > * 32-bit: with and without change (fails before, skips after) > Note: seeing some GHA failures, but unrelated to the actual test. This pull request has now been integrated. Changeset: 0f535aeb Author: Satyen Subramaniam Committer: Hamlin Li URL: https://git.openjdk.org/jdk/commit/0f535aeb0ae2f7015300889a0ee9efbf10a15896 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8367372: Test `test/hotspot/jtreg/gc/TestObjectAlignmentCardSize.java` fails on 32 bit systems Reviewed-by: stefank, tschatzl, mli ------------- PR: https://git.openjdk.org/jdk/pull/27230 From mli at openjdk.org Fri Sep 12 08:34:54 2025 From: mli at openjdk.org (Hamlin Li) Date: Fri, 12 Sep 2025 08:34:54 GMT Subject: RFR: 8367424: Cleanup unused time_remaining_ms update in G1CollectionSet::select_optional_groups In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 15:29:02 GMT, Guanqiang Han wrote: > Please review this PR. This is a trivial change that simply removes unused code. Marked as reviewed by mli (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27229#pullrequestreview-3215377039 From ghan at openjdk.org Fri Sep 12 08:34:55 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Fri, 12 Sep 2025 08:34:55 GMT Subject: RFR: 8367424: Cleanup unused time_remaining_ms update in G1CollectionSet::select_optional_groups In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 08:28:33 GMT, Hamlin Li wrote: >> Please review this PR. This is a trivial change that simply removes unused code. > > Marked as reviewed by mli (Reviewer). @Hamlin-Li Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27229#issuecomment-3284296812 From ghan at openjdk.org Fri Sep 12 08:34:56 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Fri, 12 Sep 2025 08:34:56 GMT Subject: Integrated: 8367424: Cleanup unused time_remaining_ms update in G1CollectionSet::select_optional_groups In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 15:29:02 GMT, Guanqiang Han wrote: > Please review this PR. This is a trivial change that simply removes unused code. This pull request has now been integrated. Changeset: e0ad4a66 Author: Guanqiang Han Committer: Hamlin Li URL: https://git.openjdk.org/jdk/commit/e0ad4a669629012b81f0ada2b7870409683c1015 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod 8367424: Cleanup unused time_remaining_ms update in G1CollectionSet::select_optional_groups Reviewed-by: tschatzl, mli ------------- PR: https://git.openjdk.org/jdk/pull/27229 From fandreuzzi at openjdk.org Fri Sep 12 08:35:56 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 12 Sep 2025 08:35:56 GMT Subject: Integrated: 8367472: Swap conditions order in PSScavengeCLDOopClosure::do_oop(oop*) In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 22:36:52 GMT, Francesco Andreuzzi wrote: > In this PR I propose to swap the order of conditions in `PSScavengeCLDOopClosure::do_oop`, as proposed during the review of #27199. This change will move the trivial check first in the `if` clause, which is easier for the reader and potentially for the branch predictor. This will also bring parity with `CLDOopClosure` (Serial). > > Passes `tier1`. This pull request has now been integrated. Changeset: 5f43345d Author: Francesco Andreuzzi Committer: Hamlin Li URL: https://git.openjdk.org/jdk/commit/5f43345d6e9c27ae99fffd3a53e8064ed84de458 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8367472: Swap conditions order in PSScavengeCLDOopClosure::do_oop(oop*) Reviewed-by: stefank, tschatzl, mli ------------- PR: https://git.openjdk.org/jdk/pull/27237 From tschatzl at openjdk.org Fri Sep 12 09:00:36 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 12 Sep 2025 09:00:36 GMT Subject: RFR: 8367472: Swap conditions order in PSScavengeCLDOopClosure::do_oop(oop*) In-Reply-To: <7K8feQ2bipi9GEnxJaaQotd7R_IDnK2S1CQr3brlZIM=.d98302c1-98a7-42f9-9638-518da3426e9d@github.com> References: <7K8feQ2bipi9GEnxJaaQotd7R_IDnK2S1CQr3brlZIM=.d98302c1-98a7-42f9-9638-518da3426e9d@github.com> Message-ID: <_i-uufOwHlOb3sdYnRNxlFKt8SGgVFrG0bFytjQtuss=.6eee2d0c-51a6-4967-989d-d41ef9c516ff@github.com> On Fri, 12 Sep 2025 08:31:28 GMT, Hamlin Li wrote: >> In this PR I propose to swap the order of conditions in `PSScavengeCLDOopClosure::do_oop`, as proposed during the review of #27199. This change will move the trivial check first in the `if` clause, which is easier for the reader and potentially for the branch predictor. This will also bring parity with `CLDOopClosure` (Serial). >> >> Passes `tier1`. > > Marked as reviewed by mli (Reviewer). @Hamlin-Li : this change, while it has obtained the required reviews, still needs to obey the 24h rule. So please do not push if the reviewers did not confirm the "trivial" condition in the future. It is not sufficient if the author suggested that the change is trivial. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27237#issuecomment-3284385057 From tschatzl at openjdk.org Fri Sep 12 09:05:28 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 12 Sep 2025 09:05:28 GMT Subject: RFR: 8367372: Test `test/hotspot/jtreg/gc/TestObjectAlignmentCardSize.java` fails on 32 bit systems In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 08:27:37 GMT, Hamlin Li wrote: >> On 32-bit systems, the `test/hotspot/jtreg/gc/TestObjectAlignmentCardSize.java` uses the `ObjectAlignmentInBytes` flag, which isn't supported on 32 bit systems. I'm adjusting this test to require `vm.bits` is 64 as per similar [tests](https://github.com/openjdk/jdk/blob/85715e1050fa774c3267dbbe2f749717aeeec8ff/test/hotspot/jtreg/runtime/CompressedOops/CompressedKlassPointerAndOops.java#L31). >> >> Tested on: >> * 64-bit: with and without change (passes both times) >> * 32-bit: with and without change (fails before, skips after) >> Note: seeing some GHA failures, but unrelated to the actual test. > > Marked as reviewed by mli (Reviewer). @Hamlin-Li : same as the other PR, please respect the 24h rule when sponsoring. The author did not even suggest that it is trivial. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27230#issuecomment-3284402619 From ayang at openjdk.org Fri Sep 12 09:21:24 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 12 Sep 2025 09:21:24 GMT Subject: RFR: 8367507: Parallel: Remove PSPromotionManager::drain_stacks_depth Message-ID: Trivial renaming a method so that we can remove one of two methods with identical implementations, `drain_stacks` and `drain_stacks_depth`. Test: tier1 ------------- Commit messages: - pgc-stack-merge Changes: https://git.openjdk.org/jdk/pull/27252/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27252&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367507 Stats: 8 lines in 3 files changed: 0 ins; 4 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27252.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27252/head:pull/27252 PR: https://git.openjdk.org/jdk/pull/27252 From jsjolen at openjdk.org Fri Sep 12 09:26:50 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 12 Sep 2025 09:26:50 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v3] In-Reply-To: <-eWIUjA4RqIgcpvFSyFxuiuganZpBqkMIdKSOVhnuMo=.79db2c26-5547-42fa-84d9-9bf5746728cf@github.com> References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> <-eWIUjA4RqIgcpvFSyFxuiuganZpBqkMIdKSOVhnuMo=.79db2c26-5547-42fa-84d9-9bf5746728cf@github.com> Message-ID: On Fri, 5 Sep 2025 11:02:32 GMT, Afshin Zafari wrote: >> The minimum acceptable value was 0 where using it as address was problematic according to UBSAN. >> The acceptable value is changed to 64K. >> >> Tests: >> linux-x64 tier1 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > lowest can be equal to highest src/hotspot/share/gc/shared/jvmFlagConstraintsGC.cpp line 288: > 286: // If an overflow happened in Arguments::set_heap_size(), MaxHeapSize will have too large a value. > 287: // Check for this by ensuring that MaxHeapSize plus the requested min base address still fit within max_uintx. > 288: if (value + MaxHeapSize < MaxHeapSize) {// overflow Can we perform the overflow check via subtraction from the max value instead? I know that unsigned types do wrap around, but at a first glance this will look wrong and make the reader stop and think. Style: Space between { and // if (std::numeric_limits::max() - value < MaxHeapSize) { // overflow src/hotspot/share/memory/memoryReserver.cpp line 560: > 558: if (!FLAG_IS_DEFAULT(HeapBaseMinAddress)) { > 559: reserved = try_reserve_memory(size + noaccess_prefix, alignment, page_size, (char *)aligned_heap_base_min_address); > 560: if (reserved.base() != (char *)aligned_heap_base_min_address) { // Enforce this exact address. Style: Please hug the * to the char for the casts src/hotspot/share/memory/memoryReserver.cpp line 584: > 582: // Calc address range within we try to attach (range of possible start addresses). > 583: char* const highest_start = align_down((char *)UnscaledOopHeapMax - size, attach_point_alignment); > 584: char* const lowest_start = align_up((char *)aligned_heap_base_min_address, attach_point_alignment); Keep these as uintptr_t instead and only cast when trying to reserve src/hotspot/share/memory/memoryReserver.cpp line 595: > 593: > 594: // Give it several tries from top of range to bottom. > 595: if (aligned_heap_base_min_address + size <= (uintptr_t)zerobased_max && // Zerobased theoretical possible. Do the opposite: Have zerobased_max be uintptr_t and only cast it when it needs to become a char* src/hotspot/share/memory/memoryReserver.cpp line 612: > 610: } > 611: lowest_start = align_up(lowest_start, attach_point_alignment); > 612: assert(lowest_start <= highest_start, "lowest: " INTPTR_FORMAT " highest: " INTPTR_FORMAT, Keep these as uintptr_t and cast to char* only when reserving ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2343523999 PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2343578098 PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2343582330 PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2343588323 PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2343591444 From iwalulya at openjdk.org Fri Sep 12 10:38:08 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Fri, 12 Sep 2025 10:38:08 GMT Subject: RFR: 8366865: G1: Allocation GC Pauses Triggered after JVM has started shutdown [v2] In-Reply-To: References: Message-ID: > Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. > > Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. > > Testing: Tier 1-7 Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: - return on timeout - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs - timed wait - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs - space - remove debug logs - remove debug logs - log_cpu_time - init ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27190/files - new: https://git.openjdk.org/jdk/pull/27190/files/8a05ec45..187a463b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27190&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27190&range=00-01 Stats: 11286 lines in 575 files changed: 5300 ins; 2963 del; 3023 mod Patch: https://git.openjdk.org/jdk/pull/27190.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27190/head:pull/27190 PR: https://git.openjdk.org/jdk/pull/27190 From fandreuzzi at openjdk.org Fri Sep 12 10:44:15 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 12 Sep 2025 10:44:15 GMT Subject: RFR: 8367507: Parallel: Remove PSPromotionManager::drain_stacks_depth In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 09:12:22 GMT, Albert Mingkun Yang wrote: > Trivial renaming a method so that we can remove one of two methods with identical implementations, `drain_stacks` and `drain_stacks_depth`. > > Test: tier1 Marked as reviewed by fandreuzzi (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/27252#pullrequestreview-3216052442 From ayang at openjdk.org Fri Sep 12 11:05:12 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 12 Sep 2025 11:05:12 GMT Subject: RFR: 8367476: Shenandoah: Remove use of CollectedHeap::_soft_ref_policy In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 00:19:05 GMT, Francesco Andreuzzi wrote: > Similarly to what was done in #26496 and #26648, the usages of `CollectedHeap::_soft_ref_policy` in Shenandoah can be replaced with an earlier call to `ShenandoahReferenceProcessor::set_soft_reference_policy`. > > This is the last usage of `CollectedHeap::_soft_ref_policy`, so it can be removed. > > Passes tier(1,2,3)_gc_shenandoah. src/hotspot/share/gc/shared/collectedHeap.hpp line 239: > 237: return cause == GCCause::_metadata_GC_clear_soft_refs || > 238: cause == GCCause::_wb_full_gc; > 239: } I feel that it makes more sense to have this in `GCCause`. src/hotspot/share/gc/shared/collectedHeap.hpp line 241: > 239: } > 240: > 241: inline bool should_clear_all_soft_refs() const { I suggest inlining this method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27239#discussion_r2343856579 PR Review Comment: https://git.openjdk.org/jdk/pull/27239#discussion_r2343858970 From ayang at openjdk.org Fri Sep 12 11:12:30 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 12 Sep 2025 11:12:30 GMT Subject: RFR: 8367507: Parallel: Remove PSPromotionManager::drain_stacks_depth [v2] In-Reply-To: References: Message-ID: > Trivial renaming a method so that we can remove one of two methods with identical implementations, `drain_stacks` and `drain_stacks_depth`. > > Test: tier1 Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into pgc-stack-merge - pgc-stack-merge ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27252/files - new: https://git.openjdk.org/jdk/pull/27252/files/572e1c43..6ff01cad Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27252&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27252&range=00-01 Stats: 4 lines in 2 files changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27252.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27252/head:pull/27252 PR: https://git.openjdk.org/jdk/pull/27252 From lkorinth at openjdk.org Fri Sep 12 12:00:51 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Fri, 12 Sep 2025 12:00:51 GMT Subject: RFR: 8367409: G1: Remove unused G1MonotonicArena::Segment::copy_to() Message-ID: The code compiles. ------------- Commit messages: - revert autoformat mistake - keep a newline between delete_segment and is_full() - 8367409: G1: Remove unused G1MonotonicArena::Segment::copy_to() Changes: https://git.openjdk.org/jdk/pull/27221/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27221&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367409 Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27221.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27221/head:pull/27221 PR: https://git.openjdk.org/jdk/pull/27221 From lkorinth at openjdk.org Fri Sep 12 12:00:53 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Fri, 12 Sep 2025 12:00:53 GMT Subject: RFR: 8367409: G1: Remove unused G1MonotonicArena::Segment::copy_to() In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 11:52:08 GMT, Leo Korinth wrote: > The code compiles. The code compiles. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27221#issuecomment-3280195797 From ayang at openjdk.org Fri Sep 12 12:00:52 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 12 Sep 2025 12:00:52 GMT Subject: RFR: 8367409: G1: Remove unused G1MonotonicArena::Segment::copy_to() In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 11:52:08 GMT, Leo Korinth wrote: > The code compiles. Marked as reviewed by ayang (Reviewer). src/hotspot/share/gc/g1/g1MonotonicArena.hpp line 177: > 175: > 176: static Segment* create_segment(uint slot_size, uint num_slots, Segment* next, MemTag mem_tag); > 177: static void delete_segment(Segment *segment); I'd suggest keeping the original `Segment*` type to be consistent with surrounding code. ------------- PR Review: https://git.openjdk.org/jdk/pull/27221#pullrequestreview-3212092804 PR Review Comment: https://git.openjdk.org/jdk/pull/27221#discussion_r2341240885 From tschatzl at openjdk.org Fri Sep 12 12:00:54 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 12 Sep 2025 12:00:54 GMT Subject: RFR: 8367409: G1: Remove unused G1MonotonicArena::Segment::copy_to() In-Reply-To: References: Message-ID: <8OWdkx16wF_4dtkgHCAKdQfEOXLY673_--k1Clcdm0Q=.f816f8fc-522c-401c-bc80-f6303a513b3c@github.com> On Thu, 11 Sep 2025 14:47:31 GMT, Albert Mingkun Yang wrote: >> The code compiles. > > src/hotspot/share/gc/g1/g1MonotonicArena.hpp line 177: > >> 175: >> 176: static Segment* create_segment(uint slot_size, uint num_slots, Segment* next, MemTag mem_tag); >> 177: static void delete_segment(Segment *segment); > > I'd suggest keeping the original `Segment*` type to be consistent with surrounding code. Also, I think this is part of the style guideline to keep the `*` at the type, even if the compiler parses it differently. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27221#discussion_r2343518658 From lkorinth at openjdk.org Fri Sep 12 12:00:54 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Fri, 12 Sep 2025 12:00:54 GMT Subject: RFR: 8367409: G1: Remove unused G1MonotonicArena::Segment::copy_to() In-Reply-To: <8OWdkx16wF_4dtkgHCAKdQfEOXLY673_--k1Clcdm0Q=.f816f8fc-522c-401c-bc80-f6303a513b3c@github.com> References: <8OWdkx16wF_4dtkgHCAKdQfEOXLY673_--k1Clcdm0Q=.f816f8fc-522c-401c-bc80-f6303a513b3c@github.com> Message-ID: On Fri, 12 Sep 2025 08:59:15 GMT, Thomas Schatzl wrote: >> src/hotspot/share/gc/g1/g1MonotonicArena.hpp line 177: >> >>> 175: >>> 176: static Segment* create_segment(uint slot_size, uint num_slots, Segment* next, MemTag mem_tag); >>> 177: static void delete_segment(Segment *segment); >> >> I'd suggest keeping the original `Segment*` type to be consistent with surrounding code. > > Also, I think this is part of the style guideline to keep the `*` at the type, even if the compiler parses it differently. I have now turned off auto format, sorry for that. I much prefer the asterisk close to the type. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27221#discussion_r2343927662 From tschatzl at openjdk.org Fri Sep 12 12:00:55 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 12 Sep 2025 12:00:55 GMT Subject: RFR: 8367409: G1: Remove unused G1MonotonicArena::Segment::copy_to() In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 11:52:08 GMT, Leo Korinth wrote: > The code compiles. src/hotspot/share/gc/g1/g1MonotonicArena.hpp line 183: > 181: ::memcpy(dest, _bottom, length() * _slot_size); > 182: } > 183: Please keep a newline between `delete_segment` and `is_full()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27221#discussion_r2340453367 From tschatzl at openjdk.org Fri Sep 12 12:07:14 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 12 Sep 2025 12:07:14 GMT Subject: RFR: 8367409: G1: Remove unused G1MonotonicArena::Segment::copy_to() In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 11:52:08 GMT, Leo Korinth wrote: > The code compiles. Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27221#pullrequestreview-3216364559 From ayang at openjdk.org Fri Sep 12 12:23:20 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 12 Sep 2025 12:23:20 GMT Subject: RFR: 8367409: G1: Remove unused G1MonotonicArena::Segment::copy_to() In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 11:52:08 GMT, Leo Korinth wrote: > The code compiles. Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27221#pullrequestreview-3216426353 From lkorinth at openjdk.org Fri Sep 12 12:33:54 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Fri, 12 Sep 2025 12:33:54 GMT Subject: RFR: 8285984: G1: Use standard idiom for inlined payload in G1MonotonicArena::Segment Message-ID: This change remove the old padding (extremely big, especially on x86-64), and replaces it with a guaranteed 8 byte alignment. It also removes the `_bottom` field and instead adds a `payload` method. I statically assert that Segment is 8 byte aligned. I then runtime assert that Segment is constructed on 8 byte aligned memory. I also assert that the Slot alignment is less than or equal to the Segment alignment. I am running tier 1-3 at the moment. Do you think I should run some specific performance test on this? ------------- Commit messages: - 8285984: G1: Use standard idiom for inlined payload in G1MonotonicArena::Segment Changes: https://git.openjdk.org/jdk/pull/27258/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27258&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8285984 Stats: 19 lines in 3 files changed: 4 ins; 7 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/27258.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27258/head:pull/27258 PR: https://git.openjdk.org/jdk/pull/27258 From lkorinth at openjdk.org Fri Sep 12 13:37:36 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Fri, 12 Sep 2025 13:37:36 GMT Subject: RFR: 8285984: G1: Use standard idiom for inlined payload in G1MonotonicArena::Segment [v2] In-Reply-To: References: Message-ID: > This change remove the old padding (extremely big, especially on x86-64), and replaces it with a guaranteed 8 byte alignment. It also removes the `_bottom` field and instead adds a `payload` method. I statically assert that Segment is 8 byte aligned. I then runtime assert that Segment is constructed on 8 byte aligned memory. I also assert that the Slot alignment is less than or equal to the Segment alignment. > > I am running tier 1-3 at the moment. Do you think I should run some specific performance test on this? Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: may fail on 32 bit machines, added explicit alignas ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27258/files - new: https://git.openjdk.org/jdk/pull/27258/files/766577e6..131fa911 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27258&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27258&range=00-01 Stats: 8 lines in 3 files changed: 1 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27258.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27258/head:pull/27258 PR: https://git.openjdk.org/jdk/pull/27258 From aboldtch at openjdk.org Fri Sep 12 13:42:17 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 12 Sep 2025 13:42:17 GMT Subject: RFR: 8285984: G1: Use standard idiom for inlined payload in G1MonotonicArena::Segment [v2] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 13:37:36 GMT, Leo Korinth wrote: >> This change remove the old padding (extremely big, especially on x86-64), and replaces it with a guaranteed 8 byte alignment. It also removes the `_bottom` field and instead adds a `payload` method. I statically assert that Segment is 8 byte aligned. I then runtime assert that Segment is constructed on 8 byte aligned memory. I also assert that the Slot alignment is less than or equal to the Segment alignment. >> >> I am running tier 1-3 at the moment. Do you think I should run some specific performance test on this? > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > may fail on 32 bit machines, added explicit alignas This looks good. Just wonder if we want some comment w.r.t. the (Max)Alignment variable explaining its purpose. src/hotspot/share/gc/g1/g1MonotonicArena.hpp line 113: > 111: }; > 112: > 113: static constexpr uint SegmentAlignment = 8; Maybe this should be called `SegmentMaxAlignment`, or `SegmentPayloadMaxAlignment`. And have a comment describing that we align the Segment class to this alignment to guarantee that the payload is aligned to all powers of 2 less than or equal to this value. src/hotspot/share/gc/g1/g1MonotonicArena.hpp line 239: > 237: assert(_max_num_slots > 0, "Must be"); > 238: assert(_slot_alignment > 0, "Must be"); > 239: assert(_slot_alignment <= SegmentAlignment, "Must be"); Not sure if it should be clarified that this assert is sufficient because we only ever use allow alignments which are a power of two. ------------- Marked as reviewed by aboldtch (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27258#pullrequestreview-3216748107 PR Review Comment: https://git.openjdk.org/jdk/pull/27258#discussion_r2344290116 PR Review Comment: https://git.openjdk.org/jdk/pull/27258#discussion_r2344282983 From lkorinth at openjdk.org Fri Sep 12 14:02:13 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Fri, 12 Sep 2025 14:02:13 GMT Subject: RFR: 8285984: G1: Use standard idiom for inlined payload in G1MonotonicArena::Segment [v2] In-Reply-To: References: Message-ID: <_hI14ZAaUZUGyCtuZmMj_rrBpDPB8hfiXDDCFV9-_f8=.c60da0c6-c848-43c5-92fa-4ec64ba83782@github.com> On Fri, 12 Sep 2025 13:37:10 GMT, Axel Boldt-Christmas wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> may fail on 32 bit machines, added explicit alignas > > src/hotspot/share/gc/g1/g1MonotonicArena.hpp line 113: > >> 111: }; >> 112: >> 113: static constexpr uint SegmentAlignment = 8; > > Maybe this should be called `SegmentMaxAlignment`, or `SegmentPayloadMaxAlignment`. > > And have a comment describing that we align the Segment class to this alignment to guarantee that the payload is aligned to all powers of 2 less than or equal to this value. `SegmentPayloadMaxAlignment` is okay with me. `SegmentMaxAlignment` sounds wrong, as it is actually the minimum alignment for the Segment. > src/hotspot/share/gc/g1/g1MonotonicArena.hpp line 239: > >> 237: assert(_max_num_slots > 0, "Must be"); >> 238: assert(_slot_alignment > 0, "Must be"); >> 239: assert(_slot_alignment <= SegmentAlignment, "Must be"); > > Not sure if it should be clarified that this assert is sufficient because we only ever use allow alignments which are a power of two. Do you wish me to assert that it is a power of two as well? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27258#discussion_r2344340038 PR Review Comment: https://git.openjdk.org/jdk/pull/27258#discussion_r2344348392 From fandreuzzi at openjdk.org Fri Sep 12 14:23:35 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 12 Sep 2025 14:23:35 GMT Subject: RFR: 8367476: Shenandoah: Remove use of CollectedHeap::_soft_ref_policy [v2] In-Reply-To: References: Message-ID: > Similarly to what was done in #26496 and #26648, the usages of `CollectedHeap::_soft_ref_policy` in Shenandoah can be replaced with an earlier call to `ShenandoahReferenceProcessor::set_soft_reference_policy`. > > This is the last usage of `CollectedHeap::_soft_ref_policy`, so it can be removed. > > Passes tier(1,2,3)_gc_shenandoah. Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: - eagerly initialize to always-clear - move to gccause ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27239/files - new: https://git.openjdk.org/jdk/pull/27239/files/01e41d7b..a55b8bd2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27239&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27239&range=00-01 Stats: 30 lines in 8 files changed: 11 ins; 12 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27239.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27239/head:pull/27239 PR: https://git.openjdk.org/jdk/pull/27239 From fandreuzzi at openjdk.org Fri Sep 12 14:23:37 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 12 Sep 2025 14:23:37 GMT Subject: RFR: 8367476: Shenandoah: Remove use of CollectedHeap::_soft_ref_policy [v2] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 11:00:01 GMT, Albert Mingkun Yang wrote: >> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: >> >> - eagerly initialize to always-clear >> - move to gccause > > src/hotspot/share/gc/shared/collectedHeap.hpp line 239: > >> 237: return cause == GCCause::_metadata_GC_clear_soft_refs || >> 238: cause == GCCause::_wb_full_gc; >> 239: } > > I feel that it makes more sense to have this in `GCCause`. 035963eb771c9c614cc98affdbbb18ec86a53e78 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27239#discussion_r2344402767 From aboldtch at openjdk.org Fri Sep 12 14:52:53 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 12 Sep 2025 14:52:53 GMT Subject: RFR: 8285984: G1: Use standard idiom for inlined payload in G1MonotonicArena::Segment [v2] In-Reply-To: <_hI14ZAaUZUGyCtuZmMj_rrBpDPB8hfiXDDCFV9-_f8=.c60da0c6-c848-43c5-92fa-4ec64ba83782@github.com> References: <_hI14ZAaUZUGyCtuZmMj_rrBpDPB8hfiXDDCFV9-_f8=.c60da0c6-c848-43c5-92fa-4ec64ba83782@github.com> Message-ID: <-ncbk-NRAE2n0vmKkXsVJX0I9gbT9Fn9hAcelUvyv78=.e421c596-699e-4793-a6b5-71f54047107e@github.com> On Fri, 12 Sep 2025 13:58:06 GMT, Leo Korinth wrote: >> src/hotspot/share/gc/g1/g1MonotonicArena.hpp line 239: >> >>> 237: assert(_max_num_slots > 0, "Must be"); >>> 238: assert(_slot_alignment > 0, "Must be"); >>> 239: assert(_slot_alignment <= SegmentAlignment, "Must be"); >> >> Not sure if it should be clarified that this assert is sufficient because we only ever use allow alignments which are a power of two. > > Do you wish me to assert that it is a power of two as well? Not sure. Technically it is already asserted in the `align_up` call above. I guess what we really want to ensure is that `_slot_alignment` is a divisor of `SegmentAlignment`. So maybe `SegmentAlignment % _slot_alignment == 0` is the correct assert. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27258#discussion_r2344487467 From ayang at openjdk.org Fri Sep 12 15:21:22 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 12 Sep 2025 15:21:22 GMT Subject: RFR: 8367476: Shenandoah: Remove use of CollectedHeap::_soft_ref_policy [v2] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 14:23:35 GMT, Francesco Andreuzzi wrote: >> Similarly to what was done in #26496 and #26648, the usages of `CollectedHeap::_soft_ref_policy` in Shenandoah can be replaced with an earlier call to `ShenandoahReferenceProcessor::set_soft_reference_policy`. >> >> This is the last usage of `CollectedHeap::_soft_ref_policy`, so it can be removed. >> >> Passes tier1-2, and tier3_gc_shenandoah. > > Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: > > - eagerly initialize to always-clear > - move to gccause I have reviewed all non-Shenandoah code. ------------- Marked as reviewed by ayang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27239#pullrequestreview-3217218522 From phh at openjdk.org Fri Sep 12 16:04:15 2025 From: phh at openjdk.org (Paul Hohensee) Date: Fri, 12 Sep 2025 16:04:15 GMT Subject: RFR: 8367378: GenShen: Missing timing stats when old mark buffers are flushed during final update refs In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 20:28:08 GMT, William Kemper wrote: > This change adds timing to the 'flush old SATB buffers' subphase of final update refs. Ultimately, we hope to move this phase to a handshake (or not have it all). In the interim, we should at least know how long it takes. The updated phase timings message in the logs has the form: > > [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats ] Pause Final Update Refs (N) 377 us, workers (us): ---, ---, ---, ---, ---, ---, ---, ---, > [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats ] Update Region States 98 us > [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats ] Transfer Old From SATB 74 us > [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats ] Trash Collection Set 48 us > [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats ] Rebuild Free Set 132 us > [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats ] Propagate GC State 6 us > > The `Transfer Old From SATB` is new. Marked as reviewed by phh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27234#pullrequestreview-3217509401 From phh at openjdk.org Fri Sep 12 16:06:26 2025 From: phh at openjdk.org (Paul Hohensee) Date: Fri, 12 Sep 2025 16:06:26 GMT Subject: RFR: 8367451: GenShen: Remove the option to compute age census during evacuation In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 22:16:15 GMT, William Kemper wrote: > This experimental option has always defaulted to false. We are working on changes that will make it impractical to maintain this option. We also do not regularly test this configuration. Marked as reviewed by phh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27236#pullrequestreview-3217527778 From wkemper at openjdk.org Fri Sep 12 16:53:26 2025 From: wkemper at openjdk.org (William Kemper) Date: Fri, 12 Sep 2025 16:53:26 GMT Subject: Integrated: 8367378: GenShen: Missing timing stats when old mark buffers are flushed during final update refs In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 20:28:08 GMT, William Kemper wrote: > This change adds timing to the 'flush old SATB buffers' subphase of final update refs. Ultimately, we hope to move this phase to a handshake (or not have it all). In the interim, we should at least know how long it takes. The updated phase timings message in the logs has the form: > > [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats ] Pause Final Update Refs (N) 377 us, workers (us): ---, ---, ---, ---, ---, ---, ---, ---, > [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats ] Update Region States 98 us > [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats ] Transfer Old From SATB 74 us > [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats ] Trash Collection Set 48 us > [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats ] Rebuild Free Set 132 us > [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats ] Propagate GC State 6 us > > The `Transfer Old From SATB` is new. This pull request has now been integrated. Changeset: 11df2891 Author: William Kemper URL: https://git.openjdk.org/jdk/commit/11df28916af4c2bfd69b2829c74e046ad953ee6c Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod 8367378: GenShen: Missing timing stats when old mark buffers are flushed during final update refs Reviewed-by: kdnilsen, xpeng, phh ------------- PR: https://git.openjdk.org/jdk/pull/27234 From wkemper at openjdk.org Fri Sep 12 16:53:31 2025 From: wkemper at openjdk.org (William Kemper) Date: Fri, 12 Sep 2025 16:53:31 GMT Subject: Integrated: 8367451: GenShen: Remove the option to compute age census during evacuation In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 22:16:15 GMT, William Kemper wrote: > This experimental option has always defaulted to false. We are working on changes that will make it impractical to maintain this option. We also do not regularly test this configuration. This pull request has now been integrated. Changeset: 850f904a Author: William Kemper URL: https://git.openjdk.org/jdk/commit/850f904a84186b514a9b79fd4625b4651e73149b Stats: 18 lines in 7 files changed: 0 ins; 5 del; 13 mod 8367451: GenShen: Remove the option to compute age census during evacuation Reviewed-by: kdnilsen, xpeng, phh ------------- PR: https://git.openjdk.org/jdk/pull/27236 From kdnilsen at openjdk.org Fri Sep 12 17:20:16 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Fri, 12 Sep 2025 17:20:16 GMT Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in ShenandoahFreeSet [v3] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 22:07:11 GMT, Kelvin Nilsen wrote: >> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet. In the new code, we keep a single tally of relevant information within ShenandoahFreeSet. >> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet. >> >> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies. These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms. >> >> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > another tweak to make GHA gtest happy src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 3271: > 3269: } > 3270: } > 3271: Maybe we no longer need regular bypass because CDS no longer needs regular bypass. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2344973965 From kdnilsen at openjdk.org Fri Sep 12 18:20:15 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Fri, 12 Sep 2025 18:20:15 GMT Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in ShenandoahFreeSet [v3] In-Reply-To: <0DIlqJVwgCnx2FvbXZuDySjJ3hz241ag41o3BCHkSuY=.ac51c769-c5c0-4750-99b4-0ff43f864d33@github.com> References: <0DIlqJVwgCnx2FvbXZuDySjJ3hz241ag41o3BCHkSuY=.ac51c769-c5c0-4750-99b4-0ff43f864d33@github.com> Message-ID: On Wed, 10 Sep 2025 20:42:42 GMT, Kelvin Nilsen wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> another tweak to make GHA gtest happy > > src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 372: > >> 370: _last_sample_time = now; >> 371: _last_sample_value = allocated; >> 372: } > > This was a bug. If we don't update the average, we should not restart the time until next sample and we should not overwrite the value of _last_sample_value. Let's split this out into a different PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2345013011 From kdnilsen at openjdk.org Fri Sep 12 18:20:18 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Fri, 12 Sep 2025 18:20:18 GMT Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in ShenandoahFreeSet [v3] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 22:07:11 GMT, Kelvin Nilsen wrote: >> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet. In the new code, we keep a single tally of relevant information within ShenandoahFreeSet. >> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet. >> >> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies. These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms. >> >> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > another tweak to make GHA gtest happy src/hotspot/share/gc/shenandoah/shenandoahGenerationalEvacuationTask.cpp line 235: > 233: // is_collector_free range. > 234: region->restore_top_before_promote(); > 235: size_t region_to_be_used_in_old = region->used(); is region_to_be_used_in_old dead here? test/hotspot/jtreg/gc/shenandoah/mxbeans/TestChurnNotifications.java line 162: > 160: long count = TARGET_MB * 1024 * 1024 / (16 + 4 * size); > 161: > 162: long anticipated_humongous_waste_per_array = 124_272; Define ANTICIPATED_HUMONGOUS_WASTE_PER_ARRAY as a static constant. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2345034798 PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2345081989 From mdoerr at openjdk.org Fri Sep 12 20:42:24 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 12 Sep 2025 20:42:24 GMT Subject: RFR: 8366328: G1: Crash on reading os::thread_cpu_time In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 07:48:11 GMT, Ivan Walulya wrote: > Hi, > > Please review this patch to ensure that we do not attempt to read CPU time for GC threads that have already been terminated. > > Testing: Tier 1-3. This PR needs an update since `Atomic` has been renamed to `AtomicAccess`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27087#issuecomment-3286762853 From wkemper at openjdk.org Fri Sep 12 22:19:18 2025 From: wkemper at openjdk.org (William Kemper) Date: Fri, 12 Sep 2025 22:19:18 GMT Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a runtime diagnostic option Message-ID: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com> Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option. ------------- Commit messages: - Make detailed evacuation tracking a diagnostic option in product builds Changes: https://git.openjdk.org/jdk/pull/27238/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27238&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367473 Stats: 36 lines in 4 files changed: 19 ins; 4 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/27238.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27238/head:pull/27238 PR: https://git.openjdk.org/jdk/pull/27238 From wkemper at openjdk.org Fri Sep 12 22:19:18 2025 From: wkemper at openjdk.org (William Kemper) Date: Fri, 12 Sep 2025 22:19:18 GMT Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a runtime diagnostic option In-Reply-To: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com> References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com> Message-ID: On Thu, 11 Sep 2025 22:43:23 GMT, William Kemper wrote: > Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option. Converted to draft while we wait for performance evaluations to complete. This chart shows the distribution (as a box plot) of all concurrent evacuation times across all benchmarks and platforms for the past 24 hours (approximately 15K data points in total). Each facet of the chart shows 3 configurations: * top: The diagnostic option in this PR is enabled * middle: The diagnostic option is disabled * bottom: The baseline - this behavior does not exist in the product build. The first facet shows the effect of this option on _global_ GCs in Genshen. The second facet shows the effect of this option on _global_ GCs in Shenandoah. The last option shows the effect on _young_ evacuation in GenShen. The performance impact of testing if the option is enabled seems minimal for Genshen. The impact when the option is enabled is small, but notable. I cannot explain the outlier (p100) for Genshen's young collections on master. image ------------- PR Comment: https://git.openjdk.org/jdk/pull/27238#issuecomment-3282858675 PR Comment: https://git.openjdk.org/jdk/pull/27238#issuecomment-3286899661 From kdnilsen at openjdk.org Fri Sep 12 22:19:19 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Fri, 12 Sep 2025 22:19:19 GMT Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a runtime diagnostic option In-Reply-To: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com> References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com> Message-ID: On Thu, 11 Sep 2025 22:43:23 GMT, William Kemper wrote: > Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option. src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 326: > 324: return ShenandoahBarrierSet::resolve_forwarded(p); > 325: } > 326: Am wondering if we can template the implementation of try_evacuate_object and the LRB also, so that the fast path is unaffected by the existence of this extra run-time check. I'm curious to see if there is a measurable impact on performance from this change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27238#discussion_r2342574645 From kdnilsen at openjdk.org Sun Sep 14 01:32:27 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Sun, 14 Sep 2025 01:32:27 GMT Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a runtime diagnostic option In-Reply-To: References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com> Message-ID: On Fri, 12 Sep 2025 21:29:39 GMT, William Kemper wrote: > This chart shows the distribution (as a box plot) of all concurrent evacuation times across all benchmarks and platforms for the past 24 hours (approximately 15K data points in total). Each facet of the chart shows 3 configurations: > > * top: The diagnostic option in this PR is enabled > * middle: The diagnostic option is disabled > * bottom: The baseline - this behavior does not exist in the product build. I'm confused. It looks like it takes more time when this option is disabled. And it looks like this branch runs in less time than baseline, when this option is enabled. Can you explain what I'm missing? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27238#issuecomment-3289060922 From kdnilsen at openjdk.org Sun Sep 14 01:32:28 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Sun, 14 Sep 2025 01:32:28 GMT Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a runtime diagnostic option In-Reply-To: References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com> Message-ID: On Thu, 11 Sep 2025 23:31:11 GMT, Kelvin Nilsen wrote: >> Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option. > > src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 326: > >> 324: return ShenandoahBarrierSet::resolve_forwarded(p); >> 325: } >> 326: > > Am wondering if we can template the implementation of try_evacuate_object and the LRB also, so that the fast path is unaffected by the existence of this extra run-time check. I'm curious to see if there is a measurable impact on performance from this change. If we decide we want "better performance", it seems we could have two versions of the GC worker thread evacuation closures. One calls the templated version try_evacuate_object() that has this instrumentation in it. The other calls the templated version of try_evacuate_object() that does not have this instrumentation in it. For LRB, I assume we could have an if-then-else to decide which version to call. LRB evacuations are quite rare, I believe, so that doesn't bother me so much. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27238#discussion_r2347058185 From tschatzl at openjdk.org Mon Sep 15 07:18:14 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 15 Sep 2025 07:18:14 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v61] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * iwalulya review * documentation for a few PSS members * rename some member variables to contain _ct and _rt suffixes in remembered set verification ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23739/files - new: https://git.openjdk.org/jdk/pull/23739/files/1ced9f98..bf8cab33 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=60 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=59-60 Stats: 25 lines in 3 files changed: 10 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From tschatzl at openjdk.org Mon Sep 15 07:22:26 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 15 Sep 2025 07:22:26 GMT Subject: RFR: 8367507: Parallel: Remove PSPromotionManager::drain_stacks_depth [v2] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 11:12:30 GMT, Albert Mingkun Yang wrote: >> Trivial renaming a method so that we can remove one of two methods with identical implementations, `drain_stacks` and `drain_stacks_depth`. >> >> Test: tier1 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into pgc-stack-merge > - pgc-stack-merge Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27252#pullrequestreview-3223215578 From tschatzl at openjdk.org Mon Sep 15 07:23:31 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 15 Sep 2025 07:23:31 GMT Subject: RFR: 8367422: Parallel: Refactor local variables names in copy_unmarked_to_survivor_space In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 13:59:20 GMT, Albert Mingkun Yang wrote: > Trivial "renaming" a local variable and its type to better reflect its semantic and avoid much `HeapWord*`-vs-`oop` conversion. > > Test: Comparing the generated asm in release build and they are identical. Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27227#pullrequestreview-3223219013 From iwalulya at openjdk.org Mon Sep 15 07:45:59 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 15 Sep 2025 07:45:59 GMT Subject: RFR: 8366328: G1: Crash on reading os::thread_cpu_time In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 07:48:11 GMT, Ivan Walulya wrote: > Hi, > > Please review this patch to ensure that we do not attempt to read CPU time for GC threads that have already been terminated. > > Testing: Tier 1-3. This was intended to be a quick fix, however, I could not get it in quick enough. I am closing this in favor of [PR27190](https://github.com/openjdk/jdk/pull/27190) which is a more complete solution. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27087#issuecomment-3290870327 From iwalulya at openjdk.org Mon Sep 15 07:45:59 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 15 Sep 2025 07:45:59 GMT Subject: Withdrawn: 8366328: G1: Crash on reading os::thread_cpu_time In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 07:48:11 GMT, Ivan Walulya wrote: > Hi, > > Please review this patch to ensure that we do not attempt to read CPU time for GC threads that have already been terminated. > > Testing: Tier 1-3. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27087 From ayang at openjdk.org Mon Sep 15 07:47:56 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 15 Sep 2025 07:47:56 GMT Subject: RFR: 8367422: Parallel: Refactor local variables names in copy_unmarked_to_survivor_space In-Reply-To: References: Message-ID: <-InGI4IA0Jp22Z48tGaw2Y9ZPW1wRDPsvtF1PCj6tpM=.f071fc2c-ebdb-4363-8bb7-63350cbb2deb@github.com> On Thu, 11 Sep 2025 13:59:20 GMT, Albert Mingkun Yang wrote: > Trivial "renaming" a local variable and its type to better reflect its semantic and avoid much `HeapWord*`-vs-`oop` conversion. > > Test: Comparing the generated asm in release build and they are identical. Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27227#issuecomment-3290879216 From ayang at openjdk.org Mon Sep 15 07:47:56 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 15 Sep 2025 07:47:56 GMT Subject: RFR: 8367507: Parallel: Remove PSPromotionManager::drain_stacks_depth [v2] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 11:12:30 GMT, Albert Mingkun Yang wrote: >> Trivial renaming a method so that we can remove one of two methods with identical implementations, `drain_stacks` and `drain_stacks_depth`. >> >> Test: tier1 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into pgc-stack-merge > - pgc-stack-merge Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27252#issuecomment-3290879622 From ayang at openjdk.org Mon Sep 15 07:52:01 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 15 Sep 2025 07:52:01 GMT Subject: Integrated: 8367422: Parallel: Refactor local variables names in copy_unmarked_to_survivor_space In-Reply-To: References: Message-ID: <5IitmBD_JKgiXIzDwHMtjtP2X98CimkirZfkOHCSS8s=.d21636c9-b022-4f3e-861a-aa5722eed021@github.com> On Thu, 11 Sep 2025 13:59:20 GMT, Albert Mingkun Yang wrote: > Trivial "renaming" a local variable and its type to better reflect its semantic and avoid much `HeapWord*`-vs-`oop` conversion. > > Test: Comparing the generated asm in release build and they are identical. This pull request has now been integrated. Changeset: 9ca7b244 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/9ca7b24421a5ea4fafb39bcf0c9744696932f49d Stats: 11 lines in 1 file changed: 1 ins; 0 del; 10 mod 8367422: Parallel: Refactor local variables names in copy_unmarked_to_survivor_space Reviewed-by: fandreuzzi, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/27227 From ayang at openjdk.org Mon Sep 15 07:52:00 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 15 Sep 2025 07:52:00 GMT Subject: Integrated: 8367507: Parallel: Remove PSPromotionManager::drain_stacks_depth In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 09:12:22 GMT, Albert Mingkun Yang wrote: > Trivial renaming a method so that we can remove one of two methods with identical implementations, `drain_stacks` and `drain_stacks_depth`. > > Test: tier1 This pull request has now been integrated. Changeset: 2c13c66c Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/2c13c66cf9104a1b46842a5de5e2533a87fa1849 Stats: 8 lines in 3 files changed: 0 ins; 4 del; 4 mod 8367507: Parallel: Remove PSPromotionManager::drain_stacks_depth Reviewed-by: fandreuzzi, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/27252 From ayang at openjdk.org Mon Sep 15 08:28:56 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 15 Sep 2025 08:28:56 GMT Subject: RFR: 8367626: Parallel: Remove ParallelCompactData::summarize_dense_prefix Message-ID: <4C7vmePNpSeo7KXiLiSJUWTgOXBbq-dqgZtBvD6p9WQ=.7de375d3-0f3d-4163-857c-27f004643184@github.com> Remove the unnecessary summary operation on dense-prefix, because the summary operation is only needed for compaction, but dense-prefix doesn't participate in compaction. Test: tier1-5 ------------- Commit messages: - pgc-remove-dense-prefix-summary Changes: https://git.openjdk.org/jdk/pull/27286/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27286&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367626 Stats: 36 lines in 2 files changed: 1 ins; 31 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27286.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27286/head:pull/27286 PR: https://git.openjdk.org/jdk/pull/27286 From ayang at openjdk.org Mon Sep 15 08:48:24 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 15 Sep 2025 08:48:24 GMT Subject: RFR: 8367629: Parallel: Remove logging in PSAdjustWeakRootsClosure Message-ID: Trivial removing a develop-log print during young-gc weak root processing. Test: tier1 ------------- Commit messages: - pgc-remove-log Changes: https://git.openjdk.org/jdk/pull/27287/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27287&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367629 Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27287.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27287/head:pull/27287 PR: https://git.openjdk.org/jdk/pull/27287 From azafari at openjdk.org Mon Sep 15 08:49:42 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 15 Sep 2025 08:49:42 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v4] In-Reply-To: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> Message-ID: > The minimum acceptable value was 0 where using it as address was problematic according to UBSAN. > The acceptable value is changed to 64K. > > Tests: > linux-x64 tier1 Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26955/files - new: https://git.openjdk.org/jdk/pull/26955/files/76cf950e..251dd986 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26955&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26955&range=02-03 Stats: 23 lines in 2 files changed: 0 ins; 0 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/26955.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26955/head:pull/26955 PR: https://git.openjdk.org/jdk/pull/26955 From azafari at openjdk.org Mon Sep 15 08:49:46 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 15 Sep 2025 08:49:46 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v3] In-Reply-To: References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> <-eWIUjA4RqIgcpvFSyFxuiuganZpBqkMIdKSOVhnuMo=.79db2c26-5547-42fa-84d9-9bf5746728cf@github.com> Message-ID: On Fri, 12 Sep 2025 09:01:18 GMT, Johan Sj?len wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> lowest can be equal to highest > > src/hotspot/share/gc/shared/jvmFlagConstraintsGC.cpp line 288: > >> 286: // If an overflow happened in Arguments::set_heap_size(), MaxHeapSize will have too large a value. >> 287: // Check for this by ensuring that MaxHeapSize plus the requested min base address still fit within max_uintx. >> 288: if (value + MaxHeapSize < MaxHeapSize) {// overflow > > Can we perform the overflow check via subtraction from the max value instead? I know that unsigned types do wrap around, but at a first glance this will look wrong and make the reader stop and think. > > Style: Space between { and // > > > if (std::numeric_limits::max() - value < MaxHeapSize) { // overflow Using ` a < a - b` for checking overflow, does not work when `a - b` is negative and it will become a very large number when cast to unsigned. Space added. > src/hotspot/share/memory/memoryReserver.cpp line 560: > >> 558: if (!FLAG_IS_DEFAULT(HeapBaseMinAddress)) { >> 559: reserved = try_reserve_memory(size + noaccess_prefix, alignment, page_size, (char *)aligned_heap_base_min_address); >> 560: if (reserved.base() != (char *)aligned_heap_base_min_address) { // Enforce this exact address. > > Style: Please hug the * to the char for the casts Done. There are some preexisting cases like this. Should I change them too? > src/hotspot/share/memory/memoryReserver.cpp line 584: > >> 582: // Calc address range within we try to attach (range of possible start addresses). >> 583: char* const highest_start = align_down((char *)UnscaledOopHeapMax - size, attach_point_alignment); >> 584: char* const lowest_start = align_up((char *)aligned_heap_base_min_address, attach_point_alignment); > > Keep these as uintptr_t instead and only cast when trying to reserve Done. > src/hotspot/share/memory/memoryReserver.cpp line 595: > >> 593: >> 594: // Give it several tries from top of range to bottom. >> 595: if (aligned_heap_base_min_address + size <= (uintptr_t)zerobased_max && // Zerobased theoretical possible. > > Do the opposite: Have zerobased_max be uintptr_t and only cast it when it needs to become a char* Done. > src/hotspot/share/memory/memoryReserver.cpp line 612: > >> 610: } >> 611: lowest_start = align_up(lowest_start, attach_point_alignment); >> 612: assert(lowest_start <= highest_start, "lowest: " INTPTR_FORMAT " highest: " INTPTR_FORMAT, > > Keep these as uintptr_t and cast to char* only when reserving done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2348276821 PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2348278478 PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2348278713 PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2348279035 PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2348288660 From stefank at openjdk.org Mon Sep 15 09:28:21 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 15 Sep 2025 09:28:21 GMT Subject: RFR: 8367629: Parallel: Remove logging in PSAdjustWeakRootsClosure In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 08:40:57 GMT, Albert Mingkun Yang wrote: > Trivial removing a develop-log print during young-gc weak root processing. > > Test: tier1 Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27287#pullrequestreview-3223665223 From ayang at openjdk.org Mon Sep 15 10:09:27 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 15 Sep 2025 10:09:27 GMT Subject: RFR: 8367651: Parallel: Remove workers number checking in constructor of PSAdjustTask Message-ID: <2e3WwehTnC82T1ypS8Ma_n6gYe_GHVHpDj-epViJJ2M=.ce06fa76-bb36-4df4-bebd-5400fec9168b@github.com> Uniform thread claiming path for different number of workers. Test: tier1-3 ------------- Commit messages: - pgc-remove-if Changes: https://git.openjdk.org/jdk/pull/27290/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27290&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367651 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27290.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27290/head:pull/27290 PR: https://git.openjdk.org/jdk/pull/27290 From aboldtch at openjdk.org Mon Sep 15 10:13:23 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 15 Sep 2025 10:13:23 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v4] In-Reply-To: References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> Message-ID: On Mon, 15 Sep 2025 08:49:42 GMT, Afshin Zafari wrote: >> The minimum acceptable value was 0 where using it as address was problematic according to UBSAN. >> The acceptable value is changed to 64K. >> >> Tests: >> linux-x64 tier1 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > fixes I agree with @jdksjolen that I think we should go towards using `uintptr_t` as far as possible. Maybe we do it piecemeal like this. Eventually we could end up using `uintptr_t` until we reach the os layer. Looks like you at least have to clean up the `uintptr_t` vs `uint64_t` in the touched methods as some platforms have them define as `unsigned long` vs `unsigned long long`. src/hotspot/share/memory/memoryReserver.cpp line 612: > 610: } > 611: lowest_start = align_up(lowest_start, attach_point_alignment); > 612: assert(lowest_start < highest_start, "lowest: " INTPTR_FORMAT " highest: " INTPTR_FORMAT, We should support a start which is a single value. Suggestion: assert(lowest_start <= highest_start, "lowest: " INTPTR_FORMAT " highest: " INTPTR_FORMAT, ------------- PR Review: https://git.openjdk.org/jdk/pull/26955#pullrequestreview-3223852121 PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2348500738 From iwalulya at openjdk.org Mon Sep 15 10:32:14 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 15 Sep 2025 10:32:14 GMT Subject: RFR: 8366865: G1: Allocation GC Pauses Triggered after JVM has started shutdown [v2] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 08:19:45 GMT, Ivan Walulya wrote: >> src/hotspot/share/gc/shared/collectedHeap.cpp line 616: >> >>> 614: // If the VM is shutting down, we may have skipped VM_CollectForAllocation. >>> 615: // To avoid returning nullptr (which could cause premature OOME), we stall >>> 616: // allocation requests here until the VM shutdown is complete. >> >> If I understand the shutdown sequence correctly, I don't think you can do this without risking a hang. The thread doing the shutdown can potentially execute code that requires allocation after `is_shutting_down()` returns true. This is due to the JVMTI events posted from `before_exit`: >> >> if (JvmtiExport::should_post_thread_life()) { >> JvmtiExport::post_thread_end(thread); >> } >> >> // Always call even when there are not JVMTI environments yet, since environments >> // may be attached late and JVMTI must track phases of VM execution >> JvmtiExport::post_vm_death(); >> >> I think if you can't GC during shutdown then you have to simply let the allocation fail. > > Thanks, I completely overlooked the JVMTI callbacks. It?s probably better to stall with a timeout and then return an allocation failure. I moved the `Universe::before_exit()` call and also added a timed `wait`. @dholmes-ora do you have any concerns with this approach? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2348552023 From shade at openjdk.org Mon Sep 15 11:50:36 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 15 Sep 2025 11:50:36 GMT Subject: RFR: 8348278: Trim InitialRAMPercentage to improve startup in default modes [v4] In-Reply-To: References: Message-ID: <-soNVCsKyzH55zWU9IlsfY4PotrvY7r_0k96XY6GlsY=.b32aa936-f7c0-4d65-a678-24919f7124f8@github.com> On Tue, 2 Sep 2025 12:57:47 GMT, Aleksey Shipilev wrote: >> See bug for discussion. This is the code change, which is simple. What is not simple is deciding what the new value should be. The change would probably require CSR, which I can file after we agree on the value. >> >> I think cutting to 0.2% of RAM size gets us into good sweet spot: >> - On huge 1024G machine, this yields 2G initial heap >> - On reasonably sized 128G machine, this gives 256M initial heap >> - On smaller 1G container, this gives 2M initial heap >> >> Additional testing: >> - [x] Linux AArch64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Also man page > - Fix Any other takers? @albertnetymk, @earthling-amzn, @stefank, @kstefanj, maybe? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23262#issuecomment-3291760186 From sjohanss at openjdk.org Mon Sep 15 12:43:14 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Mon, 15 Sep 2025 12:43:14 GMT Subject: RFR: 8348278: Trim InitialRAMPercentage to improve startup in default modes [v4] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 12:57:47 GMT, Aleksey Shipilev wrote: >> See bug for discussion. This is the code change, which is simple. What is not simple is deciding what the new value should be. The change would probably require CSR, which I can file after we agree on the value. >> >> I think cutting to 0.2% of RAM size gets us into good sweet spot: >> - On huge 1024G machine, this yields 2G initial heap >> - On reasonably sized 128G machine, this gives 256M initial heap >> - On smaller 1G container, this gives 2M initial heap >> >> Additional testing: >> - [x] Linux AArch64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Also man page > - Fix I started some runs in our internal perf-testing environment to see what kind of results we would get with a change like this. I think the reasoning sounds good for large machines, and for smaller containers some quick testing indicates that we never go below 8M for `Min/InitialHeapSize` which I also think is good. 2M sounds very small :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23262#issuecomment-3291985134 From tschatzl at openjdk.org Mon Sep 15 13:19:48 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 15 Sep 2025 13:19:48 GMT Subject: RFR: 8366865: G1: Allocation GC Pauses Triggered after JVM has started shutdown [v2] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 10:38:08 GMT, Ivan Walulya wrote: >> Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. >> >> Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. >> >> Testing: Tier 1-7 > > Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: > > - return on timeout > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - timed wait > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - space > - remove debug logs > - remove debug logs > - log_cpu_time > - init I think this is mostly good, just some minor nitpicks. src/hotspot/share/gc/shared/collectedHeap.cpp line 616: > 614: // If the VM is shutting down, we may have skipped VM_CollectForAllocation. > 615: // To avoid returning nullptr (which could cause premature OOME), we stall > 616: // allocation requests here allow the VM shutdown is complete. This sentence is confusing and does not seem to be proper English. I do not completely understand what is meant, (maybe `s/allow/until`?) so no particular suggestions from me. src/hotspot/share/gc/shared/collectedHeap.cpp line 624: > 622: // sequence completes in the common case. > 623: // - short enough to avoid excessive stall time if the shutdown itself > 624: // triggers a GC. I think this should be put into the .hpp file, or at least the comment `// Stall allocation requests until the VM shutdown is complete.` seems a bit misleading if in reality the VM has a timeout. src/hotspot/share/gc/shared/collectedHeap.cpp line 626: > 624: // triggers a GC. > 625: MonitorLocker ml(VMExit_lock); > 626: ml.wait(2 * 1000); Maybe log a warning or such in case this times out - it seems to be only possible at that point if we are continuing for too long, and the VM will OOME soon anyway (the code will return `nullptr`). However I'm fine if we think that is not necessary. Also maybe use the constant `MILLIUNITS` instead of the hardcoded `1000`. src/hotspot/share/runtime/java.cpp line 511: > 509: #endif > 510: > 511: // Run before exit and then stop concurrent GC threads I think this comment should be improved - it looks like a straggler from the many changes in this file. It describes what `Universe::before_exit()` does, but maybe such documentation (what it does) is better put in the documentation for that method. ------------- Changes requested by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27190#pullrequestreview-3224510575 PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2348932834 PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2348941360 PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2348962032 PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2348952363 From tschatzl at openjdk.org Mon Sep 15 13:19:50 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 15 Sep 2025 13:19:50 GMT Subject: RFR: 8366865: G1: Allocation GC Pauses Triggered after JVM has started shutdown [v2] In-Reply-To: References: <04Lru322UkYz11DPPFo3alqoYCd7pSEsPSkpW4Z0_bQ=.d536246e-a5bb-4594-8966-52936927e117@github.com> Message-ID: <3V6E695BA79HaxWhscgYqZAjY6bokbZptRqcJ1DZq4A=.9aecd1f1-b5c1-4336-8b66-fc4829ab2827@github.com> On Wed, 10 Sep 2025 13:55:44 GMT, Ivan Walulya wrote: >> src/hotspot/share/gc/shared/gcVMOperations.cpp line 115: >> >>> 113: >>> 114: // Check invocations >>> 115: if (skip_operation() || Universe::heap()->is_shutting_down()) { >> >> Can the new condition be inlined inside `skip_operation()`? > > In the first iteration I had it inlined, but then decided to make it more explicit. I can change it back if you prefer No particular preference, but the comments in `skip_operation()` need to be adjusted to also indicate that as additional condition. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2348946011 From ayang at openjdk.org Mon Sep 15 13:26:24 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 15 Sep 2025 13:26:24 GMT Subject: RFR: 8346005: Parallel: Incorrect page size calculation with UseLargePages [v5] In-Reply-To: References: Message-ID: > Refactor the heap-space and OS memory interface code to clearly separate two related but distinct concepts: `alignment` and `os-page-size`. These are now represented as two fields in `PSVirtualSpace`. > > The parallel heap consists of four spaces: old, eden, from, and to. The first belongs to the old generation, while the latter three belong to the young generation. > > The size of any space is always aligned to `alignment`, which also determines the unit for resizing. To keep the implementation simple while allowing flexible per-space commit and uncommit operations, each space must contain at least one OS page. As a result, `alignment` is always greater than or equal to `os-page-size`. > > When using explicit large pages -- which require pre-allocating large pages before the VM starts -- the actual OS page size is not known until the heap has been reserved. The additional logic in `ParallelScavengeHeap::initialize` detects the OS page size in use and adjusts `alignment` if necessary. > > Test: tier1?8 Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'master' into pgc-largepage - page-size - Merge branch 'master' into pgc-largepage - Merge branch 'master' into pgc-largepage - Merge branch 'master' into pgc-largepage - pgc-largepage ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26700/files - new: https://git.openjdk.org/jdk/pull/26700/files/74d4fa3c..c7254311 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26700&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26700&range=03-04 Stats: 28369 lines in 982 files changed: 14055 ins; 9009 del; 5305 mod Patch: https://git.openjdk.org/jdk/pull/26700.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26700/head:pull/26700 PR: https://git.openjdk.org/jdk/pull/26700 From ayang at openjdk.org Mon Sep 15 15:29:02 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 15 Sep 2025 15:29:02 GMT Subject: RFR: 8367629: Parallel: Remove logging in PSAdjustWeakRootsClosure In-Reply-To: References: Message-ID: <3A10V2lOHvREolO-2p-EZbovmfRy4MPiwUcaSi56MWY=.f25cb0f2-f250-4ad4-adda-627e0a6a02ce@github.com> On Mon, 15 Sep 2025 08:40:57 GMT, Albert Mingkun Yang wrote: > Trivial removing a develop-log print during young-gc weak root processing. > > Test: tier1 Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27287#issuecomment-3292747176 From ayang at openjdk.org Mon Sep 15 15:29:04 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 15 Sep 2025 15:29:04 GMT Subject: Integrated: 8367629: Parallel: Remove logging in PSAdjustWeakRootsClosure In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 08:40:57 GMT, Albert Mingkun Yang wrote: > Trivial removing a develop-log print during young-gc weak root processing. > > Test: tier1 This pull request has now been integrated. Changeset: e8dda2b6 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/e8dda2b67524b6575124581464921d46335dcad7 Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod 8367629: Parallel: Remove logging in PSAdjustWeakRootsClosure Reviewed-by: stefank ------------- PR: https://git.openjdk.org/jdk/pull/27287 From wkemper at openjdk.org Mon Sep 15 16:27:47 2025 From: wkemper at openjdk.org (William Kemper) Date: Mon, 15 Sep 2025 16:27:47 GMT Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a runtime diagnostic option In-Reply-To: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com> References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com> Message-ID: On Thu, 11 Sep 2025 22:43:23 GMT, William Kemper wrote: > Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option. I think we can ignore the outliers (the long "whisker" in the box plot represents p100 (max) time). The `master` branch likely has more benchmark runs than the feature branches so it may in turn be more likely to experience a long evacuation phase. The colored portion of the box plot represents P25 to P75 and aligns more with my expectations for the performance. I don't have an explanation for why enabling the diagnostic feature seems to reduce the severity of the outliers. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27238#issuecomment-3292981876 From iwalulya at openjdk.org Mon Sep 15 17:12:35 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 15 Sep 2025 17:12:35 GMT Subject: RFR: 8366865: G1: Allocation GC Pauses Triggered after JVM has started shutdown [v3] In-Reply-To: References: Message-ID: > Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. > > Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. > > Testing: Tier 1-7 Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: Thomas Review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27190/files - new: https://git.openjdk.org/jdk/pull/27190/files/187a463b..0e45912b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27190&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27190&range=01-02 Stats: 13 lines in 4 files changed: 5 ins; 5 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27190.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27190/head:pull/27190 PR: https://git.openjdk.org/jdk/pull/27190 From kdnilsen at openjdk.org Mon Sep 15 19:55:09 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 15 Sep 2025 19:55:09 GMT Subject: RFR: 8367708: GenShen: Reduce total evacuation burden Message-ID: This PR provides several improvements that cumulatively reduce the amount of evacuation performed by GenShen compared to traditional Shenandoah. Specifically: 1. Do not promote humongous arrays of primitive data. Leaving these regions in the young generation allows them to be reclaimed more quickly when they become garbage. There is no disadvantage to leaving these regions in the young generation as their contents does not need to be scanned by the garbage collector. 2. Change the default value of ShenandoahOldGarbageThreshold from 15% to 25%. This results in smaller sets of candidate regions for mixed evacuation, less aggressive compaction of old generation. This also increases the likelihood that a region will be promoted in place instead of promoted by evacuation. 3. Only promote regions in place if the used within a region exceeds ShenandoahGenerationalMinPIPUsage (default 30) percent of the heap region size. This is enforced in combination with the preexisting requirement that the garbage within the region be less than ShenandoahOldGarbageThreshold (new default 25) percent of the heap region size. This causes regions with very low utilization to be promoted by evacuation rather than promoted in place. While the immediate effect of this change is to perform more copying when the region is promoted, the secondary effect is that this region does not need to be evacuated at a later time, after it has accumulate more live data, as part of an effort to defragment old-gen memory. 4. Only defragment old-gen memory if the command-line has requested non-zero reserves for humongous objects (ShenandoahGenerationalHumongousReserves). Previously, we would invest in defragmenting old-gen memory every time we finished old-generation marking, even if ShenandoahGenerationalHumongousReserves equals zero. ------------- Commit messages: - Merge remote-tracking branch 'jdk/master' into combined-evac-improvements - Merge remote-tracking branch 'origin/master' into combined-evac-improvements - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - manualy resolve evac tracker diffs - Merge remote-tracking branch 'jdk/master' into combined-evac-improvements - Merge remote-tracking branch 'jdk/master' into combined-evac-improvements-gh - Only defragment old if non-zero humongous reserve - Less aggressive compaction of old - ... and 40 more: https://git.openjdk.org/jdk/compare/5271448b...6fc458aa Changes: https://git.openjdk.org/jdk/pull/27278/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27278&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367708 Stats: 50 lines in 6 files changed: 29 ins; 5 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/27278.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27278/head:pull/27278 PR: https://git.openjdk.org/jdk/pull/27278 From kdnilsen at openjdk.org Mon Sep 15 19:55:09 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 15 Sep 2025 19:55:09 GMT Subject: RFR: 8367708: GenShen: Reduce total evacuation burden In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 04:44:24 GMT, Kelvin Nilsen wrote: > This PR provides several improvements that cumulatively reduce the amount of evacuation performed by GenShen compared to traditional Shenandoah. Specifically: > > 1. Do not promote humongous arrays of primitive data. Leaving these regions in the young generation allows them to be reclaimed more quickly when they become garbage. There is no disadvantage to leaving these regions in the young generation as their contents does not need to be scanned by the garbage collector. > 2. Change the default value of ShenandoahOldGarbageThreshold from 15% to 25%. This results in smaller sets of candidate regions for mixed evacuation, less aggressive compaction of old generation. This also increases the likelihood that a region will be promoted in place instead of promoted by evacuation. > 3. Only promote regions in place if the used within a region exceeds ShenandoahGenerationalMinPIPUsage (default 30) percent of the heap region size. This is enforced in combination with the preexisting requirement that the garbage within the region be less than ShenandoahOldGarbageThreshold (new default 25) percent of the heap region size. This causes regions with very low utilization to be promoted by evacuation rather than promoted in place. While the immediate effect of this change is to perform more copying when the region is promoted, the secondary effect is that this region does not need to be evacuated at a later time, after it has accumulate more live data, as part of an effort to defragment old-gen memory. > 4. Only defragment old-gen memory if the command-line has requested non-zero reserves for humongous objects (ShenandoahGenerationalHumongousReserves). Previously, we would invest in defragmenting old-gen memory every time we finished old-generation marking, even if ShenandoahGenerationalHumongousReserves equals zero. The impact on overall SpecJBB scores has been minimal. Compare top charts (proposed PR) with bottom charts (baseline). These charts show the maximum number of bytes evacuated by workers and mutators into the old generation (blue, purple) across all benchmarks (~20 executions of 6 benchmark suites) and platforms (x86, aarch64). Green represents young bytes evacuated by workers; red is young bytes evacuated by mutators. Young evacuations increase slightly with this reduction in old evacuations. image ------------- PR Comment: https://git.openjdk.org/jdk/pull/27278#issuecomment-3293659081 From wkemper at openjdk.org Mon Sep 15 21:06:17 2025 From: wkemper at openjdk.org (William Kemper) Date: Mon, 15 Sep 2025 21:06:17 GMT Subject: RFR: 8367708: GenShen: Reduce total evacuation burden In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 04:44:24 GMT, Kelvin Nilsen wrote: > This PR provides several improvements that cumulatively reduce the amount of evacuation performed by GenShen compared to traditional Shenandoah. Specifically: > > 1. Do not promote humongous arrays of primitive data. Leaving these regions in the young generation allows them to be reclaimed more quickly when they become garbage. There is no disadvantage to leaving these regions in the young generation as their contents does not need to be scanned by the garbage collector. > 2. Change the default value of ShenandoahOldGarbageThreshold from 15% to 25%. This results in smaller sets of candidate regions for mixed evacuation, less aggressive compaction of old generation. This also increases the likelihood that a region will be promoted in place instead of promoted by evacuation. > 3. Only promote regions in place if the used within a region exceeds ShenandoahGenerationalMinPIPUsage (default 30) percent of the heap region size. This is enforced in combination with the preexisting requirement that the garbage within the region be less than ShenandoahOldGarbageThreshold (new default 25) percent of the heap region size. This causes regions with very low utilization to be promoted by evacuation rather than promoted in place. While the immediate effect of this change is to perform more copying when the region is promoted, the secondary effect is that this region does not need to be evacuated at a later time, after it has accumulated more live data, as part of an effort to defragment old-gen memory. > 4. Only defragment old-gen memory if the command-line has requested non-zero reserves for humongous objects (ShenandoahGenerationalHumongousReserves). Previously, we would invest in defragmenting old-gen memory every time we finished old-generation marking, even if ShenandoahGenerationalHumongousReserves equals zero. I think there is an accidental change in here that reverts https://github.com/openjdk/jdk/pull/26256. src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1443: > 1441: > 1442: oop humongous_obj = cast_to_oop(start->bottom()); > 1443: size_t size = humongous_obj->size(); Is this intentional? This looks like it would reintroduce https://github.com/openjdk/jdk/pull/26256 (crash trying to access size of humongous object after its class has been unloaded). src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 841: > 839: static inline void atomic_clear_oop(narrowOop* addr, narrowOop compare); > 840: > 841: size_t trash_humongous_region_at(ShenandoahHeapRegion *r); Original method was `const`, removal seems unintentional. ------------- Changes requested by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27278#pullrequestreview-3226316735 PR Review Comment: https://git.openjdk.org/jdk/pull/27278#discussion_r2350120750 PR Review Comment: https://git.openjdk.org/jdk/pull/27278#discussion_r2350122230 From kdnilsen at openjdk.org Mon Sep 15 21:32:25 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 15 Sep 2025 21:32:25 GMT Subject: RFR: 8367708: GenShen: Reduce total evacuation burden In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 20:59:32 GMT, William Kemper wrote: >> This PR provides several improvements that cumulatively reduce the amount of evacuation performed by GenShen compared to traditional Shenandoah. Specifically: >> >> 1. Do not promote humongous arrays of primitive data. Leaving these regions in the young generation allows them to be reclaimed more quickly when they become garbage. There is no disadvantage to leaving these regions in the young generation as their contents does not need to be scanned by the garbage collector. >> 2. Change the default value of ShenandoahOldGarbageThreshold from 15% to 25%. This results in smaller sets of candidate regions for mixed evacuation, less aggressive compaction of old generation. This also increases the likelihood that a region will be promoted in place instead of promoted by evacuation. >> 3. Only promote regions in place if the used within a region exceeds ShenandoahGenerationalMinPIPUsage (default 30) percent of the heap region size. This is enforced in combination with the preexisting requirement that the garbage within the region be less than ShenandoahOldGarbageThreshold (new default 25) percent of the heap region size. This causes regions with very low utilization to be promoted by evacuation rather than promoted in place. While the immediate effect of this change is to perform more copying when the region is promoted, the secondary effect is that this region does not need to be evacuated at a later time, after it has accumulated more live data, as part of an effort to defragment old-gen memory. >> 4. Only defragment old-gen memory if the command-line has requested non-zero reserves for humongous objects (ShenandoahGenerationalHumongousReserves). Previously, we would invest in defragmenting old-gen memory every time we finished old-generation marking, even if ShenandoahGenerationalHumongousReserves equals zero. > > src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1443: > >> 1441: >> 1442: oop humongous_obj = cast_to_oop(start->bottom()); >> 1443: size_t size = humongous_obj->size(); > > Is this intentional? This looks like it would reintroduce https://github.com/openjdk/jdk/pull/26256 (crash trying to access size of humongous object after its class has been unloaded). good catch. I'll change how this is implemented. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27278#discussion_r2350171314 From phh at openjdk.org Mon Sep 15 23:02:13 2025 From: phh at openjdk.org (Paul Hohensee) Date: Mon, 15 Sep 2025 23:02:13 GMT Subject: RFR: 8367450: Shenandoah: Log the composition of the collection set In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 21:40:50 GMT, William Kemper wrote: > Reuse the same log message from GenShen which details the composition of the live data to be evacuated. In the non-generational modes, all regions are considered young and nothing will be promoted (or old). Shouldn't evacInfo be initialized via constructor? ------------- PR Review: https://git.openjdk.org/jdk/pull/27235#pullrequestreview-3226556674 From phh at openjdk.org Mon Sep 15 23:10:13 2025 From: phh at openjdk.org (Paul Hohensee) Date: Mon, 15 Sep 2025 23:10:13 GMT Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a runtime diagnostic option In-Reply-To: References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com> Message-ID: On Sun, 14 Sep 2025 01:28:33 GMT, Kelvin Nilsen wrote: >> src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 326: >> >>> 324: return ShenandoahBarrierSet::resolve_forwarded(p); >>> 325: } >>> 326: >> >> Am wondering if we can template the implementation of try_evacuate_object and the LRB also, so that the fast path is unaffected by the existence of this extra run-time check. I'm curious to see if there is a measurable impact on performance from this change. > > If we decide we want "better performance", it seems we could have two versions of the GC worker thread evacuation closures. One calls the templated version try_evacuate_object() that has this instrumentation in it. The other calls the templated version of try_evacuate_object() that does not have this instrumentation in it. For LRB, I assume we could have an if-then-else to decide which version to call. LRB evacuations are quite rare, I believe, so that doesn't bother me so much. On typical hardware, if the test is in the fast path, the load of ShenandoahEvacTracking will hit in L1, the latency will be absorbed by speculation, and the cmp/branch is a single clock. So maybe 2 clocks at most. Downside is that if ShenandoahEvacTracking is the only thing being accessed in its cache line, you waste an L1 line. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27238#discussion_r2350295732 From kdnilsen at openjdk.org Mon Sep 15 23:16:01 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 15 Sep 2025 23:16:01 GMT Subject: RFR: 8367708: GenShen: Reduce total evacuation burden [v2] In-Reply-To: References: Message-ID: > This PR provides several improvements that cumulatively reduce the amount of evacuation performed by GenShen compared to traditional Shenandoah. Specifically: > > 1. Do not promote humongous arrays of primitive data. Leaving these regions in the young generation allows them to be reclaimed more quickly when they become garbage. There is no disadvantage to leaving these regions in the young generation as their contents does not need to be scanned by the garbage collector. > 2. Change the default value of ShenandoahOldGarbageThreshold from 15% to 25%. This results in smaller sets of candidate regions for mixed evacuation, less aggressive compaction of old generation. This also increases the likelihood that a region will be promoted in place instead of promoted by evacuation. > 3. Only promote regions in place if the used within a region exceeds ShenandoahGenerationalMinPIPUsage (default 30) percent of the heap region size. This is enforced in combination with the preexisting requirement that the garbage within the region be less than ShenandoahOldGarbageThreshold (new default 25) percent of the heap region size. This causes regions with very low utilization to be promoted by evacuation rather than promoted in place. While the immediate effect of this change is to perform more copying when the region is promoted, the secondary effect is that this region does not need to be evacuated at a later time, after it has accumulated more live data, as part of an effort to defragment old-gen memory. > 4. Only defragment old-gen memory if the command-line has requested non-zero reserves for humongous objects (ShenandoahGenerationalHumongousReserves). Previously, we would invest in defragmenting old-gen memory every time we finished old-generation marking, even if ShenandoahGenerationalHumongousReserves equals zero. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Respond to reviewer feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27278/files - new: https://git.openjdk.org/jdk/pull/27278/files/6fc458aa..69a76009 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27278&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27278&range=00-01 Stats: 20 lines in 2 files changed: 9 ins; 4 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27278.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27278/head:pull/27278 PR: https://git.openjdk.org/jdk/pull/27278 From wkemper at openjdk.org Tue Sep 16 00:02:14 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 16 Sep 2025 00:02:14 GMT Subject: RFR: 8367708: GenShen: Reduce total evacuation burden [v2] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 23:16:01 GMT, Kelvin Nilsen wrote: >> This PR provides several improvements that cumulatively reduce the amount of evacuation performed by GenShen compared to traditional Shenandoah. Specifically: >> >> 1. Do not promote humongous arrays of primitive data. Leaving these regions in the young generation allows them to be reclaimed more quickly when they become garbage. There is no disadvantage to leaving these regions in the young generation as their contents does not need to be scanned by the garbage collector. >> 2. Change the default value of ShenandoahOldGarbageThreshold from 15% to 25%. This results in smaller sets of candidate regions for mixed evacuation, less aggressive compaction of old generation. This also increases the likelihood that a region will be promoted in place instead of promoted by evacuation. >> 3. Only promote regions in place if the used within a region exceeds ShenandoahGenerationalMinPIPUsage (default 30) percent of the heap region size. This is enforced in combination with the preexisting requirement that the garbage within the region be less than ShenandoahOldGarbageThreshold (new default 25) percent of the heap region size. This causes regions with very low utilization to be promoted by evacuation rather than promoted in place. While the immediate effect of this change is to perform more copying when the region is promoted, the secondary effect is that this region does not need to be evacuated at a later time, after it has accumulated more live data, as part of an effort to defragment old-gen memory. >> 4. Only defragment old-gen memory if the command-line has requested non-zero reserves for humongous objects (ShenandoahGenerationalHumongousReserves). Previously, we would invest in defragmenting old-gen memory every time we finished old-generation marking, even if ShenandoahGenerationalHumongousReserves equals zero. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > Respond to reviewer feedback Changes requested by wkemper (Reviewer). src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1442: > 1440: assert(start->is_humongous_start(), "reclaim regions starting with the first one"); > 1441: > 1442: // Cannot access humongous_obj->size() in case class has been unloaded Why do we want to make two passes over the humongous object? I don't see why the original code needs to change or how this change is related to this PR? ------------- PR Review: https://git.openjdk.org/jdk/pull/27278#pullrequestreview-3226643002 PR Review Comment: https://git.openjdk.org/jdk/pull/27278#discussion_r2350352216 From wkemper at openjdk.org Tue Sep 16 00:30:37 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 16 Sep 2025 00:30:37 GMT Subject: RFR: 8367450: Shenandoah: Log the composition of the collection set [v2] In-Reply-To: References: Message-ID: > Reuse the same log message from GenShen which details the composition of the live data to be evacuated. In the non-generational modes, all regions are considered young and nothing will be promoted (or old). William Kemper has updated the pull request incrementally with one additional commit since the last revision: Simplify JFR evac info reporting ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27235/files - new: https://git.openjdk.org/jdk/pull/27235/files/b3e10d4c..14d36331 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27235&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27235&range=00-01 Stats: 162 lines in 4 files changed: 1 ins; 131 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/27235.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27235/head:pull/27235 PR: https://git.openjdk.org/jdk/pull/27235 From dholmes at openjdk.org Tue Sep 16 03:02:09 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 16 Sep 2025 03:02:09 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v3] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 10:29:11 GMT, Ivan Walulya wrote: >> Thanks, I completely overlooked the JVMTI callbacks. It?s probably better to stall with a timeout and then return an allocation failure. > > I moved the `Universe::before_exit()` call and also added a timed `wait`. > @dholmes-ora do you have any concerns with this approach? Yes I do have concerns - sorry. Any change to the shutdown sequence needs very careful analysis. You have now changed the circumstances whereby the JVMTI events get posted. Maybe it won't matter, maybe it will - the issue is that it is very hard to determine the impact of such a change until you get notified that someone's code is now broken. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2350540080 From duke at openjdk.org Tue Sep 16 04:04:19 2025 From: duke at openjdk.org (Rui Li) Date: Tue, 16 Sep 2025 04:04:19 GMT Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a runtime diagnostic option In-Reply-To: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com> References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com> Message-ID: On Thu, 11 Sep 2025 22:43:23 GMT, William Kemper wrote: > Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option. This print might also need to be sandwiched by the `ShenandoahEvacTracking` flag check? https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.cpp#L332-L333 ------------- PR Comment: https://git.openjdk.org/jdk/pull/27238#issuecomment-3294824583 From fyang at openjdk.org Tue Sep 16 06:06:23 2025 From: fyang at openjdk.org (Fei Yang) Date: Tue, 16 Sep 2025 06:06:23 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v59] In-Reply-To: References: Message-ID: <-D3Oiz-fmDudrEt2zZDa40Xff-Z4DP5GBWhts-CxPsY=.ea2ea9d6-49e6-4973-b4d2-cc1e0201f3c8@github.com> On Thu, 11 Sep 2025 07:24:13 GMT, Thomas Schatzl wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * walulyai review > > That test failure in windows-x64 is a shenandoah timeout that looks unrelated. @tschatzl : Hi, would you mind adding a small cleanup change for riscv? This also adds back the assertion about the registers. Still test good on linux-riscv64 platform. [riscv-addon.diff.txt](https://github.com/user-attachments/files/22356611/riscv-addon.diff.txt) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3295662846 From duke at openjdk.org Tue Sep 16 06:54:33 2025 From: duke at openjdk.org (duke) Date: Tue, 16 Sep 2025 06:54:33 GMT Subject: RFR: 8359104: gc/TestAlwaysPreTouchBehavior.java# fails on Linux [v3] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 14:32:19 GMT, Andreas Steiner wrote: >> Get accurate RSS, from smaps_rollup if available(Linux >= 4.14), because the RSS from status is inaccurate especially on systems with more than 32 CPUs. >> >> Not sure if all the additional meminfos like the Pss, Pss_dirty, Pss_Anon, Pss_File, Pss_Shmem, Swap and SwapPss are really needed too. But can be perhaps helpful too. >> >> As the inaccurate memory infos are still used in other methods: >> - [print_process_memory_info()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L2393) >> - [jfr_report_memory_info()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L2686) >> - [trim_native_heap()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L5376) >> >> one can think about to use the accurate values there too. > > Andreas Steiner has updated the pull request incrementally with one additional commit since the last revision: > > Changed num_found and num_values to size_t, do the null-check right after the fopen and return early, eliminated the variable shadowing of info @ansteiner Your change (at version 6c6fc40e006046aad728a150cd31bdf643acbc6f) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27192#issuecomment-3295952608 From asteiner at openjdk.org Tue Sep 16 07:20:34 2025 From: asteiner at openjdk.org (Andreas Steiner) Date: Tue, 16 Sep 2025 07:20:34 GMT Subject: Integrated: 8359104: gc/TestAlwaysPreTouchBehavior.java# fails on Linux In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 13:55:59 GMT, Andreas Steiner wrote: > Get accurate RSS, from smaps_rollup if available(Linux >= 4.14), because the RSS from status is inaccurate especially on systems with more than 32 CPUs. > > Not sure if all the additional meminfos like the Pss, Pss_dirty, Pss_Anon, Pss_File, Pss_Shmem, Swap and SwapPss are really needed too. But can be perhaps helpful too. > > As the inaccurate memory infos are still used in other methods: > - [print_process_memory_info()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L2393) > - [jfr_report_memory_info()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L2686) > - [trim_native_heap()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L5376) > > one can think about to use the accurate values there too. This pull request has now been integrated. Changeset: 73df06c8 Author: Andreas Steiner Committer: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/73df06c80c33be584b054a528ecdab4ecbf51d56 Stats: 61 lines in 3 files changed: 57 ins; 0 del; 4 mod 8359104: gc/TestAlwaysPreTouchBehavior.java# fails on Linux Reviewed-by: mbaesken, ayang ------------- PR: https://git.openjdk.org/jdk/pull/27192 From tschatzl at openjdk.org Tue Sep 16 07:36:40 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 16 Sep 2025 07:36:40 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v59] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 07:24:13 GMT, Thomas Schatzl wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * walulyai review > > That test failure in windows-x64 is a shenandoah timeout that looks unrelated. > @tschatzl : Hi, would you mind adding a small cleanup change for riscv? This also adds back the assertion about the registers. Still test good on linux-riscv64 platform. [riscv-addon.diff.txt](https://github.com/user-attachments/files/22356611/riscv-addon.diff.txt) This is the `end` -> `count` transformation in the barrier I suggested earlier for RISC-V, isn't it? Thanks for contributing that, but would you mind me holding off this until @theRealAph acks that similar change for aarch64? It would be unfortunate imo if the implementations diverge too much. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3296253540 From fyang at openjdk.org Tue Sep 16 07:41:46 2025 From: fyang at openjdk.org (Fei Yang) Date: Tue, 16 Sep 2025 07:41:46 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v59] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 07:33:18 GMT, Thomas Schatzl wrote: > > @tschatzl : Hi, would you mind adding a small cleanup change for riscv? This also adds back the assertion about the registers. Still test good on linux-riscv64 platform. [riscv-addon.diff.txt](https://github.com/user-attachments/files/22356611/riscv-addon.diff.txt) > > This is the `end` -> `count` transformation in the barrier I suggested earlier for RISC-V, isn't it? Thanks for contributing that, but would you mind me holding off this until @theRealAph acks that similar change for aarch64? It would be unfortunate imo if the implementations diverge too much. Yes, sure! The purpose is to minimize the difference to avoid possible issues in the future. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3296286316 From stefank at openjdk.org Tue Sep 16 08:22:31 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 16 Sep 2025 08:22:31 GMT Subject: RFR: 8367417: Serial: Use NMethodToOopClosure during Young GC In-Reply-To: <0cxHO0STcFcvdzE2UyoXFQB5Xz3IvGoHX2xb6fr3hW8=.de6c8353-4aea-42bc-bc56-1841a60f2e99@github.com> References: <0cxHO0STcFcvdzE2UyoXFQB5Xz3IvGoHX2xb6fr3hW8=.de6c8353-4aea-42bc-bc56-1841a60f2e99@github.com> Message-ID: On Thu, 11 Sep 2025 13:07:11 GMT, Albert Mingkun Yang wrote: > Change `MarkingNMethodClosure` to `NMethodToOopClosure` in young-gc, because no marking is done during young-gc. After that, `StrongRootsScope` becomes unnecessary as well, it's essentially calling `oops_do_marking_epilogue` to undo the effect of `MarkingNMethodClosure`. > > Test: tier1-5 Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27226#pullrequestreview-3228295747 From tschatzl at openjdk.org Tue Sep 16 08:33:28 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 16 Sep 2025 08:33:28 GMT Subject: RFR: 8367417: Serial: Use NMethodToOopClosure during Young GC In-Reply-To: <0cxHO0STcFcvdzE2UyoXFQB5Xz3IvGoHX2xb6fr3hW8=.de6c8353-4aea-42bc-bc56-1841a60f2e99@github.com> References: <0cxHO0STcFcvdzE2UyoXFQB5Xz3IvGoHX2xb6fr3hW8=.de6c8353-4aea-42bc-bc56-1841a60f2e99@github.com> Message-ID: On Thu, 11 Sep 2025 13:07:11 GMT, Albert Mingkun Yang wrote: > Change `MarkingNMethodClosure` to `NMethodToOopClosure` in young-gc, because no marking is done during young-gc. After that, `StrongRootsScope` becomes unnecessary as well, it's essentially calling `oops_do_marking_epilogue` to undo the effect of `MarkingNMethodClosure`. > > Test: tier1-5 Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27226#pullrequestreview-3228361569 From tschatzl at openjdk.org Tue Sep 16 08:49:30 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 16 Sep 2025 08:49:30 GMT Subject: RFR: 8367410: ZGC: Remove unused ZNmethodTable::wait_until_iteration_done() [v2] In-Reply-To: References: <684m0f5ZVkJPEEut-arf_t8mZ22o-5zv4Ub8gekJYbA=.b0b1ccb1-13d0-4c6f-9ae5-b28e97b25eb9@github.com> Message-ID: On Thu, 11 Sep 2025 17:19:00 GMT, Francesco Andreuzzi wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * also make ZNmethodTableIteration::in_progress() private > > Marked as reviewed by fandreuzzi (Author). Thanks @fandreuz @stefank for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/27223#issuecomment-3296671937 From tschatzl at openjdk.org Tue Sep 16 08:49:31 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 16 Sep 2025 08:49:31 GMT Subject: Integrated: 8367410: ZGC: Remove unused ZNmethodTable::wait_until_iteration_done() In-Reply-To: <684m0f5ZVkJPEEut-arf_t8mZ22o-5zv4Ub8gekJYbA=.b0b1ccb1-13d0-4c6f-9ae5-b28e97b25eb9@github.com> References: <684m0f5ZVkJPEEut-arf_t8mZ22o-5zv4Ub8gekJYbA=.b0b1ccb1-13d0-4c6f-9ae5-b28e97b25eb9@github.com> Message-ID: On Thu, 11 Sep 2025 12:12:25 GMT, Thomas Schatzl wrote: > Hi all, > > please review this trivial removal of `ZNmethodTable::wait_until_iteration_done()` as it is never used. > > Testing: local compilation > > Thanks, > Thomas This pull request has now been integrated. Changeset: ca89cd06 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/ca89cd06d39ed3a6bbe16f60fea4d7382849edbd Stats: 15 lines in 3 files changed: 2 ins; 12 del; 1 mod 8367410: ZGC: Remove unused ZNmethodTable::wait_until_iteration_done() Reviewed-by: stefank, fandreuzzi ------------- PR: https://git.openjdk.org/jdk/pull/27223 From azafari at openjdk.org Tue Sep 16 09:06:42 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 16 Sep 2025 09:06:42 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v5] In-Reply-To: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> Message-ID: > The minimum acceptable value was 0 where using it as address was problematic according to UBSAN. > The acceptable value is changed to 64K. > > Tests: > linux-x64 tier1 Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: uintptr_t -> uint64_t ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26955/files - new: https://git.openjdk.org/jdk/pull/26955/files/251dd986..fffb77a4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26955&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26955&range=03-04 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/26955.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26955/head:pull/26955 PR: https://git.openjdk.org/jdk/pull/26955 From iwalulya at openjdk.org Tue Sep 16 09:26:19 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 16 Sep 2025 09:26:19 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v4] In-Reply-To: References: Message-ID: > Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. > > Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. > > Testing: Tier 1-7 Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: Revert ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27190/files - new: https://git.openjdk.org/jdk/pull/27190/files/0e45912b..2ebff06c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27190&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27190&range=02-03 Stats: 5 lines in 2 files changed: 3 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27190.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27190/head:pull/27190 PR: https://git.openjdk.org/jdk/pull/27190 From iwalulya at openjdk.org Tue Sep 16 09:26:21 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 16 Sep 2025 09:26:21 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v4] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 02:58:12 GMT, David Holmes wrote: >> I moved the `Universe::before_exit()` call and also added a timed `wait`. >> @dholmes-ora do you have any concerns with this approach? > > Yes I do have concerns - sorry. Any change to the shutdown sequence needs very careful analysis. You have now changed the circumstances whereby the JVMTI events get posted. Maybe it won't matter, maybe it will - the issue is that it is very hard to determine the impact of such a change until you get notified that someone's code is now broken. I have undone that part of the change. We can revisit it separately, that way it is easier to backout if it is problematic ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2351648194 From ayang at openjdk.org Tue Sep 16 09:48:24 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 16 Sep 2025 09:48:24 GMT Subject: RFR: 8367737: Parallel: Retry allocation after lock acquire in mem_allocate_work Message-ID: Restoring the allocation retrying logic inside lock-region to avoid premature GCs. This logic was mistakenly removed in [JDK-8365557](https://bugs.openjdk.org/browse/JDK-8365557). Test: tier1-3 ------------- Commit messages: - pgc-retry-after-lock Changes: https://git.openjdk.org/jdk/pull/27308/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27308&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367737 Stats: 52 lines in 2 files changed: 29 ins; 20 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27308.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27308/head:pull/27308 PR: https://git.openjdk.org/jdk/pull/27308 From tschatzl at openjdk.org Tue Sep 16 10:13:39 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 16 Sep 2025 10:13:39 GMT Subject: RFR: 8367743: G1: Use named constants for G1CSetCandidateGroup group ids Message-ID: Hi all, please review this refactoring to use named constants for cset candidate group ids instead of raw integers. Testing: gha, local compilation, use in another patch for weeks Thanks, Thomas ------------- Commit messages: - 8367743 Changes: https://git.openjdk.org/jdk/pull/27309/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27309&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367743 Stats: 21 lines in 4 files changed: 9 ins; 2 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/27309.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27309/head:pull/27309 PR: https://git.openjdk.org/jdk/pull/27309 From tschatzl at openjdk.org Tue Sep 16 10:25:34 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 16 Sep 2025 10:25:34 GMT Subject: RFR: 8367731: G1: Make G1CollectionSet manage the young gen cset group Message-ID: Hi all, please review this change that lets the collection set manage the young cset candidate group directly. Currently everywhere the collection set (not "containing" the young cset candidate group) is used, we immediately do the same thing for the young gen candidate group in the same place. This makes it kind of natural to put together (and the `G1CollectionSet` already manages adding new regions to the young gen cset group anyway, so that split in responsibility is questionable anyway). Testing: gha Thanks, Thomas ------------- Commit messages: - * comment update - * let collectionset manage the young regions group card set Changes: https://git.openjdk.org/jdk/pull/27312/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27312&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367731 Stats: 67 lines in 9 files changed: 26 ins; 29 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/27312.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27312/head:pull/27312 PR: https://git.openjdk.org/jdk/pull/27312 From fandreuzzi at openjdk.org Tue Sep 16 10:56:10 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Tue, 16 Sep 2025 10:56:10 GMT Subject: RFR: 8367737: Parallel: Retry allocation after lock acquire in mem_allocate_work In-Reply-To: References: Message-ID: <2CHvdNJ6D9Hx-xr3qis7aRehVb0G0xyHUFGXN5bsY8M=.b7a93e2d-f83a-44b5-893d-93fa14a2b841@github.com> On Tue, 16 Sep 2025 09:40:10 GMT, Albert Mingkun Yang wrote: > Restoring the allocation retrying logic inside lock-region to avoid premature GCs. This logic was mistakenly removed in [JDK-8365557](https://bugs.openjdk.org/browse/JDK-8365557). > > Test: tier1-3 Marked as reviewed by fandreuzzi (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/27308#pullrequestreview-3229212410 From duke at openjdk.org Tue Sep 16 11:09:28 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Tue, 16 Sep 2025 11:09:28 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v4] In-Reply-To: References: Message-ID: <37fyY6jq5j6CdWbBJQK94mkR70ik6oINWLiAR6nPY90=.dd5f6d7c-8a02-46f1-99db-bfb3500772fb@github.com> On Tue, 16 Sep 2025 09:26:19 GMT, Ivan Walulya wrote: >> Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. >> >> Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. >> >> Testing: Tier 1-7 > > Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: > > Revert Changes requested by JonasNorlinder at github.com (no known OpenJDK username). src/hotspot/share/memory/universe.cpp line 1347: > 1345: > 1346: void Universe::before_exit() { > 1347: log_cpu_time(); Why did you move `log_cpu_time()`? During the review of CPUTimeUsage refactor (https://github.com/openjdk/jdk/pull/26621) we discussed this choice. Given that it still includes more than just GC I think it should stay in `Universe`. Also the PR title does not reflect that it would include a refactor of CPUTimeUsage. ------------- PR Review: https://git.openjdk.org/jdk/pull/27190#pullrequestreview-3229290160 PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2352019449 From duke at openjdk.org Tue Sep 16 11:19:15 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Tue, 16 Sep 2025 11:19:15 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v4] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 09:26:19 GMT, Ivan Walulya wrote: >> Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. >> >> Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. >> >> Testing: Tier 1-7 > > Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: > > Revert I think we want either `log_cpu_time` or `gc_threads_do` (which we might want to avoid for performance reasons?) to check `is_shutting_down()` such that we can't query terminated GC workers. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27190#issuecomment-3297922874 From ayang at openjdk.org Tue Sep 16 12:11:22 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 16 Sep 2025 12:11:22 GMT Subject: RFR: 8367743: G1: Use named constants for G1CSetCandidateGroup group ids In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 10:04:52 GMT, Thomas Schatzl wrote: > Hi all, > > please review this refactoring to use named constants for cset candidate group ids instead of raw integers. > > Testing: gha, local compilation, use in another patch for weeks > > Thanks, > Thomas src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 3055: > 3053: size_t code_roots_bytes = r->rem_set()->code_roots_mem_size(); > 3054: const char* remset_type = r->rem_set()->get_short_state_str(); > 3055: uint cset_group_id = G1CSetCandidateGroup::NoRemSetId; I suggest rewriting the following lines to sth like: uint id; if (has_remset) { id = } else { id = no_remset_id; } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27309#discussion_r2352260477 From iwalulya at openjdk.org Tue Sep 16 12:17:05 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 16 Sep 2025 12:17:05 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v4] In-Reply-To: <37fyY6jq5j6CdWbBJQK94mkR70ik6oINWLiAR6nPY90=.dd5f6d7c-8a02-46f1-99db-bfb3500772fb@github.com> References: <37fyY6jq5j6CdWbBJQK94mkR70ik6oINWLiAR6nPY90=.dd5f6d7c-8a02-46f1-99db-bfb3500772fb@github.com> Message-ID: On Tue, 16 Sep 2025 11:06:58 GMT, Jonas Norlinder wrote: >> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert > > src/hotspot/share/memory/universe.cpp line 1347: > >> 1345: >> 1346: void Universe::before_exit() { >> 1347: log_cpu_time(); > > Why did you move `log_cpu_time()`? During the review of CPUTimeUsage refactor (https://github.com/openjdk/jdk/pull/26621) we discussed this choice. Given that it still includes more than just GC I think it should stay in `Universe`. Also the PR title does not reflect that it would include a refactor of CPUTimeUsage. Main reason was to have the `log_cpu_time` and `AtomicAccess::release_store(&_is_shutting_down, true)` under same critical section. Otherwise, we have no guarantee that we don't continue GCs after `log_cpu_time`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2352287921 From iwalulya at openjdk.org Tue Sep 16 12:35:38 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 16 Sep 2025 12:35:38 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v5] In-Reply-To: References: Message-ID: > Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. > > Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. > > Testing: Tier 1-7 Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs - Revert - Thomas Review - return on timeout - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs - timed wait - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs - space - remove debug logs - remove debug logs - ... and 2 more: https://git.openjdk.org/jdk/compare/35dc4349...edad0efe ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27190/files - new: https://git.openjdk.org/jdk/pull/27190/files/2ebff06c..edad0efe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27190&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27190&range=03-04 Stats: 4639 lines in 131 files changed: 3502 ins; 611 del; 526 mod Patch: https://git.openjdk.org/jdk/pull/27190.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27190/head:pull/27190 PR: https://git.openjdk.org/jdk/pull/27190 From iwalulya at openjdk.org Tue Sep 16 13:09:07 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 16 Sep 2025 13:09:07 GMT Subject: RFR: 8367743: G1: Use named constants for G1CSetCandidateGroup group ids In-Reply-To: References: Message-ID: <0urk-3QKoKrtiBme342bSdxQPFoImai9HzWofoT7rKs=.076d75ff-eb67-41a2-8048-16332cbc01bd@github.com> On Tue, 16 Sep 2025 10:04:52 GMT, Thomas Schatzl wrote: > Hi all, > > please review this refactoring to use named constants for cset candidate group ids instead of raw integers. > > Testing: gha, local compilation, use in another patch for weeks > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27309#pullrequestreview-3229912437 From iwalulya at openjdk.org Tue Sep 16 13:09:10 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 16 Sep 2025 13:09:10 GMT Subject: RFR: 8367743: G1: Use named constants for G1CSetCandidateGroup group ids In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 12:08:11 GMT, Albert Mingkun Yang wrote: >> Hi all, >> >> please review this refactoring to use named constants for cset candidate group ids instead of raw integers. >> >> Testing: gha, local compilation, use in another patch for weeks >> >> Thanks, >> Thomas > > src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 3055: > >> 3053: size_t code_roots_bytes = r->rem_set()->code_roots_mem_size(); >> 3054: const char* remset_type = r->rem_set()->get_short_state_str(); >> 3055: uint cset_group_id = G1CSetCandidateGroup::NoRemSetId; > > I suggest rewriting the following lines to sth like: > > > uint id; > if (has_remset) { > id = > } else { > id = no_remset_id; > } I prefer initializing the variable instead of a redundant `else`, but ymmv. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27309#discussion_r2352444835 From duke at openjdk.org Tue Sep 16 14:06:44 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Tue, 16 Sep 2025 14:06:44 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v5] In-Reply-To: References: <37fyY6jq5j6CdWbBJQK94mkR70ik6oINWLiAR6nPY90=.dd5f6d7c-8a02-46f1-99db-bfb3500772fb@github.com> Message-ID: On Tue, 16 Sep 2025 12:14:28 GMT, Ivan Walulya wrote: >> src/hotspot/share/memory/universe.cpp line 1347: >> >>> 1345: >>> 1346: void Universe::before_exit() { >>> 1347: log_cpu_time(); >> >> Why did you move `log_cpu_time()`? During the review of CPUTimeUsage refactor (https://github.com/openjdk/jdk/pull/26621) we discussed this choice. Given that it still includes more than just GC I think it should stay in `Universe`. Also the PR title does not reflect that it would include a refactor of CPUTimeUsage. > > Main reason was to have the `log_cpu_time` and `AtomicAccess::release_store(&_is_shutting_down, true)` under same critical section. Otherwise, we have no guarantee that we don't continue GCs after `log_cpu_time`. I had put `log_cpu_time` right before calling `stop()`. The `stop()` is the method that terminates GC threads, so no synchronization should be needed if I'm not mistaken. Please correct me if you think I got it wrong here. Nevertheless, any user of `gc_threads_do` might still iterate over terminated GC workers thread. Could we consider adding a check or assert in that method? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2352630393 From tschatzl at openjdk.org Tue Sep 16 14:26:45 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 16 Sep 2025 14:26:45 GMT Subject: RFR: 8367737: Parallel: Retry allocation after lock acquire in mem_allocate_work In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 09:40:10 GMT, Albert Mingkun Yang wrote: > Restoring the allocation retrying logic inside lock-region to avoid premature GCs. This logic was mistakenly removed in [JDK-8365557](https://bugs.openjdk.org/browse/JDK-8365557). > > Test: tier1-3 Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27308#pullrequestreview-3230266852 From tschatzl at openjdk.org Tue Sep 16 14:27:02 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 16 Sep 2025 14:27:02 GMT Subject: RFR: 8367743: G1: Use named constants for G1CSetCandidateGroup group ids [v2] In-Reply-To: References: Message-ID: <9uV7I8V8S82iAwJl9GE4fqlZdsYxkYEE_-RPtzUmM8Y=.d905d517-0aae-4318-abf1-18193b0fd7ed@github.com> > Hi all, > > please review this refactoring to use named constants for cset candidate group ids instead of raw integers. > > Testing: gha, local compilation, use in another patch for weeks > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * fix id assigment in printregionlivenessclosure ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27309/files - new: https://git.openjdk.org/jdk/pull/27309/files/a242e6ca..f74dbcf4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27309&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27309&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27309.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27309/head:pull/27309 PR: https://git.openjdk.org/jdk/pull/27309 From iwalulya at openjdk.org Tue Sep 16 14:46:43 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 16 Sep 2025 14:46:43 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v5] In-Reply-To: References: <37fyY6jq5j6CdWbBJQK94mkR70ik6oINWLiAR6nPY90=.dd5f6d7c-8a02-46f1-99db-bfb3500772fb@github.com> Message-ID: On Tue, 16 Sep 2025 14:03:28 GMT, Jonas Norlinder wrote: >> Main reason was to have the `log_cpu_time` and `AtomicAccess::release_store(&_is_shutting_down, true)` under same critical section. Otherwise, we have no guarantee that we don't continue GCs after `log_cpu_time`. > > I had put `log_cpu_time` right before calling `stop()`. The `stop()` is the method that terminates GC threads, so no synchronization should be needed if I'm not mistaken. > > Please correct me if you think I got it wrong here. > > Nevertheless, any user of `gc_threads_do` might still iterate over terminated GC workers thread. Could we consider adding a check or assert in that method? We can have GCs between `log_cpu_time` and `stop()`. This reduces chances of that happening if we have `log_cpu_time` under same lock as setting `_is_shutting_down`. > Nevertheless, any user of gc_threads_do might still iterate over terminated GC workers thread. Could we consider adding a check or assert in that method? Yes, we can have the assert in `gc_threads_do`, I thought this was going to be done as a follow up. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2352757631 From phh at openjdk.org Tue Sep 16 15:53:37 2025 From: phh at openjdk.org (Paul Hohensee) Date: Tue, 16 Sep 2025 15:53:37 GMT Subject: RFR: 8367450: Shenandoah: Log the composition of the collection set [v2] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 00:30:37 GMT, William Kemper wrote: >> Reuse the same log message from GenShen which details the composition of the live data to be evacuated. In the non-generational modes, all regions are considered young and nothing will be promoted (or old). > > William Kemper has updated the pull request incrementally with one additional commit since the last revision: > > Simplify JFR evac info reporting Use a copy constructor in shenandoahTrace.cpp, ShenandoahTracer::report_evacuation_info? If you just copy fields, you might miss a few if the definition of ShenandoahEvacuationInformation changes. ------------- PR Review: https://git.openjdk.org/jdk/pull/27235#pullrequestreview-3230650440 From phh at openjdk.org Tue Sep 16 16:16:58 2025 From: phh at openjdk.org (Paul Hohensee) Date: Tue, 16 Sep 2025 16:16:58 GMT Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a runtime diagnostic option In-Reply-To: References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com> Message-ID: <8igXcI511iS8lbECWTA213zFWiLfBwW9I6x12ng2wrA=.c89b70e0-35b3-46b8-a091-013a5d0ffb90@github.com> On Mon, 15 Sep 2025 23:06:36 GMT, Paul Hohensee wrote: >> If we decide we want "better performance", it seems we could have two versions of the GC worker thread evacuation closures. One calls the templated version try_evacuate_object() that has this instrumentation in it. The other calls the templated version of try_evacuate_object() that does not have this instrumentation in it. For LRB, I assume we could have an if-then-else to decide which version to call. LRB evacuations are quite rare, I believe, so that doesn't bother me so much. > > On typical hardware, if the test is in the fast path, the load of ShenandoahEvacTracking will hit in L1, the latency will be absorbed by speculation, and the cmp/branch is a single clock. So maybe 2 clocks at most. Downside is that if ShenandoahEvacTracking is the only thing being accessed in its cache line, you waste an L1 line. If there are two evac closure versions, then the choice must be made at a higher level than at the closure invocation point, otherwise it's the same cost. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27238#discussion_r2353011393 From ayang at openjdk.org Tue Sep 16 17:55:10 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 16 Sep 2025 17:55:10 GMT Subject: RFR: 8367743: G1: Use named constants for G1CSetCandidateGroup group ids [v2] In-Reply-To: <9uV7I8V8S82iAwJl9GE4fqlZdsYxkYEE_-RPtzUmM8Y=.d905d517-0aae-4318-abf1-18193b0fd7ed@github.com> References: <9uV7I8V8S82iAwJl9GE4fqlZdsYxkYEE_-RPtzUmM8Y=.d905d517-0aae-4318-abf1-18193b0fd7ed@github.com> Message-ID: On Tue, 16 Sep 2025 14:27:02 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this refactoring to use named constants for cset candidate group ids instead of raw integers. >> >> Testing: gha, local compilation, use in another patch for weeks >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * fix id assigment in printregionlivenessclosure Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27309#pullrequestreview-3231091514 From kdnilsen at openjdk.org Tue Sep 16 17:56:09 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 16 Sep 2025 17:56:09 GMT Subject: RFR: 8367708: GenShen: Reduce total evacuation burden [v2] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 21:29:17 GMT, Kelvin Nilsen wrote: >> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1443: >> >>> 1441: >>> 1442: oop humongous_obj = cast_to_oop(start->bottom()); >>> 1443: size_t size = humongous_obj->size(); >> >> Is this intentional? This looks like it would reintroduce https://github.com/openjdk/jdk/pull/26256 (crash trying to access size of humongous object after its class has been unloaded). > > good catch. I'll change how this is implemented. I've fixed this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27278#discussion_r2353245688 From wkemper at openjdk.org Tue Sep 16 17:58:35 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 16 Sep 2025 17:58:35 GMT Subject: RFR: 8367450: Shenandoah: Log the composition of the collection set [v3] In-Reply-To: References: Message-ID: <6qlIiMobj48-AoxpC5sHdilE3QCo1KGJsF20-6Jgm7I=.2a977253-2393-452d-bd19-5c6eeacd1fa8@github.com> > Reuse the same log message from GenShen which details the composition of the live data to be evacuated. In the non-generational modes, all regions are considered young and nothing will be promoted (or old). William Kemper has updated the pull request incrementally with one additional commit since the last revision: Restore accidentally deleted constructor ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27235/files - new: https://git.openjdk.org/jdk/pull/27235/files/14d36331..7bde84b8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27235&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27235&range=01-02 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27235.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27235/head:pull/27235 PR: https://git.openjdk.org/jdk/pull/27235 From kdnilsen at openjdk.org Tue Sep 16 17:59:04 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 16 Sep 2025 17:59:04 GMT Subject: RFR: 8367708: GenShen: Reduce total evacuation burden [v2] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 23:58:27 GMT, William Kemper wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> Respond to reviewer feedback > > src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1442: > >> 1440: assert(start->is_humongous_start(), "reclaim regions starting with the first one"); >> 1441: >> 1442: // Cannot access humongous_obj->size() in case class has been unloaded > > Why do we want to make two passes over the humongous object? I don't see why the original code needs to change or how this change is related to this PR? There's a comment in the "new code" that we have to reclaim from the tail. Otherwise assertion fails when printing region to trace log. I agree it is unclear how this relates to current PR. I'll revert and see if something breaks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27278#discussion_r2353251364 From wkemper at openjdk.org Tue Sep 16 18:16:27 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 16 Sep 2025 18:16:27 GMT Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a runtime diagnostic option [v2] In-Reply-To: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com> References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com> Message-ID: > Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option. William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge remote-tracking branch 'jdk/master' into make-evac-tracking-runtime-option - Only print evacuation info when evac tracking is enabled (generational mode fix) - Make detailed evacuation tracking a diagnostic option in product builds ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27238/files - new: https://git.openjdk.org/jdk/pull/27238/files/013480d2..bbee4ee3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27238&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27238&range=00-01 Stats: 12926 lines in 600 files changed: 6899 ins; 2751 del; 3276 mod Patch: https://git.openjdk.org/jdk/pull/27238.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27238/head:pull/27238 PR: https://git.openjdk.org/jdk/pull/27238 From wkemper at openjdk.org Tue Sep 16 19:03:02 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 16 Sep 2025 19:03:02 GMT Subject: RFR: 8367476: Shenandoah: Remove use of CollectedHeap::_soft_ref_policy [v2] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 14:23:35 GMT, Francesco Andreuzzi wrote: >> Similarly to what was done in #26496 and #26648, the usages of `CollectedHeap::_soft_ref_policy` in Shenandoah can be replaced with an earlier call to `ShenandoahReferenceProcessor::set_soft_reference_policy`. >> >> This is the last usage of `CollectedHeap::_soft_ref_policy`, so it can be removed. >> >> Passes tier1-2, and tier3_gc_shenandoah. > > Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: > > - eagerly initialize to always-clear > - move to gccause Shenandoah parts look good to me. ------------- Marked as reviewed by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27239#pullrequestreview-3231296755 From duke at openjdk.org Tue Sep 16 19:17:59 2025 From: duke at openjdk.org (duke) Date: Tue, 16 Sep 2025 19:17:59 GMT Subject: RFR: 8367476: Shenandoah: Remove use of CollectedHeap::_soft_ref_policy [v2] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 14:23:35 GMT, Francesco Andreuzzi wrote: >> Similarly to what was done in #26496 and #26648, the usages of `CollectedHeap::_soft_ref_policy` in Shenandoah can be replaced with an earlier call to `ShenandoahReferenceProcessor::set_soft_reference_policy`. >> >> This is the last usage of `CollectedHeap::_soft_ref_policy`, so it can be removed. >> >> Passes tier1-2, and tier3_gc_shenandoah. > > Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: > > - eagerly initialize to always-clear > - move to gccause @fandreuz Your change (at version a55b8bd21ffa892b7f045bfe0961773855790661) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27239#issuecomment-3300024331 From fandreuzzi at openjdk.org Tue Sep 16 19:17:58 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Tue, 16 Sep 2025 19:17:58 GMT Subject: RFR: 8367476: Shenandoah: Remove use of CollectedHeap::_soft_ref_policy [v2] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 15:18:20 GMT, Albert Mingkun Yang wrote: >> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: >> >> - eagerly initialize to always-clear >> - move to gccause > > I have reviewed all non-Shenandoah code. Thanks for your review @albertnetymk and @earthling-amzn. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27239#issuecomment-3300021618 From wkemper at openjdk.org Tue Sep 16 19:21:51 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 16 Sep 2025 19:21:51 GMT Subject: RFR: 8367708: GenShen: Reduce total evacuation burden [v2] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 17:56:23 GMT, Kelvin Nilsen wrote: >> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1442: >> >>> 1440: assert(start->is_humongous_start(), "reclaim regions starting with the first one"); >>> 1441: >>> 1442: // Cannot access humongous_obj->size() in case class has been unloaded >> >> Why do we want to make two passes over the humongous object? I don't see why the original code needs to change or how this change is related to this PR? > > There's a comment in the "new code" that we have to reclaim from the tail. Otherwise assertion fails when printing region to trace log. > > I agree it is unclear how this relates to current PR. I'll revert and see if something breaks. Thanks. We talked about this comment in the original PR: https://github.com/openjdk/jdk/pull/26256. It's a stale comment. I ran a pipeline with `gc*=trace` (and also inspected all usages). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27278#discussion_r2353429010 From kdnilsen at openjdk.org Tue Sep 16 19:41:47 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 16 Sep 2025 19:41:47 GMT Subject: RFR: 8367708: GenShen: Reduce total evacuation burden [v3] In-Reply-To: References: Message-ID: > This PR provides several improvements that cumulatively reduce the amount of evacuation performed by GenShen compared to traditional Shenandoah. Specifically: > > 1. Do not promote humongous arrays of primitive data. Leaving these regions in the young generation allows them to be reclaimed more quickly when they become garbage. There is no disadvantage to leaving these regions in the young generation as their contents does not need to be scanned by the garbage collector. > 2. Change the default value of ShenandoahOldGarbageThreshold from 15% to 25%. This results in smaller sets of candidate regions for mixed evacuation, less aggressive compaction of old generation. This also increases the likelihood that a region will be promoted in place instead of promoted by evacuation. > 3. Only promote regions in place if the used within a region exceeds ShenandoahGenerationalMinPIPUsage (default 30) percent of the heap region size. This is enforced in combination with the preexisting requirement that the garbage within the region be less than ShenandoahOldGarbageThreshold (new default 25) percent of the heap region size. This causes regions with very low utilization to be promoted by evacuation rather than promoted in place. While the immediate effect of this change is to perform more copying when the region is promoted, the secondary effect is that this region does not need to be evacuated at a later time, after it has accumulated more live data, as part of an effort to defragment old-gen memory. > 4. Only defragment old-gen memory if the command-line has requested non-zero reserves for humongous objects (ShenandoahGenerationalHumongousReserves). Previously, we would invest in defragmenting old-gen memory every time we finished old-generation marking, even if ShenandoahGenerationalHumongousReserves equals zero. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: revert changes to trash_humongous_region_at() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27278/files - new: https://git.openjdk.org/jdk/pull/27278/files/69a76009..1ff51494 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27278&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27278&range=01-02 Stats: 26 lines in 1 file changed: 5 ins; 14 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27278.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27278/head:pull/27278 PR: https://git.openjdk.org/jdk/pull/27278 From kdnilsen at openjdk.org Tue Sep 16 19:43:49 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 16 Sep 2025 19:43:49 GMT Subject: RFR: 8367708: GenShen: Reduce total evacuation burden [v2] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 19:19:19 GMT, William Kemper wrote: >> There's a comment in the "new code" that we have to reclaim from the tail. Otherwise assertion fails when printing region to trace log. >> >> I agree it is unclear how this relates to current PR. I'll revert and see if something breaks. > > Thanks. We talked about this comment in the original PR: https://github.com/openjdk/jdk/pull/26256. It's a stale comment. I ran a pipeline with `gc*=trace` (and also inspected all usages). Running this change through test pipelines. Perhaps the original problem that I had encountered was fixed in a different way upstream, and my change was no longer necessary or relevant after merging from upstream. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27278#discussion_r2353485278 From kdnilsen at openjdk.org Tue Sep 16 20:10:42 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 16 Sep 2025 20:10:42 GMT Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need accurate live_data [v8] In-Reply-To: References: Message-ID: > The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected. In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region. This is typically ok for young regions, where the amount of live data determines whether a region should be added to the collection set during the final-mark safepoint. > > However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated. In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended. > > This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions. Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits: - Merge remote-tracking branch 'jdk/master' into fix-live-data-for-mixed-evac-candidates - Fix uninitialized variable - Remove deprecation conditional compiles - Adjust candidate live memory for each mixed evac - Refactor for better abstraction - Fix set_live() after full gc - Fix garbage_before_padded_for_promote() - Experiment 2: refinements to reduce regressions - Experiment with reviewer suggestion Redefine the way ShenandoahHeapRegion::get_live_data_ works to simplify changes. - Track live and garbage for mixed-evac regions - ... and 31 more: https://git.openjdk.org/jdk/compare/b75e35cb...d486a218 ------------- Changes: https://git.openjdk.org/jdk/pull/24319/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24319&range=07 Stats: 111 lines in 11 files changed: 76 ins; 24 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/24319.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24319/head:pull/24319 PR: https://git.openjdk.org/jdk/pull/24319 From wkemper at openjdk.org Tue Sep 16 20:56:09 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 16 Sep 2025 20:56:09 GMT Subject: RFR: 8367450: Shenandoah: Log the composition of the collection set [v4] In-Reply-To: References: Message-ID: > Reuse the same log message from GenShen which details the composition of the live data to be evacuated. In the non-generational modes, all regions are considered young and nothing will be promoted (or old). William Kemper has updated the pull request incrementally with one additional commit since the last revision: Fix zero build ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27235/files - new: https://git.openjdk.org/jdk/pull/27235/files/7bde84b8..3b6f970e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27235&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27235&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27235.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27235/head:pull/27235 PR: https://git.openjdk.org/jdk/pull/27235 From kdnilsen at openjdk.org Tue Sep 16 21:29:34 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 16 Sep 2025 21:29:34 GMT Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need accurate live_data [v9] In-Reply-To: References: Message-ID: <8GvpkoZ5-Pso8XG-AKeR0QnlBQr0op9E-lvQMS12lTI=.6c88343d-4c74-4f29-a528-f499f559a2bd@github.com> > The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected. In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region. This is typically ok for young regions, where the amount of live data determines whether a region should be added to the collection set during the final-mark safepoint. > > However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated. In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended. > > This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Fix compilation errors after merge ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24319/files - new: https://git.openjdk.org/jdk/pull/24319/files/d486a218..cc6f1153 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24319&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24319&range=07-08 Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/24319.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24319/head:pull/24319 PR: https://git.openjdk.org/jdk/pull/24319 From wkemper at openjdk.org Wed Sep 17 00:20:58 2025 From: wkemper at openjdk.org (William Kemper) Date: Wed, 17 Sep 2025 00:20:58 GMT Subject: RFR: 8367450: Shenandoah: Log the composition of the collection set [v5] In-Reply-To: References: Message-ID: <2KA4IRFQOPFBpt9D570g9HORzBXycZhs7cDPLYjnGmE=.6f331678-cb61-4e05-8c7d-06fcea7fa64e@github.com> > Reuse the same log message from GenShen which details the composition of the live data to be evacuated. In the non-generational modes, all regions are considered young and nothing will be promoted (or old). William Kemper has updated the pull request incrementally with one additional commit since the last revision: Remove redundant collection set logging ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27235/files - new: https://git.openjdk.org/jdk/pull/27235/files/3b6f970e..aeb6b39e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27235&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27235&range=03-04 Stats: 19 lines in 4 files changed: 1 ins; 18 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27235.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27235/head:pull/27235 PR: https://git.openjdk.org/jdk/pull/27235 From shade at openjdk.org Wed Sep 17 05:33:34 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 17 Sep 2025 05:33:34 GMT Subject: RFR: 8348278: Trim InitialRAMPercentage to improve startup in default modes [v4] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 12:40:39 GMT, Stefan Johansson wrote: >> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: >> >> - Also man page >> - Fix > > I started some runs in our internal perf-testing environment to see what kind of results we would get with a change like this. > > I think the reasoning sounds good for large machines, and for smaller containers some quick testing indicates that we never go below 8M for `Min/InitialHeapSize` which I also think is good. 2M sounds very small :) Thanks @kstefanj! How is it going with testing? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23262#issuecomment-3301364521 From aboldtch at openjdk.org Wed Sep 17 08:04:45 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 17 Sep 2025 08:04:45 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v5] In-Reply-To: References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> Message-ID: On Tue, 16 Sep 2025 09:06:42 GMT, Afshin Zafari wrote: >> The minimum acceptable value was 0 where using it as address was problematic according to UBSAN. >> The acceptable value is changed to 64K. >> >> Tests: >> linux-x64 tier1 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > uintptr_t -> uint64_t What is the reasoning behind using `uint64_t` rather than `uintptr_t`? I prefer the use of `uintptr_t` for values which describe addresses. While `uint64_t` will always have the same size as `uintptr_t` here (because this is 64-bit only coops code), it does not convey the same meaning to me. If anything the pre-existing type of `unscaled_end` may be wrong. Because end makes sound like an address in this context, but it is describing an offset. And is only used to check for an underflow before we may reinterpret it as an address (0 + offset). That part I think would read much better by checking for the underflow first: ```C++ uintptr_t lowest_start = aligned_heap_base_min_address; if (size <= UnscaledOopHeapMax) { lowest_start = MAX2(lowest_start, UnscaledOopHeapMax - size); } lowest_start = align_up(lowest_start, attach_point_alignment); I think the use of `uint64_t` stems from the `UnscaledOopHeapMax` and `OopEncodingHeapMax` being typed as such. Unclear to me why they are not just `size_t`, as coops is a 64-bit VM feature. ------------- PR Review: https://git.openjdk.org/jdk/pull/26955#pullrequestreview-3233193487 From ayang at openjdk.org Wed Sep 17 08:23:59 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 17 Sep 2025 08:23:59 GMT Subject: Integrated: 8367417: Serial: Use NMethodToOopClosure during Young GC In-Reply-To: <0cxHO0STcFcvdzE2UyoXFQB5Xz3IvGoHX2xb6fr3hW8=.de6c8353-4aea-42bc-bc56-1841a60f2e99@github.com> References: <0cxHO0STcFcvdzE2UyoXFQB5Xz3IvGoHX2xb6fr3hW8=.de6c8353-4aea-42bc-bc56-1841a60f2e99@github.com> Message-ID: On Thu, 11 Sep 2025 13:07:11 GMT, Albert Mingkun Yang wrote: > Change `MarkingNMethodClosure` to `NMethodToOopClosure` in young-gc, because no marking is done during young-gc. After that, `StrongRootsScope` becomes unnecessary as well, it's essentially calling `oops_do_marking_epilogue` to undo the effect of `MarkingNMethodClosure`. > > Test: tier1-5 This pull request has now been integrated. Changeset: d0ea6686 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/d0ea6686ebe2baff28f5368f5bbf9dc7f34dd6d8 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod 8367417: Serial: Use NMethodToOopClosure during Young GC Reviewed-by: fandreuzzi, stefank, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/27226 From ayang at openjdk.org Wed Sep 17 08:23:58 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 17 Sep 2025 08:23:58 GMT Subject: RFR: 8367417: Serial: Use NMethodToOopClosure during Young GC In-Reply-To: <0cxHO0STcFcvdzE2UyoXFQB5Xz3IvGoHX2xb6fr3hW8=.de6c8353-4aea-42bc-bc56-1841a60f2e99@github.com> References: <0cxHO0STcFcvdzE2UyoXFQB5Xz3IvGoHX2xb6fr3hW8=.de6c8353-4aea-42bc-bc56-1841a60f2e99@github.com> Message-ID: On Thu, 11 Sep 2025 13:07:11 GMT, Albert Mingkun Yang wrote: > Change `MarkingNMethodClosure` to `NMethodToOopClosure` in young-gc, because no marking is done during young-gc. After that, `StrongRootsScope` becomes unnecessary as well, it's essentially calling `oops_do_marking_epilogue` to undo the effect of `MarkingNMethodClosure`. > > Test: tier1-5 Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27226#issuecomment-3301863401 From fandreuzzi at openjdk.org Wed Sep 17 08:30:12 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 17 Sep 2025 08:30:12 GMT Subject: Integrated: 8367476: Shenandoah: Remove use of CollectedHeap::_soft_ref_policy In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 00:19:05 GMT, Francesco Andreuzzi wrote: > Similarly to what was done in #26496 and #26648, the usages of `CollectedHeap::_soft_ref_policy` in Shenandoah can be replaced with an earlier call to `ShenandoahReferenceProcessor::set_soft_reference_policy`. > > This is the last usage of `CollectedHeap::_soft_ref_policy`, so it can be removed. > > Passes tier1-2, and tier3_gc_shenandoah. This pull request has now been integrated. Changeset: 976207df Author: Francesco Andreuzzi Committer: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/976207df1fcebf76a5f732b26424d6a4896b359e Stats: 101 lines in 20 files changed: 16 ins; 75 del; 10 mod 8367476: Shenandoah: Remove use of CollectedHeap::_soft_ref_policy Reviewed-by: ayang, wkemper ------------- PR: https://git.openjdk.org/jdk/pull/27239 From iwalulya at openjdk.org Wed Sep 17 08:52:25 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 17 Sep 2025 08:52:25 GMT Subject: RFR: 8367737: Parallel: Retry allocation after lock acquire in mem_allocate_work In-Reply-To: References: Message-ID: <2E_HLI-G7asn_Cc7DEwCbTVpiRI0Y9AeUD7P0fJSpD0=.a0b9ea5a-f885-4900-a048-4d337c5a835e@github.com> On Tue, 16 Sep 2025 09:40:10 GMT, Albert Mingkun Yang wrote: > Restoring the allocation retrying logic inside lock-region to avoid premature GCs. This logic was mistakenly removed in [JDK-8365557](https://bugs.openjdk.org/browse/JDK-8365557). > > Test: tier1-3 Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27308#pullrequestreview-3233374430 From ayang at openjdk.org Wed Sep 17 09:07:00 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 17 Sep 2025 09:07:00 GMT Subject: RFR: 8367848: Parallel: Use NMethodToOopClosure during Young GC Message-ID: <1junjLjTWzIsXHpwN7aXUvGSrRafJPP-LBUA3ZsQnDM=.21c925ae-d5b6-486b-be19-33fbe865b994@github.com> Replace `MarkingNMethodClosure` with `NMethodToOopClosure` during young-gc. After that, a new local `ThreadsClaimTokenScope` is introduced instead of `StrongRootsScope` to make the thread-claim-token logic visible in the current context. Test: tier1-3 ------------- Commit messages: - pgc-nmethod Changes: https://git.openjdk.org/jdk/pull/27336/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27336&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367848 Stats: 11 lines in 1 file changed: 8 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27336.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27336/head:pull/27336 PR: https://git.openjdk.org/jdk/pull/27336 From tschatzl at openjdk.org Wed Sep 17 09:45:07 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 17 Sep 2025 09:45:07 GMT Subject: RFR: 8367743: G1: Use named constants for G1CSetCandidateGroup group ids [v2] In-Reply-To: <0urk-3QKoKrtiBme342bSdxQPFoImai9HzWofoT7rKs=.076d75ff-eb67-41a2-8048-16332cbc01bd@github.com> References: <0urk-3QKoKrtiBme342bSdxQPFoImai9HzWofoT7rKs=.076d75ff-eb67-41a2-8048-16332cbc01bd@github.com> Message-ID: <5O47x0C1mm0lB0VtXUh0VbpVfiIWoekiIU8KlzZIGls=.3cfce55b-d103-492f-ab27-dbdfa98e3ad3@github.com> On Tue, 16 Sep 2025 13:06:38 GMT, Ivan Walulya wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * fix id assigment in printregionlivenessclosure > > Marked as reviewed by iwalulya (Reviewer). Thanks @walulyai @albertnetymk for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/27309#issuecomment-3302168434 From tschatzl at openjdk.org Wed Sep 17 09:45:08 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 17 Sep 2025 09:45:08 GMT Subject: Integrated: 8367743: G1: Use named constants for G1CSetCandidateGroup group ids In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 10:04:52 GMT, Thomas Schatzl wrote: > Hi all, > > please review this refactoring to use named constants for cset candidate group ids instead of raw integers. > > Testing: gha, local compilation, use in another patch for weeks > > Thanks, > Thomas This pull request has now been integrated. Changeset: 005f3a39 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/005f3a392f20ea2fbe2d7d699448e65d3443a073 Stats: 25 lines in 4 files changed: 9 ins; 4 del; 12 mod 8367743: G1: Use named constants for G1CSetCandidateGroup group ids Reviewed-by: ayang, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/27309 From tschatzl at openjdk.org Wed Sep 17 09:51:44 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 17 Sep 2025 09:51:44 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v5] In-Reply-To: References: Message-ID: <3XLIQ_iY9IEEZ07Fu4ASgqwhfWW8wa_LdJ_O9fT6ipo=.d3f31990-a5ff-4083-912d-0207cb95253a@github.com> On Tue, 16 Sep 2025 12:35:38 GMT, Ivan Walulya wrote: >> Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. >> >> Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. >> >> Testing: Tier 1-7 > > Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - Revert > - Thomas Review > - return on timeout > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - timed wait > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - space > - remove debug logs > - remove debug logs > - ... and 2 more: https://git.openjdk.org/jdk/compare/67035a45...edad0efe Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27190#pullrequestreview-3233596607 From tschatzl at openjdk.org Wed Sep 17 09:57:34 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 17 Sep 2025 09:57:34 GMT Subject: RFR: 8367759: G1: Move G1UpdateRegionLivenessAndSelectForRebuildTask into its own file Message-ID: Hi all, please review this change to move `G1UpdateRegionLivenessAndSelectForRebuildTask` into a separate file. I would like to merge this class and G1BuildCandidateRegionsTask in the near future because the latter mostly repeats the work of the former anyway, but together (with helper classes) they are quite large (if not large already by themselves). This should help make `g1ConcurrentMark.cpp` a little more manageable. There is no change in the code, just moving and fixing includes/adding forwards. Testing: local compilation, gha Thanks, Thomas ------------- Commit messages: - Update src/hotspot/share/gc/g1/g1ConcurrentMark.hpp - * fix compilation - Merge branch 'master' into 8367759-move-remark-task - * remove some later change - 8367759 Changes: https://git.openjdk.org/jdk/pull/27314/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27314&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367759 Stats: 427 lines in 3 files changed: 254 ins; 173 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27314.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27314/head:pull/27314 PR: https://git.openjdk.org/jdk/pull/27314 From tschatzl at openjdk.org Wed Sep 17 09:57:37 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 17 Sep 2025 09:57:37 GMT Subject: RFR: 8367759: G1: Move G1UpdateRegionLivenessAndSelectForRebuildTask into its own file In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 14:19:41 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to move `G1UpdateRegionLivenessAndSelectForRebuildTask` into a separate file. I would like to merge this class and G1BuildCandidateRegionsTask in the near future because the latter mostly repeats the work of the former anyway, but together (with helper classes) they are quite large (if not large already by themselves). This should help make `g1ConcurrentMark.cpp` a little more manageable. > > There is no change in the code, just moving and fixing includes/adding forwards. > > Testing: local compilation, gha > > Thanks, > Thomas src/hotspot/share/gc/g1/g1ConcurrentMark.hpp line 96: > 94: // Closure used by CM during concurrent reference discovery > 95: // and reference processing (during remarking) to determine > 96: // if a particular object is alive. It is primarilfy used Suggestion: // if a particular object is alive. It is primarily used ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27314#discussion_r2354928534 From ayang at openjdk.org Wed Sep 17 10:30:52 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 17 Sep 2025 10:30:52 GMT Subject: RFR: 8367737: Parallel: Retry allocation after lock acquire in mem_allocate_work In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 09:40:10 GMT, Albert Mingkun Yang wrote: > Restoring the allocation retrying logic inside lock-region to avoid premature GCs. This logic was mistakenly removed in [JDK-8365557](https://bugs.openjdk.org/browse/JDK-8365557). > > Test: tier1-3 Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27308#issuecomment-3302341124 From ayang at openjdk.org Wed Sep 17 10:30:54 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 17 Sep 2025 10:30:54 GMT Subject: Integrated: 8367737: Parallel: Retry allocation after lock acquire in mem_allocate_work In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 09:40:10 GMT, Albert Mingkun Yang wrote: > Restoring the allocation retrying logic inside lock-region to avoid premature GCs. This logic was mistakenly removed in [JDK-8365557](https://bugs.openjdk.org/browse/JDK-8365557). > > Test: tier1-3 This pull request has now been integrated. Changeset: c28142e7 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/c28142e7c142b2938823451c1f638f56a7f969d2 Stats: 52 lines in 2 files changed: 29 ins; 20 del; 3 mod 8367737: Parallel: Retry allocation after lock acquire in mem_allocate_work Reviewed-by: fandreuzzi, tschatzl, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/27308 From ayang at openjdk.org Wed Sep 17 10:54:09 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 17 Sep 2025 10:54:09 GMT Subject: RFR: 8367739: Serial: Retry allocation after lock acquire in mem_allocate_work Message-ID: Restoring the allocation retrying logic inside lock-region to avoid premature GCs. This logic was mistakenly removed in [JDK-8364628](https://bugs.openjdk.org/browse/JDK-8364628). Test: tier1-3 ------------- Commit messages: - sgc-retry Changes: https://git.openjdk.org/jdk/pull/27340/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27340&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367739 Stats: 39 lines in 2 files changed: 28 ins; 10 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27340.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27340/head:pull/27340 PR: https://git.openjdk.org/jdk/pull/27340 From ayang at openjdk.org Wed Sep 17 12:55:53 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 17 Sep 2025 12:55:53 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v61] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 07:18:14 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * iwalulya review > * documentation for a few PSS members > * rename some member variables to contain _ct and _rt suffixes in remembered set verification Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23739#pullrequestreview-3234308768 From fandreuzzi at openjdk.org Wed Sep 17 13:45:42 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 17 Sep 2025 13:45:42 GMT Subject: RFR: 8367739: Serial: Retry allocation after lock acquire in mem_allocate_work In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 10:46:56 GMT, Albert Mingkun Yang wrote: > Restoring the allocation retrying logic inside lock-region to avoid premature GCs. This logic was mistakenly removed in [JDK-8364628](https://bugs.openjdk.org/browse/JDK-8364628). > > Test: tier1-3 Marked as reviewed by fandreuzzi (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/27340#pullrequestreview-3234539303 From sjohanss at openjdk.org Wed Sep 17 13:46:52 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Wed, 17 Sep 2025 13:46:52 GMT Subject: RFR: 8348278: Trim InitialRAMPercentage to improve startup in default modes [v4] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 12:57:47 GMT, Aleksey Shipilev wrote: >> See bug for discussion. This is the code change, which is simple. What is not simple is deciding what the new value should be. The change would probably require CSR, which I can file after we agree on the value. >> >> I think cutting to 0.2% of RAM size gets us into good sweet spot: >> - On huge 1024G machine, this yields 2G initial heap >> - On reasonably sized 128G machine, this gives 256M initial heap >> - On smaller 1G container, this gives 2M initial heap >> >> Additional testing: >> - [x] Linux AArch64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Also man page > - Fix Testing looks ok, we do see some regression in some micro-benchmarks. Likely because of smaller initial heaps. Not a very big deal, but there have been some internal discussions around changing the percentage versus capping the initial heap size to some "reasonable value", maybe 2G or so. There are pros and cons with both, but most people feel like there is less risk with capping the value. This will allow most deployments to not see a change, but for really large machines we won't use as much memory for the initial heap. I know this was brought up earlier as well, but still wanted to provide this feedback and hear if you have any more argument against capping? We cap the max heap size to the COOPs limit, so this would not be the first cap. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23262#issuecomment-3303080046 From iwalulya at openjdk.org Wed Sep 17 13:56:08 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 17 Sep 2025 13:56:08 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v5] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 09:21:59 GMT, Ivan Walulya wrote: >> Yes I do have concerns - sorry. Any change to the shutdown sequence needs very careful analysis. You have now changed the circumstances whereby the JVMTI events get posted. Maybe it won't matter, maybe it will - the issue is that it is very hard to determine the impact of such a change until you get notified that someone's code is now broken. > > I have undone that part of the change. We can revisit it separately, that way it is easier to backout if it is problematic Created [JDK-8367902](https://bugs.openjdk.org/browse/JDK-8367902) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2355608908 From gli at openjdk.org Wed Sep 17 14:07:56 2025 From: gli at openjdk.org (Guoxiong Li) Date: Wed, 17 Sep 2025 14:07:56 GMT Subject: RFR: 8367626: Parallel: Remove ParallelCompactData::summarize_dense_prefix In-Reply-To: <4C7vmePNpSeo7KXiLiSJUWTgOXBbq-dqgZtBvD6p9WQ=.7de375d3-0f3d-4163-857c-27f004643184@github.com> References: <4C7vmePNpSeo7KXiLiSJUWTgOXBbq-dqgZtBvD6p9WQ=.7de375d3-0f3d-4163-857c-27f004643184@github.com> Message-ID: <8X7ruAPzh5sDbnF8MXlMplKd-GNFQbwejIuttKQNnys=.e38883f8-56f2-4628-9dbe-6de8101bc7bc@github.com> On Mon, 15 Sep 2025 08:22:40 GMT, Albert Mingkun Yang wrote: > Remove the unnecessary summary operation on dense-prefix, because the summary operation is only needed for compaction, but dense-prefix doesn't participate in compaction. > > Test: tier1-5 Looks good. One question. src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1552: > 1550: HeapWord* dense_prefix_addr = dense_prefix(SpaceId(id)); > 1551: HeapWord* top = sp->top(); > 1552: HeapWord* cur_addr = dense_prefix_addr; These changes just refactor the code which is not related to the title `Remove ParallelCompactData::summarize_dense_prefix`. Is my thought right? ------------- Marked as reviewed by gli (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27286#pullrequestreview-3234641841 PR Review Comment: https://git.openjdk.org/jdk/pull/27286#discussion_r2355645890 From tschatzl at openjdk.org Wed Sep 17 14:03:58 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 17 Sep 2025 14:03:58 GMT Subject: RFR: 8363932: G1: Better distribute KlassCleaningTask Message-ID: <4wv4YEc8jXOrh142RF4lbiAOx5HSEe8tcDc-BYQC-5I=.461e968b-21dd-493e-9dfb-dcc9f962700a@github.com> Hi all, please review this change to parallel klass cleaning to improve performance. The current implementation only parallelizes cleaning of weak class links, while the main work, cleaning the object tree is single-threaded. Hence in practice, the current mechanism does not scale beyond 2-3 threads. Cleaning an object graph in an application that loads some jars and instantiates central classes within them, with around 180k classes the current `G1 Complete Cleaning` task (which executes this code) can take 80ms (with 25 threads). The suggested change is to walk the object graph by (live) `ClassLoaderData` klass by klass, fixing only the links of that particular klass. E.g. CLD1 has klasses A, B, C, CLD2 has klasses a, b, c and CLD3 has klasses 0, 1, 2, 4; vertical links are subklass references, while horizontal links are sibling references. j.l.O | A - B - c - 3 | 0 - 2 - C - 1 CLD 3 is dead. Thread 1 claims CLD 1, Thread 2 claims CLD 2 (and nobody claims CLD3 because it's dead). So thread 1, when reaching `A` fixes its subklass link to `C`, and otherwise does nothing with `A`. When looking at `C`, it will remove the link to `1`. Thread 2 will only remove the link to `3` of `c`. The result is j.l.O | A - B - c | C There should be no unnecessary object graph walking. There is a slight change in printing during unlinking: previously the code, when cleaning subklasses it printed `unlinking class (subclass)`for every class that has been removed on the way to the next live one. In above case, it would print unlinking class (subclass): 0 unlinking class (subclass): 2 With the change, to avoid following the subklasses of the graph twice, it prints ?unlinking class (subclass): 0 unlinking class (sibling): 0 because the string in brackets is the actual link that is followed. I can revert that change. With the change "Complete Cleaning" time for 200k classes takes 7.6ms (The test is a bit random on when it does the class unloading). Testing: tier1-5 Thanks, Thomas ------------- Commit messages: - * cleanup - * improve clean_subklass() to return the last live Klass to avoid the repeating the walk - Merge branch 'master' into 8363932-klasstaskcleaning-distribution - * somewhat fixed logging - * cleanup - * fix includes - * some more changes, works now? - * some attempts to improve class unloading Changes: https://git.openjdk.org/jdk/pull/27316/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27316&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8363932 Stats: 116 lines in 7 files changed: 6 ins; 61 del; 49 mod Patch: https://git.openjdk.org/jdk/pull/27316.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27316/head:pull/27316 PR: https://git.openjdk.org/jdk/pull/27316 From ayang at openjdk.org Wed Sep 17 14:42:26 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 17 Sep 2025 14:42:26 GMT Subject: RFR: 8367626: Parallel: Remove ParallelCompactData::summarize_dense_prefix In-Reply-To: <8X7ruAPzh5sDbnF8MXlMplKd-GNFQbwejIuttKQNnys=.e38883f8-56f2-4628-9dbe-6de8101bc7bc@github.com> References: <4C7vmePNpSeo7KXiLiSJUWTgOXBbq-dqgZtBvD6p9WQ=.7de375d3-0f3d-4163-857c-27f004643184@github.com> <8X7ruAPzh5sDbnF8MXlMplKd-GNFQbwejIuttKQNnys=.e38883f8-56f2-4628-9dbe-6de8101bc7bc@github.com> Message-ID: On Wed, 17 Sep 2025 14:04:09 GMT, Guoxiong Li wrote: >> Remove the unnecessary summary operation on dense-prefix, because the summary operation is only needed for compaction, but dense-prefix doesn't participate in compaction. >> >> Test: tier1-5 > > src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1552: > >> 1550: HeapWord* dense_prefix_addr = dense_prefix(SpaceId(id)); >> 1551: HeapWord* top = sp->top(); >> 1552: HeapWord* cur_addr = dense_prefix_addr; > > These changes just refactor the code which is not related to the title `Remove ParallelCompactData::summarize_dense_prefix`. Is my thought right? Yes; thought they are "trivial" enough, so included them here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27286#discussion_r2355763115 From stefank at openjdk.org Wed Sep 17 14:44:42 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 17 Sep 2025 14:44:42 GMT Subject: RFR: 8367848: Parallel: Use NMethodToOopClosure during Young GC In-Reply-To: <1junjLjTWzIsXHpwN7aXUvGSrRafJPP-LBUA3ZsQnDM=.21c925ae-d5b6-486b-be19-33fbe865b994@github.com> References: <1junjLjTWzIsXHpwN7aXUvGSrRafJPP-LBUA3ZsQnDM=.21c925ae-d5b6-486b-be19-33fbe865b994@github.com> Message-ID: On Wed, 17 Sep 2025 09:00:22 GMT, Albert Mingkun Yang wrote: > Replace `MarkingNMethodClosure` with `NMethodToOopClosure` during young-gc. After that, a new local `ThreadsClaimTokenScope` is introduced instead of `StrongRootsScope` to make the thread-claim-token logic visible in the current context. > > Test: tier1-3 src/hotspot/share/gc/parallel/psScavenge.cpp line 244: > 242: Threads::assert_all_threads_claimed(); > 243: } > 244: }; Could this class be placed in Threads together with these functions: static uintx thread_claim_token() static void change_thread_claim_token(); static void assert_all_threads_claimed() NOT_DEBUG_RETURN; static void possibly_parallel_oops_do(bool is_par, OopClosure* f, NMethodClosure* cf); There's other GC code that could benefit from using this helper. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27336#discussion_r2355768943 From ayang at openjdk.org Wed Sep 17 14:54:55 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 17 Sep 2025 14:54:55 GMT Subject: RFR: 8367848: Parallel: Use NMethodToOopClosure during Young GC [v2] In-Reply-To: <1junjLjTWzIsXHpwN7aXUvGSrRafJPP-LBUA3ZsQnDM=.21c925ae-d5b6-486b-be19-33fbe865b994@github.com> References: <1junjLjTWzIsXHpwN7aXUvGSrRafJPP-LBUA3ZsQnDM=.21c925ae-d5b6-486b-be19-33fbe865b994@github.com> Message-ID: > Replace `MarkingNMethodClosure` with `NMethodToOopClosure` during young-gc. After that, a new local `ThreadsClaimTokenScope` is introduced instead of `StrongRootsScope` to make the thread-claim-token logic visible in the current context. > > Test: tier1-3 Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27336/files - new: https://git.openjdk.org/jdk/pull/27336/files/ec254909..69767adf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27336&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27336&range=00-01 Stats: 18 lines in 2 files changed: 9 ins; 8 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27336.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27336/head:pull/27336 PR: https://git.openjdk.org/jdk/pull/27336 From ayang at openjdk.org Wed Sep 17 14:54:57 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 17 Sep 2025 14:54:57 GMT Subject: RFR: 8367848: Parallel: Use NMethodToOopClosure during Young GC [v2] In-Reply-To: References: <1junjLjTWzIsXHpwN7aXUvGSrRafJPP-LBUA3ZsQnDM=.21c925ae-d5b6-486b-be19-33fbe865b994@github.com> Message-ID: <9UyvmAFc29PeLlikjkncQg2RzO2pgRf-hvHh00Pf6MM=.8f39060b-1ab8-46aa-af63-d099b0706ea3@github.com> On Wed, 17 Sep 2025 14:41:11 GMT, Stefan Karlsson wrote: >> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> review > > src/hotspot/share/gc/parallel/psScavenge.cpp line 244: > >> 242: Threads::assert_all_threads_claimed(); >> 243: } >> 244: }; > > Could this class be placed in Threads together with these functions: > > static uintx thread_claim_token() > static void change_thread_claim_token(); > static void assert_all_threads_claimed() NOT_DEBUG_RETURN; > static void possibly_parallel_oops_do(bool is_par, OopClosure* f, NMethodClosure* cf); > > > There's other GC code that could benefit from using this helper. Moved to `threads.hpp` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27336#discussion_r2355810260 From iwalulya at openjdk.org Wed Sep 17 14:59:05 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 17 Sep 2025 14:59:05 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v6] In-Reply-To: References: Message-ID: > Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. > > Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. > > Testing: Tier 1-7 Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs - Revert - Thomas Review - return on timeout - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs - timed wait - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs - space - remove debug logs - ... and 3 more: https://git.openjdk.org/jdk/compare/d7eeacf2...ab94789c ------------- Changes: https://git.openjdk.org/jdk/pull/27190/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27190&range=05 Stats: 178 lines in 15 files changed: 110 ins; 62 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27190.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27190/head:pull/27190 PR: https://git.openjdk.org/jdk/pull/27190 From stefank at openjdk.org Wed Sep 17 15:10:33 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 17 Sep 2025 15:10:33 GMT Subject: RFR: 8367848: Parallel: Use NMethodToOopClosure during Young GC [v2] In-Reply-To: References: <1junjLjTWzIsXHpwN7aXUvGSrRafJPP-LBUA3ZsQnDM=.21c925ae-d5b6-486b-be19-33fbe865b994@github.com> Message-ID: On Wed, 17 Sep 2025 14:54:55 GMT, Albert Mingkun Yang wrote: >> Replace `MarkingNMethodClosure` with `NMethodToOopClosure` during young-gc. After that, a new local `ThreadsClaimTokenScope` is introduced instead of `StrongRootsScope` to make the thread-claim-token logic visible in the current context. >> >> Test: tier1-3 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Adding runtime because this now also touches the Threads class. src/hotspot/share/gc/parallel/psScavenge.cpp line 237: > 235: > 236: class ScavengeRootsTask : public WorkerTask { > 237: Threads::ThreadsClaimTokenScope _threads_claim_token_scope; // needed for Threads::possibly_parallel_threads_do I wonder if this class could just be named ClaimTokenScope so that we don't need to see the word Threads twice? Threads::ThreadsClaimTokenScope vs Threads::ClaimTokenScope OTOH, the function is named `change_thread_claim_token`. Maybe the second reviewer could weigh in on this. src/hotspot/share/runtime/threads.hpp line 112: > 110: Threads::assert_all_threads_claimed(); > 111: } > 112: }; I wonder if the implementation should be moved to the cpp file or if we consider this small enough to include here? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27336#issuecomment-3303451470 PR Review Comment: https://git.openjdk.org/jdk/pull/27336#discussion_r2355850180 PR Review Comment: https://git.openjdk.org/jdk/pull/27336#discussion_r2355850649 From ghan at openjdk.org Wed Sep 17 15:45:15 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Wed, 17 Sep 2025 15:45:15 GMT Subject: RFR: 8367754: G1: Add a fast path in heap resize related method Message-ID: Please review this change. **Description:** It's common for some Java application engineers to configure the heap with the same minimum and maximum size in order to avoid the overhead of heap resizing.In such cases no expansion or shrinkage is possible, so i think we can adds a fast path at the beginning of the method to detect when the heap?s min and max capacities are equal and return early, thereby avoiding unnecessary computation. I added a check to determine whether MinHeapSize and MaxHeapSize are equal before performing the heap resize calculation. Since both MaxHeapSize and MinHeapSize are aligned to HeapAlignment, so i think comparing them directly is good. **Test:** GHA ------------- Commit messages: - Implement fast path Changes: https://git.openjdk.org/jdk/pull/27349/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27349&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367754 Stats: 23 lines in 3 files changed: 22 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27349.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27349/head:pull/27349 PR: https://git.openjdk.org/jdk/pull/27349 From ayang at openjdk.org Wed Sep 17 15:54:45 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 17 Sep 2025 15:54:45 GMT Subject: RFR: 8367848: Parallel: Use NMethodToOopClosure during Young GC [v2] In-Reply-To: References: <1junjLjTWzIsXHpwN7aXUvGSrRafJPP-LBUA3ZsQnDM=.21c925ae-d5b6-486b-be19-33fbe865b994@github.com> Message-ID: On Wed, 17 Sep 2025 15:05:16 GMT, Stefan Karlsson wrote: >> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> review > > src/hotspot/share/gc/parallel/psScavenge.cpp line 237: > >> 235: >> 236: class ScavengeRootsTask : public WorkerTask { >> 237: Threads::ThreadsClaimTokenScope _threads_claim_token_scope; // needed for Threads::possibly_parallel_threads_do > > I wonder if this class could just be named ClaimTokenScope so that we don't need to see the word Threads twice? > > Threads::ThreadsClaimTokenScope > > vs > > Threads::ClaimTokenScope > > OTOH, the function is named `change_thread_claim_token`. Maybe the second reviewer could weigh in on this. `ThreadsClaimTokenScope` should only be used by GC code, so I can put it in GC-shared code instead of `threads`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27336#discussion_r2355992008 From ayang at openjdk.org Wed Sep 17 15:56:53 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 17 Sep 2025 15:56:53 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v6] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 14:59:05 GMT, Ivan Walulya wrote: >> Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. >> >> Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. >> >> Testing: Tier 1-7 > > Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: > > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - Revert > - Thomas Review > - return on timeout > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - timed wait > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - space > - remove debug logs > - ... and 3 more: https://git.openjdk.org/jdk/compare/d7eeacf2...ab94789c Should `CollectedHeap::satisfy_failed_metadata_allocation` also call `stall_for_vm_shutdown`? (Looking through all subclasses of `VM_GC_Collect_Operation`.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27190#issuecomment-3303632008 From shade at openjdk.org Wed Sep 17 16:00:56 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 17 Sep 2025 16:00:56 GMT Subject: RFR: 8348278: Trim InitialRAMPercentage to improve startup in default modes [v4] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 13:43:50 GMT, Stefan Johansson wrote: > There are pros and cons with both, but most people feel like there is less risk with capping the value. This will allow most deployments to not see a change, but for really large machines we won't use as much memory for the initial heap. I know this was brought up earlier as well, but still wanted to provide this feedback and hear if you have any more argument against capping? Well, as I argued before, capping does not turn out to be simpler: https://github.com/openjdk/jdk/pull/23262#issuecomment-2701763566. Performance-wise, "simpler" capping gives you surprises as well. It is easy to see there is a primary _linear_ effect with `Xms` for Serial, Parallel, G1: the larger the initial commit, proportionally more time is needed for initializing the heap itself and the internal structures that are usually linear to the size of the (initial) heap. But for G1 specifically, there is a second-order _non-linear_ effect, which shows up on small heap configurations. With Xmx <= 2G, you can get really unlucky. See the graphs in [JDK-8348278](https://bugs.openjdk.org/browse/JDK-8348278). You can see there, for example, that configurations with <= 2G Xmx for G1 are the worst configurations, and they get worse as `Xms` comes closer to `Xmx`. Intuitively, this is due to some G1 configs have a lot of small-ish regions, which are pain to init, and larger `Xms` forces you to init more regions. (See also: [JDK-8348270](https://bugs.openjdk.org/browse/JDK-8348270)). In other words, the reasonable-on-a-surface idea of capping at `Xms2g` turns out to be the worst default for a default collector, because it almost always does Xmx=Xms on a large-ish machine, like my desktop :) In other words, for G1, 2G Xms cap is way, way too high. So you would want to cap `Xms` fairly low. Otherwise, if you leave `Xmx` to auto-selection too, you may end up stepping into G1 pain zone. (In fact, that is what happened to me in Leyden startup experiments! This is how I found this is a problem.) Trimming `IRAMP` is more convenient way to achieve this, because with it -- Xmx compressed oops caps notwithstanding -- Xms and Xmx would _both_ be ratio-ed from system memory size, and thus Xms would very likely be far away from Xmx, even if you are in pain zone. Plus, as I noted before, it piggybacks on already existing ergonomics infrastructure, which avoids extra work. Bottom-line: On balance, trimming `IRAMP` is much easier way out. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23262#issuecomment-3303646279 From wkemper at openjdk.org Wed Sep 17 19:10:44 2025 From: wkemper at openjdk.org (William Kemper) Date: Wed, 17 Sep 2025 19:10:44 GMT Subject: RFR: 8367708: GenShen: Reduce total evacuation burden [v3] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 19:41:47 GMT, Kelvin Nilsen wrote: >> This PR provides several improvements that cumulatively reduce the amount of evacuation performed by GenShen compared to traditional Shenandoah. Specifically: >> >> 1. Do not promote humongous arrays of primitive data. Leaving these regions in the young generation allows them to be reclaimed more quickly when they become garbage. There is no disadvantage to leaving these regions in the young generation as their contents does not need to be scanned by the garbage collector. >> 2. Change the default value of ShenandoahOldGarbageThreshold from 15% to 25%. This results in smaller sets of candidate regions for mixed evacuation, less aggressive compaction of old generation. This also increases the likelihood that a region will be promoted in place instead of promoted by evacuation. >> 3. Only promote regions in place if the used within a region exceeds ShenandoahGenerationalMinPIPUsage (default 30) percent of the heap region size. This is enforced in combination with the preexisting requirement that the garbage within the region be less than ShenandoahOldGarbageThreshold (new default 25) percent of the heap region size. This causes regions with very low utilization to be promoted by evacuation rather than promoted in place. While the immediate effect of this change is to perform more copying when the region is promoted, the secondary effect is that this region does not need to be evacuated at a later time, after it has accumulated more live data, as part of an effort to defragment old-gen memory. >> 4. Only defragment old-gen memory if the command-line has requested non-zero reserves for humongous objects (ShenandoahGenerationalHumongousReserves). Previously, we would invest in defragmenting old-gen memory every time we finished old-generation marking, even if ShenandoahGenerationalHumongousReserves equals zero. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > revert changes to trash_humongous_region_at() LGTM! ------------- Marked as reviewed by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27278#pullrequestreview-3235879253 From stefank at openjdk.org Wed Sep 17 19:32:20 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 17 Sep 2025 19:32:20 GMT Subject: RFR: 8367848: Parallel: Use NMethodToOopClosure during Young GC [v2] In-Reply-To: References: <1junjLjTWzIsXHpwN7aXUvGSrRafJPP-LBUA3ZsQnDM=.21c925ae-d5b6-486b-be19-33fbe865b994@github.com> Message-ID: <0a04SdKiikKdYExWYiGfKjB2QtCOC0JLNw31DAVIiNU=.9310e70f-024b-4c43-95e6-bd2672ab0d65@github.com> On Wed, 17 Sep 2025 15:51:59 GMT, Albert Mingkun Yang wrote: >> src/hotspot/share/gc/parallel/psScavenge.cpp line 237: >> >>> 235: >>> 236: class ScavengeRootsTask : public WorkerTask { >>> 237: Threads::ThreadsClaimTokenScope _threads_claim_token_scope; // needed for Threads::possibly_parallel_threads_do >> >> I wonder if this class could just be named ClaimTokenScope so that we don't need to see the word Threads twice? >> >> Threads::ThreadsClaimTokenScope >> >> vs >> >> Threads::ClaimTokenScope >> >> OTOH, the function is named `change_thread_claim_token`. Maybe the second reviewer could weigh in on this. > > `ThreadsClaimTokenScope` should only be used by GC code, so I can put it in GC-shared code instead of `threads`. Well, Threads::change_thread_claim_token() are also only used by GC but it is still located in Threads. Another alternative could be to put ThreadsClaimTokenScope at the end of threads.hpp. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27336#discussion_r2356545085 From phh at openjdk.org Wed Sep 17 23:57:36 2025 From: phh at openjdk.org (Paul Hohensee) Date: Wed, 17 Sep 2025 23:57:36 GMT Subject: RFR: 8367450: Shenandoah: Log the composition of the collection set [v5] In-Reply-To: <2KA4IRFQOPFBpt9D570g9HORzBXycZhs7cDPLYjnGmE=.6f331678-cb61-4e05-8c7d-06fcea7fa64e@github.com> References: <2KA4IRFQOPFBpt9D570g9HORzBXycZhs7cDPLYjnGmE=.6f331678-cb61-4e05-8c7d-06fcea7fa64e@github.com> Message-ID: <6CrX79gi4l5yFXhCPJVvftrgC7-ykYnY3siTgHcqyPY=.f5dcd425-7bfe-4dc8-b7af-c733987e67e2@github.com> On Wed, 17 Sep 2025 00:20:58 GMT, William Kemper wrote: >> Reuse the same log message from GenShen which details the composition of the live data to be evacuated. In the non-generational modes, all regions are considered young and nothing will be promoted (or old). > > William Kemper has updated the pull request incrementally with one additional commit since the last revision: > > Remove redundant collection set logging Marked as reviewed by phh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27235#pullrequestreview-3236614392 From phh at openjdk.org Wed Sep 17 23:58:40 2025 From: phh at openjdk.org (Paul Hohensee) Date: Wed, 17 Sep 2025 23:58:40 GMT Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a runtime diagnostic option [v2] In-Reply-To: References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com> Message-ID: On Tue, 16 Sep 2025 18:16:27 GMT, William Kemper wrote: >> Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option. > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge remote-tracking branch 'jdk/master' into make-evac-tracking-runtime-option > - Only print evacuation info when evac tracking is enabled (generational mode fix) > - Make detailed evacuation tracking a diagnostic option in product builds Marked as reviewed by phh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27238#pullrequestreview-3236618160 From ysr at openjdk.org Thu Sep 18 00:52:35 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Thu, 18 Sep 2025 00:52:35 GMT Subject: RFR: 8367450: Shenandoah: Log the composition of the collection set [v5] In-Reply-To: <2KA4IRFQOPFBpt9D570g9HORzBXycZhs7cDPLYjnGmE=.6f331678-cb61-4e05-8c7d-06fcea7fa64e@github.com> References: <2KA4IRFQOPFBpt9D570g9HORzBXycZhs7cDPLYjnGmE=.6f331678-cb61-4e05-8c7d-06fcea7fa64e@github.com> Message-ID: On Wed, 17 Sep 2025 00:20:58 GMT, William Kemper wrote: >> Reuse the same log message from GenShen which details the composition of the live data to be evacuated. In the non-generational modes, all regions are considered young and nothing will be promoted (or old). > > William Kemper has updated the pull request incrementally with one additional commit since the last revision: > > Remove redundant collection set logging Changes look good, other than suggested documentation of a few APIs (see specific comment in review). src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp line 1: > 1: /* Either for the accessors (preferred because they are the public APIs for the class) or for the private data members in which those values are tracked, it would be nice to have a one-line sentence describing what the value is and when the value is valid. I realize this might seem obvious when working in this code, but the documentation is helpful for those not deeply familiar with these fields or trying to use these many months later. ------------- Marked as reviewed by ysr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27235#pullrequestreview-3236816177 PR Review Comment: https://git.openjdk.org/jdk/pull/27235#discussion_r2357188582 From ysr at openjdk.org Thu Sep 18 01:59:44 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Thu, 18 Sep 2025 01:59:44 GMT Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a runtime diagnostic option [v2] In-Reply-To: References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com> Message-ID: <-S5kGwanp5G--dEw5uQBPRFlnSO9l6yyyXGOdQKAwd8=.f891358d-5e2d-4677-bf00-e97a146e1b05@github.com> On Tue, 16 Sep 2025 18:16:27 GMT, William Kemper wrote: >> Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option. > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge remote-tracking branch 'jdk/master' into make-evac-tracking-runtime-option > - Only print evacuation info when evac tracking is enabled (generational mode fix) > - Make detailed evacuation tracking a diagnostic option in product builds Changes look good to me. I am guessing you checked that the original issue is gone; would be a good idea to check that the output looks like it's expected and may be include a sample output with the flag enabled. src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 399: > 397: product(bool, ShenandoahEvacTracking, false, DIAGNOSTIC, \ > 398: "Collect additional metrics about evacuations. Enabling this " \ > 399: "track how many objects and how many bytes were evacuated, and " \ Nit: track -> tracks? Or may be simply say: "Track additional, more detailed metrics related to evacuations by mutators and GC workers." and elide the first sentence" "Collect additional ..."? ------------- Marked as reviewed by ysr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27238#pullrequestreview-3236841054 PR Review Comment: https://git.openjdk.org/jdk/pull/27238#discussion_r2357208495 From ysr at openjdk.org Thu Sep 18 01:59:45 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Thu, 18 Sep 2025 01:59:45 GMT Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a runtime diagnostic option In-Reply-To: References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com> Message-ID: On Fri, 12 Sep 2025 21:29:39 GMT, William Kemper wrote: > This chart shows the distribution (as a box plot) of all concurrent evacuation times across all benchmarks and platforms for the past 24 hours (approximately 15K data points in total). Each facet of the chart shows 3 configurations: > > * top: The diagnostic option in this PR is enabled > * middle: The diagnostic option is disabled > * bottom: The baseline - this behavior does not exist in the product build. > > The first facet shows the effect of this option on _global_ GCs in Genshen. The second facet shows the effect of this option on _global_ GCs in Shenandoah. The last option shows the effect on _young_ evacuation in GenShen. If I am reading the data right, it seems to me that the impact is most noticeable (percentage-wise) in Shenandoah. (The effect on GenShen seems minimal.) Is it understood why there should be a bigger impact on Shenandoah, or is the data telling us something else about why it looks the way it does? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27238#issuecomment-3305110048 From ghan at openjdk.org Thu Sep 18 03:28:33 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 18 Sep 2025 03:28:33 GMT Subject: RFR: 8367754: G1: Add a fast path in heap resize related method [v2] In-Reply-To: References: Message-ID: <6KA2oD5TfcT6zCzKZnmh6lN-SD3JygYuMeli5QHXorg=.6d613ec3-459d-41ee-b267-7db59a1f358d@github.com> > Please review this change. > > **Description:** > > It's common for some Java application engineers to configure the heap with the same minimum and maximum size in order to avoid the overhead of heap resizing.In such cases no expansion or shrinkage is possible, so i think we can adds a fast path at the beginning of the method to detect when the heap?s min and max capacities are equal and return early, thereby avoiding unnecessary computation. > I added a check to determine whether MinHeapSize and MaxHeapSize are equal before performing the heap resize calculation. Since both MaxHeapSize and MinHeapSize are aligned to HeapAlignment, so i think comparing them directly is good. > > **Test:** > > GHA Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: Create TestHeapResizeAfterGC.java add regression test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27349/files - new: https://git.openjdk.org/jdk/pull/27349/files/90a5c952..0cfec1fe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27349&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27349&range=00-01 Stats: 101 lines in 1 file changed: 101 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27349.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27349/head:pull/27349 PR: https://git.openjdk.org/jdk/pull/27349 From ghan at openjdk.org Thu Sep 18 03:32:16 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 18 Sep 2025 03:32:16 GMT Subject: RFR: 8367754: G1: Add a fast path in heap resize related method [v3] In-Reply-To: References: Message-ID: <26wTFQP7L9lpuQahVHl17nukhLB4KFDH3Njti5tZhTs=.8ec65369-82c2-4d53-92ff-66dcc7bfaf6e@github.com> > Please review this change. > > **Description:** > > It's common for some Java application engineers to configure the heap with the same minimum and maximum size in order to avoid the overhead of heap resizing.In such cases no expansion or shrinkage is possible, so i think we can adds a fast path at the beginning of the method to detect when the heap?s min and max capacities are equal and return early, thereby avoiding unnecessary computation. > I added a check to determine whether MinHeapSize and MaxHeapSize are equal before performing the heap resize calculation. Since both MaxHeapSize and MinHeapSize are aligned to HeapAlignment, so i think comparing them directly is good. > > **Test:** > > GHA Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: Update TestHeapResizeAfterGC.java correct format error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27349/files - new: https://git.openjdk.org/jdk/pull/27349/files/0cfec1fe..6786ee96 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27349&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27349&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27349.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27349/head:pull/27349 PR: https://git.openjdk.org/jdk/pull/27349 From dholmes at openjdk.org Thu Sep 18 05:22:39 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 18 Sep 2025 05:22:39 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v6] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 14:59:05 GMT, Ivan Walulya wrote: >> Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. >> >> Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. >> >> Testing: Tier 1-7 > > Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: > > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - Revert > - Thomas Review > - return on timeout > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - timed wait > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - space > - remove debug logs > - ... and 3 more: https://git.openjdk.org/jdk/compare/d7eeacf2...ab94789c As this doesn't seem to perturb the general shutdown process I have no further comment and will leave it to GC folk to approve. Though I still wonder if this aspect of shutdown should be part of "Heap" (or Universe) rather than G1 specific. ------------- PR Review: https://git.openjdk.org/jdk/pull/27190#pullrequestreview-3237321918 From iwalulya at openjdk.org Thu Sep 18 05:25:46 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 18 Sep 2025 05:25:46 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v61] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 07:18:14 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * iwalulya review > * documentation for a few PSS members > * rename some member variables to contain _ct and _rt suffixes in remembered set verification LGTM! ------------- Marked as reviewed by iwalulya (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23739#pullrequestreview-3237327044 From sjohanss at openjdk.org Thu Sep 18 06:19:37 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Thu, 18 Sep 2025 06:19:37 GMT Subject: RFR: 8348278: Trim InitialRAMPercentage to improve startup in default modes [v4] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 15:58:05 GMT, Aleksey Shipilev wrote: > In other words, the reasonable-on-a-surface idea of capping at Xms2g turns out to be the worst default for a default collector, because it almost always does Xmx=Xms on a large-ish machine, like my desktop :) In other words, for G1, 2G Xms cap is way, way too high. This adds another argument to something else we discussed yesterday, why is this initial value a fraction of the RAM and not a fraction of the chosen `MaxHeapSize`? We could not come up with a good answer to that, do you see any good reason? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23262#issuecomment-3305579549 From tschatzl at openjdk.org Thu Sep 18 07:39:27 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 18 Sep 2025 07:39:27 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v59] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 07:38:56 GMT, Fei Yang wrote: >>> @tschatzl : Hi, would you mind adding a small cleanup change for riscv? This also adds back the assertion about the registers. Still test good on linux-riscv64 platform. [riscv-addon.diff.txt](https://github.com/user-attachments/files/22356611/riscv-addon.diff.txt) >> >> This is the `end` -> `count` transformation in the barrier I suggested earlier for RISC-V, isn't it? Thanks for contributing that, but would you mind me holding off this until @theRealAph acks that similar change for aarch64? It would be unfortunate imo if the implementations diverge too much. > >> > @tschatzl : Hi, would you mind adding a small cleanup change for riscv? This also adds back the assertion about the registers. Still test good on linux-riscv64 platform. [riscv-addon.diff.txt](https://github.com/user-attachments/files/22356611/riscv-addon.diff.txt) >> >> This is the `end` -> `count` transformation in the barrier I suggested earlier for RISC-V, isn't it? Thanks for contributing that, but would you mind me holding off this until @theRealAph acks that similar change for aarch64? It would be unfortunate imo if the implementations diverge too much. > > Yes, sure! The purpose is to minimize the difference to avoid possible issues in the future. @RealFYang : going to wait for the response of @theRealAph about the `end->count` matter until early next week, otherwise I'll move this change to cleanups/further enhancements like (JDK-8352069)[https://bugs.openjdk.org/browse/JDK-8352069] already planned. Just want to be "done" at some point with this change :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3305851845 From azafari at openjdk.org Thu Sep 18 07:46:21 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 18 Sep 2025 07:46:21 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v5] In-Reply-To: References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> Message-ID: On Wed, 17 Sep 2025 08:01:36 GMT, Axel Boldt-Christmas wrote: > What is the reasoning behind using `uint64_t` rather than `uintptr_t`? I follow (IIUC) your comments on replacing uintptr_t and uint64_t because of differences in platforms. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3305900059 From aph at openjdk.org Thu Sep 18 08:03:17 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 18 Sep 2025 08:03:17 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v61] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 07:18:14 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * iwalulya review > * documentation for a few PSS members > * rename some member variables to contain _ct and _rt suffixes in remembered set verification Marked as reviewed by aph (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23739#pullrequestreview-3237979731 From aph at openjdk.org Thu Sep 18 08:03:18 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 18 Sep 2025 08:03:18 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v55] In-Reply-To: <63y80KoZ7oXdnFLRmK28Z8wcOSSAMXHx91akDn0tcLc=.981add6e-0b3f-423f-9b5f-87bb7d9fad9a@github.com> References: <63y80KoZ7oXdnFLRmK28Z8wcOSSAMXHx91akDn0tcLc=.981add6e-0b3f-423f-9b5f-87bb7d9fad9a@github.com> Message-ID: On Fri, 12 Sep 2025 08:27:01 GMT, Martin Doerr wrote: > Other idea: set count = noreg to prevent usage after it is used under the other name. That wouldn't have solved the aliasing problem, because count and end were being used as aliases for a register in _the same instruction_! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2357941045 From azafari at openjdk.org Thu Sep 18 08:52:23 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 18 Sep 2025 08:52:23 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v5] In-Reply-To: References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> Message-ID: On Tue, 16 Sep 2025 09:06:42 GMT, Afshin Zafari wrote: >> The minimum acceptable value was 0 where using it as address was problematic according to UBSAN. >> The acceptable value is changed to 64K. >> >> Tests: >> linux-x64 tier1 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > uintptr_t -> uint64_t I used `uintptr_t` for addresses, but there are pre-existing uses of `uint64_t` in the code that are used for addresses: #define SIZE_64K ((uint64_t) UCONST64( 0x10000)) #define SIZE_256M ((uint64_t) UCONST64( 0x10000000)) #define SIZE_32G ((uint64_t) UCONST64( 0x800000000)) // Helper for heap allocation. Returns an array with addresses // (OS-specific) which are suited for disjoint base mode. Array is // null terminated. static char** get_attach_addresses_for_disjoint_mode() { static uint64_t addresses[] = {``` > f anything the pre-existing type of `unscaled_end` may be wrong. Because end makes sound like an address in this context, but it is describing an offset. And is only used to check for an underflow before we may reinterpret it as an address (0 + offset). > > That part I think would read much better by checking for the underflow first: > > ```c++ > uintptr_t lowest_start = aligned_heap_base_min_address; > if (size <= UnscaledOopHeapMax) { > lowest_start = MAX2(lowest_start, UnscaledOopHeapMax - size); > } > lowest_start = align_up(lowest_start, attach_point_alignment); > ``` Done. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3306322492 PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3306327411 From azafari at openjdk.org Thu Sep 18 08:57:48 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 18 Sep 2025 08:57:48 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v6] In-Reply-To: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> Message-ID: > The minimum acceptable value was 0 where using it as address was problematic according to UBSAN. > The acceptable value is changed to 64K. > > Tests: > linux-x64 tier1 Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: fixes. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26955/files - new: https://git.openjdk.org/jdk/pull/26955/files/fffb77a4..649f59d2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26955&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26955&range=04-05 Stats: 11 lines in 1 file changed: 0 ins; 1 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/26955.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26955/head:pull/26955 PR: https://git.openjdk.org/jdk/pull/26955 From azafari at openjdk.org Thu Sep 18 08:57:50 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 18 Sep 2025 08:57:50 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v5] In-Reply-To: References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> Message-ID: <5CIoOI6iDMRNQqfhVURZIQZ30sEVBOKbDBFrXXEMvTo=.389fadc8-720d-41b9-8754-b6ef082615c7@github.com> On Wed, 17 Sep 2025 08:01:36 GMT, Axel Boldt-Christmas wrote: > I think the use of `uint64_t` stems from the `UnscaledOopHeapMax` and `OopEncodingHeapMax` being typed as such. Unclear to me why they are not just `size_t`, as coops is a 64-bit VM feature. Same to me. There are some/many cases of mixing type arithmetic like ` address + size_t < uint64_t`. It may not be any problem, but it'd been better if we can define a coding rule for these cases. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3306342645 From eosterlund at openjdk.org Thu Sep 18 09:03:06 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 18 Sep 2025 09:03:06 GMT Subject: RFR: 8350596: [Linux] Increase default MaxRAMPercentage for containerized workloads In-Reply-To: References: Message-ID: <1S38JYoE4Gclx8Cv0NOWFjFWgTj_4q2eqG4rhaZ2k1M=.024810d5-5829-475d-8526-5c99fded9466@github.com> On Wed, 7 May 2025 09:29:16 GMT, Severin Gehwolf wrote: > Please take a look at this proposal to fix the "Java needs so much memory" perception in containers. The idea would be to bump the default `MaxRAMPercentage` to a higher value. The patch proposes 75%, but we could just as well use 50% if people feel more comfortable about it. Right now the default deployment in containers with resource limits in place (common for Kubernetes deployments) where a single process runs in the container isn't well catered for today for an application that just uses the default configuration. Only 25% of the container memory will be used for the Java heap, arguably wasting much of the remaining memory that has been granted to the container by a memory limit (that the JVM would detect and use as physical memory). > > I've filed a CSR for this as well for which I'm looking for reviewers too and intend to write a release note as well about this change as it has some risk associated with it, although the escape hatch is pretty simple: set `-XX:MaxRAMPercentage=25.0` to go back to the old behavour. > > Testing: > - [x] GHA - tier 1 (windows failures seem infra related) > - [x] hotspot and jdk container tests on cg v2 and cg v1 including the two new tests. > > Thoughts? Opinions? The question how much heap memory an arbitrary Java program needs to run is in many ways similar to the halting problem of answering how much time a Java program needs to run. There is no great answer. 25% was a wild guess. Sometimes it's okay, sometimes it is awful. There are plenty of situations when it is not at all what you want. But I'm very skeptical against coming up with a new wild guess hoping to improve performance, while risking getting killed. In a 512 MB container, 25% might be too small and you really want to use 75% to get better performance, except when direct mapped byte buffers use too much memory. But in a 128 MB container, 75% might be too much as the JIT compiled code and meatspace might need more than 32 MB. I think trying to find a good answer to how much heap a Java should use without running it is hopeless, and don't feel thrilled about changing the guesses from one bad guess to another bad guess, rather than having a more complete way of reasoning about *why* a limit is too high or too low, and adapting accordingly at runtime. When these sort of proposals started popping up, I started working on automatic heap sizing instead so that we would be able to recognize that there is actually no static limit if the user hasn't said so, but we can deal with that without exhausting memory with some clever policies. Now there is a JEP for both ZGC (cf. https://openjdk.org/jeps/8329758) and G1 (cf. https://openjdk.org/jeps/8359211) to do automatic heap sizing. Given their arrival, do we still need to mess around with these guesses? If not, then I think changing from one bad guess to another bad guess might just introduce risk. I'd prefer to let automatic heap sizing solve this better instead. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25086#issuecomment-3306363643 From ayang at openjdk.org Thu Sep 18 09:04:27 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 18 Sep 2025 09:04:27 GMT Subject: RFR: 8367848: Parallel: Use NMethodToOopClosure during Young GC [v3] In-Reply-To: <1junjLjTWzIsXHpwN7aXUvGSrRafJPP-LBUA3ZsQnDM=.21c925ae-d5b6-486b-be19-33fbe865b994@github.com> References: <1junjLjTWzIsXHpwN7aXUvGSrRafJPP-LBUA3ZsQnDM=.21c925ae-d5b6-486b-be19-33fbe865b994@github.com> Message-ID: > Replace `MarkingNMethodClosure` with `NMethodToOopClosure` during young-gc. After that, a new local `ThreadsClaimTokenScope` is introduced instead of `StrongRootsScope` to make the thread-claim-token logic visible in the current context. > > Test: tier1-3 Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27336/files - new: https://git.openjdk.org/jdk/pull/27336/files/69767adf..1f2e3a6b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27336&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27336&range=01-02 Stats: 20 lines in 2 files changed: 10 ins; 9 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27336.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27336/head:pull/27336 PR: https://git.openjdk.org/jdk/pull/27336 From ayang at openjdk.org Thu Sep 18 09:04:28 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 18 Sep 2025 09:04:28 GMT Subject: RFR: 8367848: Parallel: Use NMethodToOopClosure during Young GC [v2] In-Reply-To: <0a04SdKiikKdYExWYiGfKjB2QtCOC0JLNw31DAVIiNU=.9310e70f-024b-4c43-95e6-bd2672ab0d65@github.com> References: <1junjLjTWzIsXHpwN7aXUvGSrRafJPP-LBUA3ZsQnDM=.21c925ae-d5b6-486b-be19-33fbe865b994@github.com> <0a04SdKiikKdYExWYiGfKjB2QtCOC0JLNw31DAVIiNU=.9310e70f-024b-4c43-95e6-bd2672ab0d65@github.com> Message-ID: On Wed, 17 Sep 2025 19:29:38 GMT, Stefan Karlsson wrote: >> `ThreadsClaimTokenScope` should only be used by GC code, so I can put it in GC-shared code instead of `threads`. > > Well, Threads::change_thread_claim_token() are also only used by GC but it is still located in Threads. Another alternative could be to put ThreadsClaimTokenScope at the end of threads.hpp. Moved to the end of `threads.hpp`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27336#discussion_r2358140692 From ayang at openjdk.org Thu Sep 18 09:07:23 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 18 Sep 2025 09:07:23 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v6] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 05:19:25 GMT, David Holmes wrote: > Though I still wonder if this aspect of shutdown should be part of "Heap" (or Universe) rather than G1 specific. Why is it G1 specific? The new `bool _is_shutting_down` lives inside `CollectedHeap` -- Serial/Parallel/G1 are all updated to use it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27190#issuecomment-3306378857 From stefank at openjdk.org Thu Sep 18 12:54:02 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 18 Sep 2025 12:54:02 GMT Subject: RFR: 8367848: Parallel: Use NMethodToOopClosure during Young GC [v3] In-Reply-To: References: <1junjLjTWzIsXHpwN7aXUvGSrRafJPP-LBUA3ZsQnDM=.21c925ae-d5b6-486b-be19-33fbe865b994@github.com> Message-ID: On Thu, 18 Sep 2025 09:04:27 GMT, Albert Mingkun Yang wrote: >> Replace `MarkingNMethodClosure` with `NMethodToOopClosure` during young-gc. After that, a new local `ThreadsClaimTokenScope` is introduced instead of `StrongRootsScope` to make the thread-claim-token logic visible in the current context. >> >> Test: tier1-3 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27336#pullrequestreview-3239487734 From ghan at openjdk.org Thu Sep 18 13:05:23 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 18 Sep 2025 13:05:23 GMT Subject: RFR: 8367754: G1: Add a fast path in heap resize related method [v3] In-Reply-To: <26wTFQP7L9lpuQahVHl17nukhLB4KFDH3Njti5tZhTs=.8ec65369-82c2-4d53-92ff-66dcc7bfaf6e@github.com> References: <26wTFQP7L9lpuQahVHl17nukhLB4KFDH3Njti5tZhTs=.8ec65369-82c2-4d53-92ff-66dcc7bfaf6e@github.com> Message-ID: On Thu, 18 Sep 2025 03:32:16 GMT, Guanqiang Han wrote: >> Please review this change. >> >> **Description:** >> >> It's common for some Java application engineers to configure the heap with the same minimum and maximum size in order to avoid the overhead of heap resizing.In such cases no expansion or shrinkage is possible, so i think we can adds a fast path at the beginning of the method to detect when the heap?s min and max capacities are equal and return early, thereby avoiding unnecessary computation. >> I added a check to determine whether MinHeapSize and MaxHeapSize are equal before performing the heap resize calculation. Since both MaxHeapSize and MinHeapSize are aligned to HeapAlignment, so i think comparing them directly is good. >> >> **Test:** >> >> GHA > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > Update TestHeapResizeAfterGC.java > > correct format error Hi @tschatzl @albertnetymk Sorry to bother you. Could you kindly take a look at this change? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27349#issuecomment-3307334200 From ayang at openjdk.org Thu Sep 18 13:18:43 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 18 Sep 2025 13:18:43 GMT Subject: RFR: 8367754: G1: Add a fast path in heap resize related method [v3] In-Reply-To: <26wTFQP7L9lpuQahVHl17nukhLB4KFDH3Njti5tZhTs=.8ec65369-82c2-4d53-92ff-66dcc7bfaf6e@github.com> References: <26wTFQP7L9lpuQahVHl17nukhLB4KFDH3Njti5tZhTs=.8ec65369-82c2-4d53-92ff-66dcc7bfaf6e@github.com> Message-ID: On Thu, 18 Sep 2025 03:32:16 GMT, Guanqiang Han wrote: >> Please review this change. >> >> **Description:** >> >> It's common for some Java application engineers to configure the heap with the same minimum and maximum size in order to avoid the overhead of heap resizing.In such cases no expansion or shrinkage is possible, so i think we can adds a fast path at the beginning of the method to detect when the heap?s min and max capacities are equal and return early, thereby avoiding unnecessary computation. >> I added a check to determine whether MinHeapSize and MaxHeapSize are equal before performing the heap resize calculation. Since both MaxHeapSize and MinHeapSize are aligned to HeapAlignment, so i think comparing them directly is good. >> >> **Test:** >> >> GHA > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > Update TestHeapResizeAfterGC.java > > correct format error > ... thereby avoiding unnecessary computation That's absolutely true; however, the real expensive part is not the calculation but actual resizing (commit/uncommit). Since the existing logic is not simplified by the use of early-return, I feel it hinders readability slightly. I wonder what others think. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27349#issuecomment-3307400985 From iwalulya at openjdk.org Thu Sep 18 13:28:52 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 18 Sep 2025 13:28:52 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v7] In-Reply-To: References: Message-ID: > Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. > > Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. > > Testing: Tier 1-7 Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - make universal - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs - Revert - Thomas Review - return on timeout - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs - timed wait - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs - ... and 5 more: https://git.openjdk.org/jdk/compare/4c7c009d...1a53c207 ------------- Changes: https://git.openjdk.org/jdk/pull/27190/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27190&range=06 Stats: 103 lines in 17 files changed: 76 ins; 20 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27190.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27190/head:pull/27190 PR: https://git.openjdk.org/jdk/pull/27190 From iwalulya at openjdk.org Thu Sep 18 13:31:43 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 18 Sep 2025 13:31:43 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v7] In-Reply-To: References: <37fyY6jq5j6CdWbBJQK94mkR70ik6oINWLiAR6nPY90=.dd5f6d7c-8a02-46f1-99db-bfb3500772fb@github.com> Message-ID: On Tue, 16 Sep 2025 14:44:20 GMT, Ivan Walulya wrote: >> I had put `log_cpu_time` right before calling `stop()`. The `stop()` is the method that terminates GC threads, so no synchronization should be needed if I'm not mistaken. >> >> Please correct me if you think I got it wrong here. >> >> Nevertheless, any user of `gc_threads_do` might still iterate over terminated GC workers thread. Could we consider adding a check or assert in that method? > > We can have GCs between `log_cpu_time` and `stop()`. This reduces chances of that happening if we have `log_cpu_time` under same lock as setting `_is_shutting_down`. > >> Nevertheless, any user of gc_threads_do might still iterate over terminated GC workers thread. Could we consider adding a check or assert in that method? > > Yes, we can have the assert in `gc_threads_do`, I thought this was going to be done as a follow up. I moved `_is_shutting_down` to `Universe`, which allowed me to restore this `log_cpu_time`. I also added the assert before reading `os::thread_cpu_time` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2359318824 From lkorinth at openjdk.org Thu Sep 18 13:54:17 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 18 Sep 2025 13:54:17 GMT Subject: RFR: 8285984: G1: Use standard idiom for inlined payload in G1MonotonicArena::Segment [v3] In-Reply-To: References: Message-ID: > This change remove the old padding (extremely big, especially on x86-64), and replaces it with a guaranteed 8 byte alignment. It also removes the `_bottom` field and instead adds a `payload` method. I statically assert that Segment is 8 byte aligned. I then runtime assert that Segment is constructed on 8 byte aligned memory. I also assert that the Slot alignment is less than or equal to the Segment alignment. > > I am running tier 1-3 at the moment. Do you think I should run some specific performance test on this? Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: Cleanup after comments from Axel. Rename SegmentAlignment -> SegmentPayloadMaxAlignment. Transform alignment assert to use percent operator (will ensure slot alignment is both less than segment alignment AND that segment alignment is a multiple of slot alignment) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27258/files - new: https://git.openjdk.org/jdk/pull/27258/files/131fa911..faf1a72d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27258&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27258&range=01-02 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27258.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27258/head:pull/27258 PR: https://git.openjdk.org/jdk/pull/27258 From tschatzl at openjdk.org Thu Sep 18 15:06:08 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 18 Sep 2025 15:06:08 GMT Subject: RFR: 8367739: Serial: Retry allocation after lock acquire in mem_allocate_work In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 10:46:56 GMT, Albert Mingkun Yang wrote: > Restoring the allocation retrying logic inside lock-region to avoid premature GCs. This logic was mistakenly removed in [JDK-8364628](https://bugs.openjdk.org/browse/JDK-8364628). > > Test: tier1-3 Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27340#pullrequestreview-3240331291 From ayang at openjdk.org Thu Sep 18 15:11:45 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 18 Sep 2025 15:11:45 GMT Subject: RFR: 8367739: Serial: Retry allocation after lock acquire in mem_allocate_work In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 10:46:56 GMT, Albert Mingkun Yang wrote: > Restoring the allocation retrying logic inside lock-region to avoid premature GCs. This logic was mistakenly removed in [JDK-8364628](https://bugs.openjdk.org/browse/JDK-8364628). > > Test: tier1-3 Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27340#issuecomment-3308017764 From ayang at openjdk.org Thu Sep 18 15:11:45 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 18 Sep 2025 15:11:45 GMT Subject: Integrated: 8367739: Serial: Retry allocation after lock acquire in mem_allocate_work In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 10:46:56 GMT, Albert Mingkun Yang wrote: > Restoring the allocation retrying logic inside lock-region to avoid premature GCs. This logic was mistakenly removed in [JDK-8364628](https://bugs.openjdk.org/browse/JDK-8364628). > > Test: tier1-3 This pull request has now been integrated. Changeset: c927291e Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/c927291ecfa3a3871a1eed006687a3e9db4f6811 Stats: 39 lines in 2 files changed: 28 ins; 10 del; 1 mod 8367739: Serial: Retry allocation after lock acquire in mem_allocate_work Reviewed-by: fandreuzzi, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/27340 From azafari at openjdk.org Thu Sep 18 15:37:38 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 18 Sep 2025 15:37:38 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v7] In-Reply-To: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> Message-ID: > The minimum acceptable value was 0 where using it as address was problematic according to UBSAN. > The acceptable value is changed to 64K. > > Tests: > linux-x64 tier1 Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: fixed MAX2 template parameter ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26955/files - new: https://git.openjdk.org/jdk/pull/26955/files/649f59d2..3dfa9765 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26955&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26955&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26955.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26955/head:pull/26955 PR: https://git.openjdk.org/jdk/pull/26955 From aboldtch at openjdk.org Thu Sep 18 15:37:38 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 18 Sep 2025 15:37:38 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v5] In-Reply-To: References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> Message-ID: On Thu, 18 Sep 2025 07:44:04 GMT, Afshin Zafari wrote: > I followed (IIUC) your comments on replacing uintptr_t and uint64_t because of differences in platforms. Sorry, something must be lacking in my communication. What I was trying to describe was that you will have issues if you expect the two typedefs to have the same underlying type even if we can assume they are both 64bit and unsigned. You currently have the same issue with `size_t` and `uintptr_t`. The issue is that you are using a template function which expects something along the lines of `T MAX2(T, T)`. But you are using it with two distinct (but compatible) types. The compiler cannot infer if you want `unsigned long long MAX2(unsigned long long, unsigned long long)` or `unsigned long MAX2(unsigned long, unsigned long)` so you need to tell it. There are in general two ways to do this. Either you cast: ```C++ lowest_start = MAX2(lowest_start, (uintptr_t)(UnscaledOopHeapMax - size)); or you select the specific instantiation of the templated function: ```C++ lowest_start = MAX2(lowest_start, UnscaledOopHeapMax - size); I prefer the later as it allows `-Wconversions` to warn if these types are incompatible(/lossy). While the cast will silence such warnings. If I see the former I usually assume that we are truncating or allow truncation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3308161319 From wkemper at openjdk.org Thu Sep 18 16:08:34 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 18 Sep 2025 16:08:34 GMT Subject: RFR: 8367450: Shenandoah: Log the composition of the collection set [v6] In-Reply-To: References: Message-ID: > Reuse the same log message from GenShen which details the composition of the live data to be evacuated. In the non-generational modes, all regions are considered young and nothing will be promoted (or old). William Kemper has updated the pull request incrementally with one additional commit since the last revision: Improve documentation for methods touched in this change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27235/files - new: https://git.openjdk.org/jdk/pull/27235/files/aeb6b39e..e0854ecb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27235&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27235&range=04-05 Stats: 11 lines in 2 files changed: 9 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27235.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27235/head:pull/27235 PR: https://git.openjdk.org/jdk/pull/27235 From kdnilsen at openjdk.org Thu Sep 18 16:10:18 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 18 Sep 2025 16:10:18 GMT Subject: Integrated: 8367708: GenShen: Reduce total evacuation burden In-Reply-To: References: Message-ID: <191jY5pbuFDtyevG-1yhD8ZUQhBxuHMoHiv74IRFwxg=.de5794ab-6c66-454c-a651-d3f83fd1dc1e@github.com> On Mon, 15 Sep 2025 04:44:24 GMT, Kelvin Nilsen wrote: > This PR provides several improvements that cumulatively reduce the amount of evacuation performed by GenShen compared to traditional Shenandoah. Specifically: > > 1. Do not promote humongous arrays of primitive data. Leaving these regions in the young generation allows them to be reclaimed more quickly when they become garbage. There is no disadvantage to leaving these regions in the young generation as their contents does not need to be scanned by the garbage collector. > 2. Change the default value of ShenandoahOldGarbageThreshold from 15% to 25%. This results in smaller sets of candidate regions for mixed evacuation, less aggressive compaction of old generation. This also increases the likelihood that a region will be promoted in place instead of promoted by evacuation. > 3. Only promote regions in place if the used within a region exceeds ShenandoahGenerationalMinPIPUsage (default 30) percent of the heap region size. This is enforced in combination with the preexisting requirement that the garbage within the region be less than ShenandoahOldGarbageThreshold (new default 25) percent of the heap region size. This causes regions with very low utilization to be promoted by evacuation rather than promoted in place. While the immediate effect of this change is to perform more copying when the region is promoted, the secondary effect is that this region does not need to be evacuated at a later time, after it has accumulated more live data, as part of an effort to defragment old-gen memory. > 4. Only defragment old-gen memory if the command-line has requested non-zero reserves for humongous objects (ShenandoahGenerationalHumongousReserves). Previously, we would invest in defragmenting old-gen memory every time we finished old-generation marking, even if ShenandoahGenerationalHumongousReserves equals zero. This pull request has now been integrated. Changeset: c597384a Author: Kelvin Nilsen URL: https://git.openjdk.org/jdk/commit/c597384ad64c7107fba4e970aa435a141276b2fd Stats: 30 lines in 4 files changed: 22 ins; 2 del; 6 mod 8367708: GenShen: Reduce total evacuation burden Reviewed-by: wkemper ------------- PR: https://git.openjdk.org/jdk/pull/27278 From wkemper at openjdk.org Thu Sep 18 16:13:25 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 18 Sep 2025 16:13:25 GMT Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a runtime diagnostic option [v3] In-Reply-To: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com> References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com> Message-ID: > Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option. William Kemper has updated the pull request incrementally with one additional commit since the last revision: Fix typo in option description ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27238/files - new: https://git.openjdk.org/jdk/pull/27238/files/bbee4ee3..a890cd30 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27238&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27238&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27238.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27238/head:pull/27238 PR: https://git.openjdk.org/jdk/pull/27238 From shade at openjdk.org Thu Sep 18 16:49:16 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 18 Sep 2025 16:49:16 GMT Subject: RFR: 8348278: Trim InitialRAMPercentage to improve startup in default modes [v4] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 06:16:49 GMT, Stefan Johansson wrote: > This adds another argument to something else we discussed yesterday, why is this initial value a fraction of the RAM and not a fraction of the chosen `MaxHeapSize`? We could not come up with a good answer to that, do you see any good reason? Yeah, I also wondered about this, but I could not find any discussion why the heuristics is driven like this. So I am guessing it can be filed into a constantly growing "historical reasons" folder. It makes _some_ sense to drive Xms and Xmx separately, so that users who override only Xmx do not get an additional effect on Xms? I.e. so that GC would be in the same initial configuration when running experiments with different Xmx-es, for example. This is the only explanation I can come up with. Anyway, changing the _way_ Xms is selected feels way too much work, given the benefits we are after. This PR does a simple thing of adjusting the already documented ergonomic input and requires no additional code changes on top of that. This is a soft touch that does a minor change to gain minor benefit for IMO non-frequent cases of users skipping any heap configuration. (Use case: showing startup numbers on conference slides :D). If there is a strong preference of overhauling Xms policy itself, it would be a while before I could allocate any reasonable cycles to it, and someone else would probably need to take over. So, I believe we should do this trimming, since some init work is unavoidable, and then spend extra free time on actual improvements in GC initialization sequences that make startup faster in cases when users _do_ supply Xms :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23262#issuecomment-3308513014 From kirk at kodewerk.com Thu Sep 18 16:51:58 2025 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Thu, 18 Sep 2025 09:51:58 -0700 Subject: RFR: 8350596: [Linux] Increase default MaxRAMPercentage for containerized workloads In-Reply-To: <1S38JYoE4Gclx8Cv0NOWFjFWgTj_4q2eqG4rhaZ2k1M=.024810d5-5829-475d-8526-5c99fded9466@github.com> References: <1S38JYoE4Gclx8Cv0NOWFjFWgTj_4q2eqG4rhaZ2k1M=.024810d5-5829-475d-8526-5c99fded9466@github.com> Message-ID: <34CF9C0B-5D79-40D9-AC37-4760C601558F@kodewerk.com> Hi all, I have to strongly agree with Erik on this point. Going from one ?guess? to another doesn?t seem like a good solution to this question. We have deep experience with the current ?guess?. Much of what we have has been built around this ?guess?. To change this ?guess? to another ?guess? risks breaking everything that has been built on the previous guess. One of the confusions that I?ve seen and have tried to educate towards a better understanding is the difference between virtual and real memory (address spaces). The risk here is that if you give Java heap a new default setting then you will be committing more real memory and this will have an impact on those relying of defaults in that they will immediately need more real memory because if you give Java heap more memory, it will use it. If you want to OOM a significant number of apps that are relying on defaults, then a great way to do this is to change the default to a larger value. Kind regards, Kirk > On Sep 18, 2025, at 2:03?AM, Erik ?sterlund wrote: > > On Wed, 7 May 2025 09:29:16 GMT, Severin Gehwolf wrote: > >> Please take a look at this proposal to fix the "Java needs so much memory" perception in containers. The idea would be to bump the default `MaxRAMPercentage` to a higher value. The patch proposes 75%, but we could just as well use 50% if people feel more comfortable about it. Right now the default deployment in containers with resource limits in place (common for Kubernetes deployments) where a single process runs in the container isn't well catered for today for an application that just uses the default configuration. Only 25% of the container memory will be used for the Java heap, arguably wasting much of the remaining memory that has been granted to the container by a memory limit (that the JVM would detect and use as physical memory). >> >> I've filed a CSR for this as well for which I'm looking for reviewers too and intend to write a release note as well about this change as it has some risk associated with it, although the escape hatch is pretty simple: set `-XX:MaxRAMPercentage=25.0` to go back to the old behavour. >> >> Testing: >> - [x] GHA - tier 1 (windows failures seem infra related) >> - [x] hotspot and jdk container tests on cg v2 and cg v1 including the two new tests. >> >> Thoughts? Opinions? > > The question how much heap memory an arbitrary Java program needs to run is in many ways similar to the halting problem of answering how much time a Java program needs to run. There is no great answer. 25% was a wild guess. Sometimes it's okay, sometimes it is awful. There are plenty of situations when it is not at all what you want. But I'm very skeptical against coming up with a new wild guess hoping to improve performance, while risking getting killed. In a 512 MB container, 25% might be too small and you really want to use 75% to get better performance, except when direct mapped byte buffers use too much memory. But in a 128 MB container, 75% might be too much as the JIT compiled code and meatspace might need more than 32 MB. > > I think trying to find a good answer to how much heap a Java should use without running it is hopeless, and don't feel thrilled about changing the guesses from one bad guess to another bad guess, rather than having a more complete way of reasoning about *why* a limit is too high or too low, and adapting accordingly at runtime. > > When these sort of proposals started popping up, I started working on automatic heap sizing instead so that we would be able to recognize that there is actually no static limit if the user hasn't said so, but we can deal with that without exhausting memory with some clever policies. Now there is a JEP for both ZGC (cf. https://openjdk.org/jeps/8329758) and G1 (cf. https://openjdk.org/jeps/8359211) to do automatic heap sizing. Given their arrival, do we still need to mess around with these guesses? If not, then I think changing from one bad guess to another bad guess might just introduce risk. I'd prefer to let automatic heap sizing solve this better instead. > > ------------- > > PR Comment: https://git.openjdk.org/jdk/pull/25086#issuecomment-3306363643 From phh at openjdk.org Thu Sep 18 17:01:50 2025 From: phh at openjdk.org (Paul Hohensee) Date: Thu, 18 Sep 2025 17:01:50 GMT Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a runtime diagnostic option [v3] In-Reply-To: References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com> Message-ID: On Thu, 18 Sep 2025 16:13:25 GMT, William Kemper wrote: >> Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option. > > William Kemper has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo in option description Marked as reviewed by phh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27238#pullrequestreview-3240997697 From fandreuzzi at openjdk.org Thu Sep 18 17:08:34 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 18 Sep 2025 17:08:34 GMT Subject: RFR: 8367626: Parallel: Remove ParallelCompactData::summarize_dense_prefix In-Reply-To: <4C7vmePNpSeo7KXiLiSJUWTgOXBbq-dqgZtBvD6p9WQ=.7de375d3-0f3d-4163-857c-27f004643184@github.com> References: <4C7vmePNpSeo7KXiLiSJUWTgOXBbq-dqgZtBvD6p9WQ=.7de375d3-0f3d-4163-857c-27f004643184@github.com> Message-ID: On Mon, 15 Sep 2025 08:22:40 GMT, Albert Mingkun Yang wrote: > Remove the unnecessary summary operation on dense-prefix, because the summary operation is only needed for compaction, but dense-prefix doesn't participate in compaction. > > Test: tier1-5 Marked as reviewed by fandreuzzi (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/27286#pullrequestreview-3241029529 From fandreuzzi at openjdk.org Thu Sep 18 17:12:23 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 18 Sep 2025 17:12:23 GMT Subject: RFR: 8367626: Parallel: Remove ParallelCompactData::summarize_dense_prefix In-Reply-To: <4C7vmePNpSeo7KXiLiSJUWTgOXBbq-dqgZtBvD6p9WQ=.7de375d3-0f3d-4163-857c-27f004643184@github.com> References: <4C7vmePNpSeo7KXiLiSJUWTgOXBbq-dqgZtBvD6p9WQ=.7de375d3-0f3d-4163-857c-27f004643184@github.com> Message-ID: On Mon, 15 Sep 2025 08:22:40 GMT, Albert Mingkun Yang wrote: > Remove the unnecessary summary operation on dense-prefix, because the summary operation is only needed for compaction, but dense-prefix doesn't participate in compaction. > > Test: tier1-5 src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1516: > 1514: > 1515: #ifdef ASSERT > 1516: void PSParallelCompact::verify_forward() { Could this method become `const` now? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27286#discussion_r2360358886 From wkemper at openjdk.org Thu Sep 18 17:20:01 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 18 Sep 2025 17:20:01 GMT Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a runtime diagnostic option [v4] In-Reply-To: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com> References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com> Message-ID: > Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option. William Kemper has updated the pull request incrementally with one additional commit since the last revision: Only print region age tables in generational mode ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27238/files - new: https://git.openjdk.org/jdk/pull/27238/files/a890cd30..0e1446de Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27238&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27238&range=02-03 Stats: 13 lines in 1 file changed: 4 ins; 3 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27238.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27238/head:pull/27238 PR: https://git.openjdk.org/jdk/pull/27238 From ayang at openjdk.org Thu Sep 18 17:20:16 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 18 Sep 2025 17:20:16 GMT Subject: RFR: 8367626: Parallel: Remove ParallelCompactData::summarize_dense_prefix In-Reply-To: References: <4C7vmePNpSeo7KXiLiSJUWTgOXBbq-dqgZtBvD6p9WQ=.7de375d3-0f3d-4163-857c-27f004643184@github.com> Message-ID: On Thu, 18 Sep 2025 17:10:05 GMT, Francesco Andreuzzi wrote: >> Remove the unnecessary summary operation on dense-prefix, because the summary operation is only needed for compaction, but dense-prefix doesn't participate in compaction. >> >> Test: tier1-5 > > src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1516: > >> 1514: >> 1515: #ifdef ASSERT >> 1516: void PSParallelCompact::verify_forward() { > > Could this method become `const` now? It's a `static` method; `const` is only for non-static ones. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27286#discussion_r2360380852 From fandreuzzi at openjdk.org Thu Sep 18 17:20:17 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 18 Sep 2025 17:20:17 GMT Subject: RFR: 8367626: Parallel: Remove ParallelCompactData::summarize_dense_prefix In-Reply-To: References: <4C7vmePNpSeo7KXiLiSJUWTgOXBbq-dqgZtBvD6p9WQ=.7de375d3-0f3d-4163-857c-27f004643184@github.com> Message-ID: <8Ucz7DLpkqv8cLosjPfS0mZwUodQ9c0pPPZ3TWoLXZs=.c4edaa9d-2b53-4dc8-a73e-a279376f8cd9@github.com> On Thu, 18 Sep 2025 17:15:39 GMT, Albert Mingkun Yang wrote: >> src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1516: >> >>> 1514: >>> 1515: #ifdef ASSERT >>> 1516: void PSParallelCompact::verify_forward() { >> >> Could this method become `const` now? > > It's a `static` method; `const` is only for non-static ones. Right, missed it. Thanks for the clarification. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27286#discussion_r2360385996 From sgehwolf at openjdk.org Thu Sep 18 17:26:24 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 18 Sep 2025 17:26:24 GMT Subject: RFR: 8350596: [Linux] Increase default MaxRAMPercentage for containerized workloads In-Reply-To: <1S38JYoE4Gclx8Cv0NOWFjFWgTj_4q2eqG4rhaZ2k1M=.024810d5-5829-475d-8526-5c99fded9466@github.com> References: <1S38JYoE4Gclx8Cv0NOWFjFWgTj_4q2eqG4rhaZ2k1M=.024810d5-5829-475d-8526-5c99fded9466@github.com> Message-ID: On Thu, 18 Sep 2025 09:00:23 GMT, Erik ?sterlund wrote: > The question how much heap memory an arbitrary Java program needs to run is in many ways similar to the halting problem of answering how much time a Java program needs to run. There is no great answer. Agreed. Nevertheless there is a problem worth solving: Improve the memory *utilization* issue of Java when deploying to the cloud. This isn't a *performance* measure. It should be performance neutral. The goal would be to improve the memory utilization story in the default config. > 25% was a wild guess. Sometimes it's okay, sometimes it is awful. There are plenty of situations when it is not at all what you want. At the time container deployments with a single process in it weren't a thing. They are now. > But I'm very skeptical against coming up with a new wild guess hoping to improve performance, while risking getting killed. In a 512 MB container, 25% might be too small and you really want to use 75% to get better performance, except when direct mapped byte buffers use too much memory. But in a 128 MB container, 75% might be too much as the JIT compiled code and meatspace might need more than 32 MB. We have more data now, so the default should adjust. Keep in mind that the proposal is to change the `MaxRAMPercentage` value in a fairly specific setup: in a container with a memory limit set on the container level. Since this is changing only `MaxRAMPercentage` it feeds into the heuristics machinery in determining the actual `MaxHeapSize`. I've attached two charts to the bug showing that the `MaxRAMPercentage` bump has no effect on JVMs with 250MB of memory or less. > I think trying to find a good answer to how much heap a Java should use without running it is hopeless, and don't feel thrilled about changing the guesses from one bad guess to another bad guess, rather than having a more complete way of reasoning about _why_ a limit is too high or too low, and adapting accordingly at runtime. Hopeless seems a stretch. I'm arguing we have more data (today) and we need to think about how to slowly adjust the defaults to the new normal. > When these sort of proposals started popping up, I started working on automatic heap sizing instead so that we would be able to recognize that there is actually no static limit if the user hasn't said so, but we can deal with that without exhausting memory with some clever policies. Now there is a JEP for both ZGC (cf. https://openjdk.org/jeps/8329758) and G1 (cf. https://openjdk.org/jeps/8359211) to do automatic heap sizing. Given their arrival, do we still need to mess around with these guesses? I think so. While those JEP drafts are really heading in the right direction, it doesn't solve the problem for the rest of the GCs. Keep in mind that for many small deployments, say 1 core, you'd get Serial GC, not solving the problem there. > If not, then I think changing from one bad guess to another bad guess might just introduce risk. I'd prefer to let automatic heap sizing solve this better instead. I agree that automatic heap sizing should solve this problem. But it needs to do so for all cases. Also, it's not clear when those JEPs will be widely available. Until that's the case we should try to adjust defaults to the changed reality to ease some of this pain. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25086#issuecomment-3308676336 From ayang at openjdk.org Thu Sep 18 17:26:38 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 18 Sep 2025 17:26:38 GMT Subject: RFR: 8367626: Parallel: Remove ParallelCompactData::summarize_dense_prefix In-Reply-To: <4C7vmePNpSeo7KXiLiSJUWTgOXBbq-dqgZtBvD6p9WQ=.7de375d3-0f3d-4163-857c-27f004643184@github.com> References: <4C7vmePNpSeo7KXiLiSJUWTgOXBbq-dqgZtBvD6p9WQ=.7de375d3-0f3d-4163-857c-27f004643184@github.com> Message-ID: On Mon, 15 Sep 2025 08:22:40 GMT, Albert Mingkun Yang wrote: > Remove the unnecessary summary operation on dense-prefix, because the summary operation is only needed for compaction, but dense-prefix doesn't participate in compaction. > > Test: tier1-5 Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27286#issuecomment-3308665251 From ayang at openjdk.org Thu Sep 18 17:26:39 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 18 Sep 2025 17:26:39 GMT Subject: Integrated: 8367626: Parallel: Remove ParallelCompactData::summarize_dense_prefix In-Reply-To: <4C7vmePNpSeo7KXiLiSJUWTgOXBbq-dqgZtBvD6p9WQ=.7de375d3-0f3d-4163-857c-27f004643184@github.com> References: <4C7vmePNpSeo7KXiLiSJUWTgOXBbq-dqgZtBvD6p9WQ=.7de375d3-0f3d-4163-857c-27f004643184@github.com> Message-ID: <9kIZ-eryXDkKIfouaO6fSPa4i76J3_A5SfPHTg0zxOY=.a9994bd1-8ec6-41a2-8b10-9423a60747d2@github.com> On Mon, 15 Sep 2025 08:22:40 GMT, Albert Mingkun Yang wrote: > Remove the unnecessary summary operation on dense-prefix, because the summary operation is only needed for compaction, but dense-prefix doesn't participate in compaction. > > Test: tier1-5 This pull request has now been integrated. Changeset: 14b9f53b Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/14b9f53bb376c49b73b376c6e5a4b30105358b5a Stats: 36 lines in 2 files changed: 1 ins; 31 del; 4 mod 8367626: Parallel: Remove ParallelCompactData::summarize_dense_prefix Reviewed-by: gli, fandreuzzi ------------- PR: https://git.openjdk.org/jdk/pull/27286 From wkemper at openjdk.org Thu Sep 18 17:31:19 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 18 Sep 2025 17:31:19 GMT Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a runtime diagnostic option [v5] In-Reply-To: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com> References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com> Message-ID: > Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option. William Kemper has updated the pull request incrementally with one additional commit since the last revision: Only print promotion/old evacuation metrics in generational mode ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27238/files - new: https://git.openjdk.org/jdk/pull/27238/files/0e1446de..0ab56c91 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27238&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27238&range=03-04 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27238.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27238/head:pull/27238 PR: https://git.openjdk.org/jdk/pull/27238 From wkemper at openjdk.org Thu Sep 18 17:36:31 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 18 Sep 2025 17:36:31 GMT Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a runtime diagnostic option [v5] In-Reply-To: References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com> Message-ID: On Thu, 18 Sep 2025 17:31:19 GMT, William Kemper wrote: >> Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option. > > William Kemper has updated the pull request incrementally with one additional commit since the last revision: > > Only print promotion/old evacuation metrics in generational mode When the diagnostic option is disabled there is no additional output in the logs. When the option is enabled, we'll see a break down of which type of evacuations were performed by which threads: [2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats ] Workers: [2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats ] Young: Evacuated 8469K across 122601 objects, abandoned 1840B across 23 objects. [2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats ] Promotion: Evacuated 0B across 0 objects, abandoned 0B across 0 objects. [2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats ] Old: Evacuated 0B across 0 objects, abandoned 0B across 0 objects. [2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats ] [2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats ] Mutators: [2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats ] Young: Evacuated 845K across 10247 objects, abandoned 803K across 7852 objects. [2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats ] Promotion: Evacuated 0B across 0 objects, abandoned 0B across 0 objects. [2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats ] Old: Evacuated 0B across 0 objects, abandoned 0B across 0 objects. When the option is enabled in single-gen mode, we will see only evacuation data for young regions (there are no promotions or old evacuations in this mode): [2025-09-18T17:30:04.246+0000][3.663s][20861][info][gc,stats ] Workers: [2025-09-18T17:30:04.246+0000][3.663s][20861][info][gc,stats ] Young: Evacuated 5555K across 122874 objects, abandoned 0B across 0 objects. [2025-09-18T17:30:04.246+0000][3.663s][20861][info][gc,stats ] [2025-09-18T17:30:04.246+0000][3.663s][20861][info][gc,stats ] Mutators: [2025-09-18T17:30:04.246+0000][3.663s][20861][info][gc,stats ] Young: Evacuated 408K across 320 objects, abandoned 0B across 0 objects. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27238#issuecomment-3308722358 From wkemper at openjdk.org Thu Sep 18 17:36:35 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 18 Sep 2025 17:36:35 GMT Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a runtime diagnostic option [v2] In-Reply-To: <-S5kGwanp5G--dEw5uQBPRFlnSO9l6yyyXGOdQKAwd8=.f891358d-5e2d-4677-bf00-e97a146e1b05@github.com> References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com> <-S5kGwanp5G--dEw5uQBPRFlnSO9l6yyyXGOdQKAwd8=.f891358d-5e2d-4677-bf00-e97a146e1b05@github.com> Message-ID: On Thu, 18 Sep 2025 00:57:39 GMT, Y. Srinivas Ramakrishna wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge remote-tracking branch 'jdk/master' into make-evac-tracking-runtime-option >> - Only print evacuation info when evac tracking is enabled (generational mode fix) >> - Make detailed evacuation tracking a diagnostic option in product builds > > src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 399: > >> 397: product(bool, ShenandoahEvacTracking, false, DIAGNOSTIC, \ >> 398: "Collect additional metrics about evacuations. Enabling this " \ >> 399: "track how many objects and how many bytes were evacuated, and " \ > > Nit: track -> tracks? > Or may be simply say: "Track additional, more detailed metrics related to evacuations by mutators and GC workers." and elide the first sentence" "Collect additional ..."? I just fixed the typo. The following sentence explains in some detail what will be tracked and how it will be reported. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27238#discussion_r2360453664 From ayang at openjdk.org Thu Sep 18 18:08:02 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 18 Sep 2025 18:08:02 GMT Subject: RFR: 8368006: Parallel: Skip full regions in dense prefix during Full GC Message-ID: Implement skip-full-region optimization for filler related operations on dense-prefix. I constrained the filler-creation task to a single worker for simpler implementation. During the compaction phase, the most expensive part is almost always the non-dense-prefix part, so letting the rest of workers to start with the expensive tasks seems sensible. Synthetic bms shows good reduction in full-gc time in debug build; perf-neutral for other bms (specjvm2008,specjbb2015) in release build. Test: tier1-5 ------------- Commit messages: - pgc-skip-full-region Changes: https://git.openjdk.org/jdk/pull/27369/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27369&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368006 Stats: 91 lines in 1 file changed: 40 ins; 23 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/27369.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27369/head:pull/27369 PR: https://git.openjdk.org/jdk/pull/27369 From ysr at openjdk.org Thu Sep 18 18:28:57 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Thu, 18 Sep 2025 18:28:57 GMT Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a runtime diagnostic option [v5] In-Reply-To: References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com> Message-ID: On Thu, 18 Sep 2025 17:31:19 GMT, William Kemper wrote: >> Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option. > > William Kemper has updated the pull request incrementally with one additional commit since the last revision: > > Only print promotion/old evacuation metrics in generational mode Marked as reviewed by ysr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27238#pullrequestreview-3241395957 From ysr at openjdk.org Thu Sep 18 18:28:58 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Thu, 18 Sep 2025 18:28:58 GMT Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a runtime diagnostic option [v5] In-Reply-To: References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com> Message-ID: On Thu, 18 Sep 2025 17:33:10 GMT, William Kemper wrote: > When the diagnostic option is disabled there is no additional output in the logs. When the option is enabled, we'll see a break down of which type of evacuations were performed by which threads: > > ``` > [2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats ] Workers: > [2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats ] Young: Evacuated 8469K across 122601 objects, abandoned 1840B across 23 objects. > [2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats ] Promotion: Evacuated 0B across 0 objects, abandoned 0B across 0 objects. > [2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats ] Old: Evacuated 0B across 0 objects, abandoned 0B across 0 objects. > [2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats ] > [2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats ] Mutators: > [2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats ] Young: Evacuated 845K across 10247 objects, abandoned 803K across 7852 objects. > [2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats ] Promotion: Evacuated 0B across 0 objects, abandoned 0B across 0 objects. > [2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats ] Old: Evacuated 0B across 0 objects, abandoned 0B across 0 objects. > ``` > > When the option is enabled in single-gen mode, we will see only evacuation data for young regions (there are no promotions or old evacuations in this mode): > > ``` > [2025-09-18T17:30:04.246+0000][3.663s][20861][info][gc,stats ] Workers: > [2025-09-18T17:30:04.246+0000][3.663s][20861][info][gc,stats ] Young: Evacuated 5555K across 122874 objects, abandoned 0B across 0 objects. > [2025-09-18T17:30:04.246+0000][3.663s][20861][info][gc,stats ] > [2025-09-18T17:30:04.246+0000][3.663s][20861][info][gc,stats ] Mutators: > [2025-09-18T17:30:04.246+0000][3.663s][20861][info][gc,stats ] Young: Evacuated 408K across 320 objects, abandoned 0B across 0 objects. > ``` I don't suppose it's advisable to suppress data that's vacuous (pun not intended :), i.e. where no promotions occur in generational mode? Reviewed and approved. ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27238#issuecomment-3308984129 From ysr at openjdk.org Thu Sep 18 18:28:59 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Thu, 18 Sep 2025 18:28:59 GMT Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a runtime diagnostic option [v5] In-Reply-To: References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com> Message-ID: On Thu, 18 Sep 2025 18:22:53 GMT, Y. Srinivas Ramakrishna wrote: > I don't suppose it's advisable to suppress data that's vacuous (pun not intended :), i.e. where no promotions occur in generational mode? I don't think we should suppress that data. Having it explicitly spelled out at each cycle regardless is less confusing and better for human (and machine) consumption. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27238#issuecomment-3308998116 From ysr at openjdk.org Thu Sep 18 18:40:23 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Thu, 18 Sep 2025 18:40:23 GMT Subject: RFR: 8367450: Shenandoah: Log the composition of the collection set [v6] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 16:08:34 GMT, William Kemper wrote: >> Reuse the same log message from GenShen which details the composition of the live data to be evacuated. In the non-generational modes, all regions are considered young and nothing will be promoted (or old). > > William Kemper has updated the pull request incrementally with one additional commit since the last revision: > > Improve documentation for methods touched in this change Thank you! ? ------------- Marked as reviewed by ysr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27235#pullrequestreview-3241461808 From wkemper at openjdk.org Thu Sep 18 19:06:21 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 18 Sep 2025 19:06:21 GMT Subject: Integrated: 8367450: Shenandoah: Log the composition of the collection set In-Reply-To: References: Message-ID: <-3IsI6mT8huONO3dw_xhyDJ4ak5FjctdN3rbtrIxraI=.16f3ec1d-e496-41e4-b519-55c73697ca5e@github.com> On Thu, 11 Sep 2025 21:40:50 GMT, William Kemper wrote: > Reuse the same log message from GenShen which details the composition of the live data to be evacuated. In the non-generational modes, all regions are considered young and nothing will be promoted (or old). This pull request has now been integrated. Changeset: 4be4826d Author: William Kemper URL: https://git.openjdk.org/jdk/commit/4be4826ddb51c155eec3fe2923d891357f8d753b Stats: 294 lines in 11 files changed: 50 ins; 205 del; 39 mod 8367450: Shenandoah: Log the composition of the collection set Reviewed-by: ysr, kdnilsen, phh ------------- PR: https://git.openjdk.org/jdk/pull/27235 From wkemper at openjdk.org Thu Sep 18 19:24:31 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 18 Sep 2025 19:24:31 GMT Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a runtime diagnostic option [v5] In-Reply-To: References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com> Message-ID: On Thu, 18 Sep 2025 17:31:19 GMT, William Kemper wrote: >> Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option. > > William Kemper has updated the pull request incrementally with one additional commit since the last revision: > > Only print promotion/old evacuation metrics in generational mode It's only suppressed in the non-generational mode, in which case there will _always_ be zero promotions/old evacuations. In the _generational_ mode, it will show the zeros to reinforce the notion that no promotions or old evacuations happened on _this_ cycle. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27238#issuecomment-3309136169 From wkemper at openjdk.org Thu Sep 18 19:24:33 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 18 Sep 2025 19:24:33 GMT Subject: Integrated: 8367473: Shenandoah: Make the detailed evacuation metrics a runtime diagnostic option In-Reply-To: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com> References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com> Message-ID: On Thu, 11 Sep 2025 22:43:23 GMT, William Kemper wrote: > Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option. This pull request has now been integrated. Changeset: e4cb86df Author: William Kemper URL: https://git.openjdk.org/jdk/commit/e4cb86df2b05cef6dd7e29e8803ebbbf5b4fe5a2 Stats: 61 lines in 5 files changed: 27 ins; 7 del; 27 mod 8367473: Shenandoah: Make the detailed evacuation metrics a runtime diagnostic option 8367722: [GenShen] ShenandoahEvacuationStats is always empty Reviewed-by: ysr, phh ------------- PR: https://git.openjdk.org/jdk/pull/27238 From eosterlund at openjdk.org Thu Sep 18 19:25:57 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 18 Sep 2025 19:25:57 GMT Subject: RFR: 8350596: [Linux] Increase default MaxRAMPercentage for containerized workloads In-Reply-To: References: <1S38JYoE4Gclx8Cv0NOWFjFWgTj_4q2eqG4rhaZ2k1M=.024810d5-5829-475d-8526-5c99fded9466@github.com> Message-ID: <9Rn-BfvWiEjwdJb2odC3W-kD4NhAHTXmDXNbFEqFD2I=.8171a0aa-e723-4c33-a533-9df0d6d42db3@github.com> On Thu, 18 Sep 2025 17:23:22 GMT, Severin Gehwolf wrote: > > When these sort of proposals started popping up, I started working on automatic heap sizing instead so that we would be able to recognize that there is actually no static limit if the user hasn't said so, but we can deal with that without exhausting memory with some clever policies. Now there is a JEP for both ZGC (cf. https://openjdk.org/jeps/8329758) and G1 (cf. https://openjdk.org/jeps/8359211) to do automatic heap sizing. Given their arrival, do we still need to mess around with these guesses? > > > > I think so. While those JEP drafts are really heading in the right direction, it doesn't solve the problem for the rest of the GCs. Keep in mind that for many small deployments, say 1 core, you'd get Serial GC, not solving the problem there. This default quirk is fixed with https://openjdk.org/jeps/523 which makes G1 default where Serial is today. > > > > If not, then I think changing from one bad guess to another bad guess might just introduce risk. I'd prefer to let automatic heap sizing solve this better instead. > > > > I agree that automatic heap sizing should solve this problem. But it needs to do so for all cases. Also, it's not clear when those JEPs will be widely available. Until that's the case we should try to adjust defaults to the changed reality to ease some of this pain. They are pretty far along. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25086#issuecomment-3309269956 From wkemper at openjdk.org Thu Sep 18 19:58:56 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 18 Sep 2025 19:58:56 GMT Subject: RFR: 8365792: GenShen: assertion "Generations aren't reconciled" Message-ID: The coalesce-and-fill phase of an old gc cycle may be resumed at any time _without_ running a Shenandoah vm operation. The assertion itself is only meant to run during an operation which changes the active/gc generation. However, the assertion is made in places that may also run concurrently. The original assertion would be enforced if _any_ vm operation were running. For example, the assertions failures in the ticket show Shenandoah concurrently making old regions parsable (this assert should not be enforced) when a heap inspection operation takes a safepoint and (erroneously) causes this assertion to be enforced. ------------- Commit messages: - Only shenandoah vm operations participate in active/gc generation scheme Changes: https://git.openjdk.org/jdk/pull/27373/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27373&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365792 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27373.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27373/head:pull/27373 PR: https://git.openjdk.org/jdk/pull/27373 From xpeng at openjdk.org Thu Sep 18 20:09:00 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Thu, 18 Sep 2025 20:09:00 GMT Subject: RFR: 8365792: GenShen: assertion "Generations aren't reconciled" In-Reply-To: References: Message-ID: <_zxpTPbXNPMjwFXU4FSDwqkLHVQA8qClGEPch0fmXUM=.aa8c731d-fd2e-45a5-a5a8-8abe9b804f8e@github.com> On Thu, 18 Sep 2025 19:06:50 GMT, William Kemper wrote: > The coalesce-and-fill phase of an old gc cycle may be resumed at any time _without_ running a Shenandoah vm operation. The assertion itself is only meant to run during an operation which changes the active/gc generation. However, the assertion is made in places that may also run concurrently. The original assertion would be enforced if _any_ vm operation were running. For example, the assertions failures in the ticket show Shenandoah concurrently making old regions parsable (this assert should not be enforced) when a heap inspection operation takes a safepoint and (erroneously) causes this assertion to be enforced. Thanks, it makes sense. ------------- Marked as reviewed by xpeng (Committer). PR Review: https://git.openjdk.org/jdk/pull/27373#pullrequestreview-3241881071 From ysr at openjdk.org Thu Sep 18 20:50:30 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Thu, 18 Sep 2025 20:50:30 GMT Subject: RFR: 8365792: GenShen: assertion "Generations aren't reconciled" In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 19:06:50 GMT, William Kemper wrote: > The coalesce-and-fill phase of an old gc cycle may be resumed at any time _without_ running a Shenandoah vm operation. The assertion itself is only meant to run during an operation which changes the active/gc generation. However, the assertion is made in places that may also run concurrently. The original assertion would be enforced if _any_ vm operation were running. For example, the assertions failures in the ticket show Shenandoah concurrently making old regions parsable (this assert should not be enforced) when a heap inspection operation takes a safepoint and (erroneously) causes this assertion to be enforced. Very cool; thanks for chasing this down and fixing it. ? ------------- Marked as reviewed by ysr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27373#pullrequestreview-3242071548 From wkemper at openjdk.org Thu Sep 18 21:21:27 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 18 Sep 2025 21:21:27 GMT Subject: Integrated: 8365792: GenShen: assertion "Generations aren't reconciled" In-Reply-To: References: Message-ID: <7PnRe1T2rbyTIAebAWjnrICi3fdHmOwIc3zQgLbs7HQ=.19daed6b-820b-4ab4-9810-470186d5db54@github.com> On Thu, 18 Sep 2025 19:06:50 GMT, William Kemper wrote: > The coalesce-and-fill phase of an old gc cycle may be resumed at any time _without_ running a Shenandoah vm operation. The assertion itself is only meant to run during an operation which changes the active/gc generation. However, the assertion is made in places that may also run concurrently. The original assertion would be enforced if _any_ vm operation were running. For example, the assertions failures in the ticket show Shenandoah concurrently making old regions parsable (this assert should not be enforced) when a heap inspection operation takes a safepoint and (erroneously) causes this assertion to be enforced. This pull request has now been integrated. Changeset: 6e4e966d Author: William Kemper URL: https://git.openjdk.org/jdk/commit/6e4e966d9b71ec04618e19784b5a661f34595ef6 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8365792: GenShen: assertion "Generations aren't reconciled" Reviewed-by: xpeng, ysr ------------- PR: https://git.openjdk.org/jdk/pull/27373 From ysr at openjdk.org Thu Sep 18 22:01:23 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Thu, 18 Sep 2025 22:01:23 GMT Subject: RFR: 8367708: GenShen: Reduce total evacuation burden [v3] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 19:41:47 GMT, Kelvin Nilsen wrote: >> This PR provides several improvements that cumulatively reduce the amount of evacuation performed by GenShen compared to traditional Shenandoah. Specifically: >> >> 1. Do not promote humongous arrays of primitive data. Leaving these regions in the young generation allows them to be reclaimed more quickly when they become garbage. There is no disadvantage to leaving these regions in the young generation as their contents does not need to be scanned by the garbage collector. >> 2. Change the default value of ShenandoahOldGarbageThreshold from 15% to 25%. This results in smaller sets of candidate regions for mixed evacuation, less aggressive compaction of old generation. This also increases the likelihood that a region will be promoted in place instead of promoted by evacuation. >> 3. Only promote regions in place if the used within a region exceeds ShenandoahGenerationalMinPIPUsage (default 30) percent of the heap region size. This is enforced in combination with the preexisting requirement that the garbage within the region be less than ShenandoahOldGarbageThreshold (new default 25) percent of the heap region size. This causes regions with very low utilization to be promoted by evacuation rather than promoted in place. While the immediate effect of this change is to perform more copying when the region is promoted, the secondary effect is that this region does not need to be evacuated at a later time, after it has accumulated more live data, as part of an effort to defragment old-gen memory. >> 4. Only defragment old-gen memory if the command-line has requested non-zero reserves for humongous objects (ShenandoahGenerationalHumongousReserves). Previously, we would invest in defragmenting old-gen memory every time we finished old-generation marking, even if ShenandoahGenerationalHumongousReserves equals zero. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > revert changes to trash_humongous_region_at() src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 37: > 35: constraint) \ > 36: \ > 37: product(uintx, ShenandoahGenerationalMinPIPUsage, 30, EXPERIMENTAL, \ Looking at this quite late, but thought I'd leave these comments here nonetheless. While I agree that copying takes up cycle time and cpu, there is a potential space cost to promoting in place regions with substantial garbage. Why was 30% used (i.e. 70% garbage) considered reasonable? I'd have expected something like 50 or a tad higher used (i.e. less than 50% garbage) to be eligible for PIP. Did higher values not work well for specific benchmarks that were used to pick this threshold? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27278#discussion_r2361276332 From duke at openjdk.org Thu Sep 18 22:09:00 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Thu, 18 Sep 2025 22:09:00 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v7] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 13:28:52 GMT, Ivan Walulya wrote: >> Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. >> >> Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. >> >> Testing: Tier 1-7 > > Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: > > - make universal > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - Revert > - Thomas Review > - return on timeout > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - timed wait > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - ... and 5 more: https://git.openjdk.org/jdk/compare/4c7c009d...1a53c207 src/hotspot/share/memory/universe.hpp line 132: > 130: > 131: // Shutdown > 132: static volatile bool _is_shutting_down; If `_is_shutting_down` is in Universe, should ZGC/ZAbort hook into this too? It could be confusing that ZAbort reports that we are shutting down but the universe field does not report this. I would expect them both to report true. src/hotspot/share/services/cpuTimeUsage.cpp line 39: > 37: > 38: static inline jlong thread_cpu_time_or_zero(Thread* thread) { > 39: assert(!thread->has_terminated(), "Cannot get cpu time for terminated thread: %zu", thread->osthread()->thread_id_for_printing()); Are we sure that the thread is never in a de-allocated state here? I discussed adding an assert like that in `os::thread_cpu_time` but @dholmes-ora pointed out that such asserts are in general dangerous as the they may have been dealloacted and the assert itself could result in a segmentation fault. That being said, maybe we know that all threads we could possibly poke at here in this point could be terminated but not deallocated? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2361277250 PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2361281193 From duke at openjdk.org Thu Sep 18 22:09:02 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Thu, 18 Sep 2025 22:09:02 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v7] In-Reply-To: References: Message-ID: <2YPWvn-XmFS-P4PggP5HsRRStVRfa-l_UDeIbICRAMw=.0b3254fb-4e5c-4fd7-b7f1-00779fe75dd5@github.com> On Thu, 18 Sep 2025 22:01:23 GMT, Jonas Norlinder wrote: >> Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: >> >> - make universal >> - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs >> - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs >> - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs >> - Revert >> - Thomas Review >> - return on timeout >> - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs >> - timed wait >> - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs >> - ... and 5 more: https://git.openjdk.org/jdk/compare/4c7c009d...1a53c207 > > src/hotspot/share/services/cpuTimeUsage.cpp line 39: > >> 37: >> 38: static inline jlong thread_cpu_time_or_zero(Thread* thread) { >> 39: assert(!thread->has_terminated(), "Cannot get cpu time for terminated thread: %zu", thread->osthread()->thread_id_for_printing()); > > Are we sure that the thread is never in a de-allocated state here? I discussed adding an assert like that in `os::thread_cpu_time` but @dholmes-ora pointed out that such asserts are in general dangerous as the they may have been dealloacted and the assert itself could result in a segmentation fault. That being said, maybe we know that all threads we could possibly poke at here in this point could be terminated but not deallocated? The assert I had in mind was to check `_is_shutting_down` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2361287062 From dholmes at openjdk.org Fri Sep 19 05:02:18 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Sep 2025 05:02:18 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v6] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 09:04:53 GMT, Albert Mingkun Yang wrote: > > Though I still wonder if this aspect of shutdown should be part of "Heap" (or Universe) rather than G1 specific. > > Why is it G1 specific? The new `bool _is_shutting_down` lives inside `CollectedHeap` -- Serial/Parallel/G1 are all updated to use it. My mistake, I didn't track the changes enough and was just looking at all the G1 files involved. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27190#issuecomment-3310561420 From dholmes at openjdk.org Fri Sep 19 05:02:20 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Sep 2025 05:02:20 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v7] In-Reply-To: <2YPWvn-XmFS-P4PggP5HsRRStVRfa-l_UDeIbICRAMw=.0b3254fb-4e5c-4fd7-b7f1-00779fe75dd5@github.com> References: <2YPWvn-XmFS-P4PggP5HsRRStVRfa-l_UDeIbICRAMw=.0b3254fb-4e5c-4fd7-b7f1-00779fe75dd5@github.com> Message-ID: On Thu, 18 Sep 2025 22:05:59 GMT, Jonas Norlinder wrote: >> src/hotspot/share/services/cpuTimeUsage.cpp line 39: >> >>> 37: >>> 38: static inline jlong thread_cpu_time_or_zero(Thread* thread) { >>> 39: assert(!thread->has_terminated(), "Cannot get cpu time for terminated thread: %zu", thread->osthread()->thread_id_for_printing()); >> >> Are we sure that the thread is never in a de-allocated state here? I discussed adding an assert like that in `os::thread_cpu_time` but @dholmes-ora pointed out that such asserts are in general dangerous as the they may have been dealloacted and the assert itself could result in a segmentation fault. That being said, maybe we know that all threads we could possibly poke at here in this point could be terminated but not deallocated? > > The assert I had in mind was to check `_is_shutting_down` To be clear, unless you have done something to ensure a terminated thread cannot progress to deallocated, then you cannot safely query if it may be terminated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2361769389 From iwalulya at openjdk.org Fri Sep 19 05:10:22 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Fri, 19 Sep 2025 05:10:22 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v7] In-Reply-To: <2YPWvn-XmFS-P4PggP5HsRRStVRfa-l_UDeIbICRAMw=.0b3254fb-4e5c-4fd7-b7f1-00779fe75dd5@github.com> References: <2YPWvn-XmFS-P4PggP5HsRRStVRfa-l_UDeIbICRAMw=.0b3254fb-4e5c-4fd7-b7f1-00779fe75dd5@github.com> Message-ID: <1a-5AHawGFCl1Zab3YmkwEzUj8MuCq9DR-ma30usfsI=.7007a34d-9abb-469b-b40a-091217102a08@github.com> On Thu, 18 Sep 2025 22:05:59 GMT, Jonas Norlinder wrote: >> src/hotspot/share/services/cpuTimeUsage.cpp line 39: >> >>> 37: >>> 38: static inline jlong thread_cpu_time_or_zero(Thread* thread) { >>> 39: assert(!thread->has_terminated(), "Cannot get cpu time for terminated thread: %zu", thread->osthread()->thread_id_for_printing()); >> >> Are we sure that the thread is never in a de-allocated state here? I discussed adding an assert like that in `os::thread_cpu_time` but @dholmes-ora pointed out that such asserts are in general dangerous as the they may have been dealloacted and the assert itself could result in a segmentation fault. That being said, maybe we know that all threads we could possibly poke at here in this point could be terminated but not deallocated? > > The assert I had in mind was to check `_is_shutting_down` Thanks @JonasNorlinder and @dholmes-ora for pointing this out, I will use `_is_shutting_down` as suggested. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2361783277 From iwalulya at openjdk.org Fri Sep 19 05:17:23 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Fri, 19 Sep 2025 05:17:23 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v8] In-Reply-To: References: Message-ID: > Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. > > Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. > > Testing: Tier 1-7 Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: remove assert ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27190/files - new: https://git.openjdk.org/jdk/pull/27190/files/1a53c207..46add7af Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27190&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27190&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27190.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27190/head:pull/27190 PR: https://git.openjdk.org/jdk/pull/27190 From tschatzl at openjdk.org Fri Sep 19 07:16:15 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 19 Sep 2025 07:16:15 GMT Subject: RFR: 8285984: G1: Use standard idiom for inlined payload in G1MonotonicArena::Segment [v3] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 13:54:17 GMT, Leo Korinth wrote: >> This change remove the old padding (extremely big, especially on x86-64), and replaces it with a guaranteed 8 byte alignment. It also removes the `_bottom` field and instead adds a `payload` method. I statically assert that Segment is 8 byte aligned. I then runtime assert that Segment is constructed on 8 byte aligned memory. I also assert that the Slot alignment is less than or equal to the Segment alignment. >> >> I am running tier 1-3 at the moment. Do you think I should run some specific performance test on this? > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup after comments from Axel. > > Rename SegmentAlignment -> SegmentPayloadMaxAlignment. > > Transform alignment assert to use percent operator (will ensure slot > alignment is both less than segment alignment AND that segment > alignment is a multiple of slot alignment) Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27258#pullrequestreview-3243518386 From tschatzl at openjdk.org Fri Sep 19 07:22:28 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 19 Sep 2025 07:22:28 GMT Subject: RFR: 8367298: ZGC: Enhance zaddress type system's assert messages [v2] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 05:18:14 GMT, Axel Boldt-Christmas wrote: >> ZGC uses a family of strongly type integral types to test and verify invariants for addresses, offset, indices and colored pointers within the heap. It is usually the first place we hit an assert if something goes wrong, and looking at the actual value is often enough to identify if it is memory corruption, a broken color invariant or a mistake in the use of the type system. >> >> Unfortunately not all asserts print the value in the assert message, requiring more extensive investigation to even identify the nature of the problem. >> >> I propose we enhance all our zaddress assert printing to always include the invariant breaking value. >> >> _While I chose to print the max values in the assert message of the offset and indices checks, I did not print the colors in the zpointer checks. Both colors and the max values are easily available in the error report, so it would only really be a problem if a hs_err file is missing._ >> >> We should probably also see if we can enhance all the rest of our asserts in ZGC similarly. I do not think I have ever seen a failed invariant check and thought "Why are we printing the invariant breaking value", but often feel that it is unfortunate that we did not print the actual value. > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/share/gc/z/zAddress.inline.hpp > > Co-authored-by: Stefan Karlsson Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27184#pullrequestreview-3243533083 From tschatzl at openjdk.org Fri Sep 19 07:24:49 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 19 Sep 2025 07:24:49 GMT Subject: RFR: 8367848: Parallel: Use NMethodToOopClosure during Young GC [v3] In-Reply-To: References: <1junjLjTWzIsXHpwN7aXUvGSrRafJPP-LBUA3ZsQnDM=.21c925ae-d5b6-486b-be19-33fbe865b994@github.com> Message-ID: On Thu, 18 Sep 2025 09:04:27 GMT, Albert Mingkun Yang wrote: >> Replace `MarkingNMethodClosure` with `NMethodToOopClosure` during young-gc. After that, a new local `ThreadsClaimTokenScope` is introduced instead of `StrongRootsScope` to make the thread-claim-token logic visible in the current context. >> >> Test: tier1-3 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27336#pullrequestreview-3243540019 From ayang at openjdk.org Fri Sep 19 07:37:03 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 19 Sep 2025 07:37:03 GMT Subject: RFR: 8367731: G1: Make G1CollectionSet manage the young gen cset group In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 10:15:55 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that lets the collection set manage the young cset candidate group directly. Currently everywhere the collection set (not "containing" the young cset candidate group) is used, we immediately do the same thing for the young gen candidate group in the same place. > > This makes it kind of natural to put together (and the `G1CollectionSet` already manages adding new regions to the young gen cset group anyway, so that split in responsibility is questionable anyway). > > Testing: gha > > Thanks, > Thomas A minor issue but up to you. src/hotspot/share/gc/g1/g1CollectionSet.cpp line 103: > 101: > 102: void G1CollectionSet::abandon() { > 103: _g1h->young_regions_cset_group()->clear(true /* uninstall_cset_group */); It's a bit odd that `CollectionSet` doesn't have direct access to `cset_group` and have to go through heap. ------------- Marked as reviewed by ayang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27312#pullrequestreview-3243581067 PR Review Comment: https://git.openjdk.org/jdk/pull/27312#discussion_r2362048509 From tschatzl at openjdk.org Fri Sep 19 07:40:09 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 19 Sep 2025 07:40:09 GMT Subject: RFR: 8367754: G1: Add a fast path in heap resize related method [v3] In-Reply-To: <26wTFQP7L9lpuQahVHl17nukhLB4KFDH3Njti5tZhTs=.8ec65369-82c2-4d53-92ff-66dcc7bfaf6e@github.com> References: <26wTFQP7L9lpuQahVHl17nukhLB4KFDH3Njti5tZhTs=.8ec65369-82c2-4d53-92ff-66dcc7bfaf6e@github.com> Message-ID: On Thu, 18 Sep 2025 03:32:16 GMT, Guanqiang Han wrote: >> Please review this change. >> >> **Description:** >> >> It's common for some Java application engineers to configure the heap with the same minimum and maximum size in order to avoid the overhead of heap resizing.In such cases no expansion or shrinkage is possible, so i think we can adds a fast path at the beginning of the method to detect when the heap?s min and max capacities are equal and return early, thereby avoiding unnecessary computation. >> I added a check to determine whether MinHeapSize and MaxHeapSize are equal before performing the heap resize calculation. Since both MaxHeapSize and MinHeapSize are aligned to HeapAlignment, so i think comparing them directly is good. >> >> **Test:** >> >> GHA > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > Update TestHeapResizeAfterGC.java > > correct format error Changes requested by tschatzl (Reviewer). src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 894: > 892: // cannot expand or shrink. > 893: if (is_fixed_size_heap()) { > 894: log_debug(gc, ergo, heap)("Skip heap resize after full collection."); The comment should explain why we skip too. I.e. `Skip heap resize after full collection because heap size is fixed` or so. src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 1062: > 1060: // thus cannot expand or shrink. > 1061: bool _fixed_size_heap; > 1062: I prefer to not use an additional local - repeating the comparison is never significant enough to slow down performance imo, and both `MinHeapSize` and `MaxHeapSize` can not change. test/hotspot/jtreg/gc/g1/TestHeapResizeAfterGC.java line 26: > 24: /* @test > 25: * @bug 8367754 > 26: * @summary Verify fast path before performing heap resize. Suggestion: * @summary Verify fast path before performing heap resize if the command line options prohibit resizing. ------------- PR Review: https://git.openjdk.org/jdk/pull/27349#pullrequestreview-3243544451 PR Review Comment: https://git.openjdk.org/jdk/pull/27349#discussion_r2362027897 PR Review Comment: https://git.openjdk.org/jdk/pull/27349#discussion_r2362026251 PR Review Comment: https://git.openjdk.org/jdk/pull/27349#discussion_r2362055469 From tschatzl at openjdk.org Fri Sep 19 07:40:10 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 19 Sep 2025 07:40:10 GMT Subject: RFR: 8367754: G1: Add a fast path in heap resize related method [v3] In-Reply-To: References: <26wTFQP7L9lpuQahVHl17nukhLB4KFDH3Njti5tZhTs=.8ec65369-82c2-4d53-92ff-66dcc7bfaf6e@github.com> Message-ID: On Fri, 19 Sep 2025 07:24:13 GMT, Thomas Schatzl wrote: >> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: >> >> Update TestHeapResizeAfterGC.java >> >> correct format error > > src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 894: > >> 892: // cannot expand or shrink. >> 893: if (is_fixed_size_heap()) { >> 894: log_debug(gc, ergo, heap)("Skip heap resize after full collection."); > > The comment should explain why we skip too. I.e. `Skip heap resize after full collection because heap size is fixed` or so. I also think the checks should be placed in `full_collection_resize_amount/young_collection_resize_amount` instead. This is a resizing decision, so just return 0. The early return could (not right now) skip important code (like not setting the heap resize time). Actually not sure if the current code will or will not print garbage in the logs already. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27349#discussion_r2362032222 From ayang at openjdk.org Fri Sep 19 07:42:22 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 19 Sep 2025 07:42:22 GMT Subject: RFR: 8367759: G1: Move G1UpdateRegionLivenessAndSelectForRebuildTask into its own file In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 14:19:41 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to move `G1UpdateRegionLivenessAndSelectForRebuildTask` into a separate file. I would like to merge this class and G1BuildCandidateRegionsTask in the near future because the latter mostly repeats the work of the former anyway, but together (with helper classes) they are quite large (if not large already by themselves). This should help make `g1ConcurrentMark.cpp` a little more manageable. > > There is no change in the code, just moving and fixing includes/adding forwards. > > Testing: local compilation, gha > > Thanks, > Thomas Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27314#pullrequestreview-3243598419 From ayang at openjdk.org Fri Sep 19 07:42:27 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 19 Sep 2025 07:42:27 GMT Subject: RFR: 8367848: Parallel: Use NMethodToOopClosure during Young GC [v3] In-Reply-To: References: <1junjLjTWzIsXHpwN7aXUvGSrRafJPP-LBUA3ZsQnDM=.21c925ae-d5b6-486b-be19-33fbe865b994@github.com> Message-ID: On Thu, 18 Sep 2025 09:04:27 GMT, Albert Mingkun Yang wrote: >> Replace `MarkingNMethodClosure` with `NMethodToOopClosure` during young-gc. After that, a new local `ThreadsClaimTokenScope` is introduced instead of `StrongRootsScope` to make the thread-claim-token logic visible in the current context. >> >> Test: tier1-3 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27336#issuecomment-3311000949 From ayang at openjdk.org Fri Sep 19 07:42:28 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 19 Sep 2025 07:42:28 GMT Subject: Integrated: 8367848: Parallel: Use NMethodToOopClosure during Young GC In-Reply-To: <1junjLjTWzIsXHpwN7aXUvGSrRafJPP-LBUA3ZsQnDM=.21c925ae-d5b6-486b-be19-33fbe865b994@github.com> References: <1junjLjTWzIsXHpwN7aXUvGSrRafJPP-LBUA3ZsQnDM=.21c925ae-d5b6-486b-be19-33fbe865b994@github.com> Message-ID: On Wed, 17 Sep 2025 09:00:22 GMT, Albert Mingkun Yang wrote: > Replace `MarkingNMethodClosure` with `NMethodToOopClosure` during young-gc. After that, a new local `ThreadsClaimTokenScope` is introduced instead of `StrongRootsScope` to make the thread-claim-token logic visible in the current context. > > Test: tier1-3 This pull request has now been integrated. Changeset: 28879d3d Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/28879d3d03ca6e8ea68a6063da349d83310b22ce Stats: 13 lines in 2 files changed: 10 ins; 0 del; 3 mod 8367848: Parallel: Use NMethodToOopClosure during Young GC Reviewed-by: stefank, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/27336 From ayang at openjdk.org Fri Sep 19 09:23:37 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 19 Sep 2025 09:23:37 GMT Subject: RFR: 8368086: G1: Use ThreadsClaimTokenScope in G1CMRemarkTask Message-ID: <5Cfv_IvHP9XylALnSg_uAMfi8TPD6r5Nc4G1Bpc7rjA=.6176dce7-fd51-465b-a846-b797922b5ce7@github.com> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `G1ConcurrentMark::finalize_marking` to be more precise with what is actually needed and why. Test: tier1 ------------- Commit messages: - g1-remark-root Changes: https://git.openjdk.org/jdk/pull/27385/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27385&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368086 Stats: 5 lines in 1 file changed: 2 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27385.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27385/head:pull/27385 PR: https://git.openjdk.org/jdk/pull/27385 From tschatzl at openjdk.org Fri Sep 19 09:34:40 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 19 Sep 2025 09:34:40 GMT Subject: RFR: 8071277: G1: Merge commits and uncommits of contiguous memory Message-ID: Hi all, please review this change to G1 commit/uncommit to merge commit/uncommit calls to the operating system as much as possible. This significantly improves startup performanc Performance results before/after on Zen3 processor for a "HelloWorld" application: $ hyperfine -w 10 -r 10 "baseline/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello" Benchmark 1: baseline/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello Time (mean ? ?): 16.4 ms ? 0.4 ms [User: 11.0 ms, System: 14.4 ms] Range (min ? max): 15.7 ms ? 16.8 ms 10 runs $ hyperfine -w 10 -r 10 "baseline/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello" Benchmark 1: baseline/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello Time (mean ? ?): 24.7 ms ? 0.4 ms [User: 10.7 ms, System: 22.7 ms] Range (min ? max): 24.2 ms ? 25.4 ms 10 runs My reimplementation of JDK-8071277 does show improvements here: $ hyperfine -w 10 -r 10 "changes/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello" Benchmark 1: changes/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello Time (mean ? ?): 15.9 ms ? 0.4 ms [User: 11.9 ms, System: 13.1 ms] Range (min ? max): 15.4 ms ? 16.7 ms 10 runs $ hyperfine -w 10 -r 10 "changes/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello" Benchmark 1: changes/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello Time (mean ? ?): 19.7 ms ? 0.3 ms [User: 11.3 ms, System: 17.4 ms] Range (min ? max): 19.2 ms ? 20.1 ms 10 runs I.e., depending on actually committed heap size (`-Xms`), reduction of startup time by 20% or so in above cases. Testing: tier1-5, gha Thanks, Thomas ------------- Commit messages: - 8071277 Changes: https://git.openjdk.org/jdk/pull/27381/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27381&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8071277 Stats: 87 lines in 3 files changed: 69 ins; 8 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/27381.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27381/head:pull/27381 PR: https://git.openjdk.org/jdk/pull/27381 From sgehwolf at openjdk.org Fri Sep 19 09:45:50 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 19 Sep 2025 09:45:50 GMT Subject: RFR: 8350596: [Linux] Increase default MaxRAMPercentage for containerized workloads In-Reply-To: <9Rn-BfvWiEjwdJb2odC3W-kD4NhAHTXmDXNbFEqFD2I=.8171a0aa-e723-4c33-a533-9df0d6d42db3@github.com> References: <1S38JYoE4Gclx8Cv0NOWFjFWgTj_4q2eqG4rhaZ2k1M=.024810d5-5829-475d-8526-5c99fded9466@github.com> <9Rn-BfvWiEjwdJb2odC3W-kD4NhAHTXmDXNbFEqFD2I=.8171a0aa-e723-4c33-a533-9df0d6d42db3@github.com> Message-ID: On Thu, 18 Sep 2025 19:21:21 GMT, Erik ?sterlund wrote: > This default quirk is fixed with https://openjdk.org/jeps/523 which makes G1 default where Serial is today. Ah ok. I'll withdraw then. Thanks for the additional context on the various JEPs/JEP drafts. Useful. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25086#issuecomment-3311480854 From sgehwolf at openjdk.org Fri Sep 19 09:45:51 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 19 Sep 2025 09:45:51 GMT Subject: Withdrawn: 8350596: [Linux] Increase default MaxRAMPercentage for containerized workloads In-Reply-To: References: Message-ID: On Wed, 7 May 2025 09:29:16 GMT, Severin Gehwolf wrote: > Please take a look at this proposal to fix the "Java needs so much memory" perception in containers. The idea would be to bump the default `MaxRAMPercentage` to a higher value. The patch proposes 75%, but we could just as well use 50% if people feel more comfortable about it. Right now the default deployment in containers with resource limits in place (common for Kubernetes deployments) where a single process runs in the container isn't well catered for today for an application that just uses the default configuration. Only 25% of the container memory will be used for the Java heap, arguably wasting much of the remaining memory that has been granted to the container by a memory limit (that the JVM would detect and use as physical memory). > > I've filed a CSR for this as well for which I'm looking for reviewers too and intend to write a release note as well about this change as it has some risk associated with it, although the escape hatch is pretty simple: set `-XX:MaxRAMPercentage=25.0` to go back to the old behavour. > > Testing: > - [x] GHA - tier 1 (windows failures seem infra related) > - [x] hotspot and jdk container tests on cg v2 and cg v1 including the two new tests. > > Thoughts? Opinions? This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/25086 From tschatzl at openjdk.org Fri Sep 19 10:05:20 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 19 Sep 2025 10:05:20 GMT Subject: RFR: 8367754: G1: Add a fast path in heap resize related method [v3] In-Reply-To: References: <26wTFQP7L9lpuQahVHl17nukhLB4KFDH3Njti5tZhTs=.8ec65369-82c2-4d53-92ff-66dcc7bfaf6e@github.com> Message-ID: On Thu, 18 Sep 2025 13:16:04 GMT, Albert Mingkun Yang wrote: > > ... thereby avoiding unnecessary computation > > That's absolutely true; however, the real expensive part is not the calculation but actual resizing (commit/uncommit). > > Since the existing logic is not simplified by the use of early-return, I feel it hinders readability slightly. I wonder what others think. I agree with the evaluation where the actual costs are. I think the intent of the change is fine, although not absolutely necessary. That is why I suggested to avoid the new member variable. I am good either way (drop or keep) though. Thomas ------------- PR Comment: https://git.openjdk.org/jdk/pull/27349#issuecomment-3311543910 From fandreuzzi at openjdk.org Fri Sep 19 10:11:34 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 19 Sep 2025 10:11:34 GMT Subject: RFR: 8368086: G1: Use ThreadsClaimTokenScope in G1CMRemarkTask In-Reply-To: <5Cfv_IvHP9XylALnSg_uAMfi8TPD6r5Nc4G1Bpc7rjA=.6176dce7-fd51-465b-a846-b797922b5ce7@github.com> References: <5Cfv_IvHP9XylALnSg_uAMfi8TPD6r5Nc4G1Bpc7rjA=.6176dce7-fd51-465b-a846-b797922b5ce7@github.com> Message-ID: On Fri, 19 Sep 2025 09:16:47 GMT, Albert Mingkun Yang wrote: > Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `G1ConcurrentMark::finalize_marking` to be more precise with what is actually needed and why. > > Test: tier1 Marked as reviewed by fandreuzzi (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/27385#pullrequestreview-3244152232 From stefank at openjdk.org Fri Sep 19 10:19:24 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 19 Sep 2025 10:19:24 GMT Subject: RFR: 8368086: G1: Use ThreadsClaimTokenScope in G1CMRemarkTask In-Reply-To: <5Cfv_IvHP9XylALnSg_uAMfi8TPD6r5Nc4G1Bpc7rjA=.6176dce7-fd51-465b-a846-b797922b5ce7@github.com> References: <5Cfv_IvHP9XylALnSg_uAMfi8TPD6r5Nc4G1Bpc7rjA=.6176dce7-fd51-465b-a846-b797922b5ce7@github.com> Message-ID: On Fri, 19 Sep 2025 09:16:47 GMT, Albert Mingkun Yang wrote: > Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `G1ConcurrentMark::finalize_marking` to be more precise with what is actually needed and why. > > Test: tier1 One difference between the two code paths is the check to see if the number of threads are > 0. Are we guaranteed that active_workers are > 0 here? ------------- PR Review: https://git.openjdk.org/jdk/pull/27385#pullrequestreview-3244202432 From iwalulya at openjdk.org Fri Sep 19 10:22:38 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Fri, 19 Sep 2025 10:22:38 GMT Subject: RFR: 8367651: Parallel: Remove workers number checking in constructor of PSAdjustTask In-Reply-To: <2e3WwehTnC82T1ypS8Ma_n6gYe_GHVHpDj-epViJJ2M=.ce06fa76-bb36-4df4-bebd-5400fec9168b@github.com> References: <2e3WwehTnC82T1ypS8Ma_n6gYe_GHVHpDj-epViJJ2M=.ce06fa76-bb36-4df4-bebd-5400fec9168b@github.com> Message-ID: On Mon, 15 Sep 2025 10:01:45 GMT, Albert Mingkun Yang wrote: > Uniform thread claiming path for different number of workers. > > Test: tier1-3 Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27290#pullrequestreview-3244225457 From iwalulya at openjdk.org Fri Sep 19 10:23:37 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Fri, 19 Sep 2025 10:23:37 GMT Subject: RFR: 8367759: G1: Move G1UpdateRegionLivenessAndSelectForRebuildTask into its own file In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 14:19:41 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to move `G1UpdateRegionLivenessAndSelectForRebuildTask` into a separate file. I would like to merge this class and G1BuildCandidateRegionsTask in the near future because the latter mostly repeats the work of the former anyway, but together (with helper classes) they are quite large (if not large already by themselves). This should help make `g1ConcurrentMark.cpp` a little more manageable. > > There is no change in the code, just moving and fixing includes/adding forwards. > > Testing: local compilation, gha > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27314#pullrequestreview-3244233483 From sjohanss at openjdk.org Fri Sep 19 10:30:18 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Fri, 19 Sep 2025 10:30:18 GMT Subject: RFR: 8348278: Trim InitialRAMPercentage to improve startup in default modes [v4] In-Reply-To: References: Message-ID: <3M1lUtyQhhhIIYIRmeyQ42WS4zGPGQzp-kwOSvkkfHc=.c134cbac-4efa-45a4-8c65-a22bf427174e@github.com> On Tue, 2 Sep 2025 12:57:47 GMT, Aleksey Shipilev wrote: >> See bug for discussion. This is the code change, which is simple. What is not simple is deciding what the new value should be. The change would probably require CSR, which I can file after we agree on the value. >> >> I think cutting to 0.2% of RAM size gets us into good sweet spot: >> - On huge 1024G machine, this yields 2G initial heap >> - On reasonably sized 128G machine, this gives 256M initial heap >> - On smaller 1G container, this gives 2M initial heap >> >> Additional testing: >> - [x] Linux AArch64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Also man page > - Fix > Anyway, changing the _way_ Xms is selected feels way too much work, given the benefits we are after. I agree, and if we want to do a re-haul of the sizing code we should probably do it after the AHS work. Hopefully that can simplify some things. We've discussed this a bit more internally and while there are some hesitations on some points we do see some benefits with the changed default as well. So will approve it. Thanks for the discussion. ------------- Marked as reviewed by sjohanss (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23262#pullrequestreview-3244258740 From aboldtch at openjdk.org Fri Sep 19 11:05:12 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 19 Sep 2025 11:05:12 GMT Subject: RFR: 8368087: ZGC: Make ZStatLoad::print() logging conditional on os::loadavg support Message-ID: <7olPMO9LfpilQXoHcajv0nHeiBaZVycm9xBkD6UJV_4=.fc000130-5cf3-4554-9391-fe925552d2f6@github.com> ZStatLoad::print() logs the load average on the machine, however it does not check whether the operation is supported or not. This results in printing a load average of 0/0/0 on Windows which is a bit misleading. ------------- Commit messages: - 8368087: ZGC: Make ZStatLoad::print() logging conditional on os::loadavg support Changes: https://git.openjdk.org/jdk/pull/27389/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27389&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368087 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27389.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27389/head:pull/27389 PR: https://git.openjdk.org/jdk/pull/27389 From tschatzl at openjdk.org Fri Sep 19 11:24:24 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 19 Sep 2025 11:24:24 GMT Subject: RFR: 8367651: Parallel: Remove workers number checking in constructor of PSAdjustTask In-Reply-To: <2e3WwehTnC82T1ypS8Ma_n6gYe_GHVHpDj-epViJJ2M=.ce06fa76-bb36-4df4-bebd-5400fec9168b@github.com> References: <2e3WwehTnC82T1ypS8Ma_n6gYe_GHVHpDj-epViJJ2M=.ce06fa76-bb36-4df4-bebd-5400fec9168b@github.com> Message-ID: <7qsQb2pY8UEDO_9bXHjbuNvo9NJMr9a-ma0IpB9EWUM=.367cc775-1c83-457c-b7b8-757d1441774b@github.com> On Mon, 15 Sep 2025 10:01:45 GMT, Albert Mingkun Yang wrote: > Uniform thread claiming path for different number of workers. > > Test: tier1-3 Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27290#pullrequestreview-3244420470 From eosterlund at openjdk.org Fri Sep 19 11:42:01 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 19 Sep 2025 11:42:01 GMT Subject: RFR: 8368087: ZGC: Make ZStatLoad::print() logging conditional on os::loadavg support In-Reply-To: <7olPMO9LfpilQXoHcajv0nHeiBaZVycm9xBkD6UJV_4=.fc000130-5cf3-4554-9391-fe925552d2f6@github.com> References: <7olPMO9LfpilQXoHcajv0nHeiBaZVycm9xBkD6UJV_4=.fc000130-5cf3-4554-9391-fe925552d2f6@github.com> Message-ID: On Fri, 19 Sep 2025 10:59:00 GMT, Axel Boldt-Christmas wrote: > ZStatLoad::print() logs the load average on the machine, however it does not check whether the operation is supported or not. This results in printing a load average of 0/0/0 on Windows which is a bit misleading. Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27389#pullrequestreview-3244476275 From tschatzl at openjdk.org Fri Sep 19 11:47:51 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 19 Sep 2025 11:47:51 GMT Subject: RFR: 8367759: G1: Move G1UpdateRegionLivenessAndSelectForRebuildTask into its own file In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 07:39:06 GMT, Albert Mingkun Yang wrote: >> Hi all, >> >> please review this change to move `G1UpdateRegionLivenessAndSelectForRebuildTask` into a separate file. I would like to merge this class and G1BuildCandidateRegionsTask in the near future because the latter mostly repeats the work of the former anyway, but together (with helper classes) they are quite large (if not large already by themselves). This should help make `g1ConcurrentMark.cpp` a little more manageable. >> >> There is no change in the code, just moving and fixing includes/adding forwards. >> >> Testing: local compilation, gha >> >> Thanks, >> Thomas > > Marked as reviewed by ayang (Reviewer). Thanks @albertnetymk @walulyai for your reviews, Thomas ------------- PR Comment: https://git.openjdk.org/jdk/pull/27314#issuecomment-3311885040 From tschatzl at openjdk.org Fri Sep 19 11:51:15 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 19 Sep 2025 11:51:15 GMT Subject: Integrated: 8367759: G1: Move G1UpdateRegionLivenessAndSelectForRebuildTask into its own file In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 14:19:41 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to move `G1UpdateRegionLivenessAndSelectForRebuildTask` into a separate file. I would like to merge this class and G1BuildCandidateRegionsTask in the near future because the latter mostly repeats the work of the former anyway, but together (with helper classes) they are quite large (if not large already by themselves). This should help make `g1ConcurrentMark.cpp` a little more manageable. > > There is no change in the code, just moving and fixing includes/adding forwards. > > Testing: local compilation, gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 2bff4174 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/2bff4174e58e11ba78013bef8417334ff44fbb5c Stats: 427 lines in 3 files changed: 254 ins; 173 del; 0 mod 8367759: G1: Move G1UpdateRegionLivenessAndSelectForRebuildTask into its own file Reviewed-by: ayang, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/27314 From ayang at openjdk.org Fri Sep 19 12:08:57 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 19 Sep 2025 12:08:57 GMT Subject: RFR: 8368086: G1: Use ThreadsClaimTokenScope in G1CMRemarkTask In-Reply-To: References: <5Cfv_IvHP9XylALnSg_uAMfi8TPD6r5Nc4G1Bpc7rjA=.6176dce7-fd51-465b-a846-b797922b5ce7@github.com> Message-ID: <15KX-ufewzZTEM7a5gcMkixWq83x_BkVDZmq7kl6lMw=.d7b2be47-b8a4-49ce-a7dc-c87f325bc38a@github.com> On Fri, 19 Sep 2025 10:16:13 GMT, Stefan Karlsson wrote: > Are we guaranteed that active_workers are > 0 here? Yes. There is at least one active worker, or we fail at startup, as shown in `WorkerThreads::initialize_workers`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27385#issuecomment-3311943106 From ghan at openjdk.org Fri Sep 19 12:48:38 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Fri, 19 Sep 2025 12:48:38 GMT Subject: RFR: 8367754: G1: Add a fast path in heap resize related method [v3] In-Reply-To: References: <26wTFQP7L9lpuQahVHl17nukhLB4KFDH3Njti5tZhTs=.8ec65369-82c2-4d53-92ff-66dcc7bfaf6e@github.com> Message-ID: On Thu, 18 Sep 2025 13:16:04 GMT, Albert Mingkun Yang wrote: >> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: >> >> Update TestHeapResizeAfterGC.java >> >> correct format error > >> ... thereby avoiding unnecessary computation > > That's absolutely true; however, the real expensive part is not the calculation but actual resizing (commit/uncommit). > > Since the existing logic is not simplified by the use of early-return, I feel it hinders readability slightly. I wonder what others think. Hi @albertnetymk @tschatzl Thank you for your feedback! I agree the benefit of this change might indeed be small. I?ll take another look to see if there are other areas where it can help performance. If not, I?ll go ahead and close this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27349#issuecomment-3312066625 From stefank at openjdk.org Fri Sep 19 13:07:53 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 19 Sep 2025 13:07:53 GMT Subject: RFR: 8368087: ZGC: Make ZStatLoad::print() logging conditional on os::loadavg support In-Reply-To: <7olPMO9LfpilQXoHcajv0nHeiBaZVycm9xBkD6UJV_4=.fc000130-5cf3-4554-9391-fe925552d2f6@github.com> References: <7olPMO9LfpilQXoHcajv0nHeiBaZVycm9xBkD6UJV_4=.fc000130-5cf3-4554-9391-fe925552d2f6@github.com> Message-ID: On Fri, 19 Sep 2025 10:59:00 GMT, Axel Boldt-Christmas wrote: > ZStatLoad::print() logs the load average on the machine, however it does not check whether the operation is supported or not. This results in printing a load average of 0/0/0 on Windows which is a bit misleading. Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27389#pullrequestreview-3244776281 From jsikstro at openjdk.org Fri Sep 19 14:10:35 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Fri, 19 Sep 2025 14:10:35 GMT Subject: RFR: 8368087: ZGC: Make ZStatLoad::print() logging conditional on os::loadavg support In-Reply-To: <7olPMO9LfpilQXoHcajv0nHeiBaZVycm9xBkD6UJV_4=.fc000130-5cf3-4554-9391-fe925552d2f6@github.com> References: <7olPMO9LfpilQXoHcajv0nHeiBaZVycm9xBkD6UJV_4=.fc000130-5cf3-4554-9391-fe925552d2f6@github.com> Message-ID: On Fri, 19 Sep 2025 10:59:00 GMT, Axel Boldt-Christmas wrote: > ZStatLoad::print() logs the load average on the machine, however it does not check whether the operation is supported or not. This results in printing a load average of 0/0/0 on Windows which is a bit misleading. Marked as reviewed by jsikstro (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27389#pullrequestreview-3245053323 From ayang at openjdk.org Fri Sep 19 14:19:29 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 19 Sep 2025 14:19:29 GMT Subject: RFR: 8367651: Parallel: Remove workers number checking in constructor of PSAdjustTask In-Reply-To: <2e3WwehTnC82T1ypS8Ma_n6gYe_GHVHpDj-epViJJ2M=.ce06fa76-bb36-4df4-bebd-5400fec9168b@github.com> References: <2e3WwehTnC82T1ypS8Ma_n6gYe_GHVHpDj-epViJJ2M=.ce06fa76-bb36-4df4-bebd-5400fec9168b@github.com> Message-ID: <_vFM_0Adl4xu5nvq8IlO7ax8_lqgcab5OuXefQxXAhI=.50fb39af-53ea-41d7-8737-98331108bd17@github.com> On Mon, 15 Sep 2025 10:01:45 GMT, Albert Mingkun Yang wrote: > Uniform thread claiming path for different number of workers. > > Test: tier1-3 Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27290#issuecomment-3312368198 From ayang at openjdk.org Fri Sep 19 14:19:30 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 19 Sep 2025 14:19:30 GMT Subject: Integrated: 8367651: Parallel: Remove workers number checking in constructor of PSAdjustTask In-Reply-To: <2e3WwehTnC82T1ypS8Ma_n6gYe_GHVHpDj-epViJJ2M=.ce06fa76-bb36-4df4-bebd-5400fec9168b@github.com> References: <2e3WwehTnC82T1ypS8Ma_n6gYe_GHVHpDj-epViJJ2M=.ce06fa76-bb36-4df4-bebd-5400fec9168b@github.com> Message-ID: On Mon, 15 Sep 2025 10:01:45 GMT, Albert Mingkun Yang wrote: > Uniform thread claiming path for different number of workers. > > Test: tier1-3 This pull request has now been integrated. Changeset: 54206943 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/54206943a1715083a680f8c987b69f2e44e948c1 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod 8367651: Parallel: Remove workers number checking in constructor of PSAdjustTask Reviewed-by: iwalulya, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/27290 From stefank at openjdk.org Fri Sep 19 14:20:21 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 19 Sep 2025 14:20:21 GMT Subject: RFR: 8368086: G1: Use ThreadsClaimTokenScope in G1CMRemarkTask In-Reply-To: <5Cfv_IvHP9XylALnSg_uAMfi8TPD6r5Nc4G1Bpc7rjA=.6176dce7-fd51-465b-a846-b797922b5ce7@github.com> References: <5Cfv_IvHP9XylALnSg_uAMfi8TPD6r5Nc4G1Bpc7rjA=.6176dce7-fd51-465b-a846-b797922b5ce7@github.com> Message-ID: <3N3ypsrGSpR_aQ52Zy3EoIjYY1gmrabBBsjuevkbctU=.96ad2223-a6a5-4468-a2f9-0673b86b7459@github.com> On Fri, 19 Sep 2025 09:16:47 GMT, Albert Mingkun Yang wrote: > Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `G1ConcurrentMark::finalize_marking` to be more precise with what is actually needed and why. > > Test: tier1 Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27385#pullrequestreview-3245096650 From shade at openjdk.org Fri Sep 19 14:29:04 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 19 Sep 2025 14:29:04 GMT Subject: RFR: 8348278: Trim InitialRAMPercentage to improve startup in default modes [v4] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 12:57:47 GMT, Aleksey Shipilev wrote: >> See bug for discussion. This is the code change, which is simple. What is not simple is deciding what the new value should be. The change would probably require CSR, which I can file after we agree on the value. >> >> I think cutting to 0.2% of RAM size gets us into good sweet spot: >> - On huge 1024G machine, this yields 2G initial heap >> - On reasonably sized 128G machine, this gives 256M initial heap >> - On smaller 1G container, this gives 2M initial heap >> >> Additional testing: >> - [x] Linux AArch64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Also man page > - Fix Thank you! Here goes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23262#issuecomment-3312413155 From shade at openjdk.org Fri Sep 19 14:29:05 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 19 Sep 2025 14:29:05 GMT Subject: Integrated: 8348278: Trim InitialRAMPercentage to improve startup in default modes In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 11:27:46 GMT, Aleksey Shipilev wrote: > See bug for discussion. This is the code change, which is simple. What is not simple is deciding what the new value should be. The change would probably require CSR, which I can file after we agree on the value. > > I think cutting to 0.2% of RAM size gets us into good sweet spot: > - On huge 1024G machine, this yields 2G initial heap > - On reasonably sized 128G machine, this gives 256M initial heap > - On smaller 1G container, this gives 2M initial heap > > Additional testing: > - [x] Linux AArch64 server fastdebug, `all` This pull request has now been integrated. Changeset: 1512d889 Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/1512d889dee2adb6d4536202dc7f205e5daf6fe7 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8348278: Trim InitialRAMPercentage to improve startup in default modes Reviewed-by: eosterlund, sjohanss ------------- PR: https://git.openjdk.org/jdk/pull/23262 From gli at openjdk.org Fri Sep 19 14:40:58 2025 From: gli at openjdk.org (Guoxiong Li) Date: Fri, 19 Sep 2025 14:40:58 GMT Subject: RFR: 8368006: Parallel: Skip full regions in dense prefix during Full GC In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 18:00:18 GMT, Albert Mingkun Yang wrote: > Implement skip-full-region optimization for filler related operations on dense-prefix. I constrained the filler-creation task to a single worker for simpler implementation. During the compaction phase, the most expensive part is almost always the non-dense-prefix part, so letting the rest of workers to start with the expensive tasks seems sensible. > > Synthetic bms shows good reduction in full-gc time in debug build; perf-neutral for other bms (specjvm2008,specjbb2015) in release build. > > Test: tier1-5 Changes requested by gli (Reviewer). src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1680: > 1678: if (worker_id == 0) { > 1679: auto start = Ticks::now(); > 1680: PSParallelCompact::fill_dead_objs_in_dense_prefix(worker_id, _num_workers); The method `PSParallelCompact::fill_dead_objs_in_dense_prefix` doesn't need the arguments `worker_id` and `num_workers` now. ------------- PR Review: https://git.openjdk.org/jdk/pull/27369#pullrequestreview-3244908218 PR Review Comment: https://git.openjdk.org/jdk/pull/27369#discussion_r2362920705 From ayang at openjdk.org Fri Sep 19 15:09:25 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 19 Sep 2025 15:09:25 GMT Subject: RFR: 8368006: Parallel: Skip full regions in dense prefix during Full GC [v2] In-Reply-To: References: Message-ID: <0gXhjgdxG3MgUvM3qE-pYFlPrx64Tmwf4l2gzSJ617A=.b4572760-7b74-4dab-9c52-ae169c4504f2@github.com> > Implement skip-full-region optimization for filler related operations on dense-prefix. I constrained the filler-creation task to a single worker for simpler implementation. During the compaction phase, the most expensive part is almost always the non-dense-prefix part, so letting the rest of workers to start with the expensive tasks seems sensible. > > Synthetic bms shows good reduction in full-gc time in debug build; perf-neutral for other bms (specjvm2008,specjbb2015) in release build. > > Test: tier1-5 Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - review - Merge branch 'master' into pgc-skip-full-region - pgc-skip-full-region ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27369/files - new: https://git.openjdk.org/jdk/pull/27369/files/3e73200f..20937445 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27369&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27369&range=00-01 Stats: 6060 lines in 138 files changed: 4594 ins; 1188 del; 278 mod Patch: https://git.openjdk.org/jdk/pull/27369.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27369/head:pull/27369 PR: https://git.openjdk.org/jdk/pull/27369 From ayang at openjdk.org Fri Sep 19 15:32:22 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 19 Sep 2025 15:32:22 GMT Subject: RFR: 8368104: Parallel: Refactor PSThreadRootsTaskClosure Message-ID: Trivial changing the closure input arg to avoid `PSPromotionManager` lookup. Test: tier1 ------------- Commit messages: - pgc-young-gc-refactor Changes: https://git.openjdk.org/jdk/pull/27393/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27393&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368104 Stats: 13 lines in 1 file changed: 1 ins; 4 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/27393.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27393/head:pull/27393 PR: https://git.openjdk.org/jdk/pull/27393 From fandreuzzi at openjdk.org Fri Sep 19 16:06:00 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 19 Sep 2025 16:06:00 GMT Subject: RFR: 8368104: Parallel: Refactor PSThreadRootsTaskClosure In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 15:24:05 GMT, Albert Mingkun Yang wrote: > Trivial changing the closure input arg to avoid `PSPromotionManager` lookup. > > Test: tier1 Marked as reviewed by fandreuzzi (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/27393#pullrequestreview-3245658537 From stefank at openjdk.org Fri Sep 19 17:45:11 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 19 Sep 2025 17:45:11 GMT Subject: RFR: 8368104: Parallel: Refactor PSThreadRootsTaskClosure In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 15:24:05 GMT, Albert Mingkun Yang wrote: > Trivial changing the closure input arg to avoid `PSPromotionManager` lookup. > > Test: tier1 src/hotspot/share/gc/parallel/psScavenge.cpp line 273: > 271: PSPromotionManager* pm = PSPromotionManager::gc_thread_promotion_manager(worker_id); > 272: PSCardTable* card_table = ParallelScavengeHeap::heap()->card_table(); > 273: Please restore this blank line. src/hotspot/share/gc/parallel/psScavenge.cpp line 295: > 293: { > 294: PSScavengeRootsClosure root_closure(pm); > 295: _oop_storage_strong_par_state.oops_do(&root_closure); The pm variable isn't local to this scope anymore so it would probably be nicer to move the following part out of the scope: // Do the real work pm->drain_stacks(false); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27393#discussion_r2363901145 PR Review Comment: https://git.openjdk.org/jdk/pull/27393#discussion_r2363900123 From ayang at openjdk.org Fri Sep 19 18:36:28 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 19 Sep 2025 18:36:28 GMT Subject: RFR: 8368104: Parallel: Refactor PSThreadRootsTaskClosure [v2] In-Reply-To: References: Message-ID: <1Syr14Agx7L6XHx08_aTexqjgcYQG24rvPvxmApemLg=.8834ed78-473c-4ff7-8bde-1003499d51b4@github.com> > Trivial changing the closure input arg to avoid `PSPromotionManager` lookup. > > Test: tier1 Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27393/files - new: https://git.openjdk.org/jdk/pull/27393/files/b14386f3..476c3cce Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27393&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27393&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27393.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27393/head:pull/27393 PR: https://git.openjdk.org/jdk/pull/27393 From ayang at openjdk.org Fri Sep 19 18:36:29 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 19 Sep 2025 18:36:29 GMT Subject: RFR: 8368104: Parallel: Refactor PSThreadRootsTaskClosure [v2] In-Reply-To: References: Message-ID: <_688OBDQKo-yg8oMJtFwiPGiBK3SHi916LGGokSYDaM=.03882081-e155-46dc-b025-19fd2fd9ac66@github.com> On Fri, 19 Sep 2025 17:42:10 GMT, Stefan Karlsson wrote: >> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> review > > src/hotspot/share/gc/parallel/psScavenge.cpp line 295: > >> 293: { >> 294: PSScavengeRootsClosure root_closure(pm); >> 295: _oop_storage_strong_par_state.oops_do(&root_closure); > > The pm variable isn't local to this scope anymore so it would probably be nicer to move the following part out of the scope: > > // Do the real work > pm->drain_stacks(false); Well, it's there to be consistent with other kinds of roots -- old-to-young pointers, inside `scavenge_roots_work`, and `thread_closure`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27393#discussion_r2364062470 From stefank at openjdk.org Fri Sep 19 20:42:22 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 19 Sep 2025 20:42:22 GMT Subject: RFR: 8368104: Parallel: Refactor PSThreadRootsTaskClosure [v2] In-Reply-To: <_688OBDQKo-yg8oMJtFwiPGiBK3SHi916LGGokSYDaM=.03882081-e155-46dc-b025-19fd2fd9ac66@github.com> References: <_688OBDQKo-yg8oMJtFwiPGiBK3SHi916LGGokSYDaM=.03882081-e155-46dc-b025-19fd2fd9ac66@github.com> Message-ID: On Fri, 19 Sep 2025 18:31:48 GMT, Albert Mingkun Yang wrote: >> src/hotspot/share/gc/parallel/psScavenge.cpp line 295: >> >>> 293: { >>> 294: PSScavengeRootsClosure root_closure(pm); >>> 295: _oop_storage_strong_par_state.oops_do(&root_closure); >> >> The pm variable isn't local to this scope anymore so it would probably be nicer to move the following part out of the scope: >> >> // Do the real work >> pm->drain_stacks(false); > > Well, it's there to be consistent with other kinds of roots -- old-to-young pointers, inside `scavenge_roots_work`, and `thread_closure`. Ahh. I see now. Would you mind adding a blank line so that the formatting is consistent: PSScavengeRootsClosure root_closure(pm); _oop_storage_strong_par_state.oops_do(&root_closure); // Do the real work pm->drain_stacks(false); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27393#discussion_r2364486008 From ayang at openjdk.org Fri Sep 19 20:49:39 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 19 Sep 2025 20:49:39 GMT Subject: RFR: 8368104: Parallel: Refactor PSThreadRootsTaskClosure [v3] In-Reply-To: References: Message-ID: > Trivial changing the closure input arg to avoid `PSPromotionManager` lookup. > > Test: tier1 Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27393/files - new: https://git.openjdk.org/jdk/pull/27393/files/476c3cce..265a0235 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27393&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27393&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27393.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27393/head:pull/27393 PR: https://git.openjdk.org/jdk/pull/27393 From kdnilsen at openjdk.org Sat Sep 20 00:11:24 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Sat, 20 Sep 2025 00:11:24 GMT Subject: RFR: 8368015: Shenandoah: fix error in computation of average allocation rate Message-ID: We use bytes_allocated_since_gc_start() to compute allocation rates. This leaves a blind spot, as our current implementation ignores allocations and the time period between the moment we begin GC and the first time we update the allocation rate following the start of GC. When this happens, we typically find that the sampled number of allocations is smaller than the allocations that had accumulated by the time we triggered the start of the current GC cycle. This PR adds tracking for that accounting gap. ------------- Commit messages: - fix whitespace - Account for gap allocations between gc cycles Changes: https://git.openjdk.org/jdk/pull/27398/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27398&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368015 Stats: 32 lines in 4 files changed: 25 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27398.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27398/head:pull/27398 PR: https://git.openjdk.org/jdk/pull/27398 From wkemper at openjdk.org Sat Sep 20 00:11:24 2025 From: wkemper at openjdk.org (William Kemper) Date: Sat, 20 Sep 2025 00:11:24 GMT Subject: RFR: 8368015: Shenandoah: fix error in computation of average allocation rate In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 20:36:51 GMT, Kelvin Nilsen wrote: > We use bytes_allocated_since_gc_start() to compute allocation rates. This leaves a blind spot, as our current implementation ignores allocations and the time period between the moment we begin GC and the first time we update the allocation rate following the start of GC. When this happens, we typically find that the sampled number of allocations is smaller than the allocations that had accumulated by the time we triggered the start of the current GC cycle. > > This PR adds tracking for that accounting gap. Is the real issue that we reset `bytes_allocated_since_gc_start` without sampling the value _before_ it is reset (thereby losing allocations that happen during the gc)? Would it be simpler to also take the sample just before it is reset (perhaps use an atomic exchange with zero, so we lose nothing)? Then we wouldn't need to juggle an extra member variable to remember the value. There is no reason we aren't allowed to update the allocation rate outside of `should_start_gc`. Side note - should we really call this `bytes_allocated_since_gc_end`? I think that is what the variable actually represents because it is reset at the end of the cycle. ------------- PR Review: https://git.openjdk.org/jdk/pull/27398#pullrequestreview-3247194979 From kdnilsen at openjdk.org Sat Sep 20 00:11:25 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Sat, 20 Sep 2025 00:11:25 GMT Subject: RFR: 8368015: Shenandoah: fix error in computation of average allocation rate In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 21:29:32 GMT, William Kemper wrote: > Is the real issue that we reset `bytes_allocated_since_gc_start` without sampling the value _before_ it is reset > (thereby losing allocations that happen during the gc)? I guess that's a big part of the problem. But the other problem is that there is not a natural alignment between when we reset the bytes allocated and when we reset the values of _last_sample_time and _last_sample_value. > Would it be simpler to also take the sample just before it is reset (perhaps use an atomic exchange with zero, > so we lose nothing)? Then we wouldn't need to juggle an extra member variable to remember the value. There > is no reason we aren't allowed to update the allocation rate outside of `should_start_gc`. There is some inherent synchronization in place that avoids the need for an atomic variable. As implemented, we only add samples from should_start_gc(), which is invoked by a single thread "at most" once per ms only when GC is idle and we add one additional sample with GenShen from within final_mark safepoint when we are calculating the necessary reserves. So the proposed implementation already "loses" nothing, I think. If you want to "save a variable", we could just initialize _last_sample_value to the bytes allocated following the last sample prior to start of GC instead of initializing this value to zero. But then we would also have to initialize bytes_allocated_since_gc_start to this same value instead of initializing that to zero. And this would make bytes_allocated_since_gc_start() a bit imprecise in that we would really be returning bytes allocated since last sample taken before gc start. I guess I could live with that, but I'm inclined to keep the more accurate semantics and add the state variable to keep track of the delta... > > Side note - should we really call this `bytes_allocated_since_gc_end`? I think that is what the variable actually > represents because it is reset at the end of the cycle. I believe we do reset at the start of GC. The reset_bytes_allocated_since_gc_start() gets called from ShenandoahControlThread::run_service() whenever gc_requested, and at the top of ShenandoahGenerationalControlThread::run_gc_cycle(). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27398#issuecomment-3313963649 From wkemper at openjdk.org Sat Sep 20 00:11:25 2025 From: wkemper at openjdk.org (William Kemper) Date: Sat, 20 Sep 2025 00:11:25 GMT Subject: RFR: 8368015: Shenandoah: fix error in computation of average allocation rate In-Reply-To: References: Message-ID: <5SRTHzH_RSDCUkcrFB_zdKkqeBTAIYxscvSEnxT-_u8=.d43724fc-0113-4079-bbcc-d012e990eaf0@github.com> On Fri, 19 Sep 2025 21:56:25 GMT, Kelvin Nilsen wrote: > There is some inherent synchronization in place that avoids the need for an atomic variable. I meant losing updates to `bytes_allocated_since_gc_start` made by mutators as they allocate. This read/reset could _technically_ lose updates from allocating threads (I'm not really worried about that): ```C++ size_t bytes_allocated = young_generation()->bytes_allocated_since_gc_start(); // Suppose control thread is off cpu here while mutators increase bytes allocated young_generation()->reset_bytes_allocated_since_gc_start(); I had something like this in mind: ```C++ // atomic exchange existing value with zero size_t bytes_allocated = young_generation()->reset_bytes_allocated_since_gc_start(); // incorporate the value into the samples for the average young_generation()->sample_allocations(bytes_allocated); > I believe we do reset at the start of GC. You're right, I misread that code. I think I'm more confused now than I was before. I thought you were trying to fix the lost updates to `bytes_allocated_since_gc_start` between the last time the heuristic reads it and resets it. Shouldn't the average allocation rate work out the same if we read small changes frequently (the usual case when the GC is idle) or if we read a large change infrequently (such as our first read after it is reset)? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27398#issuecomment-3314002066 From kdnilsen at openjdk.org Sat Sep 20 00:11:27 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Sat, 20 Sep 2025 00:11:27 GMT Subject: RFR: 8368015: Shenandoah: fix error in computation of average allocation rate In-Reply-To: References: Message-ID: <1CVo2PV4oafnz4Es3iGyZiC8G9SBvp1B3oxrU-Pwd6c=.6d52c939-4b95-4945-803d-f1d6b566205d@github.com> On Fri, 19 Sep 2025 20:36:51 GMT, Kelvin Nilsen wrote: > We use bytes_allocated_since_gc_start() to compute allocation rates. This leaves a blind spot, as our current implementation ignores allocations and the time period between the moment we begin GC and the first time we update the allocation rate following the start of GC. When this happens, we typically find that the sampled number of allocations is smaller than the allocations that had accumulated by the time we triggered the start of the current GC cycle. > > This PR adds tracking for that accounting gap. As currently implemented, bytes_allocated_since_gc_start() is reliable (as in mainline, or as in the PR that unifies all accounting within the ShenandoahFreeSet). The problem is that the average allocation rate is not reliable. The reason average allocation rate is not reliable is because: 1. In the most common case, all of the allocations that happen between the moment we last sampled before the start of GC and we next sample at the end of final mark are ignored. This might represent several seconds of time. In the case that allocation rates are increasing, we will be excluding the most recent several seconds of allocation behavior from our next allocation average. 2. In the less common case, our "average" allocation rate will be grossly under-reported. Consider a case where allocation rate is gradually increasing. We've been sampling every 100 ms, and our average rate at the time we trigger GC is based on recent allocation rates of: ..., 1GB/s, 1.1GB/s, 1.3GB/s, 1.4GB/s and then we trigger. Suppose allocation rates continue to increase at this same rate, but we don't sample again until the end of marking, which takes 3 seconds. During these 3 seconds, we have missed 30 updates. If we had continued to sample, we would have seen that the most recent 100 ms allocated at a rate of 4.5 GB/s. The proposed new implementation would add a sample that says we just allocated at an average rate of ~3GB/s for ~3.05 seconds. In the current implementation, we might find that the last_sample_value is 8GB (assume this sample happened 50 ms before GC was triggered). The new value of allocated will be 9 GB (3 GB/s for 3 seconds). So we'll add into our average the value 1 GB allocated in 3.05 seconds, or approximately 333 MB/s (with a heavy weight because this represents 3 seconds of execution time). This causes triggering heuristic to be overly optimistic, because they are left believing that allocations are at a lower rate than reality. src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 374: > 372: _rate.add(rate); > 373: _rate_avg.add(_rate.avg()); > 374: _last_sample_time = now; Note: in original implementation, the first sample() collected following the start of GC typically finds that allocated < _last_sample_value, so we ignore all data associated with that time gap. With Shenandoah, the next sample happens the first time we ask should_start_gc() following the completion of the current GC. With GenShen, the next sample happens after marking, when we calculate the allocation runway in order to size our reserves. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27398#issuecomment-3314220009 PR Review Comment: https://git.openjdk.org/jdk/pull/27398#discussion_r2364492203 From kdnilsen at openjdk.org Sat Sep 20 00:11:28 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Sat, 20 Sep 2025 00:11:28 GMT Subject: RFR: 8368015: Shenandoah: fix error in computation of average allocation rate In-Reply-To: <1CVo2PV4oafnz4Es3iGyZiC8G9SBvp1B3oxrU-Pwd6c=.6d52c939-4b95-4945-803d-f1d6b566205d@github.com> References: <1CVo2PV4oafnz4Es3iGyZiC8G9SBvp1B3oxrU-Pwd6c=.6d52c939-4b95-4945-803d-f1d6b566205d@github.com> Message-ID: On Fri, 19 Sep 2025 20:43:59 GMT, Kelvin Nilsen wrote: >> We use bytes_allocated_since_gc_start() to compute allocation rates. This leaves a blind spot, as our current implementation ignores allocations and the time period between the moment we begin GC and the first time we update the allocation rate following the start of GC. When this happens, we typically find that the sampled number of allocations is smaller than the allocations that had accumulated by the time we triggered the start of the current GC cycle. >> >> This PR adds tracking for that accounting gap. > > src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 374: > >> 372: _rate.add(rate); >> 373: _rate_avg.add(_rate.avg()); >> 374: _last_sample_time = now; > > Note: in original implementation, the first sample() collected following the start of GC typically finds that allocated < _last_sample_value, so we ignore all data associated with that time gap. With Shenandoah, the next sample happens the first time we ask should_start_gc() following the completion of the current GC. With GenShen, the next sample happens after marking, when we calculate the allocation runway in order to size our reserves. It is possible that the first sample() collected() following the start of GC finds allocated > _last_sample value. If this happens, the above computes a bogus result. It thinks we've only allocated (new_sample_value - _last_sample_value) bytes in total time (now - _last_sample_time). In truth, we've allocated new_sample_value plus currently_unknown_allocations following _last_sample_time but before the start of GC. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27398#discussion_r2364497570 From kdnilsen at openjdk.org Sat Sep 20 00:20:13 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Sat, 20 Sep 2025 00:20:13 GMT Subject: RFR: 8368015: Shenandoah: fix error in computation of average allocation rate In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 20:36:51 GMT, Kelvin Nilsen wrote: > We use bytes_allocated_since_gc_start() to compute allocation rates. This leaves a blind spot, as our current implementation ignores allocations and the time period between the moment we begin GC and the first time we update the allocation rate following the start of GC. When this happens, we typically find that the sampled number of allocations is smaller than the allocations that had accumulated by the time we triggered the start of the current GC cycle. > > This PR adds tracking for that accounting gap. > > I had something like this in mind: > > ```c++ > // atomic exchange existing value with zero > size_t bytes_allocated = young_generation()->reset_bytes_allocated_since_gc_start(); > // incorporate the value into the samples for the average > young_generation()->sample_allocations(bytes_allocated); > ``` > This is a good idea. We'll end up with two samples whereas my proposed solution had a single combined sample. But we avoid the extra variable. Also, two samples gives us better awareness of acceleration... I'll make this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27398#issuecomment-3314273445 From gli at openjdk.org Sat Sep 20 04:53:13 2025 From: gli at openjdk.org (Guoxiong Li) Date: Sat, 20 Sep 2025 04:53:13 GMT Subject: RFR: 8368006: Parallel: Skip full regions in dense prefix during Full GC [v2] In-Reply-To: <0gXhjgdxG3MgUvM3qE-pYFlPrx64Tmwf4l2gzSJ617A=.b4572760-7b74-4dab-9c52-ae169c4504f2@github.com> References: <0gXhjgdxG3MgUvM3qE-pYFlPrx64Tmwf4l2gzSJ617A=.b4572760-7b74-4dab-9c52-ae169c4504f2@github.com> Message-ID: On Fri, 19 Sep 2025 15:09:25 GMT, Albert Mingkun Yang wrote: >> Implement skip-full-region optimization for filler related operations on dense-prefix. I constrained the filler-creation task to a single worker for simpler implementation. During the compaction phase, the most expensive part is almost always the non-dense-prefix part, so letting the rest of workers to start with the expensive tasks seems sensible. >> >> Synthetic bms shows good reduction in full-gc time in debug build; perf-neutral for other bms (specjvm2008,specjbb2015) in release build. >> >> Test: tier1-5 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - review > - Merge branch 'master' into pgc-skip-full-region > - pgc-skip-full-region Looks good. ------------- Marked as reviewed by gli (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27369#pullrequestreview-3248365684 From iwalulya at openjdk.org Sun Sep 21 06:24:13 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Sun, 21 Sep 2025 06:24:13 GMT Subject: RFR: 8368086: G1: Use ThreadsClaimTokenScope in G1CMRemarkTask In-Reply-To: <5Cfv_IvHP9XylALnSg_uAMfi8TPD6r5Nc4G1Bpc7rjA=.6176dce7-fd51-465b-a846-b797922b5ce7@github.com> References: <5Cfv_IvHP9XylALnSg_uAMfi8TPD6r5Nc4G1Bpc7rjA=.6176dce7-fd51-465b-a846-b797922b5ce7@github.com> Message-ID: On Fri, 19 Sep 2025 09:16:47 GMT, Albert Mingkun Yang wrote: > Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `G1ConcurrentMark::finalize_marking` to be more precise with what is actually needed and why. > > Test: tier1 Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27385#pullrequestreview-3249410705 From ghan at openjdk.org Sun Sep 21 23:59:24 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Sun, 21 Sep 2025 23:59:24 GMT Subject: RFR: 8368089: G1: G1PeriodicGCTask::should_start_periodic_gc may use uninitialised value if os::loadavg is unsupported Message-ID: <2OvCoQTGiaeASeEzeH7nPlNrqKuVBG4coqXf7FOqEc8=.1071778b-0427-4736-8d2c-4718b85081ca@github.com> Please review this change. Thanks! **Description:** Previously the check combined loadavg() failure and threshold comparison in a single condition. When os::loadavg() returned -1, `recent_load` contained an undefined value but was still logged as if it was a real load average, leading to misleading log output. **Fix:** This change separates the failure case from the combined check: - If os::loadavg() returns -1, log "System loadavg not supported" and skip. - Only compare `recent_load` to the threshold when loadavg() succeeds. **Test:** GHA ------------- Commit messages: - 8368089: G1: G1PeriodicGCTask::should_start_periodic_gc may use uninitialised value if os::loadavg is unsupported Changes: https://git.openjdk.org/jdk/pull/27413/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27413&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368089 Stats: 10 lines in 1 file changed: 5 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27413.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27413/head:pull/27413 PR: https://git.openjdk.org/jdk/pull/27413 From aboldtch at openjdk.org Mon Sep 22 05:09:31 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 22 Sep 2025 05:09:31 GMT Subject: RFR: 8368087: ZGC: Make ZStatLoad::print() logging conditional on os::loadavg support In-Reply-To: <7olPMO9LfpilQXoHcajv0nHeiBaZVycm9xBkD6UJV_4=.fc000130-5cf3-4554-9391-fe925552d2f6@github.com> References: <7olPMO9LfpilQXoHcajv0nHeiBaZVycm9xBkD6UJV_4=.fc000130-5cf3-4554-9391-fe925552d2f6@github.com> Message-ID: On Fri, 19 Sep 2025 10:59:00 GMT, Axel Boldt-Christmas wrote: > ZStatLoad::print() logs the load average on the machine, however it does not check whether the operation is supported or not. This results in printing a load average of 0/0/0 on Windows which is a bit misleading. Thanks for the reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/27389#issuecomment-3316819621 From aboldtch at openjdk.org Mon Sep 22 05:09:32 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 22 Sep 2025 05:09:32 GMT Subject: Integrated: 8368087: ZGC: Make ZStatLoad::print() logging conditional on os::loadavg support In-Reply-To: <7olPMO9LfpilQXoHcajv0nHeiBaZVycm9xBkD6UJV_4=.fc000130-5cf3-4554-9391-fe925552d2f6@github.com> References: <7olPMO9LfpilQXoHcajv0nHeiBaZVycm9xBkD6UJV_4=.fc000130-5cf3-4554-9391-fe925552d2f6@github.com> Message-ID: On Fri, 19 Sep 2025 10:59:00 GMT, Axel Boldt-Christmas wrote: > ZStatLoad::print() logs the load average on the machine, however it does not check whether the operation is supported or not. This results in printing a load average of 0/0/0 on Windows which is a bit misleading. This pull request has now been integrated. Changeset: a1b43c30 Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/a1b43c3046ecf42fd5b8f40274625cae120b3a3c Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod 8368087: ZGC: Make ZStatLoad::print() logging conditional on os::loadavg support Reviewed-by: eosterlund, stefank, jsikstro ------------- PR: https://git.openjdk.org/jdk/pull/27389 From aboldtch at openjdk.org Mon Sep 22 05:35:25 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 22 Sep 2025 05:35:25 GMT Subject: RFR: 8367298: ZGC: Enhance zaddress type system's assert messages [v2] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 05:18:14 GMT, Axel Boldt-Christmas wrote: >> ZGC uses a family of strongly type integral types to test and verify invariants for addresses, offset, indices and colored pointers within the heap. It is usually the first place we hit an assert if something goes wrong, and looking at the actual value is often enough to identify if it is memory corruption, a broken color invariant or a mistake in the use of the type system. >> >> Unfortunately not all asserts print the value in the assert message, requiring more extensive investigation to even identify the nature of the problem. >> >> I propose we enhance all our zaddress assert printing to always include the invariant breaking value. >> >> _While I chose to print the max values in the assert message of the offset and indices checks, I did not print the colors in the zpointer checks. Both colors and the max values are easily available in the error report, so it would only really be a problem if a hs_err file is missing._ >> >> We should probably also see if we can enhance all the rest of our asserts in ZGC similarly. I do not think I have ever seen a failed invariant check and thought "Why are we printing the invariant breaking value", but often feel that it is unfortunate that we did not print the actual value. > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/share/gc/z/zAddress.inline.hpp > > Co-authored-by: Stefan Karlsson Thanks for the reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/27184#issuecomment-3317004862 From aboldtch at openjdk.org Mon Sep 22 05:35:26 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 22 Sep 2025 05:35:26 GMT Subject: Integrated: 8367298: ZGC: Enhance zaddress type system's assert messages In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 05:55:42 GMT, Axel Boldt-Christmas wrote: > ZGC uses a family of strongly type integral types to test and verify invariants for addresses, offset, indices and colored pointers within the heap. It is usually the first place we hit an assert if something goes wrong, and looking at the actual value is often enough to identify if it is memory corruption, a broken color invariant or a mistake in the use of the type system. > > Unfortunately not all asserts print the value in the assert message, requiring more extensive investigation to even identify the nature of the problem. > > I propose we enhance all our zaddress assert printing to always include the invariant breaking value. > > _While I chose to print the max values in the assert message of the offset and indices checks, I did not print the colors in the zpointer checks. Both colors and the max values are easily available in the error report, so it would only really be a problem if a hs_err file is missing._ > > We should probably also see if we can enhance all the rest of our asserts in ZGC similarly. I do not think I have ever seen a failed invariant check and thought "Why are we printing the invariant breaking value", but often feel that it is unfortunate that we did not print the actual value. This pull request has now been integrated. Changeset: 5efaa997 Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/5efaa9970ace463f7d9bcd8f4028b1d60665cfad Stats: 19 lines in 1 file changed: 0 ins; 0 del; 19 mod 8367298: ZGC: Enhance zaddress type system's assert messages Reviewed-by: stefank, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/27184 From tschatzl at openjdk.org Mon Sep 22 05:50:59 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 22 Sep 2025 05:50:59 GMT Subject: RFR: 8368080: G1: Unnecessary initialization of G1CMTask's mark stats table Message-ID: <0dkuTBZ3PXS9So1rs2Ah-SD4_VYK8eC4hxBgY5AaEsI=.06485f44-bf02-4714-90b8-4c424507c3ab@github.com> Hi all, please review this tiny change that leaves out resetting the mark stat caches at startup. This has some (somewhat tiny, depending on heap size and number of threads) positive impact on startup time. Testing: tier1-5, gha Thanks, Thomas ------------- Commit messages: - 8368080 Changes: https://git.openjdk.org/jdk/pull/27390/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27390&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368080 Stats: 4 lines in 3 files changed: 3 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27390.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27390/head:pull/27390 PR: https://git.openjdk.org/jdk/pull/27390 From aboldtch at openjdk.org Mon Sep 22 06:07:21 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 22 Sep 2025 06:07:21 GMT Subject: RFR: 8368212: ZGC: Fix spelling and typos in comments Message-ID: Trivial fix of a hand full of comments which have typos or miss-spellings. Only fix obvious miss-spellings, not American vs British vs colloquial inconsistencies, nor englishified jargon. ------------- Commit messages: - 8368212: ZGC: Fix spelling and typos in comments Changes: https://git.openjdk.org/jdk/pull/27416/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27416&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368212 Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27416.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27416/head:pull/27416 PR: https://git.openjdk.org/jdk/pull/27416 From aboldtch at openjdk.org Mon Sep 22 06:07:26 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 22 Sep 2025 06:07:26 GMT Subject: RFR: 8368213: ZGC: Cleanup dead code, unimplemented declarations, unused private fields Message-ID: <-g7JdRe2ACZ_C1YvHLX44_daCravBY9lfGTjUaC-5_4=.205643b1-7098-4d3b-a4f1-4368252c4eb8@github.com> Over the last years refactoring and bug fixes a bit of dead code has slipped through. Clean up some of this. Purposely do not touch unused public declarations with an implementation (most if not all are trivial property checks or simple constructions which have negligible maintenance cost to keep.) nor unused public typedefs. The `is_high_usage` helper was rewritten to take a boolean rather than an optional templated print function pointer, as there was only one usage (a lambda which captured nothing). Also updated `GCThreadLocalData` size to reflect the changes that has occurred over time. Maybe we can derive this size from all the implementors in the future, but may be to hard to do in a non hack-y way. * Testing * Running ZGC test tier 1-5 on Oracle supported platforms. ------------- Commit messages: - 8368213: ZGC: Cleanup dead code, unimplemented declarations, unused private fields Changes: https://git.openjdk.org/jdk/pull/27415/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27415&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368213 Stats: 46 lines in 9 files changed: 1 ins; 36 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/27415.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27415/head:pull/27415 PR: https://git.openjdk.org/jdk/pull/27415 From jsikstro at openjdk.org Mon Sep 22 06:53:14 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Mon, 22 Sep 2025 06:53:14 GMT Subject: RFR: 8368212: ZGC: Fix spelling and typos in comments In-Reply-To: References: Message-ID: <2GaDNjAkLpOlZDzmVqYKVuqR7MJBwzy38ZBrQ5VtJW0=.414955bd-0561-438a-8469-5cb6b18a0b30@github.com> On Mon, 22 Sep 2025 05:59:03 GMT, Axel Boldt-Christmas wrote: > Trivial fix of a hand full of comments which have typos or miss-spellings. Only fix obvious miss-spellings, not American vs British vs colloquial inconsistencies, nor englishified jargon. Marked as reviewed by jsikstro (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27416#pullrequestreview-3250836292 From iwalulya at openjdk.org Mon Sep 22 07:15:22 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 22 Sep 2025 07:15:22 GMT Subject: RFR: 8368080: G1: Unnecessary initialization of G1CMTask's mark stats table In-Reply-To: <0dkuTBZ3PXS9So1rs2Ah-SD4_VYK8eC4hxBgY5AaEsI=.06485f44-bf02-4714-90b8-4c424507c3ab@github.com> References: <0dkuTBZ3PXS9So1rs2Ah-SD4_VYK8eC4hxBgY5AaEsI=.06485f44-bf02-4714-90b8-4c424507c3ab@github.com> Message-ID: On Fri, 19 Sep 2025 11:49:59 GMT, Thomas Schatzl wrote: > Hi all, > > please review this tiny change that leaves out resetting the mark stat caches at startup. > > This has some (somewhat tiny, depending on heap size and number of threads) positive impact on startup time. > > Testing: tier1-5, gha > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27390#pullrequestreview-3250900854 From stefank at openjdk.org Mon Sep 22 07:27:00 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 22 Sep 2025 07:27:00 GMT Subject: RFR: 8368213: ZGC: Cleanup dead code, unimplemented declarations, unused private fields In-Reply-To: <-g7JdRe2ACZ_C1YvHLX44_daCravBY9lfGTjUaC-5_4=.205643b1-7098-4d3b-a4f1-4368252c4eb8@github.com> References: <-g7JdRe2ACZ_C1YvHLX44_daCravBY9lfGTjUaC-5_4=.205643b1-7098-4d3b-a4f1-4368252c4eb8@github.com> Message-ID: <8Mx03elcxI8hjQhFTC3r53jpOsJSsgvEsDVECNhvezI=.44d21429-0c20-4bab-988c-94897f6e36be@github.com> On Mon, 22 Sep 2025 05:58:14 GMT, Axel Boldt-Christmas wrote: > Over the last years refactoring and bug fixes a bit of dead code has slipped through. Clean up some of this. Purposely do not touch unused public declarations with an implementation (most if not all are trivial property checks or simple constructions which have negligible maintenance cost to keep.) nor unused public typedefs. > > The `is_high_usage` helper was rewritten to take a boolean rather than an optional templated print function pointer, as there was only one usage (a lambda which captured nothing). > > Also updated `GCThreadLocalData` size to reflect the changes that has occurred over time. Maybe we can derive this size from all the implementors in the future, but may be to hard to do in a non hack-y way. > > * Testing > * Running ZGC test tier 1-5 on Oracle supported platforms. Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27415#pullrequestreview-3250935166 From ayang at openjdk.org Mon Sep 22 07:28:16 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 22 Sep 2025 07:28:16 GMT Subject: RFR: 8071277: G1: Merge commits and uncommits of contiguous memory In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 07:01:00 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to G1 commit/uncommit to merge commit/uncommit calls to the operating system as much as possible. This significantly improves startup performanc > > Performance results before/after on Zen3 processor for a "HelloWorld" application: > > > $ hyperfine -w 10 -r 10 "baseline/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello" > Benchmark 1: baseline/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello > Time (mean ? ?): 16.4 ms ? 0.4 ms [User: 11.0 ms, System: 14.4 ms] > Range (min ? max): 15.7 ms ? 16.8 ms 10 runs > > $ hyperfine -w 10 -r 10 "baseline/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello" > Benchmark 1: baseline/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello > Time (mean ? ?): 24.7 ms ? 0.4 ms [User: 10.7 ms, System: 22.7 ms] > Range (min ? max): 24.2 ms ? 25.4 ms 10 runs > > My reimplementation of JDK-8071277 does show improvements here: > > $ hyperfine -w 10 -r 10 "changes/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello" > Benchmark 1: changes/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello > Time (mean ? ?): 15.9 ms ? 0.4 ms [User: 11.9 ms, System: 13.1 ms] > Range (min ? max): 15.4 ms ? 16.7 ms 10 runs > > $ hyperfine -w 10 -r 10 "changes/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello" > Benchmark 1: changes/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello > Time (mean ? ?): 19.7 ms ? 0.3 ms [User: 11.3 ms, System: 17.4 ms] > Range (min ? max): 19.2 ms ? 20.1 ms 10 runs > > > I.e., depending on actually committed heap size (`-Xms`), reduction of startup time by 20% or so in above cases. > > Testing: tier1-5, gha > > Thanks, > Thomas src/hotspot/share/gc/g1/g1RegionToSpaceMapper.cpp line 247: > 245: } > 246: }; > 247: RangeApplicator range(commit_range); The use of higher-order-function here makes the code/flow a bit harder to follow. If the goal is to identify consecutive committed/uncommitted regions, I wonder if one do sth like: for (size_t page = start_page; page <= end_page; /* empty */) { uncommitted_l = find_first_uncommitted(); uncommitted_r = find_first_committed(); commit_range(uncommitted_l, uncommitted_r); page = uncommitted_r + 1; } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27381#discussion_r2366961486 From stefank at openjdk.org Mon Sep 22 07:28:15 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 22 Sep 2025 07:28:15 GMT Subject: RFR: 8368212: ZGC: Fix spelling and typos in comments In-Reply-To: References: Message-ID: <7tN2RjIiCV6lFgohDSMxR4OG8omm-ps90__-p_s9NmM=.25b9633c-8caf-4ba6-ab62-2cd34914d869@github.com> On Mon, 22 Sep 2025 05:59:03 GMT, Axel Boldt-Christmas wrote: > Trivial fix of a hand full of comments which have typos or miss-spellings. Only fix obvious miss-spellings, not American vs British vs colloquial inconsistencies, nor englishified jargon. Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27416#pullrequestreview-3250940514 From shade at openjdk.org Mon Sep 22 07:45:16 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 22 Sep 2025 07:45:16 GMT Subject: RFR: 8368080: G1: Unnecessary initialization of G1CMTask's mark stats table In-Reply-To: <0dkuTBZ3PXS9So1rs2Ah-SD4_VYK8eC4hxBgY5AaEsI=.06485f44-bf02-4714-90b8-4c424507c3ab@github.com> References: <0dkuTBZ3PXS9So1rs2Ah-SD4_VYK8eC4hxBgY5AaEsI=.06485f44-bf02-4714-90b8-4c424507c3ab@github.com> Message-ID: On Fri, 19 Sep 2025 11:49:59 GMT, Thomas Schatzl wrote: > Hi all, > > please review this tiny change that leaves out resetting the mark stat caches at startup. > > This has some (somewhat tiny, depending on heap size and number of threads) positive impact on startup time. > > Testing: tier1-5, gha > > Thanks, > Thomas Question: There is a use of `G1RegionMarkStatsCache` in `G1CMTask` (responsible for concurrent marking as well?) -- shouldn't the reset happen on that path as well? If so, and testing did not caught it, there should be some sort of assert somewhere? ------------- PR Review: https://git.openjdk.org/jdk/pull/27390#pullrequestreview-3251000752 From ayang at openjdk.org Mon Sep 22 07:58:03 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 22 Sep 2025 07:58:03 GMT Subject: RFR: 8368086: G1: Use ThreadsClaimTokenScope in G1CMRemarkTask In-Reply-To: <5Cfv_IvHP9XylALnSg_uAMfi8TPD6r5Nc4G1Bpc7rjA=.6176dce7-fd51-465b-a846-b797922b5ce7@github.com> References: <5Cfv_IvHP9XylALnSg_uAMfi8TPD6r5Nc4G1Bpc7rjA=.6176dce7-fd51-465b-a846-b797922b5ce7@github.com> Message-ID: <5gW_3rpOFIQhJ3dEvCPhSb8yME7MLYob7vRKDGg21DA=.88d0f754-baa1-4f31-babb-4a23c5959341@github.com> On Fri, 19 Sep 2025 09:16:47 GMT, Albert Mingkun Yang wrote: > Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `G1ConcurrentMark::finalize_marking` to be more precise with what is actually needed and why. > > Test: tier1 Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27385#issuecomment-3317423480 From ayang at openjdk.org Mon Sep 22 07:58:04 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 22 Sep 2025 07:58:04 GMT Subject: Integrated: 8368086: G1: Use ThreadsClaimTokenScope in G1CMRemarkTask In-Reply-To: <5Cfv_IvHP9XylALnSg_uAMfi8TPD6r5Nc4G1Bpc7rjA=.6176dce7-fd51-465b-a846-b797922b5ce7@github.com> References: <5Cfv_IvHP9XylALnSg_uAMfi8TPD6r5Nc4G1Bpc7rjA=.6176dce7-fd51-465b-a846-b797922b5ce7@github.com> Message-ID: On Fri, 19 Sep 2025 09:16:47 GMT, Albert Mingkun Yang wrote: > Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `G1ConcurrentMark::finalize_marking` to be more precise with what is actually needed and why. > > Test: tier1 This pull request has now been integrated. Changeset: 44454633 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/44454633eb163de17bba939e84311e8d954a2f53 Stats: 5 lines in 1 file changed: 2 ins; 2 del; 1 mod 8368086: G1: Use ThreadsClaimTokenScope in G1CMRemarkTask Reviewed-by: fandreuzzi, stefank, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/27385 From ayang at openjdk.org Mon Sep 22 08:07:19 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 22 Sep 2025 08:07:19 GMT Subject: RFR: 8363932: G1: Better distribute KlassCleaningTask In-Reply-To: <4wv4YEc8jXOrh142RF4lbiAOx5HSEe8tcDc-BYQC-5I=.461e968b-21dd-493e-9dfb-dcc9f962700a@github.com> References: <4wv4YEc8jXOrh142RF4lbiAOx5HSEe8tcDc-BYQC-5I=.461e968b-21dd-493e-9dfb-dcc9f962700a@github.com> Message-ID: On Tue, 16 Sep 2025 15:54:19 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to parallel klass cleaning to improve performance. > > The current implementation only parallelizes cleaning of weak class links, while the main work, cleaning the object tree is single-threaded. Hence in practice, the current mechanism does not scale beyond 2-3 threads. > > Cleaning an object graph in an application that loads some jars and instantiates central classes within them, with around 180k classes the current `G1 Complete Cleaning` task (which executes this code) can take 80ms (with 25 threads). > > The suggested change is to walk the object graph by (live) `ClassLoaderData` klass by klass, fixing only the links of that particular klass. > > E.g. > > CLD1 has klasses A, B, C, CLD2 has klasses a, b, c and CLD3 has klasses 0, 1, 2, 4; > vertical links are subklass references, while horizontal links are sibling references. > > j.l.O > | > A - B - c - 3 > | > 0 - 2 - C - 1 > > > CLD 3 is dead. Thread 1 claims CLD 1, Thread 2 claims CLD 2 (and nobody claims CLD3 because it's dead). > > So thread 1, when reaching `A` fixes its subklass link to `C`, and otherwise does nothing with `A`. When looking at `C`, it will remove the link to `1`. > Thread 2 will only remove the link to `3` of `c`. > > The result is > > j.l.O > | > A - B - c > | > C > > > There should be no unnecessary object graph walking. > > There is a slight change in printing during unlinking: previously the code, when cleaning subklasses it printed `unlinking class (subclass)`for every class that has been removed on the way to the next live one. In above case, it would print > > > unlinking class (subclass): 0 > unlinking class (subclass): 2 > > > With the change, to avoid following the subklasses of the graph twice, it prints > > > ?unlinking class (subclass): 0 > unlinking class (sibling): 0 > > > because the string in brackets is the actual link that is followed. I can revert that change. > > With the change "Complete Cleaning" time for 200k classes takes 7.6ms (The test is a bit random on when it does the class unloading). > > Testing: tier1-5 > > Thanks, > Thomas Preexisting: These two methods, `subklass` and `next_sibling`, sounds like plain getters, but they actually query liveness and skip dead klasses. I wonder whether it's possible to prune dead klasses in one go at some place and turn these two methods into plain getters. src/hotspot/share/gc/shared/parallelCleaning.hpp line 57: > 55: // Cleans out the Klass tree from stale data. > 56: class KlassCleaningTask : public StackObj { > 57: ClassLoaderDataGraphIteratorAtomic _cld_iterator; I suggest adding `_atomic` suffix to the field name. ------------- PR Review: https://git.openjdk.org/jdk/pull/27316#pullrequestreview-3250946195 PR Review Comment: https://git.openjdk.org/jdk/pull/27316#discussion_r2366965395 From tschatzl at openjdk.org Mon Sep 22 08:36:06 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 22 Sep 2025 08:36:06 GMT Subject: RFR: 8368089: G1: G1PeriodicGCTask::should_start_periodic_gc may use uninitialised value if os::loadavg is unsupported In-Reply-To: <2OvCoQTGiaeASeEzeH7nPlNrqKuVBG4coqXf7FOqEc8=.1071778b-0427-4736-8d2c-4718b85081ca@github.com> References: <2OvCoQTGiaeASeEzeH7nPlNrqKuVBG4coqXf7FOqEc8=.1071778b-0427-4736-8d2c-4718b85081ca@github.com> Message-ID: <_gLPNsB7JD-agIZjuNQoAOmm5WRG-jmIJT0Za2EgAJY=.8d186386-835e-49c7-8ba2-81752125d153@github.com> On Sun, 21 Sep 2025 23:52:15 GMT, Guanqiang Han wrote: > Please review this change. Thanks! > > **Description:** > > Previously the check combined loadavg() failure and threshold comparison in a single condition. When os::loadavg() returned -1, `recent_load` contained an undefined value but was still logged as if it was a real load average, leading to misleading log output. > > **Fix:** > > This change separates the failure case from the combined check: > - If os::loadavg() returns -1, log "System loadavg not supported" and skip. > - Only compare `recent_load` to the threshold when loadavg() succeeds. > > **Test:** > > GHA src/hotspot/share/gc/g1/g1PeriodicGCTask.cpp line 61: > 59: log_debug(gc, periodic)("System loadavg not supported. Skipping."); > 60: return false; > 61: } is `os::loadavg` support something that is fixed for a given run? It would maybe be nicer to fail the VM if `G1PeriodicGCSystemLoadThreshold` is set but `os::loadavg()` not supported. Or start with a warning and disable the functionality instead of printing the message over and over again. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27413#discussion_r2367119989 From xpeng at openjdk.org Mon Sep 22 08:46:32 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 22 Sep 2025 08:46:32 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation Message-ID: Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of mutator memory allocation to improve heap lock contention, at vey high level, here is how it works: * ShenandoahFreeSet holds a N (default to 13) number of ShenandoahHeapRegion* which are used by mutator threads for regular object allocations, they are called shared regions/directly allocatable regions, which are stored in PaddedEnd data structure(padded array). * Each mutator thread will be assigned one of the directly allocatable regions, the thread will try to allocate in the directly allocatable region with CAS atomic operation, if fails will try 2 more consecutive directly allocatable regions in the array storing directly allocatable region. * If mutator thread fails after trying 3 directly allocatable regions, it will: * Take heap lock * Try to retire the directly allocatable regions which are ready to retire. * Iterator mutator partition and allocate directly allocatable regions and store to the padded array if any need to be retired. * Satisfy mutator allocation request if possible. I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, I have done many tests, here are some of them: 1. Dacapo lusearch test on EC2 host with 96 CPU cores: Openjdk TIP: [ec2-user at ip-172-31-42-91 jdk]$ ./master-jdk/bin/java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms4G -Xmx4G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" ===== DaCapo tail latency, metered full smoothing: 50% 131684 usec, 90% 200192 usec, 99% 211369 usec, 99.9% 212517 usec, 99.99% 213043 usec, max 235289 usec, measured over 524288 events ===== ===== DaCapo tail latency, metered full smoothing: 50% 1568 usec, 90% 36101 usec, 99% 42172 usec, 99.9% 42928 usec, 99.99% 43100 usec, max 43305 usec, measured over 524288 events ===== ===== DaCapo tail latency, metered full smoothing: 50% 52644 usec, 90% 124393 usec, 99% 137711 usec, 99.9% 139355 usec, 99.99% 139749 usec, max 146722 usec, measured over 524288 events ===== ===== DaCapo tail latency, metered full smoothing: 50% 28623 usec, 90% 67126 usec, 99% 73916 usec, 99.9% 75175 usec, 99.99% 75462 usec, max 79066 usec, measured over 524288 events ===== ===== DaCapo tail latency, metered full smoothing: 50% 41 usec, 90% 9428 usec, 99% 21770 usec, 99.9% 23106 usec, 99.99% 23443 usec, max 24179 usec, measured over 524288 events ===== ===== DaCapo tail latency, metered full smoothing: 50% 44215 usec, 90% 89790 usec, 99% 96317 usec, 99.9% 97160 usec, 99.99% 97447 usec, max 101699 usec, measured over 524288 events ===== ===== DaCapo tail latency, metered full smoothing: 50% 5760 usec, 90% 55041 usec, 99% 66487 usec, 99.9% 67538 usec, 99.99% 67993 usec, max 75581 usec, measured over 524288 events ===== ===== DaCapo tail latency, metered full smoothing: 50% 44 usec, 90% 10890 usec, 99% 23198 usec, 99.9% 24500 usec, 99.99% 24880 usec, max 25787 usec, measured over 524288 events ===== ===== DaCapo tail latency, metered full smoothing: 50% 173 usec, 90% 28241 usec, 99% 44742 usec, 99.9% 46328 usec, 99.99% 46815 usec, max 51731 usec, measured over 524288 events ===== ===== DaCapo tail latency, metered full smoothing: 50% 3386 usec, 90% 52216 usec, 99% 65358 usec, 99.9% 67119 usec, 99.99% 67612 usec, max 75257 usec, measured over 524288 events ===== With CAS allocator: [ec2-user at ip-172-31-42-91 jdk]$ ./cas-alloc-jdk/bin/java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms4G -Xmx4G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" ===== DaCapo tail latency, metered full smoothing: 50% 116096 usec, 90% 181392 usec, 99% 194708 usec, 99.9% 197017 usec, 99.99% 198255 usec, max 209449 usec, measured over 524288 events ===== ===== DaCapo tail latency, metered full smoothing: 50% 26 usec, 90% 205 usec, 99% 2192 usec, 99.9% 5521 usec, 99.99% 9909 usec, max 20341 usec, measured over 524288 events ===== ===== DaCapo tail latency, metered full smoothing: 50% 30 usec, 90% 206 usec, 99% 819 usec, 99.9% 6330 usec, 99.99% 18174 usec, max 26832 usec, measured over 524288 events ===== ===== DaCapo tail latency, metered full smoothing: 50% 26 usec, 90% 188 usec, 99% 770 usec, 99.9% 9462 usec, 99.99% 14628 usec, max 20693 usec, measured over 524288 events ===== ===== DaCapo tail latency, metered full smoothing: 50% 26 usec, 90% 191 usec, 99% 793 usec, 99.9% 9579 usec, 99.99% 15123 usec, max 18807 usec, measured over 524288 events ===== ===== DaCapo tail latency, metered full smoothing: 50% 30 usec, 90% 211 usec, 99% 654 usec, 99.9% 5401 usec, 99.99% 14597 usec, max 30266 usec, measured over 524288 events ===== ===== DaCapo tail latency, metered full smoothing: 50% 27 usec, 90% 196 usec, 99% 794 usec, 99.9% 4499 usec, 99.99% 21784 usec, max 32097 usec, measured over 524288 events ===== ===== DaCapo tail latency, metered full smoothing: 50% 32 usec, 90% 236 usec, 99% 546 usec, 99.9% 4874 usec, 99.99% 17115 usec, max 24615 usec, measured over 524288 events ===== ===== DaCapo tail latency, metered full smoothing: 50% 30 usec, 90% 202 usec, 99% 698 usec, 99.9% 7301 usec, 99.99% 12966 usec, max 14096 usec, measured over 524288 events ===== ===== DaCapo tail latency, metered full smoothing: 50% 26 usec, 90% 193 usec, 99% 740 usec, 99.9% 5625 usec, 99.99% 16836 usec, max 22915 usec, measured over 524288 events ===== Same tests, if I run it on smaller instance with less CPU cores, the improvement is much less. 2. specJBB2015 on EC2 with 2 cores, 4G heap: OpenJDK tip jbb2015.result.category = SPECjbb2015-Composite jbb2015.result.group.count = 1 jbb2015.result.metric.max-jOPS = 2801 jbb2015.result.metric.critical-jOPS = 1463 jbb2015.result.SLA-10000-jOPS = 967 jbb2015.result.SLA-25000-jOPS = 1260 jbb2015.result.SLA-50000-jOPS = 1532 jbb2015.result.SLA-75000-jOPS = 1861 jbb2015.result.SLA-100000-jOPS = 1927 With CAS allocator: jbb2015.result.category = SPECjbb2015-Composite jbb2015.result.group.count = 1 jbb2015.result.metric.max-jOPS = 2965 jbb2015.result.metric.critical-jOPS = 1487 jbb2015.result.SLA-10000-jOPS = 906 jbb2015.result.SLA-25000-jOPS = 1197 jbb2015.result.SLA-50000-jOPS = 1692 jbb2015.result.SLA-75000-jOPS = 1867 jbb2015.result.SLA-100000-jOPS = 2125 2. specJBB2015 on EC2 with 16 cores, 31G heap: OpenJDK tip: jbb2015.result.category = SPECjbb2015-Composite jbb2015.result.group.count = 1 jbb2015.result.metric.max-jOPS = 26740 jbb2015.result.metric.critical-jOPS = 22588 jbb2015.result.SLA-10000-jOPS = 15998 jbb2015.result.SLA-25000-jOPS = 23140 jbb2015.result.SLA-50000-jOPS = 24454 jbb2015.result.SLA-75000-jOPS = 25094 jbb2015.result.SLA-100000-jOPS = 25882 With CAS allocator: jbb2015.result.category = SPECjbb2015-Composite jbb2015.result.group.count = 1 jbb2015.result.metric.max-jOPS = 28454 jbb2015.result.metric.critical-jOPS = 23763 jbb2015.result.SLA-10000-jOPS = 16284 jbb2015.result.SLA-25000-jOPS = 24511 jbb2015.result.SLA-50000-jOPS = 25882 jbb2015.result.SLA-75000-jOPS = 26911 jbb2015.result.SLA-100000-jOPS = 27254 ### Other tests: - [x] All Shenandoah jtreg tests ------------- Commit messages: - Merge branch 'master' into cas-alloc-1 - Move ShenandoahHeapRegionIterationClosure to shenandoahFreeSet.hpp - Merge branch 'openjdk:master' into cas-alloc-1 - Fix errors caused by renaming ofAtomic to AtomicAccess - Merge branch 'openjdk:master' into cas-alloc-1 - Remove unused flag - Merge branch 'openjdk:master' into cas-alloc-1 - Merge branch 'cas-alloc-1' into cas-alloc - Merge branch 'cas-alloc-1' of https://github.com/pengxiaolong/jdk into cas-alloc-1 - Merge branch 'master' into cas-alloc-1 - ... and 120 more: https://git.openjdk.org/jdk/compare/44454633...087b54fb Changes: https://git.openjdk.org/jdk/pull/26171/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361099 Stats: 735 lines in 16 files changed: 674 ins; 7 del; 54 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From kdnilsen at openjdk.org Mon Sep 22 08:46:40 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 22 Sep 2025 08:46:40 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 19:56:30 GMT, Xiaolong Peng wrote: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of mutator memory allocation to improve heap lock contention, at vey high level, here is how it works: > * ShenandoahFreeSet holds a N (default to 13) number of ShenandoahHeapRegion* which are used by mutator threads for regular object allocations, they are called shared regions/directly allocatable regions, which are stored in PaddedEnd data structure(padded array). > * Each mutator thread will be assigned one of the directly allocatable regions, the thread will try to allocate in the directly allocatable region with CAS atomic operation, if fails will try 2 more consecutive directly allocatable regions in the array storing directly allocatable region. > * If mutator thread fails after trying 3 directly allocatable regions, it will: > * Take heap lock > * Try to retire the directly allocatable regions which are ready to retire. > * Iterator mutator partition and allocate directly allocatable regions and store to the padded array if any need to be retired. > * Satisfy mutator allocation request if possible. > > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, I have done many tests, here are some of them: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores: > Openjdk TIP: > > [ec2-user at ip-172-31-42-91 jdk]$ ./master-jdk/bin/java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms4G -Xmx4G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > ===== DaCapo tail latency, metered full smoothing: 50% 131684 usec, 90% 200192 usec, 99% 211369 usec, 99.9% 212517 usec, 99.99% 213043 usec, max 235289 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 1568 usec, 90% 36101 usec, 99% 42172 usec, 99.9% 42928 usec, 99.99% 43100 usec, max 43305 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 52644 usec, 90% 124393 usec, 99% 137711 usec, 99.9% 139355 usec, 99.99% 139749 usec, max 146722 usec, measured over 524288 events ====... Thanks for doing this work. It is huge progress. I've left a number of comments. I didn't have time to study/comment on all of the code, as I am out-of-office for rest of this week. I'll look more when I return. src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 246: > 244: _leftmosts_empty[int(ShenandoahFreeSetPartitionId::Mutator)] = mutator_leftmost_empty; > 245: _rightmosts_empty[int(ShenandoahFreeSetPartitionId::Mutator)] = mutator_rightmost_empty; > 246: We have the heap lock here, so should not need to use atomic store operations. Atomic operations have a performance penalty that I think we want to avoid. src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 247: > 245: _rightmosts_empty[int(ShenandoahFreeSetPartitionId::Mutator)] = mutator_rightmost_empty; > 246: > 247: Atomic::store(_region_counts + int(ShenandoahFreeSetPartitionId::Mutator), mutator_region_count); If we do need to use Atomic operations, would prefer &_region_counts[int(ShenandoahFreeSetPartitionId::Mutator)] notation for the array elements. src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 282: > 280: > 281: void ShenandoahRegionPartitions::increase_used(ShenandoahFreeSetPartitionId which_partition, size_t bytes) { > 282: shenandoah_assert_heaplocked(); Are you now calling this directly from the CAS allocators? So you want to not have to assert heap locked and that is why we make the used accounting atomic? My preference would be to avoid this need by counting the entire region as used at the time the region becomes directly allocatable. src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 615: > 613: size_t capacity = _free_set->alloc_capacity(i); > 614: bool is_empty = (capacity == _region_size_bytes); > 615: // TODO remove assert, not possible to pass when allow mutator to allocate w/o lock. Probably the preferred approach here is to "pre-retire" regions when they are made directly allocatable. When the region is pre-retired, it is taken out of the partition, so assert_bounds no longer applies to this region. src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 2151: > 2149: > 2150: template > 2151: HeapWord* ShenandoahFreeSet::par_allocate_single_for_mutator(ShenandoahAllocRequest &req, bool &in_new_region) { Not clear to me what prefix par_ represents. Parallel allocate (without lock?) src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 2168: > 2166: for (uint i = 0u; i < max_probes; i++) { > 2167: ShenandoahHeapRegion** shared_region_address = _directly_allocatable_regions + idx; > 2168: ShenandoahHeapRegion* r = Atomic::load_acquire(shared_region_address); This code has a lot more synchronization overhead than what is required for CAS allocations. load_acquire() forces a memory fence. All writes performed by other threads before the store_release() must be visible to this thread upon return from load_acquire. I would like to see some documentation that describes the coherency model that we assume/require here. Can we write this up as a comment in the header file? Personal preference: I think there are many situations where we get better performance if we allow ourselves to see slightly old data, and we can argue that the slightly old data is "harmless". For example, if some other thread replaces the directly_allocatable_region[N] while we're attempting to allocate from directly_allocatable_region[N], we might attempt to allocate from the original region and fail. That's harmless. We'll just retry at the next probe point. If multiple probes fail to allocate, we'll take the synchronization lock and everything will be resolved there. The accumulation of atomic volatile access has a big impact on performance. I've measured this in previous experiments. You can do the same. src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 2191: > 2189: } > 2190: // If any of the 3 consecutive directly allocatable regions is ready for retire and replacement, > 2191: // grab heap lock try to retire all ready-to-retire shared regions. Would be preferable to allow this thread to retire all ready-to-retire regions in the directly allocatable set (not just the three that I know about) while it holds the heap lock. We do not necessarily need to keep a separate per-thread representation of ready-to-retire shared regions. This is a very rare event. Just iterate through the 13 (or whatever) regions in the directly allocatable set and ask for each whether end-top is less than min plab size. src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 81: > 79: // are denoted in bytes. Note that some regions that had been assigned to a particular partition at rebuild time > 80: // may have been retired following the rebuild. The tallies for these regions are still reflected in _capacity[p] > 81: // and _used[p], even though the region may have been removed from the free set. Prefer not to make these volatile, as that imposes a compiler overhead. src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 226: > 224: inline size_t available_in(ShenandoahFreeSetPartitionId which_partition) const { > 225: assert (which_partition < NumPartitions, "selected free set must be valid"); > 226: return capacity_of(which_partition) - used_by(which_partition); We can't do this outside of a lock. The value fetched for capacity may be incoherent with the value fetched for used (because each is modified independently). That is why the previous version of the code used the available[] array and computed its value while holding the lock. src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 232: > 230: // returned without acquiring the lock. In debug builds, the global heap lock is acquired in order to > 231: // enforce a consistency assert. > 232: inline size_t available_in_not_locked(ShenandoahFreeSetPartitionId which_partition) const { These changes are beyond the scope of planned topic. I think we need to consider them more carefully. Would prefer not to mix the two. (and I personally believe the original implementation has better performance, but feel free to prove me wrong.) src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 274: > 272: }; > 273: > 274: #define DIRECTLY_ALLOCATABLE_REGION_UNKNOWN_AFFINITY ((Thread*)-1) Out of time to dive deep into this right now. Wonder if it makes sense to randomly generate a hash for each thread and store this into a thread-local field. Might provide "randomness" and locality. ------------- PR Review: https://git.openjdk.org/jdk/pull/26171#pullrequestreview-2998610364 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2193123384 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2193127191 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2193133676 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2193188287 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2195596428 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2195616392 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2195638643 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2193242080 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2193250484 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2195588615 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2195661494 From wkemper at openjdk.org Mon Sep 22 08:46:41 2025 From: wkemper at openjdk.org (William Kemper) Date: Mon, 22 Sep 2025 08:46:41 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 19:56:30 GMT, Xiaolong Peng wrote: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of mutator memory allocation to improve heap lock contention, at vey high level, here is how it works: > * ShenandoahFreeSet holds a N (default to 13) number of ShenandoahHeapRegion* which are used by mutator threads for regular object allocations, they are called shared regions/directly allocatable regions, which are stored in PaddedEnd data structure(padded array). > * Each mutator thread will be assigned one of the directly allocatable regions, the thread will try to allocate in the directly allocatable region with CAS atomic operation, if fails will try 2 more consecutive directly allocatable regions in the array storing directly allocatable region. > * If mutator thread fails after trying 3 directly allocatable regions, it will: > * Take heap lock > * Try to retire the directly allocatable regions which are ready to retire. > * Iterator mutator partition and allocate directly allocatable regions and store to the padded array if any need to be retired. > * Satisfy mutator allocation request if possible. > > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, I have done many tests, here are some of them: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores: > Openjdk TIP: > > [ec2-user at ip-172-31-42-91 jdk]$ ./master-jdk/bin/java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms4G -Xmx4G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > ===== DaCapo tail latency, metered full smoothing: 50% 131684 usec, 90% 200192 usec, 99% 211369 usec, 99.9% 212517 usec, 99.99% 213043 usec, max 235289 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 1568 usec, 90% 36101 usec, 99% 42172 usec, 99.9% 42928 usec, 99.99% 43100 usec, max 43305 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 52644 usec, 90% 124393 usec, 99% 137711 usec, 99.9% 139355 usec, 99.99% 139749 usec, max 146722 usec, measured over 524288 events ====... It would be helpful to have a more detailed overview in the change log description to help reviewers get oriented with the changes. ------------- PR Review: https://git.openjdk.org/jdk/pull/26171#pullrequestreview-3007644661 From xpeng at openjdk.org Mon Sep 22 08:46:41 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 22 Sep 2025 08:46:41 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 22:45:01 GMT, William Kemper wrote: > It would be helpful to have a more detailed overview in the change log description to help reviewers get oriented with the changes. Thanks, I'll add detailed overview next week, I didn't add too much since I knew I was going to change the code significantly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26171#issuecomment-3064470661 From xpeng at openjdk.org Mon Sep 22 08:46:43 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 22 Sep 2025 08:46:43 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation In-Reply-To: References: Message-ID: On Tue, 8 Jul 2025 17:55:33 GMT, Kelvin Nilsen wrote: >> Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of mutator memory allocation to improve heap lock contention, at vey high level, here is how it works: >> * ShenandoahFreeSet holds a N (default to 13) number of ShenandoahHeapRegion* which are used by mutator threads for regular object allocations, they are called shared regions/directly allocatable regions, which are stored in PaddedEnd data structure(padded array). >> * Each mutator thread will be assigned one of the directly allocatable regions, the thread will try to allocate in the directly allocatable region with CAS atomic operation, if fails will try 2 more consecutive directly allocatable regions in the array storing directly allocatable region. >> * If mutator thread fails after trying 3 directly allocatable regions, it will: >> * Take heap lock >> * Try to retire the directly allocatable regions which are ready to retire. >> * Iterator mutator partition and allocate directly allocatable regions and store to the padded array if any need to be retired. >> * Satisfy mutator allocation request if possible. >> >> >> I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, I have done many tests, here are some of them: >> >> 1. Dacapo lusearch test on EC2 host with 96 CPU cores: >> Openjdk TIP: >> >> [ec2-user at ip-172-31-42-91 jdk]$ ./master-jdk/bin/java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms4G -Xmx4G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" >> ===== DaCapo tail latency, metered full smoothing: 50% 131684 usec, 90% 200192 usec, 99% 211369 usec, 99.9% 212517 usec, 99.99% 213043 usec, max 235289 usec, measured over 524288 events ===== >> ===== DaCapo tail latency, metered full smoothing: 50% 1568 usec, 90% 36101 usec, 99% 42172 usec, 99.9% 42928 usec, 99.99% 43100 usec, max 43305 usec, measured over 524288 events ===== >> ===== DaCapo tail latency, metered full smoothing: 50% 52644 usec, 90% 124393 usec, 99% 137711 usec, 99.9% 139355 usec, 99.99% 139749 usec, max 146722 ... > > src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 246: > >> 244: _leftmosts_empty[int(ShenandoahFreeSetPartitionId::Mutator)] = mutator_leftmost_empty; >> 245: _rightmosts_empty[int(ShenandoahFreeSetPartitionId::Mutator)] = mutator_rightmost_empty; >> 246: > > We have the heap lock here, so should not need to use atomic store operations. Atomic operations have a performance penalty that I think we want to avoid. Yes, we do have heap lock. But mutator may also update the used/available after allocation w/o heap lock, so the update for mutator partition need to be done with atomic operation, but not all of them. I'll revisit this part and remove the atomic operations which are not needed. > src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 247: > >> 245: _rightmosts_empty[int(ShenandoahFreeSetPartitionId::Mutator)] = mutator_rightmost_empty; >> 246: >> 247: Atomic::store(_region_counts + int(ShenandoahFreeSetPartitionId::Mutator), mutator_region_count); > > If we do need to use Atomic operations, would prefer &_region_counts[int(ShenandoahFreeSetPartitionId::Mutator)] notation for the array elements. It make sense, I'll update it, `[]` operation for array always has boundary check. > src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 282: > >> 280: >> 281: void ShenandoahRegionPartitions::increase_used(ShenandoahFreeSetPartitionId which_partition, size_t bytes) { >> 282: shenandoah_assert_heaplocked(); > > Are you now calling this directly from the CAS allocators? So you want to not have to assert heap locked and that is why we make the used accounting atomic? > > My preference would be to avoid this need by counting the entire region as used at the time the region becomes directly allocatable. Yes, we increase used after CAS allocation, so it can be called w/o lock. I'll revisit it along with the the comments you have above, if we count the entire region as used when we reserve a region for direct allocation, this change can be removed. > src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 2151: > >> 2149: >> 2150: template >> 2151: HeapWord* ShenandoahFreeSet::par_allocate_single_for_mutator(ShenandoahAllocRequest &req, bool &in_new_region) { > > Not clear to me what prefix par_ represents. Parallel allocate (without lock?) Yes. The name is a bit confusing, what about `try_allocate_single_for_mutator`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2198891380 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2198896336 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2198902300 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2198905623 From xpeng at openjdk.org Mon Sep 22 08:46:43 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 22 Sep 2025 08:46:43 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 22:34:27 GMT, Xiaolong Peng wrote: >> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 282: >> >>> 280: >>> 281: void ShenandoahRegionPartitions::increase_used(ShenandoahFreeSetPartitionId which_partition, size_t bytes) { >>> 282: shenandoah_assert_heaplocked(); >> >> Are you now calling this directly from the CAS allocators? So you want to not have to assert heap locked and that is why we make the used accounting atomic? >> >> My preference would be to avoid this need by counting the entire region as used at the time the region becomes directly allocatable. > > Yes, we increase used after CAS allocation, so it can be called w/o lock. > > I'll revisit it along with the the comments you have above, if we count the entire region as used when we reserve a region for direct allocation, this change can be removed. I have changed it to the approach as you suggested, now it count the entire region as used at the time the region becomes directly allocatable. >> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 2151: >> >>> 2149: >>> 2150: template >>> 2151: HeapWord* ShenandoahFreeSet::par_allocate_single_for_mutator(ShenandoahAllocRequest &req, bool &in_new_region) { >> >> Not clear to me what prefix par_ represents. Parallel allocate (without lock?) > > Yes. > The name is a bit confusing, what about `try_allocate_single_for_mutator`? Technically not completely without lock, it may take lock when there is need to retire and refill new directly allocatable regions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2202219473 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2198908091 From jsikstro at openjdk.org Mon Sep 22 08:51:37 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Mon, 22 Sep 2025 08:51:37 GMT Subject: RFR: 8368213: ZGC: Cleanup dead code, unimplemented declarations, unused private fields In-Reply-To: <-g7JdRe2ACZ_C1YvHLX44_daCravBY9lfGTjUaC-5_4=.205643b1-7098-4d3b-a4f1-4368252c4eb8@github.com> References: <-g7JdRe2ACZ_C1YvHLX44_daCravBY9lfGTjUaC-5_4=.205643b1-7098-4d3b-a4f1-4368252c4eb8@github.com> Message-ID: On Mon, 22 Sep 2025 05:58:14 GMT, Axel Boldt-Christmas wrote: > Over the last years refactoring and bug fixes a bit of dead code has slipped through. Clean up some of this. Purposely do not touch unused public declarations with an implementation (most if not all are trivial property checks or simple constructions which have negligible maintenance cost to keep.) nor unused public typedefs. > > The `is_high_usage` helper was rewritten to take a boolean rather than an optional templated print function pointer, as there was only one usage (a lambda which captured nothing). > > Also updated `GCThreadLocalData` size to reflect the changes that has occurred over time. Maybe we can derive this size from all the implementors in the future, but may be to hard to do in a non hack-y way. > > * Testing > * Running ZGC test tier 1-5 on Oracle supported platforms. Marked as reviewed by jsikstro (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27415#pullrequestreview-3251233319 From tschatzl at openjdk.org Mon Sep 22 08:57:23 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 22 Sep 2025 08:57:23 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v62] In-Reply-To: References: Message-ID: <9QFGKuKT_g9DUQCDaZ3yMJv-SNXBULg_c5zVQxA3p5U=.9ad6d425-4168-46a2-9d9d-129690017725@github.com> > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 82 commits: - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * iwalulya review * documentation for a few PSS members * rename some member variables to contain _ct and _rt suffixes in remembered set verification - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * therealaph suggestion for avoiding the register aliasin in gen_write_ref_array_post - * walulyai review - * walulyai review * tried to remove "logged card" terminology for the current "pending card" one - * aph review, fix some comment - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * iwalulya: remove confusing comment - ... and 72 more: https://git.openjdk.org/jdk/compare/5efaa997...b5d22d52 ------------- Changes: https://git.openjdk.org/jdk/pull/23739/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=61 Stats: 7178 lines in 113 files changed: 2606 ins; 3588 del; 984 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From iwalulya at openjdk.org Mon Sep 22 09:28:46 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 22 Sep 2025 09:28:46 GMT Subject: RFR: 8368080: G1: Unnecessary initialization of G1CMTask's mark stats table In-Reply-To: References: <0dkuTBZ3PXS9So1rs2Ah-SD4_VYK8eC4hxBgY5AaEsI=.06485f44-bf02-4714-90b8-4c424507c3ab@github.com> Message-ID: On Mon, 22 Sep 2025 07:42:49 GMT, Aleksey Shipilev wrote: > Question: There is a use of `G1RegionMarkStatsCache` in `G1CMTask` (responsible for concurrent marking as well?) -- shouldn't the reset happen on that path as well? If so, and testing did not caught it, there should be some sort of assert somewhere? That reset was already happening in `G1ConcurrentMark::reset()`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27390#issuecomment-3317781798 From shade at openjdk.org Mon Sep 22 09:47:51 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 22 Sep 2025 09:47:51 GMT Subject: RFR: 8368080: G1: Unnecessary initialization of G1CMTask's mark stats table In-Reply-To: <0dkuTBZ3PXS9So1rs2Ah-SD4_VYK8eC4hxBgY5AaEsI=.06485f44-bf02-4714-90b8-4c424507c3ab@github.com> References: <0dkuTBZ3PXS9So1rs2Ah-SD4_VYK8eC4hxBgY5AaEsI=.06485f44-bf02-4714-90b8-4c424507c3ab@github.com> Message-ID: On Fri, 19 Sep 2025 11:49:59 GMT, Thomas Schatzl wrote: > Hi all, > > please review this tiny change that leaves out resetting the mark stat caches at startup. > > This has some (somewhat tiny, depending on heap size and number of threads) positive impact on startup time. > > Testing: tier1-5, gha > > Thanks, > Thomas OK then! ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27390#pullrequestreview-3251475099 From lkorinth at openjdk.org Mon Sep 22 09:57:28 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 22 Sep 2025 09:57:28 GMT Subject: RFR: 8367409: G1: Remove unused G1MonotonicArena::Segment::copy_to() In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 11:52:08 GMT, Leo Korinth wrote: > The code compiles. Thanks for your reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27221#issuecomment-3317912038 From lkorinth at openjdk.org Mon Sep 22 09:57:29 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 22 Sep 2025 09:57:29 GMT Subject: Integrated: 8367409: G1: Remove unused G1MonotonicArena::Segment::copy_to() In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 11:52:08 GMT, Leo Korinth wrote: > The code compiles. This pull request has now been integrated. Changeset: 433d2ec5 Author: Leo Korinth URL: https://git.openjdk.org/jdk/commit/433d2ec534bbf6ec08157c976b567b81b748b128 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod 8367409: G1: Remove unused G1MonotonicArena::Segment::copy_to() Reviewed-by: ayang, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/27221 From tschatzl at openjdk.org Mon Sep 22 10:14:20 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 22 Sep 2025 10:14:20 GMT Subject: RFR: 8367731: G1: Make G1CollectionSet manage the young gen cset group In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 07:33:54 GMT, Albert Mingkun Yang wrote: >> Hi all, >> >> please review this change that lets the collection set manage the young cset candidate group directly. Currently everywhere the collection set (not "containing" the young cset candidate group) is used, we immediately do the same thing for the young gen candidate group in the same place. >> >> This makes it kind of natural to put together (and the `G1CollectionSet` already manages adding new regions to the young gen cset group anyway, so that split in responsibility is questionable anyway). >> >> Testing: gha >> >> Thanks, >> Thomas > > src/hotspot/share/gc/g1/g1CollectionSet.cpp line 103: > >> 101: >> 102: void G1CollectionSet::abandon() { >> 103: _g1h->young_regions_cset_group()->clear(true /* uninstall_cset_group */); > > It's a bit odd that `CollectionSet` doesn't have direct access to `cset_group` and have to go through heap. I thought back and forth making `G1CollectionSet` the owner of the `young_regions_cset_group` (i.e. a member of it) and found both advantages and disadvantages for that. Unless the second reviewer thinks it is better to do that, I'll keep it for now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27312#discussion_r2367429169 From ayang at openjdk.org Mon Sep 22 12:28:51 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 22 Sep 2025 12:28:51 GMT Subject: RFR: 8368251: Parallel: Refactor lgrp_id used in MutableNUMASpace In-Reply-To: <88Djo0LC5If0BwK55jK6e80Pr-k-HP7H0kRu__16Wfk=.500f12aa-4b38-40d8-88c8-7372004cdda5@github.com> References: <88Djo0LC5If0BwK55jK6e80Pr-k-HP7H0kRu__16Wfk=.500f12aa-4b38-40d8-88c8-7372004cdda5@github.com> Message-ID: On Mon, 22 Sep 2025 11:42:39 GMT, Joel Sikstr?m wrote: > Hello, > > There are multiple cases which handle if the locality group (lgrp) id is negative (-1) in Parallel, specifically in MutableNUMASpace. -1 was historically used to indicate that the hardware topology has changed and that the lgrp id needs to be updated. This is no longer the case, since HotSpot doesn't support CPU/NUMA hotplugging, and the last piece of code setting the lgrp id to -1 was removed in [JDK-8301149](https://bugs.openjdk.org/browse/JDK-8301149). > > I propose we simplify the code a bit by not handling edge cases where the lgrp id is -1 and removing os::numa_has_group_homing(), which always return false > > Testing: > * Running through Oracle's tier 1-4 > * Local NUMA testing tier1-4 with `-XX:+UseParallelGC -XX:+UseNUMA` Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27424#pullrequestreview-3252409150 From jsikstro at openjdk.org Mon Sep 22 12:28:53 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Mon, 22 Sep 2025 12:28:53 GMT Subject: RFR: 8368251: Parallel: Refactor lgrp_id used in MutableNUMASpace In-Reply-To: <88Djo0LC5If0BwK55jK6e80Pr-k-HP7H0kRu__16Wfk=.500f12aa-4b38-40d8-88c8-7372004cdda5@github.com> References: <88Djo0LC5If0BwK55jK6e80Pr-k-HP7H0kRu__16Wfk=.500f12aa-4b38-40d8-88c8-7372004cdda5@github.com> Message-ID: On Mon, 22 Sep 2025 11:42:39 GMT, Joel Sikstr?m wrote: > Hello, > > There are multiple cases which handle if the locality group (lgrp) id is negative (-1) in Parallel, specifically in MutableNUMASpace. -1 was historically used to indicate that the hardware topology has changed and that the lgrp id needs to be updated. This is no longer the case, since HotSpot doesn't support CPU/NUMA hotplugging, and the last piece of code setting the lgrp id to -1 was removed in [JDK-8301149](https://bugs.openjdk.org/browse/JDK-8301149). > > I propose we simplify the code a bit by not handling edge cases where the lgrp id is -1 and removing os::numa_has_group_homing(), which always return false > > Testing: > * Running through Oracle's tier 1-4 > * Local NUMA testing tier1-4 with `-XX:+UseParallelGC -XX:+UseNUMA` src/hotspot/os/windows/os_windows.cpp line 539: > 537: if (UseNUMA) { > 538: thread->update_lgrp_id(); > 539: } I'm a bit hesistant to remove this code from Windows since I have no way to test this. However, since we set `UseNUMA = false` early on initialization on Windows, Paralell should never start with NUMA enabled, so this code should effectively have no effect. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27424#discussion_r2368082735 From stefank at openjdk.org Mon Sep 22 12:43:29 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 22 Sep 2025 12:43:29 GMT Subject: RFR: 8368104: Parallel: Refactor PSThreadRootsTaskClosure [v3] In-Reply-To: References: Message-ID: <3TwVNJnz6oqUpIsNErDPNtDj13nBnOrbdEAW-SNfqYY=.78d45a4e-cdbe-4bf7-a7e7-96df98ba4deb@github.com> On Fri, 19 Sep 2025 20:49:39 GMT, Albert Mingkun Yang wrote: >> Trivial changing the closure input arg to avoid `PSPromotionManager` lookup. >> >> Test: tier1 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27393#pullrequestreview-3252496441 From ayang at openjdk.org Mon Sep 22 12:59:15 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 22 Sep 2025 12:59:15 GMT Subject: RFR: 8368104: Parallel: Refactor PSThreadRootsTaskClosure [v3] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 20:49:39 GMT, Albert Mingkun Yang wrote: >> Trivial changing the closure input arg to avoid `PSPromotionManager` lookup. >> >> Test: tier1 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27393#issuecomment-3318832817 From ayang at openjdk.org Mon Sep 22 12:59:17 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 22 Sep 2025 12:59:17 GMT Subject: Integrated: 8368104: Parallel: Refactor PSThreadRootsTaskClosure In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 15:24:05 GMT, Albert Mingkun Yang wrote: > Trivial changing the closure input arg to avoid `PSPromotionManager` lookup. > > Test: tier1 This pull request has now been integrated. Changeset: f779ad64 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/f779ad64ac3184a90e2d3ddf2cba5321d050d325 Stats: 12 lines in 1 file changed: 1 ins; 2 del; 9 mod 8368104: Parallel: Refactor PSThreadRootsTaskClosure Reviewed-by: stefank, fandreuzzi ------------- PR: https://git.openjdk.org/jdk/pull/27393 From ghan at openjdk.org Mon Sep 22 13:23:56 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Mon, 22 Sep 2025 13:23:56 GMT Subject: RFR: 8368089: G1: G1PeriodicGCTask::should_start_periodic_gc may use uninitialised value if os::loadavg is unsupported [v2] In-Reply-To: <2OvCoQTGiaeASeEzeH7nPlNrqKuVBG4coqXf7FOqEc8=.1071778b-0427-4736-8d2c-4718b85081ca@github.com> References: <2OvCoQTGiaeASeEzeH7nPlNrqKuVBG4coqXf7FOqEc8=.1071778b-0427-4736-8d2c-4718b85081ca@github.com> Message-ID: > Please review this change. Thanks! > > **Description:** > > Previously the check combined loadavg() failure and threshold comparison in a single condition. When os::loadavg() returned -1, `recent_load` contained an undefined value but was still logged as if it was a real load average, leading to misleading log output. > > **Fix:** > > This change separates the failure case from the combined check: > - If os::loadavg() returns -1, log "System loadavg not supported" and skip. > - Only compare `recent_load` to the threshold when loadavg() succeeds. > > **Test:** > > GHA Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: Update g1PeriodicGCTask.cpp Disable the functionality when os::loadavg() is not supported. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27413/files - new: https://git.openjdk.org/jdk/pull/27413/files/a490606c..4ff7567c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27413&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27413&range=00-01 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27413.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27413/head:pull/27413 PR: https://git.openjdk.org/jdk/pull/27413 From ghan at openjdk.org Mon Sep 22 13:23:58 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Mon, 22 Sep 2025 13:23:58 GMT Subject: RFR: 8368089: G1: G1PeriodicGCTask::should_start_periodic_gc may use uninitialised value if os::loadavg is unsupported [v2] In-Reply-To: <_gLPNsB7JD-agIZjuNQoAOmm5WRG-jmIJT0Za2EgAJY=.8d186386-835e-49c7-8ba2-81752125d153@github.com> References: <2OvCoQTGiaeASeEzeH7nPlNrqKuVBG4coqXf7FOqEc8=.1071778b-0427-4736-8d2c-4718b85081ca@github.com> <_gLPNsB7JD-agIZjuNQoAOmm5WRG-jmIJT0Za2EgAJY=.8d186386-835e-49c7-8ba2-81752125d153@github.com> Message-ID: On Mon, 22 Sep 2025 08:33:07 GMT, Thomas Schatzl wrote: >> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: >> >> Update g1PeriodicGCTask.cpp >> >> Disable the functionality when os::loadavg() is not supported. > > src/hotspot/share/gc/g1/g1PeriodicGCTask.cpp line 61: > >> 59: log_debug(gc, periodic)("System loadavg not supported. Skipping."); >> 60: return false; >> 61: } > > is `os::loadavg` support something that is fixed for a given run? It would maybe be nicer to fail the VM if `G1PeriodicGCSystemLoadThreshold` is set but `os::loadavg()` not supported. Or start with a warning and disable the functionality instead of printing the message over and over again. Thanks! I?ve fixed it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27413#discussion_r2368369297 From aboldtch at openjdk.org Mon Sep 22 13:39:53 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 22 Sep 2025 13:39:53 GMT Subject: RFR: 8285984: G1: Use standard idiom for inlined payload in G1MonotonicArena::Segment [v3] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 13:54:17 GMT, Leo Korinth wrote: >> This change remove the old padding (extremely big, especially on x86-64), and replaces it with a guaranteed 8 byte alignment. It also removes the `_bottom` field and instead adds a `payload` method. I statically assert that Segment is 8 byte aligned. I then runtime assert that Segment is constructed on 8 byte aligned memory. I also assert that the Slot alignment is less than or equal to the Segment alignment. >> >> I am running tier 1-3 at the moment. Do you think I should run some specific performance test on this? > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup after comments from Axel. > > Rename SegmentAlignment -> SegmentPayloadMaxAlignment. > > Transform alignment assert to use percent operator (will ensure slot > alignment is both less than segment alignment AND that segment > alignment is a multiple of slot alignment) Marked as reviewed by aboldtch (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27258#pullrequestreview-3252847127 From lkorinth at openjdk.org Mon Sep 22 14:26:22 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 22 Sep 2025 14:26:22 GMT Subject: Integrated: 8285984: G1: Use standard idiom for inlined payload in G1MonotonicArena::Segment In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 12:26:19 GMT, Leo Korinth wrote: > This change remove the old padding (extremely big, especially on x86-64), and replaces it with a guaranteed 8 byte alignment. It also removes the `_bottom` field and instead adds a `payload` method. I statically assert that Segment is 8 byte aligned. I then runtime assert that Segment is constructed on 8 byte aligned memory. I also assert that the Slot alignment is less than or equal to the Segment alignment. > > I am running tier 1-3 at the moment. Do you think I should run some specific performance test on this? This pull request has now been integrated. Changeset: bf726e82 Author: Leo Korinth URL: https://git.openjdk.org/jdk/commit/bf726e821790fad6ee304c1c36bddedbfe4152ff Stats: 15 lines in 3 files changed: 5 ins; 3 del; 7 mod 8285984: G1: Use standard idiom for inlined payload in G1MonotonicArena::Segment Reviewed-by: aboldtch, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/27258 From lkorinth at openjdk.org Mon Sep 22 14:26:21 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 22 Sep 2025 14:26:21 GMT Subject: RFR: 8285984: G1: Use standard idiom for inlined payload in G1MonotonicArena::Segment [v3] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 13:54:17 GMT, Leo Korinth wrote: >> This change remove the old padding (extremely big, especially on x86-64), and replaces it with a guaranteed 8 byte alignment. It also removes the `_bottom` field and instead adds a `payload` method. I statically assert that Segment is 8 byte aligned. I then runtime assert that Segment is constructed on 8 byte aligned memory. I also assert that the Slot alignment is less than or equal to the Segment alignment. >> >> I am running tier 1-3 at the moment. Do you think I should run some specific performance test on this? > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup after comments from Axel. > > Rename SegmentAlignment -> SegmentPayloadMaxAlignment. > > Transform alignment assert to use percent operator (will ensure slot > alignment is both less than segment alignment AND that segment > alignment is a multiple of slot alignment) Thanks for your reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27258#issuecomment-3319349384 From kdnilsen at openjdk.org Mon Sep 22 19:13:41 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 22 Sep 2025 19:13:41 GMT Subject: RFR: 8368015: Shenandoah: fix error in computation of average allocation rate [v2] In-Reply-To: References: Message-ID: > We use bytes_allocated_since_gc_start() to compute allocation rates. This leaves a blind spot, as our current implementation ignores allocations and the time period between the moment we begin GC and the first time we update the allocation rate following the start of GC. When this happens, we typically find that the sampled number of allocations is smaller than the allocations that had accumulated by the time we triggered the start of the current GC cycle. > > This PR adds tracking for that accounting gap. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: remove state variable previous GC allocated ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27398/files - new: https://git.openjdk.org/jdk/pull/27398/files/2ea7e50a..2e422421 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27398&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27398&range=00-01 Stats: 69 lines in 7 files changed: 40 ins; 15 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/27398.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27398/head:pull/27398 PR: https://git.openjdk.org/jdk/pull/27398 From kdnilsen at openjdk.org Mon Sep 22 20:42:06 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 22 Sep 2025 20:42:06 GMT Subject: RFR: 8368015: Shenandoah: fix error in computation of average allocation rate [v2] In-Reply-To: References: Message-ID: <1zWphYBRePzvVFEF3lnsQM0-8vif-l7mp-G_i5eYKEE=.37087053-f4e9-4200-b472-b91767d164ae@github.com> On Mon, 22 Sep 2025 19:13:41 GMT, Kelvin Nilsen wrote: >> We use bytes_allocated_since_gc_start() to compute allocation rates. This leaves a blind spot, as our current implementation ignores allocations and the time period between the moment we begin GC and the first time we update the allocation rate following the start of GC. When this happens, we typically find that the sampled number of allocations is smaller than the allocations that had accumulated by the time we triggered the start of the current GC cycle. >> >> This PR adds tracking for that accounting gap. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > remove state variable previous GC allocated I've refactored the code to get rid of the unnecessary state variable: _previous_gc_allocated. I accomplished by forcing a sample to be taken at the moment we begin GC. I found that the initial implementation of this change caused unruly behavior because sometimes the allocation data collected between the moment previous sample was taken and the the start of the subsequent GC is too short, and the calculated allocation rate is consequentially too noisy. The "fix" for this problem is to not force the allocation rate sample if this time is less than 2 ms in duration. When we ignore the "forced sample request", we treat the "ignored" allocations as if they had been performed after the start of this GC cycle. Here is the performance of this PR compared to baseline from 8/28 on an Extremem workload with 31 GB heap size. image ------------- PR Comment: https://git.openjdk.org/jdk/pull/27398#issuecomment-3321410934 From wkemper at openjdk.org Mon Sep 22 23:13:01 2025 From: wkemper at openjdk.org (William Kemper) Date: Mon, 22 Sep 2025 23:13:01 GMT Subject: RFR: 8368015: Shenandoah: fix error in computation of average allocation rate [v2] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 19:13:41 GMT, Kelvin Nilsen wrote: >> We use bytes_allocated_since_gc_start() to compute allocation rates. This leaves a blind spot, as our current implementation ignores allocations and the time period between the moment we begin GC and the first time we update the allocation rate following the start of GC. When this happens, we typically find that the sampled number of allocations is smaller than the allocations that had accumulated by the time we triggered the start of the current GC cycle. >> >> This PR adds tracking for that accounting gap. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > remove state variable previous GC allocated Should we move [this line](https://github.com/openjdk/jdk/pull/27398/files#diff-5cbba824b4e4b914425672f0d1bea49b44aa48940fd07f517b7312055927c575R249) where we take the allocation sample above the early exit when `_start_gc_is_pending`? Not directly related to this PR, but seems to be in the spirit of making the allocation rate sampling more accurate. src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 364: > 362: > 363: double ShenandoahAllocationRate::force_sample(size_t allocated, size_t &unaccounted_bytes_allocated) { > 364: const double MinSampleTime = 0.002; // Do not sample if time since last update is less than 2 ms Would it make sense to "carry over" the `unaccounted_bytes_allocated` if, at the time of reset, the last sample was taken less than `ShenandoahAllocationRate::_interval_sec` (instead of `MinSampleTime`)? I believe this would result in more samples being carried over. src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 382: > 380: } > 381: > 382: double ShenandoahAllocationRate::sample(size_t allocated, bool force_update) { `force_update` looks unused here. ------------- Changes requested by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27398#pullrequestreview-3255437150 PR Review Comment: https://git.openjdk.org/jdk/pull/27398#discussion_r2370548105 PR Review Comment: https://git.openjdk.org/jdk/pull/27398#discussion_r2370489243 From fandreuzzi at openjdk.org Tue Sep 23 00:00:28 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Tue, 23 Sep 2025 00:00:28 GMT Subject: RFR: 8368345: Remove leftover includes of strongRootsScope.hpp Message-ID: #27336 and #27385 replaced some `StrongRootsScope` usages with `ThreadsClaimTokenScope`. Some includes to `strongRootsScope.hpp` can now be removed. Passes tier1. ------------- Commit messages: - rm Changes: https://git.openjdk.org/jdk/pull/27442/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27442&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368345 Stats: 2 lines in 2 files changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27442.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27442/head:pull/27442 PR: https://git.openjdk.org/jdk/pull/27442 From stefank at openjdk.org Tue Sep 23 06:40:25 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 23 Sep 2025 06:40:25 GMT Subject: RFR: 8368345: Remove leftover includes of strongRootsScope.hpp In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 23:54:09 GMT, Francesco Andreuzzi wrote: > #27336 and #27385 replaced some `StrongRootsScope` usages with `ThreadsClaimTokenScope`. Some includes to `strongRootsScope.hpp` can now be removed. > > This looks trivial to me. > > Passes tier1. Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27442#pullrequestreview-3256465386 From aboldtch at openjdk.org Tue Sep 23 07:14:08 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 23 Sep 2025 07:14:08 GMT Subject: RFR: 8368213: ZGC: Cleanup dead code, unimplemented declarations, unused private fields In-Reply-To: <-g7JdRe2ACZ_C1YvHLX44_daCravBY9lfGTjUaC-5_4=.205643b1-7098-4d3b-a4f1-4368252c4eb8@github.com> References: <-g7JdRe2ACZ_C1YvHLX44_daCravBY9lfGTjUaC-5_4=.205643b1-7098-4d3b-a4f1-4368252c4eb8@github.com> Message-ID: <4otmMKARiJ40soc5LcYu6awvVO2ASdxuwypYc7DAfts=.a99669b7-1698-4031-a596-966321c2c50b@github.com> On Mon, 22 Sep 2025 05:58:14 GMT, Axel Boldt-Christmas wrote: > Over the last years refactoring and bug fixes a bit of dead code has slipped through. Clean up some of this. Purposely do not touch unused public declarations with an implementation (most if not all are trivial property checks or simple constructions which have negligible maintenance cost to keep.) nor unused public typedefs. > > The `is_high_usage` helper was rewritten to take a boolean rather than an optional templated print function pointer, as there was only one usage (a lambda which captured nothing). > > Also updated `GCThreadLocalData` size to reflect the changes that has occurred over time. Maybe we can derive this size from all the implementors in the future, but may be to hard to do in a non hack-y way. > > * Testing > * Running ZGC test tier 1-5 on Oracle supported platforms. Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27415#issuecomment-3322711036 From aboldtch at openjdk.org Tue Sep 23 07:15:27 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 23 Sep 2025 07:15:27 GMT Subject: RFR: 8368212: ZGC: Fix spelling and typos in comments In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 05:59:03 GMT, Axel Boldt-Christmas wrote: > Trivial fix of a hand full of comments which have typos or miss-spellings. Only fix obvious miss-spellings, not American vs British vs colloquial inconsistencies, nor englishified jargon. Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27416#issuecomment-3322706763 From aboldtch at openjdk.org Tue Sep 23 07:15:28 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 23 Sep 2025 07:15:28 GMT Subject: Integrated: 8368212: ZGC: Fix spelling and typos in comments In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 05:59:03 GMT, Axel Boldt-Christmas wrote: > Trivial fix of a hand full of comments which have typos or miss-spellings. Only fix obvious miss-spellings, not American vs British vs colloquial inconsistencies, nor englishified jargon. This pull request has now been integrated. Changeset: 7ed72d94 Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/7ed72d943b8d4c5cd0d3707c0c95148db74401bf Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod 8368212: ZGC: Fix spelling and typos in comments Reviewed-by: jsikstro, stefank ------------- PR: https://git.openjdk.org/jdk/pull/27416 From aboldtch at openjdk.org Tue Sep 23 07:18:39 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 23 Sep 2025 07:18:39 GMT Subject: Integrated: 8368213: ZGC: Cleanup dead code, unimplemented declarations, unused private fields In-Reply-To: <-g7JdRe2ACZ_C1YvHLX44_daCravBY9lfGTjUaC-5_4=.205643b1-7098-4d3b-a4f1-4368252c4eb8@github.com> References: <-g7JdRe2ACZ_C1YvHLX44_daCravBY9lfGTjUaC-5_4=.205643b1-7098-4d3b-a4f1-4368252c4eb8@github.com> Message-ID: <7wmdy8FXpI5Ji5cNCOsxY4wsSn0gms2f3cflHYS0cQ8=.7176e3e0-93dc-44ba-9802-0f7c413a3946@github.com> On Mon, 22 Sep 2025 05:58:14 GMT, Axel Boldt-Christmas wrote: > Over the last years refactoring and bug fixes a bit of dead code has slipped through. Clean up some of this. Purposely do not touch unused public declarations with an implementation (most if not all are trivial property checks or simple constructions which have negligible maintenance cost to keep.) nor unused public typedefs. > > The `is_high_usage` helper was rewritten to take a boolean rather than an optional templated print function pointer, as there was only one usage (a lambda which captured nothing). > > Also updated `GCThreadLocalData` size to reflect the changes that has occurred over time. Maybe we can derive this size from all the implementors in the future, but may be to hard to do in a non hack-y way. > > * Testing > * Running ZGC test tier 1-5 on Oracle supported platforms. This pull request has now been integrated. Changeset: 47ed1a8d Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/47ed1a8d1768ef0623fd9d1ff68d39df5dffaad0 Stats: 46 lines in 9 files changed: 1 ins; 36 del; 9 mod 8368213: ZGC: Cleanup dead code, unimplemented declarations, unused private fields Reviewed-by: stefank, jsikstro ------------- PR: https://git.openjdk.org/jdk/pull/27415 From tschatzl at openjdk.org Tue Sep 23 07:24:38 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 23 Sep 2025 07:24:38 GMT Subject: RFR: 8368345: Remove leftover includes of strongRootsScope.hpp In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 23:54:09 GMT, Francesco Andreuzzi wrote: > #27336 and #27385 replaced some `StrongRootsScope` usages with `ThreadsClaimTokenScope`. Some includes to `strongRootsScope.hpp` can now be removed. > > This looks trivial to me. > > Passes tier1. trivial ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27442#pullrequestreview-3256608476 From ayang at openjdk.org Tue Sep 23 07:58:44 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 23 Sep 2025 07:58:44 GMT Subject: RFR: 8368089: G1: G1PeriodicGCTask::should_start_periodic_gc may use uninitialised value if os::loadavg is unsupported [v2] In-Reply-To: References: <2OvCoQTGiaeASeEzeH7nPlNrqKuVBG4coqXf7FOqEc8=.1071778b-0427-4736-8d2c-4718b85081ca@github.com> Message-ID: <-LoH0pFQhBF8VG39_ssHEEXkaJ9MgsJOcQyDHeZzjto=.72801341-ac35-4089-90aa-112d93cd76db@github.com> On Mon, 22 Sep 2025 13:23:56 GMT, Guanqiang Han wrote: >> Please review this change. Thanks! >> >> **Description:** >> >> Previously the check combined loadavg() failure and threshold comparison in a single condition. When os::loadavg() returned -1, `recent_load` contained an undefined value but was still logged as if it was a real load average, leading to misleading log output. >> >> **Fix:** >> >> This change separates the failure case from the combined check: >> - If os::loadavg() returns -1, log "System loadavg not supported" and skip. >> - Only compare `recent_load` to the threshold when loadavg() succeeds. >> >> **Test:** >> >> GHA > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > Update g1PeriodicGCTask.cpp > > Disable the functionality when os::loadavg() is not supported. src/hotspot/share/gc/g1/g1PeriodicGCTask.cpp line 61: > 59: G1PeriodicGCInterval = 0; > 60: log_warning(gc, periodic)("System loadavg not supported. Periodic GC is disabled " > 61: "by setting G1PeriodicGCInterval to 0."); This disables periodic-gc. It's not super obvious that this is desirable. My expectation would be if `G1PeriodicGCSystemLoadThreshold`, a fine tuning knob in controlling periodic-gc, is not supported, this tuning knob will just be ignored with a warning, instead of disabling periodic-gc completely. However, I can also imagine starting periodic-gc when system-load is high can be detrimental, so disabling periodic-gc is safer. (Just raising it for discussion.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27413#discussion_r2371487036 From ayang at openjdk.org Tue Sep 23 08:14:57 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 23 Sep 2025 08:14:57 GMT Subject: RFR: 8368345: Remove leftover includes of strongRootsScope.hpp In-Reply-To: References: Message-ID: <6S-40g1Azjrvk-dW-AgLHHVBaoQX5AgaFmTxWiBBMz0=.05b5021a-862f-42d0-9a3d-f5d7304d4ea5@github.com> On Mon, 22 Sep 2025 23:54:09 GMT, Francesco Andreuzzi wrote: > #27336 and #27385 replaced some `StrongRootsScope` usages with `ThreadsClaimTokenScope`. Some includes to `strongRootsScope.hpp` can now be removed. > > This looks trivial to me. > > Passes tier1. Thanks for the cleanup. ------------- Marked as reviewed by ayang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27442#pullrequestreview-3256778301 From tschatzl at openjdk.org Tue Sep 23 08:18:15 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 23 Sep 2025 08:18:15 GMT Subject: RFR: 8368089: G1: G1PeriodicGCTask::should_start_periodic_gc may use uninitialised value if os::loadavg is unsupported [v2] In-Reply-To: References: <2OvCoQTGiaeASeEzeH7nPlNrqKuVBG4coqXf7FOqEc8=.1071778b-0427-4736-8d2c-4718b85081ca@github.com> <-LoH0pFQhBF8VG39_ssHEEXkaJ9MgsJOcQyDHeZzjto=.72801341-ac35-4089-90aa-112d93cd76db@github.com> Message-ID: <8VDX2oWD0swnzuagOuX7102Lo9MqI0Cbo5CLyYDi3BU=.24187daf-5b72-40d4-b568-1e8d535622bf@github.com> On Tue, 23 Sep 2025 08:12:48 GMT, Thomas Schatzl wrote: >> src/hotspot/share/gc/g1/g1PeriodicGCTask.cpp line 61: >> >>> 59: G1PeriodicGCInterval = 0; >>> 60: log_warning(gc, periodic)("System loadavg not supported. Periodic GC is disabled " >>> 61: "by setting G1PeriodicGCInterval to 0."); >> >> This disables periodic-gc. It's not super obvious that this is desirable. My expectation would be if `G1PeriodicGCSystemLoadThreshold`, a fine tuning knob in controlling periodic-gc, is not supported, this tuning knob will just be ignored with a warning, instead of disabling periodic-gc completely. >> >> However, I can also imagine starting periodic-gc when system-load is high can be detrimental, so disabling periodic-gc is safer. >> >> (Just raising it for discussion.) > > With "disable this functionality" I actually meant disabling the `G1PeriodicGCSystemLoadThreshold` check, but not completely disabling periodic GCs. The reason is that I do not think the impact will be that high. At least when choosing concurrent GC as the choice for getting back memory. In case of full gcs having been selected, that will have a large performance impact, it may be better to terminate the VM for safety? Not sure. To me periodic full gcs seem to be such a rare use case that it could be ignored for the sake of not making this rule too complicated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27413#discussion_r2371532776 From tschatzl at openjdk.org Tue Sep 23 08:18:15 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 23 Sep 2025 08:18:15 GMT Subject: RFR: 8368089: G1: G1PeriodicGCTask::should_start_periodic_gc may use uninitialised value if os::loadavg is unsupported [v2] In-Reply-To: <-LoH0pFQhBF8VG39_ssHEEXkaJ9MgsJOcQyDHeZzjto=.72801341-ac35-4089-90aa-112d93cd76db@github.com> References: <2OvCoQTGiaeASeEzeH7nPlNrqKuVBG4coqXf7FOqEc8=.1071778b-0427-4736-8d2c-4718b85081ca@github.com> <-LoH0pFQhBF8VG39_ssHEEXkaJ9MgsJOcQyDHeZzjto=.72801341-ac35-4089-90aa-112d93cd76db@github.com> Message-ID: On Tue, 23 Sep 2025 07:55:33 GMT, Albert Mingkun Yang wrote: >> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: >> >> Update g1PeriodicGCTask.cpp >> >> Disable the functionality when os::loadavg() is not supported. > > src/hotspot/share/gc/g1/g1PeriodicGCTask.cpp line 61: > >> 59: G1PeriodicGCInterval = 0; >> 60: log_warning(gc, periodic)("System loadavg not supported. Periodic GC is disabled " >> 61: "by setting G1PeriodicGCInterval to 0."); > > This disables periodic-gc. It's not super obvious that this is desirable. My expectation would be if `G1PeriodicGCSystemLoadThreshold`, a fine tuning knob in controlling periodic-gc, is not supported, this tuning knob will just be ignored with a warning, instead of disabling periodic-gc completely. > > However, I can also imagine starting periodic-gc when system-load is high can be detrimental, so disabling periodic-gc is safer. > > (Just raising it for discussion.) With "disable this functionality" I actually meant disabling the `G1PeriodicGCSystemLoadThreshold` check, but not completely disabling periodic GCs. The reason is that I do not think the impact will be that high. At least when choosing concurrent GC as the choice for getting back memory. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27413#discussion_r2371527123 From ghan at openjdk.org Tue Sep 23 08:35:24 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Tue, 23 Sep 2025 08:35:24 GMT Subject: RFR: 8368089: G1: G1PeriodicGCTask::should_start_periodic_gc may use uninitialised value if os::loadavg is unsupported [v2] In-Reply-To: <8VDX2oWD0swnzuagOuX7102Lo9MqI0Cbo5CLyYDi3BU=.24187daf-5b72-40d4-b568-1e8d535622bf@github.com> References: <2OvCoQTGiaeASeEzeH7nPlNrqKuVBG4coqXf7FOqEc8=.1071778b-0427-4736-8d2c-4718b85081ca@github.com> <-LoH0pFQhBF8VG39_ssHEEXkaJ9MgsJOcQyDHeZzjto=.72801341-ac35-4089-90aa-112d93cd76db@github.com> <8VDX2oWD0swnzuagOuX7102Lo9MqI0Cbo5CLyYDi3BU=.24187daf-5b72-40d4-b568-1e8d535622bf@github.com> Message-ID: On Tue, 23 Sep 2025 08:15:10 GMT, Thomas Schatzl wrote: >> With "disable this functionality" I actually meant disabling the `G1PeriodicGCSystemLoadThreshold` check, but not completely disabling periodic GCs. The reason is that I do not think the impact will be that high. At least when choosing concurrent GC as the choice for getting back memory. > > In case of full gcs having been selected, that will have a large performance impact, it may be better to terminate the VM for safety? > > Not sure. To me periodic full gcs seem to be such a rare use case that it could be ignored for the sake of not making this rule too complicated. Actually, my change was following the intent of the original author: if os::loadavg() is not supported, we return early to prevent periodic GC from triggering when the system load is uncertain. This is indeed a conservative choice. However, I can also agree with the suggestion to only disable the G1PeriodicGCSystemLoadThreshold check (i.e., set it to 0) while leaving periodic GC itself active. I would like to hear your thoughts on which approach would be preferable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27413#discussion_r2371572753 From jsikstro at openjdk.org Tue Sep 23 08:58:19 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Tue, 23 Sep 2025 08:58:19 GMT Subject: RFR: 8368251: Parallel: Refactor lgrp_id used in MutableNUMASpace [v2] In-Reply-To: <88Djo0LC5If0BwK55jK6e80Pr-k-HP7H0kRu__16Wfk=.500f12aa-4b38-40d8-88c8-7372004cdda5@github.com> References: <88Djo0LC5If0BwK55jK6e80Pr-k-HP7H0kRu__16Wfk=.500f12aa-4b38-40d8-88c8-7372004cdda5@github.com> Message-ID: <1c6u6m1uxYU8ImOy0WBWph0pzt-un3FHKuM5odBjLkE=.d0aa2ce1-ffa5-4358-bfd2-5f8ef411942a@github.com> > Hello, > > There are multiple cases which handle if the locality group (lgrp) id is negative (-1) in Parallel, specifically in MutableNUMASpace. -1 was historically used to indicate that the hardware topology has changed and that the lgrp id needs to be updated. This is no longer the case, since HotSpot doesn't support CPU/NUMA hotplugging, and the last piece of code setting the lgrp id to -1 was removed in [JDK-8301149](https://bugs.openjdk.org/browse/JDK-8301149). > > I propose we simplify the code a bit by not handling edge cases where the lgrp id is -1 and removing os::numa_has_group_homing(), which always return false > > Testing: > * Running through Oracle's tier 1-4 > * Local NUMA testing tier1-4 with `-XX:+UseParallelGC -XX:+UseNUMA` Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: Don't set lgrp_id on Windows since we don't support NUMA there ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27424/files - new: https://git.openjdk.org/jdk/pull/27424/files/980d4684..d8dcd72a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27424&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27424&range=00-01 Stats: 8 lines in 1 file changed: 0 ins; 8 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27424.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27424/head:pull/27424 PR: https://git.openjdk.org/jdk/pull/27424 From jsikstro at openjdk.org Tue Sep 23 08:58:22 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Tue, 23 Sep 2025 08:58:22 GMT Subject: RFR: 8368251: Parallel: Refactor lgrp_id used in MutableNUMASpace [v2] In-Reply-To: References: <88Djo0LC5If0BwK55jK6e80Pr-k-HP7H0kRu__16Wfk=.500f12aa-4b38-40d8-88c8-7372004cdda5@github.com> Message-ID: <7cvyFiDU7TdbLYxKQwOROtZMMpi96Tr8DWM_GUZnN3E=.e9000b69-95a3-4caa-9b87-55d907eaf24c@github.com> On Mon, 22 Sep 2025 12:25:53 GMT, Joel Sikstr?m wrote: >> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: >> >> Don't set lgrp_id on Windows since we don't support NUMA there > > src/hotspot/os/windows/os_windows.cpp line 539: > >> 537: if (UseNUMA) { >> 538: thread->update_lgrp_id(); >> 539: } > > I'm a bit hesistant to remove this code from Windows since I have no way to test this. However, since we set `UseNUMA = false` early on initialization on Windows, Paralell should never start with NUMA enabled, so this code should effectively have no effect. I decided to remove these two blocks from `os_windows.cpp`. Through some testing with logging, I see that UseNUMA is ergonomically set to false before any threads are created, so the code is never reached. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27424#discussion_r2371624197 From tschatzl at openjdk.org Tue Sep 23 09:10:31 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 23 Sep 2025 09:10:31 GMT Subject: RFR: 8368080: G1: Unnecessary initialization of G1CMTask's mark stats table In-Reply-To: References: <0dkuTBZ3PXS9So1rs2Ah-SD4_VYK8eC4hxBgY5AaEsI=.06485f44-bf02-4714-90b8-4c424507c3ab@github.com> Message-ID: On Mon, 22 Sep 2025 09:25:43 GMT, Ivan Walulya wrote: >> Question: There is a use of `G1RegionMarkStatsCache` in `G1CMTask` (responsible for concurrent marking as well?) -- shouldn't the reset happen on that path as well? If so, and testing did not caught it, there should be some sort of assert somewhere? > >> Question: There is a use of `G1RegionMarkStatsCache` in `G1CMTask` (responsible for concurrent marking as well?) -- shouldn't the reset happen on that path as well? If so, and testing did not caught it, there should be some sort of assert somewhere? > > That reset was already happening in `G1ConcurrentMark::reset()`. Thanks @walulyai @shipilev for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/27390#issuecomment-3323053535 From tschatzl at openjdk.org Tue Sep 23 09:10:33 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 23 Sep 2025 09:10:33 GMT Subject: Integrated: 8368080: G1: Unnecessary initialization of G1CMTask's mark stats table In-Reply-To: <0dkuTBZ3PXS9So1rs2Ah-SD4_VYK8eC4hxBgY5AaEsI=.06485f44-bf02-4714-90b8-4c424507c3ab@github.com> References: <0dkuTBZ3PXS9So1rs2Ah-SD4_VYK8eC4hxBgY5AaEsI=.06485f44-bf02-4714-90b8-4c424507c3ab@github.com> Message-ID: On Fri, 19 Sep 2025 11:49:59 GMT, Thomas Schatzl wrote: > Hi all, > > please review this tiny change that leaves out resetting the mark stat caches at startup. > > This has some (somewhat tiny, depending on heap size and number of threads) positive impact on startup time. > > Testing: tier1-5, gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 2e99ed64 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/2e99ed64223e48f4173f00ce56d28473dba31a83 Stats: 4 lines in 3 files changed: 3 ins; 1 del; 0 mod 8368080: G1: Unnecessary initialization of G1CMTask's mark stats table Reviewed-by: iwalulya, shade ------------- PR: https://git.openjdk.org/jdk/pull/27390 From tschatzl at openjdk.org Tue Sep 23 09:10:50 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 23 Sep 2025 09:10:50 GMT Subject: RFR: 8367731: G1: Make G1CollectionSet manage the young gen cset group [v2] In-Reply-To: References: Message-ID: <1s-OMCm1q-dvbS-lCpYd4mnYKAMct1yB7Gey6CaUsrc=.00f9ede4-8eef-4a37-839d-93e946dfc07d@github.com> > Hi all, > > please review this change that lets the collection set manage the young cset candidate group directly. Currently everywhere the collection set (not "containing" the young cset candidate group) is used, we immediately do the same thing for the young gen candidate group in the same place. > > This makes it kind of natural to put together (and the `G1CollectionSet` already manages adding new regions to the young gen cset group anyway, so that split in responsibility is questionable anyway). > > Testing: gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' into 8367731-g1collectionset-manage-young-gen-group - * comment update - * let collectionset manage the young regions group card set ------------- Changes: https://git.openjdk.org/jdk/pull/27312/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27312&range=01 Stats: 65 lines in 8 files changed: 26 ins; 29 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/27312.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27312/head:pull/27312 PR: https://git.openjdk.org/jdk/pull/27312 From iwalulya at openjdk.org Tue Sep 23 09:16:56 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 23 Sep 2025 09:16:56 GMT Subject: RFR: 8367731: G1: Make G1CollectionSet manage the young gen cset group [v2] In-Reply-To: <1s-OMCm1q-dvbS-lCpYd4mnYKAMct1yB7Gey6CaUsrc=.00f9ede4-8eef-4a37-839d-93e946dfc07d@github.com> References: <1s-OMCm1q-dvbS-lCpYd4mnYKAMct1yB7Gey6CaUsrc=.00f9ede4-8eef-4a37-839d-93e946dfc07d@github.com> Message-ID: On Tue, 23 Sep 2025 09:10:50 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that lets the collection set manage the young cset candidate group directly. Currently everywhere the collection set (not "containing" the young cset candidate group) is used, we immediately do the same thing for the young gen candidate group in the same place. >> >> This makes it kind of natural to put together (and the `G1CollectionSet` already manages adding new regions to the young gen cset group anyway, so that split in responsibility is questionable anyway). >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' into 8367731-g1collectionset-manage-young-gen-group > - * comment update > - * let collectionset manage the young regions group card set Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27312#pullrequestreview-3256994846 From duke at openjdk.org Tue Sep 23 09:32:32 2025 From: duke at openjdk.org (duke) Date: Tue, 23 Sep 2025 09:32:32 GMT Subject: RFR: 8368345: Remove leftover includes of strongRootsScope.hpp In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 23:54:09 GMT, Francesco Andreuzzi wrote: > #27336 and #27385 replaced some `StrongRootsScope` usages with `ThreadsClaimTokenScope`. Some includes to `strongRootsScope.hpp` can now be removed. > > This looks trivial to me. > > Passes tier1. @fandreuz Your change (at version 964d646d29d6c178221cd488aeed1478d0f3b74f) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27442#issuecomment-3323138946 From fandreuzzi at openjdk.org Tue Sep 23 09:44:13 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Tue, 23 Sep 2025 09:44:13 GMT Subject: Integrated: 8368345: Remove leftover includes of strongRootsScope.hpp In-Reply-To: References: Message-ID: <-QftKXCsrSNK8-_RYhSOSInfLOo9SbKflZImoXHWtP8=.f1549d2d-fbab-497f-a97a-9863035c2bbe@github.com> On Mon, 22 Sep 2025 23:54:09 GMT, Francesco Andreuzzi wrote: > #27336 and #27385 replaced some `StrongRootsScope` usages with `ThreadsClaimTokenScope`. Some includes to `strongRootsScope.hpp` can now be removed. > > This looks trivial to me. > > Passes tier1. This pull request has now been integrated. Changeset: b48f5193 Author: Francesco Andreuzzi Committer: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/b48f51932fb4c83f9ff102b286fb65e9a0e12de0 Stats: 2 lines in 2 files changed: 0 ins; 2 del; 0 mod 8368345: Remove leftover includes of strongRootsScope.hpp Reviewed-by: stefank, tschatzl, ayang ------------- PR: https://git.openjdk.org/jdk/pull/27442 From tschatzl at openjdk.org Tue Sep 23 09:54:21 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 23 Sep 2025 09:54:21 GMT Subject: RFR: 8367731: G1: Make G1CollectionSet manage the young gen cset group [v3] In-Reply-To: References: Message-ID: <6OvSxH58VwmNyxEM20LtbZZeiGO9kcUmZQQ_31q5Hz4=.e9c1400c-2606-4d61-ac81-b73615193de0@github.com> > Hi all, > > please review this change that lets the collection set manage the young cset candidate group directly. Currently everywhere the collection set (not "containing" the young cset candidate group) is used, we immediately do the same thing for the young gen candidate group in the same place. > > This makes it kind of natural to put together (and the `G1CollectionSet` already manages adding new regions to the young gen cset group anyway, so that split in responsibility is questionable anyway). > > Testing: gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * failed to save file with changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27312/files - new: https://git.openjdk.org/jdk/pull/27312/files/62805728..ac100719 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27312&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27312&range=01-02 Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27312.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27312/head:pull/27312 PR: https://git.openjdk.org/jdk/pull/27312 From iwalulya at openjdk.org Tue Sep 23 10:47:31 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 23 Sep 2025 10:47:31 GMT Subject: RFR: 8367731: G1: Make G1CollectionSet manage the young gen cset group [v3] In-Reply-To: <6OvSxH58VwmNyxEM20LtbZZeiGO9kcUmZQQ_31q5Hz4=.e9c1400c-2606-4d61-ac81-b73615193de0@github.com> References: <6OvSxH58VwmNyxEM20LtbZZeiGO9kcUmZQQ_31q5Hz4=.e9c1400c-2606-4d61-ac81-b73615193de0@github.com> Message-ID: On Tue, 23 Sep 2025 09:54:21 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that lets the collection set manage the young cset candidate group directly. Currently everywhere the collection set (not "containing" the young cset candidate group) is used, we immediately do the same thing for the young gen candidate group in the same place. >> >> This makes it kind of natural to put together (and the `G1CollectionSet` already manages adding new regions to the young gen cset group anyway, so that split in responsibility is questionable anyway). >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * failed to save file with changes Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27312#pullrequestreview-3257330872 From tschatzl at openjdk.org Tue Sep 23 11:49:52 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 23 Sep 2025 11:49:52 GMT Subject: RFR: 8367731: G1: Make G1CollectionSet manage the young gen cset group [v3] In-Reply-To: References: <6OvSxH58VwmNyxEM20LtbZZeiGO9kcUmZQQ_31q5Hz4=.e9c1400c-2606-4d61-ac81-b73615193de0@github.com> Message-ID: <8LRrsE4Yg2N13KqnWbR_aMTk3DiHacj7fTJ_2Xx6FCk=.91bed747-0071-4dd8-b70f-8a200199b270@github.com> On Tue, 23 Sep 2025 10:44:18 GMT, Ivan Walulya wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * failed to save file with changes > > Marked as reviewed by iwalulya (Reviewer). Thanks @walulyai @albertnetymk for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/27312#issuecomment-3323654943 From tschatzl at openjdk.org Tue Sep 23 11:49:53 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 23 Sep 2025 11:49:53 GMT Subject: Integrated: 8367731: G1: Make G1CollectionSet manage the young gen cset group In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 10:15:55 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that lets the collection set manage the young cset candidate group directly. Currently everywhere the collection set (not "containing" the young cset candidate group) is used, we immediately do the same thing for the young gen candidate group in the same place. > > This makes it kind of natural to put together (and the `G1CollectionSet` already manages adding new regions to the young gen cset group anyway, so that split in responsibility is questionable anyway). > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 02c78bb4 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/02c78bb47e3a9cc8760dd0d0970bb9855f9909d3 Stats: 65 lines in 8 files changed: 26 ins; 29 del; 10 mod 8367731: G1: Make G1CollectionSet manage the young gen cset group Reviewed-by: iwalulya, ayang ------------- PR: https://git.openjdk.org/jdk/pull/27312 From lkorinth at openjdk.org Tue Sep 23 13:45:03 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 23 Sep 2025 13:45:03 GMT Subject: RFR: 8368251: Parallel: Refactor lgrp_id used in MutableNUMASpace [v2] In-Reply-To: <1c6u6m1uxYU8ImOy0WBWph0pzt-un3FHKuM5odBjLkE=.d0aa2ce1-ffa5-4358-bfd2-5f8ef411942a@github.com> References: <88Djo0LC5If0BwK55jK6e80Pr-k-HP7H0kRu__16Wfk=.500f12aa-4b38-40d8-88c8-7372004cdda5@github.com> <1c6u6m1uxYU8ImOy0WBWph0pzt-un3FHKuM5odBjLkE=.d0aa2ce1-ffa5-4358-bfd2-5f8ef411942a@github.com> Message-ID: On Tue, 23 Sep 2025 08:58:19 GMT, Joel Sikstr?m wrote: >> Hello, >> >> There are multiple cases which handle if the locality group (lgrp) id is negative (-1) in Parallel, specifically in MutableNUMASpace. -1 was historically used to indicate that the hardware topology has changed and that the lgrp id needs to be updated. This is no longer the case, since HotSpot doesn't support CPU/NUMA hotplugging, and the last piece of code setting the lgrp id to -1 was removed in [JDK-8301149](https://bugs.openjdk.org/browse/JDK-8301149). >> >> I propose we simplify the code a bit by not handling edge cases where the lgrp id is -1 and removing os::numa_has_group_homing(), which always return false >> >> Testing: >> * Running through Oracle's tier 1-4 >> * Local NUMA testing tier1-4 with `-XX:+UseParallelGC -XX:+UseNUMA` > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > Don't set lgrp_id on Windows since we don't support NUMA there src/hotspot/share/gc/parallel/psYoungGen.cpp line 317: > 315: > 316: HeapWord* result = eden_space()->cas_allocate(word_size); > 317: assert(result || UseNUMA, "inv"); I prefer using `result != nullptr` (not relying on automatic conversion to boolean) but this is pre-existing, so you do not need to change it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27424#discussion_r2372391106 From lkorinth at openjdk.org Tue Sep 23 13:49:36 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 23 Sep 2025 13:49:36 GMT Subject: RFR: 8368251: Parallel: Refactor lgrp_id used in MutableNUMASpace [v2] In-Reply-To: <1c6u6m1uxYU8ImOy0WBWph0pzt-un3FHKuM5odBjLkE=.d0aa2ce1-ffa5-4358-bfd2-5f8ef411942a@github.com> References: <88Djo0LC5If0BwK55jK6e80Pr-k-HP7H0kRu__16Wfk=.500f12aa-4b38-40d8-88c8-7372004cdda5@github.com> <1c6u6m1uxYU8ImOy0WBWph0pzt-un3FHKuM5odBjLkE=.d0aa2ce1-ffa5-4358-bfd2-5f8ef411942a@github.com> Message-ID: On Tue, 23 Sep 2025 08:58:19 GMT, Joel Sikstr?m wrote: >> Hello, >> >> There are multiple cases which handle if the locality group (lgrp) id is negative (-1) in Parallel, specifically in MutableNUMASpace. -1 was historically used to indicate that the hardware topology has changed and that the lgrp id needs to be updated. This is no longer the case, since HotSpot doesn't support CPU/NUMA hotplugging, and the last piece of code setting the lgrp id to -1 was removed in [JDK-8301149](https://bugs.openjdk.org/browse/JDK-8301149). >> >> I propose we simplify the code a bit by not handling edge cases where the lgrp id is -1 and removing os::numa_has_group_homing(), which always return false >> >> Testing: >> * Running through Oracle's tier 1-4 >> * Local NUMA testing tier1-4 with `-XX:+UseParallelGC -XX:+UseNUMA` > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > Don't set lgrp_id on Windows since we don't support NUMA there src/hotspot/share/runtime/thread.cpp line 68: > 66: set_stack_base(nullptr); > 67: set_stack_size(0); > 68: _lgrp_id = -1; Here I would prefer initialising the value in an initialiser list but I think it is okay to let it be as it is (it is following the style of the file). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27424#discussion_r2372403442 From kdnilsen at openjdk.org Tue Sep 23 14:51:28 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 23 Sep 2025 14:51:28 GMT Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need accurate live_data [v9] In-Reply-To: <8GvpkoZ5-Pso8XG-AKeR0QnlBQr0op9E-lvQMS12lTI=.6c88343d-4c74-4f29-a528-f499f559a2bd@github.com> References: <8GvpkoZ5-Pso8XG-AKeR0QnlBQr0op9E-lvQMS12lTI=.6c88343d-4c74-4f29-a528-f499f559a2bd@github.com> Message-ID: On Tue, 16 Sep 2025 21:29:34 GMT, Kelvin Nilsen wrote: >> The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected. In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region. This is typically ok for young regions, where the amount of live data determines whether a region should be added to the collection set during the final-mark safepoint. >> >> However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated. In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended. >> >> This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > Fix compilation errors after merge CI data collected over several days of runs shows slight improvement or neutral impact on metrics: Sept. 16, 2025: Control: openjdk-master-aarch64 Experiment: fix-live-data-for-mixed-evac-candidates-gh-aarch64 Genshen ------------------------------------------------------------------------------------------------------- -19.76% kafka/dacapo_simple_latency_min p=0.00321 Control: 478.000us (+/- 66.09us) 70 Test: 399.125us (+/- 96.26us) 10 -12.10% avrora/shenandoahinitmark_stopped p=0.00001 Control: 0.052ms (+/- 0.01ms) 296 Test: 0.047ms (+/- 0.01ms) 44 -11.57% specjbb2015_weak_ref_patch/prepare_young p=0.00012 Control: 1.602ms (+/-107.15us) 45 Test: 1.436ms (+/- 97.24us) 6 -11.15% specjbb2015_weak_ref_patch/update_roots_young p=0.00021 Control: 1.559ms (+/-106.96us) 45 Test: 1.403ms (+/- 95.82us) 6 Shenandoah ------------------------------------------------------------------------------------------------------- -15.40% serial/cleanclassloaderdatametaspaces_stopped p=0.00236 Control: 0.110ms (+/- 0.01ms) 70 Test: 0.096ms (+/- 0.01ms) 10 Sept. 18, 2025: Control: openjdk-master-aarch64 Experiment: fix-live-data-for-mixed-evac-candidates-gh-aarch64 Genshen ------------------------------------------------------------------------------------------------------- -54.93% reactors/shenandoah_old_gen_used p=0.00069 Control: 7168817.375 (+/-2595408.39 ) 80 Test: 4627212.500 (+/-1664542.48 ) 20 -16.67% dotty/shenandoah_old_gen_used p=0.00325 Control: 16102164.875 (+/-2840080.53 ) 80 Test: 13801402.000 (+/-2233823.94 ) 20 -12.42% specjbb2015_weak_ref_patch/fu_thread_roots_young p=0.00088 Control: 1.649ms (+/-177.28us) 50 Test: 1.467ms (+/-157.40us) 13 -11.12% kafka/dacapo_simple_latency_min p=0.00435 Control: 483.453us (+/- 58.27us) 80 Test: 435.062us (+/- 82.07us) 20 Shenandoah ------------------------------------------------------------------------------------------------------- -13.50% serial/cleanclassloaderdatametaspaces_stopped p=0.00023 Control: 0.111ms (+/- 0.01ms) 80 Test: 0.098ms (+/- 0.01ms) 20 Sept. 19, 2025: Control: openjdk-master-x86_64 Experiment: fix-live-data-for-mixed-evac-candidates-gh-x86 Genshen ------------------------------------------------------------------------------------------------------- +22.88% spring/dacapo_metered_latency_max p=0.00553 Control: 57.031ms (+/- 17.50ms) 100 Test: 70.081ms (+/- 14.02ms) 20 -60.91% reactors/shenandoah_old_gen_used p=0.00002 Control: 7445668.600 (+/-2417060.62 ) 100 Test: 4627212.500 (+/-1664542.48 ) 20 -16.80% dotty/shenandoah_old_gen_used p=0.00223 Control: 16119749.300 (+/-2805728.19 ) 100 Test: 13801402.000 (+/-2233823.94 ) 20 -11.45% specjbb2015_weak_ref_patch/fu_thread_roots_young p=0.00026 Control: 1.635ms (+/-159.88us) 75 Test: 1.467ms (+/-157.40us) 13 Shenandoah ------------------------------------------------------------------------------------------------------- -13.07% serial/cleanclassloaderdatametaspaces_stopped p=0.00029 Control: 0.110ms (+/- 0.01ms) 100 Test: 0.098ms (+/- 0.01ms) 20 ------------- PR Comment: https://git.openjdk.org/jdk/pull/24319#issuecomment-3324353923 From kdnilsen at openjdk.org Tue Sep 23 15:03:22 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 23 Sep 2025 15:03:22 GMT Subject: RFR: 8368015: Shenandoah: fix error in computation of average allocation rate [v2] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 23:10:07 GMT, William Kemper wrote: > Should we move [this line](https://github.com/openjdk/jdk/pull/27398/files#diff-5cbba824b4e4b914425672f0d1bea49b44aa48940fd07f517b7312055927c575R249) > where we take the allocation sample above the early exit when `_start_gc_is_pending`? > Not directly related to this PR, but seems to be in the spirit of making the allocation rate sampling more accurate. That's a good suggestion. I'll move it. > src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 382: > >> 380: } >> 381: >> 382: double ShenandoahAllocationRate::sample(size_t allocated, bool force_update) { > > `force_update` looks unused here. Thanks for that catch. I failed to clean up my mess after an earlier experiment that didn't work... Fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27398#issuecomment-3324386185 PR Review Comment: https://git.openjdk.org/jdk/pull/27398#discussion_r2372626061 From kdnilsen at openjdk.org Tue Sep 23 15:03:25 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 23 Sep 2025 15:03:25 GMT Subject: RFR: 8368015: Shenandoah: fix error in computation of average allocation rate [v2] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 19:13:41 GMT, Kelvin Nilsen wrote: >> We use bytes_allocated_since_gc_start() to compute allocation rates. This leaves a blind spot, as our current implementation ignores allocations and the time period between the moment we begin GC and the first time we update the allocation rate following the start of GC. When this happens, we typically find that the sampled number of allocations is smaller than the allocations that had accumulated by the time we triggered the start of the current GC cycle. >> >> This PR adds tracking for that accounting gap. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > remove state variable previous GC allocated I've also run current baseline tests for comparison with this branch. Here are the results: image ------------- PR Comment: https://git.openjdk.org/jdk/pull/27398#issuecomment-3324392518 From kdnilsen at openjdk.org Tue Sep 23 15:20:16 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 23 Sep 2025 15:20:16 GMT Subject: RFR: 8368015: Shenandoah: fix error in computation of average allocation rate [v3] In-Reply-To: References: Message-ID: > We use bytes_allocated_since_gc_start() to compute allocation rates. This leaves a blind spot, as our current implementation ignores allocations and the time period between the moment we begin GC and the first time we update the allocation rate following the start of GC. When this happens, we typically find that the sampled number of allocations is smaller than the allocations that had accumulated by the time we triggered the start of the current GC cycle. > > This PR adds tracking for that accounting gap. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: reviewer feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27398/files - new: https://git.openjdk.org/jdk/pull/27398/files/2e422421..bd7448ad Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27398&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27398&range=01-02 Stats: 7 lines in 2 files changed: 3 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27398.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27398/head:pull/27398 PR: https://git.openjdk.org/jdk/pull/27398 From kdnilsen at openjdk.org Tue Sep 23 15:41:13 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 23 Sep 2025 15:41:13 GMT Subject: RFR: 8368015: Shenandoah: fix error in computation of average allocation rate [v2] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 23:07:16 GMT, William Kemper wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> remove state variable previous GC allocated > > src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 364: > >> 362: >> 363: double ShenandoahAllocationRate::force_sample(size_t allocated, size_t &unaccounted_bytes_allocated) { >> 364: const double MinSampleTime = 0.002; // Do not sample if time since last update is less than 2 ms > > Would it make sense to "carry over" the `unaccounted_bytes_allocated` if, at the time of reset, the last sample was taken less than `ShenandoahAllocationRate::_interval_sec` (instead of `MinSampleTime`)? I believe this would result in more samples being carried over. I've done experiments with a variety of different values for MinSampleTime (e.g. 50 ms, 25ms, 2 ms). I find that any value greater than 1 ms works pretty well in the sense that the measured rate is pretty consistent with the average rate as computed by the preexisting mechanisms. The biggest problem I observed was when we tried to measure rate over an interval of a few microseconds, and these intervals sometimes had zero allocations. We could make the change you suggest, but that would actually result in fewer samples rather than more. It would also make the value of bytes_allocated_since_gc_start() less precise in that this quantity would carry up to 100 ms of allocations that actually occurred before the start of the current GC. Here's an ASCII art attempt to illustrate how it works in the current implementation. Here is a timeline with a tick mark to illustrate the desired sample time, every 100 ms: .1s .2s .3s .4s. .5s .6s .7s .8s. .9s 1s 1.1s 1.2s |---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|--- ^ ^ Existing | | Samples: A B C D E | | Proposed | | Samples: A | B C D | | | | Trigger GC at 0.14s Finish GC at 1.03s In either approach, we sample at 0.1s and this sample contributes to the average allocation rate that causes us to trigger at time 0.14s. In the current implementation, at time 0.14s, we take a new sample representing the most current allocation rate as computed over the span between 0.1s and 0.14s. As implemented, if this time delta (0.14s minus 0.10s =0.04s) is less than 2 ms, we'll skip sample B. I think you are proposing that we skip sample B whenever this delta is less than 100 ms (_interval_sec). We do not sample during GC. As soon as GC finishes, we begin asking the question, should I start another GC. This resumes the sampling activity, aligning the periodic samples on the time at which we finished previous GC cycle. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27398#discussion_r2372740860 From lkorinth at openjdk.org Tue Sep 23 18:00:07 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 23 Sep 2025 18:00:07 GMT Subject: RFR: 8368251: Parallel: Refactor lgrp_id used in MutableNUMASpace [v2] In-Reply-To: <1c6u6m1uxYU8ImOy0WBWph0pzt-un3FHKuM5odBjLkE=.d0aa2ce1-ffa5-4358-bfd2-5f8ef411942a@github.com> References: <88Djo0LC5If0BwK55jK6e80Pr-k-HP7H0kRu__16Wfk=.500f12aa-4b38-40d8-88c8-7372004cdda5@github.com> <1c6u6m1uxYU8ImOy0WBWph0pzt-un3FHKuM5odBjLkE=.d0aa2ce1-ffa5-4358-bfd2-5f8ef411942a@github.com> Message-ID: On Tue, 23 Sep 2025 08:58:19 GMT, Joel Sikstr?m wrote: >> Hello, >> >> There are multiple cases which handle if the locality group (lgrp) id is negative (-1) in Parallel, specifically in MutableNUMASpace. -1 was historically used to indicate that the hardware topology has changed and that the lgrp id needs to be updated. This is no longer the case, since HotSpot doesn't support CPU/NUMA hotplugging, and the last piece of code setting the lgrp id to -1 was removed in [JDK-8301149](https://bugs.openjdk.org/browse/JDK-8301149). >> >> I propose we simplify the code a bit by not handling edge cases where the lgrp id is -1 and removing os::numa_has_group_homing(), which always return false >> >> Testing: >> * Running through Oracle's tier 1-4 >> * Local NUMA testing tier1-4 with `-XX:+UseParallelGC -XX:+UseNUMA` > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > Don't set lgrp_id on Windows since we don't support NUMA there Thanks for cleaning, this looks good to me. ------------- Marked as reviewed by lkorinth (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27424#pullrequestreview-3259076785 From wkemper at openjdk.org Tue Sep 23 20:07:37 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 23 Sep 2025 20:07:37 GMT Subject: RFR: 8368152: Shenandoah: Incorrect behavior at end of degenerated cycle Message-ID: There are several issues addressed in this PR: * Shenandoah always ran a full GC after any degenerated cycle * The number of consecutive degenerated GCs with bad progress was reset for every degenerated cycle * Good progress was reported in generational mode even when no progress is made ------------- Commit messages: - Improve documentation, add unit test - Fix logic for handling degenerated cycles that do not make good progress Changes: https://git.openjdk.org/jdk/pull/27456/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27456&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368152 Stats: 123 lines in 5 files changed: 101 ins; 9 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/27456.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27456/head:pull/27456 PR: https://git.openjdk.org/jdk/pull/27456 From wkemper at openjdk.org Tue Sep 23 21:13:27 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 23 Sep 2025 21:13:27 GMT Subject: RFR: 8368152: Shenandoah: Incorrect behavior at end of degenerated cycle [v2] In-Reply-To: References: Message-ID: > There are several issues addressed in this PR: > * Shenandoah always ran a full GC after any degenerated cycle > * The number of consecutive degenerated GCs with bad progress was reset for every degenerated cycle > * Good progress was reported in generational mode even when no progress is made William Kemper has updated the pull request incrementally with one additional commit since the last revision: Fix typo in comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27456/files - new: https://git.openjdk.org/jdk/pull/27456/files/f5aa7b13..c962f198 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27456&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27456&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27456.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27456/head:pull/27456 PR: https://git.openjdk.org/jdk/pull/27456 From kdnilsen at openjdk.org Tue Sep 23 21:13:28 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 23 Sep 2025 21:13:28 GMT Subject: RFR: 8368152: Shenandoah: Incorrect behavior at end of degenerated cycle [v2] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 21:10:11 GMT, William Kemper wrote: >> There are several issues addressed in this PR: >> * Shenandoah always ran a full GC after any degenerated cycle >> * The number of consecutive degenerated GCs with bad progress was reset for every degenerated cycle >> * Good progress was reported in generational mode even when no progress is made > > William Kemper has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo in comment A common scenario that I have seen in various GC logs is the following: 1. Concurrent GC experiences allocation failure and degenerates 2. Degenerated GC fails to make progress because lots of garbage was allocated after the start of concurrent marking (ie. all garbage is floating) 3. We escalate to Full GC, resulting in a very long STW delay (The Full GC delay plus the delay for degen that preceded Full GC) 4. It is often the case that better throughput and better latency is realized if we run a concurrent GC which may once again degenerate, rather than escalating from the first degen to Full GC. All of the floating garbage that was locked up during the previous GC should be reclaimed by the second concurrent (possibly degenerated) GC, so the second cycle should have "good progress" even if the first did not. 5. I believe the solution you've implemented here will first try a second concurrent/degenerated cycle before escalating to Full GC. Will you confirm that? Should we have some comments in this code to explain why CONSECUTIVE_BAD_DEGEN_PROGRESS_THRESHOLD is 2 and not 1? ------------- Marked as reviewed by kdnilsen (Committer). PR Review: https://git.openjdk.org/jdk/pull/27456#pullrequestreview-3259587644 From wkemper at openjdk.org Tue Sep 23 21:13:30 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 23 Sep 2025 21:13:30 GMT Subject: RFR: 8368152: Shenandoah: Incorrect behavior at end of degenerated cycle In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 19:59:05 GMT, William Kemper wrote: > There are several issues addressed in this PR: > * Shenandoah always ran a full GC after any degenerated cycle > * The number of consecutive degenerated GCs with bad progress was reset for every degenerated cycle > * Good progress was reported in generational mode even when no progress is made There is a comment in `shDegeneratedGC` explaining this scenario. I'll move it to `shCollectorPolicy`. I didn't quite understand why single-gen mode would not benefit equally from this reasoning, but I tried to preserve the original intended behavior. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27456#issuecomment-3325562835 From wkemper at openjdk.org Tue Sep 23 21:24:20 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 23 Sep 2025 21:24:20 GMT Subject: RFR: 8368152: Shenandoah: Incorrect behavior at end of degenerated cycle [v3] In-Reply-To: References: Message-ID: > There are several issues addressed in this PR: > * Shenandoah always ran a full GC after any degenerated cycle > * The number of consecutive degenerated GCs with bad progress was reset for every degenerated cycle > * Good progress was reported in generational mode even when no progress is made William Kemper has updated the pull request incrementally with one additional commit since the last revision: Improve comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27456/files - new: https://git.openjdk.org/jdk/pull/27456/files/c962f198..2324450a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27456&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27456&range=01-02 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27456.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27456/head:pull/27456 PR: https://git.openjdk.org/jdk/pull/27456 From duke at openjdk.org Tue Sep 23 21:26:00 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Tue, 23 Sep 2025 21:26:00 GMT Subject: RFR: 8366970: CPUTimeUsage: Add comment about usage during VM exit In-Reply-To: References: Message-ID: <-qtIjh72_GAo1imT-FMFG4JZY8oBQQZk1OIzXEk46xM=.615a0f83-00dd-49b3-9272-6f61df419d51@github.com> On Fri, 5 Sep 2025 10:06:32 GMT, Jonas Norlinder wrote: > Some of the methods in CPUTimeUsage make a query on the underlying threads. Calling those methods during VM exit is therefore unsafe. This PR adds a comment to provide clarification. Withdrawn in favor of using _is_shutting down introduced by 8366865 ------------- PR Comment: https://git.openjdk.org/jdk/pull/27115#issuecomment-3325595230 From duke at openjdk.org Tue Sep 23 21:26:00 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Tue, 23 Sep 2025 21:26:00 GMT Subject: Withdrawn: 8366970: CPUTimeUsage: Add comment about usage during VM exit In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 10:06:32 GMT, Jonas Norlinder wrote: > Some of the methods in CPUTimeUsage make a query on the underlying threads. Calling those methods during VM exit is therefore unsafe. This PR adds a comment to provide clarification. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27115 From ysr at openjdk.org Tue Sep 23 22:05:28 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Tue, 23 Sep 2025 22:05:28 GMT Subject: RFR: 8368152: Shenandoah: Incorrect behavior at end of degenerated cycle [v3] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 21:24:20 GMT, William Kemper wrote: >> There are several issues addressed in this PR: >> * Shenandoah always ran a full GC after any degenerated cycle >> * The number of consecutive degenerated GCs with bad progress was reset for every degenerated cycle >> * Good progress was reported in generational mode even when no progress is made > > William Kemper has updated the pull request incrementally with one additional commit since the last revision: > > Improve comment Looks good; left some documentation nits, but approved even if the documentation suggestions aren't taken. ? src/hotspot/share/gc/shenandoah/shenandoahCollectorPolicy.hpp line 68: > 66: // in generational mode, run a full GC. Non-generational modes will upgrade > 67: // immediately when a degenerated cycle does not make progress. Many degenerated > 68: // cycles are caused by floating garbage. It is more efficient to attempt If it's used only for generational case, I'd like the comment to be less coy about it. I'd place `GENERATIONAL` or some such in the name of the constant, e.g. `GENERATIONAL_TO_FULL_NON_PROGRESSING_DEGENS`, and its "accessor" (or user) down in `should_upgrade_degenerated_gc()` to, e.g., `generational_should_upgrade_degen_to_full()`. The comment could say: // When a degenerated cycle doesn't make progress: // a. for the non-generational case, we'll immediately upgrade to full at the first non-progressing degen // b. for the generational case, we'll upgrade to full after these many non-progressing consecutive degens My question is why we choose this number for genshen. May be a sentence in the ticket or in the comments on the intuition here? src/hotspot/share/gc/shenandoah/shenandoahCollectorPolicy.hpp line 117: > 115: // Genshen will only upgrade to a full gc after the configured number of futile degenerated cycles. > 116: bool should_upgrade_degenerated_gc() const { > 117: return _consecutive_degenerated_gcs_without_progress >= CONSECUTIVE_BAD_DEGEN_PROGRESS_THRESHOLD; assert that heap is generational? See previous comment above at line 68. src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp line 323: > 321: // Shenandoah to avoid introducing "surprising new behavior." It also makes less sense with non-generational > 322: // Shenandoah to replace a full GC with a degenerated GC, because both have similar pause times in non-generational > 323: // mode. May be, based on the first paragraph above, you want to say more simply (replacing the entire second paragraph): On the other hand, in non-generational mode, to both preserve legacy behavior, and because the difference between a degenerated gc and full gc is smaller, we immediately escalate to a full gc following the first degenerated cycle that doesn't make progress. I'd also move this comment out from here and to the constant that was defined for the number of consecutive degens before escalating to full in generational mode. ------------- Marked as reviewed by ysr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27456#pullrequestreview-3259658651 PR Review Comment: https://git.openjdk.org/jdk/pull/27456#discussion_r2373504315 PR Review Comment: https://git.openjdk.org/jdk/pull/27456#discussion_r2373507843 PR Review Comment: https://git.openjdk.org/jdk/pull/27456#discussion_r2373546896 From ysr at openjdk.org Tue Sep 23 22:05:29 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Tue, 23 Sep 2025 22:05:29 GMT Subject: RFR: 8368152: Shenandoah: Incorrect behavior at end of degenerated cycle [v3] In-Reply-To: References: Message-ID: <4d3hrqqqX8Dxl474hJ6fA2aCQclSHCMPao2tHdcXVx0=.06c86e17-aa98-4c55-88a9-74573b26dad6@github.com> On Tue, 23 Sep 2025 21:31:40 GMT, Y. Srinivas Ramakrishna wrote: >> William Kemper has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve comment > > src/hotspot/share/gc/shenandoah/shenandoahCollectorPolicy.hpp line 68: > >> 66: // in generational mode, run a full GC. Non-generational modes will upgrade >> 67: // immediately when a degenerated cycle does not make progress. Many degenerated >> 68: // cycles are caused by floating garbage. It is more efficient to attempt > > If it's used only for generational case, I'd like the comment to be less coy about it. I'd place `GENERATIONAL` or some such in the name of the constant, e.g. `GENERATIONAL_TO_FULL_NON_PROGRESSING_DEGENS`, and its "accessor" (or user) down in `should_upgrade_degenerated_gc()` to, e.g., `generational_should_upgrade_degen_to_full()`. > > The comment could say: > > > // When a degenerated cycle doesn't make progress: > // a. for the non-generational case, we'll immediately upgrade to full at the first non-progressing degen > // b. for the generational case, we'll upgrade to full after these many non-progressing consecutive degens > > > My question is why we choose this number for genshen. May be a sentence in the ticket or in the comments on the intuition here? Noticed the long comment at lines 313-323 in `ShenandoahDegenGC::collect()` that describes why. May be move that comment (made suitably more succinct) to this place also to tie it all together in one place. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27456#discussion_r2373551052 From kdnilsen at openjdk.org Tue Sep 23 22:17:33 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 23 Sep 2025 22:17:33 GMT Subject: RFR: 8368015: Shenandoah: fix error in computation of average allocation rate [v4] In-Reply-To: References: Message-ID: <2mbrDmNAYPTgsWGuMuGYJHPpb-fYm54iILreEPjA5fI=.4018f21c-269f-41b4-9668-dc80c98abd46@github.com> > We use bytes_allocated_since_gc_start() to compute allocation rates. This leaves a blind spot, as our current implementation ignores allocations and the time period between the moment we begin GC and the first time we update the allocation rate following the start of GC. When this happens, we typically find that the sampled number of allocations is smaller than the allocations that had accumulated by the time we triggered the start of the current GC cycle. > > This PR adds tracking for that accounting gap. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Add override declarations to satisfy certain compilers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27398/files - new: https://git.openjdk.org/jdk/pull/27398/files/bd7448ad..81db0b67 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27398&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27398&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27398.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27398/head:pull/27398 PR: https://git.openjdk.org/jdk/pull/27398 From wkemper at openjdk.org Tue Sep 23 22:24:14 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 23 Sep 2025 22:24:14 GMT Subject: RFR: 8368152: Shenandoah: Incorrect behavior at end of degenerated cycle [v4] In-Reply-To: References: Message-ID: > There are several issues addressed in this PR: > * Shenandoah always ran a full GC after any degenerated cycle > * The number of consecutive degenerated GCs with bad progress was reset for every degenerated cycle > * Good progress was reported in generational mode even when no progress is made William Kemper has updated the pull request incrementally with one additional commit since the last revision: Improve comments and names ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27456/files - new: https://git.openjdk.org/jdk/pull/27456/files/2324450a..4c36c6f3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27456&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27456&range=02-03 Stats: 32 lines in 3 files changed: 5 ins; 10 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/27456.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27456/head:pull/27456 PR: https://git.openjdk.org/jdk/pull/27456 From ysr at openjdk.org Tue Sep 23 22:24:17 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Tue, 23 Sep 2025 22:24:17 GMT Subject: RFR: 8368152: Shenandoah: Incorrect behavior at end of degenerated cycle [v3] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 21:24:20 GMT, William Kemper wrote: >> There are several issues addressed in this PR: >> * Shenandoah always ran a full GC after any degenerated cycle >> * The number of consecutive degenerated GCs with bad progress was reset for every degenerated cycle >> * Good progress was reported in generational mode even when no progress is made > > William Kemper has updated the pull request incrementally with one additional commit since the last revision: > > Improve comment Also, independently, I think the notion of progress should be clarified based on current implementation in `ShenandoahMetricsSnapshot::is_good_progress()` (which declaration should itself have a brief comment): Compare before and after snapshots to determine if GC made sufficient progress. The notion of progress is based on space free after, change in space freed, or changes in internal and/or external fragmentation. I found it slightly confusing that even though a `Generation` argument is passed into the method, it's really not used directly as far as I could tell in the notion of progress. The metrics all appear to be heap-wide, rather than generation-wide. There is a comment about the collection set being proportional to the generation in question which of course makes sense, but I'd much rather we didn't pass in an argument that isn't used there, but rather address it directly in the documentation. May be I am missing something? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27456#issuecomment-3325724362 From wkemper at openjdk.org Tue Sep 23 22:24:20 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 23 Sep 2025 22:24:20 GMT Subject: RFR: 8368152: Shenandoah: Incorrect behavior at end of degenerated cycle [v3] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 21:33:53 GMT, Y. Srinivas Ramakrishna wrote: >> William Kemper has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve comment > > src/hotspot/share/gc/shenandoah/shenandoahCollectorPolicy.hpp line 117: > >> 115: // Genshen will only upgrade to a full gc after the configured number of futile degenerated cycles. >> 116: bool should_upgrade_degenerated_gc() const { >> 117: return _consecutive_degenerated_gcs_without_progress >= CONSECUTIVE_BAD_DEGEN_PROGRESS_THRESHOLD; > > assert that heap is generational? See previous comment above at line 68. I renamed the method, but I don't want to put an assert on the mode here because it would make the unit test much harder to run. > src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp line 323: > >> 321: // Shenandoah to avoid introducing "surprising new behavior." It also makes less sense with non-generational >> 322: // Shenandoah to replace a full GC with a degenerated GC, because both have similar pause times in non-generational >> 323: // mode. > > May be, based on the first paragraph above, you want to say more simply (replacing the entire second paragraph): > > On the other hand, in non-generational mode, > to both preserve legacy behavior, and because the > difference between a degenerated gc and full gc is smaller, > we immediately escalate to > a full gc following the first degenerated cycle that doesn't make progress. > > > I'd also move this comment out from here and to the constant that was defined for the number of consecutive degens before escalating to full in generational mode. I moved the whole explanation into `shCollectorPolicy`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27456#discussion_r2373573529 PR Review Comment: https://git.openjdk.org/jdk/pull/27456#discussion_r2373574294 From wkemper at openjdk.org Tue Sep 23 22:26:31 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 23 Sep 2025 22:26:31 GMT Subject: RFR: 8368152: Shenandoah: Incorrect behavior at end of degenerated cycle [v4] In-Reply-To: References: Message-ID: <8a6wleS4lVtHAIM16-jcZmE0IzTraEslvX02RW0APaU=.8d96b9d8-4d62-418c-bd5f-d7350bb58de9@github.com> On Tue, 23 Sep 2025 22:24:14 GMT, William Kemper wrote: >> There are several issues addressed in this PR: >> * Shenandoah always ran a full GC after any degenerated cycle >> * The number of consecutive degenerated GCs with bad progress was reset for every degenerated cycle >> * Good progress was reported in generational mode even when no progress is made > > William Kemper has updated the pull request incrementally with one additional commit since the last revision: > > Improve comments and names You're right that the `generation` argument to `is_good_progress` is unused. I think it makes sense to instead pass this to the `shMetrics` constructor and have it evaluate `used` from the generation. I will experiment with this, but I think it's outside the scope of this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27456#issuecomment-3325736835 From kdnilsen at openjdk.org Tue Sep 23 22:31:19 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 23 Sep 2025 22:31:19 GMT Subject: RFR: 8368152: Shenandoah: Incorrect behavior at end of degenerated cycle [v4] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 22:24:14 GMT, William Kemper wrote: >> There are several issues addressed in this PR: >> * Shenandoah always ran a full GC after any degenerated cycle >> * The number of consecutive degenerated GCs with bad progress was reset for every degenerated cycle >> * Good progress was reported in generational mode even when no progress is made > > William Kemper has updated the pull request incrementally with one additional commit since the last revision: > > Improve comments and names Marked as reviewed by kdnilsen (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27456#pullrequestreview-3259769073 From ysr at openjdk.org Tue Sep 23 22:33:55 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Tue, 23 Sep 2025 22:33:55 GMT Subject: RFR: 8368152: Shenandoah: Incorrect behavior at end of degenerated cycle [v4] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 22:24:14 GMT, William Kemper wrote: >> There are several issues addressed in this PR: >> * Shenandoah always ran a full GC after any degenerated cycle >> * The number of consecutive degenerated GCs with bad progress was reset for every degenerated cycle >> * Good progress was reported in generational mode even when no progress is made > > William Kemper has updated the pull request incrementally with one additional commit since the last revision: > > Improve comments and names Marked as reviewed by ysr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27456#pullrequestreview-3259777394 From kdnilsen at openjdk.org Tue Sep 23 22:56:01 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 23 Sep 2025 22:56:01 GMT Subject: RFR: 8368015: Shenandoah: fix error in computation of average allocation rate [v5] In-Reply-To: References: Message-ID: > We use bytes_allocated_since_gc_start() to compute allocation rates. This leaves a blind spot, as our current implementation ignores allocations and the time period between the moment we begin GC and the first time we update the allocation rate following the start of GC. When this happens, we typically find that the sampled number of allocations is smaller than the allocations that had accumulated by the time we triggered the start of the current GC cycle. > > This PR adds tracking for that accounting gap. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: More override declarations to satisfy certain compilers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27398/files - new: https://git.openjdk.org/jdk/pull/27398/files/81db0b67..91f35d25 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27398&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27398&range=03-04 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27398.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27398/head:pull/27398 PR: https://git.openjdk.org/jdk/pull/27398 From wkemper at openjdk.org Wed Sep 24 00:49:53 2025 From: wkemper at openjdk.org (William Kemper) Date: Wed, 24 Sep 2025 00:49:53 GMT Subject: Integrated: 8368152: Shenandoah: Incorrect behavior at end of degenerated cycle In-Reply-To: References: Message-ID: <366AluM9fb6C2xeX-ht46CF8XF3ZzACBKvz8sNRBi_Q=.4e6cf433-ba1d-46e2-8f80-6fe3006a8ef1@github.com> On Tue, 23 Sep 2025 19:59:05 GMT, William Kemper wrote: > There are several issues addressed in this PR: > * Shenandoah always ran a full GC after any degenerated cycle > * The number of consecutive degenerated GCs with bad progress was reset for every degenerated cycle > * Good progress was reported in generational mode even when no progress is made This pull request has now been integrated. Changeset: f36c33c8 Author: William Kemper URL: https://git.openjdk.org/jdk/commit/f36c33c86df0400d2155bfadd9a6b5ea56743133 Stats: 141 lines in 5 files changed: 109 ins; 19 del; 13 mod 8368152: Shenandoah: Incorrect behavior at end of degenerated cycle Reviewed-by: kdnilsen, ysr ------------- PR: https://git.openjdk.org/jdk/pull/27456 From ghan at openjdk.org Wed Sep 24 01:11:40 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Wed, 24 Sep 2025 01:11:40 GMT Subject: RFR: 8368089: G1: G1PeriodicGCTask::should_start_periodic_gc may use uninitialised value if os::loadavg is unsupported [v3] In-Reply-To: <2OvCoQTGiaeASeEzeH7nPlNrqKuVBG4coqXf7FOqEc8=.1071778b-0427-4736-8d2c-4718b85081ca@github.com> References: <2OvCoQTGiaeASeEzeH7nPlNrqKuVBG4coqXf7FOqEc8=.1071778b-0427-4736-8d2c-4718b85081ca@github.com> Message-ID: > Please review this change. Thanks! > > **Description:** > > Previously the check combined loadavg() failure and threshold comparison in a single condition. When os::loadavg() returned -1, `recent_load` contained an undefined value but was still logged as if it was a real load average, leading to misleading log output. > > **Fix:** > > This change separates the failure case from the combined check: > - If os::loadavg() returns -1, log "System loadavg not supported" and skip. > - Only compare `recent_load` to the threshold when loadavg() succeeds. > > **Test:** > > GHA Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: Update g1PeriodicGCTask.cpp Only disable G1PeriodicGCSystemLoadThreshold check when system loadavg not support ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27413/files - new: https://git.openjdk.org/jdk/pull/27413/files/4ff7567c..fcaa92ca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27413&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27413&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27413.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27413/head:pull/27413 PR: https://git.openjdk.org/jdk/pull/27413 From ghan at openjdk.org Wed Sep 24 01:17:20 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Wed, 24 Sep 2025 01:17:20 GMT Subject: RFR: 8368089: G1: G1PeriodicGCTask::should_start_periodic_gc may use uninitialised value if os::loadavg is unsupported [v2] In-Reply-To: <-LoH0pFQhBF8VG39_ssHEEXkaJ9MgsJOcQyDHeZzjto=.72801341-ac35-4089-90aa-112d93cd76db@github.com> References: <2OvCoQTGiaeASeEzeH7nPlNrqKuVBG4coqXf7FOqEc8=.1071778b-0427-4736-8d2c-4718b85081ca@github.com> <-LoH0pFQhBF8VG39_ssHEEXkaJ9MgsJOcQyDHeZzjto=.72801341-ac35-4089-90aa-112d93cd76db@github.com> Message-ID: On Tue, 23 Sep 2025 07:55:33 GMT, Albert Mingkun Yang wrote: >> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: >> >> Update g1PeriodicGCTask.cpp >> >> Disable the functionality when os::loadavg() is not supported. > > src/hotspot/share/gc/g1/g1PeriodicGCTask.cpp line 61: > >> 59: G1PeriodicGCInterval = 0; >> 60: log_warning(gc, periodic)("System loadavg not supported. Periodic GC is disabled " >> 61: "by setting G1PeriodicGCInterval to 0."); > > This disables periodic-gc. It's not super obvious that this is desirable. My expectation would be if `G1PeriodicGCSystemLoadThreshold`, a fine tuning knob in controlling periodic-gc, is not supported, this tuning knob will just be ignored with a warning, instead of disabling periodic-gc completely. > > However, I can also imagine starting periodic-gc when system-load is high can be detrimental, so disabling periodic-gc is safer. > > (Just raising it for discussion.) @albertnetymk @tschatzl Fixed? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27413#discussion_r2373808236 From ghan at openjdk.org Wed Sep 24 01:17:19 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Wed, 24 Sep 2025 01:17:19 GMT Subject: RFR: 8368089: G1: G1PeriodicGCTask::should_start_periodic_gc may use uninitialised value if os::loadavg is unsupported [v4] In-Reply-To: <2OvCoQTGiaeASeEzeH7nPlNrqKuVBG4coqXf7FOqEc8=.1071778b-0427-4736-8d2c-4718b85081ca@github.com> References: <2OvCoQTGiaeASeEzeH7nPlNrqKuVBG4coqXf7FOqEc8=.1071778b-0427-4736-8d2c-4718b85081ca@github.com> Message-ID: > Please review this change. Thanks! > > **Description:** > > Previously the check combined loadavg() failure and threshold comparison in a single condition. When os::loadavg() returned -1, `recent_load` contained an undefined value but was still logged as if it was a real load average, leading to misleading log output. > > **Fix:** > > This change separates the failure case from the combined check: > - If os::loadavg() returns -1, log "System loadavg not supported" and skip. > - Only compare `recent_load` to the threshold when loadavg() succeeds. > > **Test:** > > GHA Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: Update g1PeriodicGCTask.cpp fix a small error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27413/files - new: https://git.openjdk.org/jdk/pull/27413/files/fcaa92ca..106362e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27413&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27413&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27413.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27413/head:pull/27413 PR: https://git.openjdk.org/jdk/pull/27413 From tschatzl at openjdk.org Wed Sep 24 06:08:26 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 24 Sep 2025 06:08:26 GMT Subject: RFR: 8368251: Parallel: Refactor lgrp_id used in MutableNUMASpace [v2] In-Reply-To: <1c6u6m1uxYU8ImOy0WBWph0pzt-un3FHKuM5odBjLkE=.d0aa2ce1-ffa5-4358-bfd2-5f8ef411942a@github.com> References: <88Djo0LC5If0BwK55jK6e80Pr-k-HP7H0kRu__16Wfk=.500f12aa-4b38-40d8-88c8-7372004cdda5@github.com> <1c6u6m1uxYU8ImOy0WBWph0pzt-un3FHKuM5odBjLkE=.d0aa2ce1-ffa5-4358-bfd2-5f8ef411942a@github.com> Message-ID: On Tue, 23 Sep 2025 08:58:19 GMT, Joel Sikstr?m wrote: >> Hello, >> >> There are multiple cases which handle if the locality group (lgrp) id is negative (-1) in Parallel, specifically in MutableNUMASpace. -1 was historically used to indicate that the hardware topology has changed and that the lgrp id needs to be updated. This is no longer the case, since HotSpot doesn't support CPU/NUMA hotplugging, and the last piece of code setting the lgrp id to -1 was removed in [JDK-8301149](https://bugs.openjdk.org/browse/JDK-8301149). >> >> I propose we simplify the code a bit by not handling edge cases where the lgrp id is -1 and removing os::numa_has_group_homing(), which always return false >> >> Testing: >> * Running through Oracle's tier 1-4 >> * Local NUMA testing tier1-4 with `-XX:+UseParallelGC -XX:+UseNUMA` > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > Don't set lgrp_id on Windows since we don't support NUMA there src/hotspot/os/windows/os_windows.cpp line 543: > 541: } > 542: } > 543: I recommend asserting that `UseNUMA` is false here, with a message like `Should set NUMA id here` to not miss this later. I prefer trying to formalize code assumptions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27424#discussion_r2374513598 From tschatzl at openjdk.org Wed Sep 24 06:12:19 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 24 Sep 2025 06:12:19 GMT Subject: RFR: 8368251: Parallel: Refactor lgrp_id used in MutableNUMASpace [v2] In-Reply-To: References: <88Djo0LC5If0BwK55jK6e80Pr-k-HP7H0kRu__16Wfk=.500f12aa-4b38-40d8-88c8-7372004cdda5@github.com> <1c6u6m1uxYU8ImOy0WBWph0pzt-un3FHKuM5odBjLkE=.d0aa2ce1-ffa5-4358-bfd2-5f8ef411942a@github.com> Message-ID: On Wed, 24 Sep 2025 06:05:37 GMT, Thomas Schatzl wrote: >> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: >> >> Don't set lgrp_id on Windows since we don't support NUMA there > > src/hotspot/os/windows/os_windows.cpp line 543: > >> 541: } >> 542: } >> 543: > > I recommend asserting that `UseNUMA` is false here, with a message like `Should set NUMA id here` to not miss this later. > I prefer trying to formalize code assumptions. Or just a "must be" :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27424#discussion_r2374519984 From jsikstro at openjdk.org Wed Sep 24 06:51:20 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 24 Sep 2025 06:51:20 GMT Subject: RFR: 8368251: Parallel: Refactor lgrp_id used in MutableNUMASpace [v2] In-Reply-To: References: <88Djo0LC5If0BwK55jK6e80Pr-k-HP7H0kRu__16Wfk=.500f12aa-4b38-40d8-88c8-7372004cdda5@github.com> <1c6u6m1uxYU8ImOy0WBWph0pzt-un3FHKuM5odBjLkE=.d0aa2ce1-ffa5-4358-bfd2-5f8ef411942a@github.com> Message-ID: On Wed, 24 Sep 2025 06:09:10 GMT, Thomas Schatzl wrote: >> src/hotspot/os/windows/os_windows.cpp line 543: >> >>> 541: } >>> 542: } >>> 543: >> >> I recommend asserting that `UseNUMA` is false here, with a message like `Should set NUMA id here` to not miss this later. >> I prefer trying to formalize code assumptions. > > Or just a "must be" :) I have added an assert in the only place we use it where it mustn't be -1. Do you think this is enough or should we also assert during thread creation, with a comment stating that there is thread state dependent on NUMA support, which we skip here. In the new `MutableNUMASpace::LGRPSpace *MutableNUMASpace::lgrp_space_for_thread(Thread* thr)`: assert(lgrp_id != -1, "lgrp_id must be set during thread creation"); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27424#discussion_r2374625802 From ayang at openjdk.org Wed Sep 24 08:47:58 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 24 Sep 2025 08:47:58 GMT Subject: RFR: 8368089: G1: G1PeriodicGCTask::should_start_periodic_gc may use uninitialised value if os::loadavg is unsupported [v4] In-Reply-To: References: <2OvCoQTGiaeASeEzeH7nPlNrqKuVBG4coqXf7FOqEc8=.1071778b-0427-4736-8d2c-4718b85081ca@github.com> Message-ID: <6TrkjRI3j-zyho55so9xdJlzRwfFDaduv1FbdjdkDWI=.43c59764-3b2d-4163-af53-c8a1418c817a@github.com> On Wed, 24 Sep 2025 01:17:19 GMT, Guanqiang Han wrote: >> Please review this change. Thanks! >> >> **Description:** >> >> Previously the check combined loadavg() failure and threshold comparison in a single condition. When os::loadavg() returned -1, `recent_load` contained an undefined value but was still logged as if it was a real load average, leading to misleading log output. >> >> **Fix:** >> >> This change separates the failure case from the combined check: >> - If os::loadavg() returns -1, log "System loadavg not supported" and skip. >> - Only compare `recent_load` to the threshold when loadavg() succeeds. >> >> **Test:** >> >> GHA > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > Update g1PeriodicGCTask.cpp > > fix a small error Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27413#pullrequestreview-3261822447 From tschatzl at openjdk.org Wed Sep 24 09:39:16 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 24 Sep 2025 09:39:16 GMT Subject: RFR: 8368251: Parallel: Refactor lgrp_id used in MutableNUMASpace [v2] In-Reply-To: <1c6u6m1uxYU8ImOy0WBWph0pzt-un3FHKuM5odBjLkE=.d0aa2ce1-ffa5-4358-bfd2-5f8ef411942a@github.com> References: <88Djo0LC5If0BwK55jK6e80Pr-k-HP7H0kRu__16Wfk=.500f12aa-4b38-40d8-88c8-7372004cdda5@github.com> <1c6u6m1uxYU8ImOy0WBWph0pzt-un3FHKuM5odBjLkE=.d0aa2ce1-ffa5-4358-bfd2-5f8ef411942a@github.com> Message-ID: On Tue, 23 Sep 2025 08:58:19 GMT, Joel Sikstr?m wrote: >> Hello, >> >> There are multiple cases which handle if the locality group (lgrp) id is negative (-1) in Parallel, specifically in MutableNUMASpace. -1 was historically used to indicate that the hardware topology has changed and that the lgrp id needs to be updated. This is no longer the case, since HotSpot doesn't support CPU/NUMA hotplugging, and the last piece of code setting the lgrp id to -1 was removed in [JDK-8301149](https://bugs.openjdk.org/browse/JDK-8301149). >> >> I propose we simplify the code a bit by not handling edge cases where the lgrp id is -1 and removing os::numa_has_group_homing(), which always return false >> >> Testing: >> * Running through Oracle's tier 1-4 >> * Local NUMA testing tier1-4 with `-XX:+UseParallelGC -XX:+UseNUMA` > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > Don't set lgrp_id on Windows since we don't support NUMA there Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27424#pullrequestreview-3262042243 From tschatzl at openjdk.org Wed Sep 24 09:39:18 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 24 Sep 2025 09:39:18 GMT Subject: RFR: 8368251: Parallel: Refactor lgrp_id used in MutableNUMASpace [v2] In-Reply-To: References: <88Djo0LC5If0BwK55jK6e80Pr-k-HP7H0kRu__16Wfk=.500f12aa-4b38-40d8-88c8-7372004cdda5@github.com> <1c6u6m1uxYU8ImOy0WBWph0pzt-un3FHKuM5odBjLkE=.d0aa2ce1-ffa5-4358-bfd2-5f8ef411942a@github.com> Message-ID: <0Z_UE2mTO6-x5L56Vci2zn--D5jM7SOkRxOKjeYmU7U=.93ecfb97-acce-4858-87fa-64cd555630d0@github.com> On Wed, 24 Sep 2025 06:48:28 GMT, Joel Sikstr?m wrote: >> Or just a "must be" :) > > I have added an assert in the only place we use it where it mustn't be -1. Do you think this is enough or should we also assert during thread creation, with a comment stating that there is thread state dependent on NUMA support, which we skip here. > > In the new `MutableNUMASpace::LGRPSpace *MutableNUMASpace::lgrp_space_for_thread(Thread* thr)`: > > assert(lgrp_id != -1, "lgrp_id must be set during thread creation"); I think that's good enough. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27424#discussion_r2375187853 From tschatzl at openjdk.org Wed Sep 24 14:04:22 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 24 Sep 2025 14:04:22 GMT Subject: RFR: 8368089: G1: G1PeriodicGCTask::should_start_periodic_gc may use uninitialised value if os::loadavg is unsupported [v4] In-Reply-To: References: <2OvCoQTGiaeASeEzeH7nPlNrqKuVBG4coqXf7FOqEc8=.1071778b-0427-4736-8d2c-4718b85081ca@github.com> Message-ID: On Wed, 24 Sep 2025 01:17:19 GMT, Guanqiang Han wrote: >> Please review this change. Thanks! >> >> **Description:** >> >> Previously the check combined loadavg() failure and threshold comparison in a single condition. When os::loadavg() returned -1, `recent_load` contained an undefined value but was still logged as if it was a real load average, leading to misleading log output. >> >> **Fix:** >> >> This change separates the failure case from the combined check: >> - If os::loadavg() returns -1, log "System loadavg not supported" and skip. >> - Only compare `recent_load` to the threshold when loadavg() succeeds. >> >> **Test:** >> >> GHA > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > Update g1PeriodicGCTask.cpp > > fix a small error Changes requested by tschatzl (Reviewer). src/hotspot/share/gc/g1/g1PeriodicGCTask.cpp line 67: > 65: recent_load, G1PeriodicGCSystemLoadThreshold); > 66: return false; > 67: } Suggestion: if (G1PeriodicGCSystemLoadThreshold > 0.0) { if (os::loadavg(&recent_load, 1) == -1) { G1PeriodicGCSystemLoadThreshold = 0.0; log_warning(gc, periodic)("System loadavg() call failed, disabling G1PeriodicGCSystemLoadThreshold check."); // Fall through and start the periodic GC. } else if (recent_load > G1PeriodicGCSystemLoadThreshold) { log_debug(gc, periodic)("Load %1.2f is higher than threshold %1.2f. Skipping.", recent_load, G1PeriodicGCSystemLoadThreshold); return false; } After detecting that `loadavg` is not supported, it would be preferable (more consistent) imo that the periodic gc would be started the first time too. Another option is to check `loadavg` support by a dummy call in argument processing, but here is good too. As for the other change, I would prefer to have the "disabling" in active voice, making it clear that this code disables the check. ------------- PR Review: https://git.openjdk.org/jdk/pull/27413#pullrequestreview-3263079661 PR Review Comment: https://git.openjdk.org/jdk/pull/27413#discussion_r2375909307 From ghan at openjdk.org Wed Sep 24 14:50:23 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Wed, 24 Sep 2025 14:50:23 GMT Subject: RFR: 8368089: G1: G1PeriodicGCTask::should_start_periodic_gc may use uninitialised value if os::loadavg is unsupported [v5] In-Reply-To: <2OvCoQTGiaeASeEzeH7nPlNrqKuVBG4coqXf7FOqEc8=.1071778b-0427-4736-8d2c-4718b85081ca@github.com> References: <2OvCoQTGiaeASeEzeH7nPlNrqKuVBG4coqXf7FOqEc8=.1071778b-0427-4736-8d2c-4718b85081ca@github.com> Message-ID: > Please review this change. Thanks! > > **Description:** > > Previously the check combined loadavg() failure and threshold comparison in a single condition. When os::loadavg() returned -1, `recent_load` contained an undefined value but was still logged as if it was a real load average, leading to misleading log output. > > **Fix:** > > This change separates the failure case from the combined check: > - If os::loadavg() returns -1, log "System loadavg not supported" and skip. > - Only compare `recent_load` to the threshold when loadavg() succeeds. > > **Test:** > > GHA Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: Update g1PeriodicGCTask.cpp The periodic gc would be started the first time after detecting that loadavg is not supported. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27413/files - new: https://git.openjdk.org/jdk/pull/27413/files/106362e9..9a3f6d42 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27413&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27413&range=03-04 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27413.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27413/head:pull/27413 PR: https://git.openjdk.org/jdk/pull/27413 From fandreuzzi at openjdk.org Wed Sep 24 14:52:23 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 24 Sep 2025 14:52:23 GMT Subject: RFR: 8368006: Parallel: Skip full regions in dense prefix during Full GC [v2] In-Reply-To: <0gXhjgdxG3MgUvM3qE-pYFlPrx64Tmwf4l2gzSJ617A=.b4572760-7b74-4dab-9c52-ae169c4504f2@github.com> References: <0gXhjgdxG3MgUvM3qE-pYFlPrx64Tmwf4l2gzSJ617A=.b4572760-7b74-4dab-9c52-ae169c4504f2@github.com> Message-ID: On Fri, 19 Sep 2025 15:09:25 GMT, Albert Mingkun Yang wrote: >> Implement skip-full-region optimization for filler related operations on dense-prefix. I constrained the filler-creation task to a single worker for simpler implementation. During the compaction phase, the most expensive part is almost always the non-dense-prefix part, so letting the rest of workers to start with the expensive tasks seems sensible. >> >> Synthetic bms shows good reduction in full-gc time in debug build; perf-neutral for other bms (specjvm2008,specjbb2015) in release build. >> >> Test: tier1-5 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - review > - Merge branch 'master' into pgc-skip-full-region > - pgc-skip-full-region Marked as reviewed by fandreuzzi (Author). src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1721: > 1719: for (HeapWord* cur_addr = start_addr; cur_addr < end_addr; /* empty */) { > 1720: RegionData* cur_region_ptr = _summary_data.addr_to_region_ptr(cur_addr); > 1721: if (cur_region_ptr->data_size() == region_size) { The next lines up to `cur_addr += cur_region_ptr->partial_obj_size()` could possibly be extracted to a common function? Then you could check again if `cur_region_ptr->data_size() == region_size` to decide if you should `continue`. ------------- PR Review: https://git.openjdk.org/jdk/pull/27369#pullrequestreview-3263306979 PR Review Comment: https://git.openjdk.org/jdk/pull/27369#discussion_r2376065971 From ghan at openjdk.org Wed Sep 24 14:58:06 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Wed, 24 Sep 2025 14:58:06 GMT Subject: RFR: 8368089: G1: G1PeriodicGCTask::should_start_periodic_gc may use uninitialised value if os::loadavg is unsupported [v4] In-Reply-To: References: <2OvCoQTGiaeASeEzeH7nPlNrqKuVBG4coqXf7FOqEc8=.1071778b-0427-4736-8d2c-4718b85081ca@github.com> Message-ID: On Wed, 24 Sep 2025 14:00:28 GMT, Thomas Schatzl wrote: >> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: >> >> Update g1PeriodicGCTask.cpp >> >> fix a small error > > src/hotspot/share/gc/g1/g1PeriodicGCTask.cpp line 67: > >> 65: recent_load, G1PeriodicGCSystemLoadThreshold); >> 66: return false; >> 67: } > > Suggestion: > > if (G1PeriodicGCSystemLoadThreshold > 0.0) { > if (os::loadavg(&recent_load, 1) == -1) { > G1PeriodicGCSystemLoadThreshold = 0.0; > log_warning(gc, periodic)("System loadavg() call failed, disabling G1PeriodicGCSystemLoadThreshold check."); > // Fall through and start the periodic GC. > } else if (recent_load > G1PeriodicGCSystemLoadThreshold) { > log_debug(gc, periodic)("Load %1.2f is higher than threshold %1.2f. Skipping.", > recent_load, G1PeriodicGCSystemLoadThreshold); > return false; > } > > > After detecting that `loadavg` is not supported, it would be preferable (more consistent) imo that the periodic gc would be started the first time too. > Another option is to check `loadavg` support by a dummy call in argument processing, but here is good too. > > As for the other change, I would prefer to have the "disabling" in active voice, making it clear that this code disables the check. @tschatzl Indeed, that?s more consistent. Thank you ? fixed now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27413#discussion_r2376085019 From ayang at openjdk.org Wed Sep 24 15:03:07 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 24 Sep 2025 15:03:07 GMT Subject: RFR: 8368006: Parallel: Skip full regions in dense prefix during Full GC [v2] In-Reply-To: References: <0gXhjgdxG3MgUvM3qE-pYFlPrx64Tmwf4l2gzSJ617A=.b4572760-7b74-4dab-9c52-ae169c4504f2@github.com> Message-ID: <265W_7D188gczMjpmgeDrimLujWVtEhUQrbX2tLFVzo=.f844de1b-bfa9-4266-ad26-7c946279a073@github.com> On Wed, 24 Sep 2025 14:49:00 GMT, Francesco Andreuzzi wrote: >> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - review >> - Merge branch 'master' into pgc-skip-full-region >> - pgc-skip-full-region > > src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1721: > >> 1719: for (HeapWord* cur_addr = start_addr; cur_addr < end_addr; /* empty */) { >> 1720: RegionData* cur_region_ptr = _summary_data.addr_to_region_ptr(cur_addr); >> 1721: if (cur_region_ptr->data_size() == region_size) { > > The next lines up to `cur_addr += cur_region_ptr->partial_obj_size()` could possibly be extracted to a common function? Then you could check again if `cur_region_ptr->data_size() == region_size` to decide if you should `continue`. Can you provide a snippet? I don't get what you are suggesting. Just fyi, `cur_addr += cur_region_ptr->partial_obj_size()` is needed to make sure `cur_addr` is live-obj-end. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27369#discussion_r2376098764 From iwalulya at openjdk.org Wed Sep 24 16:23:51 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 24 Sep 2025 16:23:51 GMT Subject: RFR: 8368089: G1: G1PeriodicGCTask::should_start_periodic_gc may use uninitialised value if os::loadavg is unsupported [v5] In-Reply-To: References: <2OvCoQTGiaeASeEzeH7nPlNrqKuVBG4coqXf7FOqEc8=.1071778b-0427-4736-8d2c-4718b85081ca@github.com> Message-ID: On Wed, 24 Sep 2025 14:50:23 GMT, Guanqiang Han wrote: >> Please review this change. Thanks! >> >> **Description:** >> >> Previously the check combined loadavg() failure and threshold comparison in a single condition. When os::loadavg() returned -1, `recent_load` contained an undefined value but was still logged as if it was a real load average, leading to misleading log output. >> >> **Fix:** >> >> This change separates the failure case from the combined check: >> - If os::loadavg() returns -1, log "System loadavg not supported" and skip. >> - Only compare `recent_load` to the threshold when loadavg() succeeds. >> >> **Test:** >> >> GHA > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > Update g1PeriodicGCTask.cpp > > The periodic gc would be started the first time after detecting that loadavg is not supported. Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27413#pullrequestreview-3263700803 From fandreuzzi at openjdk.org Wed Sep 24 21:00:29 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 24 Sep 2025 21:00:29 GMT Subject: RFR: 8368006: Parallel: Skip full regions in dense prefix during Full GC [v2] In-Reply-To: <265W_7D188gczMjpmgeDrimLujWVtEhUQrbX2tLFVzo=.f844de1b-bfa9-4266-ad26-7c946279a073@github.com> References: <0gXhjgdxG3MgUvM3qE-pYFlPrx64Tmwf4l2gzSJ617A=.b4572760-7b74-4dab-9c52-ae169c4504f2@github.com> <265W_7D188gczMjpmgeDrimLujWVtEhUQrbX2tLFVzo=.f844de1b-bfa9-4266-ad26-7c946279a073@github.com> Message-ID: On Wed, 24 Sep 2025 15:00:17 GMT, Albert Mingkun Yang wrote: >> src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1721: >> >>> 1719: for (HeapWord* cur_addr = start_addr; cur_addr < end_addr; /* empty */) { >>> 1720: RegionData* cur_region_ptr = _summary_data.addr_to_region_ptr(cur_addr); >>> 1721: if (cur_region_ptr->data_size() == region_size) { >> >> The next lines up to `cur_addr += cur_region_ptr->partial_obj_size()` could possibly be extracted to a common function? Then you could check again if `cur_region_ptr->data_size() == region_size` to decide if you should `continue`. > > Can you provide a snippet? I don't get what you are suggesting. Just fyi, `cur_addr += cur_region_ptr->partial_obj_size()` is needed to make sure `cur_addr` is live-obj-end. This snippet: https://github.com/openjdk/jdk/blob/20937445c8a56f905df542ebe159d53494b66670/src/hotspot/share/gc/parallel/psParallelCompact.cpp#L1720-L1737 and this: https://github.com/openjdk/jdk/blob/20937445c8a56f905df542ebe159d53494b66670/src/hotspot/share/gc/parallel/psParallelCompact.cpp#L1788-L1805 are almost identical, am I missing something? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27369#discussion_r2377064052 From kdnilsen at openjdk.org Wed Sep 24 21:40:17 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 24 Sep 2025 21:40:17 GMT Subject: RFR: 8368307: Shenandoah: get_next_bit_impl should special case weak and strong mark bits Message-ID: Check for weak bit or strong bit when giving special handling to the next bit found in first position of word. ------------- Commit messages: - check for weak bit or strong bit in first bit position Changes: https://git.openjdk.org/jdk/pull/27476/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27476&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368307 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27476.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27476/head:pull/27476 PR: https://git.openjdk.org/jdk/pull/27476 From wkemper at openjdk.org Wed Sep 24 21:56:47 2025 From: wkemper at openjdk.org (William Kemper) Date: Wed, 24 Sep 2025 21:56:47 GMT Subject: RFR: 8368015: Shenandoah: fix error in computation of average allocation rate [v2] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 15:36:42 GMT, Kelvin Nilsen wrote: >> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 364: >> >>> 362: >>> 363: double ShenandoahAllocationRate::force_sample(size_t allocated, size_t &unaccounted_bytes_allocated) { >>> 364: const double MinSampleTime = 0.002; // Do not sample if time since last update is less than 2 ms >> >> Would it make sense to "carry over" the `unaccounted_bytes_allocated` if, at the time of reset, the last sample was taken less than `ShenandoahAllocationRate::_interval_sec` (instead of `MinSampleTime`)? I believe this would result in more samples being carried over. > > I've done experiments with a variety of different values for MinSampleTime (e.g. 50 ms, 25ms, 2 ms). I find that any value > greater than 1 ms works pretty well in the sense that the measured rate is pretty consistent with the average rate as computed > by the preexisting mechanisms. > > The biggest problem I observed was when we tried to measure rate over an interval of a few microseconds, and these intervals > sometimes had zero allocations. > > We could make the change you suggest, but that would actually result in fewer samples rather than more. It would also make > the value of bytes_allocated_since_gc_start() less precise in that this quantity would carry up to 100 ms of allocations that > actually occurred before the start of the current GC. > > Here's an ASCII art attempt to illustrate how it works in the current implementation. > > Here is a timeline with a tick mark to illustrate the desired sample time, every 100 ms: > > > .1s .2s .3s .4s. .5s .6s .7s .8s. .9s 1s 1.1s 1.2s > |---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|--- > ^ ^ > Existing | | > Samples: A B C D E > | | > Proposed | | > Samples: A | B C D > | | > | | > Trigger GC at 0.14s Finish GC at 1.03s > > In either approach, we sample at 0.1s and this sample contributes to the average allocation rate that causes us to trigger at > time 0.14s. In the current implementation, at time 0.14s, we take a new sample representing the most current allocation rate > as computed over the span between 0.1s and 0.14s. As implemented, if this time delta (0.14s minus 0.10s =0... With the change in the PR, I was thinking of "skipped" samples as being "carried over" to the next cycle (per `unaccounted_bytes_allocated = allocated - _last_sample_value;`). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27398#discussion_r2377167640 From wkemper at openjdk.org Wed Sep 24 22:14:13 2025 From: wkemper at openjdk.org (William Kemper) Date: Wed, 24 Sep 2025 22:14:13 GMT Subject: RFR: 8368015: Shenandoah: fix error in computation of average allocation rate [v5] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 22:56:01 GMT, Kelvin Nilsen wrote: >> We use bytes_allocated_since_gc_start() to compute allocation rates. This leaves a blind spot, as our current implementation ignores allocations and the time period between the moment we begin GC and the first time we update the allocation rate following the start of GC. When this happens, we typically find that the sampled number of allocations is smaller than the allocations that had accumulated by the time we triggered the start of the current GC cycle. >> >> This PR adds tracking for that accounting gap. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > More override declarations to satisfy certain compilers Thank you for the changes. ------------- Marked as reviewed by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27398#pullrequestreview-3264893414 From fandreuzzi at openjdk.org Wed Sep 24 22:46:30 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 24 Sep 2025 22:46:30 GMT Subject: RFR: 8368599: ShenandoahConcurrentMark could use ThreadsClaimTokenScope Message-ID: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `ShenandoahConcurrentMark::finish_mark_work` to be more precise with what is actually needed and why. Similar to #27385. Test: tier1, and tier[1,2,3]_gc_shenandoah ------------- Commit messages: - replace Changes: https://git.openjdk.org/jdk/pull/27477/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27477&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368599 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27477.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27477/head:pull/27477 PR: https://git.openjdk.org/jdk/pull/27477 From kdnilsen at openjdk.org Wed Sep 24 22:51:49 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 24 Sep 2025 22:51:49 GMT Subject: Integrated: 8368015: Shenandoah: fix error in computation of average allocation rate In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 20:36:51 GMT, Kelvin Nilsen wrote: > We use bytes_allocated_since_gc_start() to compute allocation rates. This leaves a blind spot, as our current implementation ignores allocations and the time period between the moment we begin GC and the first time we update the allocation rate following the start of GC. When this happens, we typically find that the sampled number of allocations is smaller than the allocations that had accumulated by the time we triggered the start of the current GC cycle. > > This PR adds tracking for that accounting gap. This pull request has now been integrated. Changeset: a2870d6b Author: Kelvin Nilsen URL: https://git.openjdk.org/jdk/commit/a2870d6b4985a68beb3fe3bf6622e6245e9a82ec Stats: 80 lines in 7 files changed: 56 ins; 6 del; 18 mod 8368015: Shenandoah: fix error in computation of average allocation rate Reviewed-by: wkemper ------------- PR: https://git.openjdk.org/jdk/pull/27398 From wkemper at openjdk.org Wed Sep 24 23:01:11 2025 From: wkemper at openjdk.org (William Kemper) Date: Wed, 24 Sep 2025 23:01:11 GMT Subject: RFR: 8368499: GenShen: Do not collect age census during evac when adaptive tenuring is disabled Message-ID: This is a simplification to `ShenandoahEvacTracker` (which is a diagnostic feature). The ability to compute the age census during evacuation was still in the code, even though the (experimental) option to enable it was removed. Removing the rest of the code allows us to take an additional flag-check off the evacuation path and to consolidate duplicated gc stat processing code between `shControlThread` and `shGenerationalControlThread`. ------------- Commit messages: - Decouple age table printing from evac tracking, consolidate duplicated code - Do not compute age census during evac when adaptive tenuring is disabled Changes: https://git.openjdk.org/jdk/pull/27479/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27479&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368499 Stats: 250 lines in 11 files changed: 55 ins; 137 del; 58 mod Patch: https://git.openjdk.org/jdk/pull/27479.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27479/head:pull/27479 PR: https://git.openjdk.org/jdk/pull/27479 From ysr at openjdk.org Wed Sep 24 23:03:23 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Wed, 24 Sep 2025 23:03:23 GMT Subject: RFR: 8368015: Shenandoah: fix error in computation of average allocation rate [v5] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 22:56:01 GMT, Kelvin Nilsen wrote: >> We use bytes_allocated_since_gc_start() to compute allocation rates. This leaves a blind spot, as our current implementation ignores allocations and the time period between the moment we begin GC and the first time we update the allocation rate following the start of GC. When this happens, we typically find that the sampled number of allocations is smaller than the allocations that had accumulated by the time we triggered the start of the current GC cycle. >> >> This PR adds tracking for that accounting gap. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > More override declarations to satisfy certain compilers The changes look mostly correct (there's the small issue of ascribing time and allocation precisely to the right interval which might be unavoidable), but I feel this code can be refactored to make it slightly less clunky. However, probably best to leave that for a follow up. I left a few suggestions for documentation. src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp line 40: > 38: void allocation_counter_reset(); > 39: > 40: double force_sample(size_t allocated, size_t &unaccounted_bytes_allocated); Document these two APIs: force_sample() and sample(). A small block documentation comment on ShenandoahAllocationRate() is also a good idea. src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.hpp line 244: > 242: double elapsed_cycle_time() const; > 243: > 244: virtual size_t force_alloc_rate_sample(size_t bytes_allocated) { I realize none of these public API's have any documentation of intent, but might be a good idea to start doing that with this new API you are adding here. src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2329: > 2327: // unaccounted_bytes is the bytes not accounted for by our forced sample. If the sample interval is too short, > 2328: // the "forced sample" will not happen, and any recently allocated bytes are "unaccounted for". We pretend these > 2329: // bytes are allocated after the start of subsequent gc. I think these comments should be made slightly more abstract and moved to the spec of `reset` and of the `force` methods. These almost feel like a bit of the specifics of the sampling and the "residue" computation leaking through into objects that it shouldn't leak into. So a bit of thought on how to organize this best by pushing everything to one place would work better from the standpoint of code maintainability and robustness. As I understand the issue is that we use two separate APIs with no locking to read the allocated bytes and to reset these bytes, all while these are being concurrently incremented. So you want to have the reset method detect the residue allocation between the two points, and ascribe it to the rate computation to be used in the next sample. I feel there may be a simpler way to do this by pushing all of these mechanics & details down into the sampling method which has direct access to the counter that it can manipulate for computing rates and upon request for resetting. ------------- Marked as reviewed by ysr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27398#pullrequestreview-3264863343 PR Review Comment: https://git.openjdk.org/jdk/pull/27398#discussion_r2377176198 PR Review Comment: https://git.openjdk.org/jdk/pull/27398#discussion_r2377172069 PR Review Comment: https://git.openjdk.org/jdk/pull/27398#discussion_r2377256204 From kdnilsen at openjdk.org Wed Sep 24 23:08:07 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 24 Sep 2025 23:08:07 GMT Subject: RFR: 8368499: GenShen: Do not collect age census during evac when adaptive tenuring is disabled In-Reply-To: References: Message-ID: <2tVaJ3hKQ2TQCCLkr0BPsg_4Vkaln2tJsFkqoVl_bGI=.b0792d10-377c-4ac8-970b-1a6f6eba4588@github.com> On Wed, 24 Sep 2025 22:53:28 GMT, William Kemper wrote: > This is a simplification to `ShenandoahEvacTracker` (which is a diagnostic feature). The ability to compute the age census during evacuation was still in the code, even though the (experimental) option to enable it was removed. Removing the rest of the code allows us to take an additional flag-check off the evacuation path and to consolidate duplicated gc stat processing code between `shControlThread` and `shGenerationalControlThread`. Thanks for these improvements. ------------- Marked as reviewed by kdnilsen (Committer). PR Review: https://git.openjdk.org/jdk/pull/27479#pullrequestreview-3264977489 From wkemper at openjdk.org Wed Sep 24 23:10:22 2025 From: wkemper at openjdk.org (William Kemper) Date: Wed, 24 Sep 2025 23:10:22 GMT Subject: RFR: 8368015: Shenandoah: fix error in computation of average allocation rate [v5] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 22:58:28 GMT, Y. Srinivas Ramakrishna wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> More override declarations to satisfy certain compilers > > src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2329: > >> 2327: // unaccounted_bytes is the bytes not accounted for by our forced sample. If the sample interval is too short, >> 2328: // the "forced sample" will not happen, and any recently allocated bytes are "unaccounted for". We pretend these >> 2329: // bytes are allocated after the start of subsequent gc. > > I think these comments should be made slightly more abstract and moved to the spec of `reset` and of the `force` methods. These almost feel like a bit of the specifics of the sampling and the "residue" computation leaking through into objects that it shouldn't leak into. So a bit of thought on how to organize this best by pushing everything to one place would work better from the standpoint of code maintainability and robustness. > > As I understand the issue is that we use two separate APIs with no locking to read the allocated bytes and to reset these bytes, all while these are being concurrently incremented. So you want to have the reset method detect the residue allocation between the two points, and ascribe it to the rate computation to be used in the next sample. I feel there may be a simpler way to do this by pushing all of these mechanics & details down into the sampling method which has direct access to the counter that it can manipulate for computing rates and upon request for resetting. I agree. What we're really try to track is the mutator's allocation rate. There's no particular reason it needs to be implemented in terms of bytes allocated _since gc start_. Of course, we must reset (or at least, reduce) the value periodically to avoid rollover, but again, we don't need to do that only when we start a gc. As @kdnilsen noted, having the control thread take the samples also means we don't collect samples during the GC cycle. We should consider having mutators (or some other thread) collect the samples and manage the allocation counter. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27398#discussion_r2377265215 From kdnilsen at openjdk.org Wed Sep 24 23:10:22 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 24 Sep 2025 23:10:22 GMT Subject: RFR: 8368015: Shenandoah: fix error in computation of average allocation rate [v5] In-Reply-To: References: Message-ID: <3QX83tSpGiYad43aMwfXO8Bf3LVEtjTaRsOII8H9FAc=.204eedd4-c5d1-49c3-95d8-15586f247ae3@github.com> On Wed, 24 Sep 2025 23:07:40 GMT, William Kemper wrote: >> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2329: >> >>> 2327: // unaccounted_bytes is the bytes not accounted for by our forced sample. If the sample interval is too short, >>> 2328: // the "forced sample" will not happen, and any recently allocated bytes are "unaccounted for". We pretend these >>> 2329: // bytes are allocated after the start of subsequent gc. >> >> I think these comments should be made slightly more abstract and moved to the spec of `reset` and of the `force` methods. These almost feel like a bit of the specifics of the sampling and the "residue" computation leaking through into objects that it shouldn't leak into. So a bit of thought on how to organize this best by pushing everything to one place would work better from the standpoint of code maintainability and robustness. >> >> As I understand the issue is that we use two separate APIs with no locking to read the allocated bytes and to reset these bytes, all while these are being concurrently incremented. So you want to have the reset method detect the residue allocation between the two points, and ascribe it to the rate computation to be used in the next sample. I feel there may be a simpler way to do this by pushing all of these mechanics & details down into the sampling method which has direct access to the counter that it can manipulate for computing rates and upon request for resetting. > > I agree. What we're really try to track is the mutator's allocation rate. There's no particular reason it needs to be implemented in terms of bytes allocated _since gc start_. Of course, we must reset (or at least, reduce) the value periodically to avoid rollover, but again, we don't need to do that only when we start a gc. As @kdnilsen noted, having the control thread take the samples also means we don't collect samples during the GC cycle. We should consider having mutators (or some other thread) collect the samples and manage the allocation counter. Thanks for review. I'll update docs in a separate PR (since I integrated already). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27398#discussion_r2377265803 From ysr at openjdk.org Wed Sep 24 23:39:08 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Wed, 24 Sep 2025 23:39:08 GMT Subject: RFR: 8368499: GenShen: Do not collect age census during evac when adaptive tenuring is disabled In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 22:53:28 GMT, William Kemper wrote: > This is a simplification to `ShenandoahEvacTracker` (which is a diagnostic feature). The ability to compute the age census during evacuation was still in the code, even though the (experimental) option to enable it was removed. Removing the rest of the code allows us to take an additional flag-check off the evacuation path and to consolidate duplicated gc stat processing code between `shControlThread` and `shGenerationalControlThread`. LGTM; thanks for the clean up! ------------- Marked as reviewed by ysr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27479#pullrequestreview-3265015095 From wkemper at openjdk.org Wed Sep 24 23:58:53 2025 From: wkemper at openjdk.org (William Kemper) Date: Wed, 24 Sep 2025 23:58:53 GMT Subject: RFR: 8368599: ShenandoahConcurrentMark could use ThreadsClaimTokenScope In-Reply-To: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com> References: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com> Message-ID: <4MAbJyfv4_vkF9E9f2GO9dXfaxEB5HjY22DLDowNiu4=.880d1627-d0b8-4686-bce1-bc07b8a1d694@github.com> On Wed, 24 Sep 2025 22:37:44 GMT, Francesco Andreuzzi wrote: > Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `ShenandoahConcurrentMark::finish_mark_work` to be more precise with what is actually needed and why. Similar to #27385. > > Test: tier1, and tier[1,2,3]_gc_shenandoah LGTM! Thank you. ------------- Marked as reviewed by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27477#pullrequestreview-3265051449 From jsikstro at openjdk.org Thu Sep 25 07:01:41 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Thu, 25 Sep 2025 07:01:41 GMT Subject: RFR: 8368251: Parallel: Refactor lgrp_id used in MutableNUMASpace [v3] In-Reply-To: <88Djo0LC5If0BwK55jK6e80Pr-k-HP7H0kRu__16Wfk=.500f12aa-4b38-40d8-88c8-7372004cdda5@github.com> References: <88Djo0LC5If0BwK55jK6e80Pr-k-HP7H0kRu__16Wfk=.500f12aa-4b38-40d8-88c8-7372004cdda5@github.com> Message-ID: > Hello, > > There are multiple cases which handle if the locality group (lgrp) id is negative (-1) in Parallel, specifically in MutableNUMASpace. -1 was historically used to indicate that the hardware topology has changed and that the lgrp id needs to be updated. This is no longer the case, since HotSpot doesn't support CPU/NUMA hotplugging, and the last piece of code setting the lgrp id to -1 was removed in [JDK-8301149](https://bugs.openjdk.org/browse/JDK-8301149). > > I propose we simplify the code a bit by not handling edge cases where the lgrp id is -1 and removing os::numa_has_group_homing(), which always return false > > Testing: > * Running through Oracle's tier 1-4 > * Local NUMA testing tier1-4 with `-XX:+UseParallelGC -XX:+UseNUMA` Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' into JDK-8368251_parallel_lgrpid - Copyright years - Don't set lgrp_id on Windows since we don't support NUMA there - 8368251: Parallel: Refactor lgrp_id used in MutableNUMASpace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27424/files - new: https://git.openjdk.org/jdk/pull/27424/files/d8dcd72a..68e3a891 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27424&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27424&range=01-02 Stats: 157580 lines in 1696 files changed: 130024 ins; 16965 del; 10591 mod Patch: https://git.openjdk.org/jdk/pull/27424.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27424/head:pull/27424 PR: https://git.openjdk.org/jdk/pull/27424 From lkorinth at openjdk.org Thu Sep 25 08:04:10 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 25 Sep 2025 08:04:10 GMT Subject: RFR: 8368251: Parallel: Refactor lgrp_id used in MutableNUMASpace [v3] In-Reply-To: References: <88Djo0LC5If0BwK55jK6e80Pr-k-HP7H0kRu__16Wfk=.500f12aa-4b38-40d8-88c8-7372004cdda5@github.com> Message-ID: On Thu, 25 Sep 2025 07:01:41 GMT, Joel Sikstr?m wrote: >> Hello, >> >> There are multiple cases which handle if the locality group (lgrp) id is negative (-1) in Parallel, specifically in MutableNUMASpace. -1 was historically used to indicate that the hardware topology has changed and that the lgrp id needs to be updated. This is no longer the case, since HotSpot doesn't support CPU/NUMA hotplugging, and the last piece of code setting the lgrp id to -1 was removed in [JDK-8301149](https://bugs.openjdk.org/browse/JDK-8301149). >> >> I propose we simplify the code a bit by not handling edge cases where the lgrp id is -1 and removing os::numa_has_group_homing(), which always return false >> >> Testing: >> * Running through Oracle's tier 1-4 >> * Local NUMA testing tier1-4 with `-XX:+UseParallelGC -XX:+UseNUMA` > > Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into JDK-8368251_parallel_lgrpid > - Copyright years > - Don't set lgrp_id on Windows since we don't support NUMA there > - 8368251: Parallel: Refactor lgrp_id used in MutableNUMASpace Marked as reviewed by lkorinth (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27424#pullrequestreview-3266324726 From tschatzl at openjdk.org Thu Sep 25 08:42:48 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 25 Sep 2025 08:42:48 GMT Subject: RFR: 8368089: G1: G1PeriodicGCTask::should_start_periodic_gc may use uninitialised value if os::loadavg is unsupported [v5] In-Reply-To: References: <2OvCoQTGiaeASeEzeH7nPlNrqKuVBG4coqXf7FOqEc8=.1071778b-0427-4736-8d2c-4718b85081ca@github.com> Message-ID: On Wed, 24 Sep 2025 14:50:23 GMT, Guanqiang Han wrote: >> Please review this change. Thanks! >> >> **Description:** >> >> Previously the check combined loadavg() failure and threshold comparison in a single condition. When os::loadavg() returned -1, `recent_load` contained an undefined value but was still logged as if it was a real load average, leading to misleading log output. >> >> **Fix:** >> >> This change separates the failure case from the combined check: >> - If os::loadavg() returns -1, log "System loadavg not supported" and skip. >> - Only compare `recent_load` to the threshold when loadavg() succeeds. >> >> **Test:** >> >> GHA > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > Update g1PeriodicGCTask.cpp > > The periodic gc would be started the first time after detecting that loadavg is not supported. Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27413#pullrequestreview-3266502208 From jsikstro at openjdk.org Thu Sep 25 09:42:03 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Thu, 25 Sep 2025 09:42:03 GMT Subject: RFR: 8368251: Parallel: Refactor lgrp_id used in MutableNUMASpace [v3] In-Reply-To: References: <88Djo0LC5If0BwK55jK6e80Pr-k-HP7H0kRu__16Wfk=.500f12aa-4b38-40d8-88c8-7372004cdda5@github.com> Message-ID: <1ARn0cK4j0IuKsff-MJd6e66k-EqoBA-5IEmbsT0fRA=.b62ae51b-70c7-4f8c-ab52-4dcbf43dc65b@github.com> On Mon, 22 Sep 2025 12:26:01 GMT, Albert Mingkun Yang wrote: >> Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8368251_parallel_lgrpid >> - Copyright years >> - Don't set lgrp_id on Windows since we don't support NUMA there >> - 8368251: Parallel: Refactor lgrp_id used in MutableNUMASpace > > Marked as reviewed by ayang (Reviewer). Thank you for the reviews! @albertnetymk @lkorinth @tschatzl ------------- PR Comment: https://git.openjdk.org/jdk/pull/27424#issuecomment-3333114072 From jsikstro at openjdk.org Thu Sep 25 09:42:04 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Thu, 25 Sep 2025 09:42:04 GMT Subject: Integrated: 8368251: Parallel: Refactor lgrp_id used in MutableNUMASpace In-Reply-To: <88Djo0LC5If0BwK55jK6e80Pr-k-HP7H0kRu__16Wfk=.500f12aa-4b38-40d8-88c8-7372004cdda5@github.com> References: <88Djo0LC5If0BwK55jK6e80Pr-k-HP7H0kRu__16Wfk=.500f12aa-4b38-40d8-88c8-7372004cdda5@github.com> Message-ID: On Mon, 22 Sep 2025 11:42:39 GMT, Joel Sikstr?m wrote: > Hello, > > There are multiple cases which handle if the locality group (lgrp) id is negative (-1) in Parallel, specifically in MutableNUMASpace. -1 was historically used to indicate that the hardware topology has changed and that the lgrp id needs to be updated. This is no longer the case, since HotSpot doesn't support CPU/NUMA hotplugging, and the last piece of code setting the lgrp id to -1 was removed in [JDK-8301149](https://bugs.openjdk.org/browse/JDK-8301149). > > I propose we simplify the code a bit by not handling edge cases where the lgrp id is -1 and removing os::numa_has_group_homing(), which always return false > > Testing: > * Running through Oracle's tier 1-4 > * Local NUMA testing tier1-4 with `-XX:+UseParallelGC -XX:+UseNUMA` This pull request has now been integrated. Changeset: d407ef65 Author: Joel Sikstr?m URL: https://git.openjdk.org/jdk/commit/d407ef651032de687e3d4a2a2db211cab1016676 Stats: 125 lines in 10 files changed: 9 ins; 96 del; 20 mod 8368251: Parallel: Refactor lgrp_id used in MutableNUMASpace Reviewed-by: lkorinth, ayang, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/27424 From ghan at openjdk.org Thu Sep 25 09:44:03 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 25 Sep 2025 09:44:03 GMT Subject: RFR: 8368089: G1: G1PeriodicGCTask::should_start_periodic_gc may use uninitialised value if os::loadavg is unsupported [v4] In-Reply-To: <6TrkjRI3j-zyho55so9xdJlzRwfFDaduv1FbdjdkDWI=.43c59764-3b2d-4163-af53-c8a1418c817a@github.com> References: <2OvCoQTGiaeASeEzeH7nPlNrqKuVBG4coqXf7FOqEc8=.1071778b-0427-4736-8d2c-4718b85081ca@github.com> <6TrkjRI3j-zyho55so9xdJlzRwfFDaduv1FbdjdkDWI=.43c59764-3b2d-4163-af53-c8a1418c817a@github.com> Message-ID: On Wed, 24 Sep 2025 08:45:29 GMT, Albert Mingkun Yang wrote: >> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: >> >> Update g1PeriodicGCTask.cpp >> >> fix a small error > > Marked as reviewed by ayang (Reviewer). Hi @albertnetymk, I made a small change. Do you have any further suggestions? If not, I?ll integrate it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27413#issuecomment-3333133864 From ayang at openjdk.org Thu Sep 25 10:39:54 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 25 Sep 2025 10:39:54 GMT Subject: RFR: 8368089: G1: G1PeriodicGCTask::should_start_periodic_gc may use uninitialised value if os::loadavg is unsupported [v5] In-Reply-To: References: <2OvCoQTGiaeASeEzeH7nPlNrqKuVBG4coqXf7FOqEc8=.1071778b-0427-4736-8d2c-4718b85081ca@github.com> Message-ID: On Wed, 24 Sep 2025 14:50:23 GMT, Guanqiang Han wrote: >> Please review this change. Thanks! >> >> **Description:** >> >> Previously the check combined loadavg() failure and threshold comparison in a single condition. When os::loadavg() returned -1, `recent_load` contained an undefined value but was still logged as if it was a real load average, leading to misleading log output. >> >> **Fix:** >> >> This change separates the failure case from the combined check: >> - If os::loadavg() returns -1, log "System loadavg not supported" and skip. >> - Only compare `recent_load` to the threshold when loadavg() succeeds. >> >> **Test:** >> >> GHA > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > Update g1PeriodicGCTask.cpp > > The periodic gc would be started the first time after detecting that loadavg is not supported. Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27413#pullrequestreview-3267002864 From ayang at openjdk.org Thu Sep 25 10:42:01 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 25 Sep 2025 10:42:01 GMT Subject: RFR: 8368599: ShenandoahConcurrentMark could use ThreadsClaimTokenScope In-Reply-To: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com> References: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com> Message-ID: <4xXAiT5xKFTZOb_8v4f9vRVVk2UVS-4Cq1E66fwNqbA=.9a8b2f43-bd19-4797-841c-5c4a54481a6a@github.com> On Wed, 24 Sep 2025 22:37:44 GMT, Francesco Andreuzzi wrote: > Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `ShenandoahConcurrentMark::finish_mark_work` to be more precise with what is actually needed and why. Similar to #27385. > > Test: tier1, and tier[1,2,3]_gc_shenandoah I wonder if it can be inlined to `ShenandoahFinalMarkingTask` as a field, but up to you. ------------- Marked as reviewed by ayang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27477#pullrequestreview-3267008172 From ayang at openjdk.org Thu Sep 25 10:48:07 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 25 Sep 2025 10:48:07 GMT Subject: RFR: 8368006: Parallel: Skip full regions in dense prefix during Full GC [v2] In-Reply-To: References: <0gXhjgdxG3MgUvM3qE-pYFlPrx64Tmwf4l2gzSJ617A=.b4572760-7b74-4dab-9c52-ae169c4504f2@github.com> <265W_7D188gczMjpmgeDrimLujWVtEhUQrbX2tLFVzo=.f844de1b-bfa9-4266-ad26-7c946279a073@github.com> Message-ID: On Wed, 24 Sep 2025 20:57:43 GMT, Francesco Andreuzzi wrote: >> Can you provide a snippet? I don't get what you are suggesting. Just fyi, `cur_addr += cur_region_ptr->partial_obj_size()` is needed to make sure `cur_addr` is live-obj-end. > > This snippet: > https://github.com/openjdk/jdk/blob/20937445c8a56f905df542ebe159d53494b66670/src/hotspot/share/gc/parallel/psParallelCompact.cpp#L1720-L1737 > > and this: > https://github.com/openjdk/jdk/blob/20937445c8a56f905df542ebe159d53494b66670/src/hotspot/share/gc/parallel/psParallelCompact.cpp#L1788-L1805 > > are almost identical, am I missing something? I see; yes, they are (almost) identical. However, there is a `continue` in the middle, which makes it hard to extract them out to be a function and these operations are quite caller specific, so forcing them into a function can hinder the readability, IMO, i.e. requiring readers to read into the implementation to understand the flow. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27369#discussion_r2378639901 From fandreuzzi at openjdk.org Thu Sep 25 11:00:18 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 25 Sep 2025 11:00:18 GMT Subject: RFR: 8368599: ShenandoahConcurrentMark could use ThreadsClaimTokenScope [v2] In-Reply-To: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com> References: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com> Message-ID: > Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `ShenandoahConcurrentMark::finish_mark_work` to be more precise with what is actually needed and why. Similar to #27385. > > Test: tier1, and tier[1,2,3]_gc_shenandoah Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: as field ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27477/files - new: https://git.openjdk.org/jdk/pull/27477/files/44377b16..b1686c28 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27477&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27477&range=00-01 Stats: 4 lines in 1 file changed: 2 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27477.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27477/head:pull/27477 PR: https://git.openjdk.org/jdk/pull/27477 From fandreuzzi at openjdk.org Thu Sep 25 11:00:19 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 25 Sep 2025 11:00:19 GMT Subject: RFR: 8368599: ShenandoahConcurrentMark could use ThreadsClaimTokenScope [v2] In-Reply-To: <4xXAiT5xKFTZOb_8v4f9vRVVk2UVS-4Cq1E66fwNqbA=.9a8b2f43-bd19-4797-841c-5c4a54481a6a@github.com> References: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com> <4xXAiT5xKFTZOb_8v4f9vRVVk2UVS-4Cq1E66fwNqbA=.9a8b2f43-bd19-4797-841c-5c4a54481a6a@github.com> Message-ID: On Thu, 25 Sep 2025 10:39:12 GMT, Albert Mingkun Yang wrote: > I wonder if it can be inlined to `ShenandoahFinalMarkingTask` as a field, but up to you. Good point, it looks better this way: b1686c28687a97ef3bc0764740c33a6dd89c0c2e I re-run tier[1,2,3]_gc_shenandoah. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27477#issuecomment-3333396462 From duke at openjdk.org Thu Sep 25 11:19:26 2025 From: duke at openjdk.org (duke) Date: Thu, 25 Sep 2025 11:19:26 GMT Subject: RFR: 8368089: G1: G1PeriodicGCTask::should_start_periodic_gc may use uninitialised value if os::loadavg is unsupported [v5] In-Reply-To: References: <2OvCoQTGiaeASeEzeH7nPlNrqKuVBG4coqXf7FOqEc8=.1071778b-0427-4736-8d2c-4718b85081ca@github.com> Message-ID: <9Z0uZgAVFvn1O8CQFsVqXLdsC0d4G0qKi7rjpYot82c=.c8434574-e098-4ce7-bbe1-318b322de58d@github.com> On Wed, 24 Sep 2025 14:50:23 GMT, Guanqiang Han wrote: >> Please review this change. Thanks! >> >> **Description:** >> >> Previously the check combined loadavg() failure and threshold comparison in a single condition. When os::loadavg() returned -1, `recent_load` contained an undefined value but was still logged as if it was a real load average, leading to misleading log output. >> >> **Fix:** >> >> This change separates the failure case from the combined check: >> - If os::loadavg() returns -1, log "System loadavg not supported" and skip. >> - Only compare `recent_load` to the threshold when loadavg() succeeds. >> >> **Test:** >> >> GHA > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > Update g1PeriodicGCTask.cpp > > The periodic gc would be started the first time after detecting that loadavg is not supported. @hgqxjj Your change (at version 9a3f6d42f93bd03d80b8a857314c26eb9f40e253) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27413#issuecomment-3333457495 From ghan at openjdk.org Thu Sep 25 11:19:27 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 25 Sep 2025 11:19:27 GMT Subject: RFR: 8368089: G1: G1PeriodicGCTask::should_start_periodic_gc may use uninitialised value if os::loadavg is unsupported [v5] In-Reply-To: References: <2OvCoQTGiaeASeEzeH7nPlNrqKuVBG4coqXf7FOqEc8=.1071778b-0427-4736-8d2c-4718b85081ca@github.com> Message-ID: On Thu, 25 Sep 2025 08:40:32 GMT, Thomas Schatzl wrote: >> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: >> >> Update g1PeriodicGCTask.cpp >> >> The periodic gc would be started the first time after detecting that loadavg is not supported. > > Marked as reviewed by tschatzl (Reviewer). @tschatzl @walulyai @albertnetymk Thank you for the approval ! I've integrated the change. Could you kindly sponsor it? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27413#issuecomment-3333465125 From ghan at openjdk.org Thu Sep 25 11:58:33 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 25 Sep 2025 11:58:33 GMT Subject: Integrated: 8368089: G1: G1PeriodicGCTask::should_start_periodic_gc may use uninitialised value if os::loadavg is unsupported In-Reply-To: <2OvCoQTGiaeASeEzeH7nPlNrqKuVBG4coqXf7FOqEc8=.1071778b-0427-4736-8d2c-4718b85081ca@github.com> References: <2OvCoQTGiaeASeEzeH7nPlNrqKuVBG4coqXf7FOqEc8=.1071778b-0427-4736-8d2c-4718b85081ca@github.com> Message-ID: <9ORVnmgDrORxZaHWhmFIV-gxMcdOqZDVCq5SrHKsoTk=.72fabc8e-6470-4607-a343-52136abbd55c@github.com> On Sun, 21 Sep 2025 23:52:15 GMT, Guanqiang Han wrote: > Please review this change. Thanks! > > **Description:** > > Previously the check combined loadavg() failure and threshold comparison in a single condition. When os::loadavg() returned -1, `recent_load` contained an undefined value but was still logged as if it was a real load average, leading to misleading log output. > > **Fix:** > > This change separates the failure case from the combined check: > - If os::loadavg() returns -1, log "System loadavg not supported" and skip. > - Only compare `recent_load` to the threshold when loadavg() succeeds. > > **Test:** > > GHA This pull request has now been integrated. Changeset: 52e55046 Author: Guanqiang Han Committer: Ivan Walulya URL: https://git.openjdk.org/jdk/commit/52e550462798c568a8a5457af2f9554fd784cd8a Stats: 11 lines in 1 file changed: 6 ins; 0 del; 5 mod 8368089: G1: G1PeriodicGCTask::should_start_periodic_gc may use uninitialised value if os::loadavg is unsupported Reviewed-by: ayang, tschatzl, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/27413 From ghan at openjdk.org Thu Sep 25 12:03:50 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 25 Sep 2025 12:03:50 GMT Subject: RFR: 8368089: G1: G1PeriodicGCTask::should_start_periodic_gc may use uninitialised value if os::loadavg is unsupported [v5] In-Reply-To: References: <2OvCoQTGiaeASeEzeH7nPlNrqKuVBG4coqXf7FOqEc8=.1071778b-0427-4736-8d2c-4718b85081ca@github.com> Message-ID: On Wed, 24 Sep 2025 16:20:41 GMT, Ivan Walulya wrote: >> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: >> >> Update g1PeriodicGCTask.cpp >> >> The periodic gc would be started the first time after detecting that loadavg is not supported. > > Marked as reviewed by iwalulya (Reviewer). @walulyai Thanks? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27413#issuecomment-3333609439 From ayang at openjdk.org Thu Sep 25 13:31:32 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 25 Sep 2025 13:31:32 GMT Subject: RFR: 8368599: ShenandoahConcurrentMark could use ThreadsClaimTokenScope [v2] In-Reply-To: References: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com> Message-ID: On Thu, 25 Sep 2025 11:00:18 GMT, Francesco Andreuzzi wrote: >> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `ShenandoahConcurrentMark::finish_mark_work` to be more precise with what is actually needed and why. Similar to #27385. >> >> Test: tier1, and tier[1,2,3]_gc_shenandoah > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > as field Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27477#pullrequestreview-3267672065 From syan at openjdk.org Thu Sep 25 13:50:20 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 25 Sep 2025 13:50:20 GMT Subject: RFR: 8368668: Several vmTestbase/vm/gc/compact tests timed out Message-ID: Hi all, Several vmTestbase/vm/gc/compact tests was observed timed out after JDK-8260555 set the default jtreg timeout factor to 1. The test log shows that test detect 448 threads and 30GB(32178700288) memory. Seems that this stress make tests can not finish in 120s. This PR add '-Xmx2G' to decrease the test stress and make these tests run success steady. ------------- Commit messages: - 8368668: Several vmTestbase/vm/gc/compact tests timed out Changes: https://git.openjdk.org/jdk/pull/27488/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27488&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368668 Stats: 18 lines in 9 files changed: 9 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/27488.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27488/head:pull/27488 PR: https://git.openjdk.org/jdk/pull/27488 From shade at openjdk.org Thu Sep 25 14:19:21 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 25 Sep 2025 14:19:21 GMT Subject: RFR: 8368599: ShenandoahConcurrentMark could use ThreadsClaimTokenScope [v2] In-Reply-To: References: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com> Message-ID: On Thu, 25 Sep 2025 11:00:18 GMT, Francesco Andreuzzi wrote: >> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `ShenandoahConcurrentMark::finish_mark_work` to be more precise with what is actually needed and why. Similar to #27385. >> >> Test: tier1, and tier[1,2,3]_gc_shenandoah > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > as field Hold on a second. class StrongRootsScope : public MarkScope { ...and: MarkScope::MarkScope() { nmethod::oops_do_marking_prologue(); } MarkScope::~MarkScope() { nmethod::oops_do_marking_epilogue(); } So, what calls `nmethod::oops_do_marking_prologue`/`epilogue`, and do we know it is (not) needed? ------------- Changes requested by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27477#pullrequestreview-3267993745 From ayang at openjdk.org Thu Sep 25 14:39:50 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 25 Sep 2025 14:39:50 GMT Subject: RFR: 8368599: ShenandoahConcurrentMark could use ThreadsClaimTokenScope [v2] In-Reply-To: References: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com> Message-ID: On Thu, 25 Sep 2025 14:16:43 GMT, Aleksey Shipilev wrote: > So, what calls nmethod::oops_do_marking_prologue/epilogue, and do we know it is (not) needed? `nmethod::oops_do_marking_prologue/epilogue` is meant to undo the effect of `oops_do_try_claim` in `MarkingNMethodClosure`. Since Shenandoah conc marking doesn't use `MarkingNMethodClosure`, it's not needed. (STW full-gc marking, `ShenandoahSTWMark`, uses `MarkingNMethodClosure` though.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27477#issuecomment-3334488740 From lmesnik at openjdk.org Thu Sep 25 15:10:11 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 25 Sep 2025 15:10:11 GMT Subject: RFR: 8368668: Several vmTestbase/vm/gc/compact tests timed out In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 13:42:12 GMT, SendaoYan wrote: > Hi all, > > Several vmTestbase/vm/gc/compact tests was observed timed out after JDK-8260555 set the default jtreg timeout factor to 1. The test log shows that test detect 448 threads and 30GB(32178700288) memory. Seems that this stress make tests can not finish in 120s. > > This PR add '-Xmx2G' to decrease the test stress and make these tests run success steady. Changes requested by lmesnik (Reviewer). test/hotspot/jtreg/vmTestbase/vm/gc/compact/Compact_InternedStrings_Strings/TestDescription.java line 41: > 39: * @run main/othervm > 40: * -XX:-UseGCOverheadLimit > 41: * -Xmx2G It is not he good idea to fix heap size for the tests. We run them concurrently and heap size might be smaller then 2GB. The test should be executed for 30 seconds only and complete in 2 minutes. If you execute test with some specific configuration - it might be needed to add custom timeout factor. Can you please share the host and run confguration for failures? ------------- PR Review: https://git.openjdk.org/jdk/pull/27488#pullrequestreview-3268259045 PR Review Comment: https://git.openjdk.org/jdk/pull/27488#discussion_r2379490864 From wkemper at openjdk.org Thu Sep 25 15:40:35 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 25 Sep 2025 15:40:35 GMT Subject: Integrated: 8368499: GenShen: Do not collect age census during evac when adaptive tenuring is disabled In-Reply-To: References: Message-ID: <3qPceQaSOSQcS9k59ZW-nee-6yjND5eWelCz8RzEdXk=.ade4846d-9ae7-4349-8843-e9c6f932c901@github.com> On Wed, 24 Sep 2025 22:53:28 GMT, William Kemper wrote: > This is a simplification to `ShenandoahEvacTracker` (which is a diagnostic feature). The ability to compute the age census during evacuation was still in the code, even though the (experimental) option to enable it was removed. Removing the rest of the code allows us to take an additional flag-check off the evacuation path and to consolidate duplicated gc stat processing code between `shControlThread` and `shGenerationalControlThread`. This pull request has now been integrated. Changeset: 8ca1feaf Author: William Kemper URL: https://git.openjdk.org/jdk/commit/8ca1feaf7e29c1370853b9b95c2ee7a62c6b84b7 Stats: 250 lines in 11 files changed: 55 ins; 137 del; 58 mod 8368499: GenShen: Do not collect age census during evac when adaptive tenuring is disabled Reviewed-by: kdnilsen, ysr ------------- PR: https://git.openjdk.org/jdk/pull/27479 From xpeng at openjdk.org Thu Sep 25 19:07:22 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Thu, 25 Sep 2025 19:07:22 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v2] In-Reply-To: References: Message-ID: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of mutator memory allocation to improve heap lock contention, at vey high level, here is how it works: > * ShenandoahFreeSet holds a N (default to 13) number of ShenandoahHeapRegion* which are used by mutator threads for regular object allocations, they are called shared regions/directly allocatable regions, which are stored in PaddedEnd data structure(padded array). > * Each mutator thread will be assigned one of the directly allocatable regions, the thread will try to allocate in the directly allocatable region with CAS atomic operation, if fails will try 2 more consecutive directly allocatable regions in the array storing directly allocatable region. > * If mutator thread fails after trying 3 directly allocatable regions, it will: > * Take heap lock > * Try to retire the directly allocatable regions which are ready to retire. > * Iterator mutator partition and allocate directly allocatable regions and store to the padded array if any need to be retired. > * Satisfy mutator allocation request if possible. > > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, I have done many tests, here are some of them: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores: > Openjdk TIP: > > [ec2-user at ip-172-31-42-91 jdk]$ ./master-jdk/bin/java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms4G -Xmx4G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > ===== DaCapo tail latency, metered full smoothing: 50% 131684 usec, 90% 200192 usec, 99% 211369 usec, 99.9% 212517 usec, 99.99% 213043 usec, max 235289 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 1568 usec, 90% 36101 usec, 99% 42172 usec, 99.9% 42928 usec, 99.99% 43100 usec, max 43305 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 52644 usec, 90% 124393 usec, 99% 137711 usec, 99.9% 139355 usec, 99.99% 139749 usec, max 146722 usec, measured over 524288 events ====... Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 131 commits: - Merge branch 'openjdk:master' into cas-alloc-1 - Merge branch 'master' into cas-alloc-1 - Move ShenandoahHeapRegionIterationClosure to shenandoahFreeSet.hpp - Merge branch 'openjdk:master' into cas-alloc-1 - Fix errors caused by renaming ofAtomic to AtomicAccess - Merge branch 'openjdk:master' into cas-alloc-1 - Remove unused flag - Merge branch 'openjdk:master' into cas-alloc-1 - Merge branch 'cas-alloc-1' into cas-alloc - Merge branch 'cas-alloc-1' of https://github.com/pengxiaolong/jdk into cas-alloc-1 - ... and 121 more: https://git.openjdk.org/jdk/compare/3c9fd768...666f2ef1 ------------- Changes: https://git.openjdk.org/jdk/pull/26171/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=01 Stats: 735 lines in 16 files changed: 674 ins; 7 del; 54 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From ayang at openjdk.org Thu Sep 25 20:17:21 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 25 Sep 2025 20:17:21 GMT Subject: RFR: 8368715: Serial: Add GCTraceTime for marking from roots subphases during full gc marking Message-ID: Add a scoped timer for the first subphase of marking, to be aligned with other counterparts. Test: tier1-5 ------------- Commit messages: - sgc-scope-mark Changes: https://git.openjdk.org/jdk/pull/27499/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27499&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368715 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27499.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27499/head:pull/27499 PR: https://git.openjdk.org/jdk/pull/27499 From wkemper at openjdk.org Thu Sep 25 20:45:52 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 25 Sep 2025 20:45:52 GMT Subject: RFR: 8264851: Shenandoah: Rework control loop mechanics to use timed waits Message-ID: We use a similar mechanism in `shGenerationalControlThread` already. Using a timed wait allows the control thread to be woken up before the wait expires. ------------- Commit messages: - Add documentation and make new method private - Use timed wait/notify for more timely control thread reactions Changes: https://git.openjdk.org/jdk/pull/27502/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27502&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8264851 Stats: 28 lines in 2 files changed: 18 ins; 6 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27502.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27502/head:pull/27502 PR: https://git.openjdk.org/jdk/pull/27502 From fandreuzzi at openjdk.org Thu Sep 25 21:46:30 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 25 Sep 2025 21:46:30 GMT Subject: RFR: 8368715: Serial: Add GCTraceTime for marking from roots subphases during full gc marking In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 20:10:22 GMT, Albert Mingkun Yang wrote: > Add a scoped timer for the first subphase of marking, to be aligned with other counterparts. > > Test: tier1-5 Marked as reviewed by fandreuzzi (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/27499#pullrequestreview-3269551927 From kdnilsen at openjdk.org Thu Sep 25 23:39:57 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 25 Sep 2025 23:39:57 GMT Subject: RFR: 8368681: Shenandoah: Add documentation comments for ShenandoahAllocationRate Message-ID: Add documentation to ShenandoahAllocationRate ------------- Commit messages: - Add documentation Changes: https://git.openjdk.org/jdk/pull/27505/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27505&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368681 Stats: 44 lines in 2 files changed: 44 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27505.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27505/head:pull/27505 PR: https://git.openjdk.org/jdk/pull/27505 From wkemper at openjdk.org Thu Sep 25 23:52:22 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 25 Sep 2025 23:52:22 GMT Subject: RFR: 8368681: Shenandoah: Add documentation comments for ShenandoahAllocationRate In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 23:33:56 GMT, Kelvin Nilsen wrote: > Add documentation to ShenandoahAllocationRate Just a few typos src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp line 52: > 50: // The sampled allocation rate is computed from (allocated - _last_sample_value) / (current_time - _last_sample_time). > 51: // Return the newly computed rate if the sample is taken, zero if it is not an appropriate time to add a sample. > 52: // In the case that a new sample is not take, overwrite unaccounted_bytes_allocated with bytes allocated since s/take/taken src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp line 53: > 51: // Return the newly computed rate if the sample is taken, zero if it is not an appropriate time to add a sample. > 52: // In the case that a new sample is not take, overwrite unaccounted_bytes_allocated with bytes allocated since > 53: // the previous sample was taken (allocated - __last_sample_value). Otherwise, overwrite unaccounted_byets_allocated s/byets/bytes src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp line 73: > 71: private: > 72: > 73: // Return the instantaneous rate calculated from from (allocated - _last_sample_value) / (time - _last_sample_time). s/from from/from ------------- Changes requested by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27505#pullrequestreview-3269736178 PR Review Comment: https://git.openjdk.org/jdk/pull/27505#discussion_r2380542331 PR Review Comment: https://git.openjdk.org/jdk/pull/27505#discussion_r2380542829 PR Review Comment: https://git.openjdk.org/jdk/pull/27505#discussion_r2380544508 From wkemper at openjdk.org Thu Sep 25 23:59:22 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 25 Sep 2025 23:59:22 GMT Subject: RFR: 8368307: Shenandoah: get_next_bit_impl should special case weak and strong mark bits In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 21:31:24 GMT, Kelvin Nilsen wrote: > Check for weak bit or strong bit when giving special handling to the next bit found in first position of word. Changes requested by wkemper (Reviewer). src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.inline.hpp line 138: > 136: idx_t index = to_words_align_down(l_index); > 137: bm_word_t cword = (map(index) ^ flip) >> bit_in_word(l_index); > 138: if ((cword & 0x03) != 0) { Can we update the comment below to indicate that we are checking the first two bits because of strong and weak marking? Is there a risk here that dependents of this method will now start treating objects that are only weakly reachable as alive? Or does this fix a bug that caused us to miss such objects? ------------- PR Review: https://git.openjdk.org/jdk/pull/27476#pullrequestreview-3269751140 PR Review Comment: https://git.openjdk.org/jdk/pull/27476#discussion_r2380554607 From xpeng at openjdk.org Fri Sep 26 00:24:45 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 26 Sep 2025 00:24:45 GMT Subject: RFR: 8368681: Shenandoah: Add documentation comments for ShenandoahAllocationRate In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 23:33:56 GMT, Kelvin Nilsen wrote: > Add documentation to ShenandoahAllocationRate src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp line 74: > 72: > 73: // Return the instantaneous rate calculated from from (allocated - _last_sample_value) / (time - _last_sample_time). > 74: // Return Sentinel vlue 0.0 if (time - _last_sample_time) == 0 or if (allocated <= _last_sample_value). s/vlue/value ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27505#discussion_r2380581112 From syan at openjdk.org Fri Sep 26 03:05:51 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 26 Sep 2025 03:05:51 GMT Subject: RFR: 8368668: Several vmTestbase/vm/gc/compact tests timed out on large memory machine In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 15:07:29 GMT, Leonid Mesnik wrote: > We run them concurrently The file such as test/hotspot/jtreg/vmTestbase/vm/gc/compact/Compact_InternedStrings/TEST.properties which contain config `exclusiveAccess.dirs=.` will make sure these tests run serial, jtreg will ignore the '-conc' parameter when run these tests. > If you execute test with some specific configuration My test command is 'jtreg -v:fail,error,time -timeout:10 -nr -w tmp test/hotspot/jtreg/vmTestbase/vm/gc/compact/Compact_InternedStrings_Strings/TestDescription.java', there is no specific configuration. I think the biggest difference maybe my machine has huge physical memory, and many cpu core number. The test log shows this test will run finish 250 seconds on my machine, seems that the test will detect all the available memory automaticly and the huge memory will consume lots of time to finish. On my machine this test use 448 threads and 30GB max memory to test. So I want to limit the memory usage in test by jvm option `-Xmx2G`. The partial log snippet from vmTestbase/vm/gc/compact/Compact_InternedStrings_Strings/TestDescription.jtr Max memory: 32178700288 Sleep time: 500 Iterations: 0 Number of threads: 448 [TestDescription.jtr.log](https://github.com/user-attachments/files/22551569/TestDescription.jtr.log) After add the `-Xmx2G`, the test will detect use 64 threads and 2GB max memory to test. Another solution maybe use test parameter -t 16 to limit the test thread. The test environmental info: $ lscpu | head -n 8 Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Address sizes: 52 bits physical, 57 bits virtual Byte Order: Little Endian CPU(s): 224 On-line CPU(s) list: 0-223 Vendor ID: GenuineIntel Model name: Intel(R) Xeon(R) Platinum 8480+ $ free -h total used free shared buff/cache available Mem: 755Gi 8.6Gi 720Gi 4.0Mi 26Gi 742Gi Swap: 8.0Gi 18Mi 8.0Gi ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27488#discussion_r2380733991 From syan at openjdk.org Fri Sep 26 03:25:01 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 26 Sep 2025 03:25:01 GMT Subject: RFR: 8368668: Several vmTestbase/vm/gc/compact tests timed out on large memory machine [v2] In-Reply-To: References: Message-ID: <_LQgTVl9nWyvyUbpf6ySWDj5q5UGSCr2Px--Os02zxE=.c50d558e-737e-422e-a1d8-334412edace5@github.com> > Hi all, > > Several vmTestbase/vm/gc/compact tests was observed timed out after JDK-8260555 set the default jtreg timeout factor to 1. The test log shows that test detect 448 threads and 30GB(32178700288) memory. Seems that this stress make tests can not finish in 120s. > > This PR add '-Xmx2G' to decrease the test stress and make these tests run success steady. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Add -Xmx2G for vmTestbase/gc/gctests/AllocateWithoutOomTest/AllocateWithoutOomTest.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27488/files - new: https://git.openjdk.org/jdk/pull/27488/files/c337af53..7e10e171 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27488&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27488&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27488.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27488/head:pull/27488 PR: https://git.openjdk.org/jdk/pull/27488 From lmesnik at openjdk.org Fri Sep 26 05:44:14 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 26 Sep 2025 05:44:14 GMT Subject: RFR: 8368668: Several vmTestbase/vm/gc/compact tests timed out on large memory machine [v2] In-Reply-To: References: Message-ID: <4ypDhx0g1BlcmTF6Lpb7bjXMBmo6yeB33Tm93ssBgIQ=.17999e59-67bf-48aa-9f7a-e880a5d7c622@github.com> On Fri, 26 Sep 2025 02:59:26 GMT, SendaoYan wrote: >> test/hotspot/jtreg/vmTestbase/vm/gc/compact/Compact_InternedStrings_Strings/TestDescription.java line 41: >> >>> 39: * @run main/othervm >>> 40: * -XX:-UseGCOverheadLimit >>> 41: * -Xmx2G >> >> It is not he good idea to fix heap size for the tests. We run them concurrently and heap size might be smaller then 2GB. >> The test should be executed for 30 seconds only and complete in 2 minutes. >> If you execute test with some specific configuration - it might be needed to add custom timeout factor. >> Can you please share the host and run confguration for failures? > >> We run them concurrently > > The file such as test/hotspot/jtreg/vmTestbase/vm/gc/compact/Compact_InternedStrings/TEST.properties which contain config `exclusiveAccess.dirs=.` will make sure these tests run serial, jtreg will ignore the '-conc' parameter when run these tests. > >> If you execute test with some specific configuration > > My test command is 'jtreg -v:fail,error,time -timeout:10 -nr -w tmp test/hotspot/jtreg/vmTestbase/vm/gc/compact/Compact_InternedStrings_Strings/TestDescription.java', there is no specific configuration. I think the biggest difference maybe my machine has huge physical memory, and many cpu core number. > > The test log shows this test will run finish 250 seconds on my machine, seems that the test will detect all the available memory automaticly and the huge memory will consume lots of time to finish. On my machine this test use 448 threads and 30GB max memory to test. So I want to limit the memory usage in test by jvm option `-Xmx2G`. > > The partial log snippet from vmTestbase/vm/gc/compact/Compact_InternedStrings_Strings/TestDescription.jtr > Max memory: 32178700288 > Sleep time: 500 > Iterations: 0 > Number of threads: 448 > > [TestDescription.jtr.log](https://github.com/user-attachments/files/22551569/TestDescription.jtr.log) > > After add the `-Xmx2G`, the test will detect use 64 threads and 2GB max memory to test. Another solution maybe use test parameter -t 16 to limit the test thread. > > > The test environmental info: > $ lscpu | head -n 8 > Architecture: x86_64 > CPU op-mode(s): 32-bit, 64-bit > Address sizes: 52 bits physical, 57 bits virtual > Byte Order: Little Endian > CPU(s): 224 > On-line CPU(s) list: 0-223 > Vendor ID: GenuineIntel > Model name: Intel(R) Xeon(R) Platinum 8480+ > $ free -h > total used free shared buff/cache available > Mem: 755Gi 8.6Gi 720Gi 4.0Mi 26Gi 742Gi > Swap: 8.0Gi 18Mi 8.0Gi Thank you for info. The original idea is to scale these tests based on the execution host and not limit them to any particular size. I think that would be better to change the execution for your run assuming that your host is not typical commodity HW. You can set Xmx or RamPercentage for you runs instead of changing tests. Also, the number of CPU and thus the number of threads in stress tests might cause time consuming delays. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27488#discussion_r2380900531 From syan at openjdk.org Fri Sep 26 06:19:15 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 26 Sep 2025 06:19:15 GMT Subject: RFR: 8368668: Several vmTestbase/vm/gc/compact tests timed out on large memory machine [v2] In-Reply-To: <4ypDhx0g1BlcmTF6Lpb7bjXMBmo6yeB33Tm93ssBgIQ=.17999e59-67bf-48aa-9f7a-e880a5d7c622@github.com> References: <4ypDhx0g1BlcmTF6Lpb7bjXMBmo6yeB33Tm93ssBgIQ=.17999e59-67bf-48aa-9f7a-e880a5d7c622@github.com> Message-ID: On Fri, 26 Sep 2025 05:23:22 GMT, Leonid Mesnik wrote: >>> We run them concurrently >> >> The file such as test/hotspot/jtreg/vmTestbase/vm/gc/compact/Compact_InternedStrings/TEST.properties which contain config `exclusiveAccess.dirs=.` will make sure these tests run serial, jtreg will ignore the '-conc' parameter when run these tests. >> >>> If you execute test with some specific configuration >> >> My test command is 'jtreg -v:fail,error,time -timeout:10 -nr -w tmp test/hotspot/jtreg/vmTestbase/vm/gc/compact/Compact_InternedStrings_Strings/TestDescription.java', there is no specific configuration. I think the biggest difference maybe my machine has huge physical memory, and many cpu core number. >> >> The test log shows this test will run finish 250 seconds on my machine, seems that the test will detect all the available memory automaticly and the huge memory will consume lots of time to finish. On my machine this test use 448 threads and 30GB max memory to test. So I want to limit the memory usage in test by jvm option `-Xmx2G`. >> >> The partial log snippet from vmTestbase/vm/gc/compact/Compact_InternedStrings_Strings/TestDescription.jtr >> Max memory: 32178700288 >> Sleep time: 500 >> Iterations: 0 >> Number of threads: 448 >> >> [TestDescription.jtr.log](https://github.com/user-attachments/files/22551569/TestDescription.jtr.log) >> >> After add the `-Xmx2G`, the test will detect use 64 threads and 2GB max memory to test. Another solution maybe use test parameter -t 16 to limit the test thread. >> >> >> The test environmental info: >> $ lscpu | head -n 8 >> Architecture: x86_64 >> CPU op-mode(s): 32-bit, 64-bit >> Address sizes: 52 bits physical, 57 bits virtual >> Byte Order: Little Endian >> CPU(s): 224 >> On-line CPU(s) list: 0-223 >> Vendor ID: GenuineIntel >> Model name: Intel(R) Xeon(R) Platinum 8480+ >> $ free -h >> total used free shared buff/cache available >> Mem: 755Gi 8.6Gi 720Gi 4.0Mi 26Gi 742Gi >> Swap: 8.0Gi 18Mi 8.0Gi > > Thank you for info. > > The original idea is to scale these tests based on the execution host and not limit them to any particular size. > > I think that would be better to change the execution for your run assuming that your host is not typical commodity HW. You can set Xmx or RamPercentage for you runs instead of changing tests. Also, the number of CPU and thus the number of threads in stress tests might cause time consuming delays. The default timeout factor ie set to 4 before JDK-8260555, after JDK-8260555 the default timeout factor is set to 1, and this cause these stress tests run timed out. If we do not change the stress mode for these tests, should we increase the default timeout value from 120s to 480s, this will make these tests run normally for most of the machines. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27488#discussion_r2380987433 From syan at openjdk.org Fri Sep 26 06:36:39 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 26 Sep 2025 06:36:39 GMT Subject: RFR: 8368668: Several vmTestbase/vm/gc/compact tests timed out on large memory machine [v3] In-Reply-To: References: Message-ID: > Hi all, > > Several vmTestbase/vm/gc/compact tests was observed timed out after JDK-8260555 set the default jtreg timeout factor to 1. The test log shows that test detect 448 threads and 30GB(32178700288) memory. Seems that this stress make tests can not finish in 120s. > > This PR add '-Xmx2G' to decrease the test stress and make these tests run success steady. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Remove -Xmx2G and add timeout/480 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27488/files - new: https://git.openjdk.org/jdk/pull/27488/files/7e10e171..ddc4126d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27488&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27488&range=01-02 Stats: 20 lines in 10 files changed: 0 ins; 10 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/27488.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27488/head:pull/27488 PR: https://git.openjdk.org/jdk/pull/27488 From tschatzl at openjdk.org Fri Sep 26 07:24:26 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 26 Sep 2025 07:24:26 GMT Subject: RFR: 8368715: Serial: Add GCTraceTime for marking from roots subphases during full gc marking In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 20:10:22 GMT, Albert Mingkun Yang wrote: > Add a scoped timer for the first subphase of marking, to be aligned with other counterparts. > > Test: tier1-5 Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27499#pullrequestreview-3270531823 From ayang at openjdk.org Fri Sep 26 07:30:34 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 26 Sep 2025 07:30:34 GMT Subject: RFR: 8368006: Parallel: Skip full regions in dense prefix during Full GC [v2] In-Reply-To: <0gXhjgdxG3MgUvM3qE-pYFlPrx64Tmwf4l2gzSJ617A=.b4572760-7b74-4dab-9c52-ae169c4504f2@github.com> References: <0gXhjgdxG3MgUvM3qE-pYFlPrx64Tmwf4l2gzSJ617A=.b4572760-7b74-4dab-9c52-ae169c4504f2@github.com> Message-ID: On Fri, 19 Sep 2025 15:09:25 GMT, Albert Mingkun Yang wrote: >> Implement skip-full-region optimization for filler related operations on dense-prefix. I constrained the filler-creation task to a single worker for simpler implementation. During the compaction phase, the most expensive part is almost always the non-dense-prefix part, so letting the rest of workers to start with the expensive tasks seems sensible. >> >> Synthetic bms shows good reduction in full-gc time in debug build; perf-neutral for other bms (specjvm2008,specjbb2015) in release build. >> >> Test: tier1-5 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - review > - Merge branch 'master' into pgc-skip-full-region > - pgc-skip-full-region Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27369#issuecomment-3337132000 From ayang at openjdk.org Fri Sep 26 07:30:35 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 26 Sep 2025 07:30:35 GMT Subject: Integrated: 8368006: Parallel: Skip full regions in dense prefix during Full GC In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 18:00:18 GMT, Albert Mingkun Yang wrote: > Implement skip-full-region optimization for filler related operations on dense-prefix. I constrained the filler-creation task to a single worker for simpler implementation. During the compaction phase, the most expensive part is almost always the non-dense-prefix part, so letting the rest of workers to start with the expensive tasks seems sensible. > > Synthetic bms shows good reduction in full-gc time in debug build; perf-neutral for other bms (specjvm2008,specjbb2015) in release build. > > Test: tier1-5 This pull request has now been integrated. Changeset: 87307802 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/873078028b7cac1df94cd5a09e403c8537f14ba9 Stats: 96 lines in 2 files changed: 40 ins; 25 del; 31 mod 8368006: Parallel: Skip full regions in dense prefix during Full GC Reviewed-by: gli, fandreuzzi ------------- PR: https://git.openjdk.org/jdk/pull/27369 From ayang at openjdk.org Fri Sep 26 07:35:09 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 26 Sep 2025 07:35:09 GMT Subject: RFR: 8368715: Serial: Add GCTraceTime for marking from roots subphases during full gc marking [v2] In-Reply-To: References: Message-ID: > Add a scoped timer for the first subphase of marking, to be aligned with other counterparts. > > Test: tier1-5 Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: sgc-scope-mark ------------- Changes: https://git.openjdk.org/jdk/pull/27499/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27499&range=01 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27499.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27499/head:pull/27499 PR: https://git.openjdk.org/jdk/pull/27499 From ayang at openjdk.org Fri Sep 26 07:40:08 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 26 Sep 2025 07:40:08 GMT Subject: RFR: 8368740: Serial: Swap eden and survivor spaces position in young generation Message-ID: Change the relative position of eden and survior spaces in young-gen so that eden can be expanded to fulfill allocation request in heap-near-full scenario. What is on master doesn't allow eden expansion if there is live objs inside from/to after full-gc. Test: tier1-8 ------------- Commit messages: - sgc-expand-allocate Changes: https://git.openjdk.org/jdk/pull/27513/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27513&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368740 Stats: 216 lines in 5 files changed: 64 ins; 61 del; 91 mod Patch: https://git.openjdk.org/jdk/pull/27513.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27513/head:pull/27513 PR: https://git.openjdk.org/jdk/pull/27513 From fandreuzzi at openjdk.org Fri Sep 26 08:17:19 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 26 Sep 2025 08:17:19 GMT Subject: RFR: 8368599: ShenandoahConcurrentMark could use ThreadsClaimTokenScope [v2] In-Reply-To: References: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com> Message-ID: On Thu, 25 Sep 2025 14:37:06 GMT, Albert Mingkun Yang wrote: >> Hold on a second. >> >> >> class StrongRootsScope : public MarkScope { >> >> >> ...and: >> >> >> MarkScope::MarkScope() { >> nmethod::oops_do_marking_prologue(); >> } >> >> MarkScope::~MarkScope() { >> nmethod::oops_do_marking_epilogue(); >> } >> >> >> So, what calls `nmethod::oops_do_marking_prologue`/`epilogue`, and do we know it is (not) needed? > >> So, what calls nmethod::oops_do_marking_prologue/epilogue, and do we know it is (not) needed? > > `nmethod::oops_do_marking_prologue/epilogue` is meant to undo the effect of `oops_do_try_claim` in `MarkingNMethodClosure`. Since Shenandoah conc marking doesn't use `MarkingNMethodClosure`, it's not needed. (STW full-gc marking, `ShenandoahSTWMark`, uses `MarkingNMethodClosure` though.) Thanks for the review @albertnetymk and @earthling-amzn. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27477#issuecomment-3337288304 From duke at openjdk.org Fri Sep 26 08:17:23 2025 From: duke at openjdk.org (duke) Date: Fri, 26 Sep 2025 08:17:23 GMT Subject: RFR: 8368599: ShenandoahConcurrentMark could use ThreadsClaimTokenScope [v2] In-Reply-To: References: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com> Message-ID: On Thu, 25 Sep 2025 11:00:18 GMT, Francesco Andreuzzi wrote: >> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `ShenandoahConcurrentMark::finish_mark_work` to be more precise with what is actually needed and why. Similar to #27385. >> >> Test: tier1, and tier[1,2,3]_gc_shenandoah > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > as field @fandreuz Your change (at version b1686c28687a97ef3bc0764740c33a6dd89c0c2e) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27477#issuecomment-3337296420 From kdnilsen at openjdk.org Fri Sep 26 08:39:29 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Fri, 26 Sep 2025 08:39:29 GMT Subject: RFR: 8368307: Shenandoah: get_next_bit_impl should special case weak and strong mark bits [v2] In-Reply-To: References: Message-ID: > Check for weak bit or strong bit when giving special handling to the next bit found in first position of word. Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Fix up comment - Merge remote-tracking branch 'jdk/master' into next-bit-may-be-weak - check for weak bit or strong bit in first bit position ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27476/files - new: https://git.openjdk.org/jdk/pull/27476/files/d144bdc1..a3700aa0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27476&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27476&range=00-01 Stats: 13168 lines in 308 files changed: 7595 ins; 3835 del; 1738 mod Patch: https://git.openjdk.org/jdk/pull/27476.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27476/head:pull/27476 PR: https://git.openjdk.org/jdk/pull/27476 From kdnilsen at openjdk.org Fri Sep 26 08:39:32 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Fri, 26 Sep 2025 08:39:32 GMT Subject: RFR: 8368307: Shenandoah: get_next_bit_impl should special case weak and strong mark bits [v2] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 23:56:53 GMT, William Kemper wrote: >> Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Fix up comment >> - Merge remote-tracking branch 'jdk/master' into next-bit-may-be-weak >> - check for weak bit or strong bit in first bit position > > src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.inline.hpp line 138: > >> 136: idx_t index = to_words_align_down(l_index); >> 137: bm_word_t cword = (map(index) ^ flip) >> bit_in_word(l_index); >> 138: if ((cword & 0x03) != 0) { > > Can we update the comment below to indicate that we are checking the first two bits because of strong and weak marking? > > Is there a risk here that dependents of this method will now start treating objects that are only weakly reachable as alive? Or does this fix a bug that caused us to miss such objects? This does not fix a correctness issue. This represents a "special" case optimization. Basically, if either the first weak-mark or first strong-mark bits are set, we want to take this fast path to the return statement. The code is not wrong if we fail to take this fast path. It is simply less efficient. I noticed that the intent of this function is to return the index of the next set bit, regardless of whether it is a weak-mark bit or a strong-mark bit, when I was writing a unit test for this function as part of https://github.com/openjdk/jdk/pull/27353. In that PR, we introduce a new function complementary function, get_last_bit_impl(), and we use the 0x03 search pattern in that code. So this fix mirrors the behavior of the new function. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27476#discussion_r2381373652 From kdnilsen at openjdk.org Fri Sep 26 08:39:32 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Fri, 26 Sep 2025 08:39:32 GMT Subject: RFR: 8368307: Shenandoah: get_next_bit_impl should special case weak and strong mark bits [v2] In-Reply-To: References: Message-ID: <3rNS4PO9DmD_IJpPBIaj5UrRzoY7mzTMl59wU_c7q5I=.b4d766ee-fad3-4de1-abfa-2ea858d6546b@github.com> On Fri, 26 Sep 2025 08:32:10 GMT, Kelvin Nilsen wrote: >> src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.inline.hpp line 138: >> >>> 136: idx_t index = to_words_align_down(l_index); >>> 137: bm_word_t cword = (map(index) ^ flip) >> bit_in_word(l_index); >>> 138: if ((cword & 0x03) != 0) { >> >> Can we update the comment below to indicate that we are checking the first two bits because of strong and weak marking? >> >> Is there a risk here that dependents of this method will now start treating objects that are only weakly reachable as alive? Or does this fix a bug that caused us to miss such objects? > > This does not fix a correctness issue. This represents a "special" case optimization. > > Basically, if either the first weak-mark or first strong-mark bits are set, we want to take this fast path to the return statement. The code is not wrong if we fail to take this fast path. It is simply less efficient. > > I noticed that the intent of this function is to return the index of the next set bit, regardless of whether it is a weak-mark bit or a strong-mark bit, when I was writing a unit test for this function as part of https://github.com/openjdk/jdk/pull/27353. > > In that PR, we introduce a new function complementary function, get_last_bit_impl(), and we use the 0x03 search pattern in that code. So this fix mirrors the behavior of the new function. I'll fix this comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27476#discussion_r2381379088 From ayang at openjdk.org Fri Sep 26 09:02:40 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 26 Sep 2025 09:02:40 GMT Subject: RFR: 8368752: Serial: Remove unused arg of DefNewGeneration::gc_epilogue Message-ID: Trivial removing dead code. Test: tier1 ------------- Commit messages: - sgc-trivial Changes: https://git.openjdk.org/jdk/pull/27516/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27516&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368752 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27516.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27516/head:pull/27516 PR: https://git.openjdk.org/jdk/pull/27516 From iwalulya at openjdk.org Fri Sep 26 09:03:30 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Fri, 26 Sep 2025 09:03:30 GMT Subject: RFR: 8368715: Serial: Add GCTraceTime for marking from roots subphases during full gc marking [v2] In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 07:35:09 GMT, Albert Mingkun Yang wrote: >> Add a scoped timer for the first subphase of marking, to be aligned with other counterparts. >> >> Test: tier1-5 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > sgc-scope-mark Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27499#pullrequestreview-3271003044 From fandreuzzi at openjdk.org Fri Sep 26 09:08:41 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 26 Sep 2025 09:08:41 GMT Subject: RFR: 8368740: Serial: Swap eden and survivor spaces position in young generation In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 07:33:19 GMT, Albert Mingkun Yang wrote: > Change the relative position of eden and survior spaces in young-gen so that eden can be expanded to fulfill allocation request in heap-near-full scenario. What is on master doesn't allow eden expansion if there is live objs inside from/to after full-gc. > > Test: tier1-8 src/hotspot/share/gc/serial/defNewGeneration.cpp line 345: > 343: > 344: MemRegion eden_mr{eden()->bottom(), (HeapWord*)_virtual_space.high()}; > 345: eden()->initialize(eden_mr, eden()->is_empty(), SpaceDecorator::Mangle); `eden()->is_empty()` should always be `false` after expansion, since `delta_bytes > 0`, right? Could be an assertion ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27513#discussion_r2381511734 From fandreuzzi at openjdk.org Fri Sep 26 09:16:29 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 26 Sep 2025 09:16:29 GMT Subject: RFR: 8368740: Serial: Swap eden and survivor spaces position in young generation In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 07:33:19 GMT, Albert Mingkun Yang wrote: > Change the relative position of eden and survior spaces in young-gen so that eden can be expanded to fulfill allocation request in heap-near-full scenario. What is on master doesn't allow eden expansion if there is live objs inside from/to after full-gc. > > Test: tier1-8 src/hotspot/share/gc/serial/defNewGeneration.cpp line 283: > 281: } > 282: size_t eden_size = size - (2 * survivor_size); > 283: assert(eden_size > 0 && survivor_size <= eden_size, "just checking"); Is it guaranteed that `size > 2 * survivor_size`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27513#discussion_r2381545364 From ayang at openjdk.org Fri Sep 26 09:16:31 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 26 Sep 2025 09:16:31 GMT Subject: RFR: 8368740: Serial: Swap eden and survivor spaces position in young generation In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 09:05:40 GMT, Francesco Andreuzzi wrote: > eden()->is_empty() should always be false after expansion, since delta_bytes > 0 I don't get it; it's possible that eden is NOT empty and we expands it to satisfy pending alloc-request. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27513#discussion_r2381547015 From tschatzl at openjdk.org Fri Sep 26 09:17:37 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 26 Sep 2025 09:17:37 GMT Subject: RFR: 8368752: Serial: Remove unused arg of DefNewGeneration::gc_epilogue In-Reply-To: References: Message-ID: <3h8elH3_rwM3Iajav-Fdnq65g6bCp7C9CNUZkh_eHuk=.c8d85fdb-94dc-4bfc-b0c0-f826008bea51@github.com> On Fri, 26 Sep 2025 08:56:11 GMT, Albert Mingkun Yang wrote: > Trivial removing dead code. > > Test: tier1 Trivial. ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27516#pullrequestreview-3271092900 From aboldtch at openjdk.org Fri Sep 26 09:19:12 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 26 Sep 2025 09:19:12 GMT Subject: RFR: 8367317: ZGC: ZVirtualMemoryReserver::force_reserve_discontiguous arithmetic underflow [v2] In-Reply-To: References: Message-ID: > ZVirtualMemoryReserver::force_reserve_discontiguous is a debug only API used to simulate and test a discontinuous heap. The loop variable `end` is incorrectly checked which may lead to an underflow. > > In our normal testing we never observe this as the address space is always available. We observed this issue when running a hardened build (like ASAN) which had already mmapped the address space we tried to reserve. > > Rather than always jump two reserve sizes in its search, it searches every reserve size, moving an extra reserve size every time it succeeds with a reservation (so that there always is a gap). Searching in reserve sized steps is not really a requirement here, we could have just used a granule sized step. Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge tag 'jdk-26+17' into JDK-8367317 Added tag jdk-26+17 for changeset 2aafda19 - 8367317: ZGC: ZVirtualMemoryReserver::force_reserve_discontiguous arithmetic underflow ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27207/files - new: https://git.openjdk.org/jdk/pull/27207/files/825941e0..6c77150f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27207&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27207&range=00-01 Stats: 162142 lines in 1784 files changed: 132737 ins; 18333 del; 11072 mod Patch: https://git.openjdk.org/jdk/pull/27207.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27207/head:pull/27207 PR: https://git.openjdk.org/jdk/pull/27207 From aboldtch at openjdk.org Fri Sep 26 09:22:58 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 26 Sep 2025 09:22:58 GMT Subject: RFR: 8351137: ZGC: Improve ZValueStorage alignment support [v3] In-Reply-To: References: Message-ID: > ZValueStorage only align the allocations to the alignment defined by the storage but ignores the alignment of the types. Right now all usages of our different storages all have types which have an alignment less than or equal to the alignment set by its storage. > > I wish to improve this so that types with greater alignment than the storage alignment can be used. > > The UB caused by using a type larger than the storage alignment is something I have seen materialise as returning bad address (and crashing) on Windows. > > As we use `utilities/align.hpp` for our alignment utilities we only support power of two alignment, I added extra asserts here because we use the fact that `lcm(x, y) = max(x, y)` if both are powers of two. > > Testing: > * tier 1 through tier 5 Oracle supported platforms > * GHA Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge tag 'jdk-26+17' into JDK-8351137 Added tag jdk-26+17 for changeset 2aafda19 - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8351137 - 8351137: ZGC: Improve ZValueStorage alignment support ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23887/files - new: https://git.openjdk.org/jdk/pull/23887/files/ccca8a5d..857249f5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23887&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23887&range=01-02 Stats: 565837 lines in 8608 files changed: 383369 ins; 124373 del; 58095 mod Patch: https://git.openjdk.org/jdk/pull/23887.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23887/head:pull/23887 PR: https://git.openjdk.org/jdk/pull/23887 From fandreuzzi at openjdk.org Fri Sep 26 09:24:11 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 26 Sep 2025 09:24:11 GMT Subject: RFR: 8368740: Serial: Swap eden and survivor spaces position in young generation In-Reply-To: References: Message-ID: <01zQaGMPKUdTsmabZUWcR66D_G169geVqWju4rDU7MU=.7e30d508-253d-4c20-ada1-9b9858a08407@github.com> On Fri, 26 Sep 2025 09:13:00 GMT, Albert Mingkun Yang wrote: >> src/hotspot/share/gc/serial/defNewGeneration.cpp line 345: >> >>> 343: >>> 344: MemRegion eden_mr{eden()->bottom(), (HeapWord*)_virtual_space.high()}; >>> 345: eden()->initialize(eden_mr, eden()->is_empty(), SpaceDecorator::Mangle); >> >> `eden()->is_empty()` should always be `false` after expansion, since `delta_bytes > 0`, right? Could be an assertion > >> eden()->is_empty() should always be false after expansion, since delta_bytes > 0 > > I don't get it; it's possible that eden is NOT empty and we expands it to satisfy pending alloc-request. What I'm asking is: is it possible that `eden()->is_empty()` is `false` in L345? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27513#discussion_r2381582170 From fandreuzzi at openjdk.org Fri Sep 26 09:24:14 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 26 Sep 2025 09:24:14 GMT Subject: RFR: 8368740: Serial: Swap eden and survivor spaces position in young generation In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 07:33:19 GMT, Albert Mingkun Yang wrote: > Change the relative position of eden and survior spaces in young-gen so that eden can be expanded to fulfill allocation request in heap-near-full scenario. What is on master doesn't allow eden expansion if there is live objs inside from/to after full-gc. > > Test: tier1-8 src/hotspot/share/gc/serial/defNewGeneration.cpp line 426: > 424: return; > 425: } > 426: } else { How about `else if (current_young_gen_size_bytes > desired_young_gen_size_bytes)` here? `VirtualSpace::shrink_by(size_t)` seems to do some work even when `delta_bytes = 0`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27513#discussion_r2381571226 From fandreuzzi at openjdk.org Fri Sep 26 09:45:41 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 26 Sep 2025 09:45:41 GMT Subject: RFR: 8368752: Serial: Remove unused arg of DefNewGeneration::gc_epilogue In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 08:56:11 GMT, Albert Mingkun Yang wrote: > Trivial removing dead code. > > Test: tier1 Marked as reviewed by fandreuzzi (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/27516#pullrequestreview-3271260901 From kdnilsen at openjdk.org Fri Sep 26 10:23:14 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Fri, 26 Sep 2025 10:23:14 GMT Subject: RFR: 8358735: GenShen: bug in #undef'd code in block_start() Message-ID: When scanning a range of dirty cards within the GenShen remembered set, we need to find the object that spans the beginning of the left-most dirty card. The existing code is not reliable following class unloading. The new code uses the marking context when it is available to determine the location of live objects that reside below TAMS within each region. Above TAMS, all objects are presumed live and parsable. ------------- Commit messages: - cleanup code for review - Fix order of include files - fix white space - disable for debug build, alphabetic order for includes - add explicit typecast to avoid compiler warning message - Remove troublesome assert that assumes lock is held - Merge remote-tracking branch 'jdk/master' into finish-block-start - Add handling for first_object_start() past end of range - Revert extraneous changes - Add special handling above TAMS - ... and 15 more: https://git.openjdk.org/jdk/compare/01d7554b...76979421 Changes: https://git.openjdk.org/jdk/pull/27353/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27353&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358735 Stats: 849 lines in 11 files changed: 812 ins; 5 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/27353.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27353/head:pull/27353 PR: https://git.openjdk.org/jdk/pull/27353 From kdnilsen at openjdk.org Fri Sep 26 10:23:14 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Fri, 26 Sep 2025 10:23:14 GMT Subject: RFR: 8358735: GenShen: bug in #undef'd code in block_start() In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 20:12:49 GMT, Kelvin Nilsen wrote: > When scanning a range of dirty cards within the GenShen remembered set, we need to find the object that spans the beginning of the left-most dirty card. The existing code is not reliable following class unloading. > > The new code uses the marking context when it is available to determine the location of live objects that reside below TAMS within each region. Above TAMS, all objects are presumed live and parsable. /author: ysramakrishna Have confirmed with several hundred runs that this fixes the error typically observed within 100 runs on master. Reproducer: ~/github/jdk.finish-block-start/build/linux-x86_64-server-fastdebug/jdk/bin/java \ -XX:+PrintFlagsFinal -XX:-UseCompressedOops \ -XX:-UseCompressedClassPointers -XX:+AlwaysPreTouch -Xms10g -Xmx10g \ -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational \ -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions \ -XX:-ShenandoahUncommit -XX:+ShenandoahVerify -XX:+ShenandoahAllocFailureALot -XX:+UseStringDeduplication \ -Xlog:async -Xlog:"gc*=info,safepoint*=info,handshake*=info" \ -jar ~/lib/dacapo-23.11-chopin.jar --scratch-directory ./tmp/dacapo-scratch/tomcat \ --no-validation --iterations 5 --log-directory ./tmp/dacapo-log/tomcat tomcat \ > trial.$COUNT.out 2>trial.$COUNT.err ------------- PR Comment: https://git.openjdk.org/jdk/pull/27353#issuecomment-3304431762 PR Comment: https://git.openjdk.org/jdk/pull/27353#issuecomment-3337947338 From tschatzl at openjdk.org Fri Sep 26 11:46:28 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 26 Sep 2025 11:46:28 GMT Subject: RFR: 8071277: G1: Merge commits and uncommits of contiguous memory [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review this change to G1 commit/uncommit to merge commit/uncommit calls to the operating system as much as possible. This significantly improves startup performanc > > Performance results before/after on Zen3 processor for a "HelloWorld" application: > > > $ hyperfine -w 10 -r 10 "baseline/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello" > Benchmark 1: baseline/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello > Time (mean ? ?): 16.4 ms ? 0.4 ms [User: 11.0 ms, System: 14.4 ms] > Range (min ? max): 15.7 ms ? 16.8 ms 10 runs > > $ hyperfine -w 10 -r 10 "baseline/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello" > Benchmark 1: baseline/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello > Time (mean ? ?): 24.7 ms ? 0.4 ms [User: 10.7 ms, System: 22.7 ms] > Range (min ? max): 24.2 ms ? 25.4 ms 10 runs > > My reimplementation of JDK-8071277 does show improvements here: > > $ hyperfine -w 10 -r 10 "changes/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello" > Benchmark 1: changes/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello > Time (mean ? ?): 15.9 ms ? 0.4 ms [User: 11.9 ms, System: 13.1 ms] > Range (min ? max): 15.4 ms ? 16.7 ms 10 runs > > $ hyperfine -w 10 -r 10 "changes/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello" > Benchmark 1: changes/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello > Time (mean ? ?): 19.7 ms ? 0.3 ms [User: 11.3 ms, System: 17.4 ms] > Range (min ? max): 19.2 ms ? 20.1 ms 10 runs > > > I.e., depending on actually committed heap size (`-Xms`), reduction of startup time by 20% or so in above cases. > > Testing: tier1-5, gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision: - * exploit the fact that this is always a single region to (un-)commit - * ayang idea to use an iterative approach for better readability ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27381/files - new: https://git.openjdk.org/jdk/pull/27381/files/30248277..779daa7f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27381&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27381&range=00-01 Stats: 109 lines in 1 file changed: 24 ins; 56 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/27381.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27381/head:pull/27381 PR: https://git.openjdk.org/jdk/pull/27381 From tschatzl at openjdk.org Fri Sep 26 11:49:58 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 26 Sep 2025 11:49:58 GMT Subject: RFR: 8071277: G1: Merge commits and uncommits of contiguous memory [v2] In-Reply-To: References: Message-ID: <47oBkVXcalEwkR9TrjPALsojFWjNKpbFclxJ4AOq-rw=.52132f2b-955b-4f6f-bb98-3006a6638348@github.com> On Fri, 26 Sep 2025 11:46:28 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change to G1 commit/uncommit to merge commit/uncommit calls to the operating system as much as possible. This significantly improves startup performanc >> >> Performance results before/after on Zen3 processor for a "HelloWorld" application: >> >> >> $ hyperfine -w 10 -r 10 "baseline/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello" >> Benchmark 1: baseline/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello >> Time (mean ? ?): 16.4 ms ? 0.4 ms [User: 11.0 ms, System: 14.4 ms] >> Range (min ? max): 15.7 ms ? 16.8 ms 10 runs >> >> $ hyperfine -w 10 -r 10 "baseline/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello" >> Benchmark 1: baseline/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello >> Time (mean ? ?): 24.7 ms ? 0.4 ms [User: 10.7 ms, System: 22.7 ms] >> Range (min ? max): 24.2 ms ? 25.4 ms 10 runs >> >> My reimplementation of JDK-8071277 does show improvements here: >> >> $ hyperfine -w 10 -r 10 "changes/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello" >> Benchmark 1: changes/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello >> Time (mean ? ?): 15.9 ms ? 0.4 ms [User: 11.9 ms, System: 13.1 ms] >> Range (min ? max): 15.4 ms ? 16.7 ms 10 runs >> >> $ hyperfine -w 10 -r 10 "changes/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello" >> Benchmark 1: changes/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello >> Time (mean ? ?): 19.7 ms ? 0.3 ms [User: 11.3 ms, System: 17.4 ms] >> Range (min ? max): 19.2 ms ? 20.1 ms 10 runs >> >> >> I.e., depending on actually committed heap size (`-Xms`), reduction of startup time by 20% or so in above cases. >> >> Testing: tier1-5, gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision: > > - * exploit the fact that this is always a single region to (un-)commit > - * ayang idea to use an iterative approach for better readability The latest change implements @albertnetymk 's suggestion to make the loop explicit; I also noticed that actually there can be at most a single range of memory that can be committed/uncommitted for one commit/uncommit call, so the loop can actually be removed. Testing: tier1-5 ------------- PR Comment: https://git.openjdk.org/jdk/pull/27381#issuecomment-3338293792 From ayang at openjdk.org Fri Sep 26 13:27:32 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 26 Sep 2025 13:27:32 GMT Subject: RFR: 8368740: Serial: Swap eden and survivor spaces position in young generation [v2] In-Reply-To: References: Message-ID: > Change the relative position of eden and survior spaces in young-gen so that eden can be expanded to fulfill allocation request in heap-near-full scenario. What is on master doesn't allow eden expansion if there is live objs inside from/to after full-gc. > > Test: tier1-8 Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27513/files - new: https://git.openjdk.org/jdk/pull/27513/files/56c2b0e3..57a88bd4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27513&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27513&range=00-01 Stats: 15 lines in 1 file changed: 11 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27513.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27513/head:pull/27513 PR: https://git.openjdk.org/jdk/pull/27513 From ayang at openjdk.org Fri Sep 26 13:27:35 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 26 Sep 2025 13:27:35 GMT Subject: RFR: 8368740: Serial: Swap eden and survivor spaces position in young generation [v2] In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 09:12:37 GMT, Francesco Andreuzzi wrote: >> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> review > > src/hotspot/share/gc/serial/defNewGeneration.cpp line 283: > >> 281: } >> 282: size_t eden_size = size - (2 * survivor_size); >> 283: assert(eden_size > 0 && survivor_size <= eden_size, "just checking"); > > Is it guaranteed that `size > 2 * survivor_size`? I overlooked that. Revised `calculate_desired_young_gen_bytes` so that we can have such invariant here. > src/hotspot/share/gc/serial/defNewGeneration.cpp line 426: > >> 424: return; >> 425: } >> 426: } else { > > How about `else if (current_young_gen_size_bytes > desired_young_gen_size_bytes)` here? `VirtualSpace::shrink_by(size_t)` seems to do some work even when `delta_bytes = 0`. The zero-case is handled a few lines above by `if (current_young_gen_size_bytes == desired_young_gen_size_bytes)`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27513#discussion_r2382420566 PR Review Comment: https://git.openjdk.org/jdk/pull/27513#discussion_r2381640393 From ayang at openjdk.org Fri Sep 26 13:27:36 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 26 Sep 2025 13:27:36 GMT Subject: RFR: 8368740: Serial: Swap eden and survivor spaces position in young generation [v2] In-Reply-To: <01zQaGMPKUdTsmabZUWcR66D_G169geVqWju4rDU7MU=.7e30d508-253d-4c20-ada1-9b9858a08407@github.com> References: <01zQaGMPKUdTsmabZUWcR66D_G169geVqWju4rDU7MU=.7e30d508-253d-4c20-ada1-9b9858a08407@github.com> Message-ID: On Fri, 26 Sep 2025 09:21:31 GMT, Francesco Andreuzzi wrote: > is it possible that eden()->is_empty() is false in L345? Yes; it can be `true` or `false`. `is_empty` is about whether there is any allocation in it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27513#discussion_r2381656191 From fandreuzzi at openjdk.org Fri Sep 26 13:33:27 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 26 Sep 2025 13:33:27 GMT Subject: RFR: 8368740: Serial: Swap eden and survivor spaces position in young generation [v2] In-Reply-To: References: <01zQaGMPKUdTsmabZUWcR66D_G169geVqWju4rDU7MU=.7e30d508-253d-4c20-ada1-9b9858a08407@github.com> Message-ID: On Fri, 26 Sep 2025 09:37:39 GMT, Albert Mingkun Yang wrote: >> What I'm asking is: is it possible that `eden()->is_empty()` is `false` in L345? > >> is it possible that eden()->is_empty() is false in L345? > > Yes; it can be `true` or `false`. `is_empty` is about whether there is any allocation in it. Thanks for the clarification ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27513#discussion_r2382442174 From fandreuzzi at openjdk.org Fri Sep 26 13:33:30 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 26 Sep 2025 13:33:30 GMT Subject: RFR: 8368740: Serial: Swap eden and survivor spaces position in young generation [v2] In-Reply-To: References: Message-ID: <28dDIG51WlEvWpvzBvqSug8IXTDwRDZf5fd2Nojn2ho=.cf9b2e0d-c826-411c-b9ea-c2ca9e32811b@github.com> On Fri, 26 Sep 2025 09:34:16 GMT, Albert Mingkun Yang wrote: >> src/hotspot/share/gc/serial/defNewGeneration.cpp line 426: >> >>> 424: return; >>> 425: } >>> 426: } else { >> >> How about `else if (current_young_gen_size_bytes > desired_young_gen_size_bytes)` here? `VirtualSpace::shrink_by(size_t)` seems to do some work even when `delta_bytes = 0`. > > The zero-case is handled a few lines above by `if (current_young_gen_size_bytes == desired_young_gen_size_bytes)`. Missed that, thanks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27513#discussion_r2382438178 From ayang at openjdk.org Fri Sep 26 14:51:40 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 26 Sep 2025 14:51:40 GMT Subject: RFR: 8368752: Serial: Remove unused arg of DefNewGeneration::gc_epilogue In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 08:56:11 GMT, Albert Mingkun Yang wrote: > Trivial removing dead code. > > Test: tier1 Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27516#issuecomment-3339034467 From ayang at openjdk.org Fri Sep 26 14:51:41 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 26 Sep 2025 14:51:41 GMT Subject: Integrated: 8368752: Serial: Remove unused arg of DefNewGeneration::gc_epilogue In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 08:56:11 GMT, Albert Mingkun Yang wrote: > Trivial removing dead code. > > Test: tier1 This pull request has now been integrated. Changeset: 25abdd85 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/25abdd85c41f7aef41915cabd8596c0ce573acd6 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod 8368752: Serial: Remove unused arg of DefNewGeneration::gc_epilogue Reviewed-by: tschatzl, fandreuzzi ------------- PR: https://git.openjdk.org/jdk/pull/27516 From wkemper at openjdk.org Fri Sep 26 15:13:55 2025 From: wkemper at openjdk.org (William Kemper) Date: Fri, 26 Sep 2025 15:13:55 GMT Subject: RFR: 8368307: Shenandoah: get_next_bit_impl should special case weak and strong mark bits [v2] In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 08:39:29 GMT, Kelvin Nilsen wrote: >> Check for weak bit or strong bit when giving special handling to the next bit found in first position of word. > > Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Fix up comment > - Merge remote-tracking branch 'jdk/master' into next-bit-may-be-weak > - check for weak bit or strong bit in first bit position Marked as reviewed by wkemper (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27476#pullrequestreview-3272694762 From wkemper at openjdk.org Fri Sep 26 15:13:57 2025 From: wkemper at openjdk.org (William Kemper) Date: Fri, 26 Sep 2025 15:13:57 GMT Subject: RFR: 8368307: Shenandoah: get_next_bit_impl should special case weak and strong mark bits [v2] In-Reply-To: <3rNS4PO9DmD_IJpPBIaj5UrRzoY7mzTMl59wU_c7q5I=.b4d766ee-fad3-4de1-abfa-2ea858d6546b@github.com> References: <3rNS4PO9DmD_IJpPBIaj5UrRzoY7mzTMl59wU_c7q5I=.b4d766ee-fad3-4de1-abfa-2ea858d6546b@github.com> Message-ID: On Fri, 26 Sep 2025 08:33:24 GMT, Kelvin Nilsen wrote: >> This does not fix a correctness issue. This represents a "special" case optimization. >> >> Basically, if either the first weak-mark or first strong-mark bits are set, we want to take this fast path to the return statement. The code is not wrong if we fail to take this fast path. It is simply less efficient. >> >> I noticed that the intent of this function is to return the index of the next set bit, regardless of whether it is a weak-mark bit or a strong-mark bit, when I was writing a unit test for this function as part of https://github.com/openjdk/jdk/pull/27353. >> >> In that PR, we introduce a new function complementary function, get_last_bit_impl(), and we use the 0x03 search pattern in that code. So this fix mirrors the behavior of the new function. > > I'll fix this comment. Got i t, thank you! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27476#discussion_r2382711211 From lmesnik at openjdk.org Fri Sep 26 17:31:47 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 26 Sep 2025 17:31:47 GMT Subject: RFR: 8368668: Several vmTestbase/vm/gc/compact tests timed out on large memory machine [v3] In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 06:36:39 GMT, SendaoYan wrote: >> Hi all, >> >> Several vmTestbase/vm/gc/compact tests was observed timed out after JDK-8260555 set the default jtreg timeout factor to 1. The test log shows that test detect 448 threads and 30GB(32178700288) memory. Seems that this stress make tests can not finish in 120s. >> >> The default timeout factor ie set to 4 before JDK-8260555, after JDK-8260555 the default timeout factor is set to 1, and this cause these stress tests run timed out. If we do not change the stress mode for these tests, should we increase the default timeout value from 120s to 480s, this will make these tests run normally for most of the machines and make these tests more generally. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Remove -Xmx2G and add timeout/480 Thanks for update. The tests might be optimized later if needed. ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27488#pullrequestreview-3273180443 From syan at openjdk.org Sat Sep 27 02:40:26 2025 From: syan at openjdk.org (SendaoYan) Date: Sat, 27 Sep 2025 02:40:26 GMT Subject: RFR: 8368668: Several vmTestbase/vm/gc/compact tests timed out on large memory machine [v3] In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 17:29:07 GMT, Leonid Mesnik wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove -Xmx2G and add timeout/480 > > Thanks for update. The tests might be optimized later if needed. Thanks @lmesnik Only change the default timeout value for several vmTestbase tests, No risk. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27488#issuecomment-3341051685 From syan at openjdk.org Sat Sep 27 02:40:27 2025 From: syan at openjdk.org (SendaoYan) Date: Sat, 27 Sep 2025 02:40:27 GMT Subject: Integrated: 8368668: Several vmTestbase/vm/gc/compact tests timed out on large memory machine In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 13:42:12 GMT, SendaoYan wrote: > Hi all, > > Several vmTestbase/vm/gc/compact tests was observed timed out after JDK-8260555 set the default jtreg timeout factor to 1. The test log shows that test detect 448 threads and 30GB(32178700288) memory. Seems that this stress make tests can not finish in 120s. > > The default timeout factor ie set to 4 before JDK-8260555, after JDK-8260555 the default timeout factor is set to 1, and this cause these stress tests run timed out. If we do not change the stress mode for these tests, should we increase the default timeout value from 120s to 480s, this will make these tests run normally for most of the machines and make these tests more generally. This pull request has now been integrated. Changeset: 9093d3a0 Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/9093d3a04cd2b66425cefb44de2990cb5362a29f Stats: 20 lines in 10 files changed: 0 ins; 0 del; 20 mod 8368668: Several vmTestbase/vm/gc/compact tests timed out on large memory machine Reviewed-by: lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/27488 From kdnilsen at openjdk.org Sat Sep 27 04:10:22 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Sat, 27 Sep 2025 04:10:22 GMT Subject: Integrated: 8368307: Shenandoah: get_next_bit_impl should special case weak and strong mark bits In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 21:31:24 GMT, Kelvin Nilsen wrote: > Check for weak bit or strong bit when giving special handling to the next bit found in first position of word. This pull request has now been integrated. Changeset: af8fb20a Author: Kelvin Nilsen URL: https://git.openjdk.org/jdk/commit/af8fb20ac0325a231ee14bd72e9764e02ca07681 Stats: 8 lines in 1 file changed: 0 ins; 2 del; 6 mod 8368307: Shenandoah: get_next_bit_impl should special case weak and strong mark bits Reviewed-by: wkemper ------------- PR: https://git.openjdk.org/jdk/pull/27476 From tschatzl at openjdk.org Sat Sep 27 08:54:24 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Sat, 27 Sep 2025 08:54:24 GMT Subject: RFR: 8048180: Eager reclaim of humongous objects with references Message-ID: Hi all, please review this change to G1 that enables eager reclaim of humongous objects with references, either objArrays or just really large objects. It works the same as other humongous object's eager reclaim, with the caveat that I disabled it during concurrent mark to avoid problems with SATB. There is fairly extensive documentation about why I think this works, and how in the comment in `g1YoungCollector.cpp`. The test case exhaustively tests all combinations of when a particular type of object should be able to be reclaimed depending on when it is allocated (only for `typeArray` and `objArray` - huge objects work the same as the latter). I added a diagnostic flag `G1EagerReclaimWithRefs` to allow disabling this particular functionality for diagnostic purposes, but I think it's not really necessary, and I'm open to remove it. The following screenshot shows pause times before (purple) and after (brown) of one of the [Optaplanner](https://www.optaplanner.org/blog/2021/09/15/HowMuchFasterIsJava17.html) benchmarks as a result of this change. Screenshot 2025-09-26 at 13 59 05 Testing: new test cases, gha, tier1-5 Thanks, Thomas ------------- Commit messages: - * also check for actual region reclamation Changes: https://git.openjdk.org/jdk/pull/27525/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27525&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8048180 Stats: 356 lines in 9 files changed: 187 ins; 113 del; 56 mod Patch: https://git.openjdk.org/jdk/pull/27525.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27525/head:pull/27525 PR: https://git.openjdk.org/jdk/pull/27525 From ayang at openjdk.org Sat Sep 27 09:54:14 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Sat, 27 Sep 2025 09:54:14 GMT Subject: RFR: 8071277: G1: Merge commits and uncommits of contiguous memory [v2] In-Reply-To: References: Message-ID: <8oGDuQDNNd8hOc37GqVVxSswU6Gx-_PW7sM3q7tILRo=.58a7f6cf-af6d-481d-a6cd-b3dd0e80d0de@github.com> On Fri, 26 Sep 2025 11:46:28 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change to G1 commit/uncommit to merge commit/uncommit calls to the operating system as much as possible. This significantly improves startup performanc >> >> Performance results before/after on Zen3 processor for a "HelloWorld" application: >> >> >> $ hyperfine -w 10 -r 10 "baseline/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello" >> Benchmark 1: baseline/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello >> Time (mean ? ?): 16.4 ms ? 0.4 ms [User: 11.0 ms, System: 14.4 ms] >> Range (min ? max): 15.7 ms ? 16.8 ms 10 runs >> >> $ hyperfine -w 10 -r 10 "baseline/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello" >> Benchmark 1: baseline/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello >> Time (mean ? ?): 24.7 ms ? 0.4 ms [User: 10.7 ms, System: 22.7 ms] >> Range (min ? max): 24.2 ms ? 25.4 ms 10 runs >> >> My reimplementation of JDK-8071277 does show improvements here: >> >> $ hyperfine -w 10 -r 10 "changes/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello" >> Benchmark 1: changes/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello >> Time (mean ? ?): 15.9 ms ? 0.4 ms [User: 11.9 ms, System: 13.1 ms] >> Range (min ? max): 15.4 ms ? 16.7 ms 10 runs >> >> $ hyperfine -w 10 -r 10 "changes/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello" >> Benchmark 1: changes/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello >> Time (mean ? ?): 19.7 ms ? 0.3 ms [User: 11.3 ms, System: 17.4 ms] >> Range (min ? max): 19.2 ms ? 20.1 ms 10 runs >> >> >> I.e., depending on actually committed heap size (`-Xms`), reduction of startup time by 20% or so in above cases. >> >> Testing: tier1-5, gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision: > > - * exploit the fact that this is always a single region to (un-)commit > - * ayang idea to use an iterative approach for better readability Marked as reviewed by ayang (Reviewer). src/hotspot/share/gc/g1/g1RegionToSpaceMapper.cpp line 219: > 217: > 218: size_t uncommitted_l = find_first_uncommitted(start_page, end_page); > 219: size_t committed_r = find_first_committed(uncommitted_l + 1, end_page); I'd suggest `uncommitted_r` to match its "left" pair -- together they (left + right) form the uncommitted-range. ------------- PR Review: https://git.openjdk.org/jdk/pull/27381#pullrequestreview-3274773562 PR Review Comment: https://git.openjdk.org/jdk/pull/27381#discussion_r2384025606 From kdnilsen at openjdk.org Sat Sep 27 23:13:34 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Sat, 27 Sep 2025 23:13:34 GMT Subject: RFR: 8368681: Shenandoah: Add documentation comments for ShenandoahAllocationRate [v2] In-Reply-To: References: Message-ID: > Add documentation to ShenandoahAllocationRate Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Fix several typos ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27505/files - new: https://git.openjdk.org/jdk/pull/27505/files/2dce29d2..35bce7e3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27505&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27505&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27505.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27505/head:pull/27505 PR: https://git.openjdk.org/jdk/pull/27505 From kdnilsen at openjdk.org Sat Sep 27 23:13:35 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Sat, 27 Sep 2025 23:13:35 GMT Subject: RFR: 8368681: Shenandoah: Add documentation comments for ShenandoahAllocationRate [v2] In-Reply-To: References: Message-ID: <29b4Jj0ouaoWbHsGS_Sqfiji0TZwdb0XXoRmNSEoIWI=.fb31b179-3101-4627-9ee9-a9df25ba3861@github.com> On Thu, 25 Sep 2025 23:46:11 GMT, William Kemper wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix several typos > > src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp line 53: > >> 51: // Return the newly computed rate if the sample is taken, zero if it is not an appropriate time to add a sample. >> 52: // In the case that a new sample is not take, overwrite unaccounted_bytes_allocated with bytes allocated since >> 53: // the previous sample was taken (allocated - __last_sample_value). Otherwise, overwrite unaccounted_byets_allocated > > s/byets/bytes Thanks. Fixed. > src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp line 73: > >> 71: private: >> 72: >> 73: // Return the instantaneous rate calculated from from (allocated - _last_sample_value) / (time - _last_sample_time). > > s/from from/from Thanks. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27505#discussion_r2384381257 PR Review Comment: https://git.openjdk.org/jdk/pull/27505#discussion_r2384381400 From kdnilsen at openjdk.org Sat Sep 27 23:13:37 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Sat, 27 Sep 2025 23:13:37 GMT Subject: RFR: 8368681: Shenandoah: Add documentation comments for ShenandoahAllocationRate [v2] In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 00:22:14 GMT, Xiaolong Peng wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix several typos > > src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp line 74: > >> 72: >> 73: // Return the instantaneous rate calculated from from (allocated - _last_sample_value) / (time - _last_sample_time). >> 74: // Return Sentinel vlue 0.0 if (time - _last_sample_time) == 0 or if (allocated <= _last_sample_value). > > s/vlue/value Thanks. Fixed. (Sorry Xiaolong and William for so many typos in this PR. Thanks for your careful reviews.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27505#discussion_r2384381630 From tschatzl at openjdk.org Sun Sep 28 09:39:34 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Sun, 28 Sep 2025 09:39:34 GMT Subject: RFR: 8071277: G1: Merge commits and uncommits of contiguous memory [v3] In-Reply-To: References: Message-ID: <1MIxbJcVrqKOqS2xXyQysBL9M6HEGIT9dOHjdkICwN4=.f48899ba-2d80-488c-8221-ddb9b6211d10@github.com> > Hi all, > > please review this change to G1 commit/uncommit to merge commit/uncommit calls to the operating system as much as possible. This significantly improves startup performanc > > Performance results before/after on Zen3 processor for a "HelloWorld" application: > > > $ hyperfine -w 10 -r 10 "baseline/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello" > Benchmark 1: baseline/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello > Time (mean ? ?): 16.4 ms ? 0.4 ms [User: 11.0 ms, System: 14.4 ms] > Range (min ? max): 15.7 ms ? 16.8 ms 10 runs > > $ hyperfine -w 10 -r 10 "baseline/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello" > Benchmark 1: baseline/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello > Time (mean ? ?): 24.7 ms ? 0.4 ms [User: 10.7 ms, System: 22.7 ms] > Range (min ? max): 24.2 ms ? 25.4 ms 10 runs > > My reimplementation of JDK-8071277 does show improvements here: > > $ hyperfine -w 10 -r 10 "changes/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello" > Benchmark 1: changes/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello > Time (mean ? ?): 15.9 ms ? 0.4 ms [User: 11.9 ms, System: 13.1 ms] > Range (min ? max): 15.4 ms ? 16.7 ms 10 runs > > $ hyperfine -w 10 -r 10 "changes/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello" > Benchmark 1: changes/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello > Time (mean ? ?): 19.7 ms ? 0.3 ms [User: 11.3 ms, System: 17.4 ms] > Range (min ? max): 19.2 ms ? 20.1 ms 10 runs > > > I.e., depending on actually committed heap size (`-Xms`), reduction of startup time by 20% or so in above cases. > > Testing: tier1-5, gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * ayang review, renaming ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27381/files - new: https://git.openjdk.org/jdk/pull/27381/files/779daa7f..eadbba67 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27381&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27381&range=01-02 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27381.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27381/head:pull/27381 PR: https://git.openjdk.org/jdk/pull/27381 From bronee at gmail.com Sun Sep 28 16:19:11 2025 From: bronee at gmail.com (Brian S O'Neill) Date: Sun, 28 Sep 2025 09:19:11 -0700 Subject: G1 concurrent refinement regression Message-ID: <0e327fd3-3fc2-484f-86eb-9c4fc0b09869@gmail.com> I'm observing an interesting regression between build 26-ea+16-1649 and build 26-ea+17-1764 with respect to concurrent refinement. I suspect the cause is JEP 522. I ran a stress test in which GC pauses are about 25ms in the steady state. With 26-ea+16-1649, concurrent refinement is never initiated. With 26-ea+17-1764 (JEP 522) concurrent refinement starts after the test has run for a few minutes. Eventually, concurrent refinement runs back to back forever, wasting a CPU core and affecting overall performance. [244.479s][info][gc,start ] GC(60) Pause Young (Normal) (G1 Evacuation Pause) [244.479s][info][gc,task ] GC(60) Using 8 workers of 8 for evacuation [244.501s][info][gc,phases ] GC(60) Pre Evacuate Collection Set: 0.19ms [244.501s][info][gc,phases ] GC(60) Merge Heap Roots: 0.12ms [244.501s][info][gc,phases ] GC(60) Evacuate Collection Set: 20.53ms [244.501s][info][gc,phases ] GC(60) Post Evacuate Collection Set: 0.59ms [244.501s][info][gc,phases ] GC(60) Other: 0.35ms [244.501s][info][gc,heap ] GC(60) Eden regions: 920->0(920) [244.501s][info][gc,heap ] GC(60) Survivor regions: 1->1(116) [244.501s][info][gc,heap ] GC(60) Old regions: 156->156 [244.501s][info][gc,heap ] GC(60) Humongous regions: 9->9 [244.501s][info][gc,metaspace] GC(60) Metaspace: 5499K(5952K)->5499K(5952K) NonClass: 4891K(5184K)->4891K(5184K) Class: 608K(768K)->608K(768K) [244.502s][info][gc ] GC(60) Pause Young (Normal) (G1 Evacuation Pause) 2167M->327M(3072M) 22.125ms [244.502s][info][gc,cpu ] GC(60) User=0.23s Sys=0.00s Real=0.02s [248.721s][info][gc,refine,start] Concurrent Refine Cycle [248.721s][info][gc,refine,start] Concurrent Refine Global Card Table Swap [248.721s][info][gc,refine ] Concurrent Refine Global Card Table Swap 0.029ms [248.721s][info][gc,refine,start] Concurrent Refine Java Thread CT swap [248.726s][info][gc,refine ] Concurrent Refine Java Thread CT swap 4.946ms [248.726s][info][gc,refine,start] Concurrent Refine GC Thread CT swap [248.726s][info][gc,refine ] Concurrent Refine GC Thread CT swap 0.050ms [248.726s][info][gc,refine,start] Concurrent Refine Snapshot Heap [248.726s][info][gc,refine ] Concurrent Refine Snapshot Heap 0.076ms [248.726s][info][gc,task ] Concurrent Refine Sweep Using 1 of 8 Workers [248.726s][info][gc,refine,start] Concurrent Refine Table Step [248.884s][info][gc,refine ] Concurrent Refine Table Step 158.020ms [248.884s][info][gc,refine,start] Concurrent Refine Complete Work [248.884s][info][gc,refine ] Concurrent Refine Complete Work 0.030ms [248.884s][info][gc,refine ] Concurrent Refine Cycle 163.510ms And eventually: [403.369s][info][gc,refine,start] Concurrent Refine Cycle [403.369s][info][gc,refine,start] Concurrent Refine Global Card Table Swap [403.369s][info][gc,refine ] Concurrent Refine Global Card Table Swap 0.019ms [403.369s][info][gc,refine,start] Concurrent Refine Java Thread CT swap [403.371s][info][gc,refine ] Concurrent Refine Java Thread CT swap 1.910ms [403.371s][info][gc,refine,start] Concurrent Refine GC Thread CT swap [403.371s][info][gc,refine ] Concurrent Refine GC Thread CT swap 0.048ms [403.371s][info][gc,refine,start] Concurrent Refine Snapshot Heap [403.371s][info][gc,refine ] Concurrent Refine Snapshot Heap 0.077ms [403.371s][info][gc,task ] Concurrent Refine Sweep Using 1 of 8 Workers [403.371s][info][gc,refine,start] Concurrent Refine Table Step [403.601s][info][gc,refine ] Concurrent Refine Table Step 229.866ms [403.601s][info][gc,refine,start] Concurrent Refine Complete Work [403.601s][info][gc,refine ] Concurrent Refine Complete Work 0.022ms [403.601s][info][gc,refine ] Concurrent Refine Cycle 232.259ms [403.601s][info][gc,refine,start] Concurrent Refine Cycle [403.601s][info][gc,refine,start] Concurrent Refine Global Card Table Swap [403.601s][info][gc,refine ] Concurrent Refine Global Card Table Swap 0.015ms [403.601s][info][gc,refine,start] Concurrent Refine Java Thread CT swap [403.602s][info][gc,refine ] Concurrent Refine Java Thread CT swap 0.669ms [403.602s][info][gc,refine,start] Concurrent Refine GC Thread CT swap [403.602s][info][gc,refine ] Concurrent Refine GC Thread CT swap 0.047ms [403.602s][info][gc,refine,start] Concurrent Refine Snapshot Heap [403.602s][info][gc,refine ] Concurrent Refine Snapshot Heap 0.079ms [403.602s][info][gc,task ] Concurrent Refine Sweep Using 1 of 8 Workers [403.602s][info][gc,refine,start] Concurrent Refine Table Step [403.761s][info][gc,refine ] Concurrent Refine Table Step 159.273ms [403.761s][info][gc,refine,start] Concurrent Refine Complete Work [403.761s][info][gc,refine ] Concurrent Refine Complete Work 0.022ms [403.761s][info][gc,refine ] Concurrent Refine Cycle 160.341ms The problem goes away when I set -XX:MaxGCPauseMillis=500 or higher. Considering that the pauses are always well below the 200ms default, I'm surprised that concurrent refinement occurs at all. From kdnilsen at openjdk.org Sun Sep 28 16:32:14 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Sun, 28 Sep 2025 16:32:14 GMT Subject: RFR: 8264851: Shenandoah: Rework control loop mechanics to use timed waits In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 20:35:59 GMT, William Kemper wrote: > We use a similar mechanism in `shGenerationalControlThread` already. Using a timed wait allows the control thread to be woken up before the wait expires. Marked as reviewed by kdnilsen (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27502#pullrequestreview-3277156578 From kdnilsen at openjdk.org Sun Sep 28 21:44:14 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Sun, 28 Sep 2025 21:44:14 GMT Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in ShenandoahFreeSet [v4] In-Reply-To: References: Message-ID: > This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet. In the new code, we keep a single tally of relevant information within ShenandoahFreeSet. > Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet. > > This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies. These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms. > > The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: revert changes to shenandoahAdaptiveHeuristics.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26867/files - new: https://git.openjdk.org/jdk/pull/26867/files/cd9522af..46717a74 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=02-03 Stats: 5 lines in 1 file changed: 3 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26867.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26867/head:pull/26867 PR: https://git.openjdk.org/jdk/pull/26867 From kdnilsen at openjdk.org Sun Sep 28 23:45:18 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Sun, 28 Sep 2025 23:45:18 GMT Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in ShenandoahFreeSet [v3] In-Reply-To: References: <0DIlqJVwgCnx2FvbXZuDySjJ3hz241ag41o3BCHkSuY=.ac51c769-c5c0-4750-99b4-0ff43f864d33@github.com> Message-ID: <-h1hI8i3oFf5q81lymjg6wVR3r0RMA3ZCF-z6-m7dTU=.52f09166-ea4d-445e-9393-12923464cdf2@github.com> On Fri, 12 Sep 2025 17:37:01 GMT, Kelvin Nilsen wrote: >> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 372: >> >>> 370: _last_sample_time = now; >>> 371: _last_sample_value = allocated; >>> 372: } >> >> This was a bug. If we don't update the average, we should not restart the time until next sample and we should not overwrite the value of _last_sample_value. > > Let's split this out into a different PR. I reverted these changes, addressed this issue in separate PR https://github.com/openjdk/jdk/pull/27398, and merged from mainline. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2386423882 From kdnilsen at openjdk.org Sun Sep 28 23:52:07 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Sun, 28 Sep 2025 23:52:07 GMT Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in ShenandoahFreeSet [v5] In-Reply-To: References: Message-ID: <1GU4oXKtR0svO4h0rBVbeUdApNLbcuTNbRwg2M2qMSs=.dcc9cc11-a298-4d3e-920f-30caf7ed4f92@github.com> > This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet. In the new code, we keep a single tally of relevant information within ShenandoahFreeSet. > Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet. > > This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies. These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms. > > The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books. Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 116 commits: - Merge remote-tracking branch 'jdk/master' into freeset-has-authoritative-tallies - revert changes to shenandoahAdaptiveHeuristics.cpp - another tweak to make GHA gtest happy - Add include file for missing declaration - Fix ShenandoahAllocationRate::sample() and remove debug scaffolding - Remove debug instrumentation - Cleanup make_all_regions_unavailable() - Remove RENAISSANCE debugging instrumentation - Replace MEMORY_USAGE debugging with assertions - Zero [empty_]region_counts in make_all_regions_unavailable plus lots of debug instrumentation - ... and 106 more: https://git.openjdk.org/jdk/compare/320230db...7fad8482 ------------- Changes: https://git.openjdk.org/jdk/pull/26867/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=04 Stats: 3110 lines in 34 files changed: 1978 ins; 539 del; 593 mod Patch: https://git.openjdk.org/jdk/pull/26867.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26867/head:pull/26867 PR: https://git.openjdk.org/jdk/pull/26867 From kdnilsen at openjdk.org Mon Sep 29 00:05:16 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 29 Sep 2025 00:05:16 GMT Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in ShenandoahFreeSet [v3] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 17:17:17 GMT, Kelvin Nilsen wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> another tweak to make GHA gtest happy > > src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 3271: > >> 3269: } >> 3270: } >> 3271: > > Maybe we no longer need regular bypass because CDS no longer needs regular bypass. ShenandoahFreeSet::decrease_humongous_waste_for_regular_bypass() is called from ShenandoahHeapRegion::decrement_humongous_waste(). ShenandoahHeapRegion::decrement_humongous_waste() is called from ShenandoahHeapRegion::make_trash(). It looks to me like we still need this functionality. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2386436422 From kdnilsen at openjdk.org Mon Sep 29 00:13:41 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 29 Sep 2025 00:13:41 GMT Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in ShenandoahFreeSet [v6] In-Reply-To: References: Message-ID: > This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet. In the new code, we keep a single tally of relevant information within ShenandoahFreeSet. > Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet. > > This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies. These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms. > > The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Change spelling of symbolic constant in test program ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26867/files - new: https://git.openjdk.org/jdk/pull/26867/files/7fad8482..ad45b667 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=04-05 Stats: 6 lines in 1 file changed: 2 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26867.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26867/head:pull/26867 PR: https://git.openjdk.org/jdk/pull/26867 From kdnilsen at openjdk.org Mon Sep 29 00:13:42 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 29 Sep 2025 00:13:42 GMT Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in ShenandoahFreeSet [v3] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 18:13:54 GMT, Kelvin Nilsen wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> another tweak to make GHA gtest happy > > test/hotspot/jtreg/gc/shenandoah/mxbeans/TestChurnNotifications.java line 162: > >> 160: long count = TARGET_MB * 1024 * 1024 / (16 + 4 * size); >> 161: >> 162: long anticipated_humongous_waste_per_array = 124_272; > > Define ANTICIPATED_HUMONGOUS_WASTE_PER_ARRAY as a static constant. I've made this change ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2386439133 From kdnilsen at openjdk.org Mon Sep 29 03:40:16 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 29 Sep 2025 03:40:16 GMT Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in ShenandoahFreeSet [v7] In-Reply-To: References: Message-ID: > This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet. In the new code, we keep a single tally of relevant information within ShenandoahFreeSet. > Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet. > > This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies. These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms. > > The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books. Kelvin Nilsen has updated the pull request incrementally with two additional commits since the last revision: - Fix typo introduced during merge - Use OO implementation of ShenandoahGeneration::used() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26867/files - new: https://git.openjdk.org/jdk/pull/26867/files/ad45b667..144ace0b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=05-06 Stats: 43 lines in 5 files changed: 21 ins; 15 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/26867.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26867/head:pull/26867 PR: https://git.openjdk.org/jdk/pull/26867 From thomas.schatzl at oracle.com Mon Sep 29 06:09:00 2025 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 29 Sep 2025 08:09:00 +0200 Subject: G1 concurrent refinement regression In-Reply-To: <0e327fd3-3fc2-484f-86eb-9c4fc0b09869@gmail.com> References: <0e327fd3-3fc2-484f-86eb-9c4fc0b09869@gmail.com> Message-ID: <1bd99343-b71d-43f8-9543-6bb28d343fc2@oracle.com> Hi Brian, On 28.09.25 18:19, Brian S O'Neill wrote: > I'm observing an interesting regression between build 26-ea+16-1649 and > build 26-ea+17-1764 with respect to concurrent refinement. I suspect the > cause is JEP 522. > > I ran a stress test in which GC pauses are about 25ms in the steady > state. With 26-ea+16-1649, concurrent refinement is never initiated. Thanks for trying out latest EAs. > With 26-ea+17-1764 (JEP 522) concurrent refinement starts after the > test has run for a few minutes. Eventually, concurrent refinement runs > back to back forever, wasting a CPU core and affecting overall > performance. > > [...] > > The problem goes away when I set -XX:MaxGCPauseMillis=500 or higher. > Considering that the pauses are always well below the 200ms default, > I'm surprised that concurrent refinement occurs at all. Before and after this change, refinement is and has been driven by time allocated for refinement in the pause. By default this is 10% of the maximum pause time goal (-XX:G1RSetUpdatingPauseTimePercent). This is, at a pause time goal of 200ms, 20ms. It is somewhat unlikely that this part of the GC takes 20ms out of your 25ms pauses, so I suspect some bug :) Is it possible to add gc+refine=debug,gc+phases=debug to your logs and send them here to better analyze what is happening? Thanks, Thomas From thomas.schatzl at oracle.com Mon Sep 29 06:10:15 2025 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 29 Sep 2025 08:10:15 +0200 Subject: G1 concurrent refinement regression In-Reply-To: <1bd99343-b71d-43f8-9543-6bb28d343fc2@oracle.com> References: <0e327fd3-3fc2-484f-86eb-9c4fc0b09869@gmail.com> <1bd99343-b71d-43f8-9543-6bb28d343fc2@oracle.com> Message-ID: Hi, On 29.09.25 08:09, Thomas Schatzl wrote: > Hi Brian, > > On 28.09.25 18:19, Brian S O'Neill wrote: >> I'm observing an interesting regression between build 26-ea+16-1649 >> and build 26-ea+17-1764 with respect to concurrent refinement. I >> suspect the cause is JEP 522. >> >> I ran a stress test in which GC pauses are about 25ms in the steady >> state. With 26-ea+16-1649, concurrent refinement is never initiated. > > Thanks for trying out latest EAs. > > > > With 26-ea+17-1764 (JEP 522) concurrent refinement starts after the > > test has run for a few minutes. Eventually, concurrent refinement runs > > back to back forever, wasting a CPU core and affecting overall > > performance. > > > > [...] > > > > The problem goes away when I set -XX:MaxGCPauseMillis=500 or higher. > > Considering that the pauses are always well below the 200ms default, > > I'm surprised that concurrent refinement occurs at all. > > > Before and after this change, refinement is and has been driven by time > allocated for refinement in the pause. > > By default this is 10% of the maximum pause time goal (- > XX:G1RSetUpdatingPauseTimePercent). This is, at a pause time goal of > 200ms, 20ms. It is somewhat unlikely that this part of the GC takes 20ms > out of your 25ms pauses, so I suspect some bug :) That said, increasing this percentage would/should serve as a temporary workaround. > > Is it possible to add gc+refine=debug,gc+phases=debug to your logs and > send them here to better analyze what is happening? > > Thanks, > ? Thomas > Thanks, Thomas From gli at openjdk.org Mon Sep 29 06:57:50 2025 From: gli at openjdk.org (Guoxiong Li) Date: Mon, 29 Sep 2025 06:57:50 GMT Subject: RFR: 8368740: Serial: Swap eden and survivor spaces position in young generation [v2] In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 13:27:32 GMT, Albert Mingkun Yang wrote: >> Change the relative position of eden and survior spaces in young-gen so that eden can be expanded to fulfill allocation request in heap-near-full scenario. What is on master doesn't allow eden expansion if there is live objs inside from/to after full-gc. >> >> Test: tier1-8 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review src/hotspot/share/gc/serial/defNewGeneration.cpp line 478: > 476: > 477: // Keep from/to and expand eden. > 478: expand_eden_by(_virtual_space.uncommitted_size()); Just expanding eden space may go against the option `SurvivorRatio`. src/hotspot/share/gc/serial/defNewGeneration.cpp line 507: > 505: const size_t min_survivor_bytes = SpaceAlignment; > 506: return reserved_bytes - min_survivor_bytes; > 507: } You set `min_survivor_bytes` as `SpaceAlignment`. It seems not obey the eden/survivor ratio rule. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27513#discussion_r2386884934 PR Review Comment: https://git.openjdk.org/jdk/pull/27513#discussion_r2386826126 From ayang at openjdk.org Mon Sep 29 07:30:24 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 29 Sep 2025 07:30:24 GMT Subject: RFR: 8071277: G1: Merge commits and uncommits of contiguous memory [v3] In-Reply-To: <1MIxbJcVrqKOqS2xXyQysBL9M6HEGIT9dOHjdkICwN4=.f48899ba-2d80-488c-8221-ddb9b6211d10@github.com> References: <1MIxbJcVrqKOqS2xXyQysBL9M6HEGIT9dOHjdkICwN4=.f48899ba-2d80-488c-8221-ddb9b6211d10@github.com> Message-ID: On Sun, 28 Sep 2025 09:39:34 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change to G1 commit/uncommit to merge commit/uncommit calls to the operating system as much as possible. This significantly improves startup performanc >> >> Performance results before/after on Zen3 processor for a "HelloWorld" application: >> >> >> $ hyperfine -w 10 -r 10 "baseline/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello" >> Benchmark 1: baseline/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello >> Time (mean ? ?): 16.4 ms ? 0.4 ms [User: 11.0 ms, System: 14.4 ms] >> Range (min ? max): 15.7 ms ? 16.8 ms 10 runs >> >> $ hyperfine -w 10 -r 10 "baseline/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello" >> Benchmark 1: baseline/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello >> Time (mean ? ?): 24.7 ms ? 0.4 ms [User: 10.7 ms, System: 22.7 ms] >> Range (min ? max): 24.2 ms ? 25.4 ms 10 runs >> >> My reimplementation of JDK-8071277 does show improvements here: >> >> $ hyperfine -w 10 -r 10 "changes/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello" >> Benchmark 1: changes/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello >> Time (mean ? ?): 15.9 ms ? 0.4 ms [User: 11.9 ms, System: 13.1 ms] >> Range (min ? max): 15.4 ms ? 16.7 ms 10 runs >> >> $ hyperfine -w 10 -r 10 "changes/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello" >> Benchmark 1: changes/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello >> Time (mean ? ?): 19.7 ms ? 0.3 ms [User: 11.3 ms, System: 17.4 ms] >> Range (min ? max): 19.2 ms ? 20.1 ms 10 runs >> >> >> I.e., depending on actually committed heap size (`-Xms`), reduction of startup time by 20% or so in above cases. >> >> Testing: tier1-5, gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * ayang review, renaming Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27381#pullrequestreview-3278286465 From ayang at openjdk.org Mon Sep 29 07:30:37 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 29 Sep 2025 07:30:37 GMT Subject: Integrated: 8368715: Serial: Add GCTraceTime for marking from roots subphases during full gc marking In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 20:10:22 GMT, Albert Mingkun Yang wrote: > Add a scoped timer for the first subphase of marking, to be aligned with other counterparts. > > Test: tier1-5 This pull request has now been integrated. Changeset: 75269fdb Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/75269fdb49aeb9d37acbbc1502c446a822fd30e3 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8368715: Serial: Add GCTraceTime for marking from roots subphases during full gc marking Reviewed-by: fandreuzzi, tschatzl, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/27499 From ayang at openjdk.org Mon Sep 29 07:30:35 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 29 Sep 2025 07:30:35 GMT Subject: RFR: 8368715: Serial: Add GCTraceTime for marking from roots subphases during full gc marking [v2] In-Reply-To: References: Message-ID: <5FnnGnpfpPOokeUDMRCWWWOkmiHDT9lu0ckoV3UjNAk=.eb311810-0f61-442b-973a-1c21108698b9@github.com> On Fri, 26 Sep 2025 07:35:09 GMT, Albert Mingkun Yang wrote: >> Add a scoped timer for the first subphase of marking, to be aligned with other counterparts. >> >> Test: tier1-5 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision: > > sgc-scope-mark Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27499#issuecomment-3345424899 From ayang at openjdk.org Mon Sep 29 07:37:19 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 29 Sep 2025 07:37:19 GMT Subject: RFR: 8368740: Serial: Swap eden and survivor spaces position in young generation [v2] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 06:54:39 GMT, Guoxiong Li wrote: >> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> review > > src/hotspot/share/gc/serial/defNewGeneration.cpp line 478: > >> 476: >> 477: // Keep from/to and expand eden. >> 478: expand_eden_by(_virtual_space.uncommitted_size()); > > Just expanding eden space may go against the option `SurvivorRatio`. Indeed; this happens when young-gen is still not empty after full-gc -- this is kind of an extreme scenario. Given there can be live objs inside survivor/eden, the only safe way to expand is to expand eden, as it's the final space in the new layout. Consequently, `DefNewGeneration::max_capacity` is updated to ensure `capacity <= max_capacity`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27513#discussion_r2386982306 From ayang at openjdk.org Mon Sep 29 07:51:19 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 29 Sep 2025 07:51:19 GMT Subject: RFR: 8368842: Parallel: Refactor PCAddThreadRootsMarkingTaskClosure Message-ID: Trivial revising the signature of `PCAddThreadRootsMarkingTaskClosure` to pass `ParCompactionManager*` instead of `uint worker_id` as the constructor arg. Test: tier1 ------------- Commit messages: - pgc-full-gc-refactor Changes: https://git.openjdk.org/jdk/pull/27541/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27541&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368842 Stats: 11 lines in 1 file changed: 0 ins; 5 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27541.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27541/head:pull/27541 PR: https://git.openjdk.org/jdk/pull/27541 From iwalulya at openjdk.org Mon Sep 29 07:54:42 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 29 Sep 2025 07:54:42 GMT Subject: RFR: 8071277: G1: Merge commits and uncommits of contiguous memory [v3] In-Reply-To: <1MIxbJcVrqKOqS2xXyQysBL9M6HEGIT9dOHjdkICwN4=.f48899ba-2d80-488c-8221-ddb9b6211d10@github.com> References: <1MIxbJcVrqKOqS2xXyQysBL9M6HEGIT9dOHjdkICwN4=.f48899ba-2d80-488c-8221-ddb9b6211d10@github.com> Message-ID: On Sun, 28 Sep 2025 09:39:34 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change to G1 commit/uncommit to merge commit/uncommit calls to the operating system as much as possible. This significantly improves startup performanc >> >> Performance results before/after on Zen3 processor for a "HelloWorld" application: >> >> >> $ hyperfine -w 10 -r 10 "baseline/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello" >> Benchmark 1: baseline/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello >> Time (mean ? ?): 16.4 ms ? 0.4 ms [User: 11.0 ms, System: 14.4 ms] >> Range (min ? max): 15.7 ms ? 16.8 ms 10 runs >> >> $ hyperfine -w 10 -r 10 "baseline/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello" >> Benchmark 1: baseline/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello >> Time (mean ? ?): 24.7 ms ? 0.4 ms [User: 10.7 ms, System: 22.7 ms] >> Range (min ? max): 24.2 ms ? 25.4 ms 10 runs >> >> My reimplementation of JDK-8071277 does show improvements here: >> >> $ hyperfine -w 10 -r 10 "changes/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello" >> Benchmark 1: changes/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello >> Time (mean ? ?): 15.9 ms ? 0.4 ms [User: 11.9 ms, System: 13.1 ms] >> Range (min ? max): 15.4 ms ? 16.7 ms 10 runs >> >> $ hyperfine -w 10 -r 10 "changes/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello" >> Benchmark 1: changes/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello >> Time (mean ? ?): 19.7 ms ? 0.3 ms [User: 11.3 ms, System: 17.4 ms] >> Range (min ? max): 19.2 ms ? 20.1 ms 10 runs >> >> >> I.e., depending on actually committed heap size (`-Xms`), reduction of startup time by 20% or so in above cases. >> >> Testing: tier1-5, gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * ayang review, renaming Nit: src/hotspot/share/gc/g1/g1RegionToSpaceMapper.cpp line 186: > 184: page++; > 185: } > 186: return MIN2(page, end); shouldn't `page <= end` be true here? So just `return page;` ------------- Marked as reviewed by iwalulya (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27381#pullrequestreview-3278321668 PR Review Comment: https://git.openjdk.org/jdk/pull/27381#discussion_r2386988387 From fandreuzzi at openjdk.org Mon Sep 29 08:11:48 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Mon, 29 Sep 2025 08:11:48 GMT Subject: RFR: 8368842: Parallel: Refactor PCAddThreadRootsMarkingTaskClosure In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 07:43:07 GMT, Albert Mingkun Yang wrote: > Trivial revising the signature of `PCAddThreadRootsMarkingTaskClosure` to pass `ParCompactionManager*` instead of `uint worker_id` as the constructor arg. > > Test: tier1 Marked as reviewed by fandreuzzi (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/27541#pullrequestreview-3278443503 From azafari at openjdk.org Mon Sep 29 08:29:57 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 29 Sep 2025 08:29:57 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer In-Reply-To: <-Ct2yCIbRn7bSazmFKxlMPMeP85zAZk3kUfP9ele4so=.78e5ec0f-2d17-45e6-a68d-9fff149577c1@github.com> References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> <-Ct2yCIbRn7bSazmFKxlMPMeP85zAZk3kUfP9ele4so=.78e5ec0f-2d17-45e6-a68d-9fff149577c1@github.com> Message-ID: On Wed, 27 Aug 2025 14:19:23 GMT, Johan Sj?len wrote: >> The minimum acceptable value was 0 where using it as address was problematic according to UBSAN. >> The acceptable value is changed to 64K. >> >> Tests: >> linux-x64 tier1 > > It seems to me like we can fix the ubsan issue by avoiding the cast into pointers and computing through `size_t` as far as possible, and converting into pointer when necessary. > > For example > > ```c++ > size_t aligned_heap_base_min_address = align_up(HeapBaseMinAddress, alignment); > size_t noaccess_prefix = ((aligned_heap_base_min_address + size) > OopEncodingHeapMax) ? noaccess_prefix_size : 0; > > if (!FLAG_IS_DEFAULT(HeapBaseMinAddress)) { > reserved = try_reserve_memory(size + noaccess_prefix, alignment, page_size, static_cast(aligned_heap_base_min_address)); > if (reserved.base() != static_cast(aligned_heap_base_min_address)) { // Enforce this exact address. > release(reserved); > reserved = {}; > } > } > > > The semantics of reserving a `null` base address is still preserved as meaning "don't care where you put it" then. Someone from GC needs to look at this and see whether or not an undefined (implicitly 0?) HeapBaseMinAddress is meant to have that type of meaning. @jdksjolen and @xmas92, would you please check if your comments are applied here. TIA. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3345655077 From thomas.schatzl at oracle.com Mon Sep 29 09:14:26 2025 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 29 Sep 2025 11:14:26 +0200 Subject: G1 concurrent refinement regression In-Reply-To: <0e327fd3-3fc2-484f-86eb-9c4fc0b09869@gmail.com> References: <0e327fd3-3fc2-484f-86eb-9c4fc0b09869@gmail.com> Message-ID: <91888603-00f3-498e-90f9-22b50612df8f@oracle.com> Hi again, here is a more comprehensive answer using some example application: On 28.09.25 18:19, Brian S O'Neill wrote: > I'm observing an interesting regression between build 26-ea+16-1649 and > build 26-ea+17-1764 with respect to concurrent refinement. I suspect the > cause is JEP 522. > > I ran a stress test in which GC pauses are about 25ms in the steady > state. With 26-ea+16-1649, concurrent refinement is never initiated. > > With 26-ea+17-1764 (JEP 522) concurrent refinement starts after the test > has run for a few minutes. Eventually, concurrent refinement runs back > to back forever, wasting a CPU core and affecting overall performance. These concurrent refinement log messages were added with JEP 522. Previously there were no refinement logs at info level; just because there were no logs, it does not mean that no refinement happens. Typically, JEP 522 reduces refinement work by a very significant amount, making your application (typically faster). Let me show you on an example: using specjbb2015 with a fixed load as a test application (because I do not know yours), using 8 parallel gc threads and a 50ms pause time goal (to induce some more refinement activity). I used a pre-JEP 522 build (just the one before, ca182912a305e1e226d97d9613c7baf8a3d22780), and latest tip (75269fdb49aeb9d37acbbc1502c446a822fd30e3). Further, I will show results with refinement disabled (using -XX:-G1UseConcRefinement). Pause time stats: pre-522: Total: 16,062s, Avg: 50,32ms post-522: Total: 17,245s, Avg: 48,31ms no-refine: Total: 24,940s, Avg: 50,80ms Post-522 spends more time in GC (this may be due to heuristics changes since pushing it), the no-refinement build spends much more time due to more work. Additionally I obtained CPU usage per thread type periodically every 5 seconds (using "jcmd PerfCounter.print"). Let's discuss the results for the 50th occurence (~250s into the run): CPU time values are in s (I just added a comma - originally they were in ns), first is cpu time for concurrent mark, then concurrent refinement, then the parallel workers (~gc pause cpu time) and then the service thread. pre-jep522: sun.threads.cpu_time.gc_conc_mark=29,602801037 sun.threads.cpu_time.gc_conc_refine=85,135331304 sun.threads.cpu_time.gc_parallel_workers=130,768855722 sun.threads.cpu_time.gc_service=0,059843947 post-jep522: sun.threads.cpu_time.gc_conc_mark=29,524970498 sun.threads.cpu_time.gc_conc_refine=53,489763400 sun.threads.cpu_time.gc_conc_refine_control=0,777702253 sun.threads.cpu_time.gc_parallel_workers=139,873904419 sun.threads.cpu_time.gc_service=0,256793143 The first observation is that, the post-jep522 build split refinement cpu time into "conc_refine" and "conc_refine_control" threads, but that's an implementation detail - just add them together for comparison. CPU spent in concurrent marking is the same, as expected. This is a fixed load test after all. There is a significant difference in time spent in refinement between these builds. Pre-JEP 522 around 85s are spent there, around 54.5s post-JEP 522. So actually post-JEP 522 builds spend ~36% _less_ time in concurrent refinement. Post-JEP 522 spends around 7% more in garbage collection. However, summing up all components, post-JEP 522 spends around 9.7% less time in GC related activities. So it seems a win. no-refine (post-jep522 build): sun.threads.cpu_time.gc_conc_mark=29,373202848 sun.threads.cpu_time.gc_conc_refine=0 sun.threads.cpu_time.gc_conc_refine_control=0 sun.threads.cpu_time.gc_parallel_workers=152,750078728 sun.threads.cpu_time.gc_service=0,237132193 When disabling concurrent refinement as -XX:-G1UseConcRefinement does, more work is moved into the pauses. From a throughput POV it is a win, spending only ~182s in total in GC threads, vs. 223s (post-JEP 522) and 245s (pre-JEP 522). G1 then spends more time in pauses though, potentially affecting latencies more. > > [244.479s][info][gc,start??? ] GC(60) Pause Young (Normal) (G1 > Evacuation Pause) > [...]> [403.761s][info][gc,refine????? ] Concurrent Refine Complete Work 0.022ms > [403.761s][info][gc,refine????? ] Concurrent Refine Cycle 160.341ms > > The problem goes away when I set -XX:MaxGCPauseMillis=500 or higher. > Considering that the pauses are always well below the 200ms default, I'm > surprised that concurrent refinement occurs at all. As already mentioned in the other email, by default G1 allocates 10% of pause time for refinement in the pause. The rest is (attempted to be) moved out to the concurrent phase. By increasing the maximum pause time you increase that allowance. Concurrent work adds some inefficiencies depending on your application, but typically reduces time spent in pause where the application comes to a complete halt. G1 tries to provide a balance between pauses and concurrent work even when nominally it is allowed to consume 200ms per pause; the (fixed) value of -XX:G1RSetUpdatingPauseTimePercent is also likely not optimal. Still nowadays people do not really want a 200ms pause even if they implicitly allow it (by not specifying any pause time goal), so by default some concurrent refinement is enabled and often actually performed. (Fwiw, by default G1 is allowed a pause time goal of 200ms within any interval of 201ms - it is unlikely that people really want that). It would also be nice if you verified that in your test application G1 really does not do any refinement. If it really does not, it would be fairly surprising, and we would be interested in investigated this more. The logging I asked for (gc+refine=debug and gc+phases=debug) will help us to analyze what is happening in your case. (If you enabled more detailed refinement logging in the pre-JEP 522 build, I think one could also see refinement activity, i.e. use gc+refine=debug). Hth, Thomas From tschatzl at openjdk.org Mon Sep 29 09:31:16 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 29 Sep 2025 09:31:16 GMT Subject: RFR: 8071277: G1: Merge commits and uncommits of contiguous memory [v4] In-Reply-To: References: Message-ID: > Hi all, > > please review this change to G1 commit/uncommit to merge commit/uncommit calls to the operating system as much as possible. This significantly improves startup performanc > > Performance results before/after on Zen3 processor for a "HelloWorld" application: > > > $ hyperfine -w 10 -r 10 "baseline/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello" > Benchmark 1: baseline/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello > Time (mean ? ?): 16.4 ms ? 0.4 ms [User: 11.0 ms, System: 14.4 ms] > Range (min ? max): 15.7 ms ? 16.8 ms 10 runs > > $ hyperfine -w 10 -r 10 "baseline/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello" > Benchmark 1: baseline/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello > Time (mean ? ?): 24.7 ms ? 0.4 ms [User: 10.7 ms, System: 22.7 ms] > Range (min ? max): 24.2 ms ? 25.4 ms 10 runs > > My reimplementation of JDK-8071277 does show improvements here: > > $ hyperfine -w 10 -r 10 "changes/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello" > Benchmark 1: changes/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello > Time (mean ? ?): 15.9 ms ? 0.4 ms [User: 11.9 ms, System: 13.1 ms] > Range (min ? max): 15.4 ms ? 16.7 ms 10 runs > > $ hyperfine -w 10 -r 10 "changes/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello" > Benchmark 1: changes/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello > Time (mean ? ?): 19.7 ms ? 0.3 ms [User: 11.3 ms, System: 17.4 ms] > Range (min ? max): 19.2 ms ? 20.1 ms 10 runs > > > I.e., depending on actually committed heap size (`-Xms`), reduction of startup time by 20% or so in above cases. > > Testing: tier1-5, gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * walulyai review * remove debug log messages ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27381/files - new: https://git.openjdk.org/jdk/pull/27381/files/eadbba67..dbcba4dd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27381&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27381&range=02-03 Stats: 8 lines in 1 file changed: 0 ins; 7 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27381.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27381/head:pull/27381 PR: https://git.openjdk.org/jdk/pull/27381 From tschatzl at openjdk.org Mon Sep 29 09:31:19 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 29 Sep 2025 09:31:19 GMT Subject: RFR: 8071277: G1: Merge commits and uncommits of contiguous memory [v3] In-Reply-To: References: <1MIxbJcVrqKOqS2xXyQysBL9M6HEGIT9dOHjdkICwN4=.f48899ba-2d80-488c-8221-ddb9b6211d10@github.com> Message-ID: On Mon, 29 Sep 2025 07:37:30 GMT, Ivan Walulya wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * ayang review, renaming > > src/hotspot/share/gc/g1/g1RegionToSpaceMapper.cpp line 186: > >> 184: page++; >> 185: } >> 186: return MIN2(page, end); > > shouldn't `page <= end` be true here? So just `return page;` Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27381#discussion_r2387285925 From iwalulya at openjdk.org Mon Sep 29 10:10:19 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 29 Sep 2025 10:10:19 GMT Subject: RFR: 8071277: G1: Merge commits and uncommits of contiguous memory [v4] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 09:31:16 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change to G1 commit/uncommit to merge commit/uncommit calls to the operating system as much as possible. This significantly improves startup performanc >> >> Performance results before/after on Zen3 processor for a "HelloWorld" application: >> >> >> $ hyperfine -w 10 -r 10 "baseline/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello" >> Benchmark 1: baseline/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello >> Time (mean ? ?): 16.4 ms ? 0.4 ms [User: 11.0 ms, System: 14.4 ms] >> Range (min ? max): 15.7 ms ? 16.8 ms 10 runs >> >> $ hyperfine -w 10 -r 10 "baseline/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello" >> Benchmark 1: baseline/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello >> Time (mean ? ?): 24.7 ms ? 0.4 ms [User: 10.7 ms, System: 22.7 ms] >> Range (min ? max): 24.2 ms ? 25.4 ms 10 runs >> >> My reimplementation of JDK-8071277 does show improvements here: >> >> $ hyperfine -w 10 -r 10 "changes/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello" >> Benchmark 1: changes/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello >> Time (mean ? ?): 15.9 ms ? 0.4 ms [User: 11.9 ms, System: 13.1 ms] >> Range (min ? max): 15.4 ms ? 16.7 ms 10 runs >> >> $ hyperfine -w 10 -r 10 "changes/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello" >> Benchmark 1: changes/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello >> Time (mean ? ?): 19.7 ms ? 0.3 ms [User: 11.3 ms, System: 17.4 ms] >> Range (min ? max): 19.2 ms ? 20.1 ms 10 runs >> >> >> I.e., depending on actually committed heap size (`-Xms`), reduction of startup time by 20% or so in above cases. >> >> Testing: tier1-5, gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * walulyai review > * remove debug log messages Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27381#pullrequestreview-3278922330 From tschatzl at openjdk.org Mon Sep 29 10:10:19 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 29 Sep 2025 10:10:19 GMT Subject: RFR: 8071277: G1: Merge commits and uncommits of contiguous memory [v4] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 10:03:44 GMT, Ivan Walulya wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * walulyai review >> * remove debug log messages > > Marked as reviewed by iwalulya (Reviewer). Thanks @walulyai @albertnetymk for your review ------------- PR Comment: https://git.openjdk.org/jdk/pull/27381#issuecomment-3346085414 From tschatzl at openjdk.org Mon Sep 29 10:10:21 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 29 Sep 2025 10:10:21 GMT Subject: Integrated: 8071277: G1: Merge commits and uncommits of contiguous memory In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 07:01:00 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to G1 commit/uncommit to merge commit/uncommit calls to the operating system as much as possible. This significantly improves startup performanc > > Performance results before/after on Zen3 processor for a "HelloWorld" application: > > > $ hyperfine -w 10 -r 10 "baseline/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello" > Benchmark 1: baseline/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello > Time (mean ? ?): 16.4 ms ? 0.4 ms [User: 11.0 ms, System: 14.4 ms] > Range (min ? max): 15.7 ms ? 16.8 ms 10 runs > > $ hyperfine -w 10 -r 10 "baseline/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello" > Benchmark 1: baseline/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello > Time (mean ? ?): 24.7 ms ? 0.4 ms [User: 10.7 ms, System: 22.7 ms] > Range (min ? max): 24.2 ms ? 25.4 ms 10 runs > > My reimplementation of JDK-8071277 does show improvements here: > > $ hyperfine -w 10 -r 10 "changes/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello" > Benchmark 1: changes/bin/java -XX:+UseG1GC -Xms128m -Xmx128m Hello > Time (mean ? ?): 15.9 ms ? 0.4 ms [User: 11.9 ms, System: 13.1 ms] > Range (min ? max): 15.4 ms ? 16.7 ms 10 runs > > $ hyperfine -w 10 -r 10 "changes/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello" > Benchmark 1: changes/bin/java -XX:+UseG1GC -Xms2g -Xmx2g Hello > Time (mean ? ?): 19.7 ms ? 0.3 ms [User: 11.3 ms, System: 17.4 ms] > Range (min ? max): 19.2 ms ? 20.1 ms 10 runs > > > I.e., depending on actually committed heap size (`-Xms`), reduction of startup time by 20% or so in above cases. > > Testing: tier1-5, gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 08b677bb Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/08b677bba4b1e23feb55b104d86fe0eef543d59c Stats: 78 lines in 3 files changed: 33 ins; 11 del; 34 mod 8071277: G1: Merge commits and uncommits of contiguous memory Reviewed-by: iwalulya, ayang ------------- PR: https://git.openjdk.org/jdk/pull/27381 From tschatzl at openjdk.org Mon Sep 29 10:12:10 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 29 Sep 2025 10:12:10 GMT Subject: RFR: 8368842: Parallel: Refactor PCAddThreadRootsMarkingTaskClosure In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 07:43:07 GMT, Albert Mingkun Yang wrote: > Trivial revising the signature of `PCAddThreadRootsMarkingTaskClosure` to pass `ParCompactionManager*` instead of `uint worker_id` as the constructor arg. > > Test: tier1 Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27541#pullrequestreview-3278952035 From bronee at gmail.com Mon Sep 29 15:27:56 2025 From: bronee at gmail.com (Brian S O'Neill) Date: Mon, 29 Sep 2025 08:27:56 -0700 Subject: G1 concurrent refinement regression In-Reply-To: <91888603-00f3-498e-90f9-22b50612df8f@oracle.com> References: <0e327fd3-3fc2-484f-86eb-9c4fc0b09869@gmail.com> <91888603-00f3-498e-90f9-22b50612df8f@oracle.com> Message-ID: Here's the timings under ideal conditions (no logging overhead, priority boost): Pre JEP 522 no conc refinement: 499 seconds Pre JEP 522 with conc refinement: 492 seconds Post JEP 522 no conc refinement: 488 seconds Post JEP 522 with conc refinement: 518 seconds In my case it seems that with JEP 522, concurrent refinement should be disabled to see any benefit. On 2025-09-29 02:14 AM, Thomas Schatzl wrote: > Hi again, > > ? here is a more comprehensive answer using some example application: > > On 28.09.25 18:19, Brian S O'Neill wrote: >> I'm observing an interesting regression between build 26-ea+16-1649 >> and build 26-ea+17-1764 with respect to concurrent refinement. I >> suspect the cause is JEP 522. >> >> I ran a stress test in which GC pauses are about 25ms in the steady >> state. With 26-ea+16-1649, concurrent refinement is never initiated. >> >> With 26-ea+17-1764 (JEP 522) concurrent refinement starts after the >> test has run for a few minutes. Eventually, concurrent refinement runs >> back to back forever, wasting a CPU core and affecting overall >> performance. > > These concurrent refinement log messages were added with JEP 522. > Previously there were no refinement logs at info level; just because > there were no logs, it does not mean that no refinement happens. > > Typically, JEP 522 reduces refinement work by a very significant amount, > making your application (typically faster). > > Let me show you on an example: using specjbb2015 with a fixed load as a > test application (because I do not know yours), using 8 parallel gc > threads and a 50ms pause time goal (to induce some more refinement > activity). > > I used a pre-JEP 522 build (just the one before, > ca182912a305e1e226d97d9613c7baf8a3d22780), and latest tip > (75269fdb49aeb9d37acbbc1502c446a822fd30e3). Further, I will show results > with refinement disabled (using -XX:-G1UseConcRefinement). > > Pause time stats: > > pre-522:?? Total: 16,062s, Avg: 50,32ms > post-522:? Total: 17,245s, Avg: 48,31ms > no-refine: Total: 24,940s, Avg: 50,80ms > > Post-522 spends more time in GC (this may be due to heuristics changes > since pushing it), the no-refinement build spends much more time due to > more work. > > Additionally I obtained CPU usage per thread type periodically every 5 > seconds (using "jcmd PerfCounter.print"). Let's discuss the > results for the 50th occurence (~250s into the run): > > CPU time values are in s (I just added a comma - originally they were in > ns), first is cpu time for concurrent mark, then concurrent refinement, > then the parallel workers (~gc pause cpu time) and then the service thread. > > pre-jep522: > > sun.threads.cpu_time.gc_conc_mark=29,602801037 > sun.threads.cpu_time.gc_conc_refine=85,135331304 > sun.threads.cpu_time.gc_parallel_workers=130,768855722 > sun.threads.cpu_time.gc_service=0,059843947 > > post-jep522: > > sun.threads.cpu_time.gc_conc_mark=29,524970498 > sun.threads.cpu_time.gc_conc_refine=53,489763400 > sun.threads.cpu_time.gc_conc_refine_control=0,777702253 > sun.threads.cpu_time.gc_parallel_workers=139,873904419 > sun.threads.cpu_time.gc_service=0,256793143 > > The first observation is that, the post-jep522 build split refinement > cpu time into "conc_refine" and "conc_refine_control" threads, but > that's an implementation detail - just add them together for comparison. > > CPU spent in concurrent marking is the same, as expected. This is a > fixed load test after all. > > There is a significant difference in time spent in refinement between > these builds. Pre-JEP 522 around 85s are spent there, around 54.5s post- > JEP 522. > > So actually post-JEP 522 builds spend ~36% _less_ time in concurrent > refinement. > > Post-JEP 522 spends around 7% more in garbage collection. > > However, summing up all components, post-JEP 522 spends around 9.7% less > time in GC related activities. So it seems a win. > > no-refine (post-jep522 build): > > sun.threads.cpu_time.gc_conc_mark=29,373202848 > sun.threads.cpu_time.gc_conc_refine=0 > sun.threads.cpu_time.gc_conc_refine_control=0 > sun.threads.cpu_time.gc_parallel_workers=152,750078728 > sun.threads.cpu_time.gc_service=0,237132193 > > When disabling concurrent refinement as -XX:-G1UseConcRefinement does, > more work is moved into the pauses. From a throughput POV it is a win, > spending only ~182s in total in GC threads, vs. 223s (post-JEP 522) and > 245s (pre-JEP 522). > > G1 then spends more time in pauses though, potentially affecting > latencies more. > >> >> [244.479s][info][gc,start??? ] GC(60) Pause Young (Normal) (G1 >> Evacuation Pause) > > [...]> [403.761s][info][gc,refine????? ] Concurrent Refine Complete > Work 0.022ms >> [403.761s][info][gc,refine????? ] Concurrent Refine Cycle 160.341ms >> >> The problem goes away when I set -XX:MaxGCPauseMillis=500 or higher. >> Considering that the pauses are always well below the 200ms default, >> I'm surprised that concurrent refinement occurs at all. > > As already mentioned in the other email, by default G1 allocates 10% of > pause time for refinement in the pause. The rest is (attempted to be) > moved out to the concurrent phase. By increasing the maximum pause time > you increase that allowance. > > Concurrent work adds some inefficiencies depending on your application, > but typically reduces time spent in pause where the application comes to > a complete halt. > > G1 tries to provide a balance between pauses and concurrent work even > when nominally it is allowed to consume 200ms per pause; the (fixed) > value of -XX:G1RSetUpdatingPauseTimePercent is also likely not optimal. > > Still nowadays people do not really want a 200ms pause even if they > implicitly allow it (by not specifying any pause time goal), so by > default some concurrent refinement is enabled and often actually performed. > > (Fwiw, by default G1 is allowed a pause time goal of 200ms within any > interval of 201ms - it is unlikely that people really want that). > > It would also be nice if you verified that in your test application G1 > really does not do any refinement. If it really does not, it would be > fairly surprising, and we would be interested in investigated this more. > > The logging I asked for (gc+refine=debug and gc+phases=debug) will help > us to analyze what is happening in your case. > > (If you enabled more detailed refinement logging in the pre-JEP 522 > build, I think one could also see refinement activity, i.e. use > gc+refine=debug). > > Hth, > ? Thomas From wkemper at openjdk.org Mon Sep 29 16:43:38 2025 From: wkemper at openjdk.org (William Kemper) Date: Mon, 29 Sep 2025 16:43:38 GMT Subject: RFR: 8358735: GenShen: bug in #undef'd code in block_start() In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 20:12:49 GMT, Kelvin Nilsen wrote: > When scanning a range of dirty cards within the GenShen remembered set, we need to find the object that spans the beginning of the left-most dirty card. The existing code is not reliable following class unloading. > > The new code uses the marking context when it is available to determine the location of live objects that reside below TAMS within each region. Above TAMS, all objects are presumed live and parsable. src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.hpp line 132: > 130: > 131: // Search for last one in the range [l_index, r_index). Return r_index if not found. > 132: inline idx_t get_prev_one_offset (idx_t l_index, idx_t r_index) const; Nit: Some idiosyncratic formatting here (space before opening parenthesis). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27353#discussion_r2388596886 From wkemper at openjdk.org Mon Sep 29 16:49:37 2025 From: wkemper at openjdk.org (William Kemper) Date: Mon, 29 Sep 2025 16:49:37 GMT Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need accurate live_data [v9] In-Reply-To: <8GvpkoZ5-Pso8XG-AKeR0QnlBQr0op9E-lvQMS12lTI=.6c88343d-4c74-4f29-a528-f499f559a2bd@github.com> References: <8GvpkoZ5-Pso8XG-AKeR0QnlBQr0op9E-lvQMS12lTI=.6c88343d-4c74-4f29-a528-f499f559a2bd@github.com> Message-ID: On Tue, 16 Sep 2025 21:29:34 GMT, Kelvin Nilsen wrote: >> The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected. In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region. This is typically ok for young regions, where the amount of live data determines whether a region should be added to the collection set during the final-mark safepoint. >> >> However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated. In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended. >> >> This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > Fix compilation errors after merge Suggest a small refactoring to reduce code duplication. src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 91: > 89: } > 90: > 91: // Between consecutive mixed-evacuation cycles, the live data within each candidate region may change due to I think we could reduce some duplication and call `recalibrate_old_collection_candidates_live_memory` here if the function didn't have the side effect of updating `_live_bytes_in_unprocessed_candidates`. Perhaps the function could return `total_live_data` and be `const`? ------------- Changes requested by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24319#pullrequestreview-3231974347 PR Review Comment: https://git.openjdk.org/jdk/pull/24319#discussion_r2353850889 From xpeng at openjdk.org Mon Sep 29 20:28:15 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 29 Sep 2025 20:28:15 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v3] In-Reply-To: References: Message-ID: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of mutator memory allocation to improve heap lock contention, at vey high level, here is how it works: > * ShenandoahFreeSet holds a N (default to 13) number of ShenandoahHeapRegion* which are used by mutator threads for regular object allocations, they are called shared regions/directly allocatable regions, which are stored in PaddedEnd data structure(padded array). > * Each mutator thread will be assigned one of the directly allocatable regions, the thread will try to allocate in the directly allocatable region with CAS atomic operation, if fails will try 2 more consecutive directly allocatable regions in the array storing directly allocatable region. > * If mutator thread fails after trying 3 directly allocatable regions, it will: > * Take heap lock > * Try to retire the directly allocatable regions which are ready to retire. > * Iterator mutator partition and allocate directly allocatable regions and store to the padded array if any need to be retired. > * Satisfy mutator allocation request if possible. > > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, I have done many tests, here are some of them: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores: > Openjdk TIP: > > [ec2-user at ip-172-31-42-91 jdk]$ ./master-jdk/bin/java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms4G -Xmx4G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > ===== DaCapo tail latency, metered full smoothing: 50% 131684 usec, 90% 200192 usec, 99% 211369 usec, 99.9% 212517 usec, 99.99% 213043 usec, max 235289 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 1568 usec, 90% 36101 usec, 99% 42172 usec, 99.9% 42928 usec, 99.99% 43100 usec, max 43305 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 52644 usec, 90% 124393 usec, 99% 137711 usec, 99.9% 139355 usec, 99.99% 139749 usec, max 146722 usec, measured over 524288 events ====... Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 133 commits: - format - Merge branch 'openjdk:master' into cas-alloc-1 - Merge branch 'openjdk:master' into cas-alloc-1 - Merge branch 'master' into cas-alloc-1 - Move ShenandoahHeapRegionIterationClosure to shenandoahFreeSet.hpp - Merge branch 'openjdk:master' into cas-alloc-1 - Fix errors caused by renaming ofAtomic to AtomicAccess - Merge branch 'openjdk:master' into cas-alloc-1 - Remove unused flag - Merge branch 'openjdk:master' into cas-alloc-1 - ... and 123 more: https://git.openjdk.org/jdk/compare/2f29b3f2...6bd38d61 ------------- Changes: https://git.openjdk.org/jdk/pull/26171/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=02 Stats: 735 lines in 16 files changed: 674 ins; 7 del; 54 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From kdnilsen at openjdk.org Mon Sep 29 21:19:19 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 29 Sep 2025 21:19:19 GMT Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in ShenandoahFreeSet [v8] In-Reply-To: References: Message-ID: > This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet. In the new code, we keep a single tally of relevant information within ShenandoahFreeSet. > Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet. > > This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies. These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms. > > The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: more cosmetic improvements for used ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26867/files - new: https://git.openjdk.org/jdk/pull/26867/files/144ace0b..01229f45 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=06-07 Stats: 50 lines in 8 files changed: 25 ins; 21 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26867.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26867/head:pull/26867 PR: https://git.openjdk.org/jdk/pull/26867 From wkemper at openjdk.org Mon Sep 29 21:31:27 2025 From: wkemper at openjdk.org (William Kemper) Date: Mon, 29 Sep 2025 21:31:27 GMT Subject: RFR: 8368501: Shenandoah: GC progress evaluation does not use generation Message-ID: Remove unused `generation` parameter from stop-the-world GC progress evaluation. Also, have `shMetrics` use the freeset for `usage` details. This is a follow up to a comment from an unrelated PR: https://github.com/openjdk/jdk/pull/27456#issuecomment-3325724362. ------------- Commit messages: - Have stw progress evaluation just use the free set - Use collected generation to assess "used" progress Changes: https://git.openjdk.org/jdk/pull/27561/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27561&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368501 Stats: 79 lines in 4 files changed: 6 ins; 37 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/27561.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27561/head:pull/27561 PR: https://git.openjdk.org/jdk/pull/27561 From kdnilsen at openjdk.org Mon Sep 29 23:09:45 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 29 Sep 2025 23:09:45 GMT Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in ShenandoahFreeSet [v9] In-Reply-To: References: Message-ID: > This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet. In the new code, we keep a single tally of relevant information within ShenandoahFreeSet. > Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet. > > This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies. These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms. > > The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: cosmetic miprovements for bytes_allocated_since_gc_start() and get_affiliated_region_count() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26867/files - new: https://git.openjdk.org/jdk/pull/26867/files/01229f45..8a0cee03 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=07-08 Stats: 94 lines in 8 files changed: 63 ins; 30 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26867.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26867/head:pull/26867 PR: https://git.openjdk.org/jdk/pull/26867 From ayang at openjdk.org Tue Sep 30 08:23:00 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 30 Sep 2025 08:23:00 GMT Subject: RFR: 8368599: ShenandoahConcurrentMark could use ThreadsClaimTokenScope [v2] In-Reply-To: References: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com> Message-ID: On Thu, 25 Sep 2025 14:16:43 GMT, Aleksey Shipilev wrote: >> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: >> >> as field > > Hold on a second. > > > class StrongRootsScope : public MarkScope { > > > ...and: > > > MarkScope::MarkScope() { > nmethod::oops_do_marking_prologue(); > } > > MarkScope::~MarkScope() { > nmethod::oops_do_marking_epilogue(); > } > > > So, what calls `nmethod::oops_do_marking_prologue`/`epilogue`, and do we know it is (not) needed? @shipilev Is the above explanation enough? If so, hopefully, this PR can be merged to unblock further cleanups around `StrongRootsScope`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27477#issuecomment-3350610528 From tschatzl at openjdk.org Tue Sep 30 08:48:44 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 30 Sep 2025 08:48:44 GMT Subject: RFR: 8363932: G1: Better distribute KlassCleaningTask [v2] In-Reply-To: References: <4wv4YEc8jXOrh142RF4lbiAOx5HSEe8tcDc-BYQC-5I=.461e968b-21dd-493e-9dfb-dcc9f962700a@github.com> Message-ID: On Mon, 29 Sep 2025 20:36:35 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * ayang review > > Marked as reviewed by ayang (Reviewer). Thanks @albertnetymk @coleenp for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/27316#issuecomment-3350740673 From thomas.schatzl at oracle.com Tue Sep 30 08:51:01 2025 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 30 Sep 2025 10:51:01 +0200 Subject: G1 concurrent refinement regression In-Reply-To: References: <0e327fd3-3fc2-484f-86eb-9c4fc0b09869@gmail.com> <91888603-00f3-498e-90f9-22b50612df8f@oracle.com> Message-ID: Hi Brian, On 29.09.25 17:27, Brian S O'Neill wrote: > Here's the timings under ideal conditions (no logging overhead, priority > boost): > > Pre JEP 522 no conc refinement:??? 499 seconds > Pre JEP 522 with conc refinement:? 492 seconds > Post JEP 522 no conc refinement:?? 488 seconds > Post JEP 522 with conc refinement: 518 seconds > > In my case it seems that with JEP 522, concurrent refinement should be > disabled to see any benefit. Filed https://bugs.openjdk.org/browse/JDK-8368935. It indeed seems like this is a stress test; from the attached logs (thanks) I can see that the test apparently over and over again marks (mostly) single cards in the card table by adding a reference and then clearing them (nulling) again. G1's card marking activity monitoring just sees the constant re-marking indicated by the large mark rate. After refinement cleared all the cards, repeat. There is basically no other activity. We'll see if we can improve this kind of application. We were planning on decreasing refinement activity anyway. Maybe, since it's a stress test, you can share it? Thanks, Thomas From tschatzl at openjdk.org Tue Sep 30 08:51:55 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 30 Sep 2025 08:51:55 GMT Subject: Integrated: 8363932: G1: Better distribute KlassCleaningTask In-Reply-To: <4wv4YEc8jXOrh142RF4lbiAOx5HSEe8tcDc-BYQC-5I=.461e968b-21dd-493e-9dfb-dcc9f962700a@github.com> References: <4wv4YEc8jXOrh142RF4lbiAOx5HSEe8tcDc-BYQC-5I=.461e968b-21dd-493e-9dfb-dcc9f962700a@github.com> Message-ID: <46A0boaLdRkCJRykJbOKjkjYQtPEtq2AA6b6lJvSLS4=.7c79f287-81b7-421b-a45c-906b50eef65c@github.com> On Tue, 16 Sep 2025 15:54:19 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to parallel klass cleaning to improve performance. > > The current implementation only parallelizes cleaning of weak class links, while the main work, cleaning the object tree is single-threaded. Hence in practice, the current mechanism does not scale beyond 2-3 threads. > > Cleaning an object graph in an application that loads some jars and instantiates central classes within them, with around 180k classes the current `G1 Complete Cleaning` task (which executes this code) can take 80ms (with 25 threads). > > The suggested change is to walk the object graph by (live) `ClassLoaderData` klass by klass, fixing only the links of that particular klass. > > E.g. > > CLD1 has klasses A, B, C, CLD2 has klasses a, b, c and CLD3 has klasses 0, 1, 2, 4; > vertical links are subklass references, while horizontal links are sibling references. > > j.l.O > | > A - B - c - 3 > | > 0 - 2 - C - 1 > > > CLD 3 is dead. Thread 1 claims CLD 1, Thread 2 claims CLD 2 (and nobody claims CLD3 because it's dead). > > So thread 1, when reaching `A` fixes its subklass link to `C`, and otherwise does nothing with `A`. When looking at `C`, it will remove the link to `1`. > Thread 2 will only remove the link to `3` of `c`. > > The result is > > j.l.O > | > A - B - c > | > C > > > There should be no unnecessary object graph walking. > > There is a slight change in printing during unlinking: previously the code, when cleaning subklasses it printed `unlinking class (subclass)`for every class that has been removed on the way to the next live one. In above case, it would print > > > unlinking class (subclass): 0 > unlinking class (subclass): 2 > > > With the change, to avoid following the subklasses of the graph twice, it prints > > > ?unlinking class (subclass): 0 > unlinking class (sibling): 0 > > > because the string in brackets is the actual link that is followed. I can revert that change. > > With the change "Complete Cleaning" time for 200k classes takes 7.6ms (The test is a bit random on when it does the class unloading). > > Testing: tier1-5 > > Thanks, > Thomas This pull request has now been integrated. Changeset: 586167cf Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/586167cff5aaead0949c509f48bc5080834cc362 Stats: 116 lines in 7 files changed: 6 ins; 61 del; 49 mod 8363932: G1: Better distribute KlassCleaningTask Reviewed-by: ayang, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/27316 From tschatzl at openjdk.org Tue Sep 30 11:38:44 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 30 Sep 2025 11:38:44 GMT Subject: RFR: 8368954: G1: Document why G1 uses TLS storage for the current card table reference Message-ID: Hi all, please review some documentation update why G1 now uses TLS storage to get the current card table base value for the card mark. TLDR: it's the overall fastest currently available way. Testing: local compilation, this is just a trivial documentation change. Thanks, Thomas ------------- Commit messages: - 8368954 Changes: https://git.openjdk.org/jdk/pull/27573/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27573&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368954 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27573.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27573/head:pull/27573 PR: https://git.openjdk.org/jdk/pull/27573 From tschatzl at openjdk.org Tue Sep 30 11:50:04 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 30 Sep 2025 11:50:04 GMT Subject: RFR: 8368953: Document the reason why Serial/Parallel/G1 use zero as dirty card value Message-ID: <52vrwVAnYa__vQf-giR4Yb3G_NWFfArR_LtLXW-syX0=.eafffb44-6c22-4551-b484-06031adf30ae@github.com> Hi all, please review this trivial change to document the reason for the dirty/clean card value selection. Testing: local compilation Thanks, Thomas ------------- Commit messages: - 8368953 Changes: https://git.openjdk.org/jdk/pull/27575/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27575&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368953 Stats: 13 lines in 1 file changed: 13 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27575.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27575/head:pull/27575 PR: https://git.openjdk.org/jdk/pull/27575 From rcastanedalo at openjdk.org Tue Sep 30 11:54:20 2025 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Tue, 30 Sep 2025 11:54:20 GMT Subject: RFR: 8368954: G1: Document why G1 uses TLS storage for the current card table reference In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 11:27:46 GMT, Thomas Schatzl wrote: > Hi all, > > please review some documentation update why G1 now uses TLS storage to get the current card table base value for the card mark. > > TLDR: it's the overall fastest currently available way. > > Testing: local compilation, this is just a trivial documentation change. > > Thanks, > Thomas Marked as reviewed by rcastanedalo (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27573#pullrequestreview-3284279712 From iwalulya at openjdk.org Tue Sep 30 12:16:18 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 30 Sep 2025 12:16:18 GMT Subject: RFR: 8368954: G1: Document why G1 uses TLS storage for the current card table reference In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 11:27:46 GMT, Thomas Schatzl wrote: > Hi all, > > please review some documentation update why G1 now uses TLS storage to get the current card table base value for the card mark. > > TLDR: it's the overall fastest currently available way. > > Testing: local compilation, this is just a trivial documentation change. > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27573#pullrequestreview-3284371916 From iwalulya at openjdk.org Tue Sep 30 12:17:26 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 30 Sep 2025 12:17:26 GMT Subject: RFR: 8368953: Document the reason why Serial/Parallel/G1 use zero as dirty card value In-Reply-To: <52vrwVAnYa__vQf-giR4Yb3G_NWFfArR_LtLXW-syX0=.eafffb44-6c22-4551-b484-06031adf30ae@github.com> References: <52vrwVAnYa__vQf-giR4Yb3G_NWFfArR_LtLXW-syX0=.eafffb44-6c22-4551-b484-06031adf30ae@github.com> Message-ID: <4bZVMoroa4XjtZ_y2JhNC-OrBmzIYNAub79Mq3YuIOM=.264de427-e23a-4be9-9115-0da76236b92b@github.com> On Tue, 30 Sep 2025 11:43:10 GMT, Thomas Schatzl wrote: > Hi all, > > please review this trivial change to document the reason for the dirty/clean card value selection. > > Testing: local compilation > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27575#pullrequestreview-3284374275 From ayang at openjdk.org Tue Sep 30 12:27:41 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 30 Sep 2025 12:27:41 GMT Subject: RFR: 8368842: Parallel: Refactor PCAddThreadRootsMarkingTaskClosure In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 07:43:07 GMT, Albert Mingkun Yang wrote: > Trivial revising the signature of `PCAddThreadRootsMarkingTaskClosure` to pass `ParCompactionManager*` instead of `uint worker_id` as the constructor arg. > > Test: tier1 Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27541#issuecomment-3351799109 From ayang at openjdk.org Tue Sep 30 12:30:56 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 30 Sep 2025 12:30:56 GMT Subject: Integrated: 8368842: Parallel: Refactor PCAddThreadRootsMarkingTaskClosure In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 07:43:07 GMT, Albert Mingkun Yang wrote: > Trivial revising the signature of `PCAddThreadRootsMarkingTaskClosure` to pass `ParCompactionManager*` instead of `uint worker_id` as the constructor arg. > > Test: tier1 This pull request has now been integrated. Changeset: 444007fc Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/444007fc234aeff75025831c2d1b5538c87fa8f1 Stats: 11 lines in 1 file changed: 0 ins; 5 del; 6 mod 8368842: Parallel: Refactor PCAddThreadRootsMarkingTaskClosure Reviewed-by: fandreuzzi, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/27541 From ayang at openjdk.org Tue Sep 30 12:47:46 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 30 Sep 2025 12:47:46 GMT Subject: RFR: 8368953: Document the reason why Serial/Parallel/G1 use zero as dirty card value In-Reply-To: <52vrwVAnYa__vQf-giR4Yb3G_NWFfArR_LtLXW-syX0=.eafffb44-6c22-4551-b484-06031adf30ae@github.com> References: <52vrwVAnYa__vQf-giR4Yb3G_NWFfArR_LtLXW-syX0=.eafffb44-6c22-4551-b484-06031adf30ae@github.com> Message-ID: On Tue, 30 Sep 2025 11:43:10 GMT, Thomas Schatzl wrote: > Hi all, > > please review this trivial change to document the reason for the dirty/clean card value selection. > > Testing: local compilation > > Thanks, > Thomas src/hotspot/share/gc/shared/cardTable.hpp line 64: > 62: inline size_t compute_byte_map_size(size_t num_bytes); > 63: > 64: // We use 0x00 (zero) as "dirty" and 0xff as "clean" because this reduces the I think the first sentence can be a bit misleading -- it should be quantified to "certain architectures". This saving-by-one-instruction is not universal. Suggestion: "We use 0x00 (zero) to represent dirty and 0xFF to represent clean because this choice reduces the barrier code by one instruction on architectures with a constant-zero register. On such architectures, the dirty value (0x00) is directly accessible through the zero register, eliminating the need to load the value explicitly and thereby saving one instruction." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27575#discussion_r2391293974 From tschatzl at openjdk.org Tue Sep 30 13:15:57 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 30 Sep 2025 13:15:57 GMT Subject: RFR: 8368953: Document the reason why Serial/Parallel/G1 use zero as dirty card value [v2] In-Reply-To: <52vrwVAnYa__vQf-giR4Yb3G_NWFfArR_LtLXW-syX0=.eafffb44-6c22-4551-b484-06031adf30ae@github.com> References: <52vrwVAnYa__vQf-giR4Yb3G_NWFfArR_LtLXW-syX0=.eafffb44-6c22-4551-b484-06031adf30ae@github.com> Message-ID: > Hi all, > > please review this trivial change to document the reason for the dirty/clean card value selection. > > Testing: local compilation > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision: - Update src/hotspot/share/gc/shared/cardTable.hpp - Update src/hotspot/share/gc/shared/cardTable.hpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27575/files - new: https://git.openjdk.org/jdk/pull/27575/files/d103feb7..cef01833 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27575&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27575&range=00-01 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27575.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27575/head:pull/27575 PR: https://git.openjdk.org/jdk/pull/27575 From tschatzl at openjdk.org Tue Sep 30 13:15:58 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 30 Sep 2025 13:15:58 GMT Subject: RFR: 8368953: Document the reason why Serial/Parallel/G1 use zero as dirty card value [v2] In-Reply-To: References: <52vrwVAnYa__vQf-giR4Yb3G_NWFfArR_LtLXW-syX0=.eafffb44-6c22-4551-b484-06031adf30ae@github.com> Message-ID: On Tue, 30 Sep 2025 13:12:45 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this trivial change to document the reason for the dirty/clean card value selection. >> >> Testing: local compilation >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision: > > - Update src/hotspot/share/gc/shared/cardTable.hpp > - Update src/hotspot/share/gc/shared/cardTable.hpp src/hotspot/share/gc/shared/cardTable.hpp line 67: > 65: // barrier code by one instruction. Many architectures have a constant-zero > 66: // register that can be used for the store, so the dirty value does not need > 67: // to be explicitly loaded. Suggestion: // We use 0x00 (zero) to represent dirty and 0xFF to represent clean because // this choice reduces the barrier code by one instruction on architectures with // a constant-zero register. On such architectures, the dirty value (0x00) is // directly accessible through the zero register, eliminating the need to load // the value explicitly and thereby saving one instruction src/hotspot/share/gc/shared/cardTable.hpp line 68: > 66: // a constant-zero register. On such architectures, the dirty value (0x00) is > 67: // directly accessible through the zero register, eliminating the need to load > 68: // the value explicitly and thereby saving one instruction Suggestion: // We use 0x00 (zero) to represent Dirty and 0xFF to represent Clean because // this choice reduces the barrier code by one instruction on architectures with // a constant-zero register. On such architectures, the Dirty value (0x00) is // directly accessible through the zero register, eliminating the need to load // the value explicitly and thereby saving one instruction ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27575#discussion_r2391389180 PR Review Comment: https://git.openjdk.org/jdk/pull/27575#discussion_r2391395335 From kbarrett at openjdk.org Tue Sep 30 13:58:58 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 30 Sep 2025 13:58:58 GMT Subject: RFR: 8368957: Remove metaprogramming/logical.hpp in favor of C++17 facilities Message-ID: Please review this trivial change to remove metaprogramming/logical.hpp and its associated gtest, after first updating the one lingering use. Testing: mach5 tier1 ------------- Commit messages: - remove logical.hpp and gtest - update use of Conjunction => std::conjunction Changes: https://git.openjdk.org/jdk/pull/27578/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27578&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368957 Stats: 159 lines in 3 files changed: 2 ins; 155 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27578.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27578/head:pull/27578 PR: https://git.openjdk.org/jdk/pull/27578 From mchevalier at openjdk.org Tue Sep 30 14:11:19 2025 From: mchevalier at openjdk.org (Marc Chevalier) Date: Tue, 30 Sep 2025 14:11:19 GMT Subject: RFR: 8368957: Remove metaprogramming/logical.hpp in favor of C++17 facilities In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 13:50:57 GMT, Kim Barrett wrote: > Please review this trivial change to remove metaprogramming/logical.hpp and > its associated gtest, after first updating the one lingering use. > > Testing: mach5 tier1 Marked as reviewed by mchevalier (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27578#pullrequestreview-3285096743 From iwalulya at openjdk.org Tue Sep 30 14:30:53 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 30 Sep 2025 14:30:53 GMT Subject: RFR: 8368957: Remove metaprogramming/logical.hpp in favor of C++17 facilities In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 13:50:57 GMT, Kim Barrett wrote: > Please review this trivial change to remove metaprogramming/logical.hpp and > its associated gtest, after first updating the one lingering use. > > Testing: mach5 tier1 Trivial! Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27578#pullrequestreview-3285258400 PR Review: https://git.openjdk.org/jdk/pull/27578#pullrequestreview-3285260401 From ayang at openjdk.org Tue Sep 30 15:21:06 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 30 Sep 2025 15:21:06 GMT Subject: RFR: 8368954: G1: Document why G1 uses TLS storage for the current card table reference In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 11:27:46 GMT, Thomas Schatzl wrote: > Hi all, > > please review some documentation update why G1 now uses TLS storage to get the current card table base value for the card mark. > > TLDR: it's the overall fastest currently available way. > > Testing: local compilation, this is just a trivial documentation change. > > Thanks, > Thomas src/hotspot/share/gc/g1/g1ThreadLocalData.hpp line 46: > 44: // way for fast access to this value in the barrier. > 45: // E.g. embedding an address to that value directly into the code stream similar > 46: // to Serial/Parallel and then loading from that was found to be slower at least Not sure if I misunderstood this text or not, but Serial/Parallel doesn't embed the "address" into the code stream -- they embed the actual value in the code stream, since the value (card-tabe-base) is constant. G1 can't/doesn't do that, since card-table-base is not constant. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27573#discussion_r2391992400 From tschatzl at openjdk.org Tue Sep 30 15:50:24 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 30 Sep 2025 15:50:24 GMT Subject: RFR: 8368954: G1: Document why G1 uses TLS storage for the current card table reference In-Reply-To: References: Message-ID: <9GzrKJl8FDGLkwYnvghKspevTxMz-mJItsOnLloDZ9g=.f25a22dc-e0fe-43ed-bd15-ae4667c78609@github.com> On Tue, 30 Sep 2025 15:18:51 GMT, Albert Mingkun Yang wrote: >> Hi all, >> >> please review some documentation update why G1 now uses TLS storage to get the current card table base value for the card mark. >> >> TLDR: it's the overall fastest currently available way. >> >> Testing: local compilation, this is just a trivial documentation change. >> >> Thanks, >> Thomas > > src/hotspot/share/gc/g1/g1ThreadLocalData.hpp line 46: > >> 44: // way for fast access to this value in the barrier. >> 45: // E.g. embedding an address to that value directly into the code stream similar >> 46: // to Serial/Parallel and then loading from that was found to be slower at least > > Not sure if I misunderstood this text or not, but Serial/Parallel doesn't embed the "address" into the code stream -- they embed the actual value in the code stream, since the value (card-tabe-base) is constant. G1 can't/doesn't do that, since card-table-base is not constant. But G1 can embed the address of the value in the code stream, similar to Serial/Parallel (which embed the actual base address). The emphasis should be on the embedding, not what is embedded. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27573#discussion_r2392088099 From tschatzl at openjdk.org Tue Sep 30 15:57:49 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 30 Sep 2025 15:57:49 GMT Subject: RFR: 8236073: G1: Use SoftMaxHeapSize to guide GC heuristics [v3] In-Reply-To: <8jjBh52pZlAjsLJ4ce1oacnDVdu8qCe2pJYApXsU5HM=.462adbdd-e3b7-4d4a-a130-aecadba36b00@github.com> References: <8jjBh52pZlAjsLJ4ce1oacnDVdu8qCe2pJYApXsU5HM=.462adbdd-e3b7-4d4a-a130-aecadba36b00@github.com> Message-ID: > Hi all, > > please review this change to implement `SoftMaxHeapSize` for G1. > > Main change is that `SoftMaxHeapSize` now impacts the `G1IHOPControl::target_occupancy()`, i.e. the amount of bytes G1 when reclaim should start. > > Most of the other changes are just about updating logging/JFR and making sure that the `SoftMaxHeapSize` values are consistent across calls. > > Testing: tier1-5 > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * fix whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27524/files - new: https://git.openjdk.org/jdk/pull/27524/files/ec1ccb7f..390e70ca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27524&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27524&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27524.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27524/head:pull/27524 PR: https://git.openjdk.org/jdk/pull/27524 From ayang at openjdk.org Tue Sep 30 16:00:26 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 30 Sep 2025 16:00:26 GMT Subject: RFR: 8368954: G1: Document why G1 uses TLS storage for the current card table reference In-Reply-To: <8PSLxX7FDRvwr6eMTpp2JpDspk3AwRoYTdNaY_y8Y1M=.750b6877-ec2c-4b44-b778-eb4a1698c292@github.com> References: <9GzrKJl8FDGLkwYnvghKspevTxMz-mJItsOnLloDZ9g=.f25a22dc-e0fe-43ed-bd15-ae4667c78609@github.com> <8PSLxX7FDRvwr6eMTpp2JpDspk3AwRoYTdNaY_y8Y1M=.750b6877-ec2c-4b44-b778-eb4a1698c292@github.com> Message-ID: <1Fs4Xum9gqCgSYBuo2hr-BZPBJ-2fbG2b7ummLAhqtA=.d2244693-93d1-404e-b61a-f4336f69dcf6@github.com> On Tue, 30 Sep 2025 15:55:23 GMT, Thomas Schatzl wrote: >> But G1 can embed the address of the value in the code stream, similar to Serial/Parallel (which embed the actual base address). The emphasis should be on the embedding, not what is embedded. > > maybe just remove the "an address" to avoid the confusion? It's my misunderstanding then. How about just dropping "similar to Serial/Parallel"? I don't see any benefit of referencing them here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27573#discussion_r2392112959 From tschatzl at openjdk.org Tue Sep 30 16:00:26 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 30 Sep 2025 16:00:26 GMT Subject: RFR: 8368954: G1: Document why G1 uses TLS storage for the current card table reference In-Reply-To: <9GzrKJl8FDGLkwYnvghKspevTxMz-mJItsOnLloDZ9g=.f25a22dc-e0fe-43ed-bd15-ae4667c78609@github.com> References: <9GzrKJl8FDGLkwYnvghKspevTxMz-mJItsOnLloDZ9g=.f25a22dc-e0fe-43ed-bd15-ae4667c78609@github.com> Message-ID: <8PSLxX7FDRvwr6eMTpp2JpDspk3AwRoYTdNaY_y8Y1M=.750b6877-ec2c-4b44-b778-eb4a1698c292@github.com> On Tue, 30 Sep 2025 15:46:55 GMT, Thomas Schatzl wrote: >> src/hotspot/share/gc/g1/g1ThreadLocalData.hpp line 46: >> >>> 44: // way for fast access to this value in the barrier. >>> 45: // E.g. embedding an address to that value directly into the code stream similar >>> 46: // to Serial/Parallel and then loading from that was found to be slower at least >> >> Not sure if I misunderstood this text or not, but Serial/Parallel doesn't embed the "address" into the code stream -- they embed the actual value in the code stream, since the value (card-tabe-base) is constant. G1 can't/doesn't do that, since card-table-base is not constant. > > But G1 can embed the address of the value in the code stream, similar to Serial/Parallel (which embed the actual base address). The emphasis should be on the embedding, not what is embedded. maybe just remove the "an address" to avoid the confusion? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27573#discussion_r2392110354 From ayang at openjdk.org Tue Sep 30 16:00:27 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 30 Sep 2025 16:00:27 GMT Subject: RFR: 8368954: G1: Document why G1 uses TLS storage for the current card table reference In-Reply-To: <1Fs4Xum9gqCgSYBuo2hr-BZPBJ-2fbG2b7ummLAhqtA=.d2244693-93d1-404e-b61a-f4336f69dcf6@github.com> References: <9GzrKJl8FDGLkwYnvghKspevTxMz-mJItsOnLloDZ9g=.f25a22dc-e0fe-43ed-bd15-ae4667c78609@github.com> <8PSLxX7FDRvwr6eMTpp2JpDspk3AwRoYTdNaY_y8Y1M=.750b6877-ec2c-4b44-b778-eb4a1698c292@github.com> <1Fs4Xum9gqCgSYBuo2hr-BZPBJ-2fbG2b7ummLAhqtA=.d2244693-93d1-404e-b61a-f4336f69dcf6@github.com> Message-ID: On Tue, 30 Sep 2025 15:56:21 GMT, Albert Mingkun Yang wrote: >> maybe just remove the "an address" to avoid the confusion? > > It's my misunderstanding then. How about just dropping "similar to Serial/Parallel"? I don't see any benefit of referencing them here. > maybe just remove the "an address" to avoid the confusion? I think you need the "address" to connect with the latter "loading from that" -- "that" refers to the "address", doesn't it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27573#discussion_r2392117452 From tschatzl at openjdk.org Tue Sep 30 16:11:36 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 30 Sep 2025 16:11:36 GMT Subject: RFR: 8368954: G1: Document why G1 uses TLS storage for the current card table reference [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review some documentation update why G1 now uses TLS storage to get the current card table base value for the card mark. > > TLDR: it's the overall fastest currently available way. > > Testing: local compilation, this is just a trivial documentation change. > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/share/gc/g1/g1ThreadLocalData.hpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27573/files - new: https://git.openjdk.org/jdk/pull/27573/files/bf0f553e..bfc4d1e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27573&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27573&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27573.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27573/head:pull/27573 PR: https://git.openjdk.org/jdk/pull/27573 From tschatzl at openjdk.org Tue Sep 30 16:11:37 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 30 Sep 2025 16:11:37 GMT Subject: RFR: 8368954: G1: Document why G1 uses TLS storage for the current card table reference [v2] In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 16:07:47 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review some documentation update why G1 now uses TLS storage to get the current card table base value for the card mark. >> >> TLDR: it's the overall fastest currently available way. >> >> Testing: local compilation, this is just a trivial documentation change. >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/share/gc/g1/g1ThreadLocalData.hpp src/hotspot/share/gc/g1/g1ThreadLocalData.hpp line 47: > 45: // E.g. embedding an address to that value directly into the code stream similar > 46: // to Serial/Parallel and then loading from that was found to be slower at least > 47: // on non-x64, and increases code size a lot. Suggestion: // Tests showed that embedding this value in the TLS block is the cheapest // way for fast access to this value in the barrier. // E.g. embedding an address to that value directly into the code stream and // then loading from that was found to be slower on non-x64 architectures. // Additionally it increases code size a lot. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27573#discussion_r2392134663 From shade at openjdk.org Tue Sep 30 16:18:35 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 30 Sep 2025 16:18:35 GMT Subject: RFR: 8368599: ShenandoahConcurrentMark could use ThreadsClaimTokenScope [v2] In-Reply-To: References: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com> Message-ID: On Thu, 25 Sep 2025 11:00:18 GMT, Francesco Andreuzzi wrote: >> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `ShenandoahConcurrentMark::finish_mark_work` to be more precise with what is actually needed and why. Similar to #27385. >> >> Test: tier1, and tier[1,2,3]_gc_shenandoah > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > as field OK, fine. I see `ShenandoahSTWMark` still uses `StrongRootsScope`, which answers my question. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27477#pullrequestreview-3285772695 From fandreuzzi at openjdk.org Tue Sep 30 16:18:36 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Tue, 30 Sep 2025 16:18:36 GMT Subject: Integrated: 8368599: ShenandoahConcurrentMark could use ThreadsClaimTokenScope In-Reply-To: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com> References: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com> Message-ID: On Wed, 24 Sep 2025 22:37:44 GMT, Francesco Andreuzzi wrote: > Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `ShenandoahConcurrentMark::finish_mark_work` to be more precise with what is actually needed and why. Similar to #27385. > > Test: tier1, and tier[1,2,3]_gc_shenandoah This pull request has now been integrated. Changeset: fe9dbcc4 Author: Francesco Andreuzzi Committer: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/fe9dbcc496671a256c61ac52df5580569dbafb0a Stats: 5 lines in 1 file changed: 2 ins; 2 del; 1 mod 8368599: ShenandoahConcurrentMark could use ThreadsClaimTokenScope Reviewed-by: ayang, shade, wkemper ------------- PR: https://git.openjdk.org/jdk/pull/27477 From kdnilsen at openjdk.org Tue Sep 30 16:38:08 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 30 Sep 2025 16:38:08 GMT Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in ShenandoahFreeSet [v10] In-Reply-To: References: Message-ID: > This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet. In the new code, we keep a single tally of relevant information within ShenandoahFreeSet. > Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet. > > This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies. These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms. > > The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: OO improvements to get_humongous_waste() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26867/files - new: https://git.openjdk.org/jdk/pull/26867/files/8a0cee03..cbe83407 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=08-09 Stats: 48 lines in 8 files changed: 31 ins; 16 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26867.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26867/head:pull/26867 PR: https://git.openjdk.org/jdk/pull/26867 From kdnilsen at openjdk.org Tue Sep 30 16:58:47 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 30 Sep 2025 16:58:47 GMT Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in ShenandoahFreeSet [v11] In-Reply-To: References: Message-ID: > This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet. In the new code, we keep a single tally of relevant information within ShenandoahFreeSet. > Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet. > > This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies. These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms. > > The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: OO refinements to used_regions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26867/files - new: https://git.openjdk.org/jdk/pull/26867/files/cbe83407..c6a51a95 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=09-10 Stats: 34 lines in 6 files changed: 13 ins; 14 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/26867.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26867/head:pull/26867 PR: https://git.openjdk.org/jdk/pull/26867 From ayang at openjdk.org Tue Sep 30 19:16:37 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 30 Sep 2025 19:16:37 GMT Subject: RFR: 8368954: G1: Document why G1 uses TLS storage for the current card table reference [v2] In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 16:11:36 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review some documentation update why G1 now uses TLS storage to get the current card table base value for the card mark. >> >> TLDR: it's the overall fastest currently available way. >> >> Testing: local compilation, this is just a trivial documentation change. >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/share/gc/g1/g1ThreadLocalData.hpp Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27573#pullrequestreview-3286383685 From ayang at openjdk.org Tue Sep 30 19:16:37 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 30 Sep 2025 19:16:37 GMT Subject: RFR: 8368953: Document the reason why Serial/Parallel/G1 use zero as dirty card value [v2] In-Reply-To: References: <52vrwVAnYa__vQf-giR4Yb3G_NWFfArR_LtLXW-syX0=.eafffb44-6c22-4551-b484-06031adf30ae@github.com> Message-ID: <9E5nTM1Kfguvi18JFVNgIhF1eWE-Zp0JByAmAaqIYvI=.95247849-90a8-4c2b-a46f-52756778917a@github.com> On Tue, 30 Sep 2025 13:15:57 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this trivial change to document the reason for the dirty/clean card value selection. >> >> Testing: local compilation >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision: > > - Update src/hotspot/share/gc/shared/cardTable.hpp > - Update src/hotspot/share/gc/shared/cardTable.hpp Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27575#pullrequestreview-3286384640 From tschatzl at openjdk.org Tue Sep 30 19:32:37 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 30 Sep 2025 19:32:37 GMT Subject: RFR: 8236073: G1: Use SoftMaxHeapSize to guide GC heuristics [v4] In-Reply-To: <8jjBh52pZlAjsLJ4ce1oacnDVdu8qCe2pJYApXsU5HM=.462adbdd-e3b7-4d4a-a130-aecadba36b00@github.com> References: <8jjBh52pZlAjsLJ4ce1oacnDVdu8qCe2pJYApXsU5HM=.462adbdd-e3b7-4d4a-a130-aecadba36b00@github.com> Message-ID: > Hi all, > > please review this change to implement `SoftMaxHeapSize` for G1. > > Main change is that `SoftMaxHeapSize` now impacts the `G1IHOPControl::target_occupancy()`, i.e. the amount of bytes G1 when reclaim should start. > > Most of the other changes are just about updating logging/JFR and making sure that the `SoftMaxHeapSize` values are consistent across calls. > > Testing: tier1-5 > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * align MinHeapSize to heap alignment to avoid issues with conflicting MinHeapSize and SoftMaxHeapSize ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27524/files - new: https://git.openjdk.org/jdk/pull/27524/files/390e70ca..edfcca13 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27524&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27524&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27524.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27524/head:pull/27524 PR: https://git.openjdk.org/jdk/pull/27524 From kdnilsen at openjdk.org Tue Sep 30 21:55:46 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 30 Sep 2025 21:55:46 GMT Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in ShenandoahFreeSet [v12] In-Reply-To: References: Message-ID: > This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet. In the new code, we keep a single tally of relevant information within ShenandoahFreeSet. > Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet. > > This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies. These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms. > > The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books. Kelvin Nilsen has updated the pull request incrementally with five additional commits since the last revision: - small refactoring - OO refinements to used_regions_size() - fix broken assert from previous commit - OO refinements to free_unaffiliated_regions() - OO refinements to max_capacity() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26867/files - new: https://git.openjdk.org/jdk/pull/26867/files/c6a51a95..43e1358f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=10-11 Stats: 147 lines in 9 files changed: 76 ins; 56 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/26867.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26867/head:pull/26867 PR: https://git.openjdk.org/jdk/pull/26867 From manc at openjdk.org Tue Sep 30 22:07:10 2025 From: manc at openjdk.org (Man Cao) Date: Tue, 30 Sep 2025 22:07:10 GMT Subject: RFR: 8236073: G1: Use SoftMaxHeapSize to guide GC heuristics [v4] In-Reply-To: References: <8jjBh52pZlAjsLJ4ce1oacnDVdu8qCe2pJYApXsU5HM=.462adbdd-e3b7-4d4a-a130-aecadba36b00@github.com> Message-ID: On Tue, 30 Sep 2025 19:32:37 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change to implement `SoftMaxHeapSize` for G1. >> >> Main change is that `SoftMaxHeapSize` now impacts the `G1IHOPControl::target_occupancy()`, i.e. the amount of bytes G1 when reclaim should start. >> >> Most of the other changes are just about updating logging/JFR and making sure that the `SoftMaxHeapSize` values are consistent across calls. >> >> Testing: tier1-5 >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * align MinHeapSize to heap alignment to avoid issues with conflicting MinHeapSize and SoftMaxHeapSize Responding to @tschatzl's comment in https://bugs.openjdk.org/browse/JDK-8236073: > SoftMaxHeapSize just affects the target heap size for scheduling concurrent marks. GCTimeRatio sets the target as well, so the result is basically MIN(SoftMaxHeapSize, GCTimeRatio-based-target). I have not verified, but could this problematic feedback loop happen? User sets a **low** `SoftMaxHeapSize` value, then G1 starts to trigger more concurrent marks and incremental collections, then GC overhead becomes higher. Then G1 observes that the actual GC overhead is above the `GCTimeRatio` target, so it **expands** the heap. Thus, setting a small `SoftMaxHeapSize` makes G1 expand the heap further, ------------- PR Comment: https://git.openjdk.org/jdk/pull/27524#issuecomment-3353942624