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