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