From mbeckwit at openjdk.org Fri Aug 1 01:41:42 2025 From: mbeckwit at openjdk.org (Monica Beckwith) Date: Fri, 1 Aug 2025 01:41:42 GMT Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods [v6] In-Reply-To: References: Message-ID: > **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 two additional commits since the last revision: - Resolve merge conflict - keep proper @tschatzl time type implementation - Keep Tickspan::from_milliseconds(G1UncommitDelayMillis) initialization - Keep (jlong)elapsed.milliseconds() cast for macOS build compatibility - Keep elapsed > _uncommit_delay direct Tickspan comparison - Maintains cross-platform compatibility - JDK-8357445: Implement @tschatzl code review feedback for time-based heap sizing - Convert from jlong milliseconds to proper time types (Ticks/Tickspan) - Reclassify G1UseTimeBasedHeapSizing from EXPERIMENTAL+false to DIAGNOSTIC+true - Reclassify G1MinRegionsToUncommit from EXPERIMENTAL to DIAGNOSTIC - Keep timing flags (G1UncommitDelayMillis, G1HeapEvaluationIntervalMillis) as MANAGEABLE - Update all test files to use UnlockDiagnosticVMOptions instead of UnlockExperimentalVMOptions - Remove explicit G1UseTimeBasedHeapSizing=true from tests (now enabled by default) - Improve logging terminology from 'time-based' to 'uncommit evaluation' - Fix comment style and remove unused heap_sizing_policy() accessor - Comprehensive type safety improvements throughout the codebase This addresses all feedback regarding type safety, flag design, and production readiness of the time-based heap sizing feature. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26240/files - new: https://git.openjdk.org/jdk/pull/26240/files/53a79368..11061e51 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26240&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26240&range=04-05 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26240.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26240/head:pull/26240 PR: https://git.openjdk.org/jdk/pull/26240 From mbeckwit at openjdk.org Fri Aug 1 05:53:48 2025 From: mbeckwit at openjdk.org (Monica Beckwith) Date: Fri, 1 Aug 2025 05:53:48 GMT Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods [v7] In-Reply-To: References: Message-ID: > **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 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26240/files - new: https://git.openjdk.org/jdk/pull/26240/files/11061e51..e574db86 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26240&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26240&range=05-06 Stats: 10 lines in 2 files changed: 0 ins; 8 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26240.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26240/head:pull/26240 PR: https://git.openjdk.org/jdk/pull/26240 From ayang at openjdk.org Fri Aug 1 06:02:10 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 1 Aug 2025 06:02:10 GMT Subject: Integrated: 8364504: [BACKOUT] JDK-8364176 Serial: Group all class unloading logic at the end of marking phase Message-ID: <9sZOdi-pBu3If4oHJt0bNnkWhzB3uGreh68MZrVE_nA=.942d93cc-4d34-4b38-b7e2-5f7d4e3c3a64@github.com> A clean revert of "JDK-8364176 Serial: Group all class unloading logic at the end of marking phase". Test: Used `jdk/jfr/event/gc/stacktrace/TestMetaspaceSerialGCAllocationPendingStackTrace.java` to verify that it fails before the revert and passes after the revert. ------------- Commit messages: - backout Changes: https://git.openjdk.org/jdk/pull/26587/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26587&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364504 Stats: 22 lines in 2 files changed: 10 ins; 9 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26587.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26587/head:pull/26587 PR: https://git.openjdk.org/jdk/pull/26587 From dholmes at openjdk.org Fri Aug 1 06:02:10 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 1 Aug 2025 06:02:10 GMT Subject: Integrated: 8364504: [BACKOUT] JDK-8364176 Serial: Group all class unloading logic at the end of marking phase In-Reply-To: <9sZOdi-pBu3If4oHJt0bNnkWhzB3uGreh68MZrVE_nA=.942d93cc-4d34-4b38-b7e2-5f7d4e3c3a64@github.com> References: <9sZOdi-pBu3If4oHJt0bNnkWhzB3uGreh68MZrVE_nA=.942d93cc-4d34-4b38-b7e2-5f7d4e3c3a64@github.com> Message-ID: <4zgWDVVmjo30ON0tjLpFp3hSbmKKT6bI5VyQGwtWkqA=.a96b9470-ffd5-45b1-9829-37de2c3877a7@github.com> On Fri, 1 Aug 2025 05:56:02 GMT, Albert Mingkun Yang wrote: > A clean revert of "JDK-8364176 Serial: Group all class unloading logic at the end of marking phase". > > Test: Used `jdk/jfr/event/gc/stacktrace/TestMetaspaceSerialGCAllocationPendingStackTrace.java` to verify that it fails before the revert and passes after the revert. Backout looks good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26587#pullrequestreview-3077790296 From ayang at openjdk.org Fri Aug 1 06:02:10 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 1 Aug 2025 06:02:10 GMT Subject: Integrated: 8364504: [BACKOUT] JDK-8364176 Serial: Group all class unloading logic at the end of marking phase In-Reply-To: <9sZOdi-pBu3If4oHJt0bNnkWhzB3uGreh68MZrVE_nA=.942d93cc-4d34-4b38-b7e2-5f7d4e3c3a64@github.com> References: <9sZOdi-pBu3If4oHJt0bNnkWhzB3uGreh68MZrVE_nA=.942d93cc-4d34-4b38-b7e2-5f7d4e3c3a64@github.com> Message-ID: On Fri, 1 Aug 2025 05:56:02 GMT, Albert Mingkun Yang wrote: > A clean revert of "JDK-8364176 Serial: Group all class unloading logic at the end of marking phase". > > Test: Used `jdk/jfr/event/gc/stacktrace/TestMetaspaceSerialGCAllocationPendingStackTrace.java` to verify that it fails before the revert and passes after the revert. This pull request has now been integrated. Changeset: 913d318c Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/913d318c97aa46c16aca89e565660e5fb67e8efd Stats: 22 lines in 2 files changed: 10 ins; 9 del; 3 mod 8364504: [BACKOUT] JDK-8364176 Serial: Group all class unloading logic at the end of marking phase Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/26587 From ayang at openjdk.org Fri Aug 1 06:02:10 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 1 Aug 2025 06:02:10 GMT Subject: Integrated: 8364504: [BACKOUT] JDK-8364176 Serial: Group all class unloading logic at the end of marking phase In-Reply-To: <9sZOdi-pBu3If4oHJt0bNnkWhzB3uGreh68MZrVE_nA=.942d93cc-4d34-4b38-b7e2-5f7d4e3c3a64@github.com> References: <9sZOdi-pBu3If4oHJt0bNnkWhzB3uGreh68MZrVE_nA=.942d93cc-4d34-4b38-b7e2-5f7d4e3c3a64@github.com> Message-ID: On Fri, 1 Aug 2025 05:56:02 GMT, Albert Mingkun Yang wrote: > A clean revert of "JDK-8364176 Serial: Group all class unloading logic at the end of marking phase". > > Test: Used `jdk/jfr/event/gc/stacktrace/TestMetaspaceSerialGCAllocationPendingStackTrace.java` to verify that it fails before the revert and passes after the revert. Thank you for the quick review. Merging now to reduce CI noise. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26587#issuecomment-3142507671 From shade at openjdk.org Fri Aug 1 06:30:59 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 1 Aug 2025 06:30:59 GMT Subject: RFR: 8358340: Support CDS heap archive with Generational Shenandoah In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 18:22:36 GMT, Aleksey Shipilev wrote: > Now that [JDK-8364111](https://bugs.openjdk.org/browse/JDK-8364111) is integrated, Generational Shenandoah can support CDS heap loads. This also allows Generational Shenandoah to work well with Leyden/AOT. We allocate things in young regions, and there is nothing else in the heap, so no card table updates are necessary. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` > - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational` > - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:+ShenandoahVerify` Thanks! Here goes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25597#issuecomment-3142755055 From shade at openjdk.org Fri Aug 1 06:30:59 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 1 Aug 2025 06:30:59 GMT Subject: Integrated: 8358340: Support CDS heap archive with Generational Shenandoah In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 18:22:36 GMT, Aleksey Shipilev wrote: > Now that [JDK-8364111](https://bugs.openjdk.org/browse/JDK-8364111) is integrated, Generational Shenandoah can support CDS heap loads. This also allows Generational Shenandoah to work well with Leyden/AOT. We allocate things in young regions, and there is nothing else in the heap, so no card table updates are necessary. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` > - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational` > - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:+ShenandoahVerify` This pull request has now been integrated. Changeset: 577ac061 Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/577ac0610a0c62d6a3f5501bb0d1bd45f8c47f22 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8358340: Support CDS heap archive with Generational Shenandoah Reviewed-by: xpeng, wkemper ------------- PR: https://git.openjdk.org/jdk/pull/25597 From jsikstro at openjdk.org Fri Aug 1 07:13:58 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Fri, 1 Aug 2025 07:13:58 GMT Subject: RFR: 8364351: ZGC: Replace usages of ZPageAgeRange() with ZPageAgeRangeAll In-Reply-To: References: Message-ID: On Wed, 30 Jul 2025 14:59:15 GMT, Stefan Karlsson wrote: >> Hello, >> >> Following up on [JDK-8357053](https://bugs.openjdk.org/browse/JDK-8357053) and [JDK-8358586](https://bugs.openjdk.org/browse/JDK-8358586), this RFE adds a new pre-defined ZPageAge iterator called ZPageAgeRangeAll to iterate over all ages. ZPageAgeRangeAll replaces the usage of `ZPageAgeRange()`, and the ZPageAge gtest is expanded to cover this. >> >> Testing: >> * Oracle's tier 1-4 > > Marked as reviewed by stefank (Reviewer). Thanks for the reviews! @stefank @xmas92 ------------- PR Comment: https://git.openjdk.org/jdk/pull/26549#issuecomment-3143194221 From jsikstro at openjdk.org Fri Aug 1 07:13:59 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Fri, 1 Aug 2025 07:13:59 GMT Subject: Integrated: 8364351: ZGC: Replace usages of ZPageAgeRange() with ZPageAgeRangeAll In-Reply-To: References: Message-ID: On Wed, 30 Jul 2025 12:15:34 GMT, Joel Sikstr?m wrote: > Hello, > > Following up on [JDK-8357053](https://bugs.openjdk.org/browse/JDK-8357053) and [JDK-8358586](https://bugs.openjdk.org/browse/JDK-8358586), this RFE adds a new pre-defined ZPageAge iterator called ZPageAgeRangeAll to iterate over all ages. ZPageAgeRangeAll replaces the usage of `ZPageAgeRange()`, and the ZPageAge gtest is expanded to cover this. > > Testing: > * Oracle's tier 1-4 This pull request has now been integrated. Changeset: e82d7f58 Author: Joel Sikstr?m URL: https://git.openjdk.org/jdk/commit/e82d7f58101aa5b7147a881bfc1c96b826446758 Stats: 14 lines in 7 files changed: 5 ins; 0 del; 9 mod 8364351: ZGC: Replace usages of ZPageAgeRange() with ZPageAgeRangeAll Reviewed-by: stefank, aboldtch ------------- PR: https://git.openjdk.org/jdk/pull/26549 From shade at openjdk.org Fri Aug 1 07:30:40 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 1 Aug 2025 07:30:40 GMT Subject: RFR: 8364212: Shenandoah: Rework archived objects loading [v5] In-Reply-To: References: Message-ID: > As continuation of [JDK-8293650](https://bugs.openjdk.org/browse/JDK-8293650), we would want to avoid allocating CDS archives as humongous regions and then flipping them back to regular state. This already complicates the region accounting significantly, and was a source a few bugs. We can rework the CDS archive load to cleanly ask collector for a contiguous set of regular regions. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` > - [x] Linux x86_64 server fastdebug, `runtime/cds` > - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC` > - [x] Linux x86_64 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 eight additional commits since the last revision: - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs - Do not fill out the entire regions - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs - A bit more verification - Fix - Fix - Regular CDS ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26510/files - new: https://git.openjdk.org/jdk/pull/26510/files/84a64649..780bb19e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26510&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26510&range=03-04 Stats: 6239 lines in 132 files changed: 4457 ins; 1551 del; 231 mod Patch: https://git.openjdk.org/jdk/pull/26510.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26510/head:pull/26510 PR: https://git.openjdk.org/jdk/pull/26510 From jsikstro at openjdk.org Fri Aug 1 07:46:00 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Fri, 1 Aug 2025 07:46:00 GMT Subject: RFR: 8364248: Separate commit and reservation limit detection [v6] In-Reply-To: References: Message-ID: On Thu, 31 Jul 2025 10:20:52 GMT, Joel Sikstr?m wrote: >> The function os::has_allocatable_memory_limit() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory_limit() tells us both how much memory can be committed and how much virtual address space is available. On Windows, os::has_allocatable_memory_limit() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space on Windows, and also the virtual address space cannot be limited. >> >> ZGC currently uses os::has_allocatable_memory_limit() to check if the virtual address space is limited (i.e. if there's a limit on how much memory can be reserved). To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::reserve_memory_limit(), which returns the upper-bound of how much memory can be reserved. This should just be SIZE_MAX on Windows, since the virtual address space cannot be limited. >> >> Additionally, we should rename os::has_allocatable_memory_limit() to os::commit_memory_limit(), to be more in line with os::reserve_memory_limit() and read nicely next to the os::commit_memory() and os::reserve_memory() functions. The return type of the new os::commit_memory_limit() should also only be size_t, not bool + out-parameter, to fit better next to os::reserve_memory_limit(). >> >> As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory_limit() (will be os::commit_memory_limit()) on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V). >> >> Testing: >> * Oracle's tier1-2 >> * Manual testing on Linux by limiting the virtual address space: >> >> $ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > commit_memory_limit return size_t instead of bool + out-parameter I've rerun testing, both some manual limit-setting and tier1-2, and looks good. Thank you for the reviews! @albertnetymk @tstuefe @stefank ------------- PR Comment: https://git.openjdk.org/jdk/pull/26530#issuecomment-3143569133 From jsikstro at openjdk.org Fri Aug 1 07:46:01 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Fri, 1 Aug 2025 07:46:01 GMT Subject: Integrated: 8364248: Separate commit and reservation limit detection In-Reply-To: References: Message-ID: On Tue, 29 Jul 2025 11:24:48 GMT, Joel Sikstr?m wrote: > The function os::has_allocatable_memory_limit() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory_limit() tells us both how much memory can be committed and how much virtual address space is available. On Windows, os::has_allocatable_memory_limit() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space on Windows, and also the virtual address space cannot be limited. > > ZGC currently uses os::has_allocatable_memory_limit() to check if the virtual address space is limited (i.e. if there's a limit on how much memory can be reserved). To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::reserve_memory_limit(), which returns the upper-bound of how much memory can be reserved. This should just be SIZE_MAX on Windows, since the virtual address space cannot be limited. > > Additionally, we should rename os::has_allocatable_memory_limit() to os::commit_memory_limit(), to be more in line with os::reserve_memory_limit() and read nicely next to the os::commit_memory() and os::reserve_memory() functions. The return type of the new os::commit_memory_limit() should also only be size_t, not bool + out-parameter, to fit better next to os::reserve_memory_limit(). > > As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory_limit() (will be os::commit_memory_limit()) on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V). > > Testing: > * Oracle's tier1-2 > * Manual testing on Linux by limiting the virtual address space: > > $ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version This pull request has now been integrated. Changeset: ae11d8f4 Author: Joel Sikstr?m URL: https://git.openjdk.org/jdk/commit/ae11d8f44689502d35cb511e9ce288ab7cc0acae Stats: 107 lines in 5 files changed: 45 ins; 38 del; 24 mod 8364248: Separate commit and reservation limit detection Reviewed-by: stuefe, ayang ------------- PR: https://git.openjdk.org/jdk/pull/26530 From tschatzl at openjdk.org Fri Aug 1 08:22:01 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 1 Aug 2025 08:22:01 GMT Subject: RFR: 8364423: G1: Refactor G1UpdateRegionLivenessAndSelectForRebuildTask [v3] In-Reply-To: References: Message-ID: On Thu, 31 Jul 2025 18:58:04 GMT, Sangheon Kim wrote: >> Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision: >> >> - * readding blank line too >> - * indentation > > LGTM Thanks @sangheon @albertnetymk for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/26574#issuecomment-3143632260 From tschatzl at openjdk.org Fri Aug 1 08:25:03 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 1 Aug 2025 08:25:03 GMT Subject: Integrated: 8364423: G1: Refactor G1UpdateRegionLivenessAndSelectForRebuildTask In-Reply-To: References: Message-ID: On Thu, 31 Jul 2025 12:07:13 GMT, Thomas Schatzl wrote: > Hi all, > > please review this refactoring of `G1UpdateRegionLivenessAndSelectForRebuildTask` to remove some code duplication, which makes it simpler to add more common code > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: beda14e3 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/beda14e3cba368b0bf9f8e4567df163cf1e648a4 Stats: 29 lines in 1 file changed: 13 ins; 14 del; 2 mod 8364423: G1: Refactor G1UpdateRegionLivenessAndSelectForRebuildTask Reviewed-by: sangheki, ayang ------------- PR: https://git.openjdk.org/jdk/pull/26574 From ayang at openjdk.org Fri Aug 1 08:53:06 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 1 Aug 2025 08:53:06 GMT Subject: RFR: 8364516: Serial: Move class unloading logic inside SerialFullGC::invoke_at_safepoint Message-ID: Encapsulating classunloading logic inside `invoke_at_safepoint` and adding doc explaining why the classunloading logic can't be placed at the end of marking during full-gc, like other STW collectors. Test: tier1-3 ------------- Commit messages: - sgc-unloading-doc Changes: https://git.openjdk.org/jdk/pull/26588/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26588&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364516 Stats: 27 lines in 2 files changed: 17 ins; 10 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26588.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26588/head:pull/26588 PR: https://git.openjdk.org/jdk/pull/26588 From tschatzl at openjdk.org Fri Aug 1 09:29:56 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 1 Aug 2025 09:29:56 GMT Subject: RFR: 8364516: Serial: Move class unloading logic inside SerialFullGC::invoke_at_safepoint In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 08:47:57 GMT, Albert Mingkun Yang wrote: > Encapsulating classunloading logic inside `invoke_at_safepoint` and adding doc explaining why the classunloading logic can't be placed at the end of marking during full-gc, like other STW collectors. > > Test: tier1-3 Minor suggestions to the comment. src/hotspot/share/gc/serial/serialFullGC.cpp line 708: > 706: allocate_stacks(); > 707: > 708: // Usually, all classunloading works occurs at the end of phase 1, but Serial Suggestion: // Usually, all class unloading works occurs at the end of phase 1, but Serial src/hotspot/share/gc/serial/serialFullGC.cpp line 711: > 709: // full-gc accesses dead-objs' klass to find out the start of next live-obj > 710: // during phase 2. This requires klasses of dead-objs to be kept loaded. > 711: // Therefore, we declare classunloading context in the same level as various Suggestion: // Therefore, we declare the class unloading context at the same level as the other or Suggestion: // Therefore, we declare the ClassUnloadingContext at the same level as the other src/hotspot/share/gc/serial/serialFullGC.cpp line 713: > 711: // Therefore, we declare classunloading context in the same level as various > 712: // phases, and purge dead classes (invoking ClassLoaderDataGraph::purge) > 713: // after all phases of full-gc. Suggestion: // phases, and purge dead classes (invoking ClassLoaderDataGraph::purge()) // after the other phases of full-gc. src/hotspot/share/gc/serial/serialFullGC.cpp line 768: > 766: } > 767: > 768: // Delete metaspaces for unloaded class loaders and clean up loader_data graph Suggestion: // Delete metaspaces for unloaded class loaders and clean up the CLDG. or Suggestion: // Delete metaspaces for unloaded class loaders and clean up the class loader data graph. ------------- Changes requested by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26588#pullrequestreview-3078401549 PR Review Comment: https://git.openjdk.org/jdk/pull/26588#discussion_r2247430537 PR Review Comment: https://git.openjdk.org/jdk/pull/26588#discussion_r2247433520 PR Review Comment: https://git.openjdk.org/jdk/pull/26588#discussion_r2247436334 PR Review Comment: https://git.openjdk.org/jdk/pull/26588#discussion_r2247439584 From tschatzl at openjdk.org Fri Aug 1 09:29:56 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 1 Aug 2025 09:29:56 GMT Subject: RFR: 8364516: Serial: Move class unloading logic inside SerialFullGC::invoke_at_safepoint In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 09:24:30 GMT, Thomas Schatzl wrote: >> Encapsulating classunloading logic inside `invoke_at_safepoint` and adding doc explaining why the classunloading logic can't be placed at the end of marking during full-gc, like other STW collectors. >> >> Test: tier1-3 > > src/hotspot/share/gc/serial/serialFullGC.cpp line 713: > >> 711: // Therefore, we declare classunloading context in the same level as various >> 712: // phases, and purge dead classes (invoking ClassLoaderDataGraph::purge) >> 713: // after all phases of full-gc. > > Suggestion: > > // phases, and purge dead classes (invoking ClassLoaderDataGraph::purge()) > // after the other phases of full-gc. Not sure why "full gc" has a hyphen in the middle but I guess that's done elsewhere too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26588#discussion_r2247437619 From ayang at openjdk.org Fri Aug 1 09:49:08 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 1 Aug 2025 09:49:08 GMT Subject: RFR: 8364516: Serial: Move class unloading logic inside SerialFullGC::invoke_at_safepoint [v2] In-Reply-To: References: Message-ID: > Encapsulating classunloading logic inside `invoke_at_safepoint` and adding doc explaining why the classunloading logic can't be placed at the end of marking during full-gc, like other STW collectors. > > Test: tier1-3 Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26588/files - new: https://git.openjdk.org/jdk/pull/26588/files/f32132a7..f41fb5ef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26588&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26588&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/26588.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26588/head:pull/26588 PR: https://git.openjdk.org/jdk/pull/26588 From ayang at openjdk.org Fri Aug 1 09:49:09 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 1 Aug 2025 09:49:09 GMT Subject: RFR: 8364516: Serial: Move class unloading logic inside SerialFullGC::invoke_at_safepoint In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 08:47:57 GMT, Albert Mingkun Yang wrote: > Encapsulating classunloading logic inside `invoke_at_safepoint` and adding doc explaining why the classunloading logic can't be placed at the end of marking during full-gc, like other STW collectors. > > Test: tier1-3 Thank you for the feedback; applied all except this one -- "the other" phases probably don't make much sense, because this comment precedes all full-gc phases; there is no "current" phase. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26588#issuecomment-3143931687 From tschatzl at openjdk.org Fri Aug 1 10:36:05 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 1 Aug 2025 10:36:05 GMT Subject: RFR: 8364531: G1: Factor out liveness tracing code Message-ID: Hi all, please review this refactoring, eliminating some copy&paste, in cset candidate group liveness logging. The output is mostly the same, except for the young cset group, where the "-" has been replaced to just print the default value (0.0) for efficiency. I did not see this important to have, the gc efficiency for young gen isn't interesting. Testing: local compilation, gha, visual inspection of output Thanks, Thomas ------------- Commit messages: - 8364531 Changes: https://git.openjdk.org/jdk/pull/26591/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26591&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364531 Stats: 60 lines in 2 files changed: 18 ins; 35 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/26591.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26591/head:pull/26591 PR: https://git.openjdk.org/jdk/pull/26591 From tschatzl at openjdk.org Fri Aug 1 11:39:49 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 1 Aug 2025 11:39:49 GMT Subject: RFR: 8364503: Test gc/g1/TestCodeCacheUnloadDuringConcCycle.java failed Message-ID: Hi all, please review this change to the `gc/g1/TestCodeCacheUnloadDuringConcCycle.java` test - previously, the GC that we were waiting for in the test could occur between releasing whitebox control and the marker we use to distinguish before/after test setup. The change makes sure the marker is printed before releasing Whitebox control. So the concurrent start gc we look for can not happen before the marker printing. Testing: passes 5000 runs of that benchmark Thanks, Thomas ------------- Commit messages: - 8364503 Changes: https://git.openjdk.org/jdk/pull/26592/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26592&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364503 Stats: 7 lines in 1 file changed: 6 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26592.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26592/head:pull/26592 PR: https://git.openjdk.org/jdk/pull/26592 From tschatzl at openjdk.org Fri Aug 1 12:31:10 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 1 Aug 2025 12:31:10 GMT Subject: RFR: 8364531: G1: Factor out liveness tracing code [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review this refactoring, eliminating some copy&paste, in cset candidate group liveness logging. > > The output is mostly the same, except for the young cset group, where the "-" has been replaced to just print the default value (0.0) for efficiency. I did not see this important to have, the gc efficiency for young gen isn't interesting. > > Testing: local compilation, gha, visual inspection of output > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * use one line per parameter in log message ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26591/files - new: https://git.openjdk.org/jdk/pull/26591/files/66524c81..d1653627 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26591&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26591&range=00-01 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26591.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26591/head:pull/26591 PR: https://git.openjdk.org/jdk/pull/26591 From tschatzl at openjdk.org Fri Aug 1 13:33:34 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 1 Aug 2025 13:33:34 GMT Subject: RFR: 8364531: G1: Factor out liveness tracing code [v3] In-Reply-To: References: Message-ID: > Hi all, > > please review this refactoring, eliminating some copy&paste, in cset candidate group liveness logging. > > The output is mostly the same, except for the young cset group, where the "-" has been replaced to just print the default value (0.0) for efficiency. I did not see this important to have, the gc efficiency for young gen isn't interesting. > > Testing: local compilation, gha, visual inspection of output > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * more refactoring ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26591/files - new: https://git.openjdk.org/jdk/pull/26591/files/d1653627..6f605b70 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26591&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26591&range=01-02 Stats: 18 lines in 2 files changed: 9 ins; 6 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26591.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26591/head:pull/26591 PR: https://git.openjdk.org/jdk/pull/26591 From ayang at openjdk.org Fri Aug 1 13:46:59 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 1 Aug 2025 13:46:59 GMT Subject: RFR: 8364503: gc/g1/TestCodeCacheUnloadDuringConcCycle.java fails because of race printing to stdout In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 10:31:53 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to the `gc/g1/TestCodeCacheUnloadDuringConcCycle.java` test - previously, the GC that we were waiting for in the test could occur between releasing whitebox control and the marker we use to distinguish before/after test setup. > > The change makes sure the marker is printed before releasing Whitebox control. So the concurrent start gc we look for can not happen before the marker printing. > > Testing: passes 5000 runs of that benchmark > > Thanks, > Thomas test/hotspot/jtreg/gc/g1/TestCodeCacheUnloadDuringConcCycle.java line 165: > 163: // can start. > 164: System.out.println(TestCodeCacheUnloadDuringConcCycle.AFTER_FIRST_CYCLE_MARKER); > 165: System.out.flush(); I thought println already flushes the stdout. Why is explicit flush needed? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26592#discussion_r2248032389 From ayang at openjdk.org Fri Aug 1 15:42:06 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 1 Aug 2025 15:42:06 GMT Subject: RFR: 8364541: Parallel: Support allocation in old generation when heap is almost full Message-ID: Adding old-gen allocation support in heap-almost-full scenario. This can make tests that cause OOM deliberately more resilient to timeout and help runaway apps to exit/fail faster. Test: tier1-3 ------------- Commit messages: - pgc-old-gen-allocate Changes: https://git.openjdk.org/jdk/pull/26599/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26599&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364541 Stats: 7 lines in 1 file changed: 2 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/26599.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26599/head:pull/26599 PR: https://git.openjdk.org/jdk/pull/26599 From ayang at openjdk.org Fri Aug 1 15:49:03 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 1 Aug 2025 15:49:03 GMT Subject: RFR: 8364518: Support for Job Objects in os::commit_memory_limit() on Windows In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 10:38:32 GMT, Joel Sikstr?m wrote: > Hello, > > We currently use os::commit_memory_limit() to limit the initial, min and max values when ergonomically setting the heap size. Right now, os::commit_memory_limit() returns the available virtual address space on Windows, which is guaranteed to be the upper-bound of how much memory can be committed. However, this does not take into account user-configurable limits. > > I propose revising os::commit_memory_limit() to consider Windows Job Objects. Job Objects can, among other things, restrict the amount of memory that can be committed by a single process or all processes in a job. If we are unable to query Job Object information or if no limit is set, I suggest returning SIZE_MAX, since the next effective limit is the available virtual address space. The size of this virtual address space cannot be modified by the user, except by consuming it. > > For more details and short examples, I have created a GitHub repository summarizing my findings regarding memory limits and Job Objects on Windows: [https://github.com/jsikstro/MemoryLimitsWindows ](https://github.com/jsikstro/MemoryLimitsWindows). > > Adding support for Job Objects in this way adds support for detecting memory limits when using native Windows Hyper-V containers, which uses Job Objects to limit memory. > > Testing: > * Oracles tier1-2 > * Manual testing on Windows using both [Process Governor](https://github.com/lowleveldesign/process-governor) (a popular tool), and creating a Job Object manually. src/hotspot/os/windows/os_windows.cpp line 3306: > 3304: if (!res) { > 3305: return SIZE_MAX; > 3306: } I wonder if it makes sense to print a warning or sth here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26593#discussion_r2248303775 From sangheki at openjdk.org Fri Aug 1 16:35:54 2025 From: sangheki at openjdk.org (Sangheon Kim) Date: Fri, 1 Aug 2025 16:35:54 GMT Subject: RFR: 8364516: Serial: Move class unloading logic inside SerialFullGC::invoke_at_safepoint [v2] In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 09:49:08 GMT, Albert Mingkun Yang wrote: >> Encapsulating classunloading logic inside `invoke_at_safepoint` and adding doc explaining why the classunloading logic can't be placed at the end of marking during full-gc, like other STW collectors. >> >> Test: tier1-3 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Looks good as is. There are not aligned lines at 714, 715. ------------- Marked as reviewed by sangheki (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26588#pullrequestreview-3079869693 From ayang at openjdk.org Fri Aug 1 16:54:45 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 1 Aug 2025 16:54:45 GMT Subject: RFR: 8364516: Serial: Move class unloading logic inside SerialFullGC::invoke_at_safepoint [v3] In-Reply-To: References: Message-ID: > Encapsulating classunloading logic inside `invoke_at_safepoint` and adding doc explaining why the classunloading logic can't be placed at the end of marking during full-gc, like other STW collectors. > > Test: tier1-3 Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26588/files - new: https://git.openjdk.org/jdk/pull/26588/files/f41fb5ef..88fe17c7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26588&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26588&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26588.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26588/head:pull/26588 PR: https://git.openjdk.org/jdk/pull/26588 From mdoerr at openjdk.org Fri Aug 1 18:36:56 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 1 Aug 2025 18:36:56 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v2] In-Reply-To: References: Message-ID: On Thu, 24 Jul 2025 18:51:22 GMT, Dean Long wrote: >> This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value. Further, it takes a fast-path that uses the previous direct store when at a safepoint. Combined, these changes should get us back to almost where we were before in terms of overhead. If necessary, we could go even further and allow make_not_entrant() to perform a direct byte store, leaving 24 bits for the guard value. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > remove NMethodEntryBarrier_lock Thanks for implementing it for PPC64! The instruction sequence needs to be modified (see below). I'd like to have https://github.com/TheRealMDoerr/jdk/commit/522b1ef2e75509d91ac18a1acd27275fc0305e8e, too. Should I file a separate RFE for that? src/hotspot/cpu/ppc/gc/shared/barrierSetAssembler_ppc.cpp line 195: > 193: // This is a compound instruction. Patching support is provided by NativeMovRegMem. > 194: // Actual patching is done in (platform-specific part of) BarrierSetNMethod. > 195: __ align(8); // align for atomic update We can't do this within this fixed size instruction sequence. But, it can be fixed like this: https://github.com/TheRealMDoerr/jdk/commit/a06b34468f5cb063892f92b66d058a8f444f05a1 ------------- Changes requested by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26399#pullrequestreview-3080187466 PR Review Comment: https://git.openjdk.org/jdk/pull/26399#discussion_r2248603769 From wkemper at openjdk.org Fri Aug 1 18:42:00 2025 From: wkemper at openjdk.org (William Kemper) Date: Fri, 1 Aug 2025 18:42:00 GMT Subject: RFR: 8364212: Shenandoah: Rework archived objects loading [v5] In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 07:30:40 GMT, Aleksey Shipilev wrote: >> As continuation of [JDK-8293650](https://bugs.openjdk.org/browse/JDK-8293650), we would want to avoid allocating CDS archives as humongous regions and then flipping them back to regular state. This already complicates the region accounting significantly, and was a source a few bugs. We can rework the CDS archive load to cleanly ask collector for a contiguous set of regular regions. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` >> - [x] Linux x86_64 server fastdebug, `runtime/cds` >> - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC` >> - [x] Linux x86_64 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 eight additional commits since the last revision: > > - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs > - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs > - Do not fill out the entire regions > - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs > - A bit more verification > - Fix > - Fix > - Regular CDS src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1282: > 1280: ShenandoahHeapRegion* r = _heap->get_region(i); > 1281: if (r->free() < PLAB::min_size() * HeapWordSize) { > 1282: _partitions.retire_from_partition(ShenandoahFreeSetPartitionId::Mutator, i, r->used()); Should we accrue waste here when these regions are retired? Or is waste only _humongous_ waste? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26510#discussion_r2248623501 From mdoerr at openjdk.org Fri Aug 1 18:46:55 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 1 Aug 2025 18:46:55 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v2] In-Reply-To: References: Message-ID: On Thu, 24 Jul 2025 18:51:22 GMT, Dean Long wrote: >> This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value. Further, it takes a fast-path that uses the previous direct store when at a safepoint. Combined, these changes should get us back to almost where we were before in terms of overhead. If necessary, we could go even further and allow make_not_entrant() to perform a direct byte store, leaving 24 bits for the guard value. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > remove NMethodEntryBarrier_lock src/hotspot/share/gc/shared/barrierSetNMethod.cpp line 113: > 111: } > 112: > 113: MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXWrite, Thread::current())); This looks also ok as alternative to my proposal. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26399#discussion_r2248631958 From shade at openjdk.org Fri Aug 1 19:11:02 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 1 Aug 2025 19:11:02 GMT Subject: RFR: 8364212: Shenandoah: Rework archived objects loading [v5] In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 18:39:28 GMT, William Kemper wrote: >> 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 eight additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs >> - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs >> - Do not fill out the entire regions >> - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs >> - A bit more verification >> - Fix >> - Fix >> - Regular CDS > > src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1282: > >> 1280: ShenandoahHeapRegion* r = _heap->get_region(i); >> 1281: if (r->free() < PLAB::min_size() * HeapWordSize) { >> 1282: _partitions.retire_from_partition(ShenandoahFreeSetPartitionId::Mutator, i, r->used()); > > Should we accrue waste here when these regions are retired? Or is waste only _humongous_ waste? I believe yes, we only report the _humongous_ waste in ShenandoahAllocRequest. The rest of the waste is accrued right in `retire_from_partition`: https://github.com/openjdk/jdk/blob/8e921aee5abb20c240b45cb75b06fb1f316d8a1f/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp#L373-L376 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26510#discussion_r2248692418 From wkemper at openjdk.org Fri Aug 1 19:29:55 2025 From: wkemper at openjdk.org (William Kemper) Date: Fri, 1 Aug 2025 19:29:55 GMT Subject: RFR: 8364212: Shenandoah: Rework archived objects loading [v5] In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 07:30:40 GMT, Aleksey Shipilev wrote: >> As continuation of [JDK-8293650](https://bugs.openjdk.org/browse/JDK-8293650), we would want to avoid allocating CDS archives as humongous regions and then flipping them back to regular state. This already complicates the region accounting significantly, and was a source a few bugs. We can rework the CDS archive load to cleanly ask collector for a contiguous set of regular regions. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` >> - [x] Linux x86_64 server fastdebug, `runtime/cds` >> - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC` >> - [x] Linux x86_64 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 eight additional commits since the last revision: > > - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs > - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs > - Do not fill out the entire regions > - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs > - A bit more verification > - Fix > - Fix > - Regular CDS Marked as reviewed by wkemper (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26510#pullrequestreview-3080348336 From dlong at openjdk.org Fri Aug 1 20:09:11 2025 From: dlong at openjdk.org (Dean Long) Date: Fri, 1 Aug 2025 20:09:11 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v3] In-Reply-To: References: Message-ID: <_8Z-PXaFqGay1pHqcJmeWXrOFv4QQVqnJG2RuZ7rzTk=.34cc6ecb-e189-461c-971b-f59f899372f5@github.com> > This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value. Further, it takes a fast-path that uses the previous direct store when at a safepoint. Combined, these changes should get us back to almost where we were before in terms of overhead. If necessary, we could go even further and allow make_not_entrant() to perform a direct byte store, leaving 24 bits for the guard value. Dean Long has updated the pull request incrementally with one additional commit since the last revision: Fix PPC64 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26399/files - new: https://git.openjdk.org/jdk/pull/26399/files/e05605eb..a06b3446 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26399&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26399&range=01-02 Stats: 24 lines in 2 files changed: 11 ins; 10 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26399.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26399/head:pull/26399 PR: https://git.openjdk.org/jdk/pull/26399 From mdoerr at openjdk.org Fri Aug 1 20:09:11 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 1 Aug 2025 20:09:11 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v3] In-Reply-To: <_8Z-PXaFqGay1pHqcJmeWXrOFv4QQVqnJG2RuZ7rzTk=.34cc6ecb-e189-461c-971b-f59f899372f5@github.com> References: <_8Z-PXaFqGay1pHqcJmeWXrOFv4QQVqnJG2RuZ7rzTk=.34cc6ecb-e189-461c-971b-f59f899372f5@github.com> Message-ID: On Fri, 1 Aug 2025 20:05:56 GMT, Dean Long wrote: >> This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value. Further, it takes a fast-path that uses the previous direct store when at a safepoint. Combined, these changes should get us back to almost where we were before in terms of overhead. If necessary, we could go even further and allow make_not_entrant() to perform a direct byte store, leaving 24 bits for the guard value. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > Fix PPC64 Thanks for integrating my fix! ------------- PR Review: https://git.openjdk.org/jdk/pull/26399#pullrequestreview-3080433000 From mdoerr at openjdk.org Fri Aug 1 21:58:56 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 1 Aug 2025 21:58:56 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v3] In-Reply-To: <_8Z-PXaFqGay1pHqcJmeWXrOFv4QQVqnJG2RuZ7rzTk=.34cc6ecb-e189-461c-971b-f59f899372f5@github.com> References: <_8Z-PXaFqGay1pHqcJmeWXrOFv4QQVqnJG2RuZ7rzTk=.34cc6ecb-e189-461c-971b-f59f899372f5@github.com> Message-ID: On Fri, 1 Aug 2025 20:09:11 GMT, Dean Long wrote: >> This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value. Further, it takes a fast-path that uses the previous direct store when at a safepoint. Combined, these changes should get us back to almost where we were before in terms of overhead. If necessary, we could go even further and allow make_not_entrant() to perform a direct byte store, leaving 24 bits for the guard value. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > Fix PPC64 PPC64 code looks correct, now, but I have minor proposals. src/hotspot/cpu/ppc/gc/shared/barrierSetNMethod_ppc.cpp line 84: > 82: nativeMovRegMem_at(new_mov_instr.buf)->set_offset(new_value, false /* no icache flush */); > 83: // Swap in the new value > 84: uint64_t v = Atomic::cmpxchg(instr, old_mov_instr.u64, new_mov_instr.u64, memory_order_release); We have `OrderAccess::release()` above, so `memory_order_release` looks redundant. Shouldn't we use `memory_order_relaxed`, here? src/hotspot/cpu/ppc/gc/shared/barrierSetNMethod_ppc.cpp line 88: > 86: old_mov_instr.u64 = v; > 87: } > 88: ICache::ppc64_flush_icache_bytes(addr_at(0), NativeMovRegMem::instruction_size); Maybe only use flushing if `cmpxchg` succeeded? Otherwise, we didn't modify the code. ------------- PR Review: https://git.openjdk.org/jdk/pull/26399#pullrequestreview-3080627303 PR Review Comment: https://git.openjdk.org/jdk/pull/26399#discussion_r2248909656 PR Review Comment: https://git.openjdk.org/jdk/pull/26399#discussion_r2248925985 From kdnilsen at openjdk.org Sun Aug 3 22:42:54 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Sun, 3 Aug 2025 22:42:54 GMT Subject: RFR: 8364212: Shenandoah: Rework archived objects loading [v5] In-Reply-To: References: Message-ID: <_B8dg2PqDeKOfcnFjCYzvi02rMn9aB_FUmJebzyYJtA=.972e96cf-4b7c-403e-bf92-285c7ddd85a2@github.com> On Fri, 1 Aug 2025 07:30:40 GMT, Aleksey Shipilev wrote: >> As continuation of [JDK-8293650](https://bugs.openjdk.org/browse/JDK-8293650), we would want to avoid allocating CDS archives as humongous regions and then flipping them back to regular state. This already complicates the region accounting significantly, and was a source a few bugs. We can rework the CDS archive load to cleanly ask collector for a contiguous set of regular regions. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` >> - [x] Linux x86_64 server fastdebug, `runtime/cds` >> - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC` >> - [x] Linux x86_64 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 eight additional commits since the last revision: > > - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs > - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs > - Do not fill out the entire regions > - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs > - A bit more verification > - Fix > - Fix > - Regular CDS Marked as reviewed by kdnilsen (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26510#pullrequestreview-3082385892 From kdnilsen at openjdk.org Sun Aug 3 22:42:55 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Sun, 3 Aug 2025 22:42:55 GMT Subject: RFR: 8364212: Shenandoah: Rework archived objects loading [v5] In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 19:08:29 GMT, Aleksey Shipilev wrote: >> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1282: >> >>> 1280: ShenandoahHeapRegion* r = _heap->get_region(i); >>> 1281: if (r->free() < PLAB::min_size() * HeapWordSize) { >>> 1282: _partitions.retire_from_partition(ShenandoahFreeSetPartitionId::Mutator, i, r->used()); >> >> Should we accrue waste here when these regions are retired? Or is waste only _humongous_ waste? > > I believe yes, we only report the _humongous_ waste in ShenandoahAllocRequest. The rest of the waste is accrued right in `retire_from_partition`: https://github.com/openjdk/jdk/blob/8e921aee5abb20c240b45cb75b06fb1f316d8a1f/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp#L373-L376 The "theory" is that if the remainder of this region is available for allocations, then we should not count the remnant as humongous_waste. Is there any reason why we could not allow additional allocations within the CDS regions? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26510#discussion_r2250161656 From kdnilsen at openjdk.org Sun Aug 3 22:42:55 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Sun, 3 Aug 2025 22:42:55 GMT Subject: RFR: 8364212: Shenandoah: Rework archived objects loading [v5] In-Reply-To: References: Message-ID: On Sun, 3 Aug 2025 22:36:51 GMT, Kelvin Nilsen wrote: >> I believe yes, we only report the _humongous_ waste in ShenandoahAllocRequest. The rest of the waste is accrued right in `retire_from_partition`: https://github.com/openjdk/jdk/blob/8e921aee5abb20c240b45cb75b06fb1f316d8a1f/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp#L373-L376 > > The "theory" is that if the remainder of this region is available for allocations, then we should not count the remnant as humongous_waste. Is there any reason why we could not allow additional allocations within the CDS regions? I agree that if we need to prevent further allocations in this region, then calling retire_from_partition() will account for the remnant memory as used and will prevent further allocations from this region. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26510#discussion_r2250161916 From jsikstro at openjdk.org Mon Aug 4 07:40:12 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Mon, 4 Aug 2025 07:40:12 GMT Subject: RFR: 8364518: Support for Job Objects in os::commit_memory_limit() on Windows [v2] In-Reply-To: References: Message-ID: <1yjYw2L7Jta-_-v0KPNcvz8wS9arjOCzvrwQpZ6sP6k=.186ac2f0-6d5f-4dd6-bcdb-839841847f25@github.com> > Hello, > > We currently use os::commit_memory_limit() to limit the initial, min and max values when ergonomically setting the heap size. Right now, os::commit_memory_limit() returns the available virtual address space on Windows, which is guaranteed to be the upper-bound of how much memory can be committed. However, this does not take into account user-configurable limits. > > I propose revising os::commit_memory_limit() to consider Windows Job Objects. Job Objects can, among other things, restrict the amount of memory that can be committed by a single process or all processes in a job. If we are unable to query Job Object information or if no limit is set, I suggest returning SIZE_MAX, since the next effective limit is the available virtual address space. The size of this virtual address space cannot be modified by the user, except by consuming it. > > For more details and short examples, I have created a GitHub repository summarizing my findings regarding memory limits and Job Objects on Windows: [https://github.com/jsikstro/MemoryLimitsWindows ](https://github.com/jsikstro/MemoryLimitsWindows). > > Adding support for Job Objects in this way adds support for detecting memory limits when using native Windows Hyper-V containers, which uses Job Objects to limit memory. > > Testing: > * Oracles tier1-2 > * Manual testing on Windows using both [Process Governor](https://github.com/lowleveldesign/process-governor) (a popular tool), and creating a Job Object manually. Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: Print error message if query fails ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26593/files - new: https://git.openjdk.org/jdk/pull/26593/files/436e2160..eb446664 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26593&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26593&range=00-01 Stats: 6 lines in 1 file changed: 5 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26593.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26593/head:pull/26593 PR: https://git.openjdk.org/jdk/pull/26593 From jsikstro at openjdk.org Mon Aug 4 07:40:12 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Mon, 4 Aug 2025 07:40:12 GMT Subject: RFR: 8364518: Support for Job Objects in os::commit_memory_limit() on Windows [v2] In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 15:46:19 GMT, Albert Mingkun Yang wrote: >> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: >> >> Print error message if query fails > > src/hotspot/os/windows/os_windows.cpp line 3306: > >> 3304: if (!res) { >> 3305: return SIZE_MAX; >> 3306: } > > I wonder if it makes sense to print a warning or sth here. Looking at how `QueryInformationJobObject` is used in `os::win32::active_processors_in_job_object()`, which is the only other place where it is called, we do this when querying fails: char buf[512]; size_t buf_len = os::lasterror(buf, sizeof(buf)); warning("Attempt to query job object information failed: %s", buf_len != 0 ? buf : ""); I'll add this to the code to be consistent with hos `os::win32::active_processors_in_job_object()` works, but I'm open to new suggestions as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26593#discussion_r2250657359 From ayang at openjdk.org Mon Aug 4 07:52:59 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 4 Aug 2025 07:52:59 GMT Subject: RFR: 8364518: Support for Job Objects in os::commit_memory_limit() on Windows [v2] In-Reply-To: <1yjYw2L7Jta-_-v0KPNcvz8wS9arjOCzvrwQpZ6sP6k=.186ac2f0-6d5f-4dd6-bcdb-839841847f25@github.com> References: <1yjYw2L7Jta-_-v0KPNcvz8wS9arjOCzvrwQpZ6sP6k=.186ac2f0-6d5f-4dd6-bcdb-839841847f25@github.com> Message-ID: On Mon, 4 Aug 2025 07:40:12 GMT, Joel Sikstr?m wrote: >> Hello, >> >> We currently use os::commit_memory_limit() to limit the initial, min and max values when ergonomically setting the heap size. Right now, os::commit_memory_limit() returns the available virtual address space on Windows, which is guaranteed to be the upper-bound of how much memory can be committed. However, this does not take into account user-configurable limits. >> >> I propose revising os::commit_memory_limit() to consider Windows Job Objects. Job Objects can, among other things, restrict the amount of memory that can be committed by a single process or all processes in a job. If we are unable to query Job Object information or if no limit is set, I suggest returning SIZE_MAX, since the next effective limit is the available virtual address space. The size of this virtual address space cannot be modified by the user, except by consuming it. >> >> For more details and short examples, I have created a GitHub repository summarizing my findings regarding memory limits and Job Objects on Windows: [https://github.com/jsikstro/MemoryLimitsWindows ](https://github.com/jsikstro/MemoryLimitsWindows). >> >> Adding support for Job Objects in this way adds support for detecting memory limits when using native Windows Hyper-V containers, which uses Job Objects to limit memory. >> >> Testing: >> * Oracles tier1-2 >> * Manual testing on Windows using both [Process Governor](https://github.com/lowleveldesign/process-governor) (a popular tool), and creating a Job Object manually. > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > Print error message if query fails Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26593#pullrequestreview-3083085532 From tschatzl at openjdk.org Mon Aug 4 08:05:03 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 4 Aug 2025 08:05:03 GMT Subject: RFR: 8364503: gc/g1/TestCodeCacheUnloadDuringConcCycle.java fails because of race printing to stdout [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review this change to the `gc/g1/TestCodeCacheUnloadDuringConcCycle.java` test - previously, the GC that we were waiting for in the test could occur between releasing whitebox control and the marker we use to distinguish before/after test setup. > > The change makes sure the marker is printed before releasing Whitebox control. So the concurrent start gc we look for can not happen before the marker printing. > > Testing: passes 5000 runs of that benchmark > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * review ayang ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26592/files - new: https://git.openjdk.org/jdk/pull/26592/files/fbdc1416..3ff76be7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26592&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26592&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26592.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26592/head:pull/26592 PR: https://git.openjdk.org/jdk/pull/26592 From tschatzl at openjdk.org Mon Aug 4 08:05:04 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 4 Aug 2025 08:05:04 GMT Subject: RFR: 8364503: gc/g1/TestCodeCacheUnloadDuringConcCycle.java fails because of race printing to stdout [v2] In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 13:44:41 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * review ayang > > test/hotspot/jtreg/gc/g1/TestCodeCacheUnloadDuringConcCycle.java line 165: > >> 163: // can start. >> 164: System.out.println(TestCodeCacheUnloadDuringConcCycle.AFTER_FIRST_CYCLE_MARKER); >> 165: System.out.flush(); > > I thought println already flushes the stdout. Why is explicit flush needed? The spec (javadoc) does not define whether the `PrintStream` for `System.out` is one that does auto flushing afaict. However the current implementation does that, so I removed the explicit `flush()` call. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26592#discussion_r2250721141 From tschatzl at openjdk.org Mon Aug 4 08:07:57 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 4 Aug 2025 08:07:57 GMT Subject: RFR: 8364516: Serial: Move class unloading logic inside SerialFullGC::invoke_at_safepoint [v3] In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 16:54:45 GMT, Albert Mingkun Yang wrote: >> Encapsulating classunloading logic inside `invoke_at_safepoint` and adding doc explaining why the classunloading logic can't be placed at the end of marking during full-gc, like other STW collectors. >> >> Test: tier1-3 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Sorry, one more typo I apparently forgot last time. src/hotspot/share/gc/serial/serialFullGC.cpp line 708: > 706: allocate_stacks(); > 707: > 708: // Usually, all class unloading works occurs at the end of phase 1, but Serial Suggestion: // Usually, all class unloading work occurs at the end of phase 1, but Serial ------------- Changes requested by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26588#pullrequestreview-3083136375 PR Review Comment: https://git.openjdk.org/jdk/pull/26588#discussion_r2250730716 From ayang at openjdk.org Mon Aug 4 08:08:54 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 4 Aug 2025 08:08:54 GMT Subject: RFR: 8364503: gc/g1/TestCodeCacheUnloadDuringConcCycle.java fails because of race printing to stdout [v2] In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 08:05:03 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change to the `gc/g1/TestCodeCacheUnloadDuringConcCycle.java` test - previously, the GC that we were waiting for in the test could occur between releasing whitebox control and the marker we use to distinguish before/after test setup. >> >> The change makes sure the marker is printed before releasing Whitebox control. So the concurrent start gc we look for can not happen before the marker printing. >> >> Testing: passes 5000 runs of that benchmark >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * review ayang Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26592#pullrequestreview-3083140894 From ayang at openjdk.org Mon Aug 4 08:13:57 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 4 Aug 2025 08:13:57 GMT Subject: RFR: 8364516: Serial: Move class unloading logic inside SerialFullGC::invoke_at_safepoint [v4] In-Reply-To: References: Message-ID: > Encapsulating classunloading logic inside `invoke_at_safepoint` and adding doc explaining why the classunloading logic can't be placed at the end of marking during full-gc, like other STW collectors. > > 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 five additional commits since the last revision: - Merge branch 'master' into sgc-unloading-doc - review - review - review - sgc-unloading-doc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26588/files - new: https://git.openjdk.org/jdk/pull/26588/files/88fe17c7..a912850a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26588&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26588&range=02-03 Stats: 2991 lines in 75 files changed: 2663 ins; 119 del; 209 mod Patch: https://git.openjdk.org/jdk/pull/26588.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26588/head:pull/26588 PR: https://git.openjdk.org/jdk/pull/26588 From tschatzl at openjdk.org Mon Aug 4 08:15:07 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 4 Aug 2025 08:15:07 GMT Subject: RFR: 8364532: G1: In liveness tracing, print more significant digits for the liveness value Message-ID: Hi all, please review this small change that adds some more significant digits (3 in total) for the "liveness" column in collection set group logging. E.g. see the emphasized columns that lack precision (it's more irritating with lots of lines showing single-digit values): 50.707s][trace][gc,liveness] GC(13) ### groud-id num-regions gc-eff liveness remset type 50.707s][trace][gc,liveness] GC(13) ### (bytes/ms) % (bytes) 50.707s][trace][gc,liveness] GC(13) ### 1 70 0.0 *100* 3199208 Y 50.707s][trace][gc,liveness] GC(13) ### 2 51 5298129.5 *18* 1224072 M 50.707s][trace][gc,liveness] GC(13) ### 3 5 3223983.6 *31* 176648 M 50.707s][trace][gc,liveness] GC(13) ### 4 5 3022016.3 *32* 176648 M (This depends on PR#26591, so please look at that one first). The change makes sure that three significant digits are printed. Testing: manual review Thanks, Thomas ------------- Depends on: https://git.openjdk.org/jdk/pull/26591 Commit messages: - Merge branch '8364531-factor-out-liveness-code' into 8364532-liveness-significant-digits - * rename liveness() method to more accurate liveness_percent() - 8364532 Changes: https://git.openjdk.org/jdk/pull/26595/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26595&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364532 Stats: 7 lines in 3 files changed: 1 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/26595.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26595/head:pull/26595 PR: https://git.openjdk.org/jdk/pull/26595 From ayang at openjdk.org Mon Aug 4 08:27:01 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 4 Aug 2025 08:27:01 GMT Subject: RFR: 8364531: G1: Factor out liveness tracing code [v3] In-Reply-To: References: Message-ID: <88vIE3WBj9xtSkNOfoJIfy1ORO2E-S9QQGsXQ25xdcE=.2cc066ca-3f80-4d00-8560-e76ab5735204@github.com> On Fri, 1 Aug 2025 13:33:34 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this refactoring, eliminating some copy&paste, in cset candidate group liveness logging. >> >> The output is mostly the same, except for the young cset group, where the "-" has been replaced to just print the default value (0.0) for efficiency. I did not see this important to have, the gc efficiency for young gen isn't interesting. >> >> Testing: local compilation, gha, visual inspection of output >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * more refactoring Marked as reviewed by ayang (Reviewer). src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 3166: > 3164: _total_remset_bytes += g1h->young_regions_cset_group()->card_set()->mem_size(); > 3165: > 3166: G1CollectionSetCandidates * candidates = g1h->policy()->candidates(); Why both spaces around `*`? ------------- PR Review: https://git.openjdk.org/jdk/pull/26591#pullrequestreview-3083189963 PR Review Comment: https://git.openjdk.org/jdk/pull/26591#discussion_r2250770386 From tschatzl at openjdk.org Mon Aug 4 09:45:50 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 4 Aug 2025 09:45:50 GMT Subject: RFR: 8364531: G1: Factor out liveness tracing code [v4] In-Reply-To: References: Message-ID: > Hi all, > > please review this refactoring, eliminating some copy&paste, in cset candidate group liveness logging. > > The output is mostly the same, except for the young cset group, where the "-" has been replaced to just print the default value (0.0) for efficiency. I did not see this important to have, the gc efficiency for young gen isn't interesting. > > Testing: local compilation, gha, visual inspection of output > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * fix typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26591/files - new: https://git.openjdk.org/jdk/pull/26591/files/6f605b70..cb77371d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26591&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26591&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26591.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26591/head:pull/26591 PR: https://git.openjdk.org/jdk/pull/26591 From tschatzl at openjdk.org Mon Aug 4 09:45:52 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 4 Aug 2025 09:45:52 GMT Subject: RFR: 8364531: G1: Factor out liveness tracing code [v3] In-Reply-To: <88vIE3WBj9xtSkNOfoJIfy1ORO2E-S9QQGsXQ25xdcE=.2cc066ca-3f80-4d00-8560-e76ab5735204@github.com> References: <88vIE3WBj9xtSkNOfoJIfy1ORO2E-S9QQGsXQ25xdcE=.2cc066ca-3f80-4d00-8560-e76ab5735204@github.com> Message-ID: On Mon, 4 Aug 2025 08:22:28 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * more refactoring > > src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 3166: > >> 3164: _total_remset_bytes += g1h->young_regions_cset_group()->card_set()->mem_size(); >> 3165: >> 3166: G1CollectionSetCandidates * candidates = g1h->policy()->candidates(); > > Why both spaces around `*`? Typo? Will fix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26591#discussion_r2250953461 From ayang at openjdk.org Mon Aug 4 09:50:53 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 4 Aug 2025 09:50:53 GMT Subject: RFR: 8364531: G1: Factor out liveness tracing code [v4] In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 09:45:50 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this refactoring, eliminating some copy&paste, in cset candidate group liveness logging. >> >> The output is mostly the same, except for the young cset group, where the "-" has been replaced to just print the default value (0.0) for efficiency. I did not see this important to have, the gc efficiency for young gen isn't interesting. >> >> Testing: local compilation, gha, visual inspection of output >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * fix typo Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26591#pullrequestreview-3083454229 From ayang at openjdk.org Mon Aug 4 10:07:24 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 4 Aug 2025 10:07:24 GMT Subject: RFR: 8364628: Serial: Refactor SerialHeap::mem_allocate_work Message-ID: Extract out old-gen allocation outside the critical-region to streamline the flow in `mem_allocate_work`. Test: tier1-5 ------------- Commit messages: - sgc-mem-allocate Changes: https://git.openjdk.org/jdk/pull/26619/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26619&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364628 Stats: 59 lines in 4 files changed: 22 ins; 31 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/26619.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26619/head:pull/26619 PR: https://git.openjdk.org/jdk/pull/26619 From shade at openjdk.org Mon Aug 4 10:47:55 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 4 Aug 2025 10:47:55 GMT Subject: RFR: 8364212: Shenandoah: Rework archived objects loading [v5] In-Reply-To: References: Message-ID: On Sun, 3 Aug 2025 22:37:47 GMT, Kelvin Nilsen wrote: >> The "theory" is that if the remainder of this region is available for allocations, then we should not count the remnant as humongous_waste. Is there any reason why we could not allow additional allocations within the CDS regions? > > I agree that if we need to prevent further allocations in this region, then calling retire_from_partition() will account for the remnant memory as used and will prevent further allocations from this region. > Is there any reason why we could not allow additional allocations within the CDS regions? That code tries to accomplish exactly that, right? We only retire the regions that have too few free space. Otherwise they (well, the tail region, really) stays in mutator partition and can satisfy more allocations. This also avoid dealing with a possibility of having an unallocated tail in that tail region, which might not fit the smallest filler object. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26510#discussion_r2251110956 From tschatzl at openjdk.org Mon Aug 4 11:18:56 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 4 Aug 2025 11:18:56 GMT Subject: RFR: 8364516: Serial: Move class unloading logic inside SerialFullGC::invoke_at_safepoint [v4] In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 08:13:57 GMT, Albert Mingkun Yang wrote: >> Encapsulating classunloading logic inside `invoke_at_safepoint` and adding doc explaining why the classunloading logic can't be placed at the end of marking during full-gc, like other STW collectors. >> >> 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 five additional commits since the last revision: > > - Merge branch 'master' into sgc-unloading-doc > - review > - review > - review > - sgc-unloading-doc Ship it! ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26588#pullrequestreview-3083737607 From ayang at openjdk.org Mon Aug 4 13:03:01 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 4 Aug 2025 13:03:01 GMT Subject: RFR: 8364516: Serial: Move class unloading logic inside SerialFullGC::invoke_at_safepoint [v4] In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 08:13:57 GMT, Albert Mingkun Yang wrote: >> Encapsulating classunloading logic inside `invoke_at_safepoint` and adding doc explaining why the classunloading logic can't be placed at the end of marking during full-gc, like other STW collectors. >> >> 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 five additional commits since the last revision: > > - Merge branch 'master' into sgc-unloading-doc > - review > - review > - review > - sgc-unloading-doc Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26588#issuecomment-3150600421 From ayang at openjdk.org Mon Aug 4 13:03:02 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 4 Aug 2025 13:03:02 GMT Subject: Integrated: 8364516: Serial: Move class unloading logic inside SerialFullGC::invoke_at_safepoint In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 08:47:57 GMT, Albert Mingkun Yang wrote: > Encapsulating classunloading logic inside `invoke_at_safepoint` and adding doc explaining why the classunloading logic can't be placed at the end of marking during full-gc, like other STW collectors. > > Test: tier1-3 This pull request has now been integrated. Changeset: fc475553 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/fc4755535d61c2fd4d9a2c9a673da148f742f035 Stats: 27 lines in 2 files changed: 17 ins; 10 del; 0 mod 8364516: Serial: Move class unloading logic inside SerialFullGC::invoke_at_safepoint Reviewed-by: tschatzl, sangheki ------------- PR: https://git.openjdk.org/jdk/pull/26588 From ayang at openjdk.org Mon Aug 4 13:49:14 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 4 Aug 2025 13:49:14 GMT Subject: RFR: 8364254: Serial: Remove soft ref policy update in WhiteBox FullGC [v2] In-Reply-To: References: Message-ID: > Simple removing Serial specific logic in `WB_FullGC`, because Serial full-gc handles white-box full-gc already. > > 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 sgc-whitebox - sgc-whitebox ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26528/files - new: https://git.openjdk.org/jdk/pull/26528/files/d95ce7ed..7be7d3de Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26528&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26528&range=00-01 Stats: 13614 lines in 375 files changed: 8956 ins; 3887 del; 771 mod Patch: https://git.openjdk.org/jdk/pull/26528.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26528/head:pull/26528 PR: https://git.openjdk.org/jdk/pull/26528 From tschatzl at openjdk.org Mon Aug 4 15:07:26 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 4 Aug 2025 15:07:26 GMT Subject: RFR: 8364642: G1: Remove parameter in G1CollectedHeap::abandon_collection_set() Message-ID: Hi all, please review this small refactoring to remove some parameter that `G1CollectedHeap` already knows anyway. Testing: local compilation, gha Thanks, Thomas ------------- Commit messages: - 8364642 Changes: https://git.openjdk.org/jdk/pull/26622/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26622&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364642 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/26622.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26622/head:pull/26622 PR: https://git.openjdk.org/jdk/pull/26622 From tschatzl at openjdk.org Mon Aug 4 15:54:06 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 4 Aug 2025 15:54:06 GMT Subject: RFR: 8364649: G1: Move collection set related full gc reset code into abandon_collection_set() method Message-ID: Hi all, please review this change that removes all collection set related "abandoning" for full collection into `G1CollectedHeap::abandon_collection_set()`. Otherwise, when needing to search all over the place for the components, it's harder to verify if everything is actually properly handled. Testing: gha Thanks, Thomas ------------- Depends on: https://git.openjdk.org/jdk/pull/26622 Commit messages: - * re-add clearing the attribute table value (not really necessary either way) - 8364649 Changes: https://git.openjdk.org/jdk/pull/26624/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26624&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364649 Stats: 7 lines in 3 files changed: 4 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26624.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26624/head:pull/26624 PR: https://git.openjdk.org/jdk/pull/26624 From sangheki at openjdk.org Mon Aug 4 16:26:55 2025 From: sangheki at openjdk.org (Sangheon Kim) Date: Mon, 4 Aug 2025 16:26:55 GMT Subject: RFR: 8364254: Serial: Remove soft ref policy update in WhiteBox FullGC [v2] In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 13:49:14 GMT, Albert Mingkun Yang wrote: >> Simple removing Serial specific logic in `WB_FullGC`, because Serial full-gc handles white-box full-gc already. >> >> 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 sgc-whitebox > - sgc-whitebox LGTM ------------- Marked as reviewed by sangheki (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26528#pullrequestreview-3084933418 From duke at openjdk.org Mon Aug 4 17:45:12 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 4 Aug 2025 17:45:12 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic Message-ID: Hi all, This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() CPUTimeUsage::GC::gc_threads() CPUTimeUsage::GC::vm_thread() CPUTimeUsage::GC::stringdedup() CPUTimeUsage::Runtime::vm_thread() I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: [12.517s][info][cpu] === CPU time Statistics ============================================================= [12.517s][info][cpu] CPUs [12.517s][info][cpu] s % utilized [12.517s][info][cpu] Process [12.517s][info][cpu] Total 175.7628 100.00 14.0 [12.517s][info][cpu] VM Thread 7.0000 3.98 0.6 [12.517s][info][cpu] Garbage Collection 72.0000 40.96 5.8 [12.517s][info][cpu] GC Threads 70.0000 39.83 5.6 [12.517s][info][cpu] VM Thread 1.0000 0.57 0.1 [12.518s][info][cpu] String Deduplication 0.0000 0.00 0.0 [12.518s][info][cpu] ===================================================================================== Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. ------------- Commit messages: - Make GC CPU time framework generic Changes: https://git.openjdk.org/jdk/pull/26621/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364638 Stats: 229 lines in 11 files changed: 170 ins; 44 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/26621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621 PR: https://git.openjdk.org/jdk/pull/26621 From duke at openjdk.org Mon Aug 4 19:34:01 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 4 Aug 2025 19:34:01 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v2] In-Reply-To: References: Message-ID: > Hi all, > > This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). > > As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: > > CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() > > CPUTimeUsage::GC::gc_threads() > CPUTimeUsage::GC::vm_thread() > CPUTimeUsage::GC::stringdedup() > > CPUTimeUsage::Runtime::vm_thread() > > > I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. > > I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: > > > [12.517s][info][cpu] === CPU time Statistics ============================================================= > [12.517s][info][cpu] CPUs > [12.517s][info][cpu] s % utilized > [12.517s][info][cpu] Process > [12.517s][info][cpu] Total 175.7628 100.00 14.0 > [12.517s][info][cpu] VM Thread 7.0000 3.98 0.6 > [12.517s][info][cpu] Garbage Collection 72.0000 40.96 5.8 > [12.517s][info][cpu] GC Threads 70.0000 39.83 5.6 > [12.517s][info][cpu] VM Thread 1.0000 0.57 0.1 > [12.518s][info][cpu] String Deduplication 0.0000 0.00 0.0 > [12.518s][info][cpu] ===================================================================================== > > > Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Remove assert which may not hold in tests that exists very fast It takes some time before the OS updates the underlying counters so process CPU time may be out of sync with regards to magnitude order compared to thread CPU time ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26621/files - new: https://git.openjdk.org/jdk/pull/26621/files/4f74c2bd..6a6e3996 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621 PR: https://git.openjdk.org/jdk/pull/26621 From duke at openjdk.org Mon Aug 4 19:53:24 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 4 Aug 2025 19:53:24 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v3] In-Reply-To: References: Message-ID: > Hi all, > > This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). > > As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: > > CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() > > CPUTimeUsage::GC::gc_threads() > CPUTimeUsage::GC::vm_thread() > CPUTimeUsage::GC::stringdedup() > > CPUTimeUsage::Runtime::vm_thread() > > > I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. > > I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: > > > [12.517s][info][cpu] === CPU time Statistics ============================================================= > [12.517s][info][cpu] CPUs > [12.517s][info][cpu] s % utilized > [12.517s][info][cpu] Process > [12.517s][info][cpu] Total 175.7628 100.00 14.0 > [12.517s][info][cpu] VM Thread 7.0000 3.98 0.6 > [12.517s][info][cpu] Garbage Collection 72.0000 40.96 5.8 > [12.517s][info][cpu] GC Threads 70.0000 39.83 5.6 > [12.517s][info][cpu] VM Thread 1.0000 0.57 0.1 > [12.518s][info][cpu] String Deduplication 0.0000 0.00 0.0 > [12.518s][info][cpu] ===================================================================================== > > > Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Prefer returning 0 over +/-inf,nan ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26621/files - new: https://git.openjdk.org/jdk/pull/26621/files/6a6e3996..216ba811 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621 PR: https://git.openjdk.org/jdk/pull/26621 From sangheki at openjdk.org Mon Aug 4 20:05:06 2025 From: sangheki at openjdk.org (Sangheon Kim) Date: Mon, 4 Aug 2025 20:05:06 GMT Subject: RFR: 8364531: G1: Factor out liveness tracing code [v4] In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 09:45:50 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this refactoring, eliminating some copy&paste, in cset candidate group liveness logging. >> >> The output is mostly the same, except for the young cset group, where the "-" has been replaced to just print the default value (0.0) for efficiency. I did not see this important to have, the gc efficiency for young gen isn't interesting. >> >> Testing: local compilation, gha, visual inspection of output >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * fix typo Looks good as is. This might be a preference thing. log_xxx_group() doesn't update _total_remset_bytes while log_xxx_grouplist() updates it. It might be better to update it from log_xxx_group() with or without proper name change? e.g. append_total_and_log_cset_candidate() ------------- Marked as reviewed by sangheki (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26591#pullrequestreview-3085582595 From dlong at openjdk.org Mon Aug 4 21:22:57 2025 From: dlong at openjdk.org (Dean Long) Date: Mon, 4 Aug 2025 21:22:57 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v4] In-Reply-To: References: Message-ID: > This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value. Further, it takes a fast-path that uses the previous direct store when at a safepoint. Combined, these changes should get us back to almost where we were before in terms of overhead. If necessary, we could go even further and allow make_not_entrant() to perform a direct byte store, leaving 24 bits for the guard value. Dean Long has updated the pull request incrementally with one additional commit since the last revision: skip icache flush if nothing changed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26399/files - new: https://git.openjdk.org/jdk/pull/26399/files/a06b3446..840750ab Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26399&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26399&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26399.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26399/head:pull/26399 PR: https://git.openjdk.org/jdk/pull/26399 From dlong at openjdk.org Mon Aug 4 21:26:22 2025 From: dlong at openjdk.org (Dean Long) Date: Mon, 4 Aug 2025 21:26:22 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v5] In-Reply-To: References: Message-ID: > This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value. Further, it takes a fast-path that uses the previous direct store when at a safepoint. Combined, these changes should get us back to almost where we were before in terms of overhead. If necessary, we could go even further and allow make_not_entrant() to perform a direct byte store, leaving 24 bits for the guard value. Dean Long has updated the pull request incrementally with one additional commit since the last revision: one unconditional release should be enough ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26399/files - new: https://git.openjdk.org/jdk/pull/26399/files/840750ab..d9e93db3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26399&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26399&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26399.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26399/head:pull/26399 PR: https://git.openjdk.org/jdk/pull/26399 From dlong at openjdk.org Mon Aug 4 21:26:23 2025 From: dlong at openjdk.org (Dean Long) Date: Mon, 4 Aug 2025 21:26:23 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v3] In-Reply-To: References: <_8Z-PXaFqGay1pHqcJmeWXrOFv4QQVqnJG2RuZ7rzTk=.34cc6ecb-e189-461c-971b-f59f899372f5@github.com> Message-ID: <31qxrkcScTxkk9gjEGGuEZEyCnpLe9VapvbgIpOTpow=.5a8777ab-35bf-48e2-8900-3d6ed5c19cf7@github.com> On Fri, 1 Aug 2025 21:38:11 GMT, Martin Doerr wrote: >> Dean Long has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix PPC64 > > src/hotspot/cpu/ppc/gc/shared/barrierSetNMethod_ppc.cpp line 84: > >> 82: nativeMovRegMem_at(new_mov_instr.buf)->set_offset(new_value, false /* no icache flush */); >> 83: // Swap in the new value >> 84: uint64_t v = Atomic::cmpxchg(instr, old_mov_instr.u64, new_mov_instr.u64, memory_order_release); > > We have `OrderAccess::release()` above, so `memory_order_release` looks redundant. Shouldn't we use `memory_order_relaxed`, here? I think you are right. But your question about release is making me wonder if we need acquire as well. For example if two threads are racing to disarm, is there a memory visibility problem if we do not use acquire for the CAS, or if we did the release only on a successful CAS? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26399#discussion_r2252604613 From mdoerr at openjdk.org Mon Aug 4 21:50:09 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 4 Aug 2025 21:50:09 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v3] In-Reply-To: <31qxrkcScTxkk9gjEGGuEZEyCnpLe9VapvbgIpOTpow=.5a8777ab-35bf-48e2-8900-3d6ed5c19cf7@github.com> References: <_8Z-PXaFqGay1pHqcJmeWXrOFv4QQVqnJG2RuZ7rzTk=.34cc6ecb-e189-461c-971b-f59f899372f5@github.com> <31qxrkcScTxkk9gjEGGuEZEyCnpLe9VapvbgIpOTpow=.5a8777ab-35bf-48e2-8900-3d6ed5c19cf7@github.com> Message-ID: On Mon, 4 Aug 2025 21:22:12 GMT, Dean Long wrote: >> src/hotspot/cpu/ppc/gc/shared/barrierSetNMethod_ppc.cpp line 84: >> >>> 82: nativeMovRegMem_at(new_mov_instr.buf)->set_offset(new_value, false /* no icache flush */); >>> 83: // Swap in the new value >>> 84: uint64_t v = Atomic::cmpxchg(instr, old_mov_instr.u64, new_mov_instr.u64, memory_order_release); >> >> We have `OrderAccess::release()` above, so `memory_order_release` looks redundant. Shouldn't we use `memory_order_relaxed`, here? > > I think you are right. But your question about release is making me wonder if we need acquire as well. For example if two threads are racing to disarm, is there a memory visibility problem if we do not use acquire for the CAS, or if we do the release only on a successful CAS on the other platforms. Correct. The acquire barrier is at the end of the nmethod entry barrier: https://github.com/openjdk/jdk/blob/f96b6bcd4ddbb1d0e0a76d9f4e3b43bec20dcb7a/src/hotspot/cpu/ppc/gc/shared/barrierSetAssembler_ppc.cpp#L203 It's not needed if we use a GC with `stw_instruction_and_data_patch`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26399#discussion_r2252641681 From dcubed at openjdk.org Mon Aug 4 23:31:09 2025 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 4 Aug 2025 23:31:09 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v3] In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 19:53:24 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). >> >> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: >> >> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() >> >> CPUTimeUsage::GC::gc_threads() >> CPUTimeUsage::GC::vm_thread() >> CPUTimeUsage::GC::stringdedup() >> >> CPUTimeUsage::Runtime::vm_thread() >> >> >> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. >> >> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: >> >> >> [12.517s][info][cpu] === CPU time Statistics ============================================================= >> [12.517s][info][cpu] CPUs >> [12.517s][info][cpu] s % utilized >> [12.517s][info][cpu] Process >> [12.517s][info][cpu] Total 175.7628 100.00 14.0 >> [12.517s][info][cpu] VM Thread 7.0000 3.98 0.6 >> [12.517s][info][cpu] Garbage Collection 72.0000 40.96 5.8 >> [12.517s][info][cpu] GC Threads 70.0000 39.83 5.6 >> [12.517s][info][cpu] VM Thread 1.0000 0.57 0.1 >> [12.518s][info][cpu] String Deduplication 0.0000 0.00 0.0 >> [12.518s][info][cpu] ===================================================================================== >> >> >> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Prefer returning 0 over +/-inf,nan Seems like JVM/TI folks will be interested also. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26621#issuecomment-3152782164 From dholmes at openjdk.org Tue Aug 5 06:45:02 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 5 Aug 2025 06:45:02 GMT Subject: RFR: 8364518: Support for Job Objects in os::commit_memory_limit() on Windows [v2] In-Reply-To: <1yjYw2L7Jta-_-v0KPNcvz8wS9arjOCzvrwQpZ6sP6k=.186ac2f0-6d5f-4dd6-bcdb-839841847f25@github.com> References: <1yjYw2L7Jta-_-v0KPNcvz8wS9arjOCzvrwQpZ6sP6k=.186ac2f0-6d5f-4dd6-bcdb-839841847f25@github.com> Message-ID: On Mon, 4 Aug 2025 07:40:12 GMT, Joel Sikstr?m wrote: >> Hello, >> >> We currently use os::commit_memory_limit() to limit the initial, min and max values when ergonomically setting the heap size. Right now, os::commit_memory_limit() returns the available virtual address space on Windows, which is guaranteed to be the upper-bound of how much memory can be committed. However, this does not take into account user-configurable limits. >> >> I propose revising os::commit_memory_limit() to consider Windows Job Objects. Job Objects can, among other things, restrict the amount of memory that can be committed by a single process or all processes in a job. If we are unable to query Job Object information or if no limit is set, I suggest returning SIZE_MAX, since the next effective limit is the available virtual address space. The size of this virtual address space cannot be modified by the user, except by consuming it. >> >> For more details and short examples, I have created a GitHub repository summarizing my findings regarding memory limits and Job Objects on Windows: [https://github.com/jsikstro/MemoryLimitsWindows ](https://github.com/jsikstro/MemoryLimitsWindows). >> >> Adding support for Job Objects in this way adds support for detecting memory limits when using native Windows Hyper-V containers, which uses Job Objects to limit memory. >> >> Testing: >> * Oracle's tier1-2 >> * Manual testing on Windows using both [Process Governor](https://github.com/lowleveldesign/process-governor) (a popular tool), and creating a Job Object manually. > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > Print error message if query fails I can't help but think that this should be part of a broader effort to support "containers" on Windows. We allowed the use of JobObjects for the processor count because it was similar what you could do with cpu-sets on Linux and not fundamentally "container" related. What you propose here looks good, but surely there are more things that need to be adjusted to account for JobObjects in this space? Case in point I just raised a query today about why we have a confused notion of "physical memory" on Linux, depending on whether you are running in a container or not. I would suspect a similar distinction would need to be made on Windows if running under JobObjects. To be clear I have no issue with the current PR providing this part of Windows "container" support, but I would like to see at least an Umbrella JBS issue (JEP?) created to cover everything that would be needed for such support. Thanks ------------- PR Comment: https://git.openjdk.org/jdk/pull/26593#issuecomment-3153708050 From dholmes at openjdk.org Tue Aug 5 06:48:06 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 5 Aug 2025 06:48:06 GMT Subject: RFR: 8364518: Support for Job Objects in os::commit_memory_limit() on Windows [v2] In-Reply-To: <1yjYw2L7Jta-_-v0KPNcvz8wS9arjOCzvrwQpZ6sP6k=.186ac2f0-6d5f-4dd6-bcdb-839841847f25@github.com> References: <1yjYw2L7Jta-_-v0KPNcvz8wS9arjOCzvrwQpZ6sP6k=.186ac2f0-6d5f-4dd6-bcdb-839841847f25@github.com> Message-ID: On Mon, 4 Aug 2025 07:40:12 GMT, Joel Sikstr?m wrote: >> Hello, >> >> We currently use os::commit_memory_limit() to limit the initial, min and max values when ergonomically setting the heap size. Right now, os::commit_memory_limit() returns the available virtual address space on Windows, which is guaranteed to be the upper-bound of how much memory can be committed. However, this does not take into account user-configurable limits. >> >> I propose revising os::commit_memory_limit() to consider Windows Job Objects. Job Objects can, among other things, restrict the amount of memory that can be committed by a single process or all processes in a job. If we are unable to query Job Object information or if no limit is set, I suggest returning SIZE_MAX, since the next effective limit is the available virtual address space. The size of this virtual address space cannot be modified by the user, except by consuming it. >> >> For more details and short examples, I have created a GitHub repository summarizing my findings regarding memory limits and Job Objects on Windows: [https://github.com/jsikstro/MemoryLimitsWindows ](https://github.com/jsikstro/MemoryLimitsWindows). >> >> Adding support for Job Objects in this way adds support for detecting memory limits when using native Windows Hyper-V containers, which uses Job Objects to limit memory. >> >> Testing: >> * Oracle's tier1-2 >> * Manual testing on Windows using both [Process Governor](https://github.com/lowleveldesign/process-governor) (a popular tool), and creating a Job Object manually. > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > Print error message if query fails src/hotspot/os/windows/os_windows.cpp line 3321: > 3319: > 3320: // No limit > 3321: return SIZE_MAX; Shouldn't we fallback to using ` GlobalMemoryStatusEx` if we are not part of a Job? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26593#discussion_r2253314501 From tschatzl at openjdk.org Tue Aug 5 08:02:36 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 5 Aug 2025 08:02:36 GMT Subject: RFR: 8364531: G1: Factor out liveness tracing code [v5] In-Reply-To: References: Message-ID: > Hi all, > > please review this refactoring, eliminating some copy&paste, in cset candidate group liveness logging. > > The output is mostly the same, except for the young cset group, where the "-" has been replaced to just print the default value (0.0) for efficiency. I did not see this important to have, the gc efficiency for young gen isn't interesting. > > Testing: local compilation, gha, visual inspection of output > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * sangheon review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26591/files - new: https://git.openjdk.org/jdk/pull/26591/files/cb77371d..6c51c941 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26591&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26591&range=03-04 Stats: 6 lines in 2 files changed: 1 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26591.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26591/head:pull/26591 PR: https://git.openjdk.org/jdk/pull/26591 From tschatzl at openjdk.org Tue Aug 5 08:02:53 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 5 Aug 2025 08:02:53 GMT Subject: RFR: 8364531: G1: Factor out liveness tracing code [v4] In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 20:02:13 GMT, Sangheon Kim wrote: > Looks good as is. > > This might be a preference thing. log_xxx_group() doesn't update _total_remset_bytes while log_xxx_grouplist() updates it. It might be better to update it from log_xxx_group() with or without proper name change? e.g. append_total_and_log_cset_candidate() I originally considered that then did not do, fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26591#issuecomment-3154001490 From jsikstro at openjdk.org Tue Aug 5 08:27:04 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Tue, 5 Aug 2025 08:27:04 GMT Subject: RFR: 8364518: Support for Job Objects in os::commit_memory_limit() on Windows [v2] In-Reply-To: References: <1yjYw2L7Jta-_-v0KPNcvz8wS9arjOCzvrwQpZ6sP6k=.186ac2f0-6d5f-4dd6-bcdb-839841847f25@github.com> Message-ID: On Tue, 5 Aug 2025 06:45:50 GMT, David Holmes wrote: >> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: >> >> Print error message if query fails > > src/hotspot/os/windows/os_windows.cpp line 3321: > >> 3319: >> 3320: // No limit >> 3321: return SIZE_MAX; > > Shouldn't we fallback to using ` GlobalMemoryStatusEx` if we are not part of a Job? In [https://github.com/openjdk/jdk/pull/26530 ](https://github.com/openjdk/jdk/pull/26530) (concerning the implementation of os::commit_memory_limit and os::reserve_memory_limit), we return SIZE_MAX to indicate that there is no limit imposed by the user or system. We could potentially fall back to using `GlobalMemoryStatusEx`, which may be more accurate than returning SIZE_MAX. However, I think it is rare that there is a practical difference between using SIZE_MAX and the size of the available virtual address space, since both are typically very large values. If you or others feel strongly about falling back to reporting the size of available virtual address space from `GlobalMemoryStatusEx`, I?m open to that approach. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26593#discussion_r2253538357 From jsikstro at openjdk.org Tue Aug 5 08:34:06 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Tue, 5 Aug 2025 08:34:06 GMT Subject: RFR: 8364518: Support for Job Objects in os::commit_memory_limit() on Windows [v2] In-Reply-To: References: <1yjYw2L7Jta-_-v0KPNcvz8wS9arjOCzvrwQpZ6sP6k=.186ac2f0-6d5f-4dd6-bcdb-839841847f25@github.com> Message-ID: <6zPK6VWlzyk7vhdIYcIzgtdaSsZNubUTpFR6gZSYAlY=.b15fd2e6-b088-4eb0-905b-97f1cd58082d@github.com> On Tue, 5 Aug 2025 06:42:43 GMT, David Holmes wrote: >> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: >> >> Print error message if query fails > > I can't help but think that this should be part of a broader effort to support "containers" on Windows. We allowed the use of JobObjects for the processor count because it was similar what you could do with cpu-sets on Linux and not fundamentally "container" related. What you propose here looks good, but surely there are more things that need to be adjusted to account for JobObjects in this space? Case in point I just raised a query today about why we have a confused notion of "physical memory" on Linux, depending on whether you are running in a container or not. I would suspect a similar distinction would need to be made on Windows if running under JobObjects. > > To be clear I have no issue with the current PR providing this part of Windows "container" support, but I would like to see at least an Umbrella JBS issue (JEP?) created to cover everything that would be needed for such support. Thanks Thank you for your input @dholmes-ora, and I agree that broader support for Job Objects, and by extension, native Windows containers, are possible in this space. I have nothing against creating an umbrella issue that covers adding support for native Windows containers. However, such containers were not my main focus, but an added benefit I suppose. Using the size of the available virtual address space is a good indicator on how much memory can be committed, and will always be the absolute upper-bound. However, reading limits set by Job Object(s) is more complete IMO, since it (is the only way to?) limits how much memory can be committed, which is what this function is aiming to answer. So even though I think this overlaps with native Windows container support, I think this is a standalone enhancement as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26593#issuecomment-3154096676 From tschatzl at openjdk.org Tue Aug 5 09:09:27 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 5 Aug 2025 09:09:27 GMT Subject: RFR: 8364531: G1: Factor out liveness tracing code [v6] In-Reply-To: References: Message-ID: > Hi all, > > please review this refactoring, eliminating some copy&paste, in cset candidate group liveness logging. > > The output is mostly the same, except for the young cset group, where the "-" has been replaced to just print the default value (0.0) for efficiency. I did not see this important to have, the gc efficiency for young gen isn't interesting. > > Testing: local compilation, gha, visual inspection of output > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * ayang review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26591/files - new: https://git.openjdk.org/jdk/pull/26591/files/6c51c941..cc413ce7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26591&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26591&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26591.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26591/head:pull/26591 PR: https://git.openjdk.org/jdk/pull/26591 From mdoerr at openjdk.org Tue Aug 5 10:16:06 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 5 Aug 2025 10:16:06 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v5] In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 21:26:22 GMT, Dean Long wrote: >> This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value. Further, it takes a fast-path that uses the previous direct store when at a safepoint. Combined, these changes should get us back to almost where we were before in terms of overhead. If necessary, we could go even further and allow make_not_entrant() to perform a direct byte store, leaving 24 bits for the guard value. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > one unconditional release should be enough Thanks for implementing nice code for PPC64! I appreciate it! The shared code and the other platforms look fine, too. Maybe atomic bitwise operations could be used, but I'm happy with your current solution. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26399#pullrequestreview-3087610323 From ayang at openjdk.org Tue Aug 5 10:22:18 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 5 Aug 2025 10:22:18 GMT Subject: RFR: 8364722: Parallel: Move CLDG mark clearing to the end of full GC Message-ID: <3CdNhrwzi0I4FbPMgs1BSZzQi8nKC39gH7L3XksP0RA=.4af75b5a-4ad7-42f7-b14c-f95a41b84849@github.com> Move ClassLoaderDataGraph claim-mark clearing to `post_compact` (the end of full-gc), to be more aligned with other GCs. Test: tier1-3 ------------- Commit messages: - pgc-reset-claim Changes: https://git.openjdk.org/jdk/pull/26637/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26637&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364722 Stats: 6 lines in 1 file changed: 3 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26637.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26637/head:pull/26637 PR: https://git.openjdk.org/jdk/pull/26637 From tschatzl at openjdk.org Tue Aug 5 10:32:04 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 5 Aug 2025 10:32:04 GMT Subject: RFR: 8364722: Parallel: Move CLDG mark clearing to the end of full GC In-Reply-To: <3CdNhrwzi0I4FbPMgs1BSZzQi8nKC39gH7L3XksP0RA=.4af75b5a-4ad7-42f7-b14c-f95a41b84849@github.com> References: <3CdNhrwzi0I4FbPMgs1BSZzQi8nKC39gH7L3XksP0RA=.4af75b5a-4ad7-42f7-b14c-f95a41b84849@github.com> Message-ID: On Tue, 5 Aug 2025 10:13:53 GMT, Albert Mingkun Yang wrote: > Move ClassLoaderDataGraph claim-mark clearing to `post_compact` (the end of full-gc), to be more aligned with other GCs. > > Test: tier1-3 Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26637#pullrequestreview-3087675563 From ayang at openjdk.org Tue Aug 5 10:42:08 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 5 Aug 2025 10:42:08 GMT Subject: RFR: 8364254: Serial: Remove soft ref policy update in WhiteBox FullGC [v2] In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 13:49:14 GMT, Albert Mingkun Yang wrote: >> Simple removing Serial specific logic in `WB_FullGC`, because Serial full-gc handles white-box full-gc already. >> >> 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 sgc-whitebox > - sgc-whitebox Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26528#issuecomment-3154564288 From ayang at openjdk.org Tue Aug 5 10:46:08 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 5 Aug 2025 10:46:08 GMT Subject: Integrated: 8364254: Serial: Remove soft ref policy update in WhiteBox FullGC In-Reply-To: References: Message-ID: <0TwYYkT3Exg_w78Ku8Dv5ugVgDl22eGDsx1Y2zVoccA=.273195b8-cb8c-434a-87ac-d1d20623a8c0@github.com> On Tue, 29 Jul 2025 09:37:26 GMT, Albert Mingkun Yang wrote: > Simple removing Serial specific logic in `WB_FullGC`, because Serial full-gc handles white-box full-gc already. > > Test: tier1-3 This pull request has now been integrated. Changeset: ba0ae4cb Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/ba0ae4cb28aa520d5244077349e35ef1bb475b61 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8364254: Serial: Remove soft ref policy update in WhiteBox FullGC Reviewed-by: tschatzl, sangheki ------------- PR: https://git.openjdk.org/jdk/pull/26528 From ayang at openjdk.org Tue Aug 5 11:04:03 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 5 Aug 2025 11:04:03 GMT Subject: RFR: 8364531: G1: Factor out liveness tracing code [v6] In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 09:09:27 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this refactoring, eliminating some copy&paste, in cset candidate group liveness logging. >> >> The output is mostly the same, except for the young cset group, where the "-" has been replaced to just print the default value (0.0) for efficiency. I did not see this important to have, the gc efficiency for young gen isn't interesting. >> >> Testing: local compilation, gha, visual inspection of output >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * ayang review Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26591#pullrequestreview-3087783778 From ayang at openjdk.org Tue Aug 5 13:26:15 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 5 Aug 2025 13:26:15 GMT Subject: RFR: 8364642: G1: Remove parameter in G1CollectedHeap::abandon_collection_set() In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 15:00:29 GMT, Thomas Schatzl wrote: > Hi all, > > please review this small refactoring to remove some parameter that `G1CollectedHeap` already knows anyway. > > Testing: local compilation, gha > > Thanks, > Thomas Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26622#pullrequestreview-3088262995 From tschatzl at openjdk.org Tue Aug 5 16:16:11 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 5 Aug 2025 16:16:11 GMT Subject: RFR: 8364531: G1: Factor out liveness tracing code [v6] In-Reply-To: References: Message-ID: <6j0Xv-qaK709xhgHxEB6RtUxBT_B5W84cfRscpGZaN0=.18267a14-6869-4c35-9df8-b3576dcc48a2@github.com> On Tue, 5 Aug 2025 11:01:25 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * ayang review > > Marked as reviewed by ayang (Reviewer). Thanks @albertnetymk @sangheon for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/26591#issuecomment-3155771944 From tschatzl at openjdk.org Tue Aug 5 16:16:12 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 5 Aug 2025 16:16:12 GMT Subject: Integrated: 8364531: G1: Factor out liveness tracing code In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 10:31:43 GMT, Thomas Schatzl wrote: > Hi all, > > please review this refactoring, eliminating some copy&paste, in cset candidate group liveness logging. > > The output is mostly the same, except for the young cset group, where the "-" has been replaced to just print the default value (0.0) for efficiency. I did not see this important to have, the gc efficiency for young gen isn't interesting. > > Testing: local compilation, gha, visual inspection of output > > Thanks, > Thomas This pull request has now been integrated. Changeset: d906e450 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/d906e45026f54fe7102e531d3753adc32ff0025c Stats: 76 lines in 2 files changed: 27 ins; 40 del; 9 mod 8364531: G1: Factor out liveness tracing code Reviewed-by: ayang, sangheki ------------- PR: https://git.openjdk.org/jdk/pull/26591 From tschatzl at openjdk.org Tue Aug 5 16:19:23 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 5 Aug 2025 16:19:23 GMT Subject: RFR: 8364760: G1: Remove obsolete code in G1MergeCardSetClosure Message-ID: Hi all, please review this removal of some obsolete code. Before JDK-8343782 G1 iterated remsets for humongous eager reclaim candidates by region, as there has been a 1:1 mapping between regions and (card-based) remembered sets. With that change, all remembered set iteration should go via the group remsets (`G1CSetCandidateGroup`), and the code does, except for humongous eager reclaim candidates which handle their group remsets on the side (which is a separate issue). This obsoleted some code in `G1MergeCardSetClosure` - it does not need to be a `G1HeapRegionClosure` any more, and for humongous regions we can directly do the iteration via the group rem set attached to the humongous starts region. I.e. inline that `merge_card_set_for_region()` method. Testing: gha Thanks, Thomas ------------- Commit messages: - 8364760 Changes: https://git.openjdk.org/jdk/pull/26645/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26645&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364760 Stats: 38 lines in 1 file changed: 0 ins; 35 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26645.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26645/head:pull/26645 PR: https://git.openjdk.org/jdk/pull/26645 From tschatzl at openjdk.org Tue Aug 5 16:26:38 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 5 Aug 2025 16:26:38 GMT Subject: RFR: 8364532: G1: In liveness tracing, print more significant digits for the liveness value [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review this small change that adds some more significant digits (3 in total) for the "liveness" column in collection set group logging. > > E.g. see the emphasized columns that lack precision (it's more irritating with lots of lines showing single-digit values): > > 50.707s][trace][gc,liveness] GC(13) ### groud-id num-regions gc-eff liveness remset type > 50.707s][trace][gc,liveness] GC(13) ### (bytes/ms) % (bytes) > 50.707s][trace][gc,liveness] GC(13) ### 1 70 0.0 *100* 3199208 Y > 50.707s][trace][gc,liveness] GC(13) ### 2 51 5298129.5 *18* 1224072 M > 50.707s][trace][gc,liveness] GC(13) ### 3 5 3223983.6 *31* 176648 M > 50.707s][trace][gc,liveness] GC(13) ### 4 5 3022016.3 *32* 176648 M > > > (This depends on PR#26591, so please look at that one first). > > The change makes sure that three significant digits are printed. > > Testing: manual review > > Thanks, > Thomas Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Merge branch '8364531-factor-out-liveness-code' into 8364532-liveness-significant-digits - * use one line per parameter in log message - * rename liveness() method to more accurate liveness_percent() - 8364532 Hi all, please review this small change that adds some more significant digits (3 in total) for the "liveness" column in collection set group logging Testing: manual testing Thanks, Thomas - 8364531 Hi all, please review this refactoring, eliminating some copy&paste, in cset candidate group liveness logging. The output is mostly the same, except for the young cset group, where the "-" has been replaced to just print the default value (0.0) for efficiency. I did not see this important to have, the gc efficiency for young gen isn't interesting. Testing: local compilation, gha, visual inspection of output Thanks, Thomas ------------- Changes: https://git.openjdk.org/jdk/pull/26595/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26595&range=01 Stats: 67 lines in 4 files changed: 21 ins; 36 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/26595.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26595/head:pull/26595 PR: https://git.openjdk.org/jdk/pull/26595 From zgu at openjdk.org Tue Aug 5 17:43:03 2025 From: zgu at openjdk.org (Zhengyu Gu) Date: Tue, 5 Aug 2025 17:43:03 GMT Subject: RFR: 8364722: Parallel: Move CLDG mark clearing to the end of full GC In-Reply-To: <3CdNhrwzi0I4FbPMgs1BSZzQi8nKC39gH7L3XksP0RA=.4af75b5a-4ad7-42f7-b14c-f95a41b84849@github.com> References: <3CdNhrwzi0I4FbPMgs1BSZzQi8nKC39gH7L3XksP0RA=.4af75b5a-4ad7-42f7-b14c-f95a41b84849@github.com> Message-ID: <6353l4QBGaNP0SJuuRdAGqA3H5EP0HXBUZ-Hg49Vf_4=.2146737e-052a-44a2-9ea9-7c501503d992@github.com> On Tue, 5 Aug 2025 10:13:53 GMT, Albert Mingkun Yang wrote: > Move ClassLoaderDataGraph claim-mark clearing to `post_compact` (the end of full-gc), to be more aligned with other GCs. > > Test: tier1-3 LGTM ------------- Marked as reviewed by zgu (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26637#pullrequestreview-3089158077 From ayang at openjdk.org Tue Aug 5 18:26:18 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 5 Aug 2025 18:26:18 GMT Subject: RFR: 8364767: G1: Remove use of CollectedHeap::_soft_ref_policy Message-ID: Use gc-cause checking in `VM_G1CollectFull` to decide soft-ref policy. Test: tier1-3 ------------- Commit messages: - g1-soft-refs Changes: https://git.openjdk.org/jdk/pull/26648/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26648&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364767 Stats: 42 lines in 6 files changed: 4 ins; 35 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26648.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26648/head:pull/26648 PR: https://git.openjdk.org/jdk/pull/26648 From shade at openjdk.org Tue Aug 5 18:37:11 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 5 Aug 2025 18:37:11 GMT Subject: RFR: 8364212: Shenandoah: Rework archived objects loading [v5] In-Reply-To: References: Message-ID: <2qH9wp5hspi3MDhW3X2KPZwb3_xCIrLhKUncwsArIcE=.a598f20e-2ba5-4a10-b44d-09c0c799ce6f@github.com> On Fri, 1 Aug 2025 07:30:40 GMT, Aleksey Shipilev wrote: >> As continuation of [JDK-8293650](https://bugs.openjdk.org/browse/JDK-8293650), we would want to avoid allocating CDS archives as humongous regions and then flipping them back to regular state. This already complicates the region accounting significantly, and was a source a few bugs. We can rework the CDS archive load to cleanly ask collector for a contiguous set of regular regions. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` >> - [x] Linux x86_64 server fastdebug, `runtime/cds` >> - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC` >> - [x] Linux x86_64 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 eight additional commits since the last revision: > > - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs > - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs > - Do not fill out the entire regions > - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs > - A bit more verification > - Fix > - Fix > - Regular CDS Thanks for reviews. I am integrating to let Kelvin rebase his accounting changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26510#issuecomment-3156184478 From shade at openjdk.org Tue Aug 5 18:37:12 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 5 Aug 2025 18:37:12 GMT Subject: Integrated: 8364212: Shenandoah: Rework archived objects loading In-Reply-To: References: Message-ID: On Mon, 28 Jul 2025 15:36:22 GMT, Aleksey Shipilev wrote: > As continuation of [JDK-8293650](https://bugs.openjdk.org/browse/JDK-8293650), we would want to avoid allocating CDS archives as humongous regions and then flipping them back to regular state. This already complicates the region accounting significantly, and was a source a few bugs. We can rework the CDS archive load to cleanly ask collector for a contiguous set of regular regions. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` > - [x] Linux x86_64 server fastdebug, `runtime/cds` > - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC` > - [x] Linux x86_64 server fastdebug, `all` This pull request has now been integrated. Changeset: 68a35511 Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/68a35511ebd3fd77716242db973104657bc7b541 Stats: 115 lines in 6 files changed: 42 ins; 39 del; 34 mod 8364212: Shenandoah: Rework archived objects loading Reviewed-by: wkemper, kdnilsen ------------- PR: https://git.openjdk.org/jdk/pull/26510 From tschatzl at openjdk.org Tue Aug 5 21:57:41 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 5 Aug 2025 21:57:41 GMT Subject: RFR: 8364532: G1: In liveness tracing, print more significant digits for the liveness value [v3] In-Reply-To: References: Message-ID: > Hi all, > > please review this small change that adds some more significant digits (3 in total) for the "liveness" column in collection set group logging. > > E.g. see the emphasized columns that lack precision (it's more irritating with lots of lines showing single-digit values): > > 50.707s][trace][gc,liveness] GC(13) ### groud-id num-regions gc-eff liveness remset type > 50.707s][trace][gc,liveness] GC(13) ### (bytes/ms) % (bytes) > 50.707s][trace][gc,liveness] GC(13) ### 1 70 0.0 *100* 3199208 Y > 50.707s][trace][gc,liveness] GC(13) ### 2 51 5298129.5 *18* 1224072 M > 50.707s][trace][gc,liveness] GC(13) ### 3 5 3223983.6 *31* 176648 M > 50.707s][trace][gc,liveness] GC(13) ### 4 5 3022016.3 *32* 176648 M > > > (This depends on PR#26591, so please look at that one first). > > The change makes sure that three significant digits are printed. > > Testing: manual review > > Thanks, > Thomas Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge branch 'master' into 8364532-liveness-significant-digits - Merge branch '8364531-factor-out-liveness-code' into 8364532-liveness-significant-digits - * use one line per parameter in log message - * rename liveness() method to more accurate liveness_percent() - 8364532 Hi all, please review this small change that adds some more significant digits (3 in total) for the "liveness" column in collection set group logging Testing: manual testing Thanks, Thomas - 8364531 Hi all, please review this refactoring, eliminating some copy&paste, in cset candidate group liveness logging. The output is mostly the same, except for the young cset group, where the "-" has been replaced to just print the default value (0.0) for efficiency. I did not see this important to have, the gc efficiency for young gen isn't interesting. Testing: local compilation, gha, visual inspection of output Thanks, Thomas ------------- Changes: https://git.openjdk.org/jdk/pull/26595/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26595&range=02 Stats: 7 lines in 3 files changed: 1 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/26595.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26595/head:pull/26595 PR: https://git.openjdk.org/jdk/pull/26595 From tschatzl at openjdk.org Tue Aug 5 21:59:00 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 5 Aug 2025 21:59:00 GMT Subject: RFR: 8342382: Implementation of JEP G1: Improve Application Throughput with a More Efficient Write-Barrier [v46] In-Reply-To: References: Message-ID: <8Ja1d6zTuDEThq0VR2UQfpY94bqnQql-mqIc-fa8ico=.0909c352-1208-481e-954b-8356f45e07ad@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 63 commits: - 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 - Merge branch 'master' into pull/23739 - 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 53 more: https://git.openjdk.org/jdk/compare/d906e450...188fc811 ------------- Changes: https://git.openjdk.org/jdk/pull/23739/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=45 Stats: 7114 lines in 112 files changed: 2583 ins; 3587 del; 944 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 Tue Aug 5 22:03:03 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 5 Aug 2025 22:03:03 GMT Subject: RFR: 8364650: G1: Use InvalidCSetIndex instead of UINT_MAX for "invalid" sentinel value of young_index_in_cset Message-ID: Hi all, please review this small change to use `InvalidCSetIndex` instead of hardcoded `UINT_MAX` for `G1HeapRegion::_young_index_in_cset`. Just reuse the existing value that is already in use for `_index_in_opt_cset`. Testing: compilation, gha Thanks, Thomas ------------- Commit messages: - Hi all, Changes: https://git.openjdk.org/jdk/pull/26651/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26651&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364650 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26651.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26651/head:pull/26651 PR: https://git.openjdk.org/jdk/pull/26651 From dlong at openjdk.org Wed Aug 6 00:17:26 2025 From: dlong at openjdk.org (Dean Long) Date: Wed, 6 Aug 2025 00:17:26 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v5] In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 10:13:03 GMT, Martin Doerr wrote: >> Dean Long has updated the pull request incrementally with one additional commit since the last revision: >> >> one unconditional release should be enough > > Thanks for implementing nice code for PPC64! I appreciate it! The shared code and the other platforms look fine, too. > Maybe atomic bitwise operations could be used, but I'm happy with your current solution. Thanks @TheRealMDoerr . I didn't even consider atomic bitwise operations, but that's a good idea. I'm not in a hurry to push this, so if you could provide an atomic bitwise patch for ppc64, I would be happy to include it. In the mean time, I'm still investigating the ZGC regression. If I can figure it out, I might want to include a fix for ZGC in this PR as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26399#issuecomment-3157006874 From kbarrett at openjdk.org Wed Aug 6 02:57:16 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 6 Aug 2025 02:57:16 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v5] In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 10:13:03 GMT, Martin Doerr wrote: >> Dean Long has updated the pull request incrementally with one additional commit since the last revision: >> >> one unconditional release should be enough > > Thanks for implementing nice code for PPC64! I appreciate it! The shared code and the other platforms look fine, too. > Maybe atomic bitwise operations could be used, but I'm happy with your current solution. > Thanks @TheRealMDoerr . I didn't even consider atomic bitwise operations, but that's a good idea. I'm not in a hurry to push this, so if you could provide an atomic bitwise patch for ppc64, I would be happy to include it. In the mean time, I'm still investigating the ZGC regression. If I can figure it out, I might want to include a fix for ZGC in this PR as well. Not a review, just a drive-by comment. We've had Atomic bitops for a while now. Atomic::fetch_then_{and,or,xor}(ptr, bits [, order]) Atomic::{and,or,xor}_then_fetch(ptr, bits [, order]) They haven't been optimized for most (any?) platforms, being based on cmpxchg. (See all the "Specialize atomic bitset functions for ..." related to https://bugs.openjdk.org/browse/JDK-8293117.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/26399#issuecomment-3157237736 From dholmes at openjdk.org Wed Aug 6 06:47:05 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Aug 2025 06:47:05 GMT Subject: RFR: 8364518: Support for Job Objects in os::commit_memory_limit() on Windows [v2] In-Reply-To: <1yjYw2L7Jta-_-v0KPNcvz8wS9arjOCzvrwQpZ6sP6k=.186ac2f0-6d5f-4dd6-bcdb-839841847f25@github.com> References: <1yjYw2L7Jta-_-v0KPNcvz8wS9arjOCzvrwQpZ6sP6k=.186ac2f0-6d5f-4dd6-bcdb-839841847f25@github.com> Message-ID: On Mon, 4 Aug 2025 07:40:12 GMT, Joel Sikstr?m wrote: >> Hello, >> >> We currently use os::commit_memory_limit() to limit the initial, min and max values when ergonomically setting the heap size. Right now, os::commit_memory_limit() returns the available virtual address space on Windows, which is guaranteed to be the upper-bound of how much memory can be committed. However, this does not take into account user-configurable limits. >> >> I propose revising os::commit_memory_limit() to consider Windows Job Objects. Job Objects can, among other things, restrict the amount of memory that can be committed by a single process or all processes in a job. If we are unable to query Job Object information or if no limit is set, I suggest returning SIZE_MAX, since the next effective limit is the available virtual address space. The size of this virtual address space cannot be modified by the user, except by consuming it. >> >> For more details and short examples, I have created a GitHub repository summarizing my findings regarding memory limits and Job Objects on Windows: [https://github.com/jsikstro/MemoryLimitsWindows ](https://github.com/jsikstro/MemoryLimitsWindows). >> >> Adding support for Job Objects in this way adds support for detecting memory limits when using native Windows Hyper-V containers, which uses Job Objects to limit memory. >> >> Testing: >> * Oracle's tier1-2 >> * Manual testing on Windows using both [Process Governor](https://github.com/lowleveldesign/process-governor) (a popular tool), and creating a Job Object manually. > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > Print error message if query fails This looks good to me. I have filed > [JDK-8364803](https://bugs.openjdk.org/browse/JDK-8364803) Provide support for Windows Job Objects that limit process resources as the umbrella task for Job Object support. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26593#pullrequestreview-3090620133 From jsikstro at openjdk.org Wed Aug 6 07:58:09 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 6 Aug 2025 07:58:09 GMT Subject: RFR: 8364518: Support for Job Objects in os::commit_memory_limit() on Windows [v2] In-Reply-To: References: <1yjYw2L7Jta-_-v0KPNcvz8wS9arjOCzvrwQpZ6sP6k=.186ac2f0-6d5f-4dd6-bcdb-839841847f25@github.com> Message-ID: On Mon, 4 Aug 2025 07:50:20 GMT, Albert Mingkun Yang wrote: >> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: >> >> Print error message if query fails > > Marked as reviewed by ayang (Reviewer). Thank you for the reviews! @albertnetymk @dholmes-ora ------------- PR Comment: https://git.openjdk.org/jdk/pull/26593#issuecomment-3157917283 From jsikstro at openjdk.org Wed Aug 6 07:58:10 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 6 Aug 2025 07:58:10 GMT Subject: Integrated: 8364518: Support for Job Objects in os::commit_memory_limit() on Windows In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 10:38:32 GMT, Joel Sikstr?m wrote: > Hello, > > We currently use os::commit_memory_limit() to limit the initial, min and max values when ergonomically setting the heap size. Right now, os::commit_memory_limit() returns the available virtual address space on Windows, which is guaranteed to be the upper-bound of how much memory can be committed. However, this does not take into account user-configurable limits. > > I propose revising os::commit_memory_limit() to consider Windows Job Objects. Job Objects can, among other things, restrict the amount of memory that can be committed by a single process or all processes in a job. If we are unable to query Job Object information or if no limit is set, I suggest returning SIZE_MAX, since the next effective limit is the available virtual address space. The size of this virtual address space cannot be modified by the user, except by consuming it. > > For more details and short examples, I have created a GitHub repository summarizing my findings regarding memory limits and Job Objects on Windows: [https://github.com/jsikstro/MemoryLimitsWindows ](https://github.com/jsikstro/MemoryLimitsWindows). > > Adding support for Job Objects in this way adds support for detecting memory limits when using native Windows Hyper-V containers, which uses Job Objects to limit memory. > > Testing: > * Oracle's tier1-2 > * Manual testing on Windows using both [Process Governor](https://github.com/lowleveldesign/process-governor) (a popular tool), and creating a Job Object manually. This pull request has now been integrated. Changeset: 8d529bc4 Author: Joel Sikstr?m URL: https://git.openjdk.org/jdk/commit/8d529bc4f361407b0b5c3ac1e62c3be0f0b8d71c Stats: 22 lines in 1 file changed: 18 ins; 0 del; 4 mod 8364518: Support for Job Objects in os::commit_memory_limit() on Windows Reviewed-by: ayang, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/26593 From tschatzl at openjdk.org Wed Aug 6 08:14:04 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 6 Aug 2025 08:14:04 GMT Subject: RFR: 8364767: G1: Remove use of CollectedHeap::_soft_ref_policy In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 18:18:34 GMT, Albert Mingkun Yang wrote: > Use gc-cause checking in `VM_G1CollectFull` to decide soft-ref policy. > > Test: tier1-3 The other comment may be handled separately. src/hotspot/share/gc/g1/g1VMOperations.cpp line 54: > 52: GCCauseSetter x(g1h, _gc_cause); > 53: bool clear_all_soft_refs = _gc_cause == GCCause::_metadata_GC_clear_soft_refs || > 54: _gc_cause == GCCause::_wb_full_gc; Now that three collectors use this, it might be useful to factor this out as a helper function in `CollectedHeap` and use it. ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26648#pullrequestreview-3091140646 PR Review Comment: https://git.openjdk.org/jdk/pull/26648#discussion_r2256297755 From tschatzl at openjdk.org Wed Aug 6 08:58:07 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 6 Aug 2025 08:58:07 GMT Subject: RFR: 8364649: G1: Move collection set related full gc reset code into abandon_collection_set() method In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 15:48:13 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that removes all collection set related "abandoning" for full collection into `G1CollectedHeap::abandon_collection_set()`. Otherwise, when needing to search all over the place for the components, it's harder to verify if everything is actually properly handled. > > Testing: gha > > Thanks, > Thomas Could not reproduce the failure GHA experienced. Seems to be related to recent outage. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26624#issuecomment-3158384770 From ayang at openjdk.org Wed Aug 6 11:59:07 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 6 Aug 2025 11:59:07 GMT Subject: RFR: 8364532: G1: In liveness tracing, print more significant digits for the liveness value [v3] In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 21:57:41 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this small change that adds some more significant digits (3 in total) for the "liveness" column in collection set group logging. >> >> E.g. see the emphasized columns that lack precision (it's more irritating with lots of lines showing single-digit values): >> >> 50.707s][trace][gc,liveness] GC(13) ### groud-id num-regions gc-eff liveness remset type >> 50.707s][trace][gc,liveness] GC(13) ### (bytes/ms) % (bytes) >> 50.707s][trace][gc,liveness] GC(13) ### 1 70 0.0 *100* 3199208 Y >> 50.707s][trace][gc,liveness] GC(13) ### 2 51 5298129.5 *18* 1224072 M >> 50.707s][trace][gc,liveness] GC(13) ### 3 5 3223983.6 *31* 176648 M >> 50.707s][trace][gc,liveness] GC(13) ### 4 5 3022016.3 *32* 176648 M >> >> >> (This depends on PR#26591, so please look at that one first). >> >> The change makes sure that three significant digits are printed. >> >> Testing: manual review >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge branch 'master' into 8364532-liveness-significant-digits > - Merge branch '8364531-factor-out-liveness-code' into 8364532-liveness-significant-digits > - * use one line per parameter in log message > - * rename liveness() method to more accurate liveness_percent() > - 8364532 > > Hi all, > > please review this small change that adds some more significant digits (3 in total) for the "liveness" column in collection set group logging > > Testing: manual testing > > Thanks, > Thomas > - 8364531 > > Hi all, > > please review this refactoring, eliminating some copy&paste, in cset candidate group liveness logging. > > The output is mostly the same, except for the young cset group, where the "-" has been replaced to just print the default value (0.0) for efficiency. I did not see this important to have, the gc efficiency for young gen isn't interesting. > > Testing: local compilation, gha, visual inspection of output > > Thanks, > Thomas Minor subjective issue; up to you. src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 2984: > 2982: #define G1PPRL_LEN_H_FORMAT " %14s" > 2983: #define G1PPRL_GID_GCEFF_FORMAT " %14.1f" > 2984: #define G1PPRL_GID_LIVENESS_FORMAT " %#.3g" Why requiring 3 sig digit in total? This can make it hard to parse, even `1.23e-03` can appear. Is `%.2f` enough for the increased precision? ------------- Marked as reviewed by ayang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26595#pullrequestreview-3092186104 PR Review Comment: https://git.openjdk.org/jdk/pull/26595#discussion_r2256914889 From ayang at openjdk.org Wed Aug 6 12:18:08 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 6 Aug 2025 12:18:08 GMT Subject: RFR: 8364760: G1: Remove obsolete code in G1MergeCardSetClosure In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 16:12:32 GMT, Thomas Schatzl wrote: > Hi all, > > please review this removal of some obsolete code. > > Before JDK-8343782 G1 iterated remsets for humongous eager reclaim candidates by region, as there has been a 1:1 mapping between regions and (card-based) remembered sets. > > With that change, all remembered set iteration should go via the group remsets (`G1CSetCandidateGroup`), and the code does, except for humongous eager reclaim candidates which handle their group remsets on the side (which is a separate issue). > > This obsoleted some code in `G1MergeCardSetClosure` - it does not need to be a `G1HeapRegionClosure` any more, and for humongous regions we can directly do the iteration via the group rem set attached to the humongous starts region. I.e. inline that `merge_card_set_for_region()` method. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26645#pullrequestreview-3092260456 From ayang at openjdk.org Wed Aug 6 12:19:09 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 6 Aug 2025 12:19:09 GMT Subject: RFR: 8364650: G1: Use InvalidCSetIndex instead of UINT_MAX for "invalid" sentinel value of young_index_in_cset In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 21:56:43 GMT, Thomas Schatzl wrote: > Hi all, > > please review this small change to use `InvalidCSetIndex` instead of hardcoded `UINT_MAX` for `G1HeapRegion::_young_index_in_cset`. Just reuse the existing value that is already in use for `_index_in_opt_cset`. > > Testing: compilation, gha > > Thanks, > Thomas Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26651#pullrequestreview-3092264030 From ayang at openjdk.org Wed Aug 6 12:20:04 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 6 Aug 2025 12:20:04 GMT Subject: RFR: 8364722: Parallel: Move CLDG mark clearing to the end of full GC In-Reply-To: <3CdNhrwzi0I4FbPMgs1BSZzQi8nKC39gH7L3XksP0RA=.4af75b5a-4ad7-42f7-b14c-f95a41b84849@github.com> References: <3CdNhrwzi0I4FbPMgs1BSZzQi8nKC39gH7L3XksP0RA=.4af75b5a-4ad7-42f7-b14c-f95a41b84849@github.com> Message-ID: On Tue, 5 Aug 2025 10:13:53 GMT, Albert Mingkun Yang wrote: > Move ClassLoaderDataGraph claim-mark clearing to `post_compact` (the end of full-gc), to be more aligned with other GCs. > > Test: tier1-3 Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26637#issuecomment-3159895268 From ayang at openjdk.org Wed Aug 6 12:25:12 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 6 Aug 2025 12:25:12 GMT Subject: Integrated: 8364722: Parallel: Move CLDG mark clearing to the end of full GC In-Reply-To: <3CdNhrwzi0I4FbPMgs1BSZzQi8nKC39gH7L3XksP0RA=.4af75b5a-4ad7-42f7-b14c-f95a41b84849@github.com> References: <3CdNhrwzi0I4FbPMgs1BSZzQi8nKC39gH7L3XksP0RA=.4af75b5a-4ad7-42f7-b14c-f95a41b84849@github.com> Message-ID: On Tue, 5 Aug 2025 10:13:53 GMT, Albert Mingkun Yang wrote: > Move ClassLoaderDataGraph claim-mark clearing to `post_compact` (the end of full-gc), to be more aligned with other GCs. > > Test: tier1-3 This pull request has now been integrated. Changeset: 72d1066a Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/72d1066ae385ce511a70e762ed68afaa72e96ec4 Stats: 6 lines in 1 file changed: 3 ins; 3 del; 0 mod 8364722: Parallel: Move CLDG mark clearing to the end of full GC Reviewed-by: tschatzl, zgu ------------- PR: https://git.openjdk.org/jdk/pull/26637 From dholmes at openjdk.org Wed Aug 6 21:10:14 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Aug 2025 21:10:14 GMT Subject: RFR: 8364503: gc/g1/TestCodeCacheUnloadDuringConcCycle.java fails because of race printing to stdout [v2] In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 08:05:03 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change to the `gc/g1/TestCodeCacheUnloadDuringConcCycle.java` test - previously, the GC that we were waiting for in the test could occur between releasing whitebox control and the marker we use to distinguish before/after test setup. >> >> The change makes sure the marker is printed before releasing Whitebox control. So the concurrent start gc we look for can not happen before the marker printing. >> >> Testing: passes 5000 runs of that benchmark >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * review ayang Seems reasonable. I am still curious why this suddenly started showing up. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26592#pullrequestreview-3094289377 From manc at openjdk.org Wed Aug 6 21:15:15 2025 From: manc at openjdk.org (Man Cao) Date: Wed, 6 Aug 2025 21:15:15 GMT Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing [v3] In-Reply-To: <_yJlsycZBpjl9wwfv7sUn9Ar19akN4CKPg7i50jF1ws=.7b8ead31-ee56-42f8-b230-2fb97d1f35a4@github.com> References: <8FCHTMjSXHFLs5Q8jw9gLgWS-t1jCpRsSPKhR5LCUBE=.d845e003-ba02-47b9-afe2-45309f9adbae@github.com> <_yJlsycZBpjl9wwfv7sUn9Ar19akN4CKPg7i50jF1ws=.7b8ead31-ee56-42f8-b230-2fb97d1f35a4@github.com> Message-ID: <-QXCeqQ5G9fnCuyVw53P2VVGQSEusP7uK26xOyDN9DM=.4eb62bae-0977-4f74-9f0c-d964d6396c91@github.com> On Thu, 31 Jul 2025 09:06:40 GMT, Thomas Schatzl wrote: >> Another idea is, instead of using application cpu usage in the divisor (i.e. from the OS), calculate some `mutator-cpu-usage` similar to `gc-pause-cpu-usage` by multiplying time spent in mutator with the active processors. >> >> I.e. the resulting formula being: >> >> gc-time-ratio_new = (concurrent-cpu-usage + gc-pause-cpu-usage) / (mutator-cpu-usage + gc-pause-cpu-usage) >> ``` >> where >> >> mutator-cpu-usage = #active processors * mutator-duration >> >> effectively making it: >> >> gc-time-ratio = (concurrent-cpu-usage + gc-pause-cpu-usage) / (#active processors * time-since-last-pause) >> >> (`gc-pause-cpu-usage` calculated as before). >> >> Which is very similar to the current approach to divide `concurrent-cpu-usage` by some arbitrary threading factor, without needing to know that factor, and incurring inaccuracies because of that. >> >> Compare this formula to the current formula for determing `GCTimeRatio`: >> >> gc-time-ratio_old = gc-pause-time / time-since-last-pause >> // multiply with #active-processors on both divisor and dividend, i.e. multiplying by 1 >> = (#active processors * gc-pause-time) / (#active-processors * time-since-last-pause) >> >> >> So just adding the known concurrent cpu usage to the dividend seems... straightforward, and no more susceptible to issues than before with idle mutators. >> >> There is dependency on the number of active processors being "constant", but even the old formula uses it implicitly (i.e. the duration of the mutator and the pause is somewhat dependent on the number of active processors anyway due to allocation rate depending on it). >> >> What do you all think? This approximation seems to be no worse than the current and the formula suggested in this change to me. Somebody modifying the number of active processors at runtime for the VM, or something like burstable VMs are already very problematic. > >> Which is very similar to the current approach to divide concurrent-cpu-usage by some arbitrary threading factor, without needing to know that factor, and incurring inaccuracies because of that. > > Effectively it divides that concurrent-cpu-usage by the number of active processors if I am not mistaken :) The `#active-processors * time-since-last-pause` approach sounds worth experimenting. One potential concern is the heap sizing behavior could be more heavily affected by #active-processors, which could be surprising comparing to G1's current behavior. Admittedly, G1's current heap sizing behavior could already be affected by #active-processors (mainly via default values for ParallelGCThreads/ConcGCThreads), but it is likely to a much lesser extent. If a prototype of this approach exists, we should probably test how much difference in heap sizing there is for an application running with a low value of `ActiveProcessorCount` vs a high value. My main worry is that `#active-processors * time-since-last-pause` could inflate the divisor too much if `#active-processors` is very high (e.g. >100), which could make the heap much smaller, which is quite counter-intuitive. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26351#discussion_r2258313156 From ayang at openjdk.org Thu Aug 7 08:40:15 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 7 Aug 2025 08:40:15 GMT Subject: RFR: 8364649: G1: Move collection set related full gc reset code into abandon_collection_set() method In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 15:48:13 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that removes all collection set related "abandoning" for full collection into `G1CollectedHeap::abandon_collection_set()`. Otherwise, when needing to search all over the place for the components, it's harder to verify if everything is actually properly handled. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26624#pullrequestreview-3096041566 From tschatzl at openjdk.org Thu Aug 7 08:44:30 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 7 Aug 2025 08:44:30 GMT Subject: RFR: 8364503: gc/g1/TestCodeCacheUnloadDuringConcCycle.java fails because of race printing to stdout [v2] In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 08:06:13 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * review ayang > > Marked as reviewed by ayang (Reviewer). Thanks @albertnetymk @dholmes-ora for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/26592#issuecomment-3163116903 From tschatzl at openjdk.org Thu Aug 7 08:44:31 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 7 Aug 2025 08:44:31 GMT Subject: Integrated: 8364503: gc/g1/TestCodeCacheUnloadDuringConcCycle.java fails because of race printing to stdout In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 10:31:53 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to the `gc/g1/TestCodeCacheUnloadDuringConcCycle.java` test - previously, the GC that we were waiting for in the test could occur between releasing whitebox control and the marker we use to distinguish before/after test setup. > > The change makes sure the marker is printed before releasing Whitebox control. So the concurrent start gc we look for can not happen before the marker printing. > > Testing: passes 5000 runs of that benchmark > > Thanks, > Thomas This pull request has now been integrated. Changeset: c56fb0b6 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/c56fb0b6eff7d3f36bc65f300b784e0dd73c563e Stats: 6 lines in 1 file changed: 5 ins; 1 del; 0 mod 8364503: gc/g1/TestCodeCacheUnloadDuringConcCycle.java fails because of race printing to stdout Reviewed-by: ayang, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/26592 From tschatzl at openjdk.org Thu Aug 7 08:45:12 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 7 Aug 2025 08:45:12 GMT Subject: RFR: 8364925: G1: Improve program flow around incremental collection set building Message-ID: Hi all, please review this change that improves the G1CollectionSet incremental state handling slightly: * remove `_selected_groups_cur_length` with getter as we do not need a copy of that value around * move implementations of some methods from header files into cpp file * moved some incremental state updates from `finalize_old_part` to the respective `start/continue/stop_incremental_building` method Testing: gha Thanks, Thomas ------------- Commit messages: - * remove accidentally merged in JDK-8364934 - 8364925 Changes: https://git.openjdk.org/jdk/pull/26659/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26659&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364925 Stats: 51 lines in 2 files changed: 27 ins; 16 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/26659.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26659/head:pull/26659 PR: https://git.openjdk.org/jdk/pull/26659 From tschatzl at openjdk.org Thu Aug 7 08:46:44 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 7 Aug 2025 08:46:44 GMT Subject: RFR: 8364877: G1: Inline G1CollectedHeap::set_region_short_lived_locked Message-ID: <1g_Y0RdHzOpasE_orH8KMytqnrV9G5ozAu6Tgux1bHE=.ccd946c2-8cfe-49b1-b09b-6eaf314054cf@github.com> Hi all, please review this change that inlines `G1CollectedHeap::set_region_short_lived_locked` - it's very small, and used only once in the same class, and has a very unusual name. Testing: gha Thanks, Thomas ------------- Commit messages: - 8364877 Changes: https://git.openjdk.org/jdk/pull/26663/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26663&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364877 Stats: 15 lines in 4 files changed: 4 ins; 8 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26663.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26663/head:pull/26663 PR: https://git.openjdk.org/jdk/pull/26663 From dlong at openjdk.org Thu Aug 7 08:47:19 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 7 Aug 2025 08:47:19 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v5] In-Reply-To: References: Message-ID: On Wed, 6 Aug 2025 02:54:22 GMT, Kim Barrett wrote: >> Thanks for implementing nice code for PPC64! I appreciate it! The shared code and the other platforms look fine, too. >> Maybe atomic bitwise operations could be used, but I'm happy with your current solution. > >> Thanks @TheRealMDoerr . I didn't even consider atomic bitwise operations, but that's a good idea. I'm not in a hurry to push this, so if you could provide an atomic bitwise patch for ppc64, I would be happy to include it. In the mean time, I'm still investigating the ZGC regression. If I can figure it out, I might want to include a fix for ZGC in this PR as well. > > Not a review, just a drive-by comment. > We've had Atomic bitops for a while now. > Atomic::fetch_then_{and,or,xor}(ptr, bits [, order]) > Atomic::{and,or,xor}_then_fetch(ptr, bits [, order]) > They haven't been optimized for most (any?) platforms, being based on cmpxchg. > (See all the "Specialize atomic bitset functions for ..." related to > https://bugs.openjdk.org/browse/JDK-8293117.) Thanks @kimbarrett. I see that the Atomic::fetch_then_XXX() implementation is very similar to what I came up with. The operation I'm doing is sometimes setting a single bit, so fetch_then_or() could be used, but sometimes the operation is setting the other 31 bits, so a new fetch_then_set_with_mask() would need to be added. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26399#issuecomment-3163131928 From tschatzl at openjdk.org Thu Aug 7 09:04:17 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 7 Aug 2025 09:04:17 GMT Subject: RFR: 8364532: G1: In liveness tracing, print more significant digits for the liveness value [v3] In-Reply-To: References: Message-ID: On Wed, 6 Aug 2025 11:55:47 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Merge branch 'master' into 8364532-liveness-significant-digits >> - Merge branch '8364531-factor-out-liveness-code' into 8364532-liveness-significant-digits >> - * use one line per parameter in log message >> - * rename liveness() method to more accurate liveness_percent() >> - 8364532 >> >> Hi all, >> >> please review this small change that adds some more significant digits (3 in total) for the "liveness" column in collection set group logging >> >> Testing: manual testing >> >> Thanks, >> Thomas >> - 8364531 >> >> Hi all, >> >> please review this refactoring, eliminating some copy&paste, in cset candidate group liveness logging. >> >> The output is mostly the same, except for the young cset group, where the "-" has been replaced to just print the default value (0.0) for efficiency. I did not see this important to have, the gc efficiency for young gen isn't interesting. >> >> Testing: local compilation, gha, visual inspection of output >> >> Thanks, >> Thomas > > src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 2984: > >> 2982: #define G1PPRL_LEN_H_FORMAT " %14s" >> 2983: #define G1PPRL_GID_GCEFF_FORMAT " %14.1f" >> 2984: #define G1PPRL_GID_LIVENESS_FORMAT " %#.3g" > > Why requiring 3 sig digit in total? This can make it hard to parse, even `1.23e-03` can appear. Is `%.2f` enough for the increased precision? Did not consider the case where it used exponential format. There does not seem to be a printf format string that does what I want, and your suggestion seems to be closest (I knew about that but wanted to avoid always printing two digits after the comma). I'll test things a little bit more and probably use yours. Thanks for pointing out this formatting problem. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26595#discussion_r2259632029 From tschatzl at openjdk.org Thu Aug 7 09:35:27 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 7 Aug 2025 09:35:27 GMT Subject: RFR: 8364532: G1: In liveness tracing, print more significant digits for the liveness value [v4] In-Reply-To: References: Message-ID: > Hi all, > > please review this small change that adds some more significant digits (3 in total) for the "liveness" column in collection set group logging. > > E.g. see the emphasized columns that lack precision (it's more irritating with lots of lines showing single-digit values): > > 50.707s][trace][gc,liveness] GC(13) ### groud-id num-regions gc-eff liveness remset type > 50.707s][trace][gc,liveness] GC(13) ### (bytes/ms) % (bytes) > 50.707s][trace][gc,liveness] GC(13) ### 1 70 0.0 *100* 3199208 Y > 50.707s][trace][gc,liveness] GC(13) ### 2 51 5298129.5 *18* 1224072 M > 50.707s][trace][gc,liveness] GC(13) ### 3 5 3223983.6 *31* 176648 M > 50.707s][trace][gc,liveness] GC(13) ### 4 5 3022016.3 *32* 176648 M > > > (This depends on PR#26591, so please look at that one first). > > The change makes sure that three significant digits are printed. > > Testing: manual review > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * ayang suggestion to avoid exponential output ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26595/files - new: https://git.openjdk.org/jdk/pull/26595/files/2da72ca3..96f895dd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26595&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26595&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26595.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26595/head:pull/26595 PR: https://git.openjdk.org/jdk/pull/26595 From tschatzl at openjdk.org Thu Aug 7 09:38:53 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 7 Aug 2025 09:38:53 GMT Subject: RFR: 8364934: G1: Rename members of G1CollectionSet Message-ID: Hi all, please review this renaming of various members of `G1CollectionSet` to - use the same prefixes for the regions ("_regions") and candidate groups ("_groups") consistently, avoiding adding prefixes here and there for no discernible reason - remove unnecessary prefixes (`collection_set`) - everything is part of the collection set - fix/improve some documentation Testing: gha Thanks, THoams ------------- Depends on: https://git.openjdk.org/jdk/pull/26659 Commit messages: - 8364934 Changes: https://git.openjdk.org/jdk/pull/26670/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26670&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364934 Stats: 106 lines in 6 files changed: 15 ins; 4 del; 87 mod Patch: https://git.openjdk.org/jdk/pull/26670.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26670/head:pull/26670 PR: https://git.openjdk.org/jdk/pull/26670 From ayang at openjdk.org Thu Aug 7 09:40:15 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 7 Aug 2025 09:40:15 GMT Subject: RFR: 8364532: G1: In liveness tracing, print more significant digits for the liveness value [v4] In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 09:35:27 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this small change that adds some more significant digits (3 in total) for the "liveness" column in collection set group logging. >> >> E.g. see the emphasized columns that lack precision (it's more irritating with lots of lines showing single-digit values): >> >> 50.707s][trace][gc,liveness] GC(13) ### groud-id num-regions gc-eff liveness remset type >> 50.707s][trace][gc,liveness] GC(13) ### (bytes/ms) % (bytes) >> 50.707s][trace][gc,liveness] GC(13) ### 1 70 0.0 *100* 3199208 Y >> 50.707s][trace][gc,liveness] GC(13) ### 2 51 5298129.5 *18* 1224072 M >> 50.707s][trace][gc,liveness] GC(13) ### 3 5 3223983.6 *31* 176648 M >> 50.707s][trace][gc,liveness] GC(13) ### 4 5 3022016.3 *32* 176648 M >> >> >> (This depends on PR#26591, so please look at that one first). >> >> The change makes sure that three significant digits are printed. >> >> Testing: manual review >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * ayang suggestion to avoid exponential output Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26595#pullrequestreview-3096266562 From duke at openjdk.org Thu Aug 7 09:49:12 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Thu, 7 Aug 2025 09:49:12 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v4] In-Reply-To: References: Message-ID: > Hi all, > > This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). > > As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: > > CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() > > CPUTimeUsage::GC::gc_threads() > CPUTimeUsage::GC::vm_thread() > CPUTimeUsage::GC::stringdedup() > > CPUTimeUsage::Runtime::vm_thread() > > > I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. > > I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: > > > [12.517s][info][cpu] === CPU time Statistics ============================================================= > [12.517s][info][cpu] CPUs > [12.517s][info][cpu] s % utilized > [12.517s][info][cpu] Process > [12.517s][info][cpu] Total 175.7628 100.00 14.0 > [12.517s][info][cpu] VM Thread 7.0000 3.98 0.6 > [12.517s][info][cpu] Garbage Collection 72.0000 40.96 5.8 > [12.517s][info][cpu] GC Threads 70.0000 39.83 5.6 > [12.517s][info][cpu] VM Thread 1.0000 0.57 0.1 > [12.518s][info][cpu] String Deduplication 0.0000 0.00 0.0 > [12.518s][info][cpu] ===================================================================================== > > > Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Improve robustness ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26621/files - new: https://git.openjdk.org/jdk/pull/26621/files/216ba811..3f552362 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=02-03 Stats: 29 lines in 3 files changed: 23 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/26621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621 PR: https://git.openjdk.org/jdk/pull/26621 From tschatzl at openjdk.org Thu Aug 7 09:54:55 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 7 Aug 2025 09:54:55 GMT Subject: RFR: 8365024: G1: Make G1CollectionSet::_inc_build_state assert-only Message-ID: Hi all, please review this change that makes the `G1CollectionSet::_inc_build_state` member debug/assert-only - it's only ever used in assertions. Testing: local compilation, gha Thanks, Thomas ------------- Depends on: https://git.openjdk.org/jdk/pull/26670 Commit messages: - 8365024 Changes: https://git.openjdk.org/jdk/pull/26671/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26671&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365024 Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26671.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26671/head:pull/26671 PR: https://git.openjdk.org/jdk/pull/26671 From ayang at openjdk.org Thu Aug 7 10:09:15 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 7 Aug 2025 10:09:15 GMT Subject: RFR: 8364877: G1: Inline G1CollectedHeap::set_region_short_lived_locked In-Reply-To: <1g_Y0RdHzOpasE_orH8KMytqnrV9G5ozAu6Tgux1bHE=.ccd946c2-8cfe-49b1-b09b-6eaf314054cf@github.com> References: <1g_Y0RdHzOpasE_orH8KMytqnrV9G5ozAu6Tgux1bHE=.ccd946c2-8cfe-49b1-b09b-6eaf314054cf@github.com> Message-ID: On Wed, 6 Aug 2025 19:29:21 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that inlines `G1CollectedHeap::set_region_short_lived_locked` - it's very small, and used only once in the same class, and has a very unusual name. > > Testing: gha > > Thanks, > Thomas src/hotspot/share/gc/g1/g1EdenRegions.hpp line 45: > 43: > 44: uint add(G1HeapRegion* hr) { > 45: assert(hr->is_eden(), "should not already be set"); The string should be updated as well; maybe just "precondition" is fine. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26663#discussion_r2259793957 From tschatzl at openjdk.org Thu Aug 7 10:13:02 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 7 Aug 2025 10:13:02 GMT Subject: RFR: 8365026: G1: Initialization should start a "full" new collection set Message-ID: Hi all, please review this change that makes G1 start a "full" new collection set at initialization time, calling `G1CollectedHeap::start_new_collection_set()`. Previously G1 only did part of that (start incremental building only), on a not-fully initialized collection set instance. It works, but is not nice. Testing: gha Thanks, Thomas ------------- Commit messages: - 8365026 Changes: https://git.openjdk.org/jdk/pull/26673/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26673&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365026 Stats: 8 lines in 3 files changed: 3 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26673.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26673/head:pull/26673 PR: https://git.openjdk.org/jdk/pull/26673 From tschatzl at openjdk.org Thu Aug 7 10:41:13 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 7 Aug 2025 10:41:13 GMT Subject: RFR: 8365034: G1: Remove num_groups_selected in G1CollectionSet::select_candidates_from_optional_groups as it is unnecessary Message-ID: Hi all, please review this removal of the local `num_selected_regions` from `G1CollectionSet::select_candidates_from_optional_groups()` - the same information is maintained within the local `selected_groups` list. Testing: gha Thanks, Thomas ------------- Depends on: https://git.openjdk.org/jdk/pull/26670 Commit messages: - 8365034 Changes: https://git.openjdk.org/jdk/pull/26674/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26674&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365034 Stats: 5 lines in 1 file changed: 1 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26674.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26674/head:pull/26674 PR: https://git.openjdk.org/jdk/pull/26674 From tschatzl at openjdk.org Thu Aug 7 12:16:27 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 7 Aug 2025 12:16:27 GMT Subject: RFR: 8365040: G1: Remove sorting at end of collection set selection Message-ID: Hi all, please review this change to remove some unnecessary sorting of the collection set introduced in https://bugs.openjdk.org/browse/JDK-8165313, and made unnecessary in https://bugs.openjdk.org/browse/JDK-8165443 (all JDK 9 :)). Testing: test case in CRs, see CR for test results, gha Thanks, Thomas ------------- Depends on: https://git.openjdk.org/jdk/pull/26670 Commit messages: - 8365040 Changes: https://git.openjdk.org/jdk/pull/26676/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26676&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365040 Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26676.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26676/head:pull/26676 PR: https://git.openjdk.org/jdk/pull/26676 From tschatzl at openjdk.org Thu Aug 7 12:30:51 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 7 Aug 2025 12:30:51 GMT Subject: RFR: 8364877: G1: Inline G1CollectedHeap::set_region_short_lived_locked [v2] In-Reply-To: <1g_Y0RdHzOpasE_orH8KMytqnrV9G5ozAu6Tgux1bHE=.ccd946c2-8cfe-49b1-b09b-6eaf314054cf@github.com> References: <1g_Y0RdHzOpasE_orH8KMytqnrV9G5ozAu6Tgux1bHE=.ccd946c2-8cfe-49b1-b09b-6eaf314054cf@github.com> Message-ID: <_3h8LGMtpkllgwfPbXPa9eGEcn1jtzUZzcFm2vrPk18=.4f60b1d0-5431-4df6-b79e-c6a33b85f631@github.com> > Hi all, > > please review this change that inlines `G1CollectedHeap::set_region_short_lived_locked` - it's very small, and used only once in the same class, and has a very unusual name. > > Testing: gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * fix assert message ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26663/files - new: https://git.openjdk.org/jdk/pull/26663/files/d33e353f..7e9f3651 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26663&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26663&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26663.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26663/head:pull/26663 PR: https://git.openjdk.org/jdk/pull/26663 From ayang at openjdk.org Thu Aug 7 12:35:18 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 7 Aug 2025 12:35:18 GMT Subject: RFR: 8364877: G1: Inline G1CollectedHeap::set_region_short_lived_locked [v2] In-Reply-To: <_3h8LGMtpkllgwfPbXPa9eGEcn1jtzUZzcFm2vrPk18=.4f60b1d0-5431-4df6-b79e-c6a33b85f631@github.com> References: <1g_Y0RdHzOpasE_orH8KMytqnrV9G5ozAu6Tgux1bHE=.ccd946c2-8cfe-49b1-b09b-6eaf314054cf@github.com> <_3h8LGMtpkllgwfPbXPa9eGEcn1jtzUZzcFm2vrPk18=.4f60b1d0-5431-4df6-b79e-c6a33b85f631@github.com> Message-ID: <_eHlq3TyRuXNrft5255QjnTDyncpA7l5hgrb69Ux37c=.ce5e2b6e-ba52-4303-9ac4-08268a0f0b47@github.com> On Thu, 7 Aug 2025 12:30:51 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that inlines `G1CollectedHeap::set_region_short_lived_locked` - it's very small, and used only once in the same class, and has a very unusual name. >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * fix assert message Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26663#pullrequestreview-3096946952 From ayang at openjdk.org Thu Aug 7 13:15:16 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 7 Aug 2025 13:15:16 GMT Subject: RFR: 8364925: G1: Improve program flow around incremental collection set building In-Reply-To: References: Message-ID: <4_XEDjYRPBDyR8UJn4Dxj17P2pakNGim59edCrBko_A=.de3b49e9-4c5f-4cf7-ab7b-e3001167a274@github.com> On Wed, 6 Aug 2025 15:52:47 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that improves the G1CollectionSet incremental state handling slightly: > > * remove `_selected_groups_cur_length` with getter as we do not need a copy of that value around > * move implementations of some methods from header files into cpp file > * moved some incremental state updates from `finalize_old_part` to the respective `start/continue/stop_incremental_building` method > > Testing: gha > > Thanks, > Thomas src/hotspot/share/gc/g1/g1CollectionSet.cpp line 133: > 131: void G1CollectionSet::start_incremental_building() { > 132: assert(_collection_set_cur_length == 0, "Collection set must be empty before starting a new collection set."); > 133: Can we assert `selected_groups_cur_length() == 0` also? If so, then maybe it's best to inline `continue_incremental_building` with explicit zero-setting. src/hotspot/share/gc/g1/g1CollectionSet.hpp line 152: > 150: G1CSetCandidateGroupList _collection_set_groups; > 151: > 152: uint selected_groups_cur_length() const; Maybe move this down to methods section so that all fields are next to each other. src/hotspot/share/gc/g1/g1CollectionSet.hpp line 238: > 236: > 237: uint region_length() const { return young_region_length() + > 238: initial_old_region_length(); } Seems not needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26659#discussion_r2260286978 PR Review Comment: https://git.openjdk.org/jdk/pull/26659#discussion_r2260279534 PR Review Comment: https://git.openjdk.org/jdk/pull/26659#discussion_r2260277796 From ayang at openjdk.org Thu Aug 7 13:19:14 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 7 Aug 2025 13:19:14 GMT Subject: RFR: 8365024: G1: Make G1CollectionSet::_inc_build_state assert-only In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 09:46:52 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that makes the `G1CollectionSet::_inc_build_state` member debug/assert-only - it's only ever used in assertions. > > Testing: local compilation, gha > > Thanks, > Thomas Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26671#pullrequestreview-3097122894 From tschatzl at openjdk.org Thu Aug 7 14:53:28 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 7 Aug 2025 14:53:28 GMT Subject: RFR: 8364925: G1: Improve program flow around incremental collection set building In-Reply-To: <4_XEDjYRPBDyR8UJn4Dxj17P2pakNGim59edCrBko_A=.de3b49e9-4c5f-4cf7-ab7b-e3001167a274@github.com> References: <4_XEDjYRPBDyR8UJn4Dxj17P2pakNGim59edCrBko_A=.de3b49e9-4c5f-4cf7-ab7b-e3001167a274@github.com> Message-ID: On Thu, 7 Aug 2025 13:09:36 GMT, Albert Mingkun Yang wrote: >> Hi all, >> >> please review this change that improves the G1CollectionSet incremental state handling slightly: >> >> * remove `_selected_groups_cur_length` with getter as we do not need a copy of that value around >> * move implementations of some methods from header files into cpp file >> * moved some incremental state updates from `finalize_old_part` to the respective `start/continue/stop_incremental_building` method >> >> Testing: gha >> >> Thanks, >> Thomas > > src/hotspot/share/gc/g1/g1CollectionSet.hpp line 152: > >> 150: G1CSetCandidateGroupList _collection_set_groups; >> 151: >> 152: uint selected_groups_cur_length() const; > > Maybe move this down to methods section so that all fields are next to each other. I wanted to have this there to correspond to the place for the similar member for the regions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26659#discussion_r2260569306 From tschatzl at openjdk.org Thu Aug 7 15:08:17 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 7 Aug 2025 15:08:17 GMT Subject: RFR: 8364925: G1: Improve program flow around incremental collection set building In-Reply-To: <4_XEDjYRPBDyR8UJn4Dxj17P2pakNGim59edCrBko_A=.de3b49e9-4c5f-4cf7-ab7b-e3001167a274@github.com> References: <4_XEDjYRPBDyR8UJn4Dxj17P2pakNGim59edCrBko_A=.de3b49e9-4c5f-4cf7-ab7b-e3001167a274@github.com> Message-ID: On Thu, 7 Aug 2025 13:12:35 GMT, Albert Mingkun Yang wrote: >> Hi all, >> >> please review this change that improves the G1CollectionSet incremental state handling slightly: >> >> * remove `_selected_groups_cur_length` with getter as we do not need a copy of that value around >> * move implementations of some methods from header files into cpp file >> * moved some incremental state updates from `finalize_old_part` to the respective `start/continue/stop_incremental_building` method >> >> Testing: gha >> >> Thanks, >> Thomas > > src/hotspot/share/gc/g1/g1CollectionSet.cpp line 133: > >> 131: void G1CollectionSet::start_incremental_building() { >> 132: assert(_collection_set_cur_length == 0, "Collection set must be empty before starting a new collection set."); >> 133: > > Can we assert `selected_groups_cur_length() == 0` also? If so, then maybe it's best to inline `continue_incremental_building` with explicit zero-setting. Also adding `_optional_groups().length() == 0` here. I think calling `continue_increment...` is just fine; first start the collection set building as a whole, then start a new (first) increment within that. Maybe the name `continue_...` should be improved? > src/hotspot/share/gc/g1/g1CollectionSet.hpp line 238: > >> 236: >> 237: uint region_length() const { return young_region_length() + >> 238: initial_old_region_length(); } > > Seems not needed. When removing the other change I accidentally merged, I forgot that hunk :( ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26659#discussion_r2260615477 PR Review Comment: https://git.openjdk.org/jdk/pull/26659#discussion_r2260613241 From tschatzl at openjdk.org Thu Aug 7 15:15:08 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 7 Aug 2025 15:15:08 GMT Subject: RFR: 8364925: G1: Improve program flow around incremental collection set building [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that improves the G1CollectionSet incremental state handling slightly: > > * remove `_selected_groups_cur_length` with getter as we do not need a copy of that value around > * move implementations of some methods from header files into cpp file > * moved some incremental state updates from `finalize_old_part` to the respective `start/continue/stop_incremental_building` method > > Testing: gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * ayang review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26659/files - new: https://git.openjdk.org/jdk/pull/26659/files/141d18df..1c8188fa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26659&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26659&range=00-01 Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26659.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26659/head:pull/26659 PR: https://git.openjdk.org/jdk/pull/26659 From tschatzl at openjdk.org Thu Aug 7 15:15:25 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 7 Aug 2025 15:15:25 GMT Subject: RFR: 8364934: G1: Rename members of G1CollectionSet [v2] In-Reply-To: References: Message-ID: <7YgwDCrStFHvC1ykDCpImoibv8tQVypY0mhmAukoN5c=.5e7053e5-41ee-4e86-b82e-023728b7461c@github.com> > Hi all, > > please review this renaming of various members of `G1CollectionSet` to > > - use the same prefixes for the regions ("_regions") and candidate groups ("_groups") consistently, avoiding adding prefixes here and there for no discernible reason > - remove unnecessary prefixes (`collection_set`) - everything is part of the collection set > - fix/improve some documentation > > Testing: gha > > Thanks, > THoams Thomas Schatzl 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 '8364925-improve-program-flow-inc-cset' into 8364934-g1collectionset-renaming - 8364934 Hi all, please review this renaming of various members of `G1CollectionSet` to - use the same prefixes - remove unnecessary prefixes (`collection_set`) - fix some documentation Testing: gha Thanks, THoams ------------- Changes: https://git.openjdk.org/jdk/pull/26670/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26670&range=01 Stats: 108 lines in 6 files changed: 15 ins; 4 del; 89 mod Patch: https://git.openjdk.org/jdk/pull/26670.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26670/head:pull/26670 PR: https://git.openjdk.org/jdk/pull/26670 From ayang at openjdk.org Thu Aug 7 15:29:14 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 7 Aug 2025 15:29:14 GMT Subject: RFR: 8364925: G1: Improve program flow around incremental collection set building [v2] In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 15:15:08 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that improves the G1CollectionSet incremental state handling slightly: >> >> * remove `_selected_groups_cur_length` with getter as we do not need a copy of that value around >> * move implementations of some methods from header files into cpp file >> * moved some incremental state updates from `finalize_old_part` to the respective `start/continue/stop_incremental_building` method >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * ayang review Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26659#pullrequestreview-3097620130 From ayang at openjdk.org Thu Aug 7 15:29:16 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 7 Aug 2025 15:29:16 GMT Subject: RFR: 8364925: G1: Improve program flow around incremental collection set building [v2] In-Reply-To: References: <4_XEDjYRPBDyR8UJn4Dxj17P2pakNGim59edCrBko_A=.de3b49e9-4c5f-4cf7-ab7b-e3001167a274@github.com> Message-ID: On Thu, 7 Aug 2025 15:05:39 GMT, Thomas Schatzl wrote: >> src/hotspot/share/gc/g1/g1CollectionSet.cpp line 133: >> >>> 131: void G1CollectionSet::start_incremental_building() { >>> 132: assert(_collection_set_cur_length == 0, "Collection set must be empty before starting a new collection set."); >>> 133: >> >> Can we assert `selected_groups_cur_length() == 0` also? If so, then maybe it's best to inline `continue_incremental_building` with explicit zero-setting. > > Also adding `_optional_groups().length() == 0` here. I think calling `continue_increment...` is just fine; first start the collection set building as a whole, then start a new (first) increment within that. Maybe the name `continue_...` should be improved? I think it's easier to read with the inlined version -- those operations are not well abstracted to get a meaningful name. >> src/hotspot/share/gc/g1/g1CollectionSet.hpp line 152: >> >>> 150: G1CSetCandidateGroupList _collection_set_groups; >>> 151: >>> 152: uint selected_groups_cur_length() const; >> >> Maybe move this down to methods section so that all fields are next to each other. > > I wanted to have this there to correspond to the place for the similar member for the regions. I find it a bit odd mixing fields and methods. YMMV. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26659#discussion_r2260640984 PR Review Comment: https://git.openjdk.org/jdk/pull/26659#discussion_r2260674977 From tschatzl at openjdk.org Thu Aug 7 16:15:34 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 7 Aug 2025 16:15:34 GMT Subject: RFR: 8364934: G1: Rename members of G1CollectionSet [v3] In-Reply-To: References: Message-ID: > Hi all, > > please review this renaming of various members of `G1CollectionSet` to > > - use the same prefixes for the regions ("_regions") and candidate groups ("_groups") consistently, avoiding adding prefixes here and there for no discernible reason > - remove unnecessary prefixes (`collection_set`) - everything is part of the collection set > - fix/improve some documentation > > Testing: gha > > Thanks, > THoams Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * one more renaming: prepare_groups_for_scan() -> prepare_for_scan() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26670/files - new: https://git.openjdk.org/jdk/pull/26670/files/8a1a6e7b..b0f3180c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26670&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26670&range=01-02 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26670.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26670/head:pull/26670 PR: https://git.openjdk.org/jdk/pull/26670 From sangheki at openjdk.org Thu Aug 7 20:03:11 2025 From: sangheki at openjdk.org (Sangheon Kim) Date: Thu, 7 Aug 2025 20:03:11 GMT Subject: RFR: 8364649: G1: Move collection set related full gc reset code into abandon_collection_set() method In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 15:48:13 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that removes all collection set related "abandoning" for full collection into `G1CollectedHeap::abandon_collection_set()`. Otherwise, when needing to search all over the place for the components, it's harder to verify if everything is actually properly handled. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by sangheki (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26624#pullrequestreview-3098566879 From sangheki at openjdk.org Thu Aug 7 20:13:11 2025 From: sangheki at openjdk.org (Sangheon Kim) Date: Thu, 7 Aug 2025 20:13:11 GMT Subject: RFR: 8364760: G1: Remove obsolete code in G1MergeCardSetClosure In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 16:12:32 GMT, Thomas Schatzl wrote: > Hi all, > > please review this removal of some obsolete code. > > Before JDK-8343782 G1 iterated remsets for humongous eager reclaim candidates by region, as there has been a 1:1 mapping between regions and (card-based) remembered sets. > > With that change, all remembered set iteration should go via the group remsets (`G1CSetCandidateGroup`), and the code does, except for humongous eager reclaim candidates which handle their group remsets on the side (which is a separate issue). > > This obsoleted some code in `G1MergeCardSetClosure` - it does not need to be a `G1HeapRegionClosure` any more, and for humongous regions we can directly do the iteration via the group rem set attached to the humongous starts region. I.e. inline that `merge_card_set_for_region()` method. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by sangheki (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26645#pullrequestreview-3098588402 From phh at openjdk.org Thu Aug 7 23:22:10 2025 From: phh at openjdk.org (Paul Hohensee) Date: Thu, 7 Aug 2025 23:22:10 GMT Subject: RFR: 8364628: Serial: Refactor SerialHeap::mem_allocate_work In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 10:01:15 GMT, Albert Mingkun Yang wrote: > Extract out old-gen allocation outside the critical-region to streamline the flow in `mem_allocate_work`. > > Test: tier1-5 There's quite a lot of duplicate code in all four of these files. Perhaps take the opportunity to consolidate? ------------- PR Review: https://git.openjdk.org/jdk/pull/26619#pullrequestreview-3099036817 From phh at openjdk.org Thu Aug 7 23:26:09 2025 From: phh at openjdk.org (Paul Hohensee) Date: Thu, 7 Aug 2025 23:26:09 GMT Subject: RFR: 8364541: Parallel: Support allocation in old generation when heap is almost full In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 15:36:06 GMT, Albert Mingkun Yang wrote: > Adding old-gen allocation support in heap-almost-full scenario. This can make tests that cause OOM deliberately more resilient to timeout and help runaway apps to exit/fail faster. > > Test: tier1-3 Good idea. :) ------------- Marked as reviewed by phh (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26599#pullrequestreview-3099040440 From sangheki at openjdk.org Fri Aug 8 00:23:10 2025 From: sangheki at openjdk.org (Sangheon Kim) Date: Fri, 8 Aug 2025 00:23:10 GMT Subject: RFR: 8364877: G1: Inline G1CollectedHeap::set_region_short_lived_locked [v2] In-Reply-To: <_3h8LGMtpkllgwfPbXPa9eGEcn1jtzUZzcFm2vrPk18=.4f60b1d0-5431-4df6-b79e-c6a33b85f631@github.com> References: <1g_Y0RdHzOpasE_orH8KMytqnrV9G5ozAu6Tgux1bHE=.ccd946c2-8cfe-49b1-b09b-6eaf314054cf@github.com> <_3h8LGMtpkllgwfPbXPa9eGEcn1jtzUZzcFm2vrPk18=.4f60b1d0-5431-4df6-b79e-c6a33b85f631@github.com> Message-ID: On Thu, 7 Aug 2025 12:30:51 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that inlines `G1CollectedHeap::set_region_short_lived_locked` - it's very small, and used only once in the same class, and has a very unusual name. >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * fix assert message Marked as reviewed by sangheki (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26663#pullrequestreview-3099119611 From kbarrett at openjdk.org Fri Aug 8 06:42:13 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 8 Aug 2025 06:42:13 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v5] In-Reply-To: References: Message-ID: On Wed, 6 Aug 2025 02:54:22 GMT, Kim Barrett wrote: >> Thanks for implementing nice code for PPC64! I appreciate it! The shared code and the other platforms look fine, too. >> Maybe atomic bitwise operations could be used, but I'm happy with your current solution. > >> Thanks @TheRealMDoerr . I didn't even consider atomic bitwise operations, but that's a good idea. I'm not in a hurry to push this, so if you could provide an atomic bitwise patch for ppc64, I would be happy to include it. In the mean time, I'm still investigating the ZGC regression. If I can figure it out, I might want to include a fix for ZGC in this PR as well. > > Not a review, just a drive-by comment. > We've had Atomic bitops for a while now. > Atomic::fetch_then_{and,or,xor}(ptr, bits [, order]) > Atomic::{and,or,xor}_then_fetch(ptr, bits [, order]) > They haven't been optimized for most (any?) platforms, being based on cmpxchg. > (See all the "Specialize atomic bitset functions for ..." related to > https://bugs.openjdk.org/browse/JDK-8293117.) > Thanks @kimbarrett. I see that the Atomic::fetch_then_XXX() implementation is very similar to what I came up with. The operation I'm doing is sometimes setting a single bit, so fetch_then_or() could be used, but sometimes the operation is setting the other 31 bits, so a new fetch_then_set_with_mask() would need to be added. Oh, yes, I see. This code is setting a bitfield. Yeah, that's not one of the logical atomic primitives, and seems unlikely to be added unless more use-cases can be found. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26399#issuecomment-3166743405 From tschatzl at openjdk.org Fri Aug 8 07:56:10 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 8 Aug 2025 07:56:10 GMT Subject: RFR: 8364642: G1: Remove parameter in G1CollectedHeap::abandon_collection_set() In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 13:23:00 GMT, Albert Mingkun Yang wrote: >> Hi all, >> >> please review this small refactoring to remove some parameter that `G1CollectedHeap` already knows anyway. >> >> Testing: local compilation, gha >> >> Thanks, >> Thomas > > Marked as reviewed by ayang (Reviewer). Thanks @albertnetymk for your review ------------- PR Comment: https://git.openjdk.org/jdk/pull/26622#issuecomment-3166909550 From tschatzl at openjdk.org Fri Aug 8 07:57:12 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 8 Aug 2025 07:57:12 GMT Subject: RFR: 8364760: G1: Remove obsolete code in G1MergeCardSetClosure In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 20:10:33 GMT, Sangheon Kim wrote: >> Hi all, >> >> please review this removal of some obsolete code. >> >> Before JDK-8343782 G1 iterated remsets for humongous eager reclaim candidates by region, as there has been a 1:1 mapping between regions and (card-based) remembered sets. >> >> With that change, all remembered set iteration should go via the group remsets (`G1CSetCandidateGroup`), and the code does, except for humongous eager reclaim candidates which handle their group remsets on the side (which is a separate issue). >> >> This obsoleted some code in `G1MergeCardSetClosure` - it does not need to be a `G1HeapRegionClosure` any more, and for humongous regions we can directly do the iteration via the group rem set attached to the humongous starts region. I.e. inline that `merge_card_set_for_region()` method. >> >> Testing: gha >> >> Thanks, >> Thomas > > Marked as reviewed by sangheki (Reviewer). Thanks @sangheon @albertnetymk for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/26645#issuecomment-3166911263 From tschatzl at openjdk.org Fri Aug 8 07:57:21 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 8 Aug 2025 07:57:21 GMT Subject: RFR: 8364877: G1: Inline G1CollectedHeap::set_region_short_lived_locked [v2] In-Reply-To: <_eHlq3TyRuXNrft5255QjnTDyncpA7l5hgrb69Ux37c=.ce5e2b6e-ba52-4303-9ac4-08268a0f0b47@github.com> References: <1g_Y0RdHzOpasE_orH8KMytqnrV9G5ozAu6Tgux1bHE=.ccd946c2-8cfe-49b1-b09b-6eaf314054cf@github.com> <_3h8LGMtpkllgwfPbXPa9eGEcn1jtzUZzcFm2vrPk18=.4f60b1d0-5431-4df6-b79e-c6a33b85f631@github.com> <_eHlq3TyRuXNrft5255QjnTDyncpA7l5hgrb69Ux37c=.ce5e2b6e-ba52-4303-9ac4-08268a0f0b47@github.com> Message-ID: <3NM31Zq5XqsxVYg85B0MBV899GtfJTMGlhHOOkWItZE=.afb5c5b4-9786-48a6-9f29-a915f65903cc@github.com> On Thu, 7 Aug 2025 12:32:55 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * fix assert message > > Marked as reviewed by ayang (Reviewer). Thanks @albertnetymk @sangheon for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/26663#issuecomment-3166906773 From tschatzl at openjdk.org Fri Aug 8 07:57:22 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 8 Aug 2025 07:57:22 GMT Subject: Integrated: 8364877: G1: Inline G1CollectedHeap::set_region_short_lived_locked In-Reply-To: <1g_Y0RdHzOpasE_orH8KMytqnrV9G5ozAu6Tgux1bHE=.ccd946c2-8cfe-49b1-b09b-6eaf314054cf@github.com> References: <1g_Y0RdHzOpasE_orH8KMytqnrV9G5ozAu6Tgux1bHE=.ccd946c2-8cfe-49b1-b09b-6eaf314054cf@github.com> Message-ID: On Wed, 6 Aug 2025 19:29:21 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that inlines `G1CollectedHeap::set_region_short_lived_locked` - it's very small, and used only once in the same class, and has a very unusual name. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 198782c9 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/198782c957c728ed959d1fd31e2c2ff6cd1a9bb5 Stats: 15 lines in 4 files changed: 4 ins; 8 del; 3 mod 8364877: G1: Inline G1CollectedHeap::set_region_short_lived_locked Reviewed-by: ayang, sangheki ------------- PR: https://git.openjdk.org/jdk/pull/26663 From tschatzl at openjdk.org Fri Aug 8 07:59:17 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 8 Aug 2025 07:59:17 GMT Subject: Integrated: 8364642: G1: Remove parameter in G1CollectedHeap::abandon_collection_set() In-Reply-To: References: Message-ID: <2dOhsghcFCZ1AFdpkCJSXePPdfxSr3GGvGljI2LaqnU=.78af2910-195b-49b6-8ded-de43747cf0ef@github.com> On Mon, 4 Aug 2025 15:00:29 GMT, Thomas Schatzl wrote: > Hi all, > > please review this small refactoring to remove some parameter that `G1CollectedHeap` already knows anyway. > > Testing: local compilation, gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: bcca5cee Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/bcca5cee2d788c745bea55388b2844b395519ed0 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod 8364642: G1: Remove parameter in G1CollectedHeap::abandon_collection_set() Reviewed-by: ayang ------------- PR: https://git.openjdk.org/jdk/pull/26622 From tschatzl at openjdk.org Fri Aug 8 08:00:18 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 8 Aug 2025 08:00:18 GMT Subject: Integrated: 8364760: G1: Remove obsolete code in G1MergeCardSetClosure In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 16:12:32 GMT, Thomas Schatzl wrote: > Hi all, > > please review this removal of some obsolete code. > > Before JDK-8343782 G1 iterated remsets for humongous eager reclaim candidates by region, as there has been a 1:1 mapping between regions and (card-based) remembered sets. > > With that change, all remembered set iteration should go via the group remsets (`G1CSetCandidateGroup`), and the code does, except for humongous eager reclaim candidates which handle their group remsets on the side (which is a separate issue). > > This obsoleted some code in `G1MergeCardSetClosure` - it does not need to be a `G1HeapRegionClosure` any more, and for humongous regions we can directly do the iteration via the group rem set attached to the humongous starts region. I.e. inline that `merge_card_set_for_region()` method. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 47017e38 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/47017e38642a58fd6425ec68c1fed96f19f39404 Stats: 38 lines in 1 file changed: 0 ins; 35 del; 3 mod 8364760: G1: Remove obsolete code in G1MergeCardSetClosure Reviewed-by: ayang, sangheki ------------- PR: https://git.openjdk.org/jdk/pull/26645 From tschatzl at openjdk.org Fri Aug 8 08:10:39 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 8 Aug 2025 08:10:39 GMT Subject: RFR: 8364649: G1: Move collection set related full gc reset code into abandon_collection_set() method [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that removes all collection set related "abandoning" for full collection into `G1CollectedHeap::abandon_collection_set()`. Otherwise, when needing to search all over the place for the components, it's harder to verify if everything is actually properly handled. > > Testing: gha > > Thanks, > Thomas Thomas Schatzl 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. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26624/files - new: https://git.openjdk.org/jdk/pull/26624/files/e8250d3d..e8250d3d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26624&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26624&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26624.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26624/head:pull/26624 PR: https://git.openjdk.org/jdk/pull/26624 From tschatzl at openjdk.org Fri Aug 8 08:10:40 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 8 Aug 2025 08:10:40 GMT Subject: Integrated: 8364649: G1: Move collection set related full gc reset code into abandon_collection_set() method In-Reply-To: References: Message-ID: <-P0sdKfeHXFHL23tGfIhx5CsKzPn8qHx8VSqcgiOVgE=.b3337eea-934f-4b2b-954f-111afe47acfb@github.com> On Mon, 4 Aug 2025 15:48:13 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that removes all collection set related "abandoning" for full collection into `G1CollectedHeap::abandon_collection_set()`. Otherwise, when needing to search all over the place for the components, it's harder to verify if everything is actually properly handled. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: a26a6f31 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/a26a6f31524aba61ed83bf3ffdc7713e3e5f5911 Stats: 7 lines in 3 files changed: 4 ins; 3 del; 0 mod 8364649: G1: Move collection set related full gc reset code into abandon_collection_set() method Reviewed-by: ayang, sangheki ------------- PR: https://git.openjdk.org/jdk/pull/26624 From tschatzl at openjdk.org Fri Aug 8 08:10:39 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 8 Aug 2025 08:10:39 GMT Subject: RFR: 8364649: G1: Move collection set related full gc reset code into abandon_collection_set() method [v2] In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 08:37:10 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl 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. > > Marked as reviewed by ayang (Reviewer). Thanks @albertnetymk ?sangheon for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/26624#issuecomment-3166935558 From ayang at openjdk.org Fri Aug 8 08:14:09 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 8 Aug 2025 08:14:09 GMT Subject: RFR: 8364628: Serial: Refactor SerialHeap::mem_allocate_work In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 23:19:55 GMT, Paul Hohensee wrote: > There's quite a lot of duplicate code in all four of these files. Could you point me to the duplicate code in these files? I don't see much duplication in serialHeap and tenuredGeneration. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26619#issuecomment-3166950337 From tschatzl at openjdk.org Fri Aug 8 08:15:59 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 8 Aug 2025 08:15:59 GMT Subject: RFR: 8364962: G1: Inline G1CollectionSet::finalize_incremental_building Message-ID: Hi all, please review this inlining of `G1CollectionSet::finalize_incremental_building` - it does not do anything useful for some time now, only some fairly generic asserts. There is only one caller too. Testing: gha Thanks, Thomas ------------- Commit messages: - 8364962 Changes: https://git.openjdk.org/jdk/pull/26687/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26687&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364962 Stats: 11 lines in 2 files changed: 1 ins; 8 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26687.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26687/head:pull/26687 PR: https://git.openjdk.org/jdk/pull/26687 From tschatzl at openjdk.org Fri Aug 8 08:19:02 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 8 Aug 2025 08:19:02 GMT Subject: RFR: 8365052: G1: Remove G1CollectionSet::groups() accessors Message-ID: <8ZodEn2wqRkIaTR2ZoMjm5scNATrQHcS1IP1VVJMVtM=.70676141-6535-4869-8b14-e692bad9ab6a@github.com> Hi all, please review this small change that remove the public `G1CollectionSet::groups()` accessors because they are never used from outside the `G1CollectionSet` class. Testing: local compilation, gha Thanks, Thomas ------------- Depends on: https://git.openjdk.org/jdk/pull/26670 Commit messages: - 8365052 Changes: https://git.openjdk.org/jdk/pull/26688/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26688&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365052 Stats: 5 lines in 3 files changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26688.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26688/head:pull/26688 PR: https://git.openjdk.org/jdk/pull/26688 From tschatzl at openjdk.org Fri Aug 8 10:18:22 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 8 Aug 2025 10:18:22 GMT Subject: RFR: 8365122: G1: Minor clean up of G1SurvivorRegions Message-ID: Hi all, please review this small cleanup around `G1SurvivorRegions`: - make the `_regions` member a direct member of the class - use the C++ for-each construct for iterating over `_regions` makes the code more readable Testing: gha Thanks, Thomas ------------- Commit messages: - 8365122 Changes: https://git.openjdk.org/jdk/pull/26692/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26692&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365122 Stats: 26 lines in 3 files changed: 1 ins; 10 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/26692.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26692/head:pull/26692 PR: https://git.openjdk.org/jdk/pull/26692 From tschatzl at openjdk.org Fri Aug 8 12:00:44 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 8 Aug 2025 12:00:44 GMT Subject: RFR: 8365115: G1: Refactor rem set statistics gather code for group Message-ID: Hi all, please review this change to remove some code duplication in group remset statistics gathering. Testing: gha Thanks, Thomas ------------- Commit messages: - 8365115 Changes: https://git.openjdk.org/jdk/pull/26691/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26691&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365115 Stats: 41 lines in 1 file changed: 9 ins; 14 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/26691.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26691/head:pull/26691 PR: https://git.openjdk.org/jdk/pull/26691 From tschatzl at openjdk.org Fri Aug 8 13:01:24 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 8 Aug 2025 13:01:24 GMT Subject: RFR: 8365055: G1: Merge Heap Roots phase incorrectly clears young gen remembered set every time Message-ID: <8JFuOjov4pzLsgan8_D26HNVtWFNTBm7OzuMMwRVUAM=.f557c3d1-ccef-4ea2-ad9c-0c4a217f24b4@github.com> Hi all, please review this fix to G1 heap root merging that cleared the young gen remembered set multiple times (for every merging) and overwriting the most recent statistics for the number of young gen cards. The latter is probably the more problematic, as it directly impacts young gen sizing statistics, potentially making young gen too large. The fix is to move the two statements to the proper place - get current number of young gen cards at startup, clear the young gen remset when starting a new collection set - we do not need to do that earlier after all. Additionally we can add some (superfluous?) verification that during GC we really do not add to the young gen remset. Testing: tier1-5 Thanks, Thomas ------------- Commit messages: - 8365055 Changes: https://git.openjdk.org/jdk/pull/26695/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26695&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365055 Stats: 33 lines in 5 files changed: 17 ins; 11 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/26695.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26695/head:pull/26695 PR: https://git.openjdk.org/jdk/pull/26695 From tschatzl at openjdk.org Fri Aug 8 14:12:31 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 8 Aug 2025 14:12:31 GMT Subject: RFR: 8365055: G1: Merge Heap Roots phase incorrectly clears young gen remembered set every time [v2] In-Reply-To: <8JFuOjov4pzLsgan8_D26HNVtWFNTBm7OzuMMwRVUAM=.f557c3d1-ccef-4ea2-ad9c-0c4a217f24b4@github.com> References: <8JFuOjov4pzLsgan8_D26HNVtWFNTBm7OzuMMwRVUAM=.f557c3d1-ccef-4ea2-ad9c-0c4a217f24b4@github.com> Message-ID: > Hi all, > > please review this fix to G1 heap root merging that cleared the young gen remembered set multiple times (for every merging) and overwriting the most recent statistics for the number of young gen cards. > > The latter is probably the more problematic, as it directly impacts young gen sizing statistics, potentially making young gen too large. > > The fix is to move the two statements to the proper place - get current number of young gen cards at startup, clear the young gen remset when starting a new collection set - we do not need to do that earlier after all. Additionally we can add some (superfluous?) verification that during GC we really do not add to the young gen remset. > > Testing: tier1-5 > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * fix comment in verification code * move that G1Policy member to G1CollectedHeap as it's used to verify stuff in G1CollectedHeap (and not used elsewhere anyway) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26695/files - new: https://git.openjdk.org/jdk/pull/26695/files/857fdf91..ba62be50 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26695&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26695&range=00-01 Stats: 17 lines in 4 files changed: 3 ins; 10 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26695.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26695/head:pull/26695 PR: https://git.openjdk.org/jdk/pull/26695 From ayang at openjdk.org Fri Aug 8 14:57:20 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 8 Aug 2025 14:57:20 GMT Subject: RFR: 8346005: Parallel: Incorrect page size calculation with UseLargePages 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 ------------- Commit messages: - pgc-largepage Changes: https://git.openjdk.org/jdk/pull/26700/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26700&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346005 Stats: 230 lines in 15 files changed: 82 ins; 91 del; 57 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 sangheki at openjdk.org Fri Aug 8 22:36:11 2025 From: sangheki at openjdk.org (Sangheon Kim) Date: Fri, 8 Aug 2025 22:36:11 GMT Subject: RFR: 8364767: G1: Remove use of CollectedHeap::_soft_ref_policy In-Reply-To: References: Message-ID: <9HFVLrbzrIH4ffJz2q7YFwn7qGp008aA0b74sRnyMTM=.fd78fb39-dd8b-478e-be91-610e519870cd@github.com> On Tue, 5 Aug 2025 18:18:34 GMT, Albert Mingkun Yang wrote: > Use gc-cause checking in `VM_G1CollectFull` to decide soft-ref policy. > > Test: tier1-3 LGTM ------------- Marked as reviewed by sangheki (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26648#pullrequestreview-3102265382 From tschatzl at openjdk.org Mon Aug 11 07:41:32 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 11 Aug 2025 07:41:32 GMT Subject: RFR: 8365122: G1: Minor clean up of G1SurvivorRegions [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review this small cleanup around `G1SurvivorRegions`: > > - make the `_regions` member a direct member of the class > - use the C++ for-each construct for iterating over `_regions` makes the code more readable > > Testing: gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * add growablearray include ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26692/files - new: https://git.openjdk.org/jdk/pull/26692/files/b73da8fc..16244cad Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26692&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26692&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26692.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26692/head:pull/26692 PR: https://git.openjdk.org/jdk/pull/26692 From tschatzl at openjdk.org Mon Aug 11 08:49:13 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 11 Aug 2025 08:49:13 GMT Subject: RFR: 8364541: Parallel: Support allocation in old generation when heap is almost full In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 15:36:06 GMT, Albert Mingkun Yang wrote: > Adding old-gen allocation support in heap-almost-full scenario. This can make tests that cause OOM deliberately more resilient to timeout and help runaway apps to exit/fail faster. > > Test: tier1-3 Not sure why the condition had to be broken into two if-statements, but seems good. ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26599#pullrequestreview-3104704107 From ayang at openjdk.org Mon Aug 11 09:41:15 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 11 Aug 2025 09:41:15 GMT Subject: RFR: 8364767: G1: Remove use of CollectedHeap::_soft_ref_policy In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 18:18:34 GMT, Albert Mingkun Yang wrote: > Use gc-cause checking in `VM_G1CollectFull` to decide soft-ref policy. > > Test: tier1-3 Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26648#issuecomment-3173964461 From ayang at openjdk.org Mon Aug 11 09:45:26 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 11 Aug 2025 09:45:26 GMT Subject: Integrated: 8364767: G1: Remove use of CollectedHeap::_soft_ref_policy In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 18:18:34 GMT, Albert Mingkun Yang wrote: > Use gc-cause checking in `VM_G1CollectFull` to decide soft-ref policy. > > Test: tier1-3 This pull request has now been integrated. Changeset: 0c39228e Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/0c39228ec1c8c6eadafb54567c94ad5f19f27f7a Stats: 42 lines in 6 files changed: 4 ins; 35 del; 3 mod 8364767: G1: Remove use of CollectedHeap::_soft_ref_policy Reviewed-by: tschatzl, sangheki ------------- PR: https://git.openjdk.org/jdk/pull/26648 From ayang at openjdk.org Mon Aug 11 09:57:12 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 11 Aug 2025 09:57:12 GMT Subject: RFR: 8364962: G1: Inline G1CollectionSet::finalize_incremental_building In-Reply-To: References: Message-ID: On Fri, 8 Aug 2025 08:06:49 GMT, Thomas Schatzl wrote: > Hi all, > > please review this inlining of `G1CollectionSet::finalize_incremental_building` - it does not do anything useful for some time now, only some fairly generic asserts. There is only one caller too. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26687#pullrequestreview-3104973244 From ayang at openjdk.org Mon Aug 11 10:42:49 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 11 Aug 2025 10:42:49 GMT Subject: RFR: 8365237: Remove unused SoftRefPolicy::_all_soft_refs_clear Message-ID: Trivial removing effectively dead code. Test: tier1 ------------- Commit messages: - soft-ref-cleanup Changes: https://git.openjdk.org/jdk/pull/26722/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26722&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365237 Stats: 34 lines in 3 files changed: 0 ins; 32 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26722.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26722/head:pull/26722 PR: https://git.openjdk.org/jdk/pull/26722 From ayang at openjdk.org Mon Aug 11 10:50:11 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 11 Aug 2025 10:50:11 GMT Subject: RFR: 8364541: Parallel: Support allocation in old generation when heap is almost full In-Reply-To: References: Message-ID: On Mon, 11 Aug 2025 08:46:04 GMT, Thomas Schatzl wrote: > Not sure why the condition had to be broken into two if-statements, but seems good. The first (tlab-checking) is for correctness (old-gen can't hold tlab), while the other (size and heap-fullness) is more like heuristics. Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26599#issuecomment-3174200175 From ayang at openjdk.org Mon Aug 11 10:54:15 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 11 Aug 2025 10:54:15 GMT Subject: Integrated: 8364541: Parallel: Support allocation in old generation when heap is almost full In-Reply-To: References: Message-ID: <9VwR2z0qvRzDf2D_aLwF7n2GkKiNLzoknn-T1MFWdH8=.ba7b8c8f-0238-41fe-a2eb-abaf82517508@github.com> On Fri, 1 Aug 2025 15:36:06 GMT, Albert Mingkun Yang wrote: > Adding old-gen allocation support in heap-almost-full scenario. This can make tests that cause OOM deliberately more resilient to timeout and help runaway apps to exit/fail faster. > > Test: tier1-3 This pull request has now been integrated. Changeset: fd766b27 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/fd766b27b9f862075a415780901c242a7d48c26f Stats: 7 lines in 1 file changed: 2 ins; 0 del; 5 mod 8364541: Parallel: Support allocation in old generation when heap is almost full Reviewed-by: phh, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/26599 From ayang at openjdk.org Mon Aug 11 13:07:11 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 11 Aug 2025 13:07:11 GMT Subject: RFR: 8365052: G1: Remove G1CollectionSet::groups() accessors In-Reply-To: <8ZodEn2wqRkIaTR2ZoMjm5scNATrQHcS1IP1VVJMVtM=.70676141-6535-4869-8b14-e692bad9ab6a@github.com> References: <8ZodEn2wqRkIaTR2ZoMjm5scNATrQHcS1IP1VVJMVtM=.70676141-6535-4869-8b14-e692bad9ab6a@github.com> Message-ID: <0ZO_2Kc9qp157KRntHEXr6GQGP4AIK6jzcLa-hlV6M4=.da8cfd0a-7866-4783-be90-be1b83c87fc9@github.com> On Fri, 8 Aug 2025 08:11:10 GMT, Thomas Schatzl wrote: > Hi all, > > please review this small change that remove the public `G1CollectionSet::groups()` accessors because they are never used from outside the `G1CollectionSet` class. > > Testing: local compilation, gha > > Thanks, > Thomas Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26688#pullrequestreview-3105757366 From sangheki at openjdk.org Mon Aug 11 17:03:09 2025 From: sangheki at openjdk.org (Sangheon Kim) Date: Mon, 11 Aug 2025 17:03:09 GMT Subject: RFR: 8365122: G1: Minor clean up of G1SurvivorRegions [v2] In-Reply-To: References: Message-ID: On Mon, 11 Aug 2025 07:41:32 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this small cleanup around `G1SurvivorRegions`: >> >> - make the `_regions` member a direct member of the class >> - use the C++ for-each construct for iterating over `_regions` makes the code more readable >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * add growablearray include Looks good. ------------- Marked as reviewed by sangheki (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26692#pullrequestreview-3106864242 From duke at openjdk.org Tue Aug 12 06:02:29 2025 From: duke at openjdk.org (Cheng Pan) Date: Tue, 12 Aug 2025 06:02:29 GMT Subject: RFR: 8318706: Implement JEP 423: Region Pinning for G1 [v10] In-Reply-To: References: <1-i3-5OmZbuCNUlpfv31Kr3eiBXEd4Si8F5gsbPHuBQ=.1d97dcac-4662-4482-842c-ce86315ba61a@github.com> Message-ID: On Wed, 29 Nov 2023 10:02:31 GMT, Thomas Schatzl wrote: >> Marked as reviewed by ayang (Reviewer). > > Thanks @albertnetymk @kstefanj @walulyai for your reviews! Given that the JEP is now targeted, I will integrate. > > This has been a fairly long journey until today... :) @tschatzl thanks for your excellent work! I know that JEP 423 targets JDK 22, but I wonder if this can be backported to JDK 21. For big data workloads like Apache Spark, we do see that G1 generally performs better than other GC algorithms, but one major issue is that it heavily uses JNI for compression/decompression (e.g. [zstd-jni](https://github.com/luben/zstd-jni/issues/346)), thus easy to OOM. I have tested some internal Spark jobs, which were easy to OOM on JDK 21, work well on JDK 22, but given that JDK 22 has been EOL, I would appreciate it if this could be landed on JDK 21 ------------- PR Comment: https://git.openjdk.org/jdk/pull/16342#issuecomment-3177810965 From tschatzl at openjdk.org Tue Aug 12 07:15:11 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 12 Aug 2025 07:15:11 GMT Subject: RFR: 8365237: Remove unused SoftRefPolicy::_all_soft_refs_clear In-Reply-To: References: Message-ID: On Mon, 11 Aug 2025 10:35:26 GMT, Albert Mingkun Yang wrote: > Trivial removing effectively dead code. > > Test: tier1 Changes requested by tschatzl (Reviewer). src/hotspot/share/gc/shared/gcVMOperations.hpp line 130: > 128: _full_gc_count_before = full_gc_count_before; > 129: } > 130: ~VM_GC_Operation() {} Remove as well, unnecessary. ------------- PR Review: https://git.openjdk.org/jdk/pull/26722#pullrequestreview-3108870014 PR Review Comment: https://git.openjdk.org/jdk/pull/26722#discussion_r2268822912 From kbarrett at openjdk.org Tue Aug 12 07:31:16 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 12 Aug 2025 07:31:16 GMT Subject: RFR: 8365237: Remove unused SoftRefPolicy::_all_soft_refs_clear In-Reply-To: References: Message-ID: On Mon, 11 Aug 2025 10:35:26 GMT, Albert Mingkun Yang wrote: > Trivial removing effectively dead code. > > Test: tier1 Other than the explicit empty `~VM_GC_Ooperation()` that @tschatzl pointed out, this looks good to me. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26722#pullrequestreview-3108970658 From kbarrett at openjdk.org Tue Aug 12 07:37:14 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 12 Aug 2025 07:37:14 GMT Subject: RFR: 8365122: G1: Minor clean up of G1SurvivorRegions [v2] In-Reply-To: References: Message-ID: On Mon, 11 Aug 2025 07:41:32 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this small cleanup around `G1SurvivorRegions`: >> >> - make the `_regions` member a direct member of the class >> - use the C++ for-each construct for iterating over `_regions` makes the code more readable >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * add growablearray include Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26692#pullrequestreview-3109006431 From kbarrett at openjdk.org Tue Aug 12 07:39:19 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 12 Aug 2025 07:39:19 GMT Subject: RFR: 8365052: G1: Remove G1CollectionSet::groups() accessors In-Reply-To: <8ZodEn2wqRkIaTR2ZoMjm5scNATrQHcS1IP1VVJMVtM=.70676141-6535-4869-8b14-e692bad9ab6a@github.com> References: <8ZodEn2wqRkIaTR2ZoMjm5scNATrQHcS1IP1VVJMVtM=.70676141-6535-4869-8b14-e692bad9ab6a@github.com> Message-ID: On Fri, 8 Aug 2025 08:11:10 GMT, Thomas Schatzl wrote: > Hi all, > > please review this small change that remove the public `G1CollectionSet::groups()` accessors because they are never used from outside the `G1CollectionSet` class. > > Testing: local compilation, gha > > Thanks, > Thomas Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26688#pullrequestreview-3109016203 From kbarrett at openjdk.org Tue Aug 12 07:40:15 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 12 Aug 2025 07:40:15 GMT Subject: RFR: 8364962: G1: Inline G1CollectionSet::finalize_incremental_building In-Reply-To: References: Message-ID: On Fri, 8 Aug 2025 08:06:49 GMT, Thomas Schatzl wrote: > Hi all, > > please review this inlining of `G1CollectionSet::finalize_incremental_building` - it does not do anything useful for some time now, only some fairly generic asserts. There is only one caller too. > > Testing: gha > > Thanks, > Thomas Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26687#pullrequestreview-3109025205 From kbarrett at openjdk.org Tue Aug 12 07:50:10 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 12 Aug 2025 07:50:10 GMT Subject: RFR: 8365115: G1: Refactor rem set statistics gather code for group In-Reply-To: References: Message-ID: On Fri, 8 Aug 2025 09:39:42 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to remove some code duplication in group remset statistics gathering. > > Testing: gha > > Thanks, > Thomas Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26691#pullrequestreview-3109071738 From ayang at openjdk.org Tue Aug 12 08:14:58 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 12 Aug 2025 08:14:58 GMT Subject: RFR: 8365237: Remove unused SoftRefPolicy::_all_soft_refs_clear [v2] In-Reply-To: References: Message-ID: > Trivial removing effectively dead code. > > 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/26722/files - new: https://git.openjdk.org/jdk/pull/26722/files/7a8a54ad..c8447f7a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26722&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26722&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26722.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26722/head:pull/26722 PR: https://git.openjdk.org/jdk/pull/26722 From ayang at openjdk.org Tue Aug 12 08:32:16 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 12 Aug 2025 08:32:16 GMT Subject: RFR: 8365115: G1: Refactor rem set statistics gather code for group In-Reply-To: References: Message-ID: On Fri, 8 Aug 2025 09:39:42 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to remove some code duplication in group remset statistics gathering. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26691#pullrequestreview-3109240039 From tschatzl at openjdk.org Tue Aug 12 08:56:20 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 12 Aug 2025 08:56:20 GMT Subject: RFR: 8365122: G1: Minor clean up of G1SurvivorRegions [v2] In-Reply-To: References: Message-ID: <3aw5qTyvr81jj06dt2hsnbr4j_VPWt2OwuAy2RHf4IA=.435ff56a-0e13-4a4d-86c0-22e3d6b990b0@github.com> On Mon, 11 Aug 2025 17:00:53 GMT, Sangheon Kim wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * add growablearray include > > Looks good. Thanks @sangheon @kimbarrett for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/26692#issuecomment-3178363272 From tschatzl at openjdk.org Tue Aug 12 08:56:20 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 12 Aug 2025 08:56:20 GMT Subject: Integrated: 8365122: G1: Minor clean up of G1SurvivorRegions In-Reply-To: References: Message-ID: On Fri, 8 Aug 2025 10:10:07 GMT, Thomas Schatzl wrote: > Hi all, > > please review this small cleanup around `G1SurvivorRegions`: > > - make the `_regions` member a direct member of the class > - use the C++ for-each construct for iterating over `_regions` makes the code more readable > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 16e461ef Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/16e461ef31628ab47cd8484cdfc970c0008b97ba Stats: 27 lines in 3 files changed: 2 ins; 10 del; 15 mod 8365122: G1: Minor clean up of G1SurvivorRegions Reviewed-by: sangheki, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/26692 From ayang at openjdk.org Tue Aug 12 08:57:11 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 12 Aug 2025 08:57:11 GMT Subject: RFR: 8365026: G1: Initialization should start a "full" new collection set In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 10:05:52 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that makes G1 start a "full" new collection set at initialization time, calling `G1CollectedHeap::start_new_collection_set()`. > > Previously G1 only did part of that (start incremental building only), on a not-fully initialized collection set instance. It works, but is not nice. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26673#pullrequestreview-3109354875 From tschatzl at openjdk.org Tue Aug 12 09:05:43 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 12 Aug 2025 09:05:43 GMT Subject: RFR: 8342382: Implementation of JEP G1: Improve Application Throughput with a More Efficient Write-Barrier [v47] In-Reply-To: References: Message-ID: <8MXGEs7h-FkEkdBqBvzmyaV0yIQS-w2w3VV4nIrqtoI=.90d71538-ac03-479f-9772-d256703bb1a9@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 64 commits: - 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 - Merge branch 'master' into pull/23739 - 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 54 more: https://git.openjdk.org/jdk/compare/5a442197...7fe518ec ------------- Changes: https://git.openjdk.org/jdk/pull/23739/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=46 Stats: 7108 lines in 112 files changed: 2582 ins; 3587 del; 939 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 Tue Aug 12 09:08:10 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 12 Aug 2025 09:08:10 GMT Subject: RFR: 8365237: Remove unused SoftRefPolicy::_all_soft_refs_clear [v2] In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 08:14:58 GMT, Albert Mingkun Yang wrote: >> Trivial removing effectively dead code. >> >> Test: tier1 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Ship it! ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26722#pullrequestreview-3109399607 From ayang at openjdk.org Tue Aug 12 10:30:49 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 12 Aug 2025 10:30:49 GMT Subject: RFR: 8365316: Remove unnecessary default arg value in gcVMOperations Message-ID: Trivial removing effectively dead code. Test: tier1 ------------- Commit messages: - vm-op-remove-default-arg Changes: https://git.openjdk.org/jdk/pull/26741/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26741&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365316 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26741.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26741/head:pull/26741 PR: https://git.openjdk.org/jdk/pull/26741 From tschatzl at openjdk.org Tue Aug 12 10:37:10 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 12 Aug 2025 10:37:10 GMT Subject: RFR: 8365316: Remove unnecessary default arg value in gcVMOperations In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 10:23:54 GMT, Albert Mingkun Yang wrote: > Trivial removing effectively dead code. > > Test: tier1 Trivial. ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26741#pullrequestreview-3109831465 From ayang at openjdk.org Tue Aug 12 11:33:20 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 12 Aug 2025 11:33:20 GMT Subject: RFR: 8365237: Remove unused SoftRefPolicy::_all_soft_refs_clear [v2] In-Reply-To: References: Message-ID: <9E4nrxIEMfJwGflGHK0OLEvhyLdBad5qnr1cLcMp5d8=.6c2f3b83-92b7-45ef-9ba0-bd41b80a1239@github.com> On Tue, 12 Aug 2025 08:14:58 GMT, Albert Mingkun Yang wrote: >> Trivial removing effectively dead code. >> >> 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/26722#issuecomment-3178924678 From ayang at openjdk.org Tue Aug 12 11:33:21 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 12 Aug 2025 11:33:21 GMT Subject: Integrated: 8365237: Remove unused SoftRefPolicy::_all_soft_refs_clear In-Reply-To: References: Message-ID: On Mon, 11 Aug 2025 10:35:26 GMT, Albert Mingkun Yang wrote: > Trivial removing effectively dead code. > > Test: tier1 This pull request has now been integrated. Changeset: 95b7a8b3 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/95b7a8b3e300bf40a2a5bdf8ca8310485db363e6 Stats: 34 lines in 3 files changed: 0 ins; 33 del; 1 mod 8365237: Remove unused SoftRefPolicy::_all_soft_refs_clear Reviewed-by: tschatzl, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/26722 From ayang at openjdk.org Tue Aug 12 11:56:19 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 12 Aug 2025 11:56:19 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v4] In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 09:49:12 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). >> >> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: >> >> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() >> >> CPUTimeUsage::GC::gc_threads() >> CPUTimeUsage::GC::vm_thread() >> CPUTimeUsage::GC::stringdedup() >> >> CPUTimeUsage::Runtime::vm_thread() >> >> >> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. >> >> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: >> >> >> [71.425s][info][cpu ] === CPU time Statistics ============================================================= >> [71.425s][info][cpu ] CPUs >> [71.425s][info][cpu ] s % utilized >> [71.425s][info][cpu ] Process >> [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 >> [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 >> [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 >> [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 >> [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 >> [71.425s][info][cpu ] ===================================================================================== >> >> >> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Improve robustness src/hotspot/os/linux/os_linux.cpp line 4953: > 4951: // to detach itself from the VM - which should result in ESRCH. > 4952: assert_status(rc == ESRCH, rc, "pthread_getcpuclockid failed"); > 4953: log_warning(os)("Could not sample thread CPU time"); Maybe diff msgs can be printed so that we know better what went wrong if `-1` is returned. src/hotspot/share/gc/shared/collectedHeap.cpp line 610: > 608: } > 609: > 610: double calc_usage(double component_cpu_time, double process_cpu_time) { Could `percent_of` be used instead? src/hotspot/share/gc/shared/collectedHeap.cpp line 627: > 625: > 626: LogTarget(Info, cpu) cpuLog; > 627: if (cpuLog.is_enabled()) { Can use early-return to reduce one indentation level. src/hotspot/share/gc/shared/collectedHeap.hpp line 468: > 466: virtual void gc_threads_do(ThreadClosure* tc) const = 0; > 467: > 468: jlong elapsed_gc_cpu_time() const; Seems unused. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2269575257 PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2269582730 PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2269586175 PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2269589768 From ayang at openjdk.org Tue Aug 12 12:03:17 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 12 Aug 2025 12:03:17 GMT Subject: RFR: 8365316: Remove unnecessary default arg value in gcVMOperations In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 10:23:54 GMT, Albert Mingkun Yang wrote: > Trivial removing effectively dead code. > > Test: tier1 Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26741#issuecomment-3179016256 From ayang at openjdk.org Tue Aug 12 12:03:18 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 12 Aug 2025 12:03:18 GMT Subject: Integrated: 8365316: Remove unnecessary default arg value in gcVMOperations In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 10:23:54 GMT, Albert Mingkun Yang wrote: > Trivial removing effectively dead code. > > Test: tier1 This pull request has now been integrated. Changeset: 19a76a45 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/19a76a45e9c8616414830c865801660bc6761e92 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8365316: Remove unnecessary default arg value in gcVMOperations Reviewed-by: tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/26741 From duke at openjdk.org Tue Aug 12 12:24:35 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Tue, 12 Aug 2025 12:24:35 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v5] In-Reply-To: References: Message-ID: > Hi all, > > This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). > > As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: > > CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() > > CPUTimeUsage::GC::gc_threads() > CPUTimeUsage::GC::vm_thread() > CPUTimeUsage::GC::stringdedup() > > CPUTimeUsage::Runtime::vm_thread() > > > I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. > > I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: > > > [71.425s][info][cpu ] === CPU time Statistics ============================================================= > [71.425s][info][cpu ] CPUs > [71.425s][info][cpu ] s % utilized > [71.425s][info][cpu ] Process > [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 > [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 > [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 > [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 > [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 > [71.425s][info][cpu ] ===================================================================================== > > > Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Feedback from Albert ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26621/files - new: https://git.openjdk.org/jdk/pull/26621/files/3f552362..143fcacb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=03-04 Stats: 34 lines in 3 files changed: 2 ins; 7 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/26621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621 PR: https://git.openjdk.org/jdk/pull/26621 From duke at openjdk.org Tue Aug 12 12:24:37 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Tue, 12 Aug 2025 12:24:37 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v4] In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 09:49:12 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). >> >> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: >> >> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() >> >> CPUTimeUsage::GC::gc_threads() >> CPUTimeUsage::GC::vm_thread() >> CPUTimeUsage::GC::stringdedup() >> >> CPUTimeUsage::Runtime::vm_thread() >> >> >> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. >> >> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: >> >> >> [71.425s][info][cpu ] === CPU time Statistics ============================================================= >> [71.425s][info][cpu ] CPUs >> [71.425s][info][cpu ] s % utilized >> [71.425s][info][cpu ] Process >> [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 >> [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 >> [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 >> [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 >> [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 >> [71.425s][info][cpu ] ===================================================================================== >> >> >> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Improve robustness Thanks for the review @albertnetymk! I pushed changes reflecting your feedback. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26621#issuecomment-3179095971 From jsikstro at openjdk.org Tue Aug 12 12:48:23 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Tue, 12 Aug 2025 12:48:23 GMT Subject: RFR: 8365317: ZGC: Setting ZYoungGCThreads lower than ZOldGCThreads may result in a crash Message-ID: Hello, Setting ZYoungGCThreads lower than ZOldGCThreads may result in a crash, for example using `-XX:ZYoungGCThreads=4` and `-XX:ZOldGCThreads=8`. The problem is in `select_worker_threads()` in zDirector.cpp, where the number of young threads may be set to the number of old threads in an attempt to speed up the young collection so that the old collection can begin faster in a major collection. If the number of old threads exceed the maximum number of young threads, i.e. ZYoungGCThreads, a crash may occur. See the JBS issue for details on the crash. Even though it may not be common, or reasonable in all scenarios, to set the maximum number of young threads to less than the maximum number of old threads, the combination should be possible and not result in a crash. To solve this issue, I suggest we clamp or otherwise limit the number of young threads to the maximum amount of young threads (i.e., `ZYoungGCThreads`). Testing: * I will run this through Oracle's testing. * I can no longer observe the intermittent crashes in release builds after 1000 runs. ------------- Commit messages: - 8365317: ZGC: Setting ZYoungGCThreads lower than ZOldGCThreads may result in a crash Changes: https://git.openjdk.org/jdk/pull/26745/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26745&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365317 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26745.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26745/head:pull/26745 PR: https://git.openjdk.org/jdk/pull/26745 From tschatzl at openjdk.org Tue Aug 12 13:00:11 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 12 Aug 2025 13:00:11 GMT Subject: RFR: 8365317: ZGC: Setting ZYoungGCThreads lower than ZOldGCThreads may result in a crash In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 12:35:57 GMT, Joel Sikstr?m wrote: > Hello, > > Setting ZYoungGCThreads lower than ZOldGCThreads may result in a crash, for example using `-XX:ZYoungGCThreads=4` and `-XX:ZOldGCThreads=8`. The problem is in `select_worker_threads()` in zDirector.cpp, where the number of young threads may be set to the number of old threads in an attempt to speed up the young collection so that the old collection can begin faster in a major collection. If the number of old threads exceed the maximum number of young threads, i.e. ZYoungGCThreads, a crash may occur. See the JBS issue for details on the crash. > > Even though it may not be common, or reasonable in all scenarios, to set the maximum number of young threads to less than the maximum number of old threads, the combination should be possible and not result in a crash. To solve this issue, I suggest we clamp or otherwise limit the number of young threads to the maximum amount of young threads (i.e., `ZYoungGCThreads`). > > Testing: > * I will run this through Oracle's testing. > * I can no longer observe the intermittent crashes in release builds after 1000 runs. Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26745#pullrequestreview-3110491401 From ayang at openjdk.org Tue Aug 12 15:20:18 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 12 Aug 2025 15:20:18 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v5] In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 12:24:35 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). >> >> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: >> >> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() >> >> CPUTimeUsage::GC::gc_threads() >> CPUTimeUsage::GC::vm_thread() >> CPUTimeUsage::GC::stringdedup() >> >> CPUTimeUsage::Runtime::vm_thread() >> >> >> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. >> >> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: >> >> >> [71.425s][info][cpu ] === CPU time Statistics ============================================================= >> [71.425s][info][cpu ] CPUs >> [71.425s][info][cpu ] s % utilized >> [71.425s][info][cpu ] Process >> [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 >> [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 >> [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 >> [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 >> [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 >> [71.425s][info][cpu ] ===================================================================================== >> >> >> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Feedback from Albert src/hotspot/share/gc/shared/collectedHeap.cpp line 610: > 608: } > 609: > 610: double percent_of(double component_cpu_time, double process_cpu_time) { There is global function, `percent_of`. Can that be used directly? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2270240264 From eosterlund at openjdk.org Wed Aug 13 10:28:10 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 13 Aug 2025 10:28:10 GMT Subject: RFR: 8365317: ZGC: Setting ZYoungGCThreads lower than ZOldGCThreads may result in a crash In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 12:35:57 GMT, Joel Sikstr?m wrote: > Hello, > > Setting ZYoungGCThreads lower than ZOldGCThreads may result in a crash, for example using `-XX:ZYoungGCThreads=4` and `-XX:ZOldGCThreads=8`. The problem is in `select_worker_threads()` in zDirector.cpp, where the number of young threads may be set to the number of old threads in an attempt to speed up the young collection so that the old collection can begin faster in a major collection. If the number of old threads exceed the maximum number of young threads, i.e. ZYoungGCThreads, a crash may occur. See the JBS issue for details on the crash. > > Even though it may not be common, or reasonable in all scenarios, to set the maximum number of young threads to less than the maximum number of old threads, the combination should be possible and not result in a crash. To solve this issue, I suggest we clamp or otherwise limit the number of young threads to the maximum amount of young threads (i.e., `ZYoungGCThreads`). > > Testing: > * Oracle's tier1-2, both with and without `-XX:ConcGCThreads=20 -XX:ZYoungGCThreads=2 -XX:ZOldGCThreadds=20` pass. > * I can no longer observe the intermittent crashes in release builds after 1000 runs. Nice catch. Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26745#pullrequestreview-3115086496 From ayang at openjdk.org Wed Aug 13 10:48:14 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 13 Aug 2025 10:48:14 GMT Subject: RFR: 8364628: Serial: Refactor SerialHeap::mem_allocate_work [v2] In-Reply-To: References: Message-ID: > Extract out old-gen allocation outside the critical-region to streamline the flow in `mem_allocate_work`. > > Test: tier1-5 Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into sgc-mem-allocate - sgc-mem-allocate ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26619/files - new: https://git.openjdk.org/jdk/pull/26619/files/e1c6c3de..0b0587ad Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26619&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26619&range=00-01 Stats: 15548 lines in 418 files changed: 8300 ins; 5464 del; 1784 mod Patch: https://git.openjdk.org/jdk/pull/26619.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26619/head:pull/26619 PR: https://git.openjdk.org/jdk/pull/26619 From ayang at openjdk.org Wed Aug 13 11:13:13 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 13 Aug 2025 11:13:13 GMT Subject: RFR: 8364628: Serial: Refactor SerialHeap::mem_allocate_work [v2] In-Reply-To: References: Message-ID: <1cixMWxslbNUc3JNwsKwtcSh1cKPtBIcLSYNS1C1MMc=.3a1b2fc7-987d-41cb-ade6-af68c15c0ccf@github.com> On Thu, 7 Aug 2025 23:19:55 GMT, Paul Hohensee 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 two additional commits since the last revision: >> >> - Merge branch 'master' into sgc-mem-allocate >> - sgc-mem-allocate > > There's quite a lot of duplicate code in all four of these files. Perhaps take the opportunity to consolidate? @phohensee Ping? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26619#issuecomment-3183358296 From phh at openjdk.org Wed Aug 13 21:29:12 2025 From: phh at openjdk.org (Paul Hohensee) Date: Wed, 13 Aug 2025 21:29:12 GMT Subject: RFR: 8364628: Serial: Refactor SerialHeap::mem_allocate_work [v2] In-Reply-To: References: Message-ID: On Wed, 13 Aug 2025 10:48:14 GMT, Albert Mingkun Yang wrote: >> Extract out old-gen allocation outside the critical-region to streamline the flow in `mem_allocate_work`. >> >> Test: tier1-5 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into sgc-mem-allocate > - sgc-mem-allocate You're correct. Somehow my browser view messed up. Went to the webrev and all is well. Apologies. ------------- Marked as reviewed by phh (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26619#pullrequestreview-3117759543 From kbarrett at openjdk.org Thu Aug 14 07:00:10 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 14 Aug 2025 07:00:10 GMT Subject: RFR: 8365026: G1: Initialization should start a "full" new collection set In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 10:05:52 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that makes G1 start a "full" new collection set at initialization time, calling `G1CollectedHeap::start_new_collection_set()`. > > Previously G1 only did part of that (start incremental building only), on a not-fully initialized collection set instance. It works, but is not nice. > > Testing: gha > > Thanks, > Thomas Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26673#pullrequestreview-3119250472 From kbarrett at openjdk.org Thu Aug 14 07:04:10 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 14 Aug 2025 07:04:10 GMT Subject: RFR: 8365024: G1: Make G1CollectionSet::_inc_build_state assert-only In-Reply-To: References: Message-ID: <6zcvlT70XOWeoe7wRy9Z7wXXoepNYfcOtSauaBj9bn0=.97fdfed2-8ba2-458c-8eef-45320a5d88a3@github.com> On Thu, 7 Aug 2025 09:46:52 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that makes the `G1CollectionSet::_inc_build_state` member debug/assert-only - it's only ever used in assertions. > > Testing: local compilation, gha > > Thanks, > Thomas Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26671#pullrequestreview-3119260194 From kbarrett at openjdk.org Thu Aug 14 07:12:09 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 14 Aug 2025 07:12:09 GMT Subject: RFR: 8364934: G1: Rename members of G1CollectionSet [v3] In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 16:15:34 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this renaming of various members of `G1CollectionSet` to >> >> - use the same prefixes for the regions ("_regions") and candidate groups ("_groups") consistently, avoiding adding prefixes here and there for no discernible reason >> - remove unnecessary prefixes (`collection_set`) - everything is part of the collection set >> - fix/improve some documentation >> >> Testing: gha >> >> Thanks, >> THoams > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * one more renaming: prepare_groups_for_scan() -> prepare_for_scan() Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26670#pullrequestreview-3119281399 From kbarrett at openjdk.org Thu Aug 14 07:16:11 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 14 Aug 2025 07:16:11 GMT Subject: RFR: 8365055: G1: Merge Heap Roots phase incorrectly clears young gen remembered set every time [v2] In-Reply-To: References: <8JFuOjov4pzLsgan8_D26HNVtWFNTBm7OzuMMwRVUAM=.f557c3d1-ccef-4ea2-ad9c-0c4a217f24b4@github.com> Message-ID: <03ScRZfaRFAyDx6pK1vxesLEoLxi0-DQ4iBTF-C-KUc=.ba2cb65c-3a6a-46a5-bf06-3778c57a3650@github.com> On Fri, 8 Aug 2025 14:12:31 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this fix to G1 heap root merging that cleared the young gen remembered set multiple times (for every merging) and overwriting the most recent statistics for the number of young gen cards. >> >> The latter is probably the more problematic, as it directly impacts young gen sizing statistics, potentially making young gen too large. >> >> The fix is to move the two statements to the proper place - get current number of young gen cards at startup, clear the young gen remset when starting a new collection set - we do not need to do that earlier after all. Additionally we can add some (superfluous?) verification that during GC we really do not add to the young gen remset. >> >> Testing: tier1-5 >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * fix comment in verification code > * move that G1Policy member to G1CollectedHeap as it's used to verify stuff in G1CollectedHeap (and not used elsewhere anyway) Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26695#pullrequestreview-3119291686 From jsikstro at openjdk.org Thu Aug 14 07:40:28 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Thu, 14 Aug 2025 07:40:28 GMT Subject: RFR: 8365317: ZGC: Setting ZYoungGCThreads lower than ZOldGCThreads may result in a crash In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 12:57:41 GMT, Thomas Schatzl wrote: >> Hello, >> >> Setting ZYoungGCThreads lower than ZOldGCThreads may result in a crash, for example using `-XX:ZYoungGCThreads=4` and `-XX:ZOldGCThreads=8`. The problem is in `select_worker_threads()` in zDirector.cpp, where the number of young threads may be set to the number of old threads in an attempt to speed up the young collection so that the old collection can begin faster in a major collection. If the number of old threads exceed the maximum number of young threads, i.e. ZYoungGCThreads, a crash may occur. See the JBS issue for details on the crash. >> >> Even though it may not be common, or reasonable in all scenarios, to set the maximum number of young threads to less than the maximum number of old threads, the combination should be possible and not result in a crash. To solve this issue, I suggest we clamp or otherwise limit the number of young threads to the maximum amount of young threads (i.e., `ZYoungGCThreads`). >> >> Testing: >> * Oracle's tier1-2, both with and without `-XX:ConcGCThreads=20 -XX:ZYoungGCThreads=2 -XX:ZOldGCThreadds=20` pass. >> * I can no longer observe the intermittent crashes in release builds after 1000 runs. > > Marked as reviewed by tschatzl (Reviewer). Thank you for the reviews! @tschatzl @fisk ------------- PR Comment: https://git.openjdk.org/jdk/pull/26745#issuecomment-3187293723 From jsikstro at openjdk.org Thu Aug 14 07:40:29 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Thu, 14 Aug 2025 07:40:29 GMT Subject: Integrated: 8365317: ZGC: Setting ZYoungGCThreads lower than ZOldGCThreads may result in a crash In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 12:35:57 GMT, Joel Sikstr?m wrote: > Hello, > > Setting ZYoungGCThreads lower than ZOldGCThreads may result in a crash, for example using `-XX:ZYoungGCThreads=4` and `-XX:ZOldGCThreads=8`. The problem is in `select_worker_threads()` in zDirector.cpp, where the number of young threads may be set to the number of old threads in an attempt to speed up the young collection so that the old collection can begin faster in a major collection. If the number of old threads exceed the maximum number of young threads, i.e. ZYoungGCThreads, a crash may occur. See the JBS issue for details on the crash. > > Even though it may not be common, or reasonable in all scenarios, to set the maximum number of young threads to less than the maximum number of old threads, the combination should be possible and not result in a crash. To solve this issue, I suggest we clamp or otherwise limit the number of young threads to the maximum amount of young threads (i.e., `ZYoungGCThreads`). > > Testing: > * Oracle's tier1-2, both with and without `-XX:ConcGCThreads=20 -XX:ZYoungGCThreads=2 -XX:ZOldGCThreadds=20` pass. > * I can no longer observe the intermittent crashes in release builds after 1000 runs. This pull request has now been integrated. Changeset: 3e329850 Author: Joel Sikstr?m URL: https://git.openjdk.org/jdk/commit/3e3298509f136583b18e5ab8bf75a8b012016f16 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8365317: ZGC: Setting ZYoungGCThreads lower than ZOldGCThreads may result in a crash Reviewed-by: tschatzl, eosterlund ------------- PR: https://git.openjdk.org/jdk/pull/26745 From sjohanss at openjdk.org Thu Aug 14 08:05:17 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Thu, 14 Aug 2025 08:05:17 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v5] In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 12:24:35 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). >> >> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: >> >> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() >> >> CPUTimeUsage::GC::gc_threads() >> CPUTimeUsage::GC::vm_thread() >> CPUTimeUsage::GC::stringdedup() >> >> CPUTimeUsage::Runtime::vm_thread() >> >> >> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. >> >> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: >> >> >> [71.425s][info][cpu ] === CPU time Statistics ============================================================= >> [71.425s][info][cpu ] CPUs >> [71.425s][info][cpu ] s % utilized >> [71.425s][info][cpu ] Process >> [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 >> [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 >> [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 >> [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 >> [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 >> [71.425s][info][cpu ] ===================================================================================== >> >> >> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Feedback from Albert Thanks for looking at this and improving the CPU tracking and making it easily accessible. Overall I think the change looks good, just a few comments/questions. src/hotspot/os/linux/os_linux.cpp line 4953: > 4951: // to detach itself from the VM - which should result in ESRCH. > 4952: assert_status(rc == ESRCH, rc, "pthread_getcpuclockid failed"); > 4953: log_warning(os)("Could not sample thread CPU time (return code %d)", rc); Do we really want add a warning here? This API is used from a lot a places and reading the comment above i sound like it might happen from time to time without it being a very big deal? The risk I see is that we sometimes will get a bunch of these warning in test and they will fail because we can't handle the additional output. The same goes for the other warnings below. src/hotspot/share/gc/shared/collectedHeap.cpp line 655: > 653: print_tracing_info(); > 654: > 655: log_cpu_time(); As mentioned offline, I would prefer if this was moved away from `CollectedHeap` since it is now not only GC/Heap related times that are tracked. We could add a `Universe::before_exit()` which firsts does the CPU logging before calling `heap()->before_exit()`. As long as we do the logging before, would there be any problem with this? ------------- Changes requested by sjohanss (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26621#pullrequestreview-3119416367 PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2275777432 PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2275805357 From kbarrett at openjdk.org Thu Aug 14 10:29:12 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 14 Aug 2025 10:29:12 GMT Subject: RFR: 8364628: Serial: Refactor SerialHeap::mem_allocate_work [v2] In-Reply-To: References: Message-ID: On Wed, 13 Aug 2025 10:48:14 GMT, Albert Mingkun Yang wrote: >> Extract out old-gen allocation outside the critical-region to streamline the flow in `mem_allocate_work`. >> >> Test: tier1-5 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into sgc-mem-allocate > - sgc-mem-allocate src/hotspot/share/gc/serial/serialHeap.cpp line 312: > 310: if (!is_tlab) { > 311: // If it's too large for young-gen or heap is too full. > 312: if (size > heap_word_size(_young_gen->capacity_before_gc()) || _is_heap_almost_full) { I'm not sure inlining (and removing now unused) helper `should_try_older_generation_allocation` is an improvement. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26619#discussion_r2276040325 From sjohanss at openjdk.org Thu Aug 14 11:30:18 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Thu, 14 Aug 2025 11:30:18 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v5] In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 07:49:26 GMT, Stefan Johansson wrote: >> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback from Albert > > src/hotspot/os/linux/os_linux.cpp line 4953: > >> 4951: // to detach itself from the VM - which should result in ESRCH. >> 4952: assert_status(rc == ESRCH, rc, "pthread_getcpuclockid failed"); >> 4953: log_warning(os)("Could not sample thread CPU time (return code %d)", rc); > > Do we really want add a warning here? This API is used from a lot a places and reading the comment above i sound like it might happen from time to time without it being a very big deal? > > The risk I see is that we sometimes will get a bunch of these warning in test and they will fail because we can't handle the additional output. > > The same goes for the other warnings below. Looked closer at the users of this and one user is `ThreadMXBean.getThreadCpuTime(long id)`. Looking at the API docs for that, returning -1 is not a error but the expected result for a terminated thread. So I think we should remove these warnings. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2276356967 From ayang at openjdk.org Thu Aug 14 12:18:11 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 14 Aug 2025 12:18:11 GMT Subject: RFR: 8364628: Serial: Refactor SerialHeap::mem_allocate_work [v2] In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 09:14:15 GMT, Kim Barrett 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 two additional commits since the last revision: >> >> - Merge branch 'master' into sgc-mem-allocate >> - sgc-mem-allocate > > src/hotspot/share/gc/serial/serialHeap.cpp line 312: > >> 310: if (!is_tlab) { >> 311: // If it's too large for young-gen or heap is too full. >> 312: if (size > heap_word_size(_young_gen->capacity_before_gc()) || _is_heap_almost_full) { > > I'm not sure inlining (and removing now unused) helper `should_try_older_generation_allocation` > is an improvement. The decision whether a particular allocation, after that fails with young-gen, should use old-gen or not is largely caller-specific. There are three places where we perform old-gen-allocation after failed young-gen-allocation, one in `mem_allocate_work` and two in `satisfy_failed_allocation`. In the first case, we wanna limit old-gen-allocation to large objs only, because it's desirable to have regular young-gc that can keep the footprint low. Having a dedicate API named `should_try_older_generation_allocation` can give the wrong impression that this method provides the global policy for old-gen-allocation. Therefore, I think it's clearer to inline it to its sole caller. (There are other cleanup PRs in the pipeline to simplify the logic of `DefNewGeneration::should_allocate` and `TenuredGeneration::should_allocate` to further streamline the flow of this method.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26619#discussion_r2276463080 From ayang at openjdk.org Thu Aug 14 12:22:13 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 14 Aug 2025 12:22:13 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v5] In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 11:27:10 GMT, Stefan Johansson wrote: >> src/hotspot/os/linux/os_linux.cpp line 4953: >> >>> 4951: // to detach itself from the VM - which should result in ESRCH. >>> 4952: assert_status(rc == ESRCH, rc, "pthread_getcpuclockid failed"); >>> 4953: log_warning(os)("Could not sample thread CPU time (return code %d)", rc); >> >> Do we really want add a warning here? This API is used from a lot a places and reading the comment above i sound like it might happen from time to time without it being a very big deal? >> >> The risk I see is that we sometimes will get a bunch of these warning in test and they will fail because we can't handle the additional output. >> >> The same goes for the other warnings below. > > Looked closer at the users of this and one user is `ThreadMXBean.getThreadCpuTime(long id)`. Looking at the API docs for that, returning -1 is not a error but the expected result for a terminated thread. So I think we should remove these warnings. > ... it might happen from time to time without it being a very big deal? My concern is that we get a number on cpu-time without knowing the number is off by a large margin when failure occurs, so there should probably be some warning/msg somewhere. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2276473605 From duke at openjdk.org Thu Aug 14 13:11:12 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Thu, 14 Aug 2025 13:11:12 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v5] In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 12:19:58 GMT, Albert Mingkun Yang wrote: >> Looked closer at the users of this and one user is `ThreadMXBean.getThreadCpuTime(long id)`. Looking at the API docs for that, returning -1 is not a error but the expected result for a terminated thread. So I think we should remove these warnings. > >> ... it might happen from time to time without it being a very big deal? > > My concern is that we get a number on cpu-time without knowing the number is off by a large margin when failure occurs, so there should probably be some warning/msg somewhere. I don't sample GC threads that have terminated, so I would prefer not having the warning as well, as it would not fail unless the machine is in a bad state and then we would have larger issues at hand anyways? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2276583734 From duke at openjdk.org Thu Aug 14 13:11:14 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Thu, 14 Aug 2025 13:11:14 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v5] In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 15:17:19 GMT, Albert Mingkun Yang wrote: >> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback from Albert > > src/hotspot/share/gc/shared/collectedHeap.cpp line 610: > >> 608: } >> 609: >> 610: double percent_of(double component_cpu_time, double process_cpu_time) { > > There is global function, `percent_of`. Can that be used directly? Thanks! Certainly I misread your previous suggestion as a rename suggestion as I was not aware of that global function :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2276587345 From kbarrett at openjdk.org Thu Aug 14 13:43:16 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 14 Aug 2025 13:43:16 GMT Subject: RFR: 8364628: Serial: Refactor SerialHeap::mem_allocate_work [v2] In-Reply-To: References: Message-ID: On Wed, 13 Aug 2025 10:48:14 GMT, Albert Mingkun Yang wrote: >> Extract out old-gen allocation outside the critical-region to streamline the flow in `mem_allocate_work`. >> >> Test: tier1-5 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into sgc-mem-allocate > - sgc-mem-allocate Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26619#pullrequestreview-3120646786 From kbarrett at openjdk.org Thu Aug 14 13:43:18 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 14 Aug 2025 13:43:18 GMT Subject: RFR: 8364628: Serial: Refactor SerialHeap::mem_allocate_work [v2] In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 12:15:18 GMT, Albert Mingkun Yang wrote: >> src/hotspot/share/gc/serial/serialHeap.cpp line 312: >> >>> 310: if (!is_tlab) { >>> 311: // If it's too large for young-gen or heap is too full. >>> 312: if (size > heap_word_size(_young_gen->capacity_before_gc()) || _is_heap_almost_full) { >> >> I'm not sure inlining (and removing now unused) helper `should_try_older_generation_allocation` >> is an improvement. > > The decision whether a particular allocation, after that fails with young-gen, should use old-gen or not is largely caller-specific. There are three places where we perform old-gen-allocation after failed young-gen-allocation, one in `mem_allocate_work` and two in `satisfy_failed_allocation`. In the first case, we wanna limit old-gen-allocation to large objs only, because it's desirable to have regular young-gc that can keep the footprint low. > > Having a dedicate API named `should_try_older_generation_allocation` can give the wrong impression that this method provides the global policy for old-gen-allocation. > > Therefore, I think it's clearer to inline it to its sole caller. (There are other cleanup PRs in the pipeline to simplify the logic of `DefNewGeneration::should_allocate` and `TenuredGeneration::should_allocate` to further streamline the flow of this method.) Thanks for the explanation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26619#discussion_r2276672920 From duke at openjdk.org Thu Aug 14 14:12:18 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Thu, 14 Aug 2025 14:12:18 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v6] In-Reply-To: References: Message-ID: > Hi all, > > This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). > > As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: > > CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() > > CPUTimeUsage::GC::gc_threads() > CPUTimeUsage::GC::vm_thread() > CPUTimeUsage::GC::stringdedup() > > CPUTimeUsage::Runtime::vm_thread() > > > I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. > > I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: > > > [71.425s][info][cpu ] === CPU time Statistics ============================================================= > [71.425s][info][cpu ] CPUs > [71.425s][info][cpu ] s % utilized > [71.425s][info][cpu ] Process > [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 > [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 > [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 > [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 > [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 > [71.425s][info][cpu ] ===================================================================================== > > > Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision: - Minor improvements and fixes per @kstefanj suggestions - use percent_of from globalDefinitions.hpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26621/files - new: https://git.openjdk.org/jdk/pull/26621/files/143fcacb..ddab1f0b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=04-05 Stats: 118 lines in 4 files changed: 60 ins; 57 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621 PR: https://git.openjdk.org/jdk/pull/26621 From duke at openjdk.org Thu Aug 14 14:12:21 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Thu, 14 Aug 2025 14:12:21 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v5] In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 08:02:45 GMT, Stefan Johansson wrote: >> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback from Albert > > Thanks for looking at this and improving the CPU tracking and making it easily accessible. > > Overall I think the change looks good, just a few comments/questions. Thanks for the review @kstefanj! I've pushed a patch reflecting your suggestions, but saved removal of log_warning until we have a consensus on a path forward. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26621#issuecomment-3188595880 From ayang at openjdk.org Thu Aug 14 14:50:20 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 14 Aug 2025 14:50:20 GMT Subject: RFR: 8364628: Serial: Refactor SerialHeap::mem_allocate_work [v2] In-Reply-To: References: Message-ID: On Wed, 13 Aug 2025 10:48:14 GMT, Albert Mingkun Yang wrote: >> Extract out old-gen allocation outside the critical-region to streamline the flow in `mem_allocate_work`. >> >> Test: tier1-5 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into sgc-mem-allocate > - sgc-mem-allocate Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26619#issuecomment-3188733625 From ayang at openjdk.org Thu Aug 14 14:54:17 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 14 Aug 2025 14:54:17 GMT Subject: Integrated: 8364628: Serial: Refactor SerialHeap::mem_allocate_work In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 10:01:15 GMT, Albert Mingkun Yang wrote: > Extract out old-gen allocation outside the critical-region to streamline the flow in `mem_allocate_work`. > > Test: tier1-5 This pull request has now been integrated. Changeset: dd113c8d Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/dd113c8df06cc7e1465fb3dfef2e9b2a5a99f1fb Stats: 59 lines in 4 files changed: 22 ins; 31 del; 6 mod 8364628: Serial: Refactor SerialHeap::mem_allocate_work Reviewed-by: phh, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/26619 From ayang at openjdk.org Thu Aug 14 14:55:51 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 14 Aug 2025 14:55:51 GMT Subject: RFR: 8365557: Parallel: Refactor ParallelScavengeHeap::mem_allocate_work 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 ------------- Commit messages: - pgc-mem-allocate-refactor Changes: https://git.openjdk.org/jdk/pull/26779/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26779&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365557 Stats: 47 lines in 2 files changed: 14 ins; 27 del; 6 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 wkemper at openjdk.org Thu Aug 14 18:22:31 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 14 Aug 2025 18:22:31 GMT Subject: RFR: 8365571: GenShen: PLAB promotions may remain disabled for evacuation threads Message-ID: Mutators and GC workers have old generation LABs for promotions and old generation evacuations. Priority is given to old evacuations by using a promotion budget. Once the promotion budget is exhausted, a thread local flag is set to disable further promotions (the LAB can still be used for old evacuations). This thread local flag is meant to be cleared to allow all threads to resume promotions on the next cycle. However, this flag is only reset for workers that perform thread root evacuations, which may not be the same workers that perform subsequent evacuations. This patch clears the flag for all threads when their LABs are retired at the end of evacuation. ------------- Commit messages: - Re-enable plab promotions for all threads when plabs are retired Changes: https://git.openjdk.org/jdk/pull/26785/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26785&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365571 Stats: 24 lines in 2 files changed: 5 ins; 15 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26785.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26785/head:pull/26785 PR: https://git.openjdk.org/jdk/pull/26785 From wkemper at openjdk.org Thu Aug 14 19:26:52 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 14 Aug 2025 19:26:52 GMT Subject: RFR: 8365572: Shenandoah: Remove unused thread local _paced_time field Message-ID: We missed this spot when removing the ShenandoahPacer. ------------- Commit messages: - Remove unused ShenandoahThreadLocalData::_paced_time Changes: https://git.openjdk.org/jdk/pull/26788/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26788&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365572 Stats: 15 lines in 2 files changed: 0 ins; 15 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26788.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26788/head:pull/26788 PR: https://git.openjdk.org/jdk/pull/26788 From shade at openjdk.org Thu Aug 14 19:33:14 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 14 Aug 2025 19:33:14 GMT Subject: RFR: 8365572: Shenandoah: Remove unused thread local _paced_time field In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 19:21:34 GMT, William Kemper wrote: > We missed this spot when removing the ShenandoahPacer. Right. Looks good! ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26788#pullrequestreview-3121877645 From wkemper at openjdk.org Thu Aug 14 20:02:19 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 14 Aug 2025 20:02:19 GMT Subject: Integrated: 8365572: Shenandoah: Remove unused thread local _paced_time field In-Reply-To: References: Message-ID: <8BpPi84im-8JicE0VBKcZ2nPlx4D1JNOeVH_MZll4JI=.50559f89-e2a7-41c6-945c-c1202670348f@github.com> On Thu, 14 Aug 2025 19:21:34 GMT, William Kemper wrote: > We missed this spot when removing the ShenandoahPacer. This pull request has now been integrated. Changeset: dccca0fb Author: William Kemper URL: https://git.openjdk.org/jdk/commit/dccca0fb7a892d31179b70fa861b8b3cdde54e84 Stats: 15 lines in 2 files changed: 0 ins; 15 del; 0 mod 8365572: Shenandoah: Remove unused thread local _paced_time field Reviewed-by: shade ------------- PR: https://git.openjdk.org/jdk/pull/26788 From dlong at openjdk.org Thu Aug 14 20:40:17 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 14 Aug 2025 20:40:17 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v5] In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 21:26:22 GMT, Dean Long wrote: >> This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value. Further, it takes a fast-path that uses the previous direct store when at a safepoint. Combined, these changes should get us back to almost where we were before in terms of overhead. If necessary, we could go even further and allow make_not_entrant() to perform a direct byte store, leaving 24 bits for the guard value. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > one unconditional release should be enough I'm not convinced the ZGC regression is real. I see a 1% variance between runs even with the same binary and flags, so it looks like just noise. For this PR I'll stop here. If it turns out that ZGC or Shenandoah do have a small regression because of CAS, we can use direct stores as long as they are done inside a lock, which should be true already for disarm() but would need to be added for make_not_entrant(). @fisk , can I get you to review this? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26399#issuecomment-3189805391 PR Comment: https://git.openjdk.org/jdk/pull/26399#issuecomment-3189809429 From kdnilsen at openjdk.org Thu Aug 14 23:36:09 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 14 Aug 2025 23:36:09 GMT Subject: RFR: 8365571: GenShen: PLAB promotions may remain disabled for evacuation threads In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 18:15:00 GMT, William Kemper wrote: > Mutators and GC workers have old generation LABs for promotions and old generation evacuations. Priority is given to old evacuations by using a promotion budget. Once the promotion budget is exhausted, a thread local flag is set to disable further promotions (the LAB can still be used for old evacuations). This thread local flag is meant to be cleared to allow all threads to resume promotions on the next cycle. However, this flag is only reset for workers that perform thread root evacuations, which may not be the same workers that perform subsequent evacuations. This patch clears the flag for all threads when their LABs are retired at the end of evacuation. Thank you for much improved code structure, and for fixing this bug. Would be nice to share any improved performance results with this fix in place. ------------- Marked as reviewed by kdnilsen (Committer). PR Review: https://git.openjdk.org/jdk/pull/26785#pullrequestreview-3122435215 From ysr at openjdk.org Fri Aug 15 02:40:11 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Fri, 15 Aug 2025 02:40:11 GMT Subject: RFR: 8365571: GenShen: PLAB promotions may remain disabled for evacuation threads In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 18:15:00 GMT, William Kemper wrote: > Mutators and GC workers have old generation LABs for promotions and old generation evacuations. Priority is given to old evacuations by using a promotion budget. Once the promotion budget is exhausted, a thread local flag is set to disable further promotions (the LAB can still be used for old evacuations). This thread local flag is meant to be cleared to allow all threads to resume promotions on the next cycle. However, this flag is only reset for workers that perform thread root evacuations, which may not be the same workers that perform subsequent evacuations. This patch clears the flag for all threads when their LABs are retired at the end of evacuation. Marked as reviewed by ysr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26785#pullrequestreview-3122663034 From sjohanss at openjdk.org Fri Aug 15 07:00:12 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Fri, 15 Aug 2025 07:00:12 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v5] In-Reply-To: References: Message-ID: <6XeFouUBD4PyYJbZ-YuwafTZIocx1tv8zYkrg_2y0BI=.d9a2dfd2-b005-4152-91ab-db4005cdb167@github.com> On Thu, 14 Aug 2025 13:07:07 GMT, Jonas Norlinder wrote: >>> ... it might happen from time to time without it being a very big deal? >> >> My concern is that we get a number on cpu-time without knowing the number is off by a large margin when failure occurs, so there should probably be some warning/msg somewhere. > > I don't sample GC threads that have terminated, so I would prefer not having the warning as well, as it would not fail unless the machine is in a bad state and then we would have larger issues at hand anyways? > My concern is that we get a number on cpu-time without knowing the number is off by a large margin when failure occurs, so there should probably be some warning/msg somewhere. Sure, that could be helpful. I don't think it should be a warning on the OS API though. Looking at the code a log message like that could be added to `CPUTimeThreadClosure::do_thread(...)`. To me it would be enough to have that on `log_info(cpu)` possibly even on debug-level. What do you think? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2278420082 From ayang at openjdk.org Fri Aug 15 08:08:13 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 15 Aug 2025 08:08:13 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v5] In-Reply-To: <6XeFouUBD4PyYJbZ-YuwafTZIocx1tv8zYkrg_2y0BI=.d9a2dfd2-b005-4152-91ab-db4005cdb167@github.com> References: <6XeFouUBD4PyYJbZ-YuwafTZIocx1tv8zYkrg_2y0BI=.d9a2dfd2-b005-4152-91ab-db4005cdb167@github.com> Message-ID: On Fri, 15 Aug 2025 06:57:04 GMT, Stefan Johansson wrote: > I don't think it should be a warning on the OS API though. Agree. At this level, returning `-1` already indicates the error -- callers should/can check the return-value and act on it. > ... could be added to CPUTimeThreadClosure::do_thread(...) There are dozens of callers though; `CPUTimeThreadClosure` is just one. For this particular patch, I think emitting some msg/warning somewhere inside `static void log_cpu_time` may be enough. WDYT? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2278499043 From shade at openjdk.org Fri Aug 15 08:11:10 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 15 Aug 2025 08:11:10 GMT Subject: RFR: 8365571: GenShen: PLAB promotions may remain disabled for evacuation threads In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 18:15:00 GMT, William Kemper wrote: > Mutators and GC workers have old generation LABs for promotions and old generation evacuations. Priority is given to old evacuations by using a promotion budget. Once the promotion budget is exhausted, a thread local flag is set to disable further promotions (the LAB can still be used for old evacuations). This thread local flag is meant to be cleared to allow all threads to resume promotions on the next cycle. However, this flag is only reset for workers that perform thread root evacuations, which may not be the same workers that perform subsequent evacuations. This patch clears the flag for all threads when their LABs are retired at the end of evacuation. Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26785#pullrequestreview-3123211456 From sjohanss at openjdk.org Fri Aug 15 08:27:12 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Fri, 15 Aug 2025 08:27:12 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v5] In-Reply-To: References: <6XeFouUBD4PyYJbZ-YuwafTZIocx1tv8zYkrg_2y0BI=.d9a2dfd2-b005-4152-91ab-db4005cdb167@github.com> Message-ID: <9BTb_r1e6tX82FC9MEZQi9XW3BpFQFkSBwGwYlYS-GE=.26214213-1f74-467c-b67d-103e2e1fcbae@github.com> On Fri, 15 Aug 2025 08:05:06 GMT, Albert Mingkun Yang wrote: >>> My concern is that we get a number on cpu-time without knowing the number is off by a large margin when failure occurs, so there should probably be some warning/msg somewhere. >> >> Sure, that could be helpful. I don't think it should be a warning on the OS API though. Looking at the code a log message like that could be added to `CPUTimeThreadClosure::do_thread(...)`. To me it would be enough to have that on `log_info(cpu)` possibly even on debug-level. What do you think? > >> I don't think it should be a warning on the OS API though. > > Agree. At this level, returning `-1` already indicates the error -- callers should/can check the return-value and act on it. > >> ... could be added to CPUTimeThreadClosure::do_thread(...) > > There are dozens of callers though; `CPUTimeThreadClosure` is just one. For this particular patch, I think emitting some msg/warning somewhere inside `static void log_cpu_time` may be enough. WDYT? I don't have super strong opinion here, but to be able to add some message in `log_cpu_time` we would need to add logic to the `CPUTimeThreadClosure` to know if something went wrong or am I missing what you are suggesting? And that message would not know what thread we failed to measure, but the closure have that information. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2278524140 From ayang at openjdk.org Fri Aug 15 08:45:12 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 15 Aug 2025 08:45:12 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v5] In-Reply-To: <9BTb_r1e6tX82FC9MEZQi9XW3BpFQFkSBwGwYlYS-GE=.26214213-1f74-467c-b67d-103e2e1fcbae@github.com> References: <6XeFouUBD4PyYJbZ-YuwafTZIocx1tv8zYkrg_2y0BI=.d9a2dfd2-b005-4152-91ab-db4005cdb167@github.com> <9BTb_r1e6tX82FC9MEZQi9XW3BpFQFkSBwGwYlYS-GE=.26214213-1f74-467c-b67d-103e2e1fcbae@github.com> Message-ID: On Fri, 15 Aug 2025 08:24:38 GMT, Stefan Johansson wrote: > ... am I missing what you are suggesting? No. I think we are on the same page; I was more focusing on where the msg/warning will be, since this thread started with "Do we really want add a warning here?" > And that message would not know what thread we failed to measure, but the closure have that information. True; need to collect these info so that the printed msg/warning shows which thread(s) encountered a failure, if any. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2278547920 From ayang at openjdk.org Fri Aug 15 10:14:08 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 15 Aug 2025 10:14:08 GMT Subject: RFR: 8346005: Parallel: Incorrect page size calculation with UseLargePages [v2] 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 two additional commits since the last revision: - 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/0a67ca44..5df3735a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26700&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26700&range=00-01 Stats: 10715 lines in 306 files changed: 4992 ins; 4431 del; 1292 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 Fri Aug 15 12:59:10 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 15 Aug 2025 12:59:10 GMT Subject: RFR: 8364934: G1: Rename members of G1CollectionSet [v3] In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 16:15:34 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this renaming of various members of `G1CollectionSet` to >> >> - use the same prefixes for the regions ("_regions") and candidate groups ("_groups") consistently, avoiding adding prefixes here and there for no discernible reason >> - remove unnecessary prefixes (`collection_set`) - everything is part of the collection set >> - fix/improve some documentation >> >> Testing: gha >> >> Thanks, >> THoams > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * one more renaming: prepare_groups_for_scan() -> prepare_for_scan() Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26670#pullrequestreview-3123792918 From ayang at openjdk.org Fri Aug 15 13:06:12 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 15 Aug 2025 13:06:12 GMT Subject: RFR: 8365034: G1: Remove num_groups_selected in G1CollectionSet::select_candidates_from_optional_groups as it is unnecessary In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 10:33:59 GMT, Thomas Schatzl wrote: > Hi all, > > please review this removal of the local `num_selected_regions` from `G1CollectionSet::select_candidates_from_optional_groups()` - the same information is maintained within the local `selected_groups` list. > > Testing: gha > > Thanks, > Thomas src/hotspot/share/gc/g1/g1CollectionSet.cpp line 501: > 499: uint num_initial_regions = 0; > 500: uint prev_num_optional_regions = _optional_groups.num_regions(); > 501: guarantee(prev_num_optional_regions == 0, "must be, why else?"); Why so? Can't there be any optional regions when populating cset from marking? Also, seems not very related to this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26674#discussion_r2278954081 From wkemper at openjdk.org Fri Aug 15 17:57:10 2025 From: wkemper at openjdk.org (William Kemper) Date: Fri, 15 Aug 2025 17:57:10 GMT Subject: RFR: 8365571: GenShen: PLAB promotions may remain disabled for evacuation threads In-Reply-To: References: Message-ID: On Fri, 15 Aug 2025 02:37:57 GMT, Y. Srinivas Ramakrishna wrote: >> Mutators and GC workers have old generation LABs for promotions and old generation evacuations. Priority is given to old evacuations by using a promotion budget. Once the promotion budget is exhausted, a thread local flag is set to disable further promotions (the LAB can still be used for old evacuations). This thread local flag is meant to be cleared to allow all threads to resume promotions on the next cycle. However, this flag is only reset for workers that perform thread root evacuations, which may not be the same workers that perform subsequent evacuations. This patch clears the flag for all threads when their LABs are retired at the end of evacuation. > > Marked as reviewed by ysr (Reviewer). @ysramakrishna - the performance test results show no regressions. The level of detail we need to see the effect of the changes isn't enabled by default in the release testing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26785#issuecomment-3192309751 From wkemper at openjdk.org Fri Aug 15 18:00:17 2025 From: wkemper at openjdk.org (William Kemper) Date: Fri, 15 Aug 2025 18:00:17 GMT Subject: Integrated: 8365571: GenShen: PLAB promotions may remain disabled for evacuation threads In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 18:15:00 GMT, William Kemper wrote: > Mutators and GC workers have old generation LABs for promotions and old generation evacuations. Priority is given to old evacuations by using a promotion budget. Once the promotion budget is exhausted, a thread local flag is set to disable further promotions (the LAB can still be used for old evacuations). This thread local flag is meant to be cleared to allow all threads to resume promotions on the next cycle. However, this flag is only reset for workers that perform thread root evacuations, which may not be the same workers that perform subsequent evacuations. This patch clears the flag for all threads when their LABs are retired at the end of evacuation. This pull request has now been integrated. Changeset: 08db4b99 Author: William Kemper URL: https://git.openjdk.org/jdk/commit/08db4b99622e488558dd7987c34f1c515fa30426 Stats: 24 lines in 2 files changed: 5 ins; 15 del; 4 mod 8365571: GenShen: PLAB promotions may remain disabled for evacuation threads Reviewed-by: kdnilsen, ysr, shade ------------- PR: https://git.openjdk.org/jdk/pull/26785 From wkemper at openjdk.org Fri Aug 15 19:16:19 2025 From: wkemper at openjdk.org (William Kemper) Date: Fri, 15 Aug 2025 19:16:19 GMT Subject: RFR: 8365622: Shenandoah: Fix Shenandoah simple bit map test Message-ID: Simple fix. Test passes. ------------- Commit messages: - Use right macro too - Use correct class name for test fixture Changes: https://git.openjdk.org/jdk/pull/26805/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26805&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365622 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26805.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26805/head:pull/26805 PR: https://git.openjdk.org/jdk/pull/26805 From ysr at openjdk.org Fri Aug 15 19:48:10 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Fri, 15 Aug 2025 19:48:10 GMT Subject: RFR: 8365622: Shenandoah: Fix Shenandoah simple bit map test In-Reply-To: References: Message-ID: On Fri, 15 Aug 2025 19:09:36 GMT, William Kemper wrote: > Simple fix. Test passes. Marked as reviewed by ysr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26805#pullrequestreview-3124949032 From wkemper at openjdk.org Fri Aug 15 20:03:19 2025 From: wkemper at openjdk.org (William Kemper) Date: Fri, 15 Aug 2025 20:03:19 GMT Subject: Integrated: 8365622: Shenandoah: Fix Shenandoah simple bit map test In-Reply-To: References: Message-ID: On Fri, 15 Aug 2025 19:09:36 GMT, William Kemper wrote: > Simple fix. Test passes. This pull request has now been integrated. Changeset: 6e760b9b Author: William Kemper URL: https://git.openjdk.org/jdk/commit/6e760b9b746eba3d40ec246f3e194ce9f8c5ae29 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8365622: Shenandoah: Fix Shenandoah simple bit map test Reviewed-by: ysr ------------- PR: https://git.openjdk.org/jdk/pull/26805 From iwalulya at openjdk.org Mon Aug 18 07:05:13 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 18 Aug 2025 07:05:13 GMT Subject: RFR: 8364414: G1: Use simpler data structure for holding collection set candidates during calculation [v2] In-Reply-To: <1yNuabPYEkaNRSCQnDveI6hVfxoRrNT-3oFTj77Enn0=.062061ec-5ef7-44d6-87c5-caff8c3d034f@github.com> References: <1yNuabPYEkaNRSCQnDveI6hVfxoRrNT-3oFTj77Enn0=.062061ec-5ef7-44d6-87c5-caff8c3d034f@github.com> Message-ID: <2dfZBQ0FQPMHjXan6hv1Ag1lXJz1JRGBX3M8UqjiRcY=.9bc84f4b-b57a-4518-b6f3-cd28156d07bc@github.com> On Thu, 31 Jul 2025 13:35:20 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this refactoring of the collection set choosing mechanism to use a lighter data structure: instead of an array of `G1CollectionSetCandidateInfo`s, use an array of `G1HeapRegion*` - we do not use the additional information provided by `G1CollectionSetCandidateInfo` at all during that process, and we copy the contents later anyway. >> >> This reduces code complexity a bit (no need to extract the `G1HeapRegion*` from the struct) and reduces memory consumption a little as well. >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * fix sort function Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26572#pullrequestreview-3127027954 From iwalulya at openjdk.org Mon Aug 18 07:09:15 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 18 Aug 2025 07:09:15 GMT Subject: RFR: 8364532: G1: In liveness tracing, print more significant digits for the liveness value [v4] In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 09:35:27 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this small change that adds some more significant digits (3 in total) for the "liveness" column in collection set group logging. >> >> E.g. see the emphasized columns that lack precision (it's more irritating with lots of lines showing single-digit values): >> >> 50.707s][trace][gc,liveness] GC(13) ### groud-id num-regions gc-eff liveness remset type >> 50.707s][trace][gc,liveness] GC(13) ### (bytes/ms) % (bytes) >> 50.707s][trace][gc,liveness] GC(13) ### 1 70 0.0 *100* 3199208 Y >> 50.707s][trace][gc,liveness] GC(13) ### 2 51 5298129.5 *18* 1224072 M >> 50.707s][trace][gc,liveness] GC(13) ### 3 5 3223983.6 *31* 176648 M >> 50.707s][trace][gc,liveness] GC(13) ### 4 5 3022016.3 *32* 176648 M >> >> >> (This depends on PR#26591, so please look at that one first). >> >> The change makes sure that three significant digits are printed. >> >> Testing: manual review >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * ayang suggestion to avoid exponential output Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26595#pullrequestreview-3127040554 From iwalulya at openjdk.org Mon Aug 18 07:11:13 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 18 Aug 2025 07:11:13 GMT Subject: RFR: 8364650: G1: Use InvalidCSetIndex instead of UINT_MAX for "invalid" sentinel value of young_index_in_cset In-Reply-To: References: Message-ID: <7bSgIAWQvxD0VIIQwqQDCs-06xVAO4JAizvBk0tNcRQ=.ad8edc3a-0b31-40ab-af6a-479a1c75cdde@github.com> On Tue, 5 Aug 2025 21:56:43 GMT, Thomas Schatzl wrote: > Hi all, > > please review this small change to use `InvalidCSetIndex` instead of hardcoded `UINT_MAX` for `G1HeapRegion::_young_index_in_cset`. Just reuse the existing value that is already in use for `_index_in_opt_cset`. > > Testing: compilation, gha > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26651#pullrequestreview-3127044740 From iwalulya at openjdk.org Mon Aug 18 07:18:12 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 18 Aug 2025 07:18:12 GMT Subject: RFR: 8364925: G1: Improve program flow around incremental collection set building [v2] In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 15:15:08 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that improves the G1CollectionSet incremental state handling slightly: >> >> * remove `_selected_groups_cur_length` with getter as we do not need a copy of that value around >> * move implementations of some methods from header files into cpp file >> * moved some incremental state updates from `finalize_old_part` to the respective `start/continue/stop_incremental_building` method >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * ayang review Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26659#pullrequestreview-3127068693 From iwalulya at openjdk.org Mon Aug 18 07:26:10 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 18 Aug 2025 07:26:10 GMT Subject: RFR: 8365040: G1: Remove sorting at end of collection set selection In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 12:10:49 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to remove some unnecessary sorting of the collection set introduced in https://bugs.openjdk.org/browse/JDK-8165313, and made unnecessary in https://bugs.openjdk.org/browse/JDK-8165443 (all JDK 9 :)). > > Testing: test case in CRs, see CR for test results, gha > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26676#pullrequestreview-3127102407 From iwalulya at openjdk.org Mon Aug 18 08:53:14 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 18 Aug 2025 08:53:14 GMT Subject: RFR: 8365055: G1: Merge Heap Roots phase incorrectly clears young gen remembered set every time [v2] In-Reply-To: References: <8JFuOjov4pzLsgan8_D26HNVtWFNTBm7OzuMMwRVUAM=.f557c3d1-ccef-4ea2-ad9c-0c4a217f24b4@github.com> Message-ID: On Fri, 8 Aug 2025 14:12:31 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this fix to G1 heap root merging that cleared the young gen remembered set multiple times (for every merging) and overwriting the most recent statistics for the number of young gen cards. >> >> The latter is probably the more problematic, as it directly impacts young gen sizing statistics, potentially making young gen too large. >> >> The fix is to move the two statements to the proper place - get current number of young gen cards at startup, clear the young gen remset when starting a new collection set - we do not need to do that earlier after all. Additionally we can add some (superfluous?) verification that during GC we really do not add to the young gen remset. >> >> Testing: tier1-5 >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * fix comment in verification code > * move that G1Policy member to G1CollectedHeap as it's used to verify stuff in G1CollectedHeap (and not used elsewhere anyway) Changes requested by iwalulya (Reviewer). src/hotspot/share/gc/g1/g1Policy.cpp line 933: > 931: > 932: _analytics->report_pending_cards((double)pending_cards_at_gc_start(), is_young_only_pause); > 933: _analytics->report_card_rs_length((double)_g1h->young_regions_cardset()->occupied(), is_young_only_pause); At this point in the execution, the `_g1h->young_regions_cardset()->clear()` has already been called, so this will be `0`. `post_evacuate_collection_set()` calls `prepare_for_mutator_after_young_collection()` which calls `start_new_collection_set()`, but `post_evacuate_collection_set()` is called before `policy()->record_young_collection_end()` Probably `_num_young_rem_set_cards_at_start` was added to `G1Policy` to assert on this, but it is not used. src/hotspot/share/gc/g1/g1RemSet.cpp line 1443: > 1441: } > 1442: > 1443: { guarding this block with `if (initial_evacuation)` might be an easier alternative. ------------- PR Review: https://git.openjdk.org/jdk/pull/26695#pullrequestreview-3127345332 PR Review Comment: https://git.openjdk.org/jdk/pull/26695#discussion_r2281680822 PR Review Comment: https://git.openjdk.org/jdk/pull/26695#discussion_r2281682289 From iwalulya at openjdk.org Mon Aug 18 09:29:13 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 18 Aug 2025 09:29:13 GMT Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing [v3] In-Reply-To: References: Message-ID: On Thu, 17 Jul 2025 13:16:29 GMT, Ivan Walulya wrote: >> Hi, >> >> Please review this patch which takes into account the impact of concurrent GC activity on mutator threads when computing the time spent on GC activity in a time interval. Previously, only the GC pause times were considered, and the overhead imposed by concurrent GC worker threads was not included. >> >> With this change, we now estimate the impact of concurrent GC by dividing `elapsed_gc_cpu_time` by the number of CPUs. This provides an approximation of the additional time attributable to GC activity, assuming a fair CPU resource sharing. Although this method does not account for contention on other shared resources (such as memory bandwidth or caches), it offers a reasonable estimate for most scenarios. >> >> Testing: Tier 1 > > Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: > > - cleanup after merge > - Merge remote-tracking branch 'upstream/master' into ConcCPUImpact > - Merge branch 'NormalizeTiming' into ConcCPUImpact > - Thomas suggestion > - Thomas Review > - reorder > - concurrent gc impact > - clean out > - init > Looking a bit into the code, I think this is somewhat of a pre-existing issue. We always calculate short term pause time ratio based off the last GC pause regardless of type, i.e. in this case from Cleanup to the next Young. I am kind of doubting that this is correct right now. Yes, I figured that the alternative (considering the current work) would be incorrect as we are not at the end of the pause. Depending on the results of the computations, we may have to commit regions, thus the time from this point in the execution to the end of the pause is not insignificant. Suggestions are welcome on how we handle this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26351#issuecomment-3195866258 From iwalulya at openjdk.org Mon Aug 18 09:29:14 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 18 Aug 2025 09:29:14 GMT Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing [v3] In-Reply-To: <-QXCeqQ5G9fnCuyVw53P2VVGQSEusP7uK26xOyDN9DM=.4eb62bae-0977-4f74-9f0c-d964d6396c91@github.com> References: <8FCHTMjSXHFLs5Q8jw9gLgWS-t1jCpRsSPKhR5LCUBE=.d845e003-ba02-47b9-afe2-45309f9adbae@github.com> <_yJlsycZBpjl9wwfv7sUn9Ar19akN4CKPg7i50jF1ws=.7b8ead31-ee56-42f8-b230-2fb97d1f35a4@github.com> <-QXCeqQ5G9fnCuyVw53P2VVGQSEusP7uK26 xOyDN9DM=.4eb62bae-0977-4f74-9f0c-d964d6396c91@github.com> Message-ID: On Wed, 6 Aug 2025 21:12:52 GMT, Man Cao wrote: >>> Which is very similar to the current approach to divide concurrent-cpu-usage by some arbitrary threading factor, without needing to know that factor, and incurring inaccuracies because of that. >> >> Effectively it divides that concurrent-cpu-usage by the number of active processors if I am not mistaken :) > > The `#active-processors * time-since-last-pause` approach sounds worth experimenting. > > One potential concern is the heap sizing behavior could be more heavily affected by #active-processors, which could be surprising comparing to G1's current behavior. Admittedly, G1's current heap sizing behavior could already be affected by #active-processors (mainly via default values for ParallelGCThreads/ConcGCThreads), but it is likely to a much lesser extent. > > If a prototype of this approach exists, we should probably test how much difference in heap sizing there is for an application running with a low value of `ActiveProcessorCount` vs a high value. My main worry is that `#active-processors * time-since-last-pause` could inflate the divisor too much if `#active-processors` is very high (e.g. >100), which could make the heap much smaller, which is quite counter-intuitive. So iiuc, we have narrowed down to Suggestion: ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26351#discussion_r2281829373 From ayang at openjdk.org Mon Aug 18 11:28:10 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 18 Aug 2025 11:28:10 GMT Subject: RFR: 8365040: G1: Remove sorting at end of collection set selection In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 12:10:49 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to remove some unnecessary sorting of the collection set introduced in https://bugs.openjdk.org/browse/JDK-8165313, and made unnecessary in https://bugs.openjdk.org/browse/JDK-8165443 (all JDK 9 :)). > > Testing: test case in CRs, see CR for test results, gha > > Thanks, > Thomas Doesn't `_cleanup_list.add_ordered(&local_cleanup_list);` in `G1UpdateRegionLivenessAndSelectForRebuildTask` require those regions to be sorted? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26676#issuecomment-3196255028 From ayang at openjdk.org Mon Aug 18 12:50:10 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 18 Aug 2025 12:50:10 GMT Subject: RFR: 8365040: G1: Remove sorting at end of collection set selection In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 12:10:49 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to remove some unnecessary sorting of the collection set introduced in https://bugs.openjdk.org/browse/JDK-8165313, and made unnecessary in https://bugs.openjdk.org/browse/JDK-8165443 (all JDK 9 :)). > > Testing: test case in CRs, see CR for test results, gha > > Thanks, > Thomas ~Doesn't _cleanup_list.add_ordered(&local_cleanup_list); in G1UpdateRegionLivenessAndSelectForRebuildTask require those regions to be sorted?~ Never mind; I misunderstood the logics. ------------- Marked as reviewed by ayang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26676#pullrequestreview-3128234597 From duke at openjdk.org Mon Aug 18 13:40:21 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 18 Aug 2025 13:40:21 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v7] In-Reply-To: References: Message-ID: > Hi all, > > This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). > > As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: > > CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() > > CPUTimeUsage::GC::gc_threads() > CPUTimeUsage::GC::vm_thread() > CPUTimeUsage::GC::stringdedup() > > CPUTimeUsage::Runtime::vm_thread() > > > I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. > > I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: > > > [71.425s][info][cpu ] === CPU time Statistics ============================================================= > [71.425s][info][cpu ] CPUs > [71.425s][info][cpu ] s % utilized > [71.425s][info][cpu ] Process > [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 > [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 > [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 > [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 > [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 > [71.425s][info][cpu ] ===================================================================================== > > > Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Implement optional error handling ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26621/files - new: https://git.openjdk.org/jdk/pull/26621/files/ddab1f0b..8fe49703 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=05-06 Stats: 38 lines in 6 files changed: 29 ins; 8 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621 PR: https://git.openjdk.org/jdk/pull/26621 From duke at openjdk.org Mon Aug 18 13:40:22 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 18 Aug 2025 13:40:22 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v6] In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 14:12:18 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). >> >> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: >> >> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() >> >> CPUTimeUsage::GC::gc_threads() >> CPUTimeUsage::GC::vm_thread() >> CPUTimeUsage::GC::stringdedup() >> >> CPUTimeUsage::Runtime::vm_thread() >> >> >> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. >> >> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: >> >> >> [71.425s][info][cpu ] === CPU time Statistics ============================================================= >> [71.425s][info][cpu ] CPUs >> [71.425s][info][cpu ] s % utilized >> [71.425s][info][cpu ] Process >> [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 >> [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 >> [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 >> [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 >> [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 >> [71.425s][info][cpu ] ===================================================================================== >> >> >> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. > > Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision: > > - Minor improvements and fixes per @kstefanj suggestions > - use percent_of from globalDefinitions.hpp As per our offline discussion I implemented an optional error handling mechanism to allow users of this framework decide if they care or not. If errors are found we print something like this in the end: [0.569s][info][cpu] === CPU time Statistics ============================================================= [0.569s][info][cpu] WARNING: CPU time sampling reported errors, numbers may be unreliable [0.569s][info][cpu] CPUs [0.569s][info][cpu] s % utilized [0.569s][info][cpu] Process [0.569s][info][cpu] Total 2.2719 100.00 4.0 [0.569s][info][cpu] VM Thread 0.0031 0.14 0.0 [0.569s][info][cpu] Garbage Collection 0.0146 0.64 0.0 [0.569s][info][cpu] GC Threads 0.0141 0.62 0.0 [0.569s][info][cpu] VM Thread 0.0006 0.03 0.0 [0.569s][info][cpu] ===================================================================================== ------------- PR Comment: https://git.openjdk.org/jdk/pull/26621#issuecomment-3196939663 From duke at openjdk.org Mon Aug 18 13:56:03 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 18 Aug 2025 13:56:03 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v8] In-Reply-To: References: Message-ID: > Hi all, > > This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). > > As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: > > CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() > > CPUTimeUsage::GC::gc_threads() > CPUTimeUsage::GC::vm_thread() > CPUTimeUsage::GC::stringdedup() > > CPUTimeUsage::Runtime::vm_thread() > > > I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. > > I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: > > > [71.425s][info][cpu ] === CPU time Statistics ============================================================= > [71.425s][info][cpu ] CPUs > [71.425s][info][cpu ] s % utilized > [71.425s][info][cpu ] Process > [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 > [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 > [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 > [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 > [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 > [71.425s][info][cpu ] ===================================================================================== > > > Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision: - Minor - Minor ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26621/files - new: https://git.openjdk.org/jdk/pull/26621/files/8fe49703..9aa28717 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=06-07 Stats: 7 lines in 2 files changed: 0 ins; 4 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621 PR: https://git.openjdk.org/jdk/pull/26621 From duke at openjdk.org Mon Aug 18 14:02:48 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 18 Aug 2025 14:02:48 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v9] In-Reply-To: References: Message-ID: <5EyWJEFaUKY6HFqth8UA_Xbxl02RXXHFzS_DpokTSVc=.d497ffaa-7995-4079-8524-f36d2d15f7e9@github.com> > Hi all, > > This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). > > As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: > > CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() > > CPUTimeUsage::GC::gc_threads() > CPUTimeUsage::GC::vm_thread() > CPUTimeUsage::GC::stringdedup() > > CPUTimeUsage::Runtime::vm_thread() > > > I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. > > I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: > > > [71.425s][info][cpu ] === CPU time Statistics ============================================================= > [71.425s][info][cpu ] CPUs > [71.425s][info][cpu ] s % utilized > [71.425s][info][cpu ] Process > [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 > [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 > [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 > [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 > [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 > [71.425s][info][cpu ] ===================================================================================== > > > Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Fix indentation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26621/files - new: https://git.openjdk.org/jdk/pull/26621/files/9aa28717..afbff568 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=07-08 Stats: 36 lines in 2 files changed: 2 ins; 1 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/26621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621 PR: https://git.openjdk.org/jdk/pull/26621 From shade at openjdk.org Mon Aug 18 18:49:28 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 18 Aug 2025 18:49:28 GMT Subject: RFR: 8231269: CompileTask::is_unloaded is slow due to JNIHandles type checks [v23] In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 13:02:07 GMT, Aleksey Shipilev wrote: >> [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 incrementally with six additional commits since the last revision: > > - Docs touchup > - Use enum class > - Further simplify the API > - Tune up for release builds > - Move release() to destructor > - Deal with things without spinlocks Currently distracted by higher-priority stuff. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24018#issuecomment-3183715140 From sjohanss at openjdk.org Tue Aug 19 08:19:42 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Tue, 19 Aug 2025 08:19:42 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v9] In-Reply-To: <5EyWJEFaUKY6HFqth8UA_Xbxl02RXXHFzS_DpokTSVc=.d497ffaa-7995-4079-8524-f36d2d15f7e9@github.com> References: <5EyWJEFaUKY6HFqth8UA_Xbxl02RXXHFzS_DpokTSVc=.d497ffaa-7995-4079-8524-f36d2d15f7e9@github.com> Message-ID: On Mon, 18 Aug 2025 14:02:48 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). >> >> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: >> >> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() >> >> CPUTimeUsage::GC::gc_threads() >> CPUTimeUsage::GC::vm_thread() >> CPUTimeUsage::GC::stringdedup() >> >> CPUTimeUsage::Runtime::vm_thread() >> >> >> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. >> >> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: >> >> >> [71.425s][info][cpu ] === CPU time Statistics ============================================================= >> [71.425s][info][cpu ] CPUs >> [71.425s][info][cpu ] s % utilized >> [71.425s][info][cpu ] Process >> [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 >> [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 >> [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 >> [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 >> [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 >> [71.425s][info][cpu ] ===================================================================================== >> >> >> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Fix indentation Just some minor things that you can fix before integrating. Otherwise I think this looks good. src/hotspot/share/gc/shared/collectedHeap.cpp line 59: > 57: #include "runtime/threadSMR.hpp" > 58: #include "runtime/vmThread.hpp" > 59: #include "services/cpuTimeUsage.hpp" Can be removed now. src/hotspot/share/gc/shared/collectedHeap.hpp line 434: > 432: void print_relative_to_gc(GCWhen::Type when) const; > 433: > 434: void log_cpu_time() const; This has moved to `Universe` and can be removed. ------------- Marked as reviewed by sjohanss (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26621#pullrequestreview-3131175838 PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2284454451 PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2284450710 From duke at openjdk.org Tue Aug 19 08:42:15 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Tue, 19 Aug 2025 08:42:15 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v10] In-Reply-To: References: Message-ID: > Hi all, > > This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). > > As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: > > CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() > > CPUTimeUsage::GC::gc_threads() > CPUTimeUsage::GC::vm_thread() > CPUTimeUsage::GC::stringdedup() > > CPUTimeUsage::Runtime::vm_thread() > > > I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. > > I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: > > > [71.425s][info][cpu ] === CPU time Statistics ============================================================= > [71.425s][info][cpu ] CPUs > [71.425s][info][cpu ] s % utilized > [71.425s][info][cpu ] Process > [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 > [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 > [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 > [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 > [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 > [71.425s][info][cpu ] ===================================================================================== > > > Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Remove unused ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26621/files - new: https://git.openjdk.org/jdk/pull/26621/files/afbff568..79a3323a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=08-09 Stats: 3 lines in 2 files changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621 PR: https://git.openjdk.org/jdk/pull/26621 From iwalulya at openjdk.org Tue Aug 19 10:59:10 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 19 Aug 2025 10:59:10 GMT Subject: RFR: 8365780: G1: Remset for young regions are cleared too early during Full GC Message-ID: Hi, Please review this patch to move clearing of the young region remsets to later in the Full GC. G1HeapVerifier specifically G1FullCollector::verify_after_marking still assumes that the remsets for young regions are still valid and with status complete. Clearing these remsets too early triggers the verification failure. Testing: - Tiers 1-3 ------------- Commit messages: - can be later - space - reset remset clearing Changes: https://git.openjdk.org/jdk/pull/26839/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26839&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365780 Stats: 7 lines in 2 files changed: 5 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26839.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26839/head:pull/26839 PR: https://git.openjdk.org/jdk/pull/26839 From sjohanss at openjdk.org Tue Aug 19 11:24:37 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Tue, 19 Aug 2025 11:24:37 GMT Subject: RFR: 8365780: G1: Remset for young regions are cleared too early during Full GC In-Reply-To: References: Message-ID: <4s0GGi-Vm231UpwmpBpQs80fMRteWUiS0KRjlrVT4Xs=.35fd6864-922a-4b4c-90ed-7a22f200bd17@github.com> On Tue, 19 Aug 2025 09:24:06 GMT, Ivan Walulya wrote: > Hi, > Please review this patch to move clearing of the young region remsets to later in the Full GC. G1HeapVerifier specifically G1FullCollector::verify_after_marking still assumes that the remsets for young regions are still valid and with status complete. Clearing these remsets too early triggers the verification failure. > > Testing: - Tiers 1-3 Looks good. ------------- Marked as reviewed by sjohanss (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26839#pullrequestreview-3131877071 From ayang at openjdk.org Tue Aug 19 11:35:39 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 19 Aug 2025 11:35:39 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v10] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 08:42:15 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). >> >> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: >> >> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() >> >> CPUTimeUsage::GC::gc_threads() >> CPUTimeUsage::GC::vm_thread() >> CPUTimeUsage::GC::stringdedup() >> >> CPUTimeUsage::Runtime::vm_thread() >> >> >> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. >> >> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: >> >> >> [71.425s][info][cpu ] === CPU time Statistics ============================================================= >> [71.425s][info][cpu ] CPUs >> [71.425s][info][cpu ] s % utilized >> [71.425s][info][cpu ] Process >> [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 >> [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 >> [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 >> [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 >> [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 >> [71.425s][info][cpu ] ===================================================================================== >> >> >> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused src/hotspot/share/gc/shared/collectedHeap.cpp line 625: > 623: ClassLoaderDataGraph::print_on(&ls_trace); > 624: } > 625: } I don't think this code movement should be done -- this calls back to `Universe` and CLDG printing is not necessarily tired to heap. src/hotspot/share/services/cpuTimeUsage.cpp line 43: > 41: public: > 42: virtual void do_thread(Thread* thread) { > 43: jlong cpu_time = os::thread_cpu_time(thread); I guess a wrapper for `thread_cpu_time` can be created to group error-handling logic together, for all uses in this file. jlong thread_cpu_time_or_zero(thread) { jlong cpu_time = os::.. if (cpu_time == -1) { // mark-error return 0; } return cpu_time; } src/hotspot/share/services/cpuTimeUsage.hpp line 47: > 45: static jlong gc_threads(); > 46: static jlong vm_thread(); > 47: static jlong stringdedup(); I feel the API surface contains some redundancy. For example, the GC-part API design exposes two ways to query and they are essentially the same -- for the sake of simplicity, I'd suggest keeping only one. The calculation of `total` should be done by users of this API, I believe, when/if total is desirable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2284933253 PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2284962585 PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2284952784 From iwalulya at openjdk.org Tue Aug 19 12:43:46 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 19 Aug 2025 12:43:46 GMT Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing [v4] In-Reply-To: References: Message-ID: > Hi, > > Please review this patch which takes into account the impact of concurrent GC activity on mutator threads when computing the time spent on GC activity in a time interval. Previously, only the GC pause times were considered, and the overhead imposed by concurrent GC worker threads was not included. > > With this change, we now estimate the impact of concurrent GC by dividing `elapsed_gc_cpu_time` by the number of CPUs. This provides an approximation of the additional time attributable to GC activity, assuming a fair CPU resource sharing. Although this method does not account for contention on other shared resources (such as memory bandwidth or caches), it offers a reasonable estimate for most scenarios. > > Testing: Tier 1 Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge remote-tracking branch 'upstream/master' into ConcCPUImpact - accumlate concurrent_gc_impact_time - Merge remote-tracking branch 'upstream/master' into ConcCPUImpact - cleanup after merge - Merge remote-tracking branch 'upstream/master' into ConcCPUImpact - Merge branch 'NormalizeTiming' into ConcCPUImpact - Thomas suggestion - Thomas Review - reorder - concurrent gc impact - ... and 2 more: https://git.openjdk.org/jdk/compare/999761d0...c65429ad ------------- Changes: https://git.openjdk.org/jdk/pull/26351/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26351&range=03 Stats: 67 lines in 5 files changed: 41 ins; 1 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/26351.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26351/head:pull/26351 PR: https://git.openjdk.org/jdk/pull/26351 From iwalulya at openjdk.org Tue Aug 19 12:57:40 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 19 Aug 2025 12:57:40 GMT Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing [v3] In-Reply-To: References: Message-ID: On Mon, 28 Jul 2025 10:17:46 GMT, Thomas Schatzl wrote: >> The assumption here is the `update_gc_pause_time_ratios` is called at the end of all GCs. The only issue I notice is that we don't call it in case of allocation_failures, which is problematic. But probably I don't understand the issue you are highlighting. > > Actually I think there are two issues, let me copy from `G1Analytics::compute_pause_time_ratios`: > > > void G1Analytics::compute_pause_time_ratios(double end_time_sec, double pause_time_ms) { > [...] > double short_interval_ms = (end_time_sec - most_recent_gc_end_time_sec()) * 1000.0; > > // This estimates the wall-clock time "lost" by application mutator threads due to concurrent GC > // activity. We do not account for contention on other shared resources such as memory bandwidth and > // caches, therefore underestimate the impact of the concurrent GC activity on mutator threads. > uint num_cpus = (uint)os::active_processor_count(); > num_cpus = MIN2(num_cpus, ConcGCThreads); > double concurrent_gc_impact_time = _concurrent_gc_cpu_time_ms / num_cpus; > > _short_term_pause_time_ratio = (pause_time_ms + concurrent_gc_impact_time) / short_interval_ms; > _short_term_pause_time_ratio = clamp(_short_term_pause_time_ratio, 0.0, 1.0); > } > > * the `short_term_pause_time_ratio` only takes the most recent `_concurrent_gc_cpu_time_ms` into account in this calculation. Between two Young GCs there may have been a complete concurrent cycle, which means that `_concurrent_gc_impact_time` only contains the concurrent work from the end of the Cleanup pause to the current Young GC. It does not seem to contain the concurrent work from the previous Young GC to the Cleanup pause, as `G1Policy::record_pause_start_time` _overwrites_ the last `G1Analytics::_concurrent_gc_cpu_time_ms`. > > Just giving an idea how much concurrent time is missing here, running BRT (obviously this is to highlight the issue), printing the measured concurrent CPU time in `G1Policy::record_pause_start_time`: > > [45.341s][info ][gc,start ] GC(11) Pause Young (Concurrent Start) (G1 Evacuation Pause) > [45.341s][debug][gc ] GC(11) conc cpu time: 8319.61 // This one is not really relevant here. > [...] > [48.821s][info ][gc,start ] GC(12) Pause Remark > [48.821s][debug][gc ] GC(12) conc cpu time: 11763.96 > [...] > [50.146s][info ][gc,start ] GC(12) Pause Cleanup > [50.146s][debug][gc ] GC(12) conc cpu time: 5830.75 > [...] > [54.987s][info ][gc,start ] GC(13) Pause Young (Prepare Mixed) (G1 Evacuation Pause) > [54.987s][debug][gc ] GC(13) conc cpu time: 2780.92 > > > So in that last Young GC pause, only around 14% of actual concurrent CPU time between the most recent two Young GCs is is used to calculate short term pause time ratio afaict. > > Looking a bit into the code, I thi... Fixed so that `long_term_pause_time_ratio` accumulation takes into account concurrent work ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26351#discussion_r2285167442 From ayang at openjdk.org Tue Aug 19 14:05:41 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 19 Aug 2025 14:05:41 GMT Subject: RFR: 8365780: G1: Remset for young regions are cleared too early during Full GC In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 09:24:06 GMT, Ivan Walulya wrote: > Hi, > Please review this patch to move clearing of the young region remsets to later in the Full GC. G1HeapVerifier specifically G1FullCollector::verify_after_marking still assumes that the remsets for young regions are still valid and with status complete. Clearing these remsets too early triggers the verification failure. > > Testing: - Tiers 1-3 It's a bit odd though that we perform checking on young-gen remset during a full-gc, considering that the concept of young-gen remset is not relevant during a full-gc context. ------------- Marked as reviewed by ayang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26839#pullrequestreview-3132502220 From iwalulya at openjdk.org Tue Aug 19 14:08:37 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 19 Aug 2025 14:08:37 GMT Subject: RFR: 8365780: G1: Remset for young regions are cleared too early during Full GC In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 14:03:12 GMT, Albert Mingkun Yang wrote: > It's a bit odd though that we perform checking on young-gen remset during a full-gc, considering that the concept of young-gen remset is not relevant during a full-gc context. Yes, we might have to revisit how the G1HeapVerifier handles these verifications during full-gc. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26839#issuecomment-3200913911 From duke at openjdk.org Tue Aug 19 14:30:48 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Tue, 19 Aug 2025 14:30:48 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v10] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 11:18:48 GMT, Albert Mingkun Yang wrote: >> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unused > > src/hotspot/share/gc/shared/collectedHeap.cpp line 625: > >> 623: ClassLoaderDataGraph::print_on(&ls_trace); >> 624: } >> 625: } > > I don't think this code movement should be done -- this calls back to `Universe` and CLDG printing is not necessarily tired to heap. The motivation to move into `CollectedHeap::before_exit` is that now we finally have a specific method that is called for GC activites during exit so there is no need to conflate java.cpp with these tasks. > this calls back to Universe It called back to Universe in java.cpp too. Maybe you would want `Universe::print_on` to be refactored into CollectedHeap too? If that's the case maybe we should save that for a separate issue. > CLDG printing is not necessarily tired to heap That could be so, but it is put under `gc+exit` tag. Are you suggesting that we should break this apart and do it under another tag? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2285459470 From duke at openjdk.org Tue Aug 19 14:48:43 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Tue, 19 Aug 2025 14:48:43 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v10] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 11:27:53 GMT, Albert Mingkun Yang wrote: >> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unused > > src/hotspot/share/services/cpuTimeUsage.hpp line 47: > >> 45: static jlong gc_threads(); >> 46: static jlong vm_thread(); >> 47: static jlong stringdedup(); > > I feel the API surface contains some redundancy. > > For example, the GC-part API design exposes two ways to query and they are essentially the same -- for the sake of simplicity, I'd suggest keeping only one. > > The calculation of `total` should be done by users of this API, I believe, when/if total is desirable. The motivation for `total()` is that this is probably what most users want, but in case anyone want a sub-component I also expose each one of them. It also serves as documentation as what we currently consider to be "total", so I would prefer keeping it. If you look at e.g. `WeakProcessor::CountingClosure` the following is defined size_t dead() const { return _old_dead + _new_dead; } size_t new_dead() const { return _new_dead; } size_t total() const { return dead() + _live; } so having such convenience method in hotspot is not unprecedented and I would prefer keeping it. `statistics()` is a less important convenience method that can be removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2285510749 From ayang at openjdk.org Tue Aug 19 15:03:42 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 19 Aug 2025 15:03:42 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v10] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 14:27:59 GMT, Jonas Norlinder wrote: > now we finally have a specific method that is called for GC activites... Then, it should be in `Universe::before_exit`, not inside heap. >> src/hotspot/share/services/cpuTimeUsage.hpp line 47: >> >>> 45: static jlong gc_threads(); >>> 46: static jlong vm_thread(); >>> 47: static jlong stringdedup(); >> >> I feel the API surface contains some redundancy. >> >> For example, the GC-part API design exposes two ways to query and they are essentially the same -- for the sake of simplicity, I'd suggest keeping only one. >> >> The calculation of `total` should be done by users of this API, I believe, when/if total is desirable. > > The motivation for `total()` is that this is probably what most users want, but in case anyone want a sub-component I also expose each one of them. It also serves as documentation as what we currently consider to be "total", so I would prefer keeping it. > > If you look at e.g. `WeakProcessor::CountingClosure` the following is defined > > size_t dead() const { return _old_dead + _new_dead; } > size_t new_dead() const { return _new_dead; } > size_t total() const { return dead() + _live; } > > > so having such convenience method in hotspot is not unprecedented and I would prefer keeping it. > > `statistics()` is a less important convenience method that can be removed. I think the smallest API would be `statisics()`, which returns all sub-components, and consumers of this API can calculate other derived metrics. YMMV. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2285544932 PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2285551132 From duke at openjdk.org Tue Aug 19 15:56:39 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Tue, 19 Aug 2025 15:56:39 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v10] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 14:57:51 GMT, Albert Mingkun Yang wrote: >> The motivation to move into `CollectedHeap::before_exit` is that now we finally have a specific method that is called for GC activites during exit so there is no need to conflate java.cpp with these tasks. >> >>> this calls back to Universe >> >> It called back to Universe in java.cpp too. Maybe you would want `Universe::print_on` to be refactored into CollectedHeap too? If that's the case maybe we should save that for a separate issue. >> >> > CLDG printing is not necessarily tired to heap >> >> That could be so, but it is put under `gc+exit` tag. Are you suggesting that we should break this apart and do it under another tag? > >> now we finally have a specific method that is called for GC activites... > > Then, it should be in `Universe::before_exit`, not inside heap. FWIW; `Universe::print_on` do actually call collected heap as well. void Universe::print_on(outputStream* st) { GCMutexLocker hl(Heap_lock); // Heap_lock might be locked by caller thread. st->print_cr("Heap"); StreamIndentor si(st, 1); heap()->print_heap_on(st); MetaspaceUtils::print_on(st); } I would be OK with moving it to `Universe::before_exit` and I can see the argument that the log message is conflated with components that are not strictly GC. That being said, I think it would also make sense from a code perspective to put it under GC as the log tag is defined to be GC. The best solution would probably be to redefine the log tags and break the block apart, but that would be out-of-scope for this PR. I'll wait for @kstefanj input before proceeding. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2285690897 From duke at openjdk.org Tue Aug 19 16:03:42 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Tue, 19 Aug 2025 16:03:42 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v10] In-Reply-To: References: Message-ID: <2wSybZnJX_B_94UbbiPj_gMeKGqoFeyhXk8AAtiM9lQ=.6ae7d021-fd81-425d-b47a-bf767ad7b4dd@github.com> On Tue, 19 Aug 2025 15:00:15 GMT, Albert Mingkun Yang wrote: >> The motivation for `total()` is that this is probably what most users want, but in case anyone want a sub-component I also expose each one of them. It also serves as documentation as what we currently consider to be "total", so I would prefer keeping it. >> >> If you look at e.g. `WeakProcessor::CountingClosure` the following is defined >> >> size_t dead() const { return _old_dead + _new_dead; } >> size_t new_dead() const { return _new_dead; } >> size_t total() const { return dead() + _live; } >> >> >> so having such convenience method in hotspot is not unprecedented and I would prefer keeping it. >> >> `statistics()` is a less important convenience method that can be removed. > > I think the smallest API would be `statisics()`, which returns all sub-components, and consumers of this API can calculate other derived metrics. YMMV. I would remove `CPUTimeUsage::GC::statistics()` as I would prefer having coherent types between classes in the namespace and since using structs over of classes defeats some of the utility of putting everything into a namespace. For instance, it makes little sense to define a struct for `Runtime` which only include one component currently and it would be less than ideal to return `jlong` for some classes and custom structs for others if we only have to pick one of these approaches. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2285707652 From dholmes at openjdk.org Wed Aug 20 02:35:38 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 20 Aug 2025 02:35:38 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v10] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 08:42:15 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). >> >> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: >> >> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() >> >> CPUTimeUsage::GC::gc_threads() >> CPUTimeUsage::GC::vm_thread() >> CPUTimeUsage::GC::stringdedup() >> >> CPUTimeUsage::Runtime::vm_thread() >> >> >> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. >> >> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: >> >> >> [71.425s][info][cpu ] === CPU time Statistics ============================================================= >> [71.425s][info][cpu ] CPUs >> [71.425s][info][cpu ] s % utilized >> [71.425s][info][cpu ] Process >> [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 >> [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 >> [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 >> [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 >> [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 >> [71.425s][info][cpu ] ===================================================================================== >> >> >> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused I'll leave it to the GC folk to approve, but the shared code changes look good to me. Thanks src/hotspot/share/services/cpuTimeUsage.cpp line 2: > 1: /* > 2: * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. When refactoring code into a new file, the first copyright year for the new file should be the earliest copyright year of the substantial code/content in that file?not the year the new file is created. ------------- PR Review: https://git.openjdk.org/jdk/pull/26621#pullrequestreview-3134573286 PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2286823424 From iwalulya at openjdk.org Wed Aug 20 07:54:44 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 20 Aug 2025 07:54:44 GMT Subject: RFR: 8365780: G1: Remset for young regions are cleared too early during Full GC In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 09:24:06 GMT, Ivan Walulya wrote: > Hi, > Please review this patch to move clearing of the young region remsets to later in the Full GC. G1HeapVerifier specifically G1FullCollector::verify_after_marking still assumes that the remsets for young regions are still valid and with status complete. Clearing these remsets too early triggers the verification failure. > > Testing: - Tiers 1-3 Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26839#issuecomment-3204687295 From iwalulya at openjdk.org Wed Aug 20 07:54:44 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 20 Aug 2025 07:54:44 GMT Subject: Integrated: 8365780: G1: Remset for young regions are cleared too early during Full GC In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 09:24:06 GMT, Ivan Walulya wrote: > Hi, > Please review this patch to move clearing of the young region remsets to later in the Full GC. G1HeapVerifier specifically G1FullCollector::verify_after_marking still assumes that the remsets for young regions are still valid and with status complete. Clearing these remsets too early triggers the verification failure. > > Testing: - Tiers 1-3 This pull request has now been integrated. Changeset: 9c338f6f Author: Ivan Walulya URL: https://git.openjdk.org/jdk/commit/9c338f6f87290e3ea3b43e6f7af8f073611b54d5 Stats: 7 lines in 2 files changed: 5 ins; 2 del; 0 mod 8365780: G1: Remset for young regions are cleared too early during Full GC Reviewed-by: sjohanss, ayang ------------- PR: https://git.openjdk.org/jdk/pull/26839 From sjohanss at openjdk.org Wed Aug 20 08:17:43 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Wed, 20 Aug 2025 08:17:43 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v10] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 15:54:29 GMT, Jonas Norlinder wrote: >>> now we finally have a specific method that is called for GC activites... >> >> Then, it should be in `Universe::before_exit`, not inside heap. > > FWIW; `Universe::print_on` do actually call collected heap as well. > > > void Universe::print_on(outputStream* st) { > GCMutexLocker hl(Heap_lock); // Heap_lock might be locked by caller thread. > st->print_cr("Heap"); > > StreamIndentor si(st, 1); > heap()->print_heap_on(st); > MetaspaceUtils::print_on(st); > } > > > I would be OK with moving it to `Universe::before_exit` and I can see the argument that the log message is conflated with components that are not strictly GC. That being said, I think it would also make sense from a code perspective to put it under GC as the log tag is defined to be GC. The best solution would probably be to redefine the log tags and break the block apart, but that would be out-of-scope for this PR. I'll wait for @kstefanj input before proceeding. I'm good with moving it to `Universe::before_exit` as well. Looks like a good fit now when it was added. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2287363859 From duke at openjdk.org Wed Aug 20 09:00:30 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Wed, 20 Aug 2025 09:00:30 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v11] In-Reply-To: References: Message-ID: > Hi all, > > This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). > > As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: > > CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() > > CPUTimeUsage::GC::gc_threads() > CPUTimeUsage::GC::vm_thread() > CPUTimeUsage::GC::stringdedup() > > CPUTimeUsage::Runtime::vm_thread() > > > I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. > > I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: > > > [71.425s][info][cpu ] === CPU time Statistics ============================================================= > [71.425s][info][cpu ] CPUs > [71.425s][info][cpu ] s % utilized > [71.425s][info][cpu ] Process > [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 > [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 > [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 > [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 > [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 > [71.425s][info][cpu ] ===================================================================================== > > > Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Remove GCStatistics, add thread_cpu_time_or_zero, move GC/heap log to Universe::before_exit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26621/files - new: https://git.openjdk.org/jdk/pull/26621/files/79a3323a..f29d5af4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=09-10 Stats: 74 lines in 4 files changed: 22 ins; 45 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/26621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621 PR: https://git.openjdk.org/jdk/pull/26621 From ayang at openjdk.org Wed Aug 20 10:41:44 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 20 Aug 2025 10:41:44 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v11] In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 09:00:30 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). >> >> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: >> >> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() >> >> CPUTimeUsage::GC::gc_threads() >> CPUTimeUsage::GC::vm_thread() >> CPUTimeUsage::GC::stringdedup() >> >> CPUTimeUsage::Runtime::vm_thread() >> >> >> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. >> >> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: >> >> >> [71.425s][info][cpu ] === CPU time Statistics ============================================================= >> [71.425s][info][cpu ] CPUs >> [71.425s][info][cpu ] s % utilized >> [71.425s][info][cpu ] Process >> [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 >> [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 >> [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 >> [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 >> [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 >> [71.425s][info][cpu ] ===================================================================================== >> >> >> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Remove GCStatistics, add thread_cpu_time_or_zero, move GC/heap log to Universe::before_exit src/hotspot/share/memory/universe.cpp line 1318: > 1316: } > 1317: > 1318: const double vm_thread_cpu_time = (double) CPUTimeUsage::Runtime::vm_thread() / NANOSECS_PER_SEC; Does `vm_thread_cpu_time` include gc-vm-thread time? Looking at how it's printed, "VM Thread" and "Garbage Collection" are two separate lines, suggesting there are no overlapping btw them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2287752295 From mdoerr at openjdk.org Wed Aug 20 22:05:12 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 20 Aug 2025 22:05:12 GMT Subject: RFR: 8360540: nmethod entry barriers of new nmethods should be disarmed In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 14:55:03 GMT, Martin Doerr wrote: > Adding `disarm` calls as ZGC and ShenandoahGC already have (see JBS issue for more details). Tier1-4 tests have passed. > > I will need reviews from GC experts to check for potentially problematic side effects. > Note that `rebuild_code_roots()` disarms all nmethods during `G1FullCollector::complete_collection`, now. > > Some stats (nmethod entry barrier hits in jvm98 with/without patch): > > | GC | before | after | > | -------- | ------ | ----- | > | G1 | 3339 | 127 | > | Parallel | 3223 | 1141 | > | Serial | 3206 | 1142 | How can we proceed? Should we handle the related issues separately or is anyone intending to work on a bigger change which solves all related issues? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25982#issuecomment-3200003859 From tschatzl at openjdk.org Thu Aug 21 09:15:54 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Aug 2025 09:15:54 GMT Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing [v3] In-Reply-To: References: <8FCHTMjSXHFLs5Q8jw9gLgWS-t1jCpRsSPKhR5LCUBE=.d845e003-ba02-47b9-afe2-45309f9adbae@github.com> <_yJlsycZBpjl9wwfv7sUn9Ar19akN4CKPg7i50jF1ws=.7b8ead31-ee56-42f8-b230-2fb97d1f35a4@github.com> <-QXCeqQ5G9fnCuyVw53P2VVGQSEusP7uK26 xOyDN9DM=.4eb62bae-0977-4f74-9f0c-d964d6396c91@github.com> Message-ID: On Mon, 18 Aug 2025 09:24:55 GMT, Ivan Walulya wrote: >> The `#active-processors * time-since-last-pause` approach sounds worth experimenting. >> >> One potential concern is the heap sizing behavior could be more heavily affected by #active-processors, which could be surprising comparing to G1's current behavior. Admittedly, G1's current heap sizing behavior could already be affected by #active-processors (mainly via default values for ParallelGCThreads/ConcGCThreads), but it is likely to a much lesser extent. >> >> If a prototype of this approach exists, we should probably test how much difference in heap sizing there is for an application running with a low value of `ActiveProcessorCount` vs a high value. My main worry is that `#active-processors * time-since-last-pause` could inflate the divisor too much if `#active-processors` is very high (e.g. >100), which could make the heap much smaller, which is quite counter-intuitive. > > So iiuc, we have narrowed down to > > Suggestion: Afaics yes :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26351#discussion_r2290428890 From tschatzl at openjdk.org Thu Aug 21 09:22:00 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Aug 2025 09:22:00 GMT Subject: RFR: 8364925: G1: Improve program flow around incremental collection set building [v2] In-Reply-To: References: Message-ID: On Mon, 18 Aug 2025 07:15:19 GMT, Ivan Walulya wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * ayang review > > Marked as reviewed by iwalulya (Reviewer). Thanks @walulyai @albertnetymk for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/26659#issuecomment-3209697911 From tschatzl at openjdk.org Thu Aug 21 09:22:01 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Aug 2025 09:22:01 GMT Subject: RFR: 8364650: G1: Use InvalidCSetIndex instead of UINT_MAX for "invalid" sentinel value of young_index_in_cset In-Reply-To: <7bSgIAWQvxD0VIIQwqQDCs-06xVAO4JAizvBk0tNcRQ=.ad8edc3a-0b31-40ab-af6a-479a1c75cdde@github.com> References: <7bSgIAWQvxD0VIIQwqQDCs-06xVAO4JAizvBk0tNcRQ=.ad8edc3a-0b31-40ab-af6a-479a1c75cdde@github.com> Message-ID: On Mon, 18 Aug 2025 07:08:20 GMT, Ivan Walulya wrote: >> Hi all, >> >> please review this small change to use `InvalidCSetIndex` instead of hardcoded `UINT_MAX` for `G1HeapRegion::_young_index_in_cset`. Just reuse the existing value that is already in use for `_index_in_opt_cset`. >> >> Testing: compilation, gha >> >> Thanks, >> Thomas > > Marked as reviewed by iwalulya (Reviewer). Thanks @walulyai @albertnetymk for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/26651#issuecomment-3209695664 From tschatzl at openjdk.org Thu Aug 21 09:22:02 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Aug 2025 09:22:02 GMT Subject: Integrated: 8364925: G1: Improve program flow around incremental collection set building In-Reply-To: References: Message-ID: On Wed, 6 Aug 2025 15:52:47 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that improves the G1CollectionSet incremental state handling slightly: > > * remove `_selected_groups_cur_length` with getter as we do not need a copy of that value around > * move implementations of some methods from header files into cpp file > * moved some incremental state updates from `finalize_old_part` to the respective `start/continue/stop_incremental_building` method > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: b735ef99 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/b735ef99b2285ec55a68896de25d29a02fdfcaf7 Stats: 52 lines in 2 files changed: 29 ins; 16 del; 7 mod 8364925: G1: Improve program flow around incremental collection set building Reviewed-by: ayang, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/26659 From tschatzl at openjdk.org Thu Aug 21 09:22:02 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Aug 2025 09:22:02 GMT Subject: Integrated: 8364650: G1: Use InvalidCSetIndex instead of UINT_MAX for "invalid" sentinel value of young_index_in_cset In-Reply-To: References: Message-ID: <33LFIQQUJZL6Nd95V7ui4-cN7iPr_WYDngCpthn-K7U=.aacdc1d7-b5c6-4852-872b-9c8a95923dab@github.com> On Tue, 5 Aug 2025 21:56:43 GMT, Thomas Schatzl wrote: > Hi all, > > please review this small change to use `InvalidCSetIndex` instead of hardcoded `UINT_MAX` for `G1HeapRegion::_young_index_in_cset`. Just reuse the existing value that is already in use for `_index_in_opt_cset`. > > Testing: compilation, gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 5ede5b47 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/5ede5b47d4291a18acc16833978ded038332cf9c Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod 8364650: G1: Use InvalidCSetIndex instead of UINT_MAX for "invalid" sentinel value of young_index_in_cset Reviewed-by: ayang, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/26651 From tschatzl at openjdk.org Thu Aug 21 09:28:52 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Aug 2025 09:28:52 GMT Subject: RFR: 8365055: G1: Merge Heap Roots phase incorrectly clears young gen remembered set every time [v2] In-Reply-To: References: <8JFuOjov4pzLsgan8_D26HNVtWFNTBm7OzuMMwRVUAM=.f557c3d1-ccef-4ea2-ad9c-0c4a217f24b4@github.com> Message-ID: On Mon, 18 Aug 2025 08:33:54 GMT, Ivan Walulya wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * fix comment in verification code >> * move that G1Policy member to G1CollectedHeap as it's used to verify stuff in G1CollectedHeap (and not used elsewhere anyway) > > src/hotspot/share/gc/g1/g1Policy.cpp line 933: > >> 931: >> 932: _analytics->report_pending_cards((double)pending_cards_at_gc_start(), is_young_only_pause); >> 933: _analytics->report_card_rs_length((double)_g1h->young_regions_cardset()->occupied(), is_young_only_pause); > > At this point in the execution, the `_g1h->young_regions_cardset()->clear()` has already been called, so this will be `0`. > > `post_evacuate_collection_set()` calls `prepare_for_mutator_after_young_collection()` which calls `start_new_collection_set()`, but `post_evacuate_collection_set()` is called before `policy()->record_young_collection_end()` > > Probably `_num_young_rem_set_cards_at_start` was added to `G1Policy` to assert on this, but it is not used. I forgot to remove `G1Policy::_num_young_rem_set_cards_at_start` in the latest change. The code uses the one in `G1CollectedHeap` now. The other mentioned issue is true. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26695#discussion_r2290462309 From tschatzl at openjdk.org Thu Aug 21 09:31:55 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Aug 2025 09:31:55 GMT Subject: RFR: 8365055: G1: Merge Heap Roots phase incorrectly clears young gen remembered set every time [v2] In-Reply-To: References: <8JFuOjov4pzLsgan8_D26HNVtWFNTBm7OzuMMwRVUAM=.f557c3d1-ccef-4ea2-ad9c-0c4a217f24b4@github.com> Message-ID: On Mon, 18 Aug 2025 08:34:34 GMT, Ivan Walulya wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * fix comment in verification code >> * move that G1Policy member to G1CollectedHeap as it's used to verify stuff in G1CollectedHeap (and not used elsewhere anyway) > > src/hotspot/share/gc/g1/g1RemSet.cpp line 1443: > >> 1441: } >> 1442: >> 1443: { > > guarding this block with `if (initial_evacuation)` might be an easier alternative. I want to eventually move all the special handling for the `young_regions_cset_group` out of `merge_heap_roots` and into the collection set. All this special handling at various places where we do something with the collection set and then do something with the young card set is tiring to review and error prone. Imo it is better to just make `G1CollectionSet` handle all this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26695#discussion_r2290468771 From tschatzl at openjdk.org Thu Aug 21 09:39:09 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Aug 2025 09:39:09 GMT Subject: RFR: 8364532: G1: In liveness tracing, print more significant digits for the liveness value [v4] In-Reply-To: References: Message-ID: <-VpiqT85VAZs-iSORsFgUjg3BBUs22VekbWSEwZKKMk=.6d56d613-4272-498a-81cc-5e0c0dea05b8@github.com> On Mon, 18 Aug 2025 07:06:44 GMT, Ivan Walulya wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * ayang suggestion to avoid exponential output > > Marked as reviewed by iwalulya (Reviewer). Thanks @walulyai @albertnetymk for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/26595#issuecomment-3209755742 From tschatzl at openjdk.org Thu Aug 21 09:39:09 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Aug 2025 09:39:09 GMT Subject: RFR: 8364414: G1: Use simpler data structure for holding collection set candidates during calculation [v2] In-Reply-To: <2dfZBQ0FQPMHjXan6hv1Ag1lXJz1JRGBX3M8UqjiRcY=.9bc84f4b-b57a-4518-b6f3-cd28156d07bc@github.com> References: <1yNuabPYEkaNRSCQnDveI6hVfxoRrNT-3oFTj77Enn0=.062061ec-5ef7-44d6-87c5-caff8c3d034f@github.com> <2dfZBQ0FQPMHjXan6hv1Ag1lXJz1JRGBX3M8UqjiRcY=.9bc84f4b-b57a-4518-b6f3-cd28156d07bc@github.com> Message-ID: On Mon, 18 Aug 2025 07:02:32 GMT, Ivan Walulya wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * fix sort function > > Marked as reviewed by iwalulya (Reviewer). Thanks @walulyai @albertnetymk for your reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26572#issuecomment-3209754269 From tschatzl at openjdk.org Thu Aug 21 09:39:10 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Aug 2025 09:39:10 GMT Subject: Integrated: 8364532: G1: In liveness tracing, print more significant digits for the liveness value In-Reply-To: References: Message-ID: <-vaz2b-oLp4n53fESKPiujw60Cq88DkkP6yydxDgdc8=.0be023d0-a3f9-4b38-aa28-20d84b18d1a5@github.com> On Fri, 1 Aug 2025 11:45:35 GMT, Thomas Schatzl wrote: > Hi all, > > please review this small change that adds some more significant digits (3 in total) for the "liveness" column in collection set group logging. > > E.g. see the emphasized columns that lack precision (it's more irritating with lots of lines showing single-digit values): > > 50.707s][trace][gc,liveness] GC(13) ### groud-id num-regions gc-eff liveness remset type > 50.707s][trace][gc,liveness] GC(13) ### (bytes/ms) % (bytes) > 50.707s][trace][gc,liveness] GC(13) ### 1 70 0.0 *100* 3199208 Y > 50.707s][trace][gc,liveness] GC(13) ### 2 51 5298129.5 *18* 1224072 M > 50.707s][trace][gc,liveness] GC(13) ### 3 5 3223983.6 *31* 176648 M > 50.707s][trace][gc,liveness] GC(13) ### 4 5 3022016.3 *32* 176648 M > > > (This depends on PR#26591, so please look at that one first). > > The change makes sure that three significant digits are printed. > > Testing: manual review > > Thanks, > Thomas This pull request has now been integrated. Changeset: 9439d763 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/9439d7630901d3e29141adf46bbe9284b86683f4 Stats: 7 lines in 3 files changed: 1 ins; 1 del; 5 mod 8364532: G1: In liveness tracing, print more significant digits for the liveness value Reviewed-by: ayang, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/26595 From tschatzl at openjdk.org Thu Aug 21 09:39:10 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Aug 2025 09:39:10 GMT Subject: Integrated: 8364414: G1: Use simpler data structure for holding collection set candidates during calculation In-Reply-To: References: Message-ID: On Thu, 31 Jul 2025 10:49:39 GMT, Thomas Schatzl wrote: > Hi all, > > please review this refactoring of the collection set choosing mechanism to use a lighter data structure: instead of an array of `G1CollectionSetCandidateInfo`s, use an array of `G1HeapRegion*` - we do not use the additional information provided by `G1CollectionSetCandidateInfo` at all during that process, and we copy the contents later anyway. > > This reduces code complexity a bit (no need to extract the `G1HeapRegion*` from the struct) and reduces memory consumption a little as well. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: f0e70669 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/f0e706698df5ac199198b252d77d27a05abad1da Stats: 95 lines in 4 files changed: 29 ins; 38 del; 28 mod 8364414: G1: Use simpler data structure for holding collection set candidates during calculation Reviewed-by: ayang, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/26572 From tschatzl at openjdk.org Thu Aug 21 09:40:56 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Aug 2025 09:40:56 GMT Subject: RFR: 8365034: G1: Remove num_groups_selected in G1CollectionSet::select_candidates_from_optional_groups as it is unnecessary In-Reply-To: References: Message-ID: On Fri, 15 Aug 2025 13:03:17 GMT, Albert Mingkun Yang wrote: >> Hi all, >> >> please review this removal of the local `num_selected_regions` from `G1CollectionSet::select_candidates_from_optional_groups()` - the same information is maintained within the local `selected_groups` list. >> >> Testing: gha >> >> Thanks, >> Thomas > > src/hotspot/share/gc/g1/g1CollectionSet.cpp line 501: > >> 499: uint num_initial_regions = 0; >> 500: uint prev_num_optional_regions = _optional_groups.num_regions(); >> 501: guarantee(prev_num_optional_regions == 0, "must be, why else?"); > > Why so? Can't there be any optional regions when populating cset from marking? > > Also, seems not very related to this PR. I'll remove this and post this separately. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26674#discussion_r2290490856 From tschatzl at openjdk.org Thu Aug 21 09:41:03 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Aug 2025 09:41:03 GMT Subject: RFR: 8365026: G1: Initialization should start a "full" new collection set In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 08:54:56 GMT, Albert Mingkun Yang wrote: >> Hi all, >> >> please review this change that makes G1 start a "full" new collection set at initialization time, calling `G1CollectedHeap::start_new_collection_set()`. >> >> Previously G1 only did part of that (start incremental building only), on a not-fully initialized collection set instance. It works, but is not nice. >> >> Testing: gha >> >> Thanks, >> Thomas > > Marked as reviewed by ayang (Reviewer). Thanks @albertnetymk @kimbarrett for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/26673#issuecomment-3209760052 From tschatzl at openjdk.org Thu Aug 21 09:41:03 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Aug 2025 09:41:03 GMT Subject: Integrated: 8365026: G1: Initialization should start a "full" new collection set In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 10:05:52 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that makes G1 start a "full" new collection set at initialization time, calling `G1CollectedHeap::start_new_collection_set()`. > > Previously G1 only did part of that (start incremental building only), on a not-fully initialized collection set instance. It works, but is not nice. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: ed260e8c Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/ed260e8cae329a0c077e91ff76d104ee197fb7fd Stats: 8 lines in 3 files changed: 3 ins; 4 del; 1 mod 8365026: G1: Initialization should start a "full" new collection set Reviewed-by: ayang, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/26673 From tschatzl at openjdk.org Thu Aug 21 09:46:56 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Aug 2025 09:46:56 GMT Subject: RFR: 8364962: G1: Inline G1CollectionSet::finalize_incremental_building In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 07:37:31 GMT, Kim Barrett wrote: >> Hi all, >> >> please review this inlining of `G1CollectionSet::finalize_incremental_building` - it does not do anything useful for some time now, only some fairly generic asserts. There is only one caller too. >> >> Testing: gha >> >> Thanks, >> Thomas > > Looks good. Thanks @kimbarrett @albertnetymk for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/26687#issuecomment-3209785405 From tschatzl at openjdk.org Thu Aug 21 09:46:57 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Aug 2025 09:46:57 GMT Subject: Integrated: 8364962: G1: Inline G1CollectionSet::finalize_incremental_building In-Reply-To: References: Message-ID: On Fri, 8 Aug 2025 08:06:49 GMT, Thomas Schatzl wrote: > Hi all, > > please review this inlining of `G1CollectionSet::finalize_incremental_building` - it does not do anything useful for some time now, only some fairly generic asserts. There is only one caller too. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: f61b247f Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/f61b247fe3a818fc60a61c6f42a676ad94e8e976 Stats: 11 lines in 2 files changed: 1 ins; 8 del; 2 mod 8364962: G1: Inline G1CollectionSet::finalize_incremental_building Reviewed-by: ayang, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/26687 From tschatzl at openjdk.org Thu Aug 21 09:48:58 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Aug 2025 09:48:58 GMT Subject: RFR: 8365115: G1: Refactor rem set statistics gather code for group In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 07:47:04 GMT, Kim Barrett wrote: >> Hi all, >> >> please review this change to remove some code duplication in group remset statistics gathering. >> >> Testing: gha >> >> Thanks, >> Thomas > > Looks good. Thanks @kimbarrett @albertnetymk for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/26691#issuecomment-3209793283 From tschatzl at openjdk.org Thu Aug 21 09:48:59 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Aug 2025 09:48:59 GMT Subject: Integrated: 8365115: G1: Refactor rem set statistics gather code for group In-Reply-To: References: Message-ID: <_1DuPSZKF255IBD3eCK3NeRGJUihMy29aD0pUPxRfeQ=.fe1d4bdd-d81e-419b-824e-16e621c377e8@github.com> On Fri, 8 Aug 2025 09:39:42 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to remove some code duplication in group remset statistics gathering. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: a3fd4248 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/a3fd4248b74ed800ff124cc3e7c259dca36ea446 Stats: 41 lines in 1 file changed: 9 ins; 14 del; 18 mod 8365115: G1: Refactor rem set statistics gather code for group Reviewed-by: kbarrett, ayang ------------- PR: https://git.openjdk.org/jdk/pull/26691 From tschatzl at openjdk.org Thu Aug 21 10:07:06 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Aug 2025 10:07:06 GMT Subject: RFR: 8364934: G1: Rename members of G1CollectionSet [v4] In-Reply-To: References: Message-ID: > Hi all, > > please review this renaming of various members of `G1CollectionSet` to > > - use the same prefixes for the regions ("_regions") and candidate groups ("_groups") consistently, avoiding adding prefixes here and there for no discernible reason > - remove unnecessary prefixes (`collection_set`) - everything is part of the collection set > - fix/improve some documentation > > Testing: gha > > Thanks, > THoams Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Merge branch 'master' into 8364934-g1collectionset-renaming - Merge branch 'master' into 8364934-g1collectionset-renaming - * one more renaming: prepare_groups_for_scan() -> prepare_for_scan() - Merge branch '8364925-improve-program-flow-inc-cset' into 8364934-g1collectionset-renaming - * ayang review - 8364934 Hi all, please review this renaming of various members of `G1CollectionSet` to - use the same prefixes - remove unnecessary prefixes (`collection_set`) - fix some documentation Testing: gha Thanks, THoams - * remove accidentally merged in JDK-8364934 - 8364925 Hi all, please review this change that improves the G1CollectionSet incremental state handling slightly: * remove `_selected_groups_cur_length` with getter as we do not need a copy of that value around * move implementations of some methods from header files into cpp file * moved some incremental state updates from `finalize_old_part` to the respective `start/continue/stop_incremental_building` method Testing: gha Thanks, Thomas ------------- Changes: https://git.openjdk.org/jdk/pull/26670/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26670&range=03 Stats: 115 lines in 7 files changed: 15 ins; 9 del; 91 mod Patch: https://git.openjdk.org/jdk/pull/26670.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26670/head:pull/26670 PR: https://git.openjdk.org/jdk/pull/26670 From tschatzl at openjdk.org Thu Aug 21 10:11:06 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Aug 2025 10:11:06 GMT Subject: RFR: 8365034: G1: Remove num_groups_selected in G1CollectionSet::select_candidates_from_optional_groups as it is unnecessary [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review this removal of the local `num_selected_regions` from `G1CollectionSet::select_candidates_from_optional_groups()` - the same information is maintained within the local `selected_groups` list. > > Testing: gha > > Thanks, > Thomas Thomas Schatzl 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: - * ayang review - Merge branch '8364934-g1collectionset-renaming' into 8365034-remove-unnecessary-num_selected_regions - 8365034 Hi all, please review this removal of the local `num_selected_regions` from `G1CollectionSet::select_candidates_from_optional_groups()` - the same information is maintained within the local `selected_groups` list. Testing: gha Thanks, Thomas ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26674/files - new: https://git.openjdk.org/jdk/pull/26674/files/60a9aec4..82287099 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26674&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26674&range=00-01 Stats: 26600 lines in 855 files changed: 14971 ins; 8263 del; 3366 mod Patch: https://git.openjdk.org/jdk/pull/26674.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26674/head:pull/26674 PR: https://git.openjdk.org/jdk/pull/26674 From ayang at openjdk.org Thu Aug 21 10:16:04 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 21 Aug 2025 10:16:04 GMT Subject: RFR: 8365919: Replace currentTimeMillis with nanoTime in Stresser.java Message-ID: Mostly a mechanic change from `currentTimeMillis()` to `nanoTime()/1000000`. It also removes `finishTime` to avoid overflowing. The change in `iteration()` is to ensure `currentTime` is properly initialized. (Was investigating a timeout on Windows-x64, which led me to this code. I think this fix is good enough by its own.) Test: tier1-5 ------------- Commit messages: - test-nano-time Changes: https://git.openjdk.org/jdk/pull/26879/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26879&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365919 Stats: 23 lines in 1 file changed: 5 ins; 6 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/26879.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26879/head:pull/26879 PR: https://git.openjdk.org/jdk/pull/26879 From ghan at openjdk.org Thu Aug 21 10:17:06 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 21 Aug 2025 10:17:06 GMT Subject: RFR: 8352969: G1: Improve testability of optional collections 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. ------------- Commit messages: - 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=00 Issue: https://bugs.openjdk.org/browse/JDK-8352969 Stats: 16 lines in 4 files changed: 3 ins; 2 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/26880.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26880/head:pull/26880 PR: https://git.openjdk.org/jdk/pull/26880 From ghan at openjdk.org Thu Aug 21 10:52:07 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 21 Aug 2025 10:52:07 GMT Subject: RFR: 8352969: G1: Improve testability of optional collections [v2] 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: Simplified implementation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26880/files - new: https://git.openjdk.org/jdk/pull/26880/files/22420f09..6661deef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26880&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26880&range=00-01 Stats: 18 lines in 3 files changed: 5 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/26880.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26880/head:pull/26880 PR: https://git.openjdk.org/jdk/pull/26880 From ayang at openjdk.org Thu Aug 21 11:01:22 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 21 Aug 2025 11:01:22 GMT Subject: RFR: 8365922: Parallel: Group uses of GCTimeRatio to a single location Message-ID: 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 ------------- Commit messages: - pgc-gc-time-ratio-prepare-management Changes: https://git.openjdk.org/jdk/pull/26881/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26881&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365922 Stats: 42 lines in 5 files changed: 14 ins; 18 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/26881.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26881/head:pull/26881 PR: https://git.openjdk.org/jdk/pull/26881 From tschatzl at openjdk.org Thu Aug 21 11:04:19 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Aug 2025 11:04:19 GMT Subject: RFR: 8364934: G1: Rename members of G1CollectionSet [v5] In-Reply-To: References: Message-ID: > Hi all, > > please review this renaming of various members of `G1CollectionSet` to > > - use the same prefixes for the regions ("_regions") and candidate groups ("_groups") consistently, avoiding adding prefixes here and there for no discernible reason > - remove unnecessary prefixes (`collection_set`) - everything is part of the collection set > - fix/improve some documentation > > Testing: gha > > Thanks, > THoams Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * undo unnecessarily added JDK-8365040 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26670/files - new: https://git.openjdk.org/jdk/pull/26670/files/889b0875..88eca31a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26670&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26670&range=03-04 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26670.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26670/head:pull/26670 PR: https://git.openjdk.org/jdk/pull/26670 From ayang at openjdk.org Thu Aug 21 11:51:52 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 21 Aug 2025 11:51:52 GMT Subject: RFR: 8364934: G1: Rename members of G1CollectionSet [v5] In-Reply-To: References: Message-ID: On Thu, 21 Aug 2025 11:04:19 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this renaming of various members of `G1CollectionSet` to >> >> - use the same prefixes for the regions ("_regions") and candidate groups ("_groups") consistently, avoiding adding prefixes here and there for no discernible reason >> - remove unnecessary prefixes (`collection_set`) - everything is part of the collection set >> - fix/improve some documentation >> >> Testing: gha >> >> Thanks, >> THoams > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * undo unnecessarily added JDK-8365040 Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26670#pullrequestreview-3140296907 From tschatzl at openjdk.org Thu Aug 21 11:57:06 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Aug 2025 11:57:06 GMT Subject: RFR: 8364934: G1: Rename members of G1CollectionSet [v5] In-Reply-To: References: Message-ID: On Thu, 21 Aug 2025 11:49:00 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * undo unnecessarily added JDK-8365040 > > Marked as reviewed by ayang (Reviewer). Thanks for your reviews @albertnetymk @kimbarrett . ------------- PR Comment: https://git.openjdk.org/jdk/pull/26670#issuecomment-3210276595 From tschatzl at openjdk.org Thu Aug 21 11:57:07 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Aug 2025 11:57:07 GMT Subject: Integrated: 8364934: G1: Rename members of G1CollectionSet In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 09:32:06 GMT, Thomas Schatzl wrote: > Hi all, > > please review this renaming of various members of `G1CollectionSet` to > > - use the same prefixes for the regions ("_regions") and candidate groups ("_groups") consistently, avoiding adding prefixes here and there for no discernible reason > - remove unnecessary prefixes (`collection_set`) - everything is part of the collection set > - fix/improve some documentation > > Testing: gha > > Thanks, > THoams This pull request has now been integrated. Changeset: 02fe095d Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/02fe095d29994bec28c85beb6bf2a69b0f49b206 Stats: 111 lines in 7 files changed: 15 ins; 4 del; 92 mod 8364934: G1: Rename members of G1CollectionSet Reviewed-by: ayang, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/26670 From duke at openjdk.org Thu Aug 21 11:59:38 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Thu, 21 Aug 2025 11:59:38 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v12] In-Reply-To: References: Message-ID: > Hi all, > > This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). > > As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: > > CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() > > CPUTimeUsage::GC::gc_threads() > CPUTimeUsage::GC::vm_thread() > CPUTimeUsage::GC::stringdedup() > > CPUTimeUsage::Runtime::vm_thread() > > > I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. > > I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: > > > [71.425s][info][cpu ] === CPU time Statistics ============================================================= > [71.425s][info][cpu ] CPUs > [71.425s][info][cpu ] s % utilized > [71.425s][info][cpu ] Process > [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 > [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 > [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 > [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 > [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 > [71.425s][info][cpu ] ===================================================================================== > > > Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Remove CPUTimeUsage::Runtime ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26621/files - new: https://git.openjdk.org/jdk/pull/26621/files/f29d5af4..b7fdc0f8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=10-11 Stats: 12 lines in 3 files changed: 0 ins; 12 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621 PR: https://git.openjdk.org/jdk/pull/26621 From duke at openjdk.org Thu Aug 21 11:59:38 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Thu, 21 Aug 2025 11:59:38 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v11] In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 09:00:30 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). >> >> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: >> >> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() >> >> CPUTimeUsage::GC::gc_threads() >> CPUTimeUsage::GC::vm_thread() >> CPUTimeUsage::GC::stringdedup() >> >> CPUTimeUsage::Runtime::vm_thread() >> >> >> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. >> >> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: >> >> >> [71.425s][info][cpu ] === CPU time Statistics ============================================================= >> [71.425s][info][cpu ] CPUs >> [71.425s][info][cpu ] s % utilized >> [71.425s][info][cpu ] Process >> [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 >> [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 >> [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 >> [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 >> [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 >> [71.425s][info][cpu ] ===================================================================================== >> >> >> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Remove GCStatistics, add thread_cpu_time_or_zero, move GC/heap log to Universe::before_exit I had an offline discussion with @albertnetymk (thanks for bringing this up!) and we both agree that the current definition of `CPUTimeUsage::Runtime::vm_thread()` may be misread. As a consequence, we believe that expanding this interface to include more components would be best served by creating a separate PR that can serve as an explicit discussion for the layout. As such I'm removing `CPUTimeUsage::Runtime` from this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26621#issuecomment-3210275213 From tschatzl at openjdk.org Thu Aug 21 12:02:32 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Aug 2025 12:02:32 GMT Subject: RFR: 8365040: G1: Remove sorting at end of collection set selection [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review this change to remove some unnecessary sorting of the collection set introduced in https://bugs.openjdk.org/browse/JDK-8165313, and made unnecessary in https://bugs.openjdk.org/browse/JDK-8165443 (all JDK 9 :)). > > Testing: test case in CRs, see CR for test results, gha > > Thanks, > Thomas Thomas Schatzl 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. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26676/files - new: https://git.openjdk.org/jdk/pull/26676/files/4f4948be..4f4948be Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26676&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26676&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26676.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26676/head:pull/26676 PR: https://git.openjdk.org/jdk/pull/26676 From tschatzl at openjdk.org Thu Aug 21 12:02:18 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Aug 2025 12:02:18 GMT Subject: RFR: 8365052: G1: Remove G1CollectionSet::groups() accessors [v2] In-Reply-To: <8ZodEn2wqRkIaTR2ZoMjm5scNATrQHcS1IP1VVJMVtM=.70676141-6535-4869-8b14-e692bad9ab6a@github.com> References: <8ZodEn2wqRkIaTR2ZoMjm5scNATrQHcS1IP1VVJMVtM=.70676141-6535-4869-8b14-e692bad9ab6a@github.com> Message-ID: > Hi all, > > please review this small change that remove the public `G1CollectionSet::groups()` accessors because they are never used from outside the `G1CollectionSet` class. > > Testing: local compilation, gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - 8365052 Hi all, please review this small change that remove the public `G1CollectionSet::groups()` accessors because they are never used from outside the `G1CollectionSet` class. Testing: local compilation, gha Thanks, Thomas - * one more renaming: prepare_groups_for_scan() -> prepare_for_scan() - Merge branch '8364925-improve-program-flow-inc-cset' into 8364934-g1collectionset-renaming - * ayang review - 8364934 Hi all, please review this renaming of various members of `G1CollectionSet` to - use the same prefixes - remove unnecessary prefixes (`collection_set`) - fix some documentation Testing: gha Thanks, THoams - * remove accidentally merged in JDK-8364934 - 8364925 Hi all, please review this change that improves the G1CollectionSet incremental state handling slightly: * remove `_selected_groups_cur_length` with getter as we do not need a copy of that value around * move implementations of some methods from header files into cpp file * moved some incremental state updates from `finalize_old_part` to the respective `start/continue/stop_incremental_building` method Testing: gha Thanks, Thomas ------------- Changes: https://git.openjdk.org/jdk/pull/26688/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26688&range=01 Stats: 151 lines in 7 files changed: 44 ins; 23 del; 84 mod Patch: https://git.openjdk.org/jdk/pull/26688.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26688/head:pull/26688 PR: https://git.openjdk.org/jdk/pull/26688 From tschatzl at openjdk.org Thu Aug 21 12:02:12 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Aug 2025 12:02:12 GMT Subject: RFR: 8365024: G1: Make G1CollectionSet::_inc_build_state assert-only [v2] In-Reply-To: References: Message-ID: <6-C10PyEwkMpze2BJXRmXRWp4IsXe2PgSnBA8sy8YDs=.bfe07255-0db7-4e2c-be8b-a7c7203e3628@github.com> > Hi all, > > please review this change that makes the `G1CollectionSet::_inc_build_state` member debug/assert-only - it's only ever used in assertions. > > Testing: local compilation, gha > > Thanks, > Thomas Thomas Schatzl 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. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26671/files - new: https://git.openjdk.org/jdk/pull/26671/files/09b659ed..09b659ed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26671&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26671&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26671.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26671/head:pull/26671 PR: https://git.openjdk.org/jdk/pull/26671 From ayang at openjdk.org Thu Aug 21 12:08:56 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 21 Aug 2025 12:08:56 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v12] In-Reply-To: References: Message-ID: On Thu, 21 Aug 2025 11:59:38 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). >> >> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: >> >> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() >> >> CPUTimeUsage::GC::gc_threads() >> CPUTimeUsage::GC::vm_thread() >> CPUTimeUsage::GC::stringdedup() >> >> CPUTimeUsage::Runtime::vm_thread() >> >> >> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. >> >> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: >> >> >> [71.425s][info][cpu ] === CPU time Statistics ============================================================= >> [71.425s][info][cpu ] CPUs >> [71.425s][info][cpu ] s % utilized >> [71.425s][info][cpu ] Process >> [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 >> [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 >> [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 >> [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 >> [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 >> [71.425s][info][cpu ] ===================================================================================== >> >> >> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Remove CPUTimeUsage::Runtime Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26621#pullrequestreview-3140358434 From duke at openjdk.org Thu Aug 21 13:52:53 2025 From: duke at openjdk.org (duke) Date: Thu, 21 Aug 2025 13:52:53 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v12] In-Reply-To: References: Message-ID: <7-F_uRu2j1uwCfI9QrIcLpaZ15gJVft_sNJlN7DicRc=.0d4f66ca-77f6-4f8e-bdbd-76fa86dbcaa2@github.com> On Thu, 21 Aug 2025 11:59:38 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). >> >> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: >> >> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() >> >> CPUTimeUsage::GC::gc_threads() >> CPUTimeUsage::GC::vm_thread() >> CPUTimeUsage::GC::stringdedup() >> >> >> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. >> >> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: >> >> >> [71.425s][info][cpu ] === CPU time Statistics ============================================================= >> [71.425s][info][cpu ] CPUs >> [71.425s][info][cpu ] s % utilized >> [71.425s][info][cpu ] Process >> [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 >> [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 >> [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 >> [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 >> [71.425s][info][cpu ] ===================================================================================== > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Remove CPUTimeUsage::Runtime @JonasNorlinder Your change (at version b7fdc0f8c608ecfdd6a4f6a875b8cd6a58ace5c8) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26621#issuecomment-3210699903 From duke at openjdk.org Thu Aug 21 14:08:05 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Thu, 21 Aug 2025 14:08:05 GMT Subject: Integrated: 8364638: Refactor and make accumulated GC CPU time code generic In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 13:59:43 GMT, Jonas Norlinder wrote: > Hi all, > > This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). > > As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: > > CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() > > CPUTimeUsage::GC::gc_threads() > CPUTimeUsage::GC::vm_thread() > CPUTimeUsage::GC::stringdedup() > > > I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. > > I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: > > > [71.425s][info][cpu ] === CPU time Statistics ============================================================= > [71.425s][info][cpu ] CPUs > [71.425s][info][cpu ] s % utilized > [71.425s][info][cpu ] Process > [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 > [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 > [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 > [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 > [71.425s][info][cpu ] ===================================================================================== This pull request has now been integrated. Changeset: fb651fd6 Author: Jonas Norlinder Committer: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/fb651fd6d246e69b42363e050eb8d96afb633eed Stats: 281 lines in 11 files changed: 202 ins; 76 del; 3 mod 8364638: Refactor and make accumulated GC CPU time code generic Reviewed-by: ayang, sjohanss ------------- PR: https://git.openjdk.org/jdk/pull/26621 From tschatzl at openjdk.org Thu Aug 21 15:15:10 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Aug 2025 15:15:10 GMT Subject: RFR: 8365024: G1: Make G1CollectionSet::_inc_build_state assert-only [v3] In-Reply-To: References: Message-ID: <_sPU_ODwR_JTG506Z7lvy-7mukR-VBzJg7toKzji6qI=.3e02ed55-c6b8-4fdc-8015-e5160187d007@github.com> > Hi all, > > please review this change that makes the `G1CollectionSet::_inc_build_state` member debug/assert-only - it's only ever used in assertions. > > Testing: local compilation, gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Merge branch 'master' into 8365024-inc-cset-state-assert-only - 8365024 Hi all, please review this change that makes the `G1CollectionSet::_inc_build_state` member debug/assert-only - it's only ever used in assertions. Testing: local compilation, gha Thanks, Thomas - 8364934 Hi all, please review this renaming of various members of `G1CollectionSet` to - use the same prefixes - remove unnecessary prefixes (`collection_set`) - fix some documentation Testing: gha Thanks, THoams - * remove accidentally merged in JDK-8364934 - 8364925 Hi all, please review this change that improves the G1CollectionSet incremental state handling slightly: * remove `_selected_groups_cur_length` with getter as we do not need a copy of that value around * move implementations of some methods from header files into cpp file * moved some incremental state updates from `finalize_old_part` to the respective `start/continue/stop_incremental_building` method Testing: gha Thanks, Thomas ------------- Changes: https://git.openjdk.org/jdk/pull/26671/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26671&range=02 Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26671.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26671/head:pull/26671 PR: https://git.openjdk.org/jdk/pull/26671 From tschatzl at openjdk.org Thu Aug 21 15:19:11 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Aug 2025 15:19:11 GMT Subject: RFR: 8365034: G1: Remove num_groups_selected in G1CollectionSet::select_candidates_from_optional_groups as it is unnecessary [v3] In-Reply-To: References: Message-ID: > Hi all, > > please review this removal of the local `num_selected_regions` from `G1CollectionSet::select_candidates_from_optional_groups()` - the same information is maintained within the local `selected_groups` list. > > Testing: gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge branch 'master' into 8365034-remove-unnecessary-num_selected_regions - * ayang review - Merge branch '8364934-g1collectionset-renaming' into 8365034-remove-unnecessary-num_selected_regions - Merge branch 'master' into 8364934-g1collectionset-renaming - Merge branch 'master' into 8364934-g1collectionset-renaming - * one more renaming: prepare_groups_for_scan() -> prepare_for_scan() - Merge branch '8364925-improve-program-flow-inc-cset' into 8364934-g1collectionset-renaming - * ayang review - 8365034 Hi all, please review this removal of the local `num_selected_regions` from `G1CollectionSet::select_candidates_from_optional_groups()` - the same information is maintained within the local `selected_groups` list. Testing: gha Thanks, Thomas - 8364934 Hi all, please review this renaming of various members of `G1CollectionSet` to - use the same prefixes - remove unnecessary prefixes (`collection_set`) - fix some documentation Testing: gha Thanks, THoams - ... and 2 more: https://git.openjdk.org/jdk/compare/fb651fd6...131c4d63 ------------- Changes: https://git.openjdk.org/jdk/pull/26674/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26674&range=02 Stats: 9 lines in 1 file changed: 0 ins; 7 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26674.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26674/head:pull/26674 PR: https://git.openjdk.org/jdk/pull/26674 From ayang at openjdk.org Thu Aug 21 15:19:57 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 21 Aug 2025 15:19:57 GMT Subject: RFR: 8365024: G1: Make G1CollectionSet::_inc_build_state assert-only [v3] In-Reply-To: <_sPU_ODwR_JTG506Z7lvy-7mukR-VBzJg7toKzji6qI=.3e02ed55-c6b8-4fdc-8015-e5160187d007@github.com> References: <_sPU_ODwR_JTG506Z7lvy-7mukR-VBzJg7toKzji6qI=.3e02ed55-c6b8-4fdc-8015-e5160187d007@github.com> Message-ID: On Thu, 21 Aug 2025 15:15:10 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that makes the `G1CollectionSet::_inc_build_state` member debug/assert-only - it's only ever used in assertions. >> >> Testing: local compilation, gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Merge branch 'master' into 8365024-inc-cset-state-assert-only > - 8365024 > > Hi all, > > please review this change that makes the `G1CollectionSet::_inc_build_state` member debug/assert-only - it's only ever used in assertions. > > Testing: local compilation, gha > > Thanks, > Thomas > - 8364934 > > Hi all, > > please review this renaming of various members of `G1CollectionSet` to > > - use the same prefixes > - remove unnecessary prefixes (`collection_set`) > - fix some documentation > > Testing: gha > > Thanks, > THoams > - * remove accidentally merged in JDK-8364934 > - 8364925 > > Hi all, > > please review this change that improves the G1CollectionSet incremental state handling slightly: > > * remove `_selected_groups_cur_length` with getter as we do not need a copy of that value around > * move implementations of some methods from header files into cpp file > * moved some incremental state updates from `finalize_old_part` to the respective `start/continue/stop_incremental_building` method > > Testing: gha > > Thanks, > Thomas Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26671#pullrequestreview-3141181752 From tschatzl at openjdk.org Thu Aug 21 15:27:00 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Aug 2025 15:27:00 GMT Subject: RFR: 8365040: G1: Remove sorting at end of collection set selection [v3] In-Reply-To: References: Message-ID: > Hi all, > > please review this change to remove some unnecessary sorting of the collection set introduced in https://bugs.openjdk.org/browse/JDK-8165313, and made unnecessary in https://bugs.openjdk.org/browse/JDK-8165443 (all JDK 9 :)). > > Testing: test case in CRs, see CR for test results, gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Merge branch 'master' into 8365040-remove-collection-set-sorting - 8365040 Hi all, please review this change to remove some unnecessary sorting of the collection set introduced in https://bugs.openjdk.org/browse/JDK-8165313, and made unnecessary in https://bugs.openjdk.org/browse/JDK-8165443 (all JDK 9 :)). Testing: test case in CRs, gha Thanks, Thomas - 8364934 Hi all, please review this renaming of various members of `G1CollectionSet` to - use the same prefixes - remove unnecessary prefixes (`collection_set`) - fix some documentation Testing: gha Thanks, THoams - * remove accidentally merged in JDK-8364934 - 8364925 Hi all, please review this change that improves the G1CollectionSet incremental state handling slightly: * remove `_selected_groups_cur_length` with getter as we do not need a copy of that value around * move implementations of some methods from header files into cpp file * moved some incremental state updates from `finalize_old_part` to the respective `start/continue/stop_incremental_building` method Testing: gha Thanks, Thomas ------------- Changes: https://git.openjdk.org/jdk/pull/26676/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26676&range=02 Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26676.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26676/head:pull/26676 PR: https://git.openjdk.org/jdk/pull/26676 From tschatzl at openjdk.org Thu Aug 21 15:34:07 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Aug 2025 15:34:07 GMT Subject: RFR: 8365052: G1: Remove G1CollectionSet::groups() accessors [v3] In-Reply-To: <8ZodEn2wqRkIaTR2ZoMjm5scNATrQHcS1IP1VVJMVtM=.70676141-6535-4869-8b14-e692bad9ab6a@github.com> References: <8ZodEn2wqRkIaTR2ZoMjm5scNATrQHcS1IP1VVJMVtM=.70676141-6535-4869-8b14-e692bad9ab6a@github.com> Message-ID: <4p6MYGpIqf0vPsduIZmfN1Pf-LCqnBX-kWQBAhh40Wk=.93ae944a-996e-4328-9a18-23c2447d95fc@github.com> > Hi all, > > please review this small change that remove the public `G1CollectionSet::groups()` accessors because they are never used from outside the `G1CollectionSet` class. > > Testing: local compilation, gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Merge branch 'master' into 8365052-remove-groups-accessors - 8365052 Hi all, please review this small change that remove the public `G1CollectionSet::groups()` accessors because they are never used from outside the `G1CollectionSet` class. Testing: local compilation, gha Thanks, Thomas - * one more renaming: prepare_groups_for_scan() -> prepare_for_scan() - Merge branch '8364925-improve-program-flow-inc-cset' into 8364934-g1collectionset-renaming - * ayang review - 8364934 Hi all, please review this renaming of various members of `G1CollectionSet` to - use the same prefixes - remove unnecessary prefixes (`collection_set`) - fix some documentation Testing: gha Thanks, THoams - * remove accidentally merged in JDK-8364934 - 8364925 Hi all, please review this change that improves the G1CollectionSet incremental state handling slightly: * remove `_selected_groups_cur_length` with getter as we do not need a copy of that value around * move implementations of some methods from header files into cpp file * moved some incremental state updates from `finalize_old_part` to the respective `start/continue/stop_incremental_building` method Testing: gha Thanks, Thomas ------------- Changes: https://git.openjdk.org/jdk/pull/26688/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26688&range=02 Stats: 5 lines in 3 files changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26688.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26688/head:pull/26688 PR: https://git.openjdk.org/jdk/pull/26688 From tschatzl at openjdk.org Thu Aug 21 15:35:01 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Aug 2025 15:35:01 GMT Subject: RFR: 8365024: G1: Make G1CollectionSet::_inc_build_state assert-only [v3] In-Reply-To: References: <_sPU_ODwR_JTG506Z7lvy-7mukR-VBzJg7toKzji6qI=.3e02ed55-c6b8-4fdc-8015-e5160187d007@github.com> Message-ID: On Thu, 21 Aug 2025 15:17:07 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: >> >> - Merge branch 'master' into 8365024-inc-cset-state-assert-only >> - 8365024 >> >> Hi all, >> >> please review this change that makes the `G1CollectionSet::_inc_build_state` member debug/assert-only - it's only ever used in assertions. >> >> Testing: local compilation, gha >> >> Thanks, >> Thomas >> - 8364934 >> >> Hi all, >> >> please review this renaming of various members of `G1CollectionSet` to >> >> - use the same prefixes >> - remove unnecessary prefixes (`collection_set`) >> - fix some documentation >> >> Testing: gha >> >> Thanks, >> THoams >> - * remove accidentally merged in JDK-8364934 >> - 8364925 >> >> Hi all, >> >> please review this change that improves the G1CollectionSet incremental state handling slightly: >> >> * remove `_selected_groups_cur_length` with getter as we do not need a copy of that value around >> * move implementations of some methods from header files into cpp file >> * moved some incremental state updates from `finalize_old_part` to the respective `start/continue/stop_incremental_building` method >> >> Testing: gha >> >> Thanks, >> Thomas > > Marked as reviewed by ayang (Reviewer). Thanks @albertnetymk @kimbarrett for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/26671#issuecomment-3211113653 From tschatzl at openjdk.org Thu Aug 21 15:35:02 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Aug 2025 15:35:02 GMT Subject: Integrated: 8365024: G1: Make G1CollectionSet::_inc_build_state assert-only In-Reply-To: References: Message-ID: <6d5ujQWIO-ELQJH7qRQyO6ZBxM8maIPRlIlYN_KvHdE=.0c35f6a2-76d4-4132-a4c4-75db89aeb12d@github.com> On Thu, 7 Aug 2025 09:46:52 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that makes the `G1CollectionSet::_inc_build_state` member debug/assert-only - it's only ever used in assertions. > > Testing: local compilation, gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: cf70cb70 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/cf70cb70bcd5292ed10d8fb08019f0da82db25dd Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod 8365024: G1: Make G1CollectionSet::_inc_build_state assert-only Reviewed-by: ayang, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/26671 From tschatzl at openjdk.org Thu Aug 21 16:18:23 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Aug 2025 16:18:23 GMT Subject: RFR: 8365656: [ubsan] G1CSetCandidateGroup::liveness() reports division by 0 Message-ID: Hi all, please review this change that fixes a div-by-zero in calculating liveness for logging. It is possible that the young gen group cardset is empty when the `Cleanup` pause starts, making the liveness calculation divide by zero. The change special-cases this case when printing - I decided to always print the group in this case, regardless of length, just fudging the output value a bit. An alternative would be not printing it at all in this case. Feel free to argue for that solution. Also the printed value for liveness (0.0%) is up for discussion. Testing: failing test case does not fail any more now and then, gha Thanks, Thomas ------------- Commit messages: - 8365656 Changes: https://git.openjdk.org/jdk/pull/26888/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26888&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365656 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26888.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26888/head:pull/26888 PR: https://git.openjdk.org/jdk/pull/26888 From iwalulya at openjdk.org Thu Aug 21 17:10:55 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 21 Aug 2025 17:10:55 GMT Subject: RFR: 8365656: [ubsan] G1CSetCandidateGroup::liveness() reports division by 0 In-Reply-To: References: Message-ID: <40uXi5dV2ChF-Zc5dkXYuGpvmApIU4QlvXbCM3kGgfE=.bc6b2823-aa48-4b93-91fe-7e8f14e38889@github.com> On Thu, 21 Aug 2025 16:13:10 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that fixes a div-by-zero in calculating liveness for logging. > > It is possible that the young gen group cardset is empty when the `Cleanup` pause starts, making the liveness calculation divide by zero. > > The change special-cases this case when printing - I decided to always print the group in this case, regardless of length, just fudging the output value a bit. An alternative would be not printing it at all in this case. Feel free to argue for that solution. Also the printed value for liveness (0.0%) is up for discussion. > > Testing: failing test case does not fail any more now and then, gha > > Thanks, > Thomas Changes requested by iwalulya (Reviewer). src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 3125: > 3123: group->length(), > 3124: group->gc_efficiency(), > 3125: group->length() > 0 ? group->liveness_percent() : 0.0f, Why not move this logic into `liveness_percent()` (i.e returns 0.0f if length() == 0)? ------------- PR Review: https://git.openjdk.org/jdk/pull/26888#pullrequestreview-3141593342 PR Review Comment: https://git.openjdk.org/jdk/pull/26888#discussion_r2291667171 From tschatzl at openjdk.org Fri Aug 22 05:49:07 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 22 Aug 2025 05:49:07 GMT Subject: RFR: 8365656: [ubsan] G1CSetCandidateGroup::liveness() reports division by 0 [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that fixes a div-by-zero in calculating liveness for logging. > > It is possible that the young gen group cardset is empty (has no regions assigned to it as no eden region has retired yet) when the `Cleanup` pause starts, making the liveness calculation divide by zero. > > The change special-cases this case when printing - I decided to always print the group in this case, regardless of length, just fudging the output value a bit. An alternative would be not printing it at all in this case. Feel free to argue for that solution. Also the printed value for liveness (0.0%) is up for discussion. > > Testing: failing test case does not fail any more now and then, gha, tier1-4 > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * walulyai review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26888/files - new: https://git.openjdk.org/jdk/pull/26888/files/3c7b5d9e..6d69bb57 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26888&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26888&range=00-01 Stats: 7 lines in 2 files changed: 4 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26888.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26888/head:pull/26888 PR: https://git.openjdk.org/jdk/pull/26888 From tschatzl at openjdk.org Fri Aug 22 08:56:54 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 22 Aug 2025 08:56:54 GMT Subject: RFR: 8360540: nmethod entry barriers of new nmethods should be disarmed In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 14:55:03 GMT, Martin Doerr wrote: > Adding `disarm` calls as ZGC and ShenandoahGC already have (see JBS issue for more details). Tier1-4 tests have passed. > > I will need reviews from GC experts to check for potentially problematic side effects. > Note that `rebuild_code_roots()` disarms all nmethods during `G1FullCollector::complete_collection`, now. > > Some stats (nmethod entry barrier hits in jvm98 with/without patch): > > | GC | before | after | > | -------- | ------ | ----- | > | G1 | 3339 | 127 | > | Parallel | 3223 | 1141 | > | Serial | 3206 | 1142 | I think it is good to make the initial state uniform. Disarming during full gc is okay too - full gc will cancel any SATB activity anyway. Looks good. ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25982#pullrequestreview-3143687232 From mdoerr at openjdk.org Fri Aug 22 09:06:58 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 22 Aug 2025 09:06:58 GMT Subject: RFR: 8360540: nmethod entry barriers of new nmethods should be disarmed In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 14:55:03 GMT, Martin Doerr wrote: > Adding `disarm` calls as ZGC and ShenandoahGC already have (see JBS issue for more details). Tier1-4 tests have passed. > > I will need reviews from GC experts to check for potentially problematic side effects. > Note that `rebuild_code_roots()` disarms all nmethods during `G1FullCollector::complete_collection`, now. > > Some stats (nmethod entry barrier hits in jvm98 with/without patch): > > | GC | before | after | > | -------- | ------ | ----- | > | G1 | 3339 | 127 | > | Parallel | 3223 | 1141 | > | Serial | 3206 | 1142 | Thanks! Do we need follow-up RFEs? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25982#issuecomment-3213630663 From tschatzl at openjdk.org Fri Aug 22 09:06:59 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 22 Aug 2025 09:06:59 GMT Subject: RFR: 8360540: nmethod entry barriers of new nmethods should be disarmed In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 14:55:03 GMT, Martin Doerr wrote: > Adding `disarm` calls as ZGC and ShenandoahGC already have (see JBS issue for more details). Tier1-4 tests have passed. > > I will need reviews from GC experts to check for potentially problematic side effects. > Note that `rebuild_code_roots()` disarms all nmethods during `G1FullCollector::complete_collection`, now. > > Some stats (nmethod entry barrier hits in jvm98 with/without patch): > > | GC | before | after | > | -------- | ------ | ----- | > | G1 | 3339 | 127 | > | Parallel | 3223 | 1141 | > | Serial | 3206 | 1142 | We should probably just call `mark_as_maybe_on_stack()` in the `RebuildCodeRootClosure::do_nmethod()` to keep the hotness calculation as before. (I was too slow :) ) ------------- PR Comment: https://git.openjdk.org/jdk/pull/25982#issuecomment-3213643076 PR Comment: https://git.openjdk.org/jdk/pull/25982#issuecomment-3213643565 From mdoerr at openjdk.org Fri Aug 22 09:06:59 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 22 Aug 2025 09:06:59 GMT Subject: Integrated: 8360540: nmethod entry barriers of new nmethods should be disarmed In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 14:55:03 GMT, Martin Doerr wrote: > Adding `disarm` calls as ZGC and ShenandoahGC already have (see JBS issue for more details). Tier1-4 tests have passed. > > I will need reviews from GC experts to check for potentially problematic side effects. > Note that `rebuild_code_roots()` disarms all nmethods during `G1FullCollector::complete_collection`, now. > > Some stats (nmethod entry barrier hits in jvm98 with/without patch): > > | GC | before | after | > | -------- | ------ | ----- | > | G1 | 3339 | 127 | > | Parallel | 3223 | 1141 | > | Serial | 3206 | 1142 | This pull request has now been integrated. Changeset: e1c58f85 Author: Martin Doerr URL: https://git.openjdk.org/jdk/commit/e1c58f858a64853c2d454fd00a84455ca6700055 Stats: 9 lines in 3 files changed: 9 ins; 0 del; 0 mod 8360540: nmethod entry barriers of new nmethods should be disarmed Reviewed-by: eosterlund, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/25982 From duke at openjdk.org Fri Aug 22 09:09:58 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Fri, 22 Aug 2025 09:09:58 GMT Subject: RFR: 8365656: [ubsan] G1CSetCandidateGroup::liveness() reports division by 0 [v2] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 05:49:07 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that fixes a div-by-zero in calculating liveness for logging. >> >> It is possible that the young gen group cardset is empty (has no regions assigned to it as no eden region has retired yet) when the `Cleanup` pause starts, making the liveness calculation divide by zero. >> >> The change special-cases this case when printing - I decided to always print the group in this case, regardless of length, just fudging the output value a bit. An alternative would be not printing it at all in this case. Feel free to argue for that solution. Also the printed value for liveness (0.0%) is up for discussion. >> >> Testing: failing test case does not fail any more now and then, gha, tier1-4 >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * walulyai review src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 3165: > 3163: G1CollectedHeap* g1h = G1CollectedHeap::heap(); > 3164: > 3165: if (g1h->young_regions_cset_group()->length() != 0) { Would it make sense to have this check inside `log_cset_candidate_group_add_total` instead? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26888#discussion_r2293160889 From tschatzl at openjdk.org Fri Aug 22 09:13:59 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 22 Aug 2025 09:13:59 GMT Subject: RFR: 8360540: nmethod entry barriers of new nmethods should be disarmed In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 14:55:03 GMT, Martin Doerr wrote: > Adding `disarm` calls as ZGC and ShenandoahGC already have (see JBS issue for more details). Tier1-4 tests have passed. > > I will need reviews from GC experts to check for potentially problematic side effects. > Note that `rebuild_code_roots()` disarms all nmethods during `G1FullCollector::complete_collection`, now. > > Some stats (nmethod entry barrier hits in jvm98 with/without patch): > > | GC | before | after | > | -------- | ------ | ----- | > | G1 | 3339 | 127 | > | Parallel | 3223 | 1141 | > | Serial | 3206 | 1142 | Filed https://bugs.openjdk.org/browse/JDK-8365976, working on it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25982#issuecomment-3213664251 From tschatzl at openjdk.org Fri Aug 22 10:07:56 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 22 Aug 2025 10:07:56 GMT Subject: RFR: 8360540: nmethod entry barriers of new nmethods should be disarmed In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 14:55:03 GMT, Martin Doerr wrote: > Adding `disarm` calls as ZGC and ShenandoahGC already have (see JBS issue for more details). Tier1-4 tests have passed. > > I will need reviews from GC experts to check for potentially problematic side effects. > Note that `rebuild_code_roots()` disarms all nmethods during `G1FullCollector::complete_collection`, now. > > Some stats (nmethod entry barrier hits in jvm98 with/without patch): > > | GC | before | after | > | -------- | ------ | ----- | > | G1 | 3339 | 127 | > | Parallel | 3223 | 1141 | > | Serial | 3206 | 1142 | Actually there is already a call at end of G1 full GC to arm all (remaining) nmethods, in `G1FullCollector::collect()`, ` G1CollectedHeap::finish_codecache_marking_cycle()`does that. So everything should be fine already. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25982#issuecomment-3213819414 From tschatzl at openjdk.org Fri Aug 22 10:13:07 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 22 Aug 2025 10:13:07 GMT Subject: RFR: 8365656: [ubsan] G1CSetCandidateGroup::liveness() reports division by 0 [v3] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that fixes a div-by-zero in calculating liveness for logging. > > It is possible that the young gen group cardset is empty (has no regions assigned to it as no eden region has retired yet) when the `Cleanup` pause starts, making the liveness calculation divide by zero. > > The change special-cases this case when printing - I decided to always print the group in this case, regardless of length, just fudging the output value a bit. An alternative would be not printing it at all in this case. Feel free to argue for that solution. Also the printed value for liveness (0.0%) is up for discussion. > > Testing: failing test case does not fail any more now and then, gha, tier1-4 > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * fandreuz review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26888/files - new: https://git.openjdk.org/jdk/pull/26888/files/6d69bb57..496d9bb4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26888&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26888&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26888.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26888/head:pull/26888 PR: https://git.openjdk.org/jdk/pull/26888 From tschatzl at openjdk.org Fri Aug 22 10:21:52 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 22 Aug 2025 10:21:52 GMT Subject: RFR: 8365656: [ubsan] G1CSetCandidateGroup::liveness() reports division by 0 [v2] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 09:07:31 GMT, Francesco Andreuzzi wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * walulyai review > > src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 3165: > >> 3163: G1CollectedHeap* g1h = G1CollectedHeap::heap(); >> 3164: >> 3165: if (g1h->young_regions_cset_group()->length() != 0) { > > Would it make sense to have this check inside `log_cset_candidate_group_add_total` instead? Actually this hunk has been committed wrongly, as I did some testing, but thanks for the discussion: I am fairly unsure where to best put that check - for a card group with a length of 0 the liveness does not make sense, but since it is that special young card group does exist and always takes some memory, printing it is useful. We want its memory usage to show up in the total memory consumption too. Adding this check in `log_cset_candidate_group_add_total` to (as far as I can guess from your suggestion) just not print the log line for this is also confusing: total memory consumption will be != 0, but no separate line for that card group printed... - So the initial change that @walulyai did not like put that check into the argument of the log processing, so it would print the line, and we would have an assert in `liveness_percent()` to not try to get that value for such card groups otherwise. Thoughts? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26888#discussion_r2293327982 From tschatzl at openjdk.org Fri Aug 22 10:28:52 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 22 Aug 2025 10:28:52 GMT Subject: RFR: 8365656: [ubsan] G1CSetCandidateGroup::liveness() reports division by 0 [v2] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 10:18:56 GMT, Thomas Schatzl wrote: >> src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 3165: >> >>> 3163: G1CollectedHeap* g1h = G1CollectedHeap::heap(); >>> 3164: >>> 3165: if (g1h->young_regions_cset_group()->length() != 0) { >> >> Would it make sense to have this check inside `log_cset_candidate_group_add_total` instead? > > Actually this hunk has been committed wrongly, as I did some testing, but thanks for the discussion: > > I am fairly unsure where to best put that check > > - for a card group with a length of 0 the liveness does not make sense, but since it is that special young card group does exist and always takes some memory, printing it is useful. > > We want its memory usage to show up in the total memory consumption too. > > Adding this check in `log_cset_candidate_group_add_total` to (as far as I can guess from your suggestion) just not print the log line for this is also confusing: total memory consumption will be != 0, but no separate line for that card group printed... > > - So the initial change that @walulyai did not like put that check into the argument of the log processing, so it would print the line, and we would have an assert in `liveness_percent()` to not try to get that value for such card groups otherwise. > > Thoughts? since it's "just" logging anyway @walulyai's suggestion is maybe easiest and acceptable . ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26888#discussion_r2293350379 From jsikstro at openjdk.org Fri Aug 22 10:34:34 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Fri, 22 Aug 2025 10:34:34 GMT Subject: RFR: 8359683: ZGC: NUMA-Aware Relocation Message-ID: <_SnXFrT1StlCj4JYdTfY-S6tPa6dsi-p6VfMl01te7k=.1cabcd48-3709-4b3c-9ea8-3fc122c505fe@github.com> Hello, With [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441), ZGC got infrastructure to prefer allocations to end up on a specific NUMA node. When a new object is allocated, it is preferably placed on the NUMA node that is local to the allocating thread. This strategy improves access speeds for mutators working on that object, if it continues to be used by threads on the same NUMA node. However, when relocating objects, ZGC will potentially move (migrate) objects away from the NUMA node they were originally allocated on. This means that if a page is selected as part of the Relocation Set, the objects on that page could potentially be moved to another NUMA node, breaking the NUMA locality we strived for when allocating. We should consider adding NUMA-awareness to ZGC's relocation phase to keep NUMA-locality benefits for mutators.
Proposal (expandable section) NUMA-Awareness consists of two main features: **First**: GC threads should strive toward keeping the NUMA locality of objects to their original node, meaning that objects should ideally be relocated to a page that is on the same NUMA node. Mutator threads should have a different approach, as we know that the mutator that's (helping out with) relocating an object is also going to access it, so we migrate the object to the NUMA node associated with the relocating thread. This strategy is already in effect and does not require any changes to the code (specifically, ZObjectAllocator already track per-CPU specific Small pages). However, Medium pages are shared between CPUs and thus does not hold any guarantees on which NUMA node it is on. Combined, both mutator and Medium page relocation are not common, and thus there is little gain from introducing NUMA-awareness to that specific scenario. Instead, this can be addressed in a follow-up if we feel that's necessary. **Second**: When the GC chooses a page from the Relocation Set to relocate objects from, it should choose page(s) that are local to the same NUMA node, to speed up performance by working on NUMA-local memory. There are multiple ways to achieve this, but the main goal should be to (1) start working on pages that are local to the GC thread's NUMA node, and (2) when finished with pages on its own NUMA node, start working (help out) with pages associated with other NUMA nodes. Some key observations to consider with the above approach: * The NUMA node associated with the GC thread should be "polled"/"checked" in regular intervals, to account for the fact that the GC thread might have migrated to another CPU, and thus perhaps to another NUMA node. It is probably enough to check the associated NUMA node before claiming a new page and starting to relocate objects. * By choosing pages based on NUMA-node association rather than live bytes, we might not start with the most sparse page first. This is really only a problem if the machine is fully saturated and there are allocation stalls. Additionally, it is worth considering that in a common NUMA configuration, it takes twice as long to access remote memory compared to local memory. This means that a local page could (theoretically) be relocated twice as fast as a remote page, which could release memory faster than starting with the most sparse page, if that page is on a remote node. * The new strategy is more of an optimization for mutators and might make the GC take a bit longer to complete the relocation phase. The current strategy is to move objects to the NUMA node associated with the GC thread, regardless of where the object was originally from. This makes the GC fast, at the potential downside of mutators not accessing local memory any more. However, since ZGC is a concurrent garbage collector, it isn't really a huge issue if the relocation phase becomes a bit longer, if the mutators receive a speedup. * Depending on the distribution of what NUMA node GC threads end up on, we might see a negative impact on performance. This hasn't changed before or after this proposal, but with NUMA-awareness implemented, it would be possible to explore future enhancements where threads are placed on a core associated with a particular NUMA-node so that threads can work on NUMA-local memory more often. * To make the logic of this patch easier, multi-partition allocations for Medium pages has been disabled. After [JDK-8357449](https://bugs.openjdk.org/browse/JDK-8357449), which enables variable sizes for Medium pages all the way down to 4MB, there is little gain in enabling multi-partition for Medium pages. If a Medium page allocation would only succeed with multi-partition enabled, we do not have 4MB contiguous memory available, which would only happen if memory is extremely low or if the heap is degeneratively swiss-cheesed into 2MB chunks.
## Testing * tier1-8 ZGC tasks only, on all Oracle supported platforms, without NUMA * tier1-8 with -XX:ZFakeNUMA=16 on linux-x64-debug * tier1-3 with NUMA on linux-x64-debug Performance testing shows no regression when NUMA is disabled or not available. Testing before/after the patch shows that GC thread's relocating objects from/to NUMA-local pages has gone from about 50% up to 95%. This depends very much on the distribution of threads placed on specific NUMA-nodes, but this shows the new strategy works as intended. There is no apparent speedup or slowdown in the time it takes to complete the Relocation Phase with NUMA enabled. This could very well be due to the change in the strategy of choosing the destination NUMA node. Before we would always relocate an object to the NUMA node that is local to the GC thread. Now, we maintain the NUMA-locality when relocating, which means that if we relocate an object on a remote NUMA node, we will get worse performance as both the source and target destination is on a remote NUMA node. ------------- Commit messages: - 8359683: ZGC: NUMA-Aware Relocation Changes: https://git.openjdk.org/jdk/pull/26898/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26898&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359683 Stats: 246 lines in 15 files changed: 151 ins; 19 del; 76 mod Patch: https://git.openjdk.org/jdk/pull/26898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26898/head:pull/26898 PR: https://git.openjdk.org/jdk/pull/26898 From jsikstro at openjdk.org Fri Aug 22 10:40:56 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Fri, 22 Aug 2025 10:40:56 GMT Subject: RFR: 8359683: ZGC: NUMA-Aware Relocation In-Reply-To: <_SnXFrT1StlCj4JYdTfY-S6tPa6dsi-p6VfMl01te7k=.1cabcd48-3709-4b3c-9ea8-3fc122c505fe@github.com> References: <_SnXFrT1StlCj4JYdTfY-S6tPa6dsi-p6VfMl01te7k=.1cabcd48-3709-4b3c-9ea8-3fc122c505fe@github.com> Message-ID: On Fri, 22 Aug 2025 10:28:01 GMT, Joel Sikstr?m wrote: > Hello, > > With [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441), ZGC got infrastructure to prefer allocations to end up on a specific NUMA node. When a new object is allocated, it is preferably placed on the NUMA node that is local to the allocating thread. This strategy improves access speeds for mutators working on that object, if it continues to be used by threads on the same NUMA node. However, when relocating objects, ZGC will potentially move (migrate) objects away from the NUMA node they were originally allocated on. This means that if a page is selected as part of the Relocation Set, the objects on that page could potentially be moved to another NUMA node, breaking the NUMA locality we strived for when allocating. > > We should consider adding NUMA-awareness to ZGC's relocation phase to keep NUMA-locality benefits for mutators. > >
> > Proposal (expandable section) > > NUMA-Awareness consists of two main features: > > **First**: GC threads should strive toward keeping the NUMA locality of objects to their original node, meaning that objects should ideally be relocated to a page that is on the same NUMA node. > > Mutator threads should have a different approach, as we know that the mutator that's (helping out with) relocating an object is also going to access it, so we migrate the object to the NUMA node associated with the relocating thread. This strategy is already in effect and does not require any changes to the code (specifically, ZObjectAllocator already track per-CPU specific Small pages). However, Medium pages are shared between CPUs and thus does not hold any guarantees on which NUMA node it is on. Combined, both mutator and Medium page relocation are not common, and thus there is little gain from introducing NUMA-awareness to that specific scenario. Instead, this can be addressed in a follow-up if we feel that's necessary. > > **Second**: When the GC chooses a page from the Relocation Set to relocate objects from, it should choose page(s) that are local to the same NUMA node, to speed up performance by working on NUMA-local memory. There are multiple ways to achieve this, but the main goal should be to (1) start working on pages that are local to the GC thread's NUMA node, and (2) when finished with pages on its own NUMA node, start working (help out) with pages associated with other NUMA nodes. > > Some key observations to consider with the above approach: > > * The NUMA node associated with the GC thread should be "polle... src/hotspot/share/gc/z/zRelocate.hpp line 85: > 83: > 84: ZWorkers* workers() const; > 85: void work(ZRelocationSetParallelIterator* iter); This is dead code since [JDK-8256390](https://bugs.openjdk.org/browse/JDK-8256390), commit https://github.com/openjdk/jdk/commit/372595cca371610bac451098807a52d08e10d21e. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26898#discussion_r2293375615 From tschatzl at openjdk.org Fri Aug 22 11:05:01 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 22 Aug 2025 11:05:01 GMT Subject: RFR: 8365976: G1: Full gc should mark nmethods on stack Message-ID: Hi all, please review this fix that moves the nmethod arming after registering the nmethods during full gc to make sure that the remaining ones are armed. That changed after [JDK-8360540](https://bugs.openjdk.org/browse/JDK-8360540). Testing: gha Thanks, Thomas ------------- Commit messages: - 8365976 Changes: https://git.openjdk.org/jdk/pull/26899/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26899&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365976 Stats: 3 lines in 2 files changed: 1 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26899.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26899/head:pull/26899 PR: https://git.openjdk.org/jdk/pull/26899 From tschatzl at openjdk.org Fri Aug 22 11:08:27 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 22 Aug 2025 11:08:27 GMT Subject: RFR: 8342382: Implementation of JEP G1: Improve Application Throughput with a More Efficient Write-Barrier [v48] 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 65 commits: - 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 - Merge branch 'master' into pull/23739 - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - ... and 55 more: https://git.openjdk.org/jdk/compare/e1c58f85...6c88f1de ------------- Changes: https://git.openjdk.org/jdk/pull/23739/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=47 Stats: 7111 lines in 112 files changed: 2587 ins; 3587 del; 937 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From ayang at openjdk.org Fri Aug 22 11:09:04 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 22 Aug 2025 11:09:04 GMT Subject: RFR: 8365976: G1: Full gc should mark nmethods on stack In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 10:59:38 GMT, Thomas Schatzl wrote: > Hi all, > > please review this fix that moves the nmethod arming after registering the nmethods during full gc to make sure that the remaining ones are armed. That changed after [JDK-8360540](https://bugs.openjdk.org/browse/JDK-8360540). > > Testing: gha > > Thanks, > Thomas Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26899#pullrequestreview-3144084259 From ayang at openjdk.org Fri Aug 22 11:09:11 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 22 Aug 2025 11:09:11 GMT Subject: RFR: 8365656: [ubsan] G1CSetCandidateGroup::liveness() reports division by 0 [v3] In-Reply-To: <40uXi5dV2ChF-Zc5dkXYuGpvmApIU4QlvXbCM3kGgfE=.bc6b2823-aa48-4b93-91fe-7e8f14e38889@github.com> References: <40uXi5dV2ChF-Zc5dkXYuGpvmApIU4QlvXbCM3kGgfE=.bc6b2823-aa48-4b93-91fe-7e8f14e38889@github.com> Message-ID: On Thu, 21 Aug 2025 17:07:26 GMT, Ivan Walulya wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * fandreuz review > > src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 3125: > >> 3123: group->length(), >> 3124: group->gc_efficiency(), >> 3125: group->length() > 0 ? group->liveness_percent() : 0.0f, > > Why not move this logic into `liveness_percent()` (i.e returns 0.0f if length() == 0)? I actually think the zero-length checking should be done at the caller -- it's meaningless to ask `liveness_percent` on a zero-length group. Looking at neighboring code, does `gc_efficiency` have a sensible meaning for a zero-length group? Callees should have non-zero-length as precondition. Therefore, I suggest reorder the print a bit so that length-sensitive queries comes after `group->length()`, sth like: type group->card_set()->mem_size(), group->length(), group->length() > 0 ? group->gc_efficiency(), 0, group->length() > 0 ? group->liveness_percent(), 0); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26888#discussion_r2293427961 From iwalulya at openjdk.org Fri Aug 22 11:17:51 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Fri, 22 Aug 2025 11:17:51 GMT Subject: RFR: 8365656: [ubsan] G1CSetCandidateGroup::liveness() reports division by 0 [v3] In-Reply-To: References: <40uXi5dV2ChF-Zc5dkXYuGpvmApIU4QlvXbCM3kGgfE=.bc6b2823-aa48-4b93-91fe-7e8f14e38889@github.com> Message-ID: On Fri, 22 Aug 2025 11:05:58 GMT, Albert Mingkun Yang wrote: >> src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 3125: >> >>> 3123: group->length(), >>> 3124: group->gc_efficiency(), >>> 3125: group->length() > 0 ? group->liveness_percent() : 0.0f, >> >> Why not move this logic into `liveness_percent()` (i.e returns 0.0f if length() == 0)? > > I actually think the zero-length checking should be done at the caller -- it's meaningless to ask `liveness_percent` on a zero-length group. Looking at neighboring code, does `gc_efficiency` have a sensible meaning for a zero-length group? Callees should have non-zero-length as precondition. > > Therefore, I suggest reorder the print a bit so that length-sensitive queries comes after `group->length()`, sth like: > > > type > group->card_set()->mem_size(), > group->length(), > group->length() > 0 ? group->gc_efficiency(), 0, > group->length() > 0 ? group->liveness_percent(), 0); I disagree, why should the caller know that the public method is subject to crashes if called with length() == 0? Eventually, one will use `liveness_percent()` without this guard. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26888#discussion_r2293445720 From tschatzl at openjdk.org Fri Aug 22 11:41:27 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 22 Aug 2025 11:41:27 GMT Subject: RFR: 8342382: Implementation of JEP G1: Improve Application Throughput with a More Efficient Write-Barrier [v49] In-Reply-To: References: Message-ID: <8ed2PRthKJNDf-El4SVUWmu-FZm311FTDmgr7mcokaI=.9f9a74ee-3306-474a-8eb4-8c6b4bd3db70@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: * forgot to actually save the files ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23739/files - new: https://git.openjdk.org/jdk/pull/23739/files/6c88f1de..e8a8282b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=48 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=47-48 Stats: 6 lines in 1 file changed: 0 ins; 6 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 iwalulya at openjdk.org Fri Aug 22 11:49:52 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Fri, 22 Aug 2025 11:49:52 GMT Subject: RFR: 8365656: [ubsan] G1CSetCandidateGroup::liveness() reports division by 0 [v3] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 10:13:07 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that fixes a div-by-zero in calculating liveness for logging. >> >> It is possible that the young gen group cardset is empty (has no regions assigned to it as no eden region has retired yet) when the `Cleanup` pause starts, making the liveness calculation divide by zero. >> >> The change special-cases this case when printing - I decided to always print the group in this case, regardless of length, just fudging the output value a bit. An alternative would be not printing it at all in this case. Feel free to argue for that solution. Also the printed value for liveness (0.0%) is up for discussion. >> >> Testing: failing test case does not fail any more now and then, gha, tier1-4 >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * fandreuz review Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26888#pullrequestreview-3144196388 From ayang at openjdk.org Fri Aug 22 12:24:50 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 22 Aug 2025 12:24:50 GMT Subject: RFR: 8365656: [ubsan] G1CSetCandidateGroup::liveness() reports division by 0 [v3] In-Reply-To: References: <40uXi5dV2ChF-Zc5dkXYuGpvmApIU4QlvXbCM3kGgfE=.bc6b2823-aa48-4b93-91fe-7e8f14e38889@github.com> Message-ID: On Fri, 22 Aug 2025 11:15:16 GMT, Ivan Walulya wrote: >> I actually think the zero-length checking should be done at the caller -- it's meaningless to ask `liveness_percent` on a zero-length group. Looking at neighboring code, does `gc_efficiency` have a sensible meaning for a zero-length group? Callees should have non-zero-length as precondition. >> >> Therefore, I suggest reorder the print a bit so that length-sensitive queries comes after `group->length()`, sth like: >> >> >> type >> group->card_set()->mem_size(), >> group->length(), >> group->length() > 0 ? group->gc_efficiency(), 0, >> group->length() > 0 ? group->liveness_percent(), 0); > > I disagree, why should the caller know that the public method is subject to crashes if called with length() == 0? Eventually, one will use `liveness_percent()` without this guard. Because this method doesn't have a sensible meaning for zero-length groups. Here we are printing `0` as a pragmatic solution, but maybe `N/A` can be more pedantic in this context. In other contexts, I think it's beneficial to catch such misuse, hence the suggestion of precondition. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26888#discussion_r2293582612 From iwalulya at openjdk.org Fri Aug 22 15:16:56 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Fri, 22 Aug 2025 15:16:56 GMT Subject: RFR: 8365040: G1: Remove sorting at end of collection set selection [v3] In-Reply-To: References: Message-ID: On Thu, 21 Aug 2025 15:27:00 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change to remove some unnecessary sorting of the collection set introduced in https://bugs.openjdk.org/browse/JDK-8165313, and made unnecessary in https://bugs.openjdk.org/browse/JDK-8165443 (all JDK 9 :)). >> >> Testing: test case in CRs, see CR for test results, gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Merge branch 'master' into 8365040-remove-collection-set-sorting > - 8365040 > > Hi all, > > please review this change to remove some unnecessary sorting of the collection set introduced in https://bugs.openjdk.org/browse/JDK-8165313, and made unnecessary in https://bugs.openjdk.org/browse/JDK-8165443 (all JDK 9 :)). > > Testing: test case in CRs, gha > > Thanks, > Thomas > - 8364934 > > Hi all, > > please review this renaming of various members of `G1CollectionSet` to > > - use the same prefixes > - remove unnecessary prefixes (`collection_set`) > - fix some documentation > > Testing: gha > > Thanks, > THoams > - * remove accidentally merged in JDK-8364934 > - 8364925 > > Hi all, > > please review this change that improves the G1CollectionSet incremental state handling slightly: > > * remove `_selected_groups_cur_length` with getter as we do not need a copy of that value around > * move implementations of some methods from header files into cpp file > * moved some incremental state updates from `finalize_old_part` to the respective `start/continue/stop_incremental_building` method > > Testing: gha > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26676#pullrequestreview-3144898963 From jsikstro at openjdk.org Fri Aug 22 15:17:08 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Fri, 22 Aug 2025 15:17:08 GMT Subject: RFR: 8365994: ZGC: Incorrect type signature in ZMappedCache comparator Message-ID: <_nBhAdONXQ_QsOXGW1pwBiu4nb_pCS_wcp57lyNXMXA=.4c7e21f1-45e2-420c-8919-989a20622d57@github.com> Hello, The comparator with two IntrusiveRBNode* in ZMappedCache has the incorrent type signature. This prevents IntrusiveRBTree from using the comparator as intended during validation, resulting in it using the fallback verify function, which always returns true. This could mask potential issues in the tree structure. Testing: * Manually placing an assert in the fallback verify function to see if it is used. It is no longer used with this patch. * Oracle's tier 1-2 ------------- Commit messages: - 8365994: ZGC: Incorrect type signature in ZMappedCache comparator Changes: https://git.openjdk.org/jdk/pull/26904/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26904&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365994 Stats: 8 lines in 2 files changed: 0 ins; 3 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/26904.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26904/head:pull/26904 PR: https://git.openjdk.org/jdk/pull/26904 From cnorrbin at openjdk.org Fri Aug 22 15:17:08 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Fri, 22 Aug 2025 15:17:08 GMT Subject: RFR: 8365994: ZGC: Incorrect type signature in ZMappedCache comparator In-Reply-To: <_nBhAdONXQ_QsOXGW1pwBiu4nb_pCS_wcp57lyNXMXA=.4c7e21f1-45e2-420c-8919-989a20622d57@github.com> References: <_nBhAdONXQ_QsOXGW1pwBiu4nb_pCS_wcp57lyNXMXA=.4c7e21f1-45e2-420c-8919-989a20622d57@github.com> Message-ID: On Fri, 22 Aug 2025 15:08:42 GMT, Joel Sikstr?m wrote: > Hello, > > The comparator with two IntrusiveRBNode* in ZMappedCache has the incorrent type signature. This prevents IntrusiveRBTree from using the comparator as intended during validation, resulting in it using the fallback verify function, which always returns true. This could mask potential issues in the tree structure. > > Testing: > * Manually placing an assert in the fallback verify function to see if it is used. It is no longer used with this patch. > * Oracle's tier 1-2 Looks good! ------------- Marked as reviewed by cnorrbin (Committer). PR Review: https://git.openjdk.org/jdk/pull/26904#pullrequestreview-3144896111 From iwalulya at openjdk.org Fri Aug 22 15:17:52 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Fri, 22 Aug 2025 15:17:52 GMT Subject: RFR: 8365976: G1: Full gc should mark nmethods on stack In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 10:59:38 GMT, Thomas Schatzl wrote: > Hi all, > > please review this fix that moves the nmethod arming after registering the nmethods during full gc to make sure that the remaining ones are armed. That changed after [JDK-8360540](https://bugs.openjdk.org/browse/JDK-8360540). > > Testing: gha > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26899#pullrequestreview-3144903249 From iwalulya at openjdk.org Fri Aug 22 15:41:55 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Fri, 22 Aug 2025 15:41:55 GMT Subject: RFR: 8365034: G1: Remove num_groups_selected in G1CollectionSet::select_candidates_from_optional_groups as it is unnecessary [v3] In-Reply-To: References: Message-ID: On Thu, 21 Aug 2025 15:19:11 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this removal of the local `num_selected_regions` from `G1CollectionSet::select_candidates_from_optional_groups()` - the same information is maintained within the local `selected_groups` list. >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Merge branch 'master' into 8365034-remove-unnecessary-num_selected_regions > - * ayang review > - Merge branch '8364934-g1collectionset-renaming' into 8365034-remove-unnecessary-num_selected_regions > - Merge branch 'master' into 8364934-g1collectionset-renaming > - Merge branch 'master' into 8364934-g1collectionset-renaming > - * one more renaming: prepare_groups_for_scan() -> prepare_for_scan() > - Merge branch '8364925-improve-program-flow-inc-cset' into 8364934-g1collectionset-renaming > - * ayang review > - 8365034 > > Hi all, > > please review this removal of the local `num_selected_regions` from `G1CollectionSet::select_candidates_from_optional_groups()` - the same information is maintained within the local `selected_groups` list. > > Testing: gha > > Thanks, > Thomas > - 8364934 > > Hi all, > > please review this renaming of various members of `G1CollectionSet` to > > - use the same prefixes > - remove unnecessary prefixes (`collection_set`) > - fix some documentation > > Testing: gha > > Thanks, > THoams > - ... and 2 more: https://git.openjdk.org/jdk/compare/fb651fd6...131c4d63 Nits that will be cleared with merging. src/hotspot/share/gc/g1/g1CollectionSet.cpp line 350: > 348: return static_cast(a-b); > 349: } > 350: Should not be in this PR src/hotspot/share/gc/g1/g1CollectionSet.cpp line 691: > 689: > 690: stop_incremental_building(); > 691: QuickSort::sort(_regions, _regions_cur_length, compare_region_idx); Should not be in this PR ------------- Marked as reviewed by iwalulya (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26674#pullrequestreview-3144978340 PR Review Comment: https://git.openjdk.org/jdk/pull/26674#discussion_r2294072917 PR Review Comment: https://git.openjdk.org/jdk/pull/26674#discussion_r2294072357 From tschatzl at openjdk.org Fri Aug 22 15:50:07 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 22 Aug 2025 15:50:07 GMT Subject: RFR: 8365034: G1: Remove num_groups_selected in G1CollectionSet::select_candidates_from_optional_groups as it is unnecessary [v4] In-Reply-To: References: Message-ID: <5n0cnM0ddru6XMl7AVhFmWQFVnSvBwJqS6bD8JtpYpI=.bccb65aa-f93c-487e-bfd4-3f1d5b6fb918@github.com> > Hi all, > > please review this removal of the local `num_selected_regions` from `G1CollectionSet::select_candidates_from_optional_groups()` - the same information is maintained within the local `selected_groups` list. > > Testing: gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - * remove unwanted chagnes - Merge branch 'master' into 8365034-remove-unnecessary-num_selected_regions - Merge branch 'master' into 8365034-remove-unnecessary-num_selected_regions - * ayang review - Merge branch '8364934-g1collectionset-renaming' into 8365034-remove-unnecessary-num_selected_regions - Merge branch 'master' into 8364934-g1collectionset-renaming - Merge branch 'master' into 8364934-g1collectionset-renaming - * one more renaming: prepare_groups_for_scan() -> prepare_for_scan() - Merge branch '8364925-improve-program-flow-inc-cset' into 8364934-g1collectionset-renaming - * ayang review - ... and 4 more: https://git.openjdk.org/jdk/compare/e1c58f85...b9a66b12 ------------- Changes: https://git.openjdk.org/jdk/pull/26674/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26674&range=03 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26674.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26674/head:pull/26674 PR: https://git.openjdk.org/jdk/pull/26674 From tschatzl at openjdk.org Fri Aug 22 15:51:07 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 22 Aug 2025 15:51:07 GMT Subject: RFR: 8365052: G1: Remove G1CollectionSet::groups() accessors [v4] In-Reply-To: <8ZodEn2wqRkIaTR2ZoMjm5scNATrQHcS1IP1VVJMVtM=.70676141-6535-4869-8b14-e692bad9ab6a@github.com> References: <8ZodEn2wqRkIaTR2ZoMjm5scNATrQHcS1IP1VVJMVtM=.70676141-6535-4869-8b14-e692bad9ab6a@github.com> Message-ID: > Hi all, > > please review this small change that remove the public `G1CollectionSet::groups()` accessors because they are never used from outside the `G1CollectionSet` class. > > Testing: local compilation, gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: - Merge branch 'master' into 8365052-remove-groups-accessors - Merge branch 'master' into 8365052-remove-groups-accessors - 8365052 Hi all, please review this small change that remove the public `G1CollectionSet::groups()` accessors because they are never used from outside the `G1CollectionSet` class. Testing: local compilation, gha Thanks, Thomas - * one more renaming: prepare_groups_for_scan() -> prepare_for_scan() - Merge branch '8364925-improve-program-flow-inc-cset' into 8364934-g1collectionset-renaming - * ayang review - 8364934 Hi all, please review this renaming of various members of `G1CollectionSet` to - use the same prefixes - remove unnecessary prefixes (`collection_set`) - fix some documentation Testing: gha Thanks, THoams - * remove accidentally merged in JDK-8364934 - 8364925 Hi all, please review this change that improves the G1CollectionSet incremental state handling slightly: * remove `_selected_groups_cur_length` with getter as we do not need a copy of that value around * move implementations of some methods from header files into cpp file * moved some incremental state updates from `finalize_old_part` to the respective `start/continue/stop_incremental_building` method Testing: gha Thanks, Thomas ------------- Changes: https://git.openjdk.org/jdk/pull/26688/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26688&range=03 Stats: 5 lines in 3 files changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26688.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26688/head:pull/26688 PR: https://git.openjdk.org/jdk/pull/26688 From tschatzl at openjdk.org Fri Aug 22 15:52:18 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 22 Aug 2025 15:52:18 GMT Subject: RFR: 8365040: G1: Remove sorting at end of collection set selection [v4] In-Reply-To: References: Message-ID: <4oHim4qYGUyuuPx5qgWrhJ_r-uyGa2dq5IOzaCQceQw=.1870d772-aa70-455c-996d-7d49dcf0e513@github.com> > Hi all, > > please review this change to remove some unnecessary sorting of the collection set introduced in https://bugs.openjdk.org/browse/JDK-8165313, and made unnecessary in https://bugs.openjdk.org/browse/JDK-8165443 (all JDK 9 :)). > > Testing: test case in CRs, see CR for test results, gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge branch 'master' into 8365040-remove-collection-set-sorting - Merge branch 'master' into 8365040-remove-collection-set-sorting - 8365040 Hi all, please review this change to remove some unnecessary sorting of the collection set introduced in https://bugs.openjdk.org/browse/JDK-8165313, and made unnecessary in https://bugs.openjdk.org/browse/JDK-8165443 (all JDK 9 :)). Testing: test case in CRs, gha Thanks, Thomas - 8364934 Hi all, please review this renaming of various members of `G1CollectionSet` to - use the same prefixes - remove unnecessary prefixes (`collection_set`) - fix some documentation Testing: gha Thanks, THoams - * remove accidentally merged in JDK-8364934 - 8364925 Hi all, please review this change that improves the G1CollectionSet incremental state handling slightly: * remove `_selected_groups_cur_length` with getter as we do not need a copy of that value around * move implementations of some methods from header files into cpp file * moved some incremental state updates from `finalize_old_part` to the respective `start/continue/stop_incremental_building` method Testing: gha Thanks, Thomas ------------- Changes: https://git.openjdk.org/jdk/pull/26676/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26676&range=03 Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26676.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26676/head:pull/26676 PR: https://git.openjdk.org/jdk/pull/26676 From tschatzl at openjdk.org Fri Aug 22 16:01:26 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 22 Aug 2025 16:01:26 GMT Subject: RFR: 8342382: Implementation of JEP G1: Improve Application Throughput with a More Efficient Write-Barrier [v50] 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: * fix merge error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23739/files - new: https://git.openjdk.org/jdk/pull/23739/files/e8a8282b..cc4b7a0c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=49 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=48-49 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From ayang at openjdk.org Fri Aug 22 16:15:03 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 22 Aug 2025 16:15:03 GMT Subject: RFR: 8365034: G1: Remove num_groups_selected in G1CollectionSet::select_candidates_from_optional_groups as it is unnecessary [v4] In-Reply-To: <5n0cnM0ddru6XMl7AVhFmWQFVnSvBwJqS6bD8JtpYpI=.bccb65aa-f93c-487e-bfd4-3f1d5b6fb918@github.com> References: <5n0cnM0ddru6XMl7AVhFmWQFVnSvBwJqS6bD8JtpYpI=.bccb65aa-f93c-487e-bfd4-3f1d5b6fb918@github.com> Message-ID: On Fri, 22 Aug 2025 15:50:07 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this removal of the local `num_selected_regions` from `G1CollectionSet::select_candidates_from_optional_groups()` - the same information is maintained within the local `selected_groups` list. >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - * remove unwanted chagnes > - Merge branch 'master' into 8365034-remove-unnecessary-num_selected_regions > - Merge branch 'master' into 8365034-remove-unnecessary-num_selected_regions > - * ayang review > - Merge branch '8364934-g1collectionset-renaming' into 8365034-remove-unnecessary-num_selected_regions > - Merge branch 'master' into 8364934-g1collectionset-renaming > - Merge branch 'master' into 8364934-g1collectionset-renaming > - * one more renaming: prepare_groups_for_scan() -> prepare_for_scan() > - Merge branch '8364925-improve-program-flow-inc-cset' into 8364934-g1collectionset-renaming > - * ayang review > - ... and 4 more: https://git.openjdk.org/jdk/compare/e1c58f85...b9a66b12 Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26674#pullrequestreview-3145076114 From phh at openjdk.org Fri Aug 22 17:08:50 2025 From: phh at openjdk.org (Paul Hohensee) Date: Fri, 22 Aug 2025 17:08:50 GMT Subject: RFR: 8365922: Parallel: Group uses of GCTimeRatio to a single location In-Reply-To: References: Message-ID: <0eHrXBNDuljRnuGVTl8qWBC4LwB_4TPl8BhcH0LBaMY=.441a4c61-9a42-4405-9dc1-2508fc16663b@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 Marked as reviewed by phh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26881#pullrequestreview-3145207111 From phh at openjdk.org Fri Aug 22 17:22:55 2025 From: phh at openjdk.org (Paul Hohensee) Date: Fri, 22 Aug 2025 17:22:55 GMT Subject: RFR: 8365919: Replace currentTimeMillis with nanoTime in Stresser.java In-Reply-To: References: Message-ID: On Thu, 21 Aug 2025 10:02:12 GMT, Albert Mingkun Yang wrote: > Mostly a mechanic change from `currentTimeMillis()` to `nanoTime()/1000000`. It also removes `finishTime` to avoid overflowing. > > The change in `iteration()` is to ensure `currentTime` is properly initialized. > > (Was investigating a timeout on Windows-x64, which led me to this code. I think this fix is good enough by its own.) > > Test: tier1-5 You might want to load (options.getTime() * 1000) into a local rather than compute it multiple times. ------------- PR Review: https://git.openjdk.org/jdk/pull/26879#pullrequestreview-3145246364 From wkemper at openjdk.org Fri Aug 22 18:31:08 2025 From: wkemper at openjdk.org (William Kemper) Date: Fri, 22 Aug 2025 18:31:08 GMT Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may raise threshold prematurely Message-ID: The adaptive tenuring algorithm has been modified to begin its evaluation of mortality rates from the current tenuring threshold. To compliment this change, objects must also now be strictly above the tenuring threshold to be promoted (instead of greater-than-or-equal). ------------- Commit messages: - Revert unintended change - Merge tag 'jdk-26+12' into adaptive-tenuring-threshold - Clean up tests - Checkpoint, tests pass - Add test that simulates promotion above tenuring age - Add more census updates, exhibit current behavior in test - Remove outdated comment - Update unit test, fix slowdebug build issue - Merge remote-tracking branch 'jdk/master' into adaptive-tenuring-threshold - Assert current behavior is expected - ... and 1 more: https://git.openjdk.org/jdk/compare/02fe095d...64c68395 Changes: https://git.openjdk.org/jdk/pull/26906/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26906&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365956 Stats: 209 lines in 4 files changed: 190 ins; 4 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/26906.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26906/head:pull/26906 PR: https://git.openjdk.org/jdk/pull/26906 From wkemper at openjdk.org Fri Aug 22 18:31:09 2025 From: wkemper at openjdk.org (William Kemper) Date: Fri, 22 Aug 2025 18:31:09 GMT Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may raise threshold prematurely In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 18:24:12 GMT, William Kemper wrote: > The adaptive tenuring algorithm has been modified to begin its evaluation of mortality rates from the current tenuring threshold. To compliment this change, objects must also now be strictly above the tenuring threshold to be promoted (instead of greater-than-or-equal). src/hotspot/share/gc/shenandoah/shenandoahAgeCensus.cpp line 30: > 28: #include "gc/shenandoah/shenandoahHeap.inline.hpp" > 29: > 30: ShenandoahAgeCensus::ShenandoahAgeCensus() Many of the changes here are to facilitate unit testing. src/hotspot/share/gc/shenandoah/shenandoahAgeCensus.cpp line 307: > 305: // ignoring the mortality rates of any older cohorts (which may see > 306: // higher mortality rates due to promotions). > 307: upper_bound = MIN2(upper_bound, prev_tt); This is a key change. src/hotspot/share/gc/shenandoah/shenandoahAgeCensus.cpp line 331: > 329: assert(tenuring_threshold == i + 1 || tenuring_threshold == upper_bound, "Error"); > 330: assert(tenuring_threshold >= lower_bound && tenuring_threshold <= upper_bound, "Error"); > 331: return i + 1; This is a subtle change, but it prevents the algorithm from getting stuck on the first cohort. src/hotspot/share/gc/shenandoah/shenandoahAgeCensus.hpp line 181: > 179: // Return true if this age is above the tenuring threshold. > 180: bool is_tenurable(uint age) const { > 181: return age > tenuring_threshold(); Another key change. This prevents the algorithm from seeing higher mortality rates caused by promotions in the cohort at tenuring age. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26906#discussion_r2294394667 PR Review Comment: https://git.openjdk.org/jdk/pull/26906#discussion_r2294395207 PR Review Comment: https://git.openjdk.org/jdk/pull/26906#discussion_r2294396795 PR Review Comment: https://git.openjdk.org/jdk/pull/26906#discussion_r2294398888 From ayang at openjdk.org Fri Aug 22 18:37:47 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 22 Aug 2025 18:37:47 GMT Subject: RFR: 8365919: Replace currentTimeMillis with nanoTime in Stresser.java [v2] In-Reply-To: References: Message-ID: > Mostly a mechanic change from `currentTimeMillis()` to `nanoTime()/1000000`. It also removes `finishTime` to avoid overflowing. > > The change in `iteration()` is to ensure `currentTime` is properly initialized. > > (Was investigating a timeout on Windows-x64, which led me to this code. I think this fix is good enough by its own.) > > Test: tier1-5 Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - review - Merge branch 'master' into test-nano-time - test-nano-time ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26879/files - new: https://git.openjdk.org/jdk/pull/26879/files/7af0923b..cefb9948 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26879&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26879&range=00-01 Stats: 2221 lines in 64 files changed: 1292 ins; 549 del; 380 mod Patch: https://git.openjdk.org/jdk/pull/26879.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26879/head:pull/26879 PR: https://git.openjdk.org/jdk/pull/26879 From ayang at openjdk.org Fri Aug 22 18:40:52 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 22 Aug 2025 18:40:52 GMT Subject: RFR: 8365919: Replace currentTimeMillis with nanoTime in Stresser.java [v2] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 17:20:21 GMT, Paul Hohensee wrote: > You might want to load (options.getTime() * 1000) into a local rather than compute it multiple times. Extracted that to a local var for `getTimeLeft`. I skipped `printExecutionInfo`, as I feel introducing a local var there actually makes it a bit harder to read. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26879#issuecomment-3215273166 From wkemper at openjdk.org Fri Aug 22 21:01:32 2025 From: wkemper at openjdk.org (William Kemper) Date: Fri, 22 Aug 2025 21:01:32 GMT Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may raise threshold prematurely [v2] In-Reply-To: References: Message-ID: > The adaptive tenuring algorithm has been modified to begin its evaluation of mortality rates from the current tenuring threshold. To compliment this change, objects must also now be strictly above the tenuring threshold to be promoted (instead of greater-than-or-equal). William Kemper has updated the pull request incrementally with one additional commit since the last revision: Fix release build ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26906/files - new: https://git.openjdk.org/jdk/pull/26906/files/64c68395..8b2fb41a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26906&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26906&range=00-01 Stats: 10 lines in 2 files changed: 5 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/26906.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26906/head:pull/26906 PR: https://git.openjdk.org/jdk/pull/26906 From tschatzl at openjdk.org Mon Aug 25 07:46:07 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 25 Aug 2025 07:46:07 GMT Subject: RFR: 8365034: G1: Remove num_groups_selected in G1CollectionSet::select_candidates_from_optional_groups as it is unnecessary [v4] In-Reply-To: References: <5n0cnM0ddru6XMl7AVhFmWQFVnSvBwJqS6bD8JtpYpI=.bccb65aa-f93c-487e-bfd4-3f1d5b6fb918@github.com> Message-ID: On Fri, 22 Aug 2025 16:12:18 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: >> >> - * remove unwanted chagnes >> - Merge branch 'master' into 8365034-remove-unnecessary-num_selected_regions >> - Merge branch 'master' into 8365034-remove-unnecessary-num_selected_regions >> - * ayang review >> - Merge branch '8364934-g1collectionset-renaming' into 8365034-remove-unnecessary-num_selected_regions >> - Merge branch 'master' into 8364934-g1collectionset-renaming >> - Merge branch 'master' into 8364934-g1collectionset-renaming >> - * one more renaming: prepare_groups_for_scan() -> prepare_for_scan() >> - Merge branch '8364925-improve-program-flow-inc-cset' into 8364934-g1collectionset-renaming >> - * ayang review >> - ... and 4 more: https://git.openjdk.org/jdk/compare/e1c58f85...b9a66b12 > > Marked as reviewed by ayang (Reviewer). Thanks @albertnetymk @walulyai for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/26674#issuecomment-3219181275 From tschatzl at openjdk.org Mon Aug 25 07:46:07 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 25 Aug 2025 07:46:07 GMT Subject: RFR: 8365040: G1: Remove sorting at end of collection set selection [v4] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 15:14:16 GMT, Ivan Walulya wrote: >> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Merge branch 'master' into 8365040-remove-collection-set-sorting >> - Merge branch 'master' into 8365040-remove-collection-set-sorting >> - 8365040 >> >> Hi all, >> >> please review this change to remove some unnecessary sorting of the collection set introduced in https://bugs.openjdk.org/browse/JDK-8165313, and made unnecessary in https://bugs.openjdk.org/browse/JDK-8165443 (all JDK 9 :)). >> >> Testing: test case in CRs, gha >> >> Thanks, >> Thomas >> - 8364934 >> >> Hi all, >> >> please review this renaming of various members of `G1CollectionSet` to >> >> - use the same prefixes >> - remove unnecessary prefixes (`collection_set`) >> - fix some documentation >> >> Testing: gha >> >> Thanks, >> THoams >> - * remove accidentally merged in JDK-8364934 >> - 8364925 >> >> Hi all, >> >> please review this change that improves the G1CollectionSet incremental state handling slightly: >> >> * remove `_selected_groups_cur_length` with getter as we do not need a copy of that value around >> * move implementations of some methods from header files into cpp file >> * moved some incremental state updates from `finalize_old_part` to the respective `start/continue/stop_incremental_building` method >> >> Testing: gha >> >> Thanks, >> Thomas > > Marked as reviewed by iwalulya (Reviewer). Thanks @walulyai @albertnetymk for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/26676#issuecomment-3219182467 From tschatzl at openjdk.org Mon Aug 25 07:46:09 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 25 Aug 2025 07:46:09 GMT Subject: Integrated: 8365034: G1: Remove num_groups_selected in G1CollectionSet::select_candidates_from_optional_groups as it is unnecessary In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 10:33:59 GMT, Thomas Schatzl wrote: > Hi all, > > please review this removal of the local `num_selected_regions` from `G1CollectionSet::select_candidates_from_optional_groups()` - the same information is maintained within the local `selected_groups` list. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 28bd29f3 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/28bd29f3963938f3846e68f33ac3648b2ba101f4 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod 8365034: G1: Remove num_groups_selected in G1CollectionSet::select_candidates_from_optional_groups as it is unnecessary Reviewed-by: ayang, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/26674 From tschatzl at openjdk.org Mon Aug 25 07:46:09 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 25 Aug 2025 07:46:09 GMT Subject: Integrated: 8365040: G1: Remove sorting at end of collection set selection In-Reply-To: References: Message-ID: <_x1AsENKSeyU757N4Tpv_o6JxGJWOgf9iRIxFHCBaTc=.c74c8136-0614-4742-983b-4b560a542e22@github.com> On Thu, 7 Aug 2025 12:10:49 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to remove some unnecessary sorting of the collection set introduced in https://bugs.openjdk.org/browse/JDK-8165313, and made unnecessary in https://bugs.openjdk.org/browse/JDK-8165443 (all JDK 9 :)). > > Testing: test case in CRs, see CR for test results, gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 7fa501e3 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/7fa501e39874214c9bc7503c0bdb68d090245208 Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod 8365040: G1: Remove sorting at end of collection set selection Reviewed-by: iwalulya, ayang ------------- PR: https://git.openjdk.org/jdk/pull/26676 From tschatzl at openjdk.org Mon Aug 25 07:47:59 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 25 Aug 2025 07:47:59 GMT Subject: RFR: 8365976: G1: Full gc should mark nmethods on stack In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 15:15:12 GMT, Ivan Walulya wrote: >> Hi all, >> >> please review this fix that moves the nmethod arming after registering the nmethods during full gc to make sure that the remaining ones are armed. That changed after [JDK-8360540](https://bugs.openjdk.org/browse/JDK-8360540). >> >> Testing: gha >> >> Thanks, >> Thomas > > Marked as reviewed by iwalulya (Reviewer). Thanks @walulyai @albertnetymk for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/26899#issuecomment-3219184377 From tschatzl at openjdk.org Mon Aug 25 07:47:59 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 25 Aug 2025 07:47:59 GMT Subject: Integrated: 8365976: G1: Full gc should mark nmethods on stack In-Reply-To: References: Message-ID: <5mj-CfCq2rgIzKqaxVhHBxdH0YFzFDJbtoDBMJZlLZc=.b6ef54ad-5920-4922-9a9f-2bb0d8864a50@github.com> On Fri, 22 Aug 2025 10:59:38 GMT, Thomas Schatzl wrote: > Hi all, > > please review this fix that moves the nmethod arming after registering the nmethods during full gc to make sure that the remaining ones are armed. That changed after [JDK-8360540](https://bugs.openjdk.org/browse/JDK-8360540). > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 57434c73 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/57434c73eac9bd6557b09d4a057e3a2a18f382b4 Stats: 3 lines in 2 files changed: 1 ins; 2 del; 0 mod 8365976: G1: Full gc should mark nmethods on stack Reviewed-by: ayang, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/26899 From ayang at openjdk.org Mon Aug 25 08:58:30 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 25 Aug 2025 08:58:30 GMT Subject: RFR: 8366063: Parallel: Refactor copy_unmarked_to_survivor_space Message-ID: 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. ------------- Commit messages: - pgc-young-gc-alloc-refactor Changes: https://git.openjdk.org/jdk/pull/26922/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26922&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366063 Stats: 149 lines in 2 files changed: 81 ins; 62 del; 6 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 Mon Aug 25 09:14:53 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 25 Aug 2025 09:14:53 GMT Subject: RFR: 8366035: Simplify CPUTimeCounters::publish_gc_total_cpu_time [v2] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 08:45:47 GMT, Guanqiang Han wrote: >> This change refactors CPUTimeCounters::publish_gc_total_cpu_time() to use Atomic::xchg instead of a CAS (cmpxchg) loop. >> Please review it. Thanks > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > Update cpuTimeCounters.cpp > > a small fix Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26921#pullrequestreview-3150560761 From ayang at openjdk.org Mon Aug 25 09:15:56 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 25 Aug 2025 09:15:56 GMT Subject: RFR: 8365052: G1: Remove G1CollectionSet::groups() accessors [v4] In-Reply-To: References: <8ZodEn2wqRkIaTR2ZoMjm5scNATrQHcS1IP1VVJMVtM=.70676141-6535-4869-8b14-e692bad9ab6a@github.com> Message-ID: On Fri, 22 Aug 2025 15:51:07 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this small change that remove the public `G1CollectionSet::groups()` accessors because they are never used from outside the `G1CollectionSet` class. >> >> Testing: local compilation, gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: > > - Merge branch 'master' into 8365052-remove-groups-accessors > - Merge branch 'master' into 8365052-remove-groups-accessors > - 8365052 > > Hi all, > > please review this small change that remove the public `G1CollectionSet::groups()` accessors because they are never used from outside the `G1CollectionSet` class. > > Testing: local compilation, gha > > Thanks, > Thomas > - * one more renaming: prepare_groups_for_scan() -> prepare_for_scan() > - Merge branch '8364925-improve-program-flow-inc-cset' into 8364934-g1collectionset-renaming > - * ayang review > - 8364934 > > Hi all, > > please review this renaming of various members of `G1CollectionSet` to > > - use the same prefixes > - remove unnecessary prefixes (`collection_set`) > - fix some documentation > > Testing: gha > > Thanks, > THoams > - * remove accidentally merged in JDK-8364934 > - 8364925 > > Hi all, > > please review this change that improves the G1CollectionSet incremental state handling slightly: > > * remove `_selected_groups_cur_length` with getter as we do not need a copy of that value around > * move implementations of some methods from header files into cpp file > * moved some incremental state updates from `finalize_old_part` to the respective `start/continue/stop_incremental_building` method > > Testing: gha > > Thanks, > Thomas Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26688#pullrequestreview-3150564163 From ayang at openjdk.org Mon Aug 25 09:18:32 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 25 Aug 2025 09:18:32 GMT Subject: RFR: 8346005: Parallel: Incorrect page size calculation with UseLargePages [v3] 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 three additional commits since the last revision: - 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/5df3735a..88702f07 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26700&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26700&range=01-02 Stats: 14036 lines in 528 files changed: 8315 ins; 3770 del; 1951 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 kbarrett at openjdk.org Mon Aug 25 09:58:52 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 25 Aug 2025 09:58:52 GMT Subject: RFR: 8366035: Simplify CPUTimeCounters::publish_gc_total_cpu_time [v2] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 08:45:47 GMT, Guanqiang Han wrote: >> This change refactors CPUTimeCounters::publish_gc_total_cpu_time() to use Atomic::xchg instead of a CAS (cmpxchg) loop. >> Please review it. Thanks > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > Update cpuTimeCounters.cpp > > a small fix Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26921#pullrequestreview-3150736983 From tschatzl at openjdk.org Mon Aug 25 10:20:59 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 25 Aug 2025 10:20:59 GMT Subject: RFR: 8365052: G1: Remove G1CollectionSet::groups() accessors [v4] In-Reply-To: References: <8ZodEn2wqRkIaTR2ZoMjm5scNATrQHcS1IP1VVJMVtM=.70676141-6535-4869-8b14-e692bad9ab6a@github.com> Message-ID: On Mon, 25 Aug 2025 09:12:51 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: >> >> - Merge branch 'master' into 8365052-remove-groups-accessors >> - Merge branch 'master' into 8365052-remove-groups-accessors >> - 8365052 >> >> Hi all, >> >> please review this small change that remove the public `G1CollectionSet::groups()` accessors because they are never used from outside the `G1CollectionSet` class. >> >> Testing: local compilation, gha >> >> Thanks, >> Thomas >> - * one more renaming: prepare_groups_for_scan() -> prepare_for_scan() >> - Merge branch '8364925-improve-program-flow-inc-cset' into 8364934-g1collectionset-renaming >> - * ayang review >> - 8364934 >> >> Hi all, >> >> please review this renaming of various members of `G1CollectionSet` to >> >> - use the same prefixes >> - remove unnecessary prefixes (`collection_set`) >> - fix some documentation >> >> Testing: gha >> >> Thanks, >> THoams >> - * remove accidentally merged in JDK-8364934 >> - 8364925 >> >> Hi all, >> >> please review this change that improves the G1CollectionSet incremental state handling slightly: >> >> * remove `_selected_groups_cur_length` with getter as we do not need a copy of that value around >> * move implementations of some methods from header files into cpp file >> * moved some incremental state updates from `finalize_old_part` to the respective `start/continue/stop_incremental_building` method >> >> Testing: gha >> >> Thanks, >> Thomas > > Marked as reviewed by ayang (Reviewer). Thanks @albertnetymk @kimbarrett for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/26688#issuecomment-3219670530 From tschatzl at openjdk.org Mon Aug 25 10:21:00 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 25 Aug 2025 10:21:00 GMT Subject: Integrated: 8365052: G1: Remove G1CollectionSet::groups() accessors In-Reply-To: <8ZodEn2wqRkIaTR2ZoMjm5scNATrQHcS1IP1VVJMVtM=.70676141-6535-4869-8b14-e692bad9ab6a@github.com> References: <8ZodEn2wqRkIaTR2ZoMjm5scNATrQHcS1IP1VVJMVtM=.70676141-6535-4869-8b14-e692bad9ab6a@github.com> Message-ID: On Fri, 8 Aug 2025 08:11:10 GMT, Thomas Schatzl wrote: > Hi all, > > please review this small change that remove the public `G1CollectionSet::groups()` accessors because they are never used from outside the `G1CollectionSet` class. > > Testing: local compilation, gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 45726a1f Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/45726a1f8b8f76586037867a32b82f8ab9b96937 Stats: 5 lines in 3 files changed: 0 ins; 3 del; 2 mod 8365052: G1: Remove G1CollectionSet::groups() accessors Reviewed-by: ayang, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/26688 From tschatzl at openjdk.org Mon Aug 25 10:34:11 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 25 Aug 2025 10:34:11 GMT Subject: RFR: 8365656: [ubsan] G1CSetCandidateGroup::liveness() reports division by 0 [v4] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that fixes a div-by-zero in calculating liveness for logging. > > It is possible that the young gen group cardset is empty (has no regions assigned to it as no eden region has retired yet) when the `Cleanup` pause starts, making the liveness calculation divide by zero. > > The change special-cases this case when printing - I decided to always print the group in this case, regardless of length, just fudging the output value a bit. An alternative would be not printing it at all in this case. Feel free to argue for that solution. Also the printed value for liveness (0.0%) is up for discussion. > > Testing: failing test case does not fail any more now and then, gha, tier1-4 > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * make liveness_percent() fail on an empty group, check before use ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26888/files - new: https://git.openjdk.org/jdk/pull/26888/files/496d9bb4..3730e498 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26888&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26888&range=02-03 Stats: 5 lines in 2 files changed: 0 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26888.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26888/head:pull/26888 PR: https://git.openjdk.org/jdk/pull/26888 From tschatzl at openjdk.org Mon Aug 25 10:34:11 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 25 Aug 2025 10:34:11 GMT Subject: RFR: 8365656: [ubsan] G1CSetCandidateGroup::liveness() reports division by 0 [v4] In-Reply-To: References: <40uXi5dV2ChF-Zc5dkXYuGpvmApIU4QlvXbCM3kGgfE=.bc6b2823-aa48-4b93-91fe-7e8f14e38889@github.com> Message-ID: <5PV5q4wfuOXY8GkUtqcLiSlR4PzZOOOYvTgpRuIxJWI=.9e0885a6-1a4f-4a91-b321-a9cd8174ad8c@github.com> On Fri, 22 Aug 2025 12:22:24 GMT, Albert Mingkun Yang wrote: >> I disagree, why should the caller know that the public method is subject to crashes if called with length() == 0? Eventually, one will use `liveness_percent()` without this guard. > > Because this method doesn't have a sensible meaning for zero-length groups. Here we are printing `0` as a pragmatic solution, but maybe `N/A` can be more pedantic in this context. > > In other contexts, I think it's beneficial to catch such misuse, hence the suggestion of precondition. I do not feel strongly about this, and I can see both sides. Changed it to do the check in the logging directly. For simplicity I want to avoid a "n/a" or something, and in fact we recently changed it to just return 0. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26888#discussion_r2297740725 From ayang at openjdk.org Mon Aug 25 10:43:54 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 25 Aug 2025 10:43:54 GMT Subject: RFR: 8365656: [ubsan] G1CSetCandidateGroup::liveness() reports division by 0 [v4] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 10:34:11 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that fixes a div-by-zero in calculating liveness for logging. >> >> It is possible that the young gen group cardset is empty (has no regions assigned to it as no eden region has retired yet) when the `Cleanup` pause starts, making the liveness calculation divide by zero. >> >> The change special-cases this case when printing - I decided to always print the group in this case, regardless of length, just fudging the output value a bit. An alternative would be not printing it at all in this case. Feel free to argue for that solution. Also the printed value for liveness (0.0%) is up for discussion. >> >> Testing: failing test case does not fail any more now and then, gha, tier1-4 >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * make liveness_percent() fail on an empty group, check before use Why `0.0f` instead of just `0.0`? ------------- Marked as reviewed by ayang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26888#pullrequestreview-3150879428 From aboldtch at openjdk.org Mon Aug 25 10:49:53 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 25 Aug 2025 10:49:53 GMT Subject: RFR: 8365994: ZGC: Incorrect type signature in ZMappedCache comparator In-Reply-To: <_nBhAdONXQ_QsOXGW1pwBiu4nb_pCS_wcp57lyNXMXA=.4c7e21f1-45e2-420c-8919-989a20622d57@github.com> References: <_nBhAdONXQ_QsOXGW1pwBiu4nb_pCS_wcp57lyNXMXA=.4c7e21f1-45e2-420c-8919-989a20622d57@github.com> Message-ID: <3_pBsWIKwkghoX4W-mBA4v_qn5bbeRtrTtf-Ekq4IEU=.4aaf9238-8574-44f1-817b-6b84f5ce24a9@github.com> On Fri, 22 Aug 2025 15:08:42 GMT, Joel Sikstr?m wrote: > Hello, > > The comparator with two IntrusiveRBNode* in ZMappedCache has the incorrent type signature. This prevents IntrusiveRBTree from using the comparator as intended during validation, resulting in it using the fallback verify function, which always returns true. This could mask potential issues in the tree structure. > > Testing: > * Manually placing an assert in the fallback verify function to see if it is used. It is no longer used with this patch. > * Oracle's tier 1-2 Good catch. ------------- Marked as reviewed by aboldtch (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26904#pullrequestreview-3150892756 From jsikstro at openjdk.org Mon Aug 25 11:33:50 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Mon, 25 Aug 2025 11:33:50 GMT Subject: RFR: 8359683: ZGC: NUMA-Aware Relocation [v2] In-Reply-To: <_SnXFrT1StlCj4JYdTfY-S6tPa6dsi-p6VfMl01te7k=.1cabcd48-3709-4b3c-9ea8-3fc122c505fe@github.com> References: <_SnXFrT1StlCj4JYdTfY-S6tPa6dsi-p6VfMl01te7k=.1cabcd48-3709-4b3c-9ea8-3fc122c505fe@github.com> Message-ID: > Hello, > > With [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441), ZGC got infrastructure to prefer allocations to end up on a specific NUMA node. When a new object is allocated, it is preferably placed on the NUMA node that is local to the allocating thread. This strategy improves access speeds for mutators working on that object, if it continues to be used by threads on the same NUMA node. However, when relocating objects, ZGC will potentially move (migrate) objects away from the NUMA node they were originally allocated on. This means that if a page is selected as part of the Relocation Set, the objects on that page could potentially be moved to another NUMA node, breaking the NUMA locality we strived for when allocating. > > We should consider adding NUMA-awareness to ZGC's relocation phase to keep NUMA-locality benefits for mutators. > >
> > Proposal (expandable section) > > NUMA-Awareness consists of two main features: > > **First**: GC threads should strive toward keeping the NUMA locality of objects to their original node, meaning that objects should ideally be relocated to a page that is on the same NUMA node. > > Mutator threads should have a different approach, as we know that the mutator that's (helping out with) relocating an object is also going to access it, so we migrate the object to the NUMA node associated with the relocating thread. This strategy is already in effect and does not require any changes to the code (specifically, ZObjectAllocator already track per-CPU specific Small pages). However, Medium pages are shared between CPUs and thus does not hold any guarantees on which NUMA node it is on. Combined, both mutator and Medium page relocation are not common, and thus there is little gain from introducing NUMA-awareness to that specific scenario. Instead, this can be addressed in a follow-up if we feel that's necessary. > > **Second**: When the GC chooses a page from the Relocation Set to relocate objects from, it should choose page(s) that are local to the same NUMA node, to speed up performance by working on NUMA-local memory. There are multiple ways to achieve this, but the main goal should be to (1) start working on pages that are local to the GC thread's NUMA node, and (2) when finished with pages on its own NUMA node, start working (help out) with pages associated with other NUMA nodes. > > Some key observations to consider with the above approach: > > * The NUMA node associated with the GC thread should be "polle... Joel Sikstr?m has updated the pull request incrementally with three additional commits since the last revision: - Improve comment for relocation iterators destruction - Break out multi-partition check to its own function - Remove partition_id parameter from alloc_and_retire_target_page ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26898/files - new: https://git.openjdk.org/jdk/pull/26898/files/4082be65..829368fe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26898&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26898&range=00-01 Stats: 14 lines in 3 files changed: 9 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/26898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26898/head:pull/26898 PR: https://git.openjdk.org/jdk/pull/26898 From jsikstro at openjdk.org Mon Aug 25 11:33:51 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Mon, 25 Aug 2025 11:33:51 GMT Subject: RFR: 8359683: ZGC: NUMA-Aware Relocation In-Reply-To: <_SnXFrT1StlCj4JYdTfY-S6tPa6dsi-p6VfMl01te7k=.1cabcd48-3709-4b3c-9ea8-3fc122c505fe@github.com> References: <_SnXFrT1StlCj4JYdTfY-S6tPa6dsi-p6VfMl01te7k=.1cabcd48-3709-4b3c-9ea8-3fc122c505fe@github.com> Message-ID: <7lZKqq_UadXT4LYi6rZjEOahMsLxtMRUn6evD-TtAP0=.bc4e86fb-f397-464c-8308-c726930b479f@github.com> On Fri, 22 Aug 2025 10:28:01 GMT, Joel Sikstr?m wrote: > Hello, > > With [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441), ZGC got infrastructure to prefer allocations to end up on a specific NUMA node. When a new object is allocated, it is preferably placed on the NUMA node that is local to the allocating thread. This strategy improves access speeds for mutators working on that object, if it continues to be used by threads on the same NUMA node. However, when relocating objects, ZGC will potentially move (migrate) objects away from the NUMA node they were originally allocated on. This means that if a page is selected as part of the Relocation Set, the objects on that page could potentially be moved to another NUMA node, breaking the NUMA locality we strived for when allocating. > > We should consider adding NUMA-awareness to ZGC's relocation phase to keep NUMA-locality benefits for mutators. > >
> > Proposal (expandable section) > > NUMA-Awareness consists of two main features: > > **First**: GC threads should strive toward keeping the NUMA locality of objects to their original node, meaning that objects should ideally be relocated to a page that is on the same NUMA node. > > Mutator threads should have a different approach, as we know that the mutator that's (helping out with) relocating an object is also going to access it, so we migrate the object to the NUMA node associated with the relocating thread. This strategy is already in effect and does not require any changes to the code (specifically, ZObjectAllocator already track per-CPU specific Small pages). However, Medium pages are shared between CPUs and thus does not hold any guarantees on which NUMA node it is on. Combined, both mutator and Medium page relocation are not common, and thus there is little gain from introducing NUMA-awareness to that specific scenario. Instead, this can be addressed in a follow-up if we feel that's necessary. > > **Second**: When the GC chooses a page from the Relocation Set to relocate objects from, it should choose page(s) that are local to the same NUMA node, to speed up performance by working on NUMA-local memory. There are multiple ways to achieve this, but the main goal should be to (1) start working on pages that are local to the GC thread's NUMA node, and (2) when finished with pages on its own NUMA node, start working (help out) with pages associated with other NUMA nodes. > > Some key observations to consider with the above approach: > > * The NUMA node associated with the GC thread should be "polle... I addressed some offline feedback from @kstefanj in new commits. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26898#issuecomment-3219903928 From jsikstro at openjdk.org Mon Aug 25 11:46:31 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Mon, 25 Aug 2025 11:46:31 GMT Subject: RFR: 8359683: ZGC: NUMA-Aware Relocation [v3] In-Reply-To: <_SnXFrT1StlCj4JYdTfY-S6tPa6dsi-p6VfMl01te7k=.1cabcd48-3709-4b3c-9ea8-3fc122c505fe@github.com> References: <_SnXFrT1StlCj4JYdTfY-S6tPa6dsi-p6VfMl01te7k=.1cabcd48-3709-4b3c-9ea8-3fc122c505fe@github.com> Message-ID: > Hello, > > With [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441), ZGC got infrastructure to prefer allocations to end up on a specific NUMA node. When a new object is allocated, it is preferably placed on the NUMA node that is local to the allocating thread. This strategy improves access speeds for mutators working on that object, if it continues to be used by threads on the same NUMA node. However, when relocating objects, ZGC will potentially move (migrate) objects away from the NUMA node they were originally allocated on. This means that if a page is selected as part of the Relocation Set, the objects on that page could potentially be moved to another NUMA node, breaking the NUMA locality we strived for when allocating. > > We should consider adding NUMA-awareness to ZGC's relocation phase to keep NUMA-locality benefits for mutators. > >
> > Proposal (expandable section) > > NUMA-Awareness consists of two main features: > > **First**: GC threads should strive toward keeping the NUMA locality of objects to their original node, meaning that objects should ideally be relocated to a page that is on the same NUMA node. > > Mutator threads should have a different approach, as we know that the mutator that's (helping out with) relocating an object is also going to access it, so we migrate the object to the NUMA node associated with the relocating thread. This strategy is already in effect and does not require any changes to the code (specifically, ZObjectAllocator already track per-CPU specific Small pages). However, Medium pages are shared between CPUs and thus does not hold any guarantees on which NUMA node it is on. Combined, both mutator and Medium page relocation are not common, and thus there is little gain from introducing NUMA-awareness to that specific scenario. Instead, this can be addressed in a follow-up if we feel that's necessary. > > **Second**: When the GC chooses a page from the Relocation Set to relocate objects from, it should choose page(s) that are local to the same NUMA node, to speed up performance by working on NUMA-local memory. There are multiple ways to achieve this, but the main goal should be to (1) start working on pages that are local to the GC thread's NUMA node, and (2) when finished with pages on its own NUMA node, start working (help out) with pages associated with other NUMA nodes. > > Some key observations to consider with the above approach: > > * The NUMA node associated with the GC thread should be "polle... Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: Rename initiating_numa_id to preferred_partition ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26898/files - new: https://git.openjdk.org/jdk/pull/26898/files/829368fe..ac8a76ea Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26898&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26898&range=01-02 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/26898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26898/head:pull/26898 PR: https://git.openjdk.org/jdk/pull/26898 From jsikstro at openjdk.org Mon Aug 25 11:46:31 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Mon, 25 Aug 2025 11:46:31 GMT Subject: RFR: 8359683: ZGC: NUMA-Aware Relocation [v2] In-Reply-To: References: <_SnXFrT1StlCj4JYdTfY-S6tPa6dsi-p6VfMl01te7k=.1cabcd48-3709-4b3c-9ea8-3fc122c505fe@github.com> Message-ID: On Mon, 25 Aug 2025 11:33:50 GMT, Joel Sikstr?m wrote: >> Hello, >> >> With [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441), ZGC got infrastructure to prefer allocations to end up on a specific NUMA node. When a new object is allocated, it is preferably placed on the NUMA node that is local to the allocating thread. This strategy improves access speeds for mutators working on that object, if it continues to be used by threads on the same NUMA node. However, when relocating objects, ZGC will potentially move (migrate) objects away from the NUMA node they were originally allocated on. This means that if a page is selected as part of the Relocation Set, the objects on that page could potentially be moved to another NUMA node, breaking the NUMA locality we strived for when allocating. >> >> We should consider adding NUMA-awareness to ZGC's relocation phase to keep NUMA-locality benefits for mutators. >> >>
>> >> Proposal (expandable section) >> >> NUMA-Awareness consists of two main features: >> >> **First**: GC threads should strive toward keeping the NUMA locality of objects to their original node, meaning that objects should ideally be relocated to a page that is on the same NUMA node. >> >> Mutator threads should have a different approach, as we know that the mutator that's (helping out with) relocating an object is also going to access it, so we migrate the object to the NUMA node associated with the relocating thread. This strategy is already in effect and does not require any changes to the code (specifically, ZObjectAllocator already track per-CPU specific Small pages). However, Medium pages are shared between CPUs and thus does not hold any guarantees on which NUMA node it is on. Combined, both mutator and Medium page relocation are not common, and thus there is little gain from introducing NUMA-awareness to that specific scenario. Instead, this can be addressed in a follow-up if we feel that's necessary. >> >> **Second**: When the GC chooses a page from the Relocation Set to relocate objects from, it should choose page(s) that are local to the same NUMA node, to speed up performance by working on NUMA-local memory. There are multiple ways to achieve this, but the main goal should be to (1) start working on pages that are local to the GC thread's NUMA node, and (2) when finished with pages on its own NUMA node, start working (help out) with pages associated with other NUMA nodes. >> >> Some key observations to consider with the above approach: >> >> * The NUMA node asso... > > Joel Sikstr?m has updated the pull request incrementally with three additional commits since the last revision: > > - Improve comment for relocation iterators destruction > - Break out multi-partition check to its own function > - Remove partition_id parameter from alloc_and_retire_target_page ... and some more offline feedback from @xmas92! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26898#issuecomment-3219938928 From tschatzl at openjdk.org Mon Aug 25 12:01:32 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 25 Aug 2025 12:01:32 GMT Subject: RFR: 8365656: [ubsan] G1CSetCandidateGroup::liveness() reports division by 0 [v4] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 10:41:08 GMT, Albert Mingkun Yang wrote: > Why `0.0f` instead of just `0.0`? Habit to use the smaller data type. I changed it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26888#issuecomment-3219983591 From tschatzl at openjdk.org Mon Aug 25 12:01:32 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 25 Aug 2025 12:01:32 GMT Subject: RFR: 8365656: [ubsan] G1CSetCandidateGroup::liveness() reports division by 0 [v5] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that fixes a div-by-zero in calculating liveness for logging. > > It is possible that the young gen group cardset is empty (has no regions assigned to it as no eden region has retired yet) when the `Cleanup` pause starts, making the liveness calculation divide by zero. > > The change special-cases this case when printing - I decided to always print the group in this case, regardless of length, just fudging the output value a bit. An alternative would be not printing it at all in this case. Feel free to argue for that solution. Also the printed value for liveness (0.0%) is up for discussion. > > Testing: failing test case does not fail any more now and then, gha, tier1-4 > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * use double-sized 0.0 constants ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26888/files - new: https://git.openjdk.org/jdk/pull/26888/files/3730e498..512ce461 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26888&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26888&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26888.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26888/head:pull/26888 PR: https://git.openjdk.org/jdk/pull/26888 From ayang at openjdk.org Mon Aug 25 12:04:53 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 25 Aug 2025 12:04:53 GMT Subject: RFR: 8365656: [ubsan] G1CSetCandidateGroup::liveness() reports division by 0 [v5] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 12:01:32 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that fixes a div-by-zero in calculating liveness for logging. >> >> It is possible that the young gen group cardset is empty (has no regions assigned to it as no eden region has retired yet) when the `Cleanup` pause starts, making the liveness calculation divide by zero. >> >> The change special-cases this case when printing - I decided to always print the group in this case, regardless of length, just fudging the output value a bit. An alternative would be not printing it at all in this case. Feel free to argue for that solution. Also the printed value for liveness (0.0%) is up for discussion. >> >> Testing: failing test case does not fail any more now and then, gha, tier1-4 >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * use double-sized 0.0 constants Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26888#pullrequestreview-3151127725 From iwalulya at openjdk.org Mon Aug 25 12:17:53 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 25 Aug 2025 12:17:53 GMT Subject: RFR: 8365656: [ubsan] G1CSetCandidateGroup::liveness() reports division by 0 [v5] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 12:01:32 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that fixes a div-by-zero in calculating liveness for logging. >> >> It is possible that the young gen group cardset is empty (has no regions assigned to it as no eden region has retired yet) when the `Cleanup` pause starts, making the liveness calculation divide by zero. >> >> The change special-cases this case when printing - I decided to always print the group in this case, regardless of length, just fudging the output value a bit. An alternative would be not printing it at all in this case. Feel free to argue for that solution. Also the printed value for liveness (0.0%) is up for discussion. >> >> Testing: failing test case does not fail any more now and then, gha, tier1-4 >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * use double-sized 0.0 constants Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26888#pullrequestreview-3151170749 From tschatzl at openjdk.org Mon Aug 25 12:31:54 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 25 Aug 2025 12:31:54 GMT Subject: RFR: 8365919: Replace currentTimeMillis with nanoTime in Stresser.java [v2] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 18:37:47 GMT, Albert Mingkun Yang wrote: >> Mostly a mechanic change from `currentTimeMillis()` to `nanoTime()/1000000`. It also removes `finishTime` to avoid overflowing. >> >> The change in `iteration()` is to ensure `currentTime` is properly initialized. >> >> (Was investigating a timeout on Windows-x64, which led me to this code. I think this fix is good enough by its own.) >> >> Test: tier1-5 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - review > - Merge branch 'master' into test-nano-time > - test-nano-time Changes requested by tschatzl (Reviewer). test/hotspot/jtreg/vmTestbase/nsk/share/test/Stresser.java line 184: > 182: public void printExecutionInfo(PrintStream out) { > 183: println(out, "Completed iterations: " + iterations); > 184: println(out, "Execution time: " + (currentTime - startTime)/1000.0 + " seconds"); There should be spaces around the operator. The change sometimes has them and sometimes not. Suggestion: println(out, "Execution time: " + (currentTime - startTime) / 1000.0 + " seconds"); test/hotspot/jtreg/vmTestbase/nsk/share/test/Stresser.java line 214: > 212: iterations = 0; > 213: long stressTime = options.getTime(); > 214: startTime = System.nanoTime()/1000000; If the reason for the change is to use `System.nanoTime()` instead of `System.currentTimeMillis()` because of monoticity, wouldn't it be simpler to add a helper that returns a millisecond value based on `System.nanoTime()` and call that one instead of `System.currentTimeMillis()` and keep everything else the same? Inlining the `System.nanoTime() / 1000000` statement a few times seems bad. Having a helper function for this might allow to include a comment why `System.currentTimeMillis()` is not used too. test/hotspot/jtreg/vmTestbase/nsk/share/test/Stresser.java line 276: > 274: && !finished > 275: && (maxIterations == 0 || iterations < maxIterations) > 276: && (options.getTime() == 0 || (currentTime - startTime) < options.getTime() * 1000); I doubt that inlining `options.getTime() * 1000` literally 10 times instead of storing it in a local (`finishTime`) or having a getter makes the code easier to understand. Maybe just rename `finishTime` to sth like `stressTime`? test/hotspot/jtreg/vmTestbase/nsk/share/test/Stresser.java line 320: > 318: */ > 319: public long getTimeLeft() { > 320: long elapsedTime = System.nanoTime()/1000000 - startTime; This could maybe use `getExecutionTime()`? Also the repeated use of the term `System.nanoTime() / 1000000` five time definitely warrants a helper function imo, and allows documentation of the reason for its use. ------------- PR Review: https://git.openjdk.org/jdk/pull/26879#pullrequestreview-3151131499 PR Review Comment: https://git.openjdk.org/jdk/pull/26879#discussion_r2297919503 PR Review Comment: https://git.openjdk.org/jdk/pull/26879#discussion_r2297945572 PR Review Comment: https://git.openjdk.org/jdk/pull/26879#discussion_r2297958826 PR Review Comment: https://git.openjdk.org/jdk/pull/26879#discussion_r2297928840 From duke at openjdk.org Mon Aug 25 12:45:55 2025 From: duke at openjdk.org (Bernd) Date: Mon, 25 Aug 2025 12:45:55 GMT Subject: RFR: 8365919: Replace currentTimeMillis with nanoTime in Stresser.java [v2] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 12:16:35 GMT, Thomas Schatzl 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 test-nano-time >> - test-nano-time > > test/hotspot/jtreg/vmTestbase/nsk/share/test/Stresser.java line 214: > >> 212: iterations = 0; >> 213: long stressTime = options.getTime(); >> 214: startTime = System.nanoTime()/1000000; > > If the reason for the change is to use `System.nanoTime()` instead of `System.currentTimeMillis()` because of monoticity, wouldn't it be simpler to add a helper that returns a millisecond value based on `System.nanoTime()` and call that one instead of `System.currentTimeMillis()` and keep everything else the same? > > Inlining the `System.nanoTime() / 1000000` statement a few times seems bad. Having a helper function for this might allow to include a comment why `System.currentTimeMillis()` is not used too. Or use nanoTime resolution throughout the calculations and only normalize on printout and when comparing with the deadline. Although nanoTime is here not used for its resolution, I find it quite unusual to see that /1_000_000 sprinkled around the start time recording. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26879#discussion_r2298000781 From sjohanss at openjdk.org Mon Aug 25 13:15:53 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Mon, 25 Aug 2025 13:15:53 GMT Subject: RFR: 8359683: ZGC: NUMA-Aware Relocation [v3] In-Reply-To: References: <_SnXFrT1StlCj4JYdTfY-S6tPa6dsi-p6VfMl01te7k=.1cabcd48-3709-4b3c-9ea8-3fc122c505fe@github.com> Message-ID: On Mon, 25 Aug 2025 11:46:31 GMT, Joel Sikstr?m wrote: >> Hello, >> >> With [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441), ZGC got infrastructure to prefer allocations to end up on a specific NUMA node. When a new object is allocated, it is preferably placed on the NUMA node that is local to the allocating thread. This strategy improves access speeds for mutators working on that object, if it continues to be used by threads on the same NUMA node. However, when relocating objects, ZGC will potentially move (migrate) objects away from the NUMA node they were originally allocated on. This means that if a page is selected as part of the Relocation Set, the objects on that page could potentially be moved to another NUMA node, breaking the NUMA locality we strived for when allocating. >> >> We should consider adding NUMA-awareness to ZGC's relocation phase to keep NUMA-locality benefits for mutators. >> >>
>> >> Proposal (expandable section) >> >> NUMA-Awareness consists of two main features: >> >> **First**: GC threads should strive toward keeping the NUMA locality of objects to their original node, meaning that objects should ideally be relocated to a page that is on the same NUMA node. >> >> Mutator threads should have a different approach, as we know that the mutator that's (helping out with) relocating an object is also going to access it, so we migrate the object to the NUMA node associated with the relocating thread. This strategy is already in effect and does not require any changes to the code (specifically, ZObjectAllocator already track per-CPU specific Small pages). However, Medium pages are shared between CPUs and thus does not hold any guarantees on which NUMA node it is on. Combined, both mutator and Medium page relocation are not common, and thus there is little gain from introducing NUMA-awareness to that specific scenario. Instead, this can be addressed in a follow-up if we feel that's necessary. >> >> **Second**: When the GC chooses a page from the Relocation Set to relocate objects from, it should choose page(s) that are local to the same NUMA node, to speed up performance by working on NUMA-local memory. There are multiple ways to achieve this, but the main goal should be to (1) start working on pages that are local to the GC thread's NUMA node, and (2) when finished with pages on its own NUMA node, start working (help out) with pages associated with other NUMA nodes. >> >> Some key observations to consider with the above approach: >> >> * The NUMA node asso... > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > Rename initiating_numa_id to preferred_partition Looks good, did you look anything at changing the iterators to make it possible having something like `_iters.reset()` in the constructor for `ZRelocateTask`. This could also be done as a followup. src/hotspot/share/gc/z/zPageAllocator.cpp line 2200: > 2198: is_multi_partition_enabled() && > 2199: sum_available() >= allocation->size(); > 2200: } Thanks for addressing my comments, if I'm being picky I would prefer this order of the statements. If you prefer the current I'm ok with this as well. Suggestion: return is_multi_partition_enabled() && allocation->type() == ZPageType::large && allocation->size() <= sum_available(); } ------------- Marked as reviewed by sjohanss (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26898#pullrequestreview-3151383090 PR Review Comment: https://git.openjdk.org/jdk/pull/26898#discussion_r2298058476 From ayang at openjdk.org Mon Aug 25 14:09:13 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 25 Aug 2025 14:09:13 GMT Subject: RFR: 8365919: Replace currentTimeMillis with nanoTime in Stresser.java [v3] In-Reply-To: References: Message-ID: > Mostly a mechanic change from `currentTimeMillis()` to `nanoTime()/1000000`. It also removes `finishTime` to avoid overflowing. > > The change in `iteration()` is to ensure `currentTime` is properly initialized. > > (Was investigating a timeout on Windows-x64, which led me to this code. I think this fix is good enough by its own.) > > Test: tier1-5 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/26879/files - new: https://git.openjdk.org/jdk/pull/26879/files/cefb9948..10404cea Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26879&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26879&range=01-02 Stats: 14 lines in 1 file changed: 1 ins; 1 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/26879.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26879/head:pull/26879 PR: https://git.openjdk.org/jdk/pull/26879 From ayang at openjdk.org Mon Aug 25 14:11:58 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 25 Aug 2025 14:11:58 GMT Subject: RFR: 8365919: Replace currentTimeMillis with nanoTime in Stresser.java [v2] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 18:37:47 GMT, Albert Mingkun Yang wrote: >> Mostly a mechanic change from `currentTimeMillis()` to `nanoTime()/1000000`. It also removes `finishTime` to avoid overflowing. >> >> The change in `iteration()` is to ensure `currentTime` is properly initialized. >> >> (Was investigating a timeout on Windows-x64, which led me to this code. I think this fix is good enough by its own.) >> >> Test: tier1-5 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - review > - Merge branch 'master' into test-nano-time > - test-nano-time I have changed to use nanoseconds for all fields, to avoid excessive unit conversion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26879#issuecomment-3220455460 From ayang at openjdk.org Mon Aug 25 14:16:59 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 25 Aug 2025 14:16:59 GMT Subject: RFR: 8365994: ZGC: Incorrect type signature in ZMappedCache comparator In-Reply-To: <_nBhAdONXQ_QsOXGW1pwBiu4nb_pCS_wcp57lyNXMXA=.4c7e21f1-45e2-420c-8919-989a20622d57@github.com> References: <_nBhAdONXQ_QsOXGW1pwBiu4nb_pCS_wcp57lyNXMXA=.4c7e21f1-45e2-420c-8919-989a20622d57@github.com> Message-ID: On Fri, 22 Aug 2025 15:08:42 GMT, Joel Sikstr?m wrote: > Hello, > > The comparator with two IntrusiveRBNode* in ZMappedCache has the incorrent type signature. This prevents IntrusiveRBTree from using the comparator as intended during validation, resulting in it using the fallback verify function, which always returns true. This could mask potential issues in the tree structure. > > Testing: > * Manually placing an assert in the fallback verify function to see if it is used. It is no longer used with this patch. > * Oracle's tier 1-2 src/hotspot/share/gc/z/zMappedCache.hpp line 44: > 42: struct EntryCompare { > 43: static int cmp(zoffset a, const IntrusiveRBNode* b); > 44: static bool cmp(const IntrusiveRBNode* a, const IntrusiveRBNode* b); I'd expect `cmp` to return `int`; otherwise, the `cmp` name is rather misleading. I wonder if rbtree can be changed so that all `cmp` methods return `int` instead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26904#discussion_r2298236455 From jsikstro at openjdk.org Mon Aug 25 15:00:29 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Mon, 25 Aug 2025 15:00:29 GMT Subject: RFR: 8359683: ZGC: NUMA-Aware Relocation [v4] In-Reply-To: <_SnXFrT1StlCj4JYdTfY-S6tPa6dsi-p6VfMl01te7k=.1cabcd48-3709-4b3c-9ea8-3fc122c505fe@github.com> References: <_SnXFrT1StlCj4JYdTfY-S6tPa6dsi-p6VfMl01te7k=.1cabcd48-3709-4b3c-9ea8-3fc122c505fe@github.com> Message-ID: > Hello, > > With [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441), ZGC got infrastructure to prefer allocations to end up on a specific NUMA node. When a new object is allocated, it is preferably placed on the NUMA node that is local to the allocating thread. This strategy improves access speeds for mutators working on that object, if it continues to be used by threads on the same NUMA node. However, when relocating objects, ZGC will potentially move (migrate) objects away from the NUMA node they were originally allocated on. This means that if a page is selected as part of the Relocation Set, the objects on that page could potentially be moved to another NUMA node, breaking the NUMA locality we strived for when allocating. > > We should consider adding NUMA-awareness to ZGC's relocation phase to keep NUMA-locality benefits for mutators. > >
> > Proposal (expandable section) > > NUMA-Awareness consists of two main features: > > **First**: GC threads should strive toward keeping the NUMA locality of objects to their original node, meaning that objects should ideally be relocated to a page that is on the same NUMA node. > > Mutator threads should have a different approach, as we know that the mutator that's (helping out with) relocating an object is also going to access it, so we migrate the object to the NUMA node associated with the relocating thread. This strategy is already in effect and does not require any changes to the code (specifically, ZObjectAllocator already track per-CPU specific Small pages). However, Medium pages are shared between CPUs and thus does not hold any guarantees on which NUMA node it is on. Combined, both mutator and Medium page relocation are not common, and thus there is little gain from introducing NUMA-awareness to that specific scenario. Instead, this can be addressed in a follow-up if we feel that's necessary. > > **Second**: When the GC chooses a page from the Relocation Set to relocate objects from, it should choose page(s) that are local to the same NUMA node, to speed up performance by working on NUMA-local memory. There are multiple ways to achieve this, but the main goal should be to (1) start working on pages that are local to the GC thread's NUMA node, and (2) when finished with pages on its own NUMA node, start working (help out) with pages associated with other NUMA nodes. > > Some key observations to consider with the above approach: > > * The NUMA node associated with the GC thread should be "polle... Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/share/gc/z/zPageAllocator.cpp Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26898/files - new: https://git.openjdk.org/jdk/pull/26898/files/ac8a76ea..247ef485 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26898&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26898&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26898/head:pull/26898 PR: https://git.openjdk.org/jdk/pull/26898 From jsikstro at openjdk.org Mon Aug 25 15:00:29 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Mon, 25 Aug 2025 15:00:29 GMT Subject: RFR: 8359683: ZGC: NUMA-Aware Relocation [v3] In-Reply-To: References: <_SnXFrT1StlCj4JYdTfY-S6tPa6dsi-p6VfMl01te7k=.1cabcd48-3709-4b3c-9ea8-3fc122c505fe@github.com> Message-ID: On Mon, 25 Aug 2025 13:07:08 GMT, Stefan Johansson wrote: >> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: >> >> Rename initiating_numa_id to preferred_partition > > src/hotspot/share/gc/z/zPageAllocator.cpp line 2200: > >> 2198: is_multi_partition_enabled() && >> 2199: sum_available() >= allocation->size(); >> 2200: } > > Thanks for addressing my comments, if I'm being picky I would prefer this order of the statements. If you prefer the current I'm ok with this as well. > > Suggestion: > > return is_multi_partition_enabled() && > allocation->type() == ZPageType::large && > allocation->size() <= sum_available(); > } I agree! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26898#discussion_r2298348869 From jsikstro at openjdk.org Mon Aug 25 15:07:52 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Mon, 25 Aug 2025 15:07:52 GMT Subject: RFR: 8359683: ZGC: NUMA-Aware Relocation [v3] In-Reply-To: References: <_SnXFrT1StlCj4JYdTfY-S6tPa6dsi-p6VfMl01te7k=.1cabcd48-3709-4b3c-9ea8-3fc122c505fe@github.com> Message-ID: On Mon, 25 Aug 2025 13:13:19 GMT, Stefan Johansson wrote: > Looks good, did you look anything at changing the iterators to make it possible having something like `_iters.reset()` in the constructor for `ZRelocateTask`. This could also be done as a followup. I tested out and discussed some potential alternatives with Axel and we both agreed that a nice solution to this would be better implemented in a follow-up. We envisioned something where we can reset the state of an iterator, without destructing and constructing them like we do in this patch. This would require control over changing the iterator's internal state. Another solution is to use malloc to allocate/free the array before/after every GC cycle, but I prefer the current solution more. I expanded upon the comment next to destructing the iterators, which I hope is a good compromise until a nicer solution is in place. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26898#issuecomment-3220659696 From aboldtch at openjdk.org Mon Aug 25 15:24:53 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 25 Aug 2025 15:24:53 GMT Subject: RFR: 8365994: ZGC: Incorrect type signature in ZMappedCache comparator In-Reply-To: References: <_nBhAdONXQ_QsOXGW1pwBiu4nb_pCS_wcp57lyNXMXA=.4c7e21f1-45e2-420c-8919-989a20622d57@github.com> Message-ID: On Mon, 25 Aug 2025 14:14:35 GMT, Albert Mingkun Yang wrote: >> Hello, >> >> The comparator with two IntrusiveRBNode* in ZMappedCache has the incorrent type signature. This prevents IntrusiveRBTree from using the comparator as intended during validation, resulting in it using the fallback verify function, which always returns true. This could mask potential issues in the tree structure. >> >> Testing: >> * Manually placing an assert in the fallback verify function to see if it is used. It is no longer used with this patch. >> * Oracle's tier 1-2 > > src/hotspot/share/gc/z/zMappedCache.hpp line 44: > >> 42: struct EntryCompare { >> 43: static int cmp(zoffset a, const IntrusiveRBNode* b); >> 44: static bool cmp(const IntrusiveRBNode* a, const IntrusiveRBNode* b); > > I'd expect `cmp` to return `int`; otherwise, the `cmp` name is rather misleading. I wonder if rbtree can be changed so that all `cmp` methods return `int` instead. I tend to agree, or rename it to `less`. And I think `cmp` should even return a more strongly typed class, rather than `int` to discourage code like `return b - a;` as you have to be very careful to not introduce underflow arithmetic bugs. Maybe even take inspiration from `operator<=>` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26904#discussion_r2298416095 From mark.reinhold at oracle.com Mon Aug 25 16:26:18 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Mon, 25 Aug 2025 16:26:18 +0000 Subject: New candidate JEP: 522: G1 GC: Improve Throughput by Reducing Synchronization Message-ID: <20250825162539.3368C346@naskeag.niobe.net> https://openjdk.org/jeps/522 Summary: Increase application throughput when using the G1 garbage collector by reducing the amount of synchronization required between application threads and GC threads. - Mark From phh at openjdk.org Mon Aug 25 17:16:38 2025 From: phh at openjdk.org (Paul Hohensee) Date: Mon, 25 Aug 2025 17:16:38 GMT Subject: RFR: 8365919: Replace currentTimeMillis with nanoTime in Stresser.java [v3] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 14:09:13 GMT, Albert Mingkun Yang wrote: >> Mostly a mechanic change from `currentTimeMillis()` to `nanoTime()/1000000`. It also removes `finishTime` to avoid overflowing. >> >> The change in `iteration()` is to ensure `currentTime` is properly initialized. >> >> (Was investigating a timeout on Windows-x64, which led me to this code. I think this fix is good enough by its own.) >> >> Test: tier1-5 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Marked as reviewed by phh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26879#pullrequestreview-3152368046 From wkemper at openjdk.org Mon Aug 25 17:23:11 2025 From: wkemper at openjdk.org (William Kemper) Date: Mon, 25 Aug 2025 17:23:11 GMT Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may raise threshold prematurely [v3] In-Reply-To: References: Message-ID: > The adaptive tenuring algorithm has been modified to begin its evaluation of mortality rates from the current tenuring threshold. To compliment this change, objects must also now be strictly above the tenuring threshold to be promoted (instead of greater-than-or-equal). William Kemper has updated the pull request incrementally with one additional commit since the last revision: Fix windows build ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26906/files - new: https://git.openjdk.org/jdk/pull/26906/files/8b2fb41a..b9e16d26 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26906&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26906&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26906.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26906/head:pull/26906 PR: https://git.openjdk.org/jdk/pull/26906 From ghan at openjdk.org Tue Aug 26 06:32:56 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Tue, 26 Aug 2025 06:32:56 GMT Subject: RFR: 8352969: G1: Improve testability of optional collections [v3] In-Reply-To: References: Message-ID: <1fNzfZ2HlfWuS2tMoENBL5Xp3wZH8XUxiXB-soC85r0=.915bb437-5655-4b21-89c4-f0a07b70c072@github.com> > This PR introduces a new diagnostic flag EvacuateAllOptionalRegions to force G1 GC to evacuate all optional regions regardless of the predicted pause time. The motivation is to allow testing and validation of optional region evacuation behavior without being constrained by the remaining pause time. Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: Update g1YoungCollector.cpp format fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26880/files - new: https://git.openjdk.org/jdk/pull/26880/files/6661deef..fc13c5e0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26880&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26880&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26880.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26880/head:pull/26880 PR: https://git.openjdk.org/jdk/pull/26880 From tschatzl at openjdk.org Tue Aug 26 07:00:44 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 26 Aug 2025 07:00:44 GMT Subject: Integrated: 8365656: [ubsan] G1CSetCandidateGroup::liveness() reports division by 0 In-Reply-To: References: Message-ID: On Thu, 21 Aug 2025 16:13:10 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that fixes a div-by-zero in calculating liveness for logging. > > It is possible that the young gen group cardset is empty (has no regions assigned to it as no eden region has retired yet) when the `Cleanup` pause starts, making the liveness calculation divide by zero. > > The change special-cases this case when printing - I decided to always print the group in this case, regardless of length, just fudging the output value a bit. An alternative would be not printing it at all in this case. Feel free to argue for that solution. Also the printed value for liveness (0.0%) is up for discussion. > > Testing: failing test case does not fail any more now and then, gha, tier1-4 > > Thanks, > Thomas This pull request has now been integrated. Changeset: e38c6f98 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/e38c6f9827c15777361dd1c7ce420f020f5de313 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod 8365656: [ubsan] G1CSetCandidateGroup::liveness() reports division by 0 Reviewed-by: iwalulya, ayang ------------- PR: https://git.openjdk.org/jdk/pull/26888 From tschatzl at openjdk.org Tue Aug 26 07:00:43 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 26 Aug 2025 07:00:43 GMT Subject: RFR: 8365656: [ubsan] G1CSetCandidateGroup::liveness() reports division by 0 [v5] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 12:02:43 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * use double-sized 0.0 constants > > Marked as reviewed by ayang (Reviewer). Thanks @albertnetymk @walulyai (and @fandreuz) for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/26888#issuecomment-3222870414 From tschatzl at openjdk.org Tue Aug 26 07:17:36 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 26 Aug 2025 07:17:36 GMT Subject: RFR: 8365919: Replace currentTimeMillis with nanoTime in Stresser.java [v3] In-Reply-To: References: Message-ID: <2fiNgy3tAehxBdVMVImAvgIXxTDzvkn9ZXLJpm91-dw=.6b11ddd2-9f23-481d-ba8c-6280be39d761@github.com> On Mon, 25 Aug 2025 14:09:13 GMT, Albert Mingkun Yang wrote: >> Mostly a mechanic change from `currentTimeMillis()` to `nanoTime()/1000000`. It also removes `finishTime` to avoid overflowing. >> >> The change in `iteration()` is to ensure `currentTime` is properly initialized. >> >> (Was investigating a timeout on Windows-x64, which led me to this code. I think this fix is good enough by its own.) >> >> Test: tier1-5 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Changes requested by tschatzl (Reviewer). test/hotspot/jtreg/vmTestbase/nsk/share/test/Stresser.java line 185: > 183: public void printExecutionInfo(PrintStream out) { > 184: println(out, "Completed iterations: " + iterations); > 185: println(out, "Execution time: " + (currentTime - startTime)/1_000_000_000.0 + " seconds"); Suggestion: println(out, "Execution time: " + (currentTime - startTime) / 1_000_000_000.0 + " seconds"); ------------- PR Review: https://git.openjdk.org/jdk/pull/26879#pullrequestreview-3154208625 PR Review Comment: https://git.openjdk.org/jdk/pull/26879#discussion_r2299984613 From ayang at openjdk.org Tue Aug 26 07:42:56 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 26 Aug 2025 07:42:56 GMT Subject: RFR: 8365919: Replace currentTimeMillis with nanoTime in Stresser.java [v4] In-Reply-To: References: Message-ID: > Mostly a mechanic change from `currentTimeMillis()` to `nanoTime()/1000000`. It also removes `finishTime` to avoid overflowing. > > The change in `iteration()` is to ensure `currentTime` is properly initialized. > > (Was investigating a timeout on Windows-x64, which led me to this code. I think this fix is good enough by its own.) > > Test: tier1-5 Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - review - Merge branch 'master' into test-nano-time - review - review - Merge branch 'master' into test-nano-time - test-nano-time ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26879/files - new: https://git.openjdk.org/jdk/pull/26879/files/10404cea..994e3fe3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26879&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26879&range=02-03 Stats: 1536 lines in 74 files changed: 777 ins; 544 del; 215 mod Patch: https://git.openjdk.org/jdk/pull/26879.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26879/head:pull/26879 PR: https://git.openjdk.org/jdk/pull/26879 From tschatzl at openjdk.org Tue Aug 26 08:15:34 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 26 Aug 2025 08:15:34 GMT Subject: RFR: 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 Seems good. ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26779#pullrequestreview-3154491619 From tschatzl at openjdk.org Tue Aug 26 08:17:37 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 26 Aug 2025 08:17:37 GMT Subject: RFR: 8365919: Replace currentTimeMillis with nanoTime in Stresser.java [v4] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 07:42:56 GMT, Albert Mingkun Yang wrote: >> Mostly a mechanic change from `currentTimeMillis()` to `nanoTime()/1000000`. It also removes `finishTime` to avoid overflowing. >> >> The change in `iteration()` is to ensure `currentTime` is properly initialized. >> >> (Was investigating a timeout on Windows-x64, which led me to this code. I think this fix is good enough by its own.) >> >> Test: tier1-5 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - review > - Merge branch 'master' into test-nano-time > - review > - review > - Merge branch 'master' into test-nano-time > - test-nano-time Marked as reviewed by tschatzl (Reviewer). Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26879#pullrequestreview-3154493898 PR Review: https://git.openjdk.org/jdk/pull/26879#pullrequestreview-3154496012 From tschatzl at openjdk.org Tue Aug 26 08:18:36 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 26 Aug 2025 08:18:36 GMT Subject: RFR: 8365922: Parallel: Group uses of GCTimeRatio to a single location In-Reply-To: References: Message-ID: 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 src/hotspot/share/gc/parallel/psAdaptiveSizePolicy.cpp line 90: > 88: > 89: // Get a local copy and use it inside gc-pause in case the global var gets updated externally. > 90: const uint local_GCTimeRatio = GCTimeRatio; needs an `Atomic::load()` as the compiler is free to re-read the global later at any use of the local. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26881#discussion_r2300191830 From ayang at openjdk.org Tue Aug 26 08:24:38 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 26 Aug 2025 08:24:38 GMT Subject: RFR: 8365922: Parallel: Group uses of GCTimeRatio to a single location In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 08:16:25 GMT, Thomas Schatzl 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 > > src/hotspot/share/gc/parallel/psAdaptiveSizePolicy.cpp line 90: > >> 88: >> 89: // Get a local copy and use it inside gc-pause in case the global var gets updated externally. >> 90: const uint local_GCTimeRatio = GCTimeRatio; > > needs an `Atomic::load()` as the compiler is free to re-read the global later at any use of the local. I was thinking to add that when this flag actually becomes manageable. I don't feel too strongly about it. Do you prefer using atomic already now? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26881#discussion_r2300206747 From tschatzl at openjdk.org Tue Aug 26 08:25:33 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 26 Aug 2025 08:25:33 GMT Subject: RFR: 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. Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26922#pullrequestreview-3154523400 From ghan at openjdk.org Tue Aug 26 08:38:39 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Tue, 26 Aug 2025 08:38:39 GMT Subject: RFR: 8366035: Simplify CPUTimeCounters::publish_gc_total_cpu_time [v2] In-Reply-To: References: Message-ID: <9OwgKIyEKxxfUjTtlUz7t0SMvvG40hFod-YUzXcFT8U=.49dcd745-341d-4664-b921-498fb54f35a0@github.com> On Mon, 25 Aug 2025 09:11:45 GMT, Albert Mingkun Yang wrote: >> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: >> >> Update cpuTimeCounters.cpp >> >> a small fix > > Marked as reviewed by ayang (Reviewer). @albertnetymk @kimbarrett Thanks for your reviews! I?ve integrated this PR. Could you please sponsor it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26921#issuecomment-3223168189 From ghan at openjdk.org Tue Aug 26 08:38:40 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Tue, 26 Aug 2025 08:38:40 GMT Subject: Integrated: 8366035: Simplify CPUTimeCounters::publish_gc_total_cpu_time In-Reply-To: References: Message-ID: <0TIULUzP9Wjql9Wy3-kRj_jcK6Vt7Cm8HGqTwtyTDJ4=.8105d994-9038-4778-ab8c-349fdbfe3e48@github.com> On Mon, 25 Aug 2025 08:10:17 GMT, Guanqiang Han wrote: > This change refactors CPUTimeCounters::publish_gc_total_cpu_time() to use Atomic::xchg instead of a CAS (cmpxchg) loop. > Please review it. Thanks This pull request has now been integrated. Changeset: 2ae3ea2a Author: Guanqiang Han Committer: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/2ae3ea2ad93b83deec1922159d80b94da0397357 Stats: 8 lines in 1 file changed: 0 ins; 6 del; 2 mod 8366035: Simplify CPUTimeCounters::publish_gc_total_cpu_time Reviewed-by: ayang, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/26921 From jsikstro at openjdk.org Tue Aug 26 08:57:41 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Tue, 26 Aug 2025 08:57:41 GMT Subject: RFR: 8365994: ZGC: Incorrect type signature in ZMappedCache comparator In-Reply-To: References: <_nBhAdONXQ_QsOXGW1pwBiu4nb_pCS_wcp57lyNXMXA=.4c7e21f1-45e2-420c-8919-989a20622d57@github.com> Message-ID: On Fri, 22 Aug 2025 15:13:35 GMT, Casper Norrbin wrote: >> Hello, >> >> The comparator with two IntrusiveRBNode* in ZMappedCache has the incorrent type signature. This prevents IntrusiveRBTree from using the comparator as intended during validation, resulting in it using the fallback verify function, which always returns true. This could mask potential issues in the tree structure. >> >> Testing: >> * Manually placing an assert in the fallback verify function to see if it is used. It is no longer used with this patch. >> * Oracle's tier 1-2 > > Looks good! Thank you for the reviews! @caspernorrbin @xmas92 ------------- PR Comment: https://git.openjdk.org/jdk/pull/26904#issuecomment-3223242045 From jsikstro at openjdk.org Tue Aug 26 08:57:43 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Tue, 26 Aug 2025 08:57:43 GMT Subject: RFR: 8365994: ZGC: Incorrect type signature in ZMappedCache comparator In-Reply-To: References: <_nBhAdONXQ_QsOXGW1pwBiu4nb_pCS_wcp57lyNXMXA=.4c7e21f1-45e2-420c-8919-989a20622d57@github.com> Message-ID: <8-T0HWnowQCj4zxZiSx03QhLFwYWxpyP_KLp1LCBDag=.fa8955bc-e5cc-487f-a6e7-3683ae1931b3@github.com> On Mon, 25 Aug 2025 15:22:21 GMT, Axel Boldt-Christmas wrote: >> src/hotspot/share/gc/z/zMappedCache.hpp line 44: >> >>> 42: struct EntryCompare { >>> 43: static int cmp(zoffset a, const IntrusiveRBNode* b); >>> 44: static bool cmp(const IntrusiveRBNode* a, const IntrusiveRBNode* b); >> >> I'd expect `cmp` to return `int`; otherwise, the `cmp` name is rather misleading. I wonder if rbtree can be changed so that all `cmp` methods return `int` instead. > > I tend to agree, or rename it to `less`. > > And I think `cmp` should even return a more strongly typed class, rather than `int` to discourage code like `return b - a;` as you have to be very careful to not introduce underflow arithmetic bugs. Maybe even take inspiration from `operator<=>` I agree with both of you that there is room for improvement here. I've talked with @caspernorrbin, who is the author of the tree, and we've agreed that he will address this feedback in a follow-up. I'll go ahead and integrate this change so that the comparator we have in ZGC is aligned with the (current) type signature and we verify the tree correctly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26904#discussion_r2300289687 From jsikstro at openjdk.org Tue Aug 26 08:57:43 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Tue, 26 Aug 2025 08:57:43 GMT Subject: Integrated: 8365994: ZGC: Incorrect type signature in ZMappedCache comparator In-Reply-To: <_nBhAdONXQ_QsOXGW1pwBiu4nb_pCS_wcp57lyNXMXA=.4c7e21f1-45e2-420c-8919-989a20622d57@github.com> References: <_nBhAdONXQ_QsOXGW1pwBiu4nb_pCS_wcp57lyNXMXA=.4c7e21f1-45e2-420c-8919-989a20622d57@github.com> Message-ID: On Fri, 22 Aug 2025 15:08:42 GMT, Joel Sikstr?m wrote: > Hello, > > The comparator with two IntrusiveRBNode* in ZMappedCache has the incorrent type signature. This prevents IntrusiveRBTree from using the comparator as intended during validation, resulting in it using the fallback verify function, which always returns true. This could mask potential issues in the tree structure. > > Testing: > * Manually placing an assert in the fallback verify function to see if it is used. It is no longer used with this patch. > * Oracle's tier 1-2 This pull request has now been integrated. Changeset: 3641c32c Author: Joel Sikstr?m URL: https://git.openjdk.org/jdk/commit/3641c32c11aa3768ce986d5dcd5393b74f776228 Stats: 8 lines in 2 files changed: 0 ins; 3 del; 5 mod 8365994: ZGC: Incorrect type signature in ZMappedCache comparator Reviewed-by: cnorrbin, aboldtch ------------- PR: https://git.openjdk.org/jdk/pull/26904 From tschatzl at openjdk.org Tue Aug 26 09:08:39 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 26 Aug 2025 09:08:39 GMT Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing [v4] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 12:43:46 GMT, Ivan Walulya wrote: >> Hi, >> >> Please review this patch which takes into account the impact of concurrent GC activity on mutator threads when computing the time spent on GC activity in a time interval. Previously, only the GC pause times were considered, and the overhead imposed by concurrent GC worker threads was not included. >> >> With this change, we now estimate the impact of concurrent GC by dividing `elapsed_gc_cpu_time` by the number of CPUs. This provides an approximation of the additional time attributable to GC activity, assuming a fair CPU resource sharing. Although this method does not account for contention on other shared resources (such as memory bandwidth or caches), it offers a reasonable estimate for most scenarios. >> >> Testing: Tier 1 > > Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Merge remote-tracking branch 'upstream/master' into ConcCPUImpact > - accumlate concurrent_gc_impact_time > - Merge remote-tracking branch 'upstream/master' into ConcCPUImpact > - cleanup after merge > - Merge remote-tracking branch 'upstream/master' into ConcCPUImpact > - Merge branch 'NormalizeTiming' into ConcCPUImpact > - Thomas suggestion > - Thomas Review > - reorder > - concurrent gc impact > - ... and 2 more: https://git.openjdk.org/jdk/compare/999761d0...c65429ad Looks good. src/hotspot/share/gc/g1/g1Analytics.hpp line 142: > 140: return _concurrent_gc_cpu_time_ms; > 141: } > 142: Now this method is unused :) ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26351#pullrequestreview-3154659056 PR Review Comment: https://git.openjdk.org/jdk/pull/26351#discussion_r2300305738 From sjohanss at openjdk.org Tue Aug 26 09:48:36 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Tue, 26 Aug 2025 09:48:36 GMT Subject: RFR: 8359683: ZGC: NUMA-Aware Relocation [v4] In-Reply-To: References: <_SnXFrT1StlCj4JYdTfY-S6tPa6dsi-p6VfMl01te7k=.1cabcd48-3709-4b3c-9ea8-3fc122c505fe@github.com> Message-ID: On Mon, 25 Aug 2025 15:00:29 GMT, Joel Sikstr?m wrote: >> Hello, >> >> With [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441), ZGC got infrastructure to prefer allocations to end up on a specific NUMA node. When a new object is allocated, it is preferably placed on the NUMA node that is local to the allocating thread. This strategy improves access speeds for mutators working on that object, if it continues to be used by threads on the same NUMA node. However, when relocating objects, ZGC will potentially move (migrate) objects away from the NUMA node they were originally allocated on. This means that if a page is selected as part of the Relocation Set, the objects on that page could potentially be moved to another NUMA node, breaking the NUMA locality we strived for when allocating. >> >> We should consider adding NUMA-awareness to ZGC's relocation phase to keep NUMA-locality benefits for mutators. >> >>
>> >> Proposal (expandable section) >> >> NUMA-Awareness consists of two main features: >> >> **First**: GC threads should strive toward keeping the NUMA locality of objects to their original node, meaning that objects should ideally be relocated to a page that is on the same NUMA node. >> >> Mutator threads should have a different approach, as we know that the mutator that's (helping out with) relocating an object is also going to access it, so we migrate the object to the NUMA node associated with the relocating thread. This strategy is already in effect and does not require any changes to the code (specifically, ZObjectAllocator already track per-CPU specific Small pages). However, Medium pages are shared between CPUs and thus does not hold any guarantees on which NUMA node it is on. Combined, both mutator and Medium page relocation are not common, and thus there is little gain from introducing NUMA-awareness to that specific scenario. Instead, this can be addressed in a follow-up if we feel that's necessary. >> >> **Second**: When the GC chooses a page from the Relocation Set to relocate objects from, it should choose page(s) that are local to the same NUMA node, to speed up performance by working on NUMA-local memory. There are multiple ways to achieve this, but the main goal should be to (1) start working on pages that are local to the GC thread's NUMA node, and (2) when finished with pages on its own NUMA node, start working (help out) with pages associated with other NUMA nodes. >> >> Some key observations to consider with the above approach: >> >> * The NUMA node asso... > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/share/gc/z/zPageAllocator.cpp > > Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com> Marked as reviewed by sjohanss (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26898#pullrequestreview-3154854509 From ayang at openjdk.org Tue Aug 26 10:06:41 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 26 Aug 2025 10:06:41 GMT Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing [v4] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 12:43:46 GMT, Ivan Walulya wrote: >> Hi, >> >> Please review this patch which takes into account the impact of concurrent GC activity on mutator threads when computing the time spent on GC activity in a time interval. Previously, only the GC pause times were considered, and the overhead imposed by concurrent GC worker threads was not included. >> >> With this change, we now estimate the impact of concurrent GC by dividing `elapsed_gc_cpu_time` by the number of CPUs. This provides an approximation of the additional time attributable to GC activity, assuming a fair CPU resource sharing. Although this method does not account for contention on other shared resources (such as memory bandwidth or caches), it offers a reasonable estimate for most scenarios. >> >> Testing: Tier 1 > > Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Merge remote-tracking branch 'upstream/master' into ConcCPUImpact > - accumlate concurrent_gc_impact_time > - Merge remote-tracking branch 'upstream/master' into ConcCPUImpact > - cleanup after merge > - Merge remote-tracking branch 'upstream/master' into ConcCPUImpact > - Merge branch 'NormalizeTiming' into ConcCPUImpact > - Thomas suggestion > - Thomas Review > - reorder > - concurrent gc impact > - ... and 2 more: https://git.openjdk.org/jdk/compare/999761d0...c65429ad Marked as reviewed by ayang (Reviewer). src/hotspot/share/gc/g1/g1Analytics.cpp line 167: > 165: // caches, therefore underestimate the impact of the concurrent GC activity on mutator threads. > 166: uint num_cpus = (uint)os::active_processor_count(); > 167: double concurrent_gc_impact_time = _concurrent_gc_cpu_time_ms / num_cpus; I'd expect to see `ConcGCThreads` somewhere in the formula, but maybe this is enough. src/hotspot/share/gc/g1/g1Analytics.cpp line 322: > 320: > 321: void G1Analytics::update_recent_gc_times(double end_time_sec, > 322: double elapsed_ms) { The caller uses `gc_time_ms`. I feel that's more descriptive than this. src/hotspot/share/gc/g1/g1Analytics.hpp line 49: > 47: double _prev_collection_pause_end_ms; > 48: double _gc_cpu_time_pause_end_ms; > 49: double _concurrent_gc_cpu_time_ms; How about `_gc_cpu_time_at_pause_end_ms`? Additionally, maybe some doc on these two fields, what they track and when they are updated, sth like: """ 1 tracks the total gc-cpu-time at the end of a gc-pause. 2 tracks the conc gc-cpu-time, updated at the beginning of a gc-pause. """ ------------- PR Review: https://git.openjdk.org/jdk/pull/26351#pullrequestreview-3154875538 PR Review Comment: https://git.openjdk.org/jdk/pull/26351#discussion_r2300489543 PR Review Comment: https://git.openjdk.org/jdk/pull/26351#discussion_r2300457503 PR Review Comment: https://git.openjdk.org/jdk/pull/26351#discussion_r2300482872 From lkorinth at openjdk.org Tue Aug 26 11:27:44 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 26 Aug 2025 11:27:44 GMT Subject: RFR: 8366145: Help diagnose ubsan failure Message-ID: <1hYLqTPwBlVCBFe09QMtJi7JHemtDnniTsEPbWvM5yI=.9a8ccf7a-20db-4517-9aaa-6020b0cfbf99@github.com> This pull request is created to help diagnose the bug report https://bugs.openjdk.org/browse/JDK-8354430. The problem is that we get a ubsan runtime error when dividing by zero. Ubsan is not normally running, so I will add an assert making it easier to catch the problem and printing the value of the two variables that when subtracted will create a zero; it will hopefully help with diagnosis. Some comments: 1) the result of most_recent_gc_end_time_sec() will not change within the function, thus I will clutter the code with a new variable, is that okay? 2) I added two calls to `fabs` which are most probably not needed (ieee floating point rules seems to say that positive and negative zero equals). However I think my proposed code makes it clear that I have thought about it. I am now running tier1-3 ------------- Commit messages: - 8366145: Help diagnose ubsan failure Changes: https://git.openjdk.org/jdk/pull/26939/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26939&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366145 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26939.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26939/head:pull/26939 PR: https://git.openjdk.org/jdk/pull/26939 From duke at openjdk.org Tue Aug 26 12:54:34 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Tue, 26 Aug 2025 12:54:34 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 src/hotspot/share/gc/serial/serialHeap.cpp line 286: > 284: > 285: HeapWord* SerialHeap::expand_heap_and_allocate(size_t size, bool is_tlab) { > 286: HeapWord* result = _young_gen->allocate(size); The order of `_young_gen->allocate` and `old_gen->expand_and_allocate` is reversed now. It used to be `_old_gen->expand_and_allocate == nullptr --> _young_gen->allocate`, now it's the other way around. Is that intended? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26941#discussion_r2300894601 From jsikstro at openjdk.org Tue Aug 26 13:03:31 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Tue, 26 Aug 2025 13:03:31 GMT Subject: RFR: 8359683: ZGC: NUMA-Aware Relocation [v5] In-Reply-To: <_SnXFrT1StlCj4JYdTfY-S6tPa6dsi-p6VfMl01te7k=.1cabcd48-3709-4b3c-9ea8-3fc122c505fe@github.com> References: <_SnXFrT1StlCj4JYdTfY-S6tPa6dsi-p6VfMl01te7k=.1cabcd48-3709-4b3c-9ea8-3fc122c505fe@github.com> Message-ID: > Hello, > > With [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441), ZGC got infrastructure to prefer allocations to end up on a specific NUMA node. When a new object is allocated, it is preferably placed on the NUMA node that is local to the allocating thread. This strategy improves access speeds for mutators working on that object, if it continues to be used by threads on the same NUMA node. However, when relocating objects, ZGC will potentially move (migrate) objects away from the NUMA node they were originally allocated on. This means that if a page is selected as part of the Relocation Set, the objects on that page could potentially be moved to another NUMA node, breaking the NUMA locality we strived for when allocating. > > We should consider adding NUMA-awareness to ZGC's relocation phase to keep NUMA-locality benefits for mutators. > >
> > Proposal (expandable section) > > NUMA-Awareness consists of two main features: > > **First**: GC threads should strive toward keeping the NUMA locality of objects to their original node, meaning that objects should ideally be relocated to a page that is on the same NUMA node. > > Mutator threads should have a different approach, as we know that the mutator that's (helping out with) relocating an object is also going to access it, so we migrate the object to the NUMA node associated with the relocating thread. This strategy is already in effect and does not require any changes to the code (specifically, ZObjectAllocator already track per-CPU specific Small pages). However, Medium pages are shared between CPUs and thus does not hold any guarantees on which NUMA node it is on. Combined, both mutator and Medium page relocation are not common, and thus there is little gain from introducing NUMA-awareness to that specific scenario. Instead, this can be addressed in a follow-up if we feel that's necessary. > > **Second**: When the GC chooses a page from the Relocation Set to relocate objects from, it should choose page(s) that are local to the same NUMA node, to speed up performance by working on NUMA-local memory. There are multiple ways to achieve this, but the main goal should be to (1) start working on pages that are local to the GC thread's NUMA node, and (2) when finished with pages on its own NUMA node, start working (help out) with pages associated with other NUMA nodes. > > Some key observations to consider with the above approach: > > * The NUMA node associated with the GC thread should be "polle... Joel Sikstr?m has updated the pull request incrementally with two additional commits since the last revision: - Make shared stats variable volatile - Remove friend class for ZRelocateTask and add accessor ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26898/files - new: https://git.openjdk.org/jdk/pull/26898/files/247ef485..f09cb290 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26898&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26898&range=03-04 Stats: 9 lines in 3 files changed: 6 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26898/head:pull/26898 PR: https://git.openjdk.org/jdk/pull/26898 From jsikstro at openjdk.org Tue Aug 26 13:03:33 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Tue, 26 Aug 2025 13:03:33 GMT Subject: RFR: 8359683: ZGC: NUMA-Aware Relocation [v4] In-Reply-To: References: <_SnXFrT1StlCj4JYdTfY-S6tPa6dsi-p6VfMl01te7k=.1cabcd48-3709-4b3c-9ea8-3fc122c505fe@github.com> Message-ID: <-e3dVX-bIOC0S0h34DSmQY9JFVZSi2c7VpRr2W7T0LU=.3cc4baa6-f382-44a9-abd6-a6cebd2fb66b@github.com> On Mon, 25 Aug 2025 15:00:29 GMT, Joel Sikstr?m wrote: >> Hello, >> >> With [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441), ZGC got infrastructure to prefer allocations to end up on a specific NUMA node. When a new object is allocated, it is preferably placed on the NUMA node that is local to the allocating thread. This strategy improves access speeds for mutators working on that object, if it continues to be used by threads on the same NUMA node. However, when relocating objects, ZGC will potentially move (migrate) objects away from the NUMA node they were originally allocated on. This means that if a page is selected as part of the Relocation Set, the objects on that page could potentially be moved to another NUMA node, breaking the NUMA locality we strived for when allocating. >> >> We should consider adding NUMA-awareness to ZGC's relocation phase to keep NUMA-locality benefits for mutators. >> >>
>> >> Proposal (expandable section) >> >> NUMA-Awareness consists of two main features: >> >> **First**: GC threads should strive toward keeping the NUMA locality of objects to their original node, meaning that objects should ideally be relocated to a page that is on the same NUMA node. >> >> Mutator threads should have a different approach, as we know that the mutator that's (helping out with) relocating an object is also going to access it, so we migrate the object to the NUMA node associated with the relocating thread. This strategy is already in effect and does not require any changes to the code (specifically, ZObjectAllocator already track per-CPU specific Small pages). However, Medium pages are shared between CPUs and thus does not hold any guarantees on which NUMA node it is on. Combined, both mutator and Medium page relocation are not common, and thus there is little gain from introducing NUMA-awareness to that specific scenario. Instead, this can be addressed in a follow-up if we feel that's necessary. >> >> **Second**: When the GC chooses a page from the Relocation Set to relocate objects from, it should choose page(s) that are local to the same NUMA node, to speed up performance by working on NUMA-local memory. There are multiple ways to achieve this, but the main goal should be to (1) start working on pages that are local to the GC thread's NUMA node, and (2) when finished with pages on its own NUMA node, start working (help out) with pages associated with other NUMA nodes. >> >> Some key observations to consider with the above approach: >> >> * The NUMA node asso... > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/share/gc/z/zPageAllocator.cpp > > Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com> I addressed additional offline review feedback from @xmas92 in new commits. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26898#issuecomment-3224070702 From aboldtch at openjdk.org Tue Aug 26 13:03:32 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 26 Aug 2025 13:03:32 GMT Subject: RFR: 8359683: ZGC: NUMA-Aware Relocation [v5] In-Reply-To: References: <_SnXFrT1StlCj4JYdTfY-S6tPa6dsi-p6VfMl01te7k=.1cabcd48-3709-4b3c-9ea8-3fc122c505fe@github.com> Message-ID: On Tue, 26 Aug 2025 12:59:41 GMT, Joel Sikstr?m wrote: >> Hello, >> >> With [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441), ZGC got infrastructure to prefer allocations to end up on a specific NUMA node. When a new object is allocated, it is preferably placed on the NUMA node that is local to the allocating thread. This strategy improves access speeds for mutators working on that object, if it continues to be used by threads on the same NUMA node. However, when relocating objects, ZGC will potentially move (migrate) objects away from the NUMA node they were originally allocated on. This means that if a page is selected as part of the Relocation Set, the objects on that page could potentially be moved to another NUMA node, breaking the NUMA locality we strived for when allocating. >> >> We should consider adding NUMA-awareness to ZGC's relocation phase to keep NUMA-locality benefits for mutators. >> >>
>> >> Proposal (expandable section) >> >> NUMA-Awareness consists of two main features: >> >> **First**: GC threads should strive toward keeping the NUMA locality of objects to their original node, meaning that objects should ideally be relocated to a page that is on the same NUMA node. >> >> Mutator threads should have a different approach, as we know that the mutator that's (helping out with) relocating an object is also going to access it, so we migrate the object to the NUMA node associated with the relocating thread. This strategy is already in effect and does not require any changes to the code (specifically, ZObjectAllocator already track per-CPU specific Small pages). However, Medium pages are shared between CPUs and thus does not hold any guarantees on which NUMA node it is on. Combined, both mutator and Medium page relocation are not common, and thus there is little gain from introducing NUMA-awareness to that specific scenario. Instead, this can be addressed in a follow-up if we feel that's necessary. >> >> **Second**: When the GC chooses a page from the Relocation Set to relocate objects from, it should choose page(s) that are local to the same NUMA node, to speed up performance by working on NUMA-local memory. There are multiple ways to achieve this, but the main goal should be to (1) start working on pages that are local to the GC thread's NUMA node, and (2) when finished with pages on its own NUMA node, start working (help out) with pages associated with other NUMA nodes. >> >> Some key observations to consider with the above approach: >> >> * The NUMA node asso... > > Joel Sikstr?m has updated the pull request incrementally with two additional commits since the last revision: > > - Make shared stats variable volatile > - Remove friend class for ZRelocateTask and add accessor Reviewed this mostly offline. Good work. I also think we can cleanup the iterator, but let us do it in a followup. ------------- Marked as reviewed by aboldtch (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26898#pullrequestreview-3155514354 From ayang at openjdk.org Tue Aug 26 13:37:34 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 26 Aug 2025 13:37:34 GMT Subject: RFR: 8366155: Serial: Obsolete PretenureSizeThreshold In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 12:51:21 GMT, Francesco Andreuzzi 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 > > src/hotspot/share/gc/serial/serialHeap.cpp line 286: > >> 284: >> 285: HeapWord* SerialHeap::expand_heap_and_allocate(size_t size, bool is_tlab) { >> 286: HeapWord* result = _young_gen->allocate(size); > > The order of `_young_gen->allocate` and `old_gen->expand_and_allocate` is reversed now. It used to be `_old_gen->expand_and_allocate == nullptr --> _young_gen->allocate`, now it's the other way around. Is that intended? On master, before the method is invoked, young-gen allocation is already attempted inside `attempt_allocation(size, is_tlab, false /*first_only*/);`. With this cleanup, it become clearer that we try young-gen first, then old-gen. So, yes, this is intended. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26941#discussion_r2301014403 From duke at openjdk.org Tue Aug 26 13:37:35 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Tue, 26 Aug 2025 13:37:35 GMT Subject: RFR: 8366155: Serial: Obsolete PretenureSizeThreshold In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 13:32:34 GMT, Albert Mingkun Yang wrote: >> src/hotspot/share/gc/serial/serialHeap.cpp line 286: >> >>> 284: >>> 285: HeapWord* SerialHeap::expand_heap_and_allocate(size_t size, bool is_tlab) { >>> 286: HeapWord* result = _young_gen->allocate(size); >> >> The order of `_young_gen->allocate` and `old_gen->expand_and_allocate` is reversed now. It used to be `_old_gen->expand_and_allocate == nullptr --> _young_gen->allocate`, now it's the other way around. Is that intended? > > On master, before the method is invoked, young-gen allocation is already attempted inside `attempt_allocation(size, is_tlab, false /*first_only*/);`. > > With this cleanup, it become clearer that we try young-gen first, then old-gen. So, yes, this is intended. Thanks for clarifying ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26941#discussion_r2301022598 From iwalulya at openjdk.org Tue Aug 26 14:50:50 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 26 Aug 2025 14:50:50 GMT Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing [v5] In-Reply-To: References: Message-ID: > Hi, > > Please review this patch which takes into account the impact of concurrent GC activity on mutator threads when computing the time spent on GC activity in a time interval. Previously, only the GC pause times were considered, and the overhead imposed by concurrent GC worker threads was not included. > > With this change, we now estimate the impact of concurrent GC by dividing `elapsed_gc_cpu_time` by the number of CPUs. This provides an approximation of the additional time attributable to GC activity, assuming a fair CPU resource sharing. Although this method does not account for contention on other shared resources (such as memory bandwidth or caches), it offers a reasonable estimate for most scenarios. > > Testing: Tier 1 Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - Albert Review + Merge - Merge remote-tracking branch 'upstream/master' into ConcCPUImpact - remove unused - Merge remote-tracking branch 'upstream/master' into ConcCPUImpact - accumlate concurrent_gc_impact_time - Merge remote-tracking branch 'upstream/master' into ConcCPUImpact - cleanup after merge - Merge remote-tracking branch 'upstream/master' into ConcCPUImpact - Merge branch 'NormalizeTiming' into ConcCPUImpact - Thomas suggestion - ... and 5 more: https://git.openjdk.org/jdk/compare/3641c32c...bf349d2d ------------- Changes: https://git.openjdk.org/jdk/pull/26351/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26351&range=04 Stats: 70 lines in 5 files changed: 44 ins; 1 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/26351.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26351/head:pull/26351 PR: https://git.openjdk.org/jdk/pull/26351 From iwalulya at openjdk.org Tue Aug 26 15:40:12 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 26 Aug 2025 15:40:12 GMT Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing [v6] In-Reply-To: References: Message-ID: > Hi, > > Please review this patch which takes into account the impact of concurrent GC activity on mutator threads when computing the time spent on GC activity in a time interval. Previously, only the GC pause times were considered, and the overhead imposed by concurrent GC worker threads was not included. > > With this change, we now estimate the impact of concurrent GC by dividing `elapsed_gc_cpu_time` by the number of CPUs. This provides an approximation of the additional time attributable to GC activity, assuming a fair CPU resource sharing. Although this method does not account for contention on other shared resources (such as memory bandwidth or caches), it offers a reasonable estimate for most scenarios. > > Testing: Tier 1 Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: Albert suggestion ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26351/files - new: https://git.openjdk.org/jdk/pull/26351/files/bf349d2d..06ccc786 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26351&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26351&range=04-05 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26351.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26351/head:pull/26351 PR: https://git.openjdk.org/jdk/pull/26351 From kdnilsen at openjdk.org Tue Aug 26 16:09:34 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 26 Aug 2025 16:09:34 GMT Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may raise threshold prematurely [v3] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 17:23:11 GMT, William Kemper wrote: >> The adaptive tenuring algorithm has been modified to begin its evaluation of mortality rates from the current tenuring threshold. To compliment this change, objects must also now be strictly above the tenuring threshold to be promoted (instead of greater-than-or-equal). > > William Kemper has updated the pull request incrementally with one additional commit since the last revision: > > Fix windows build Thank you very much for these changes. LGTM. ------------- Marked as reviewed by kdnilsen (Committer). PR Review: https://git.openjdk.org/jdk/pull/26906#pullrequestreview-3156366673 From iwalulya at openjdk.org Tue Aug 26 18:38:14 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 26 Aug 2025 18:38:14 GMT Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing [v7] In-Reply-To: References: Message-ID: > Hi, > > Please review this patch which takes into account the impact of concurrent GC activity on mutator threads when computing the time spent on GC activity in a time interval. Previously, only the GC pause times were considered, and the overhead imposed by concurrent GC worker threads was not included. > > With this change, we now estimate the impact of concurrent GC by dividing `elapsed_gc_cpu_time` by the number of CPUs. This provides an approximation of the additional time attributable to GC activity, assuming a fair CPU resource sharing. Although this method does not account for contention on other shared resources (such as memory bandwidth or caches), it offers a reasonable estimate for most scenarios. > > Testing: Tier 1 Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: cast ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26351/files - new: https://git.openjdk.org/jdk/pull/26351/files/06ccc786..2f7d70a2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26351&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26351&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26351.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26351/head:pull/26351 PR: https://git.openjdk.org/jdk/pull/26351 From manc at openjdk.org Tue Aug 26 19:50:36 2025 From: manc at openjdk.org (Man Cao) Date: Tue, 26 Aug 2025 19:50:36 GMT Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing [v7] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 18:38:14 GMT, Ivan Walulya wrote: >> Hi, >> >> Please review this patch which takes into account the impact of concurrent GC activity on mutator threads when computing the time spent on GC activity in a time interval. Previously, only the GC pause times were considered, and the overhead imposed by concurrent GC worker threads was not included. >> >> With this change, we now estimate the impact of concurrent GC by dividing `elapsed_gc_cpu_time` by the number of CPUs. This provides an approximation of the additional time attributable to GC activity, assuming a fair CPU resource sharing. Although this method does not account for contention on other shared resources (such as memory bandwidth or caches), it offers a reasonable estimate for most scenarios. >> >> Testing: Tier 1 > > Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: > > cast Thank you for this work! ------------- Marked as reviewed by manc (Committer). PR Review: https://git.openjdk.org/jdk/pull/26351#pullrequestreview-3157087823 From manc at openjdk.org Tue Aug 26 19:50:39 2025 From: manc at openjdk.org (Man Cao) Date: Tue, 26 Aug 2025 19:50:39 GMT Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing [v4] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 10:04:06 GMT, Albert Mingkun Yang wrote: >> Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: >> >> - Merge remote-tracking branch 'upstream/master' into ConcCPUImpact >> - accumlate concurrent_gc_impact_time >> - Merge remote-tracking branch 'upstream/master' into ConcCPUImpact >> - cleanup after merge >> - Merge remote-tracking branch 'upstream/master' into ConcCPUImpact >> - Merge branch 'NormalizeTiming' into ConcCPUImpact >> - Thomas suggestion >> - Thomas Review >> - reorder >> - concurrent gc impact >> - ... and 2 more: https://git.openjdk.org/jdk/compare/999761d0...c65429ad > > src/hotspot/share/gc/g1/g1Analytics.cpp line 167: > >> 165: // caches, therefore underestimate the impact of the concurrent GC activity on mutator threads. >> 166: uint num_cpus = (uint)os::active_processor_count(); >> 167: double concurrent_gc_impact_time = _concurrent_gc_cpu_time_ms / num_cpus; > > I'd expect to see `ConcGCThreads` somewhere in the formula, but maybe this is enough. Now I think the number of active GC threads could be irrelevant for converting CPU time to mutator wall-clock time. The idea is more like "what if the CPU used by concurrent GC is used by mutator threads instead". Then the number of active mutator threads is a more appropriate divisor. Anyway, we still have the under-estimation problem, because applications typically do not use up all active processors. It is impractical to fully solve this problem. The current approach and acknowledging the under-estimation looks good. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26351#discussion_r2301983566 From iwalulya at openjdk.org Wed Aug 27 08:02:27 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 27 Aug 2025 08:02:27 GMT Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing [v8] In-Reply-To: References: Message-ID: > Hi, > > Please review this patch which takes into account the impact of concurrent GC activity on mutator threads when computing the time spent on GC activity in a time interval. Previously, only the GC pause times were considered, and the overhead imposed by concurrent GC worker threads was not included. > > With this change, we now estimate the impact of concurrent GC by dividing `elapsed_gc_cpu_time` by the number of CPUs. This provides an approximation of the additional time attributable to GC activity, assuming a fair CPU resource sharing. Although this method does not account for contention on other shared resources (such as memory bandwidth or caches), it offers a reasonable estimate for most scenarios. > > Testing: Tier 1 Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26351/files - new: https://git.openjdk.org/jdk/pull/26351/files/2f7d70a2..95bac57a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26351&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26351&range=06-07 Stats: 12 lines in 3 files changed: 7 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26351.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26351/head:pull/26351 PR: https://git.openjdk.org/jdk/pull/26351 From tschatzl at openjdk.org Wed Aug 27 08:18:44 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 27 Aug 2025 08:18:44 GMT Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing [v8] In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 08:02:27 GMT, Ivan Walulya wrote: >> Hi, >> >> Please review this patch which takes into account the impact of concurrent GC activity on mutator threads when computing the time spent on GC activity in a time interval. Previously, only the GC pause times were considered, and the overhead imposed by concurrent GC worker threads was not included. >> >> With this change, we now estimate the impact of concurrent GC by dividing `elapsed_gc_cpu_time` by the number of CPUs. This provides an approximation of the additional time attributable to GC activity, assuming a fair CPU resource sharing. Although this method does not account for contention on other shared resources (such as memory bandwidth or caches), it offers a reasonable estimate for most scenarios. >> >> Testing: Tier 1 > > Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: > > cleanup Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26351#pullrequestreview-3156173578 From tschatzl at openjdk.org Wed Aug 27 08:18:47 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 27 Aug 2025 08:18:47 GMT Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing [v5] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 14:50:50 GMT, Ivan Walulya wrote: >> Hi, >> >> Please review this patch which takes into account the impact of concurrent GC activity on mutator threads when computing the time spent on GC activity in a time interval. Previously, only the GC pause times were considered, and the overhead imposed by concurrent GC worker threads was not included. >> >> With this change, we now estimate the impact of concurrent GC by dividing `elapsed_gc_cpu_time` by the number of CPUs. This provides an approximation of the additional time attributable to GC activity, assuming a fair CPU resource sharing. Although this method does not account for contention on other shared resources (such as memory bandwidth or caches), it offers a reasonable estimate for most scenarios. >> >> Testing: Tier 1 > > Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: > > - Albert Review + Merge > - Merge remote-tracking branch 'upstream/master' into ConcCPUImpact > - remove unused > - Merge remote-tracking branch 'upstream/master' into ConcCPUImpact > - accumlate concurrent_gc_impact_time > - Merge remote-tracking branch 'upstream/master' into ConcCPUImpact > - cleanup after merge > - Merge remote-tracking branch 'upstream/master' into ConcCPUImpact > - Merge branch 'NormalizeTiming' into ConcCPUImpact > - Thomas suggestion > - ... and 5 more: https://git.openjdk.org/jdk/compare/3641c32c...bf349d2d src/hotspot/share/gc/g1/g1Policy.cpp line 670: > 668: > 669: double prev_gc_cpu_pause_end_ms = _analytics->gc_cpu_time_pause_end_ms(); > 670: double cur_gc_cpu_time_ms = (double) CPUTimeUsage::GC::gc_threads() / NANOSECS_PER_MILLISEC; Suggestion: double cur_gc_cpu_time_ms = (double)CPUTimeUsage::GC::gc_threads() / NANOSECS_PER_MILLISEC; src/hotspot/share/gc/g1/g1Policy.cpp line 1380: > 1378: update_time_to_mixed_tracking(gc_type, start, end); > 1379: > 1380: double elapsed_gc_cpu_time = CPUTimeUsage::GC::gc_threads() / NANOSECS_PER_MILLISEC; I think this should be: Suggestion: double elapsed_gc_cpu_time = (double)CPUTimeUsage::GC::gc_threads() / NANOSECS_PER_MILLISEC; to avoid rounding. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26351#discussion_r2301354864 PR Review Comment: https://git.openjdk.org/jdk/pull/26351#discussion_r2301356279 From jsikstro at openjdk.org Wed Aug 27 08:41:20 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 27 Aug 2025 08:41:20 GMT Subject: RFR: 8359683: ZGC: NUMA-Aware Relocation [v6] In-Reply-To: <_SnXFrT1StlCj4JYdTfY-S6tPa6dsi-p6VfMl01te7k=.1cabcd48-3709-4b3c-9ea8-3fc122c505fe@github.com> References: <_SnXFrT1StlCj4JYdTfY-S6tPa6dsi-p6VfMl01te7k=.1cabcd48-3709-4b3c-9ea8-3fc122c505fe@github.com> Message-ID: > Hello, > > With [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441), ZGC got infrastructure to prefer allocations to end up on a specific NUMA node. When a new object is allocated, it is preferably placed on the NUMA node that is local to the allocating thread. This strategy improves access speeds for mutators working on that object, if it continues to be used by threads on the same NUMA node. However, when relocating objects, ZGC will potentially move (migrate) objects away from the NUMA node they were originally allocated on. This means that if a page is selected as part of the Relocation Set, the objects on that page could potentially be moved to another NUMA node, breaking the NUMA locality we strived for when allocating. > > We should consider adding NUMA-awareness to ZGC's relocation phase to keep NUMA-locality benefits for mutators. > >
> > Proposal (expandable section) > > NUMA-Awareness consists of two main features: > > **First**: GC threads should strive toward keeping the NUMA locality of objects to their original node, meaning that objects should ideally be relocated to a page that is on the same NUMA node. > > Mutator threads should have a different approach, as we know that the mutator that's (helping out with) relocating an object is also going to access it, so we migrate the object to the NUMA node associated with the relocating thread. This strategy is already in effect and does not require any changes to the code (specifically, ZObjectAllocator already track per-CPU specific Small pages). However, Medium pages are shared between CPUs and thus does not hold any guarantees on which NUMA node it is on. Combined, both mutator and Medium page relocation are not common, and thus there is little gain from introducing NUMA-awareness to that specific scenario. Instead, this can be addressed in a follow-up if we feel that's necessary. > > **Second**: When the GC chooses a page from the Relocation Set to relocate objects from, it should choose page(s) that are local to the same NUMA node, to speed up performance by working on NUMA-local memory. There are multiple ways to achieve this, but the main goal should be to (1) start working on pages that are local to the GC thread's NUMA node, and (2) when finished with pages on its own NUMA node, start working (help out) with pages associated with other NUMA nodes. > > Some key observations to consider with the above approach: > > * The NUMA node associated with the GC thread should be "polle... Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: Fix grammar for iterator destruction comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26898/files - new: https://git.openjdk.org/jdk/pull/26898/files/f09cb290..8e754a11 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26898&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26898&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26898/head:pull/26898 PR: https://git.openjdk.org/jdk/pull/26898 From aboldtch at openjdk.org Wed Aug 27 08:41:20 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 27 Aug 2025 08:41:20 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 Wed, 27 Aug 2025 08:36:48 GMT, Joel Sikstr?m wrote: >> Hello, >> >> With [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441), ZGC got infrastructure to prefer allocations to end up on a specific NUMA node. When a new object is allocated, it is preferably placed on the NUMA node that is local to the allocating thread. This strategy improves access speeds for mutators working on that object, if it continues to be used by threads on the same NUMA node. However, when relocating objects, ZGC will potentially move (migrate) objects away from the NUMA node they were originally allocated on. This means that if a page is selected as part of the Relocation Set, the objects on that page could potentially be moved to another NUMA node, breaking the NUMA locality we strived for when allocating. >> >> We should consider adding NUMA-awareness to ZGC's relocation phase to keep NUMA-locality benefits for mutators. >> >>
>> >> Proposal (expandable section) >> >> NUMA-Awareness consists of two main features: >> >> **First**: GC threads should strive toward keeping the NUMA locality of objects to their original node, meaning that objects should ideally be relocated to a page that is on the same NUMA node. >> >> Mutator threads should have a different approach, as we know that the mutator that's (helping out with) relocating an object is also going to access it, so we migrate the object to the NUMA node associated with the relocating thread. This strategy is already in effect and does not require any changes to the code (specifically, ZObjectAllocator already track per-CPU specific Small pages). However, Medium pages are shared between CPUs and thus does not hold any guarantees on which NUMA node it is on. Combined, both mutator and Medium page relocation are not common, and thus there is little gain from introducing NUMA-awareness to that specific scenario. Instead, this can be addressed in a follow-up if we feel that's necessary. >> >> **Second**: When the GC chooses a page from the Relocation Set to relocate objects from, it should choose page(s) that are local to the same NUMA node, to speed up performance by working on NUMA-local memory. There are multiple ways to achieve this, but the main goal should be to (1) start working on pages that are local to the GC thread's NUMA node, and (2) when finished with pages on its own NUMA node, start working (help out) with pages associated with other NUMA nodes. >> >> Some key observations to consider with the above approach: >> >> * The NUMA node asso... > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > Fix grammar for iterator destruction comment Marked as reviewed by aboldtch (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26898#pullrequestreview-3158887620 From jsikstro at openjdk.org Wed Aug 27 09:11:02 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 27 Aug 2025 09:11:02 GMT Subject: Integrated: 8359683: ZGC: NUMA-Aware Relocation In-Reply-To: <_SnXFrT1StlCj4JYdTfY-S6tPa6dsi-p6VfMl01te7k=.1cabcd48-3709-4b3c-9ea8-3fc122c505fe@github.com> References: <_SnXFrT1StlCj4JYdTfY-S6tPa6dsi-p6VfMl01te7k=.1cabcd48-3709-4b3c-9ea8-3fc122c505fe@github.com> Message-ID: On Fri, 22 Aug 2025 10:28:01 GMT, Joel Sikstr?m wrote: > Hello, > > With [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441), ZGC got infrastructure to prefer allocations to end up on a specific NUMA node. When a new object is allocated, it is preferably placed on the NUMA node that is local to the allocating thread. This strategy improves access speeds for mutators working on that object, if it continues to be used by threads on the same NUMA node. However, when relocating objects, ZGC will potentially move (migrate) objects away from the NUMA node they were originally allocated on. This means that if a page is selected as part of the Relocation Set, the objects on that page could potentially be moved to another NUMA node, breaking the NUMA locality we strived for when allocating. > > We should consider adding NUMA-awareness to ZGC's relocation phase to keep NUMA-locality benefits for mutators. > >
> > Proposal (expandable section) > > NUMA-Awareness consists of two main features: > > **First**: GC threads should strive toward keeping the NUMA locality of objects to their original node, meaning that objects should ideally be relocated to a page that is on the same NUMA node. > > Mutator threads should have a different approach, as we know that the mutator that's (helping out with) relocating an object is also going to access it, so we migrate the object to the NUMA node associated with the relocating thread. This strategy is already in effect and does not require any changes to the code (specifically, ZObjectAllocator already track per-CPU specific Small pages). However, Medium pages are shared between CPUs and thus does not hold any guarantees on which NUMA node it is on. Combined, both mutator and Medium page relocation are not common, and thus there is little gain from introducing NUMA-awareness to that specific scenario. Instead, this can be addressed in a follow-up if we feel that's necessary. > > **Second**: When the GC chooses a page from the Relocation Set to relocate objects from, it should choose page(s) that are local to the same NUMA node, to speed up performance by working on NUMA-local memory. There are multiple ways to achieve this, but the main goal should be to (1) start working on pages that are local to the GC thread's NUMA node, and (2) when finished with pages on its own NUMA node, start working (help out) with pages associated with other NUMA nodes. > > Some key observations to consider with the above approach: > > * The NUMA node associated with the GC thread should be "polle... This pull request has now been integrated. Changeset: b39c7369 Author: Joel Sikstr?m URL: https://git.openjdk.org/jdk/commit/b39c73696d0421b218e301403d589af5a91b037f Stats: 263 lines in 15 files changed: 165 ins; 19 del; 79 mod 8359683: ZGC: NUMA-Aware Relocation Reviewed-by: aboldtch, sjohanss ------------- PR: https://git.openjdk.org/jdk/pull/26898 From jsikstro at openjdk.org Wed Aug 27 09:11:00 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 27 Aug 2025 09:11:00 GMT Subject: RFR: 8359683: ZGC: NUMA-Aware Relocation [v4] In-Reply-To: References: <_SnXFrT1StlCj4JYdTfY-S6tPa6dsi-p6VfMl01te7k=.1cabcd48-3709-4b3c-9ea8-3fc122c505fe@github.com> Message-ID: On Tue, 26 Aug 2025 09:46:27 GMT, Stefan Johansson wrote: >> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/hotspot/share/gc/z/zPageAllocator.cpp >> >> Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com> > > Marked as reviewed by sjohanss (Reviewer). Thank you for the reviews! @kstefanj @xmas92 I reran some sanity testing (tier1-3) with with and without `-XX:ZFakeNUMA=16`, which looks good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26898#issuecomment-3227401746 From tschatzl at openjdk.org Wed Aug 27 09:20:46 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 27 Aug 2025 09:20:46 GMT Subject: RFR: 8366145: Help diagnose ubsan failure In-Reply-To: <1hYLqTPwBlVCBFe09QMtJi7JHemtDnniTsEPbWvM5yI=.9a8ccf7a-20db-4517-9aaa-6020b0cfbf99@github.com> References: <1hYLqTPwBlVCBFe09QMtJi7JHemtDnniTsEPbWvM5yI=.9a8ccf7a-20db-4517-9aaa-6020b0cfbf99@github.com> Message-ID: <4-mVFCgrEfPLUGe4273iLBAM1PhimtMjvHNIYp9AShE=.cc35e66e-d4fd-407f-bf5e-f20ffbf53012@github.com> On Tue, 26 Aug 2025 11:22:30 GMT, Leo Korinth wrote: > This pull request is created to help diagnose the bug report https://bugs.openjdk.org/browse/JDK-8354430. > > The problem is that we get a ubsan runtime error when dividing by zero. Ubsan is not normally running, so I will add an assert making it easier to catch the problem and printing the value of the two variables that when subtracted will create a zero; it will hopefully help with diagnosis. > > Some comments: > 1) the result of `most_recent_gc_end_time_sec()` will not change within the function, thus I will not clutter the code with a new variable, is that okay? > 2) I added two calls to `fabs` which are most probably not needed (ieee floating point rules seems to say that positive and negative zero equals). However I think my proposed code makes it clear that I have thought about it. > > I am now running tier1-3 The CR title should be more specific, possibly mentioning both the approximate issue and failure and/or the CR number. E.g. `Help diagnose ubsan division by zero in computing pause time ratios` or something. src/hotspot/share/gc/g1/g1Analytics.cpp line 167: > 165: > 166: double short_interval_ms = (end_time_sec - most_recent_gc_end_time_sec()) * 1000.0; > 167: assert(fabs(short_interval_ms) != fabs(0.0), "short_interval_ms should not be zero, calculated from %f and %f", end_time_sec, most_recent_gc_end_time_sec()); Not sure why one would need the `fabs(0.0)`. It simply returns `0.0`. Suggestion: assert(fabs(short_interval_ms) != 0.0, "short_interval_ms should not be zero, calculated from %f and %f", end_time_sec, most_recent_gc_end_time_sec()); Maybe even compare against some very small epsilon, which would also be suspicious given that pauses smaller than a nanosecond or so seem suspicious in any case. ------------- Changes requested by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26939#pullrequestreview-3159020811 PR Review Comment: https://git.openjdk.org/jdk/pull/26939#discussion_r2303369293 From tschatzl at openjdk.org Wed Aug 27 09:22:43 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 27 Aug 2025 09:22:43 GMT Subject: RFR: 8365922: Parallel: Group uses of GCTimeRatio to a single location In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 08:22:24 GMT, Albert Mingkun Yang wrote: >> src/hotspot/share/gc/parallel/psAdaptiveSizePolicy.cpp line 90: >> >>> 88: >>> 89: // Get a local copy and use it inside gc-pause in case the global var gets updated externally. >>> 90: const uint local_GCTimeRatio = GCTimeRatio; >> >> needs an `Atomic::load()` as the compiler is free to re-read the global later at any use of the local. > > I was thinking to add that when this flag actually becomes manageable. I don't feel too strongly about it. Do you prefer using atomic already now? I prefer to either do this with that change then, or have the change complete. Separating the main change out seems prone for errors, and no different than not having this patch in. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26881#discussion_r2303375182 From tschatzl at openjdk.org Wed Aug 27 09:25:44 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 27 Aug 2025 09:25:44 GMT Subject: RFR: 8352969: G1: Improve testability of optional collections [v3] In-Reply-To: <1fNzfZ2HlfWuS2tMoENBL5Xp3wZH8XUxiXB-soC85r0=.915bb437-5655-4b21-89c4-f0a07b70c072@github.com> References: <1fNzfZ2HlfWuS2tMoENBL5Xp3wZH8XUxiXB-soC85r0=.915bb437-5655-4b21-89c4-f0a07b70c072@github.com> Message-ID: On Tue, 26 Aug 2025 06:32:56 GMT, Guanqiang Han wrote: >> This PR introduces a new diagnostic flag EvacuateAllOptionalRegions to force G1 GC to evacuate all optional regions regardless of the predicted pause time. The motivation is to allow testing and validation of optional region evacuation behavior without being constrained by the remaining pause time. > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > Update g1YoungCollector.cpp > > format fix Changes requested by tschatzl (Reviewer). src/hotspot/share/gc/g1/g1CollectionSet.cpp line 652: > 650: num_regions_selected, optional_regions_count, total_prediction_ms); > 651: return num_regions_selected; > 652: } Please separate out this cleanup, it has nothing to do with this change. src/hotspot/share/gc/g1/g1YoungCollector.cpp line 828: > 826: double time_used_ms = os::elapsedTime() * 1000.0 - pause_start_time_ms; > 827: time_left_ms = MaxGCPauseMillis - time_used_ms; > 828: } Even if it is not 100% technically correct, I would prefer to put the total available time into a local, and set it to either `MaxGCPauseMillis` or `DBL_MAX` outside the loop, and keep the loop as is. This reduces the complexity of the loop body for the negligible issue in case that option is set. src/hotspot/share/gc/g1/g1_globals.hpp line 375: > 373: product(bool, EvacuateAllOptionalRegions, false, DIAGNOSTIC, \ > 374: "Force to evacuate all optional regions.") \ > 375: \ This new option looks like a `develop` option, not a product option to me since it is explicitly about increasing testing of some functionality. This change should also have a test that exercises the option (and optional regions if possible). Note that if there were a good test for optional regions, this flag would be unnecessary in the first place. If you plan to add tests incorporating this flag later it would be great if you could give us a preview for them. We want to avoid adding flags and logic that is not used somewhere/somehow. ------------- PR Review: https://git.openjdk.org/jdk/pull/26880#pullrequestreview-3154308825 PR Review Comment: https://git.openjdk.org/jdk/pull/26880#discussion_r2300054069 PR Review Comment: https://git.openjdk.org/jdk/pull/26880#discussion_r2300109914 PR Review Comment: https://git.openjdk.org/jdk/pull/26880#discussion_r2300172748 From ayang at openjdk.org Wed Aug 27 09:33:50 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 27 Aug 2025 09:33:50 GMT Subject: RFR: 8365919: Replace currentTimeMillis with nanoTime in Stresser.java [v4] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 07:42:56 GMT, Albert Mingkun Yang wrote: >> Mostly a mechanic change from `currentTimeMillis()` to `nanoTime()/1000000`. It also removes `finishTime` to avoid overflowing. >> >> The change in `iteration()` is to ensure `currentTime` is properly initialized. >> >> (Was investigating a timeout on Windows-x64, which led me to this code. I think this fix is good enough by its own.) >> >> Test: tier1-5 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - review > - Merge branch 'master' into test-nano-time > - review > - review > - Merge branch 'master' into test-nano-time > - test-nano-time Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26879#issuecomment-3227471265 From ayang at openjdk.org Wed Aug 27 09:33:51 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 27 Aug 2025 09:33:51 GMT Subject: Integrated: 8365919: Replace currentTimeMillis with nanoTime in Stresser.java In-Reply-To: References: Message-ID: On Thu, 21 Aug 2025 10:02:12 GMT, Albert Mingkun Yang wrote: > Mostly a mechanic change from `currentTimeMillis()` to `nanoTime()/1000000`. It also removes `finishTime` to avoid overflowing. > > The change in `iteration()` is to ensure `currentTime` is properly initialized. > > (Was investigating a timeout on Windows-x64, which led me to this code. I think this fix is good enough by its own.) > > Test: tier1-5 This pull request has now been integrated. Changeset: 0ca38bdc Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/0ca38bdc4d503158fda57bbc8bc9adc420628079 Stats: 25 lines in 1 file changed: 6 ins; 6 del; 13 mod 8365919: Replace currentTimeMillis with nanoTime in Stresser.java Reviewed-by: tschatzl, phh ------------- PR: https://git.openjdk.org/jdk/pull/26879 From aboldtch at openjdk.org Wed Aug 27 09:42:59 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 27 Aug 2025 09:42:59 GMT Subject: RFR: 8366223: ZGC: ZPageAllocator::cleanup_failed_commit_multi_partition is broken Message-ID: While investigating [JDK-8366147](https://bugs.openjdk.org/browse/JDK-8366147) we also found that ZPageAllocator::cleanup_failed_commit_multi_partition is broken. The implementation is intended to work by going over each partitions part of the allocation one by one and returning any harvested or committed and mapped memory to to cache and returning any failed to be committed physical associations back to our internal free lists. But when deriving what part of the memory is associated with which partition it uses the wrong variable and ends up working with the wrong memory. And multiple partitions will end up working on the same supposedly mutually exclusive memory. This fix is to use the correct `partial_vmem` rather than `vmem` which holds the whole allocation. The new test reproduces this error. The test is tightly coupled to the current ZPageAllocator implementation and its policies. We might want to enhance this test in the future to ensure that we are actually provoking commit failures with harvesting and get notified if this changes. Currently there is no none intrusive way to do this. The best option might be our JFR events which contain all the information. * Testing (In progress) * Oracle supported platforms tier1 + ZGC tier1-8 ------------- Commit messages: - 8366223: ZGC: ZPageAllocator::cleanup_failed_commit_multi_partition is broken Changes: https://git.openjdk.org/jdk/pull/26953/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26953&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366223 Stats: 122 lines in 4 files changed: 120 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26953.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26953/head:pull/26953 PR: https://git.openjdk.org/jdk/pull/26953 From ayang at openjdk.org Wed Aug 27 09:52:47 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 27 Aug 2025 09:52:47 GMT Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing [v8] In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 08:02:27 GMT, Ivan Walulya wrote: >> Hi, >> >> Please review this patch which takes into account the impact of concurrent GC activity on mutator threads when computing the time spent on GC activity in a time interval. Previously, only the GC pause times were considered, and the overhead imposed by concurrent GC worker threads was not included. >> >> With this change, we now estimate the impact of concurrent GC by dividing `elapsed_gc_cpu_time` by the number of CPUs. This provides an approximation of the additional time attributable to GC activity, assuming a fair CPU resource sharing. Although this method does not account for contention on other shared resources (such as memory bandwidth or caches), it offers a reasonable estimate for most scenarios. >> >> Testing: Tier 1 > > Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: > > cleanup Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26351#pullrequestreview-3159121808 From ayang at openjdk.org Wed Aug 27 09:56:01 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 27 Aug 2025 09:56:01 GMT Subject: RFR: 8365922: Parallel: Group uses of GCTimeRatio to a single location [v2] In-Reply-To: References: Message-ID: > 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 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26881/files - new: https://git.openjdk.org/jdk/pull/26881/files/fd6b6e94..b26072e2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26881&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26881&range=00-01 Stats: 7855 lines in 241 files changed: 5021 ins; 1815 del; 1019 mod Patch: https://git.openjdk.org/jdk/pull/26881.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26881/head:pull/26881 PR: https://git.openjdk.org/jdk/pull/26881 From ayang at openjdk.org Wed Aug 27 09:56:02 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 27 Aug 2025 09:56:02 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:20:34 GMT, Thomas Schatzl wrote: >> I was thinking to add that when this flag actually becomes manageable. I don't feel too strongly about it. Do you prefer using atomic already now? > > I prefer to either do this with that change then, or have the change complete. Separating the main change out seems prone for errors, and no different than not having this patch in. Using atomic op now. All Parallel-specific changes are in place. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26881#discussion_r2303448344 From aboldtch at openjdk.org Wed Aug 27 09:57:25 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 27 Aug 2025 09:57:25 GMT Subject: RFR: 8366223: ZGC: ZPageAllocator::cleanup_failed_commit_multi_partition is broken [v2] In-Reply-To: References: Message-ID: > While investigating [JDK-8366147](https://bugs.openjdk.org/browse/JDK-8366147) we also found that ZPageAllocator::cleanup_failed_commit_multi_partition is broken. > > The implementation is intended to work by going over each partitions part of the allocation one by one and returning any harvested or committed and mapped memory to to cache and returning any failed to be committed physical associations back to our internal free lists. > > But when deriving what part of the memory is associated with which partition it uses the wrong variable and ends up working with the wrong memory. And multiple partitions will end up working on the same supposedly mutually exclusive memory. > > This fix is to use the correct `partial_vmem` rather than `vmem` which holds the whole allocation. > > The new test reproduces this error. The test is tightly coupled to the current ZPageAllocator implementation and its policies. We might want to enhance this test in the future to ensure that we are actually provoking commit failures with harvesting and get notified if this changes. Currently there is no none intrusive way to do this. The best option might be our JFR events which contain all the information. > > * Testing (In progress) > * Oracle supported platforms tier1 + ZGC tier1-8 Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Run in driver rather than othervm ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26953/files - new: https://git.openjdk.org/jdk/pull/26953/files/b87dfffb..616c55a8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26953&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26953&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26953.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26953/head:pull/26953 PR: https://git.openjdk.org/jdk/pull/26953 From aboldtch at openjdk.org Wed Aug 27 10:04:03 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 27 Aug 2025 10:04:03 GMT Subject: RFR: 8366147: ZGC: ZPageAllocator::cleanup_failed_commit_single_partition may leak memory Message-ID: ZPageAllocator::cleanup_failed_commit_single_partition is responsible for cleaning up the successful part of a failed allocation by returning it to the cache so it can be reused. When a commit fails the the parts that should be returned is any "harvested" memory (memory it took from the cache) and any partially freshly committed memory. In a late revision of [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) we rewrote part of the allocation logic such that the "harvested" part was no longer part of the partial vmems after successfully harvesting. However the cleanup code was not adapted to this change. The solution is to add back both the harvested and newly committed memory, not just the newly committed part. * Testing (In progress) * Oracle supported platforms tier1 + ZGC tier1-8 ------------- Depends on: https://git.openjdk.org/jdk/pull/26953 Commit messages: - 8366147: ZGC: ZPageAllocator::cleanup_failed_commit_single_partition may leak memory Changes: https://git.openjdk.org/jdk/pull/26954/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26954&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366147 Stats: 20 lines in 2 files changed: 14 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/26954.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26954/head:pull/26954 PR: https://git.openjdk.org/jdk/pull/26954 From lkorinth at openjdk.org Wed Aug 27 10:06:43 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 27 Aug 2025 10:06:43 GMT Subject: RFR: 8366145: Help diagnose ubsan division by zero in computing pause time ratios In-Reply-To: <4-mVFCgrEfPLUGe4273iLBAM1PhimtMjvHNIYp9AShE=.cc35e66e-d4fd-407f-bf5e-f20ffbf53012@github.com> References: <1hYLqTPwBlVCBFe09QMtJi7JHemtDnniTsEPbWvM5yI=.9a8ccf7a-20db-4517-9aaa-6020b0cfbf99@github.com> <4-mVFCgrEfPLUGe4273iLBAM1PhimtMjvHNIYp9AShE=.cc35e66e-d4fd-407f-bf5e-f20ffbf53012@github.com> Message-ID: <3EcFiM3bod-xVyWag1eEGrOzYL9bZfE_DEEvxvmKJr0=.1738be44-933d-449b-91ca-669bf13a8fc6@github.com> On Wed, 27 Aug 2025 09:17:45 GMT, Thomas Schatzl wrote: >> This pull request is created to help diagnose the bug report https://bugs.openjdk.org/browse/JDK-8354430. >> >> The problem is that we get a ubsan runtime error when dividing by zero. Ubsan is not normally running, so I will add an assert making it easier to catch the problem and printing the value of the two variables that when subtracted will create a zero; it will hopefully help with diagnosis. >> >> Some comments: >> 1) the result of `most_recent_gc_end_time_sec()` will not change within the function, thus I will not clutter the code with a new variable, is that okay? >> 2) I added two calls to `fabs` which are most probably not needed (ieee floating point rules seems to say that positive and negative zero equals). However I think my proposed code makes it clear that I have thought about it. >> >> I am now running tier1-3 > > src/hotspot/share/gc/g1/g1Analytics.cpp line 167: > >> 165: >> 166: double short_interval_ms = (end_time_sec - most_recent_gc_end_time_sec()) * 1000.0; >> 167: assert(fabs(short_interval_ms) != fabs(0.0), "short_interval_ms should not be zero, calculated from %f and %f", end_time_sec, most_recent_gc_end_time_sec()); > > Not sure why one would need the `fabs(0.0)`. It simply returns `0.0`. > Suggestion: > > assert(fabs(short_interval_ms) != 0.0, "short_interval_ms should not be zero, calculated from %f and %f", end_time_sec, most_recent_gc_end_time_sec()); > > Maybe even compare against some very small epsilon, which would also be suspicious given that pauses smaller than a nanosecond or so seem suspicious in any case. Do you want me to remove the right `fabs` or both `fabs`? I am not interested in an epsilon, I want to see when we get a real division by zero. The code clamps the big value after the computation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26939#discussion_r2303474578 From aboldtch at openjdk.org Wed Aug 27 11:12:03 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 27 Aug 2025 11:12:03 GMT Subject: RFR: 8366147: ZGC: ZPageAllocator::cleanup_failed_commit_single_partition may leak memory [v2] In-Reply-To: References: Message-ID: > ZPageAllocator::cleanup_failed_commit_single_partition is responsible for cleaning up the successful part of a failed allocation by returning it to the cache so it can be reused. > > When a commit fails the the parts that should be returned is any "harvested" memory (memory it took from the cache) and any partially freshly committed memory. > > In a late revision of [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) we rewrote part of the allocation logic such that the "harvested" part was no longer part of the partial vmems after successfully harvesting. However the cleanup code was not adapted to this change. > > The solution is to add back both the harvested and newly committed memory, not just the newly committed part. > > * Testing (In progress) > * Oracle supported platforms tier1 + ZGC tier1-8 Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Run in driver rather than othervm ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26954/files - new: https://git.openjdk.org/jdk/pull/26954/files/39cb2967..35b04f96 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26954&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26954&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26954.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26954/head:pull/26954 PR: https://git.openjdk.org/jdk/pull/26954 From iwalulya at openjdk.org Wed Aug 27 11:48:49 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 27 Aug 2025 11:48:49 GMT Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing [v8] In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 08:02:27 GMT, Ivan Walulya wrote: >> Hi, >> >> Please review this patch which takes into account the impact of concurrent GC activity on mutator threads when computing the time spent on GC activity in a time interval. Previously, only the GC pause times were considered, and the overhead imposed by concurrent GC worker threads was not included. >> >> With this change, we now estimate the impact of concurrent GC by dividing `elapsed_gc_cpu_time` by the number of CPUs. This provides an approximation of the additional time attributable to GC activity, assuming a fair CPU resource sharing. Although this method does not account for contention on other shared resources (such as memory bandwidth or caches), it offers a reasonable estimate for most scenarios. >> >> Testing: Tier 1 > > Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: > > cleanup Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26351#issuecomment-3227865178 From iwalulya at openjdk.org Wed Aug 27 11:48:50 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 27 Aug 2025 11:48:50 GMT Subject: Integrated: 8359348: G1: Improve cpu usage measurements for heap sizing In-Reply-To: References: Message-ID: On Wed, 16 Jul 2025 13:55:32 GMT, Ivan Walulya wrote: > Hi, > > Please review this patch which takes into account the impact of concurrent GC activity on mutator threads when computing the time spent on GC activity in a time interval. Previously, only the GC pause times were considered, and the overhead imposed by concurrent GC worker threads was not included. > > With this change, we now estimate the impact of concurrent GC by dividing `elapsed_gc_cpu_time` by the number of CPUs. This provides an approximation of the additional time attributable to GC activity, assuming a fair CPU resource sharing. Although this method does not account for contention on other shared resources (such as memory bandwidth or caches), it offers a reasonable estimate for most scenarios. > > Testing: Tier 1 This pull request has now been integrated. Changeset: 124575b4 Author: Ivan Walulya URL: https://git.openjdk.org/jdk/commit/124575b4c2b52328a8efddb40e67057a53b44a04 Stats: 77 lines in 5 files changed: 50 ins; 1 del; 26 mod 8359348: G1: Improve cpu usage measurements for heap sizing Reviewed-by: tschatzl, ayang, manc ------------- PR: https://git.openjdk.org/jdk/pull/26351 From aboldtch at openjdk.org Wed Aug 27 12:34:27 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 27 Aug 2025 12:34:27 GMT Subject: RFR: 8366147: ZGC: ZPageAllocator::cleanup_failed_commit_single_partition may leak memory [v3] In-Reply-To: References: Message-ID: > ZPageAllocator::cleanup_failed_commit_single_partition is responsible for cleaning up the successful part of a failed allocation by returning it to the cache so it can be reused. > > When a commit fails the the parts that should be returned is any "harvested" memory (memory it took from the cache) and any partially freshly committed memory. > > In a late revision of [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) we rewrote part of the allocation logic such that the "harvested" part was no longer part of the partial vmems after successfully harvesting. However the cleanup code was not adapted to this change. > > The solution is to add back both the harvested and newly committed memory, not just the newly committed part. > > * Testing (In progress) > * Oracle supported platforms tier1 + ZGC tier1-8 Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision: - Change name and addition order - Remove extra newline ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26954/files - new: https://git.openjdk.org/jdk/pull/26954/files/35b04f96..ebb04ad9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26954&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26954&range=01-02 Stats: 4 lines in 2 files changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26954.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26954/head:pull/26954 PR: https://git.openjdk.org/jdk/pull/26954 From stefank at openjdk.org Wed Aug 27 13:51:47 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 27 Aug 2025 13:51:47 GMT Subject: RFR: 8366223: ZGC: ZPageAllocator::cleanup_failed_commit_multi_partition is broken [v2] In-Reply-To: References: Message-ID: <8gLyqb2mh6SnVPCeDe_vcUH36ZGmvi5ylQPaLouPB7s=.ce2090b4-3e2f-4284-9a3e-d86e1bbbbfe8@github.com> On Wed, 27 Aug 2025 09:57:25 GMT, Axel Boldt-Christmas wrote: >> While investigating [JDK-8366147](https://bugs.openjdk.org/browse/JDK-8366147) we also found that ZPageAllocator::cleanup_failed_commit_multi_partition is broken. >> >> The implementation is intended to work by going over each partitions part of the allocation one by one and returning any harvested or committed and mapped memory to to cache and returning any failed to be committed physical associations back to our internal free lists. >> >> But when deriving what part of the memory is associated with which partition it uses the wrong variable and ends up working with the wrong memory. And multiple partitions will end up working on the same supposedly mutually exclusive memory. >> >> This fix is to use the correct `partial_vmem` rather than `vmem` which holds the whole allocation. >> >> The new test reproduces this error. The test is tightly coupled to the current ZPageAllocator implementation and its policies. We might want to enhance this test in the future to ensure that we are actually provoking commit failures with harvesting and get notified if this changes. Currently there is no none intrusive way to do this. The best option might be our JFR events which contain all the information. >> >> * Testing (In progress) >> * Oracle supported platforms tier1 + ZGC tier1-8 > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Run in driver rather than othervm Looks good. Thanks for finding and fixing this. ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26953#pullrequestreview-3159889194 From jsikstro at openjdk.org Wed Aug 27 13:58:43 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 27 Aug 2025 13:58:43 GMT Subject: RFR: 8366223: ZGC: ZPageAllocator::cleanup_failed_commit_multi_partition is broken [v2] In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 09:57:25 GMT, Axel Boldt-Christmas wrote: >> While investigating [JDK-8366147](https://bugs.openjdk.org/browse/JDK-8366147) we also found that ZPageAllocator::cleanup_failed_commit_multi_partition is broken. >> >> The implementation is intended to work by going over each partitions part of the allocation one by one and returning any harvested or committed and mapped memory to to cache and returning any failed to be committed physical associations back to our internal free lists. >> >> But when deriving what part of the memory is associated with which partition it uses the wrong variable and ends up working with the wrong memory. And multiple partitions will end up working on the same supposedly mutually exclusive memory. >> >> This fix is to use the correct `partial_vmem` rather than `vmem` which holds the whole allocation. >> >> The new test reproduces this error. The test is tightly coupled to the current ZPageAllocator implementation and its policies. We might want to enhance this test in the future to ensure that we are actually provoking commit failures with harvesting and get notified if this changes. Currently there is no none intrusive way to do this. The best option might be our JFR events which contain all the information. >> >> * Testing (In progress) >> * Oracle supported platforms tier1 + ZGC tier1-8 > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Run in driver rather than othervm Good find and thank you for this! The test is definitely a nice addition. ------------- Marked as reviewed by jsikstro (Committer). PR Review: https://git.openjdk.org/jdk/pull/26953#pullrequestreview-3159917044 From tschatzl at openjdk.org Wed Aug 27 14:10:42 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 27 Aug 2025 14:10:42 GMT Subject: RFR: 8366145: Help diagnose ubsan division by zero in computing pause time ratios In-Reply-To: <3EcFiM3bod-xVyWag1eEGrOzYL9bZfE_DEEvxvmKJr0=.1738be44-933d-449b-91ca-669bf13a8fc6@github.com> References: <1hYLqTPwBlVCBFe09QMtJi7JHemtDnniTsEPbWvM5yI=.9a8ccf7a-20db-4517-9aaa-6020b0cfbf99@github.com> <4-mVFCgrEfPLUGe4273iLBAM1PhimtMjvHNIYp9AShE=.cc35e66e-d4fd-407f-bf5e-f20ffbf53012@github.com> <3EcFiM3bod-xVyWag1eEGrOzYL9bZfE_DEEvxvmKJr0=.1738be44-933d-449b-91ca-669bf13a8fc6@github.com> Message-ID: On Wed, 27 Aug 2025 10:03:53 GMT, Leo Korinth wrote: >> src/hotspot/share/gc/g1/g1Analytics.cpp line 167: >> >>> 165: >>> 166: double short_interval_ms = (end_time_sec - most_recent_gc_end_time_sec()) * 1000.0; >>> 167: assert(fabs(short_interval_ms) != fabs(0.0), "short_interval_ms should not be zero, calculated from %f and %f", end_time_sec, most_recent_gc_end_time_sec()); >> >> Not sure why one would need the `fabs(0.0)`. It simply returns `0.0`. >> Suggestion: >> >> assert(fabs(short_interval_ms) != 0.0, "short_interval_ms should not be zero, calculated from %f and %f", end_time_sec, most_recent_gc_end_time_sec()); >> >> Maybe even compare against some very small epsilon, which would also be suspicious given that pauses smaller than a nanosecond or so seem suspicious in any case. > > Do you want me to remove the right `fabs` or both `fabs`? I am not interested in an epsilon, I want to see when we get a real division by zero. The code clamps the big value after the computation. just the one suggested in the Suggestion box is good enough. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26939#discussion_r2304054684 From jsjolen at openjdk.org Wed Aug 27 14:21:43 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 27 Aug 2025 14:21:43 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer 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: <-Ct2yCIbRn7bSazmFKxlMPMeP85zAZk3kUfP9ele4so=.78e5ec0f-2d17-45e6-a68d-9fff149577c1@github.com> On Wed, 27 Aug 2025 11:24:07 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 It seems to me like we can fix the ubsan issue by avoiding the cast into pointers and computing through `size_t` as far as possible, and converting into pointer when necessary. For example ```c++ size_t aligned_heap_base_min_address = align_up(HeapBaseMinAddress, alignment); size_t noaccess_prefix = ((aligned_heap_base_min_address + size) > OopEncodingHeapMax) ? noaccess_prefix_size : 0; if (!FLAG_IS_DEFAULT(HeapBaseMinAddress)) { reserved = try_reserve_memory(size + noaccess_prefix, alignment, page_size, static_cast(aligned_heap_base_min_address)); if (reserved.base() != static_cast(aligned_heap_base_min_address)) { // Enforce this exact address. release(reserved); reserved = {}; } } The semantics of reserving a `null` base address is still preserved as meaning "don't care where you put it" then. Someone from GC needs to look at this and see whether or not an undefined (implicitly 0?) HeapBaseMinAddress is meant to have that type of meaning. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3228406340 From kbarrett at openjdk.org Wed Aug 27 14:21:48 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 27 Aug 2025 14:21:48 GMT Subject: RFR: 8366145: Help diagnose ubsan division by zero in computing pause time ratios In-Reply-To: References: <1hYLqTPwBlVCBFe09QMtJi7JHemtDnniTsEPbWvM5yI=.9a8ccf7a-20db-4517-9aaa-6020b0cfbf99@github.com> <4-mVFCgrEfPLUGe4273iLBAM1PhimtMjvHNIYp9AShE=.cc35e66e-d4fd-407f-bf5e-f20ffbf53012@github.com> <3EcFiM3bod-xVyWag1eEGrOzYL9bZfE_DEEvxvmKJr0=.1738be44-933d-449b-91ca-669bf13a8fc6@github.com> Message-ID: On Wed, 27 Aug 2025 14:08:34 GMT, Thomas Schatzl wrote: >> Do you want me to remove the right `fabs` or both `fabs`? I am not interested in an epsilon, I want to see when we get a real division by zero. The code clamps the big value after the computation. > > just the one suggested in the Suggestion box is good enough. I think `fabs` is just clutter, and doesn't add anything. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26939#discussion_r2304062284 From kbarrett at openjdk.org Wed Aug 27 14:21:48 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 27 Aug 2025 14:21:48 GMT Subject: RFR: 8366145: Help diagnose ubsan division by zero in computing pause time ratios In-Reply-To: References: <1hYLqTPwBlVCBFe09QMtJi7JHemtDnniTsEPbWvM5yI=.9a8ccf7a-20db-4517-9aaa-6020b0cfbf99@github.com> <4-mVFCgrEfPLUGe4273iLBAM1PhimtMjvHNIYp9AShE=.cc35e66e-d4fd-407f-bf5e-f20ffbf53012@github.com> <3EcFiM3bod-xVyWag1eEGrOzYL9bZfE_DEEvxvmKJr0=.1738be44-933d-449b-91ca-669bf13a8fc6@github.com> Message-ID: On Wed, 27 Aug 2025 14:11:10 GMT, Kim Barrett wrote: >> just the one suggested in the Suggestion box is good enough. > > I think `fabs` is just clutter, and doesn't add anything. I think checking for zero is fine, rather than some small interval. We're trying to figure out how someone got a ubsan divide-by-zero complaint in the next statement. It's a supposition that a broken (insufficiently granular) clock was involved. If that's the case, checking for a small interval won't change anything, as the coarse clock will either not tick, or tick by some largish amount. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26939#discussion_r2304081159 From tschatzl at openjdk.org Wed Aug 27 14:35:42 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 27 Aug 2025 14:35:42 GMT Subject: RFR: 8366145: Help diagnose ubsan division by zero in computing pause time ratios In-Reply-To: References: <1hYLqTPwBlVCBFe09QMtJi7JHemtDnniTsEPbWvM5yI=.9a8ccf7a-20db-4517-9aaa-6020b0cfbf99@github.com> <4-mVFCgrEfPLUGe4273iLBAM1PhimtMjvHNIYp9AShE=.cc35e66e-d4fd-407f-bf5e-f20ffbf53012@github.com> <3EcFiM3bod-xVyWag1eEGrOzYL9bZfE_DEEvxvmKJr0=.1738be44-933d-449b-91ca-669bf13a8fc6@github.com> Message-ID: <6XYRhXInbHXhkZjRu-FbL1RWdB1jlJt_UXl9byIezJg=.23f8f707-6054-4fcc-8a02-2d7d05752d3c@github.com> On Wed, 27 Aug 2025 14:18:03 GMT, Kim Barrett wrote: >> I think `fabs` is just clutter, and doesn't add anything. > > I think checking for zero is fine, rather than some small interval. We're > trying to figure out how someone got a ubsan divide-by-zero complaint in the > next statement. It's a supposition that a broken (insufficiently granular) > clock was involved. If that's the case, checking for a small interval won't > change anything, as the coarse clock will either not tick, or tick by some > largish amount. also good with me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26939#discussion_r2304124306 From tschatzl at openjdk.org Wed Aug 27 14:39:21 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 27 Aug 2025 14:39:21 GMT Subject: RFR: 8365939: [Redo] G1: Move collection set related full gc reset code into abandon_collection_set() method Message-ID: Hi all, please review this attempt on clearing the young regions cset group early in `abandon_collection_set()` during full gc. The initial attempt failed because some verification code depended on the young gen remembered set being `Complete` and contain valid card entries. This change fixes both: - we need to clear the `young_regions_cset_group` with `uninstall_group_cardsets` being `true` to a) remove the cards and b) make it incomplete - some verification expects that the young gen remset is always complete, which is not necessary during full gc. Test: tier1-5, the failing test that caused the failures in JDK-8365780 passes always. Thanks, Thomas ------------- Commit messages: - 8365939 Changes: https://git.openjdk.org/jdk/pull/26948/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26948&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365939 Stats: 10 lines in 3 files changed: 4 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26948.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26948/head:pull/26948 PR: https://git.openjdk.org/jdk/pull/26948 From tschatzl at openjdk.org Wed Aug 27 15:34:04 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 27 Aug 2025 15:34:04 GMT Subject: RFR: 8365055: G1: Merge Heap Roots phase incorrectly clears young gen remembered set every time [v3] In-Reply-To: <8JFuOjov4pzLsgan8_D26HNVtWFNTBm7OzuMMwRVUAM=.f557c3d1-ccef-4ea2-ad9c-0c4a217f24b4@github.com> References: <8JFuOjov4pzLsgan8_D26HNVtWFNTBm7OzuMMwRVUAM=.f557c3d1-ccef-4ea2-ad9c-0c4a217f24b4@github.com> Message-ID: > Hi all, > > please review this fix to G1 heap root merging that cleared the young gen remembered set multiple times (for every merging) and overwriting the most recent statistics for the number of young gen cards. > > The latter is probably the more problematic, as it directly impacts young gen sizing statistics, potentially making young gen too large. > > The fix is to move the two statements to the proper place - get current number of young gen cards at startup, clear the young gen remset when starting a new collection set - we do not need to do that earlier after all. Additionally we can add some (superfluous?) verification that during GC we really do not add to the young gen remset. > > Testing: tier1-5 > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * fix issue: remember the current young regions cset group occupancy much earlier ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26695/files - new: https://git.openjdk.org/jdk/pull/26695/files/ba62be50..5cf09947 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26695&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26695&range=01-02 Stats: 27 lines in 5 files changed: 10 ins; 11 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/26695.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26695/head:pull/26695 PR: https://git.openjdk.org/jdk/pull/26695 From ayang at openjdk.org Wed Aug 27 15:36:42 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 27 Aug 2025 15:36:42 GMT Subject: RFR: 8365939: [Redo] G1: Move collection set related full gc reset code into abandon_collection_set() method In-Reply-To: References: Message-ID: <-UWHGOTrQchU2qOQ92zmHIbrBelUrVlCL0l91G7pfWA=.9c4dc1a1-f023-42c4-9ac2-36a5fcf24361@github.com> On Tue, 26 Aug 2025 17:44:04 GMT, Thomas Schatzl wrote: > Hi all, > > please review this attempt on clearing the young regions cset group early in `abandon_collection_set()` during full gc. > > The initial attempt failed because some verification code depended on the young gen remembered set being `Complete` and contain valid card entries. > > This change fixes both: > > - we need to clear the `young_regions_cset_group` with `uninstall_group_cardsets` being `true` to a) remove the cards and b) make it incomplete > - some verification expects that the young gen remset is always complete, which is not necessary during full gc. > > Test: tier1-5, the failing test that caused the failures in JDK-8365780 passes always. > > Thanks, > Thomas I wonder if the verification logic will be simpler if diff closures are in used in diff context, instead of reusing the same closure. ------------- Marked as reviewed by ayang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26948#pullrequestreview-3160412346 From ayang at openjdk.org Wed Aug 27 15:38:41 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 27 Aug 2025 15:38:41 GMT Subject: RFR: 8366145: Help diagnose ubsan division by zero in computing pause time ratios In-Reply-To: <1hYLqTPwBlVCBFe09QMtJi7JHemtDnniTsEPbWvM5yI=.9a8ccf7a-20db-4517-9aaa-6020b0cfbf99@github.com> References: <1hYLqTPwBlVCBFe09QMtJi7JHemtDnniTsEPbWvM5yI=.9a8ccf7a-20db-4517-9aaa-6020b0cfbf99@github.com> Message-ID: On Tue, 26 Aug 2025 11:22:30 GMT, Leo Korinth wrote: > This pull request is created to help diagnose the bug report https://bugs.openjdk.org/browse/JDK-8354430. > > The problem is that we get a ubsan runtime error when dividing by zero. Ubsan is not normally running, so I will add an assert making it easier to catch the problem and printing the value of the two variables that when subtracted will create a zero; it will hopefully help with diagnosis. > > Some comments: > 1) the result of `most_recent_gc_end_time_sec()` will not change within the function, thus I will not clutter the code with a new variable, is that okay? > 2) I added two calls to `fabs` which are most probably not needed (ieee floating point rules seems to say that positive and negative zero equals). However I think my proposed code makes it clear that I have thought about it. > > I am now running tier1-3 I suggest adding a `G1: ` prefix in the title. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26939#issuecomment-3228709050 From lkorinth at openjdk.org Wed Aug 27 16:26:53 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 27 Aug 2025 16:26:53 GMT Subject: RFR: 8366145: G1: Help diagnose ubsan division by zero in computing pause time ratios (g1Analytics.cpp) [v2] In-Reply-To: <1hYLqTPwBlVCBFe09QMtJi7JHemtDnniTsEPbWvM5yI=.9a8ccf7a-20db-4517-9aaa-6020b0cfbf99@github.com> References: <1hYLqTPwBlVCBFe09QMtJi7JHemtDnniTsEPbWvM5yI=.9a8ccf7a-20db-4517-9aaa-6020b0cfbf99@github.com> Message-ID: > This pull request is created to help diagnose the bug report https://bugs.openjdk.org/browse/JDK-8354430. > > The problem is that we get a ubsan runtime error when dividing by zero. Ubsan is not normally running, so I will add an assert making it easier to catch the problem and printing the value of the two variables that when subtracted will create a zero; it will hopefully help with diagnosis. > > Some comments: > 1) the result of `most_recent_gc_end_time_sec()` will not change within the function, thus I will not clutter the code with a new variable, is that okay? > 2) I added two calls to `fabs` which are most probably not needed (ieee floating point rules seems to say that positive and negative zero equals). However I think my proposed code makes it clear that I have thought about it. > > I am now running tier1-3 Leo Korinth 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' into _8366145 - 8366145: Help diagnose ubsan failure ------------- Changes: https://git.openjdk.org/jdk/pull/26939/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26939&range=01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26939.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26939/head:pull/26939 PR: https://git.openjdk.org/jdk/pull/26939 From duke at openjdk.org Wed Aug 27 16:53:41 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Wed, 27 Aug 2025 16:53:41 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer 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: On Wed, 27 Aug 2025 11:24:07 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 src/hotspot/share/memory/memoryReserver.cpp line 552: > 550: > 551: char* aligned_heap_base_min_address = align_up((char*)HeapBaseMinAddress, alignment); > 552: assert(aligned_heap_base_min_address != 0,"Should not be 0"); Suggestion: assert(aligned_heap_base_min_address != 0, "Should not be 0"); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2304663375 From iwalulya at openjdk.org Wed Aug 27 17:08:41 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 27 Aug 2025 17:08:41 GMT Subject: RFR: 8365939: [Redo] G1: Move collection set related full gc reset code into abandon_collection_set() method In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 17:44:04 GMT, Thomas Schatzl wrote: > Hi all, > > please review this attempt on clearing the young regions cset group early in `abandon_collection_set()` during full gc. > > The initial attempt failed because some verification code depended on the young gen remembered set being `Complete` and contain valid card entries. > > This change fixes both: > > - we need to clear the `young_regions_cset_group` with `uninstall_group_cardsets` being `true` to a) remove the cards and b) make it incomplete > - some verification expects that the young gen remset is always complete, which is not necessary during full gc. > > Test: tier1-5, the failing test that caused the failures in JDK-8365780 passes always. > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26948#pullrequestreview-3160877381 From iwalulya at openjdk.org Wed Aug 27 17:35:44 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 27 Aug 2025 17:35:44 GMT Subject: RFR: 8365055: G1: Merge Heap Roots phase incorrectly clears young gen remembered set every time [v3] In-Reply-To: References: <8JFuOjov4pzLsgan8_D26HNVtWFNTBm7OzuMMwRVUAM=.f557c3d1-ccef-4ea2-ad9c-0c4a217f24b4@github.com> Message-ID: <2spwM0zbvjDh_kXiTjFGVZX5xhwsZBOPLqjTGwUhIM8=.9899f0e9-0cc5-407f-8f0f-2bbde8a357c1@github.com> On Wed, 27 Aug 2025 15:34:04 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this fix to G1 heap root merging that cleared the young gen remembered set multiple times (for every merging) and overwriting the most recent statistics for the number of young gen cards. >> >> The latter is probably the more problematic, as it directly impacts young gen sizing statistics, potentially making young gen too large. >> >> The fix is to move the two statements to the proper place - get current number of young gen cards at startup, clear the young gen remset when starting a new collection set - we do not need to do that earlier after all. Additionally we can add some (superfluous?) verification that during GC we really do not add to the young gen remset. >> >> Testing: tier1-5 >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * fix issue: remember the current young regions cset group occupancy much earlier Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26695#pullrequestreview-3161023659 From duke at openjdk.org Wed Aug 27 18:31:03 2025 From: duke at openjdk.org (Rui Li) Date: Wed, 27 Aug 2025 18:31:03 GMT Subject: RFR: 8342640: GenShen: Silently ignoring ShenandoahGCHeuristics considered poor user-experience Message-ID: 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) ------------- Commit messages: - 8342640: GenShen: Silently ignoring ShenandoahGCHeuristics considered poor user-experience Changes: https://git.openjdk.org/jdk/pull/26968/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26968&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8342640 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26968.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26968/head:pull/26968 PR: https://git.openjdk.org/jdk/pull/26968 From eosterlund at openjdk.org Wed Aug 27 20:19:46 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 27 Aug 2025 20:19:46 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v5] In-Reply-To: References: Message-ID: <-MqvO74Up2R0qmEDtgyGY-yScxZ-v6ZQWxDtSxpKO_g=.56d4eeca-670d-41e4-9e96-ba20b1b44100@github.com> On Thu, 14 Aug 2025 20:37:51 GMT, Dean Long wrote: > @fisk , can I get you to review this? Sure! Based on the symptoms you described, my main comment is that we might be looking at the wrong places. I don't know if this is really about lock contention. Perhaps it is indirectly. But you mention there is still so e regression with ZGC. My hypothesis would be that it is the unnecessary incrementing of the global patching epoch that causes the regression when using ZGC. It is only really needed when disarming the nmethod - in orher words when the guard value is set to the good value. The point of incrementing the patching epoch is to protect other threads from entering the nmethod without executing an instruction cross modication fence. And all other threads will have to do that. Only ZGC uses the mode of nmethod entry barriers that does this due to being the only GC that updates instructions in a concurrent phase on AArch64. We are conservative on AArch64 and ensure the use of appropriate synchronous cross modifying code. But that's not needed when arming, which is what we do when making the bmethod not entrant. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26399#issuecomment-3229619234 From kbarrett at openjdk.org Wed Aug 27 21:58:43 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 27 Aug 2025 21:58:43 GMT Subject: RFR: 8365055: G1: Merge Heap Roots phase incorrectly clears young gen remembered set every time [v3] In-Reply-To: References: <8JFuOjov4pzLsgan8_D26HNVtWFNTBm7OzuMMwRVUAM=.f557c3d1-ccef-4ea2-ad9c-0c4a217f24b4@github.com> Message-ID: <2Hat3iSSRgCPQN2PsRmmi7h7GhdftE6pbr5xnRNcQ2I=.b08f55ff-34b0-412b-80cd-3d3a74c7389f@github.com> On Wed, 27 Aug 2025 15:34:04 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this fix to G1 heap root merging that cleared the young gen remembered set multiple times (for every merging) and overwriting the most recent statistics for the number of young gen cards. >> >> The latter is probably the more problematic, as it directly impacts young gen sizing statistics, potentially making young gen too large. >> >> The fix is to move the two statements to the proper place - get current number of young gen cards at startup, clear the young gen remset when starting a new collection set - we do not need to do that earlier after all. Additionally we can add some (superfluous?) verification that during GC we really do not add to the young gen remset. >> >> Testing: tier1-5 >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * fix issue: remember the current young regions cset group occupancy much earlier Marked as reviewed by kbarrett (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26695#pullrequestreview-3161865188 From kbarrett at openjdk.org Wed Aug 27 22:02:43 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 27 Aug 2025 22:02:43 GMT Subject: RFR: 8366145: G1: Help diagnose ubsan division by zero in computing pause time ratios (g1Analytics.cpp) [v2] In-Reply-To: References: <1hYLqTPwBlVCBFe09QMtJi7JHemtDnniTsEPbWvM5yI=.9a8ccf7a-20db-4517-9aaa-6020b0cfbf99@github.com> Message-ID: On Wed, 27 Aug 2025 16:26:53 GMT, Leo Korinth wrote: >> This pull request is created to help diagnose the bug report https://bugs.openjdk.org/browse/JDK-8354430. >> >> The problem is that we get a ubsan runtime error when dividing by zero. Ubsan is not normally running, so I will add an assert making it easier to catch the problem and printing the value of the two variables that when subtracted will create a zero; it will hopefully help with diagnosis. >> >> Some comments: >> 1) the result of `most_recent_gc_end_time_sec()` will not change within the function, thus I will not clutter the code with a new variable, is that okay? >> 2) I added two calls to `fabs` which are most probably not needed (ieee floating point rules seems to say that positive and negative zero equals). However I think my proposed code makes it clear that I have thought about it. >> >> I am now running tier1-3 > > Leo Korinth 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' into _8366145 > - 8366145: Help diagnose ubsan failure Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26939#pullrequestreview-3161871673 From duke at openjdk.org Wed Aug 27 22:47:58 2025 From: duke at openjdk.org (Rui Li) Date: Wed, 27 Aug 2025 22:47:58 GMT Subject: RFR: 8342640: GenShen: Silently ignoring ShenandoahGCHeuristics considered poor user-experience [v2] In-Reply-To: References: Message-ID: <-G7AGJRPOYIhjHRPhx8fyuinCe-nLXZfbZO3Sz5Y7iM=.0b6d63d6-24e6-4618-9fa0-106dde9fa2f7@github.com> > 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 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26968/files - new: https://git.openjdk.org/jdk/pull/26968/files/c999d47f..247dce42 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26968&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26968&range=00-01 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26968.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26968/head:pull/26968 PR: https://git.openjdk.org/jdk/pull/26968 From ysr at openjdk.org Wed Aug 27 23:07:41 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Wed, 27 Aug 2025 23:07:41 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: 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 fixing this. The new behaviour is much more user friendly, and I like the clear error message. Approved, modulo testing results (which I don't expect any issues with given the change). ------------- Marked as reviewed by ysr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26968#pullrequestreview-3162061524 From wkemper at openjdk.org Wed Aug 27 23:13:41 2025 From: wkemper at openjdk.org (William Kemper) Date: Wed, 27 Aug 2025 23:13:41 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: <0Y1dV8xouNEnMbmpNqT5rLrA96_K5YxmpWkCCiBDcOk=.2f088f9f-c3b1-4d14-a033-db1bb195da25@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 Looks good to me. ------------- Marked as reviewed by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26968#pullrequestreview-3162081094 From ysr at openjdk.org Thu Aug 28 01:08:50 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Thu, 28 Aug 2025 01:08:50 GMT Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may raise threshold prematurely [v3] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 17:23:11 GMT, William Kemper wrote: >> The adaptive tenuring algorithm has been modified to begin its evaluation of mortality rates from the current tenuring threshold. To compliment this change, objects must also now be strictly above the tenuring threshold to be promoted (instead of greater-than-or-equal). > > William Kemper has updated the pull request incrementally with one additional commit since the last revision: > > Fix windows build Left some comments. Will take a look at the tests and re-review the computation loop, once I understand your response to my comment about uniformly using `is_tenurable` (or its moral equivalent of doing a strictly greater than check in age comparisons for tenuring). Sorry for the delay. Also, are there any comparative performance numbers to share yet? src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 219: > 217: // We don't want to deal with MT here just to ensure we read the right mark word. > 218: // Skip the potential promotion attempt for this one. > 219: } else if (age_census()->is_tenurable(r->age() + mark.age())) { See comment above re using this boolean accessor at other places where comparisons are made with tenuring threshold. ------------- PR Review: https://git.openjdk.org/jdk/pull/26906#pullrequestreview-3162543552 PR Comment: https://git.openjdk.org/jdk/pull/26906#issuecomment-3230713766 PR Review Comment: https://git.openjdk.org/jdk/pull/26906#discussion_r2305790877 From ysr at openjdk.org Thu Aug 28 01:08:50 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Thu, 28 Aug 2025 01:08:50 GMT Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may raise threshold prematurely [v3] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 18:27:57 GMT, William Kemper wrote: >> William Kemper has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix windows build > > src/hotspot/share/gc/shenandoah/shenandoahAgeCensus.hpp line 181: > >> 179: // Return true if this age is above the tenuring threshold. >> 180: bool is_tenurable(uint age) const { >> 181: return age > tenuring_threshold(); > > Another key change. This prevents the algorithm from seeing higher mortality rates caused by promotions in the cohort at tenuring age. The strict ">" says objects of age strictly greater than the computed tenuring threshold are tenurable, not those of that age. This might make sense if it were used at all the places where tenuring decisions were being made during evacuation. Was that the intention? That doesn't seem to be the case -- there are pre-existing places in the code where a raw comparison with the tenuring threshold are made that don't do the strict check. Might be a good idea to go over all such spots and use this method (and inline it for performance?). It would then make `tenuring_threshold()` a private accessor, so the official API would be `is_tenurable(age)`, and no raw comparisons w/`tenuring_threshold()` that might become mutually inconsistent. See raw comparisons in: 1. `ShenandoahYoungHeuristics::choose_young_collection_set` 2. `ShenandoahGenerationalEvacuationTask::maybe_promote_region` 3. `ShenandoahGenerationalHeuristics::choose_collection_set` 4. `ShenandoahGenerationalHeuristics::add_preselected_regions_to_collection_set` 5. `ShenandoahGlobalHeuristics::choose_global_collection_set` 6. `ShenandoahCollectionSet::add_region` 7. etc... there are several more. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26906#discussion_r2305788307 From duke at openjdk.org Thu Aug 28 01:19:41 2025 From: duke at openjdk.org (duke) Date: Thu, 28 Aug 2025 01:19:41 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: 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 @rgithubli Your change (at version 247dce42a12bad7d7a305819cb0057613912ca85) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26968#issuecomment-3230808479 From aboldtch at openjdk.org Thu Aug 28 05:05:53 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 28 Aug 2025 05:05:53 GMT Subject: Integrated: 8366223: ZGC: ZPageAllocator::cleanup_failed_commit_multi_partition is broken In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 09:37:46 GMT, Axel Boldt-Christmas wrote: > While investigating [JDK-8366147](https://bugs.openjdk.org/browse/JDK-8366147) we also found that ZPageAllocator::cleanup_failed_commit_multi_partition is broken. > > The implementation is intended to work by going over each partitions part of the allocation one by one and returning any harvested or committed and mapped memory to to cache and returning any failed to be committed physical associations back to our internal free lists. > > But when deriving what part of the memory is associated with which partition it uses the wrong variable and ends up working with the wrong memory. And multiple partitions will end up working on the same supposedly mutually exclusive memory. > > This fix is to use the correct `partial_vmem` rather than `vmem` which holds the whole allocation. > > The new test reproduces this error. The test is tightly coupled to the current ZPageAllocator implementation and its policies. We might want to enhance this test in the future to ensure that we are actually provoking commit failures with harvesting and get notified if this changes. Currently there is no none intrusive way to do this. The best option might be our JFR events which contain all the information. > > * Testing (In progress) > * Oracle supported platforms tier1 + ZGC tier1-8 This pull request has now been integrated. Changeset: 501e6aed Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/501e6aed4407d63b000320168dc5d0553ce8a23b Stats: 122 lines in 4 files changed: 120 ins; 0 del; 2 mod 8366223: ZGC: ZPageAllocator::cleanup_failed_commit_multi_partition is broken Reviewed-by: stefank, jsikstro ------------- PR: https://git.openjdk.org/jdk/pull/26953 From aboldtch at openjdk.org Thu Aug 28 05:05:51 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 28 Aug 2025 05:05:51 GMT Subject: RFR: 8366223: ZGC: ZPageAllocator::cleanup_failed_commit_multi_partition is broken [v2] In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 09:57:25 GMT, Axel Boldt-Christmas wrote: >> While investigating [JDK-8366147](https://bugs.openjdk.org/browse/JDK-8366147) we also found that ZPageAllocator::cleanup_failed_commit_multi_partition is broken. >> >> The implementation is intended to work by going over each partitions part of the allocation one by one and returning any harvested or committed and mapped memory to to cache and returning any failed to be committed physical associations back to our internal free lists. >> >> But when deriving what part of the memory is associated with which partition it uses the wrong variable and ends up working with the wrong memory. And multiple partitions will end up working on the same supposedly mutually exclusive memory. >> >> This fix is to use the correct `partial_vmem` rather than `vmem` which holds the whole allocation. >> >> The new test reproduces this error. The test is tightly coupled to the current ZPageAllocator implementation and its policies. We might want to enhance this test in the future to ensure that we are actually provoking commit failures with harvesting and get notified if this changes. Currently there is no none intrusive way to do this. The best option might be our JFR events which contain all the information. >> >> * Testing (In progress) >> * Oracle supported platforms tier1 + ZGC tier1-8 > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Run in driver rather than othervm Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26953#issuecomment-3231893652 From dholmes at openjdk.org Thu Aug 28 06:38:44 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 28 Aug 2025 06:38:44 GMT Subject: RFR: 8366157: Clarify in man pages that only G1 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 should be reviewed by GC team not core-libs ------------- PR Comment: https://git.openjdk.org/jdk/pull/26940#issuecomment-3232138155 From tschatzl at openjdk.org Thu Aug 28 07:12:43 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 28 Aug 2025 07:12:43 GMT Subject: RFR: 8366157: Clarify in man pages that only G1 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`. src/java.base/share/man/java.md line 2507: > 2505: specified value doesn't adapt to your heap size. G1's default for the > 2506: maximum pause time target is 200 milliseconds and only G1 currently supports > 2507: a maximum GC pause time target. Suggestion: specified value doesn't adapt to your heap size. Currently only G1 supports a maximum GC pause time target. The default value is 200 milliseconds. Reason for this suggestion: * it seems more important that only G1 supports this value than the default value, so put this first * these are two separate statements, so put them into two separate sentences. The default value is also independent of the collector. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26940#discussion_r2306431827 From tschatzl at openjdk.org Thu Aug 28 07:27:52 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 28 Aug 2025 07:27:52 GMT Subject: RFR: 8366145: G1: Help diagnose ubsan division by zero in computing pause time ratios (g1Analytics.cpp) [v2] In-Reply-To: References: <1hYLqTPwBlVCBFe09QMtJi7JHemtDnniTsEPbWvM5yI=.9a8ccf7a-20db-4517-9aaa-6020b0cfbf99@github.com> Message-ID: On Wed, 27 Aug 2025 16:26:53 GMT, Leo Korinth wrote: >> This pull request is created to help diagnose the bug report https://bugs.openjdk.org/browse/JDK-8354430. >> >> The problem is that we get a ubsan runtime error when dividing by zero. Ubsan is not normally running, so I will add an assert making it easier to catch the problem and printing the value of the two variables that when subtracted will create a zero; it will hopefully help with diagnosis. >> >> Some comments: >> 1) the result of `most_recent_gc_end_time_sec()` will not change within the function, thus I will not clutter the code with a new variable, is that okay? >> 2) I added two calls to `fabs` which are most probably not needed (ieee floating point rules seems to say that positive and negative zero equals). However I think my proposed code makes it clear that I have thought about it. >> >> I am now running tier1-3 > > Leo Korinth 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' into _8366145 > - 8366145: Help diagnose ubsan failure Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26939#pullrequestreview-3163565957 From tschatzl at openjdk.org Thu Aug 28 07:59:45 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 28 Aug 2025 07:59:45 GMT Subject: RFR: 8366145: G1: Help diagnose ubsan division by zero in computing pause time ratios (g1Analytics.cpp) [v2] In-Reply-To: References: <1hYLqTPwBlVCBFe09QMtJi7JHemtDnniTsEPbWvM5yI=.9a8ccf7a-20db-4517-9aaa-6020b0cfbf99@github.com> Message-ID: On Wed, 27 Aug 2025 16:26:53 GMT, Leo Korinth wrote: >> This pull request is created to help diagnose the bug report https://bugs.openjdk.org/browse/JDK-8354430. >> >> The problem is that we get a ubsan runtime error when dividing by zero. Ubsan is not normally running, so I will add an assert making it easier to catch the problem and printing the value of the two variables that when subtracted will create a zero; it will hopefully help with diagnosis. >> >> Some comments: >> 1) the result of `most_recent_gc_end_time_sec()` will not change within the function, thus I will not clutter the code with a new variable, is that okay? >> 2) I added two calls to `fabs` which are most probably not needed (ieee floating point rules seems to say that positive and negative zero equals). However I think my proposed code makes it clear that I have thought about it. >> >> I am now running tier1-3 > > Leo Korinth 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' into _8366145 > - 8366145: Help diagnose ubsan failure Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26939#pullrequestreview-3163683368 From duke at openjdk.org Thu Aug 28 08:11:42 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Thu, 28 Aug 2025 08:11:42 GMT Subject: RFR: 8366157: Clarify in man pages that only G1 supports MaxGCPauseMillis In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 07:09:49 GMT, Thomas Schatzl wrote: >> Hi all, >> >> This patch clarifies the description of `MaxGCPauseMillis`. > > src/java.base/share/man/java.md line 2507: > >> 2505: specified value doesn't adapt to your heap size. G1's default for the >> 2506: maximum pause time target is 200 milliseconds and only G1 currently supports >> 2507: a maximum GC pause time target. > > Suggestion: > > specified value doesn't adapt to your heap size. The default value is 200 milliseconds. > Currently only G1 supports a maximum GC pause time target. > > > Reason for this suggestion: > * it seems more important that only G1 supports this value than the default value, so put this first > * these are two separate statements, so put them into two separate sentences. The default value is also independent of the collector. > The specified value doesn't adapt to your heap size. Should we consider putting this last as that seems like a less important implementation detail compared to which GC support it and the default value? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26940#discussion_r2306587544 From tschatzl at openjdk.org Thu Aug 28 08:38:43 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 28 Aug 2025 08:38:43 GMT Subject: RFR: 8366157: Clarify in man pages that only G1 supports MaxGCPauseMillis In-Reply-To: References: Message-ID: <09eFHC3NUyLLZVl95dHB7UUd3rA4ZL0vUnsNzfYV7lk=.0e33ad49-4d44-4781-aa21-9a5b87aa8aac@github.com> On Thu, 28 Aug 2025 08:07:58 GMT, Jonas Norlinder wrote: >> src/java.base/share/man/java.md line 2507: >> >>> 2505: specified value doesn't adapt to your heap size. G1's default for the >>> 2506: maximum pause time target is 200 milliseconds and only G1 currently supports >>> 2507: a maximum GC pause time target. >> >> Suggestion: >> >> specified value doesn't adapt to your heap size. The default value is 200 milliseconds. >> Currently only G1 supports a maximum GC pause time target. >> >> >> Reason for this suggestion: >> * it seems more important that only G1 supports this value than the default value, so put this first >> * these are two separate statements, so put them into two separate sentences. The default value is also independent of the collector. > >> The specified value doesn't adapt to your heap size. > > Should we consider putting this last as that seems like a less important implementation detail compared to which GC support it and the default value? Actually we can leave this sentence completely out. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26940#discussion_r2306672722 From tschatzl at openjdk.org Thu Aug 28 08:41:42 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 28 Aug 2025 08:41:42 GMT Subject: RFR: 8366157: Clarify in man pages that only G1 supports MaxGCPauseMillis In-Reply-To: <09eFHC3NUyLLZVl95dHB7UUd3rA4ZL0vUnsNzfYV7lk=.0e33ad49-4d44-4781-aa21-9a5b87aa8aac@github.com> References: <09eFHC3NUyLLZVl95dHB7UUd3rA4ZL0vUnsNzfYV7lk=.0e33ad49-4d44-4781-aa21-9a5b87aa8aac@github.com> Message-ID: <_pI22lkHV3yVEmlP8Tij2_mArxxGSjcIqPiQWXWYZGk=.625a5455-1964-41e7-9642-94ae25ccfc30@github.com> On Thu, 28 Aug 2025 08:36:22 GMT, Thomas Schatzl wrote: >>> The specified value doesn't adapt to your heap size. >> >> Should we consider putting this last as that seems like a less important implementation detail compared to which GC support it and the default value? > > Actually we can leave this sentence completely out. Typically heuristically determined values have a default value of `0`, with a clear indication that the actual value is determined ergonomically. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26940#discussion_r2306678910 From aboldtch at openjdk.org Thu Aug 28 08:51:48 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 28 Aug 2025 08:51:48 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer 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: <98TT8Dv88wv5zq2bm2mvAN80JlwICKKHZ8QVfeA414A=.87ac3000-9705-480f-aa8c-d24a27439391@github.com> On Wed, 27 Aug 2025 11:24:07 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 I agree with Johan that we cast this to a pointer to early. I much prefer `uintptr_t` rather than `char*` when doing byte sized pointer arithmetic on values which represent address which are not supposed to be dereferenced. In this particular instance, in `HeapReserver::Instance::reserve_compressed_oops_heap` we might want to read `HeapBaseMinAddress` as: ```C++ uintptr_t aligned_heap_base_min_address = align_up(MAX2(HeapBaseMinAddress, alignment), alignment); Because `aligned_heap_base_min_address` is used later directly as an address. (We might instead want to propagate non pointer types further, but it will be a larger refactoring that is probably not suitable for this rfe). Regardless I feel like we should not change the public "API" of HeapBaseMinAddress in a bug fix, I would rather we simply treat the value of HeapBaseMinAddress as a heap base minimum address and use it as a lower bound. No OS we run on (afaik) will let us reserve an address space where 0 can be dereferenced. I also wonder how we got here with `HeapBaseMinAddress == 0` as we set the value back to the default if it is lower when using compressed oops (in `Arguments::set_heap_size()`). And I think the default is 2G on all platforms. _There seems to be a lot of pre-existing weirdness / corner cases in this code_ ------------- PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3232561871 From tschatzl at openjdk.org Thu Aug 28 09:21:24 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 28 Aug 2025 09:21:24 GMT Subject: RFR: 8365939: [Redo] G1: Move collection set related full gc reset code into abandon_collection_set() method In-Reply-To: <-UWHGOTrQchU2qOQ92zmHIbrBelUrVlCL0l91G7pfWA=.9c4dc1a1-f023-42c4-9ac2-36a5fcf24361@github.com> References: <-UWHGOTrQchU2qOQ92zmHIbrBelUrVlCL0l91G7pfWA=.9c4dc1a1-f023-42c4-9ac2-36a5fcf24361@github.com> Message-ID: On Wed, 27 Aug 2025 15:34:35 GMT, Albert Mingkun Yang wrote: > I wonder if the verification logic will be simpler if diff closures are in used in diff context, instead of reusing the same closure. I thought about that too, I'll file a CR about that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26948#issuecomment-3232658158 From tschatzl at openjdk.org Thu Aug 28 09:21:30 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 28 Aug 2025 09:21:30 GMT Subject: RFR: 8365055: G1: Merge Heap Roots phase incorrectly clears young gen remembered set every time [v3] In-Reply-To: <2Hat3iSSRgCPQN2PsRmmi7h7GhdftE6pbr5xnRNcQ2I=.b08f55ff-34b0-412b-80cd-3d3a74c7389f@github.com> References: <8JFuOjov4pzLsgan8_D26HNVtWFNTBm7OzuMMwRVUAM=.f557c3d1-ccef-4ea2-ad9c-0c4a217f24b4@github.com> <2Hat3iSSRgCPQN2PsRmmi7h7GhdftE6pbr5xnRNcQ2I=.b08f55ff-34b0-412b-80cd-3d3a74c7389f@github.com> Message-ID: On Wed, 27 Aug 2025 21:56:18 GMT, Kim Barrett wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * fix issue: remember the current young regions cset group occupancy much earlier > > Marked as reviewed by kbarrett (Reviewer). Thanks @kimbarrett @walulyai for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/26695#issuecomment-3232661462 From tschatzl at openjdk.org Thu Aug 28 09:21:27 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 28 Aug 2025 09:21:27 GMT Subject: RFR: 8365939: [Redo] G1: Move collection set related full gc reset code into abandon_collection_set() method In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 17:06:22 GMT, Ivan Walulya wrote: >> Hi all, >> >> please review this attempt on clearing the young regions cset group early in `abandon_collection_set()` during full gc. >> >> The initial attempt failed because some verification code depended on the young gen remembered set being `Complete` and contain valid card entries. >> >> This change fixes both: >> >> - we need to clear the `young_regions_cset_group` with `uninstall_group_cardsets` being `true` to a) remove the cards and b) make it incomplete >> - some verification expects that the young gen remset is always complete, which is not necessary during full gc. >> >> Test: tier1-5, the failing test that caused the failures in JDK-8365780 passes always. >> >> Thanks, >> Thomas > > Marked as reviewed by iwalulya (Reviewer). Thanks @walulyai @albertnetymk for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/26948#issuecomment-3232659042 From tschatzl at openjdk.org Thu Aug 28 09:24:46 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 28 Aug 2025 09:24:46 GMT Subject: RFR: 8366157: Clarify in man pages that only G1 supports MaxGCPauseMillis In-Reply-To: <_pI22lkHV3yVEmlP8Tij2_mArxxGSjcIqPiQWXWYZGk=.625a5455-1964-41e7-9642-94ae25ccfc30@github.com> References: <09eFHC3NUyLLZVl95dHB7UUd3rA4ZL0vUnsNzfYV7lk=.0e33ad49-4d44-4781-aa21-9a5b87aa8aac@github.com> <_pI22lkHV3yVEmlP8Tij2_mArxxGSjcIqPiQWXWYZGk=.625a5455-1964-41e7-9642-94ae25ccfc30@github.com> Message-ID: On Thu, 28 Aug 2025 08:38:42 GMT, Thomas Schatzl wrote: >> Actually we can leave this sentence completely out. > > Typically heuristically determined values have a default value of `0`, with a clear indication that the actual value is determined ergonomically. Actually, we should probably also remove the "Currently" of the last sentence because we do not want/need to give indications about future support for other collectors. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26940#discussion_r2306800822 From tschatzl at openjdk.org Thu Aug 28 09:24:54 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 28 Aug 2025 09:24:54 GMT Subject: Integrated: 8365939: [Redo] G1: Move collection set related full gc reset code into abandon_collection_set() method In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 17:44:04 GMT, Thomas Schatzl wrote: > Hi all, > > please review this attempt on clearing the young regions cset group early in `abandon_collection_set()` during full gc. > > The initial attempt failed because some verification code depended on the young gen remembered set being `Complete` and contain valid card entries. > > This change fixes both: > > - we need to clear the `young_regions_cset_group` with `uninstall_group_cardsets` being `true` to a) remove the cards and b) make it incomplete > - some verification expects that the young gen remset is always complete, which is not necessary during full gc. > > Test: tier1-5, the failing test that caused the failures in JDK-8365780 passes always. > > Thanks, > Thomas This pull request has now been integrated. Changeset: 7469a274 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/7469a274bb70b2cdc8a47e62cc989f86766c605a Stats: 10 lines in 3 files changed: 4 ins; 5 del; 1 mod 8365939: [Redo] G1: Move collection set related full gc reset code into abandon_collection_set() method Reviewed-by: ayang, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/26948 From tschatzl at openjdk.org Thu Aug 28 09:26:59 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 28 Aug 2025 09:26:59 GMT Subject: Integrated: 8365055: G1: Merge Heap Roots phase incorrectly clears young gen remembered set every time In-Reply-To: <8JFuOjov4pzLsgan8_D26HNVtWFNTBm7OzuMMwRVUAM=.f557c3d1-ccef-4ea2-ad9c-0c4a217f24b4@github.com> References: <8JFuOjov4pzLsgan8_D26HNVtWFNTBm7OzuMMwRVUAM=.f557c3d1-ccef-4ea2-ad9c-0c4a217f24b4@github.com> Message-ID: On Fri, 8 Aug 2025 12:09:07 GMT, Thomas Schatzl wrote: > Hi all, > > please review this fix to G1 heap root merging that cleared the young gen remembered set multiple times (for every merging) and overwriting the most recent statistics for the number of young gen cards. > > The latter is probably the more problematic, as it directly impacts young gen sizing statistics, potentially making young gen too large. > > The fix is to move the two statements to the proper place - get current number of young gen cards at startup, clear the young gen remset when starting a new collection set - we do not need to do that earlier after all. Additionally we can add some (superfluous?) verification that during GC we really do not add to the young gen remset. > > Testing: tier1-5 > > Thanks, > Thomas This pull request has now been integrated. Changeset: d06c66f7 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/d06c66f7f5a6d3c649c0a10ad735f0cc7c673b2a Stats: 23 lines in 5 files changed: 9 ins; 11 del; 3 mod 8365055: G1: Merge Heap Roots phase incorrectly clears young gen remembered set every time Reviewed-by: kbarrett, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/26695 From duke at openjdk.org Thu Aug 28 09:30:02 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Thu, 28 Aug 2025 09:30:02 GMT Subject: RFR: 8366157: Clarify in man pages that only G1 supports MaxGCPauseMillis [v2] In-Reply-To: References: Message-ID: > Hi all, > > This patch clarifies the description of `MaxGCPauseMillis`. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Improve description after review discussion ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26940/files - new: https://git.openjdk.org/jdk/pull/26940/files/e1fb04b0..868d446f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26940&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26940&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26940.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26940/head:pull/26940 PR: https://git.openjdk.org/jdk/pull/26940 From lkorinth at openjdk.org Thu Aug 28 09:33:46 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 28 Aug 2025 09:33:46 GMT Subject: RFR: 8366145: G1: Help diagnose ubsan division by zero in computing pause time ratios (g1Analytics.cpp) [v2] In-Reply-To: References: <1hYLqTPwBlVCBFe09QMtJi7JHemtDnniTsEPbWvM5yI=.9a8ccf7a-20db-4517-9aaa-6020b0cfbf99@github.com> Message-ID: On Wed, 27 Aug 2025 16:26:53 GMT, Leo Korinth wrote: >> This pull request is created to help diagnose the bug report https://bugs.openjdk.org/browse/JDK-8354430. >> >> The problem is that we get a ubsan runtime error when dividing by zero. Ubsan is not normally running, so I will add an assert making it easier to catch the problem and printing the value of the two variables that when subtracted will create a zero; it will hopefully help with diagnosis. >> >> Some comments: >> 1) the result of `most_recent_gc_end_time_sec()` will not change within the function, thus I will not clutter the code with a new variable, is that okay? >> 2) I added two calls to `fabs` which are most probably not needed (ieee floating point rules seems to say that positive and negative zero equals). However I think my proposed code makes it clear that I have thought about it. >> >> I am now running tier1-3 > > Leo Korinth 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' into _8366145 > - 8366145: Help diagnose ubsan failure Thanks Thomas and Kim! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26939#issuecomment-3232719748 From aboldtch at openjdk.org Thu Aug 28 09:46:45 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 28 Aug 2025 09:46:45 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer In-Reply-To: <98TT8Dv88wv5zq2bm2mvAN80JlwICKKHZ8QVfeA414A=.87ac3000-9705-480f-aa8c-d24a27439391@github.com> References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> <98TT8Dv88wv5zq2bm2mvAN80JlwICKKHZ8QVfeA414A=.87ac3000-9705-480f-aa8c-d24a27439391@github.com> Message-ID: On Thu, 28 Aug 2025 08:49:06 GMT, Axel Boldt-Christmas wrote: >I also wonder how we got here with HeapBaseMinAddress == 0 as we set the value back to the default if it is lower when using compressed oops (in Arguments::set_heap_size()). And I think the default is 2G on all platforms. I realise now that this is based on if we have set the max heap explicitly. So we can end up with 0 as the lower bound in `try_reserve_range` which will cause us to request "any address", which seems like another bug. (Making sure `aligned_heap_base_min_address != 0` fixes this here, but `try_reserve_range` should probably guard agains having an `attach_point` which is 0 or a `lowest_start` which is 0.) While experimenting with the flags I notice we do not protect against overflow in the reservation code so setting a high `HeapBaseMinAddress` will crash. And it is not captured by `TestOptionsWithRanges` because it cannot understand our constraint function and will only try SIZE_MAX, but we only allow SIZE_MAX aligned down to our alignment. Regardless seems like this code is crawling with bugs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3232761537 From tschatzl at openjdk.org Thu Aug 28 11:29:43 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 28 Aug 2025 11:29:43 GMT Subject: RFR: 8366157: Clarify in man pages that only G1 supports MaxGCPauseMillis [v2] In-Reply-To: References: Message-ID: <0574pOYHNwhNEisrTH_npVyYWqh-VNYzy6CSoiBuDHg=.2a37d018-5508-4f33-9354-5c8290710499@github.com> On Thu, 28 Aug 2025 09:30:02 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This patch clarifies the description of `MaxGCPauseMillis`. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Improve description after review discussion Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26940#pullrequestreview-3164457520 From lkorinth at openjdk.org Thu Aug 28 11:40:47 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 28 Aug 2025 11:40:47 GMT Subject: Integrated: 8366145: G1: Help diagnose ubsan division by zero in computing pause time ratios (g1Analytics.cpp) In-Reply-To: <1hYLqTPwBlVCBFe09QMtJi7JHemtDnniTsEPbWvM5yI=.9a8ccf7a-20db-4517-9aaa-6020b0cfbf99@github.com> References: <1hYLqTPwBlVCBFe09QMtJi7JHemtDnniTsEPbWvM5yI=.9a8ccf7a-20db-4517-9aaa-6020b0cfbf99@github.com> Message-ID: On Tue, 26 Aug 2025 11:22:30 GMT, Leo Korinth wrote: > This pull request is created to help diagnose the bug report https://bugs.openjdk.org/browse/JDK-8354430. > > The problem is that we get a ubsan runtime error when dividing by zero. Ubsan is not normally running, so I will add an assert making it easier to catch the problem and printing the value of the two variables that when subtracted will create a zero; it will hopefully help with diagnosis. > > Some comments: > 1) the result of `most_recent_gc_end_time_sec()` will not change within the function, thus I will not clutter the code with a new variable, is that okay? > 2) I added two calls to `fabs` which are most probably not needed (ieee floating point rules seems to say that positive and negative zero equals). However I think my proposed code makes it clear that I have thought about it. > > I am now running tier1-3 This pull request has now been integrated. Changeset: b0f5b23e Author: Leo Korinth URL: https://git.openjdk.org/jdk/commit/b0f5b23ed2a2f3b9d97754ced5382bb3fb3e8f40 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8366145: G1: Help diagnose ubsan division by zero in computing pause time ratios (g1Analytics.cpp) Reviewed-by: tschatzl, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/26939 From aboldtch at openjdk.org Thu Aug 28 12:21:29 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 28 Aug 2025 12:21:29 GMT Subject: RFR: 8366147: ZGC: ZPageAllocator::cleanup_failed_commit_single_partition may leak memory [v4] In-Reply-To: References: Message-ID: > ZPageAllocator::cleanup_failed_commit_single_partition is responsible for cleaning up the successful part of a failed allocation by returning it to the cache so it can be reused. > > When a commit fails the the parts that should be returned is any "harvested" memory (memory it took from the cache) and any partially freshly committed memory. > > In a late revision of [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) we rewrote part of the allocation logic such that the "harvested" part was no longer part of the partial vmems after successfully harvesting. However the cleanup code was not adapted to this change. > > The solution is to add back both the harvested and newly committed memory, not just the newly committed part. > > * Testing (In progress) > * Oracle supported platforms tier1 + ZGC tier1-8 Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8366147 - Change name and addition order - Remove extra newline - Run in driver rather than othervm - 8366147: ZGC: ZPageAllocator::cleanup_failed_commit_single_partition may leak memory - Run in driver rather than othervm - 8366223: ZGC: ZPageAllocator::cleanup_failed_commit_multi_partition is broken ------------- Changes: https://git.openjdk.org/jdk/pull/26954/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26954&range=03 Stats: 19 lines in 2 files changed: 13 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/26954.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26954/head:pull/26954 PR: https://git.openjdk.org/jdk/pull/26954 From jsikstro at openjdk.org Thu Aug 28 12:28:19 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Thu, 28 Aug 2025 12:28:19 GMT Subject: RFR: 8366065: ZGC: Differentiate Young Collection type strings in ZGC statistics Message-ID: 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 ------------- Commit messages: - 8366065: ZGC: Differentiate Young Collection type strings in statistics Changes: https://git.openjdk.org/jdk/pull/26986/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26986&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366065 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26986.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26986/head:pull/26986 PR: https://git.openjdk.org/jdk/pull/26986 From aboldtch at openjdk.org Thu Aug 28 12:32:26 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 28 Aug 2025 12:32:26 GMT Subject: RFR: 8366147: ZGC: ZPageAllocator::cleanup_failed_commit_single_partition may leak memory [v5] In-Reply-To: References: Message-ID: > ZPageAllocator::cleanup_failed_commit_single_partition is responsible for cleaning up the successful part of a failed allocation by returning it to the cache so it can be reused. > > When a commit fails the the parts that should be returned is any "harvested" memory (memory it took from the cache) and any partially freshly committed memory. > > In a late revision of [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) we rewrote part of the allocation logic such that the "harvested" part was no longer part of the partial vmems after successfully harvesting. However the cleanup code was not adapted to this change. > > The solution is to add back both the harvested and newly committed memory, not just the newly committed part. > > * Testing (In progress) > * Oracle supported platforms tier1 + ZGC tier1-8 Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Update comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26954/files - new: https://git.openjdk.org/jdk/pull/26954/files/f4e45462..f1b5ecb6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26954&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26954&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26954.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26954/head:pull/26954 PR: https://git.openjdk.org/jdk/pull/26954 From aboldtch at openjdk.org Thu Aug 28 13:14:18 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 28 Aug 2025 13:14:18 GMT Subject: RFR: 8366147: ZGC: ZPageAllocator::cleanup_failed_commit_single_partition may leak memory [v6] In-Reply-To: References: Message-ID: > ZPageAllocator::cleanup_failed_commit_single_partition is responsible for cleaning up the successful part of a failed allocation by returning it to the cache so it can be reused. > > When a commit fails the the parts that should be returned is any "harvested" memory (memory it took from the cache) and any partially freshly committed memory. > > In a late revision of [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) we rewrote part of the allocation logic such that the "harvested" part was no longer part of the partial vmems after successfully harvesting. However the cleanup code was not adapted to this change. > > The solution is to add back both the harvested and newly committed memory, not just the newly committed part. > > * Testing (In progress) > * Oracle supported platforms tier1 + ZGC tier1-8 Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Update variable names ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26954/files - new: https://git.openjdk.org/jdk/pull/26954/files/f1b5ecb6..bfdd6474 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26954&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26954&range=04-05 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/26954.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26954/head:pull/26954 PR: https://git.openjdk.org/jdk/pull/26954 From stefank at openjdk.org Thu Aug 28 13:50:44 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 28 Aug 2025 13:50:44 GMT Subject: RFR: 8366147: ZGC: ZPageAllocator::cleanup_failed_commit_single_partition may leak memory [v6] In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 13:14:18 GMT, Axel Boldt-Christmas wrote: >> ZPageAllocator::cleanup_failed_commit_single_partition is responsible for cleaning up the successful part of a failed allocation by returning it to the cache so it can be reused. >> >> When a commit fails the the parts that should be returned is any "harvested" memory (memory it took from the cache) and any partially freshly committed memory. >> >> In a late revision of [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) we rewrote part of the allocation logic such that the "harvested" part was no longer part of the partial vmems after successfully harvesting. However the cleanup code was not adapted to this change. >> >> The solution is to add back both the harvested and newly committed memory, not just the newly committed part. >> >> * Testing (In progress) >> * Oracle supported platforms tier1 + ZGC tier1-8 > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Update variable names Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26954#pullrequestreview-3164948941 From duke at openjdk.org Thu Aug 28 13:56:55 2025 From: duke at openjdk.org (Rui Li) Date: Thu, 28 Aug 2025 13:56:55 GMT Subject: Integrated: 8342640: GenShen: Silently ignoring ShenandoahGCHeuristics considered poor user-experience In-Reply-To: References: Message-ID: <5GH1rWiImDIKhQZs_X6KFcWTfkfDDcq6MGyhuJ5XIdk=.77f33adc-910f-4984-95c6-50c26b604b13@github.com> On Wed, 27 Aug 2025 18:26:22 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) This pull request has now been integrated. Changeset: 8051aaf0 Author: Rui Li Committer: SendaoYan URL: https://git.openjdk.org/jdk/commit/8051aaf0685f7bb23bf3e23d32ad45b0bffbce7b Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod 8342640: GenShen: Silently ignoring ShenandoahGCHeuristics considered poor user-experience Reviewed-by: ysr, wkemper ------------- PR: https://git.openjdk.org/jdk/pull/26968 From sjohanss at openjdk.org Thu Aug 28 14:08:43 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Thu, 28 Aug 2025 14:08:43 GMT Subject: RFR: 8366147: ZGC: ZPageAllocator::cleanup_failed_commit_single_partition may leak memory [v6] In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 13:14:18 GMT, Axel Boldt-Christmas wrote: >> ZPageAllocator::cleanup_failed_commit_single_partition is responsible for cleaning up the successful part of a failed allocation by returning it to the cache so it can be reused. >> >> When a commit fails the the parts that should be returned is any "harvested" memory (memory it took from the cache) and any partially freshly committed memory. >> >> In a late revision of [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) we rewrote part of the allocation logic such that the "harvested" part was no longer part of the partial vmems after successfully harvesting. However the cleanup code was not adapted to this change. >> >> The solution is to add back both the harvested and newly committed memory, not just the newly committed part. >> >> * Testing (In progress) >> * Oracle supported platforms tier1 + ZGC tier1-8 > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Update variable names Looks good. ------------- Marked as reviewed by sjohanss (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26954#pullrequestreview-3165021752 From bronee at gmail.com Thu Aug 28 14:42:14 2025 From: bronee at gmail.com (Brian S O'Neill) Date: Thu, 28 Aug 2025 07:42:14 -0700 Subject: JEP 522 performance regression with large pages Message-ID: <841c7254-6b39-476d-8fa0-22fe7506d80a@gmail.com> I'm experimenting with the changes in PR 23739 (8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization) and I'm seeing a small performance regression when large pages are configured. The test is fairly complicated, and most of the memory it uses is off heap. The GC heap size is set to 3GB (min and max), which is much larger than is actually required. A bunch of objects are allocated up front and remain in the old gen for the duration of the test run. Between each GC cycle, almost all the old gen objects will have been updated to reference a young object. The young gen objects live for about 2 microseconds, and the references from the old gen objects are cleared. Here's the baseline results when running with "normal" pages: ParallelGC: 235.6 seconds G1GC JEP 522: 238.7 seconds G1GC: 241.5 seconds ZGC: 246.2 seconds With JEP 522, there's a small performance improvement, about 1%, which is nice to see. Here's the results when running with large pages (-XX:+UseLargePages -XX:+UseTransparentHugePages shmem_enabled is advise): ParallelGC: 228.9 seconds G1GC: 235.1 seconds ZGC: 239.3 seconds G1GC JEP 522: 239.7 seconds All of the GCs show a performance improvement when using large pages, but with JEP 522, G1 is slower than the current version (JDK 24). I don't know why there's a performance regression. Is this to be expected with large pages, or is there a missing configuration somewhere? I'm not configuring anything other than -Xms, -Xmx, and the large page settings. Also note that the test is run ten times (without restarting the JVM) and the average time is reported. From jsikstro at openjdk.org Thu Aug 28 15:06:42 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Thu, 28 Aug 2025 15:06:42 GMT Subject: RFR: 8366147: ZGC: ZPageAllocator::cleanup_failed_commit_single_partition may leak memory [v6] In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 13:14:18 GMT, Axel Boldt-Christmas wrote: >> ZPageAllocator::cleanup_failed_commit_single_partition is responsible for cleaning up the successful part of a failed allocation by returning it to the cache so it can be reused. >> >> When a commit fails the the parts that should be returned is any "harvested" memory (memory it took from the cache) and any partially freshly committed memory. >> >> In a late revision of [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) we rewrote part of the allocation logic such that the "harvested" part was no longer part of the partial vmems after successfully harvesting. However the cleanup code was not adapted to this change. >> >> The solution is to add back both the harvested and newly committed memory, not just the newly committed part. >> >> * Testing (In progress) >> * Oracle supported platforms tier1 + ZGC tier1-8 > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Update variable names Looks good, nice that you found this! ------------- Marked as reviewed by jsikstro (Committer). PR Review: https://git.openjdk.org/jdk/pull/26954#pullrequestreview-3165298010 From thomas.stuefe at gmail.com Thu Aug 28 15:20:03 2025 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 28 Aug 2025 17:20:03 +0200 Subject: JEP 522 performance regression with large pages In-Reply-To: <841c7254-6b39-476d-8fa0-22fe7506d80a@gmail.com> References: <841c7254-6b39-476d-8fa0-22fe7506d80a@gmail.com> Message-ID: Disclaimer: I am not a G1 expert, just a curious bystander. Just some questions: - what is the standard deviation on those tests; meaning, how reliable are the results? - you are sure that THP is set to madvise mode on the OS side, right? Not always? - can you exclude the (as you say, large) off-heap memory as a cause for the delta? So the only THP memory in use is the Java heap? Is anyone madvising those offheap memory regions, third-party native code maybe? Note, you can use jcmd System.map to get a look at the THP state of all memory regions of the process. It shows you which areas are eliglbe for THP coalescation, and which are already coalesced. That includes heap and your offheap memory (if you happen to know its address). Other than that, my first guess would be that any performance regression with THP stems from THP repeatedly forming and shattering. E.g. the OS coalesces large pages concurrently to the JVM uncommitting small-page-sized-portions of just coalesced large THP pages. On Thu, Aug 28, 2025 at 4:42?PM Brian S O'Neill wrote: > I'm experimenting with the changes in PR 23739 (8342382: Implement JEP > 522: G1 GC: Improve Throughput by Reducing Synchronization) and I'm > seeing a small performance regression when large pages are configured. > > The test is fairly complicated, and most of the memory it uses is off > heap. The GC heap size is set to 3GB (min and max), which is much larger > than is actually required. A bunch of objects are allocated up front and > remain in the old gen for the duration of the test run. Between each GC > cycle, almost all the old gen objects will have been updated to > reference a young object. The young gen objects live for about 2 > microseconds, and the references from the old gen objects are cleared. > > Here's the baseline results when running with "normal" pages: > > ParallelGC: 235.6 seconds > G1GC JEP 522: 238.7 seconds > G1GC: 241.5 seconds > ZGC: 246.2 seconds > > With JEP 522, there's a small performance improvement, about 1%, which > is nice to see. Here's the results when running with large pages > (-XX:+UseLargePages -XX:+UseTransparentHugePages shmem_enabled is advise): > > ParallelGC: 228.9 seconds > G1GC: 235.1 seconds > ZGC: 239.3 seconds > G1GC JEP 522: 239.7 seconds > > All of the GCs show a performance improvement when using large pages, > but with JEP 522, G1 is slower than the current version (JDK 24). > > I don't know why there's a performance regression. Is this to be > expected with large pages, or is there a missing configuration > somewhere? I'm not configuring anything other than -Xms, -Xmx, and the > large page settings. Also note that the test is run ten times (without > restarting the JVM) and the average time is reported. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bronee at gmail.com Thu Aug 28 15:48:38 2025 From: bronee at gmail.com (Brian S O'Neill) Date: Thu, 28 Aug 2025 08:48:38 -0700 Subject: JEP 522 performance regression with large pages In-Reply-To: References: <841c7254-6b39-476d-8fa0-22fe7506d80a@gmail.com> Message-ID: <2fd31c44-4374-486b-ad68-ec196f1eea8a@gmail.com> On 2025-08-28 08:20 AM, Thomas St?fe wrote: > Disclaimer: I am not a G1 expert, just a curious bystander. > > Just some questions: > - what is the standard deviation on those tests; meaning, how reliable > are the results? Other than the first one, the timing differed by 1 second between each test run. > - you are sure that THP is set to madvise mode on the OS side, right? > Not always? Yes. > - can you exclude the (as you say, large) off-heap memory as a cause for > the delta? So the only THP memory in use is the Java heap? Is anyone > madvising?those offheap memory regions, third-party native code maybe? > The off-heap memory is allocated using THP, 16GB, fully allocated and touched at the start of each test run. There's no third-party code running. The machine has 48GB in total, and nothing else is running. This leaves about 28GB of free memory. > Note, you can use jcmd System.map to get a look at the THP state of all > memory regions of the process. It shows you which areas are eliglbe?for > THP coalescation, and which are already coalesced. That includes heap > and your offheap memory (if you happen to know its address). > > Other than that, my first guess would be that any performance regression > with THP stems from THP repeatedly forming and shattering. E.g. the OS > coalesces large pages concurrently to the JVM uncommitting small-page- > sized-portions of just coalesced large THP pages. > I've not looked, but considering that there's a ton of free memory, the performance is consistent, and nothing else is running, leads me think that the regression is due to some change in the PR. From wkemper at openjdk.org Thu Aug 28 17:26:43 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 28 Aug 2025 17:26:43 GMT Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may raise threshold prematurely [v3] In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 00:59:08 GMT, Y. Srinivas Ramakrishna wrote: >> src/hotspot/share/gc/shenandoah/shenandoahAgeCensus.hpp line 181: >> >>> 179: // Return true if this age is above the tenuring threshold. >>> 180: bool is_tenurable(uint age) const { >>> 181: return age > tenuring_threshold(); >> >> Another key change. This prevents the algorithm from seeing higher mortality rates caused by promotions in the cohort at tenuring age. > > The strict ">" says objects of age strictly greater than the computed tenuring threshold are tenurable, not those of that age. This might make sense if it were used at all the places where tenuring decisions were being made during evacuation. Was that the intention? > > That doesn't seem to be the case -- there are pre-existing places in the code where a raw comparison with the tenuring threshold are made that don't do the strict check. Might be a good idea to go over all such spots and use this method (and inline it for performance?). It would then make `tenuring_threshold()` a private accessor, so the official API would be `is_tenurable(age)`, and no raw comparisons w/`tenuring_threshold()` that might become mutually inconsistent. > > See raw comparisons in: > 1. `ShenandoahYoungHeuristics::choose_young_collection_set` > 2. `ShenandoahGenerationalEvacuationTask::maybe_promote_region` > 3. `ShenandoahGenerationalHeuristics::choose_collection_set` > 4. `ShenandoahGenerationalHeuristics::add_preselected_regions_to_collection_set` > 5. `ShenandoahGlobalHeuristics::choose_global_collection_set` > 6. `ShenandoahCollectionSet::add_region` > 7. etc... there are several more. Yes, that the intention was to make the comparison strictly greater than (to prevent the adaptive tenuring algorithm from looking at cohorts that may have been promoted). I'll make the changes you suggested. Methods defined in headers are implicitly inline. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26906#discussion_r2308056678 From wkemper at openjdk.org Thu Aug 28 19:12:43 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 28 Aug 2025 19:12:43 GMT Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may raise threshold prematurely [v4] In-Reply-To: References: Message-ID: > The adaptive tenuring algorithm has been modified to begin its evaluation of mortality rates from the current tenuring threshold. To compliment this change, objects must also now be strictly above the tenuring threshold to be promoted (instead of greater-than-or-equal). William Kemper has updated the pull request incrementally with one additional commit since the last revision: Be consistent when comparing tenuring threshold with ages ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26906/files - new: https://git.openjdk.org/jdk/pull/26906/files/b9e16d26..658f76f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26906&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26906&range=02-03 Stats: 84 lines in 12 files changed: 42 ins; 20 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/26906.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26906/head:pull/26906 PR: https://git.openjdk.org/jdk/pull/26906 From dlong at openjdk.org Thu Aug 28 20:21:59 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 28 Aug 2025 20:21:59 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v5] In-Reply-To: <-MqvO74Up2R0qmEDtgyGY-yScxZ-v6ZQWxDtSxpKO_g=.56d4eeca-670d-41e4-9e96-ba20b1b44100@github.com> References: <-MqvO74Up2R0qmEDtgyGY-yScxZ-v6ZQWxDtSxpKO_g=.56d4eeca-670d-41e4-9e96-ba20b1b44100@github.com> Message-ID: On Wed, 27 Aug 2025 20:17:07 GMT, Erik ?sterlund wrote: >> @fisk , can I get you to review this? > >> @fisk , can I get you to review this? > > Sure! Based on the symptoms you described, my main comment is that we might be looking at the wrong places. I don't know if this is really about lock contention. Perhaps it is indirectly. But you mention there is still so e regression with ZGC. > > My hypothesis would be that it is the unnecessary incrementing of the global patching epoch that causes the regression when using ZGC. It is only really needed when disarming the nmethod - in orher words when the guard value is set to the good value. > > The point of incrementing the patching epoch is to protect other threads from entering the nmethod without executing an instruction cross modication fence. And all other threads will have to do that. > > Only ZGC uses the mode of nmethod entry barriers that does this due to being the only GC that updates instructions in a concurrent phase on AArch64. We are conservative on AArch64 and ensure the use of appropriate synchronous cross modifying code. But that's not needed when arming, which is what we do when making the bmethod not entrant. Thanks @fisk, that's a good theory, but it is not what I am seeing. For G1, lock contention does seem to explain the issue, and this PR fixes the regression. (Also the lock overhead I measured seemed to agree with the regression in GC phase time and benchmark scores.) For ZGC, I am not seeing an increase in calls to BarrierSetAssembler::increment_patching_epoch(). And increment_patching_epoch() is only called when disarming -- that part hasn't changed. I think the suspected ZGC regression is just noise in the benchmark, as the benchmark can show a regression across multiple runs even with the same build, flags, and host. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26399#issuecomment-3234822398 From thomas.schatzl at oracle.com Thu Aug 28 20:59:51 2025 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 28 Aug 2025 22:59:51 +0200 Subject: JEP 522 performance regression with large pages In-Reply-To: <841c7254-6b39-476d-8fa0-22fe7506d80a@gmail.com> References: <841c7254-6b39-476d-8fa0-22fe7506d80a@gmail.com> Message-ID: Hi Brian, On 28.08.25 16:42, Brian S O'Neill wrote: > I'm experimenting with the changes in PR 23739 (8342382: Implement JEP > 522: G1 GC: Improve Throughput by Reducing Synchronization) and I'm > seeing a small performance regression when large pages are configured. > thanks for giving the change a spin. > The test is fairly complicated, and most of the memory it uses is off > heap. The GC heap size is set to 3GB (min and max), which is much > larger than is actually required. A bunch of objects are allocated up > front and remain in the old gen for the duration of the test run. > Between each GC cycle, almost all the old gen objects will have been > updated to reference a young object. The young gen objects live for > about 2 microseconds, and the references from the old gen objects are > cleared. > > Here's the baseline results when running with "normal" pages: > > ParallelGC: 235.6 seconds > G1GC JEP 522: 238.7 seconds > G1GC: 241.5 seconds > ZGC: 246.2 seconds > > With JEP 522, there's a small performance improvement, about 1%, which > is nice to see. Here's the results when running with large pages (-XX: > +UseLargePages -XX:+UseTransparentHugePages shmem_enabled is advise): Just to make sure it's not THP: can you also try with pre-allocated large pages? E.g. via sysctl -w vm.nr_hugepages= and -XX:-UseTransparentHugePages? > > ParallelGC: 228.9 seconds > G1GC: 235.1 seconds > ZGC: 239.3 seconds > G1GC JEP 522: 239.7 seconds > > All of the GCs show a performance improvement when using large pages, > but with JEP 522, G1 is slower than the current version (JDK 24). > > I don't know why there's a performance regression. Is this to be > expected with large pages, or is there a missing configuration > somewhere? I'm not configuring anything other than -Xms, -Xmx, and the > large page settings. Also note that the test is run ten times (without Can you give the full command line? > restarting the JVM) and the average time is reported. > No, we are not aware of such a regression. We do run benchmarks with large pages regularly, although not so often with THP but pre-allocated ones. Thanks, Thomas From bronee at gmail.com Thu Aug 28 21:49:54 2025 From: bronee at gmail.com (Brian S O'Neill) Date: Thu, 28 Aug 2025 14:49:54 -0700 Subject: JEP 522 performance regression with large pages In-Reply-To: References: <841c7254-6b39-476d-8fa0-22fe7506d80a@gmail.com> Message-ID: <1b4d1e9b-f87d-4ef4-8eb1-8ef1706adfe8@gmail.com> 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. On 2025-08-28 01:59 PM, Thomas Schatzl wrote: > Hi Brian, > > On 28.08.25 16:42, Brian S O'Neill wrote: > > I'm experimenting with the changes in PR 23739 (8342382: Implement JEP > > 522: G1 GC: Improve Throughput by Reducing Synchronization) and I'm > > seeing a small performance regression when large pages are configured. > > > > ? thanks for giving the change a spin. > > > The test is fairly complicated, and most of the memory it uses is off > > heap. The GC heap size is set to 3GB (min and max), which is much > > larger than is actually required. A bunch of objects are allocated up > > front and remain in the old gen for the duration of the test run. > > Between each GC cycle, almost all the old gen objects will have been > > updated to reference a young object. The young gen objects live for > > about 2 microseconds, and the references from the old gen objects are > > cleared. > > > > Here's the baseline results when running with "normal" pages: > > > > ParallelGC:?? 235.6 seconds > > G1GC JEP 522: 238.7 seconds > > G1GC:???????? 241.5 seconds > > ZGC:????????? 246.2 seconds > > > > With JEP 522, there's a small performance improvement, about 1%, which > > is nice to see. Here's the results when running with large pages (-XX: > > +UseLargePages -XX:+UseTransparentHugePages shmem_enabled is advise): > > Just to make sure it's not THP: can you also try with pre-allocated > large pages? > > E.g. via > sysctl -w vm.nr_hugepages= > > and > > -XX:-UseTransparentHugePages? > > > > > ParallelGC:?? 228.9 seconds > > G1GC:???????? 235.1 seconds > > ZGC:????????? 239.3 seconds > > G1GC JEP 522: 239.7 seconds > > > > All of the GCs show a performance improvement when using large pages, > > but with JEP 522, G1 is slower than the current version (JDK 24). > > > > I don't know why there's a performance regression. Is this to be > > expected with large pages, or is there a missing configuration > > somewhere? I'm not configuring anything other than -Xms, -Xmx, and the > > large page settings. Also note that the test is run ten times (without > > Can you give the full command line? > > > restarting the JVM) and the average time is reported. > > > > No, we are not aware of such a regression. We do run benchmarks with > large pages regularly, although not so often with THP but pre-allocated > ones. > > Thanks, > ? Thomas From aboldtch at openjdk.org Fri Aug 29 07:33:47 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 29 Aug 2025 07:33:47 GMT Subject: RFR: 8366147: ZGC: ZPageAllocator::cleanup_failed_commit_single_partition may leak memory [v6] In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 13:14:18 GMT, Axel Boldt-Christmas wrote: >> ZPageAllocator::cleanup_failed_commit_single_partition is responsible for cleaning up the successful part of a failed allocation by returning it to the cache so it can be reused. >> >> When a commit fails the the parts that should be returned is any "harvested" memory (memory it took from the cache) and any partially freshly committed memory. >> >> In a late revision of [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) we rewrote part of the allocation logic such that the "harvested" part was no longer part of the partial vmems after successfully harvesting. However the cleanup code was not adapted to this change. >> >> The solution is to add back both the harvested and newly committed memory, not just the newly committed part. >> >> * Testing (In progress) >> * Oracle supported platforms tier1 + ZGC tier1-8 > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Update variable names Thanks for the reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/26954#issuecomment-3235850738 From aboldtch at openjdk.org Fri Aug 29 07:37:47 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 29 Aug 2025 07:37:47 GMT Subject: Integrated: 8366147: ZGC: ZPageAllocator::cleanup_failed_commit_single_partition may leak memory In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 09:56:33 GMT, Axel Boldt-Christmas wrote: > ZPageAllocator::cleanup_failed_commit_single_partition is responsible for cleaning up the successful part of a failed allocation by returning it to the cache so it can be reused. > > When a commit fails the the parts that should be returned is any "harvested" memory (memory it took from the cache) and any partially freshly committed memory. > > In a late revision of [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) we rewrote part of the allocation logic such that the "harvested" part was no longer part of the partial vmems after successfully harvesting. However the cleanup code was not adapted to this change. > > The solution is to add back both the harvested and newly committed memory, not just the newly committed part. > > * Testing (In progress) > * Oracle supported platforms tier1 + ZGC tier1-8 This pull request has now been integrated. Changeset: 86d6a2e0 Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/86d6a2e05eb52ea2c603a06bce838a56d5ae507b Stats: 22 lines in 2 files changed: 13 ins; 0 del; 9 mod 8366147: ZGC: ZPageAllocator::cleanup_failed_commit_single_partition may leak memory Reviewed-by: stefank, sjohanss, jsikstro ------------- PR: https://git.openjdk.org/jdk/pull/26954 From sjohanss at openjdk.org Fri Aug 29 09:14:43 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Fri, 29 Aug 2025 09:14:43 GMT Subject: RFR: 8366157: Clarify in man pages that only G1 supports MaxGCPauseMillis [v2] In-Reply-To: References: Message-ID: <1YA9bx-VCGaoO7KKv83ECAZh4o6zT3wSvcrMz8dMQ0g=.7bd28e88-4a03-4f6a-992c-24136aa54f41@github.com> On Thu, 28 Aug 2025 09:30:02 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This patch clarifies the description of `MaxGCPauseMillis`. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Improve description after review discussion Marked as reviewed by sjohanss (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26940#pullrequestreview-3167990908 From duke at openjdk.org Fri Aug 29 09:29:10 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Fri, 29 Aug 2025 09:29:10 GMT Subject: RFR: 8366157: Clarify in man pages that only G1 and Parallel supports MaxGCPauseMillis [v3] In-Reply-To: References: Message-ID: > Hi all, > > This patch clarifies the description of `MaxGCPauseMillis`. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Parallel do support a pause time target but does not use it by default ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26940/files - new: https://git.openjdk.org/jdk/pull/26940/files/868d446f..d70a6d7a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26940&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26940&range=01-02 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26940.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26940/head:pull/26940 PR: https://git.openjdk.org/jdk/pull/26940 From ayang at openjdk.org Fri Aug 29 09:34:44 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 29 Aug 2025 09:34:44 GMT Subject: RFR: 8366157: Clarify in man pages that only G1 and Parallel supports MaxGCPauseMillis [v3] In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 09:29:10 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This patch clarifies the description of `MaxGCPauseMillis`. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Parallel do support a pause time target but does not use it by default src/java.base/share/man/java.md line 2505: > 2503: : Sets a target for the maximum GC pause time (in milliseconds). This is a > 2504: soft goal, and the JVM will make its best effort to achieve it. Only G1 > 2505: and Parallel supports a maximum GC pause time target. For G1, the default I guess "Only G1 and Parallel support this flag." is enough to convey the meaning. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26940#discussion_r2309678849 From tschatzl at openjdk.org Fri Aug 29 09:39:45 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 29 Aug 2025 09:39:45 GMT Subject: RFR: 8366157: Clarify in man pages that only G1 and Parallel supports MaxGCPauseMillis [v3] In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 09:29:10 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This patch clarifies the description of `MaxGCPauseMillis`. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Parallel do support a pause time target but does not use it by default Changes requested by tschatzl (Reviewer). src/java.base/share/man/java.md line 2507: > 2505: and Parallel supports a maximum GC pause time target. For G1, the default > 2506: maximum pause time target is 200 milliseconds. Parallel do not use a > 2507: pause time goal by default. Suggestion: soft goal, and the JVM will make a best effort to achieve it. The default maximum pause time target is 200 milliseconds. Only G1 and Parallel GC support a maximum pause time target. * grammar error: `supports`->`support` * I do not think it is useful to tell that Parallel GC does not adhere to this target by default and needs another setting. First, this begs the question what option this is, and second, this information should be part of the tuning guide as otherwise the manpage will get too lengthy (if we explained all interactions with all flags for every option here). I am aware that most likely this is not currently in the documentation. I mean, similarly to Parallel, one would, to be somewhat complete also detail that there is an important interaction with another flag (-XX:GCPauseIntervalMillis). (This is explained in the guide) Leaving out this sentence is not a strong opinion, but just imho. ------------- PR Review: https://git.openjdk.org/jdk/pull/26940#pullrequestreview-3168073800 PR Review Comment: https://git.openjdk.org/jdk/pull/26940#discussion_r2309688836 From duke at openjdk.org Fri Aug 29 09:44:45 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Fri, 29 Aug 2025 09:44:45 GMT Subject: RFR: 8366157: Clarify in man pages that only G1 and Parallel supports MaxGCPauseMillis [v3] In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 09:36:00 GMT, Thomas Schatzl wrote: >> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: >> >> Parallel do support a pause time target but does not use it by default > > src/java.base/share/man/java.md line 2507: > >> 2505: and Parallel supports a maximum GC pause time target. For G1, the default >> 2506: maximum pause time target is 200 milliseconds. Parallel do not use a >> 2507: pause time goal by default. > > Suggestion: > > soft goal, and the JVM will make a best effort to achieve it. The default > maximum pause time target is 200 milliseconds. > Only G1 and Parallel GC support a maximum pause time target. > > > * grammar error: `supports`->`support` > * I do not think it is useful to tell that Parallel GC does not adhere to this target by default and needs another setting. First, this begs the question what option this is, and second, this information should be part of the tuning guide as otherwise the manpage will get too lengthy (if we explained all interactions with all flags for every option here). I am aware that most likely this is not currently in the documentation. > I mean, similarly to Parallel, one would, to be somewhat complete also detail that there is an important interaction with another flag (-XX:GCPauseIntervalMillis). (This is explained in the guide) > Leaving out this sentence is not a strong opinion, but just imho. Thanks guys for your input. Only kept it since it was part of the original statement, but I would agree that it is not super useful to point out here and will remove it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26940#discussion_r2309702216 From azafari at openjdk.org Fri Aug 29 10:16:45 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 29 Aug 2025 10:16:45 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer In-Reply-To: <-Ct2yCIbRn7bSazmFKxlMPMeP85zAZk3kUfP9ele4so=.78e5ec0f-2d17-45e6-a68d-9fff149577c1@github.com> References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> <-Ct2yCIbRn7bSazmFKxlMPMeP85zAZk3kUfP9ele4so=.78e5ec0f-2d17-45e6-a68d-9fff149577c1@github.com> Message-ID: On Wed, 27 Aug 2025 14:19:23 GMT, Johan Sj?len wrote: >> The minimum acceptable value was 0 where using it as address was problematic according to UBSAN. >> The acceptable value is changed to 64K. >> >> Tests: >> linux-x64 tier1 > > It seems to me like we can fix the ubsan issue by avoiding the cast into pointers and computing through `size_t` as far as possible, and converting into pointer when necessary. > > For example > > ```c++ > size_t aligned_heap_base_min_address = align_up(HeapBaseMinAddress, alignment); > size_t noaccess_prefix = ((aligned_heap_base_min_address + size) > OopEncodingHeapMax) ? noaccess_prefix_size : 0; > > if (!FLAG_IS_DEFAULT(HeapBaseMinAddress)) { > reserved = try_reserve_memory(size + noaccess_prefix, alignment, page_size, static_cast(aligned_heap_base_min_address)); > if (reserved.base() != static_cast(aligned_heap_base_min_address)) { // Enforce this exact address. > release(reserved); > reserved = {}; > } > } > > > The semantics of reserving a `null` base address is still preserved as meaning "don't care where you put it" then. Someone from GC needs to look at this and see whether or not an undefined (implicitly 0?) HeapBaseMinAddress is meant to have that type of meaning. Thanks for your comments @jdksjolen and @xmas92. The discussion here is exactly what I meant by running UBSAN checks. It seems that more bugs get discovered. 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`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3236511021 From duke at openjdk.org Fri Aug 29 10:25:04 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Fri, 29 Aug 2025 10:25:04 GMT Subject: RFR: 8366157: Clarify in man pages that only G1 and Parallel supports MaxGCPauseMillis [v4] In-Reply-To: References: Message-ID: > Hi all, > > This patch clarifies the description of `MaxGCPauseMillis`. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Remove statement about Parallel's default value ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26940/files - new: https://git.openjdk.org/jdk/pull/26940/files/d70a6d7a..62a22af5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26940&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26940&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26940.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26940/head:pull/26940 PR: https://git.openjdk.org/jdk/pull/26940 From tschatzl at openjdk.org Fri Aug 29 11:14:43 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 29 Aug 2025 11:14:43 GMT Subject: RFR: 8366157: Clarify in man pages that only G1 and Parallel supports MaxGCPauseMillis [v4] In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 10:25:04 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This patch clarifies the description of `MaxGCPauseMillis`. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Remove statement about Parallel's default value Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26940#pullrequestreview-3168359158 From sjohanss at openjdk.org Fri Aug 29 15:25:43 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Fri, 29 Aug 2025 15:25:43 GMT Subject: RFR: 8366157: Clarify in man pages that only G1 and Parallel supports MaxGCPauseMillis [v4] In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 10:25:04 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This patch clarifies the description of `MaxGCPauseMillis`. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Remove statement about Parallel's default value Marked as reviewed by sjohanss (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26940#pullrequestreview-3169155999 From duke at openjdk.org Fri Aug 29 15:29:46 2025 From: duke at openjdk.org (duke) Date: Fri, 29 Aug 2025 15:29:46 GMT Subject: RFR: 8366157: Clarify in man pages that only G1 and Parallel supports MaxGCPauseMillis [v4] In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 10:25:04 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This patch clarifies the description of `MaxGCPauseMillis`. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Remove statement about Parallel's default value @JonasNorlinder Your change (at version 62a22af591a7ec54df72a0e2b7941ee5535d39ef) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26940#issuecomment-3237433570 From syan at openjdk.org Sat Aug 30 05:04:52 2025 From: syan at openjdk.org (SendaoYan) Date: Sat, 30 Aug 2025 05:04:52 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 Wed, 27 Aug 2025 08:41:20 GMT, Joel Sikstr?m wrote: >> Hello, >> >> With [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441), ZGC got infrastructure to prefer allocations to end up on a specific NUMA node. When a new object is allocated, it is preferably placed on the NUMA node that is local to the allocating thread. This strategy improves access speeds for mutators working on that object, if it continues to be used by threads on the same NUMA node. However, when relocating objects, ZGC will potentially move (migrate) objects away from the NUMA node they were originally allocated on. This means that if a page is selected as part of the Relocation Set, the objects on that page could potentially be moved to another NUMA node, breaking the NUMA locality we strived for when allocating. >> >> We should consider adding NUMA-awareness to ZGC's relocation phase to keep NUMA-locality benefits for mutators. >> >>
>> >> Proposal (expandable section) >> >> NUMA-Awareness consists of two main features: >> >> **First**: GC threads should strive toward keeping the NUMA locality of objects to their original node, meaning that objects should ideally be relocated to a page that is on the same NUMA node. >> >> Mutator threads should have a different approach, as we know that the mutator that's (helping out with) relocating an object is also going to access it, so we migrate the object to the NUMA node associated with the relocating thread. This strategy is already in effect and does not require any changes to the code (specifically, ZObjectAllocator already track per-CPU specific Small pages). However, Medium pages are shared between CPUs and thus does not hold any guarantees on which NUMA node it is on. Combined, both mutator and Medium page relocation are not common, and thus there is little gain from introducing NUMA-awareness to that specific scenario. Instead, this can be addressed in a follow-up if we feel that's necessary. >> >> **Second**: When the GC chooses a page from the Relocation Set to relocate objects from, it should choose page(s) that are local to the same NUMA node, to speed up performance by working on NUMA-local memory. There are multiple ways to achieve this, but the main goal should be to (1) start working on pages that are local to the GC thread's NUMA node, and (2) when finished with pages on its own NUMA node, start working (help out) with pages associated with other NUMA nodes. >> >> Some key observations to consider with the above approach: >> >> * The NUMA node asso... > > 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) ------------- PR Comment: https://git.openjdk.org/jdk/pull/26898#issuecomment-3238952365 From lgxbslgx at gmail.com Sat Aug 30 10:40:39 2025 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Sat, 30 Aug 2025 18:40:39 +0800 Subject: [Question] The property `vm.gc` in jtreg test Message-ID: Hi all, I notice the meaning of the test property `vm.gc` is not clear. The method `VMProps::vmGCforCDS` (shown below, in directory: test/jtreg-ext/requires/VMProps.java) extracts the property `vm.gc` from the option `test.cds.runtime.options`. So the current `vm.gc` is about both CDS and GC, not only the GC. I propose changing the current test property name `vm.gc` to `vm.gc.cds` or `vm.cds.gc`. Waiting for your opinion. Any ideas will be appreciated. ```java /** * "jtreg -vmoptions:-Dtest.cds.runtime.options=..." can be used to specify * the GC type to be used when running with a CDS archive. Set "vm.gc" accordingly, * so that tests that need to explicitly choose the GC type can be excluded * with "@requires vm.gc == null". * * @param map - property-value pairs */ protected void vmGCforCDS(SafeMap map) { if (!GC.isSelectedErgonomically()) { // The GC has been explicitly specified on the command line, so // jtreg will set the "vm.gc" property. Let's not interfere with it. return; } String jtropts = System.getProperty("test.cds.runtime.options"); if (jtropts != null) { for (String opt : jtropts.split(",")) { if (opt.startsWith(GC_PREFIX) && opt.endsWith(GC_SUFFIX)) { String gc = opt.substring(GC_PREFIX.length(), opt.length() - GC_SUFFIX.length()); map.put("vm.gc", () -> gc); } } } } ``` Best Regards, -- Guoxiong -------------- next part -------------- An HTML attachment was scrubbed... URL: From gli at openjdk.org Sat Aug 30 10:54:51 2025 From: gli at openjdk.org (Guoxiong Li) Date: Sat, 30 Aug 2025 10:54:51 GMT Subject: RFR: 8357188: Remove the field MemAllocator::Allocation::_overhead_limit_exceeded and the related code Message-ID: <0qHdlghXGyq966nZz5mrxkDrTLtN-FNb7zqRSewz92o=.84d3673c-7526-4ad7-a37d-17c3637ce918@github.com> 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 ------------- Commit messages: - JDK-8357188 Changes: https://git.openjdk.org/jdk/pull/27020/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27020&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357188 Stats: 38 lines in 14 files changed: 0 ins; 18 del; 20 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 ayang at openjdk.org Sat Aug 30 11:42:41 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Sat, 30 Aug 2025 11:42:41 GMT Subject: RFR: 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 src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp line 197: > 195: // an excessive amount of time is being spent doing collections > 196: // and caused a null to be returned. If a null is not returned, > 197: // "gc_time_limit_was_exceeded" has an undefined meaning. Outdated comments about "gc_time_limit_was_exceeded". Looks good otherwise. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27020#discussion_r2311911209 From aboldtch at openjdk.org Sun Aug 31 10:31:40 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Sun, 31 Aug 2025 10:31:40 GMT Subject: RFR: 8366462: Test gc/z/TestCommitFailure.java#Normal failed: expected output missing Message-ID: 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. ------------- Commit messages: - 8366462: Test gc/z/TestCommitFailure.java#Normal failed: expected output missing Changes: https://git.openjdk.org/jdk/pull/27023/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27023&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366462 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27023.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27023/head:pull/27023 PR: https://git.openjdk.org/jdk/pull/27023 From gli at openjdk.org Sun Aug 31 11:31:32 2025 From: gli at openjdk.org (Guoxiong Li) Date: Sun, 31 Aug 2025 11:31:32 GMT Subject: RFR: 8357188: Remove the field MemAllocator::Allocation::_overhead_limit_exceeded and the related code [v2] In-Reply-To: <0qHdlghXGyq966nZz5mrxkDrTLtN-FNb7zqRSewz92o=.84d3673c-7526-4ad7-a37d-17c3637ce918@github.com> References: <0qHdlghXGyq966nZz5mrxkDrTLtN-FNb7zqRSewz92o=.84d3673c-7526-4ad7-a37d-17c3637ce918@github.com> Message-ID: <4suEaL8ElbI5gbPNk1Sq0hO4j5v3SvHUemCfLDbERiY=.1d0d93ff-15f7-4f04-8cb5-a705fc2ddfce@github.com> > 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. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27020/files - new: https://git.openjdk.org/jdk/pull/27020/files/d617cbd5..949e1620 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27020&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27020&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 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 gli at openjdk.org Sun Aug 31 11:31:32 2025 From: gli at openjdk.org (Guoxiong Li) Date: Sun, 31 Aug 2025 11:31:32 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> Message-ID: On Sat, 30 Aug 2025 11:40:27 GMT, Albert Mingkun Yang wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove outdated comments. > > src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp line 197: > >> 195: // an excessive amount of time is being spent doing collections >> 196: // and caused a null to be returned. If a null is not returned, >> 197: // "gc_time_limit_was_exceeded" has an undefined meaning. > > Outdated comments about "gc_time_limit_was_exceeded". > > Looks good otherwise. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27020#discussion_r2312417378 From ayang at openjdk.org Sun Aug 31 13:09:41 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Sun, 31 Aug 2025 13:09:41 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. Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27020#pullrequestreview-3171619294 From dholmes at openjdk.org Sun Aug 31 23:49:45 2025 From: dholmes at openjdk.org (David Holmes) Date: Sun, 31 Aug 2025 23:49:45 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. As at least a short term remedy this seems fine - thanks. GC team can figure out a longer term strategy for this aspect of testing. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27023#pullrequestreview-3171842649