From aph at openjdk.org Thu Jan 1 13:15:59 2026 From: aph at openjdk.org (Andrew Haley) Date: Thu, 1 Jan 2026 13:15:59 GMT Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact on GCs and JIT performance [v21] In-Reply-To: References: <15wAKoik-66gfbUzGQEROBTv_cTV_I_6jq96S2ErOyA=.22e19b52-220c-4c35-9aaa-9f08719e16fa@github.com> Message-ID: On Wed, 31 Dec 2025 16:06:53 GMT, Evgeny Astigeevich wrote: > > Is there any reason not to do this by default on all AArch64? > > It will be turned on if AArch64 has `ctr_el0.IDC` and `ctr_el0.DIC` set. See https://github.com/openjdk/jdk/pull/28328/changes#diff-a87e260510f34ca7d9b0feb089ad982be8268c5c8aa5a71221f6738b051ea488R663 Sure, I can see that, but is there any reason not to do this by default on all AArch64? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28328#issuecomment-3703679652 From eastigeevich at openjdk.org Thu Jan 1 20:38:08 2026 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Thu, 1 Jan 2026 20:38:08 GMT Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact on GCs and JIT performance [v21] In-Reply-To: References: <15wAKoik-66gfbUzGQEROBTv_cTV_I_6jq96S2ErOyA=.22e19b52-220c-4c35-9aaa-9f08719e16fa@github.com> Message-ID: On Thu, 1 Jan 2026 13:13:07 GMT, Andrew Haley wrote: > Sure, I can see that, but is there any reason not to do this by default on all AArch64? Do you mean to do this for all AArch64 OSes, not only for Linux AArch64? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28328#issuecomment-3704085326 From aboldtch at openjdk.org Fri Jan 2 04:29:55 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 2 Jan 2026 04:29:55 GMT Subject: RFR: 8351137: ZGC: Improve ZValueStorage alignment support [v8] In-Reply-To: References: Message-ID: > ZValueStorage only align the allocations to the alignment defined by the storage but ignores the alignment of the types. Right now all usages of our different storages all have types which have an alignment less than or equal to the alignment set by its storage. > > I wish to improve this so that types with greater alignment than the storage alignment can be used. > > The UB caused by using a type larger than the storage alignment is something I have seen materialise as returning bad address (and crashing) on Windows. > > As we use `utilities/align.hpp` for our alignment utilities we only support power of two alignment, I added extra asserts here because we use the fact that `lcm(x, y) = max(x, y)` if both are powers of two. > > Testing: > * tier 1 through tier 5 Oracle supported platforms > * GHA Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Merge tag 'jdk-27+3' into JDK-8351137 Added tag jdk-27+3 for changeset 4f283f18 - Merge tag 'jdk-26+26' into JDK-8351137 Added tag jdk-26+26 for changeset 847fbab7 - Merge tag 'jdk-26+21' into JDK-8351137 Added tag jdk-26+21 for changeset 3e20a939 - Merge tag 'jdk-26+19' into JDK-8351137 Added tag jdk-26+19 for changeset b37a1a33 - Merge tag 'jdk-26+18' into JDK-8351137 Added tag jdk-26+18 for changeset 5251405c - Merge tag 'jdk-26+17' into JDK-8351137 Added tag jdk-26+17 for changeset 2aafda19 - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8351137 - 8351137: ZGC: Improve ZValueStorage alignment support ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23887/files - new: https://git.openjdk.org/jdk/pull/23887/files/fb298944..306d09b7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23887&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23887&range=06-07 Stats: 71581 lines in 1436 files changed: 45436 ins; 18779 del; 7366 mod Patch: https://git.openjdk.org/jdk/pull/23887.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23887/head:pull/23887 PR: https://git.openjdk.org/jdk/pull/23887 From kbarrett at openjdk.org Fri Jan 2 09:31:04 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 2 Jan 2026 09:31:04 GMT Subject: RFR: 8374371: Failed assertion in G1HeapRegion gtest In-Reply-To: References: Message-ID: On Mon, 29 Dec 2025 10:13:09 GMT, Thomas Schatzl wrote: >> Please review this simple change to the G1HeapRegion gtest to eliminate a >> failed assertion when run in some configurations. >> >> Testing: mach5 tier1. Locally (linux-aarch64) ran the test directly, in a >> configuration that was failing and no longer fails after the change. > > Marked as reviewed by tschatzl (Reviewer). Thanks for reviews @tschatzl and @walulyai ------------- PR Comment: https://git.openjdk.org/jdk/pull/29000#issuecomment-3704845914 From kbarrett at openjdk.org Fri Jan 2 09:31:06 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 2 Jan 2026 09:31:06 GMT Subject: Integrated: 8374371: Failed assertion in G1HeapRegion gtest In-Reply-To: References: Message-ID: On Sat, 27 Dec 2025 05:10:23 GMT, Kim Barrett wrote: > Please review this simple change to the G1HeapRegion gtest to eliminate a > failed assertion when run in some configurations. > > Testing: mach5 tier1. Locally (linux-aarch64) ran the test directly, in a > configuration that was failing and no longer fails after the change. This pull request has now been integrated. Changeset: 65af6bcb Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/65af6bcb8f74484436b0331032260f2a646f203f Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8374371: Failed assertion in G1HeapRegion gtest Reviewed-by: tschatzl, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/29000 From aph at openjdk.org Fri Jan 2 12:11:55 2026 From: aph at openjdk.org (Andrew Haley) Date: Fri, 2 Jan 2026 12:11:55 GMT Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact on GCs and JIT performance [v21] In-Reply-To: References: <15wAKoik-66gfbUzGQEROBTv_cTV_I_6jq96S2ErOyA=.22e19b52-220c-4c35-9aaa-9f08719e16fa@github.com> Message-ID: <2b8w_8NwTITCCqqyirLgPcfxyQd35yS-MmPlO8rEwS0=.74b73b12-1b0a-4d73-b18f-1f6ac0e5f18d@github.com> On Thu, 1 Jan 2026 20:35:25 GMT, Evgeny Astigeevich wrote: > > Sure, I can see that, but is there any reason not to do this by default on all AArch64? > > Do you mean to do this for all AArch64 OSes, not only for Linux AArch64? In a perfect world we'd do this for all AArch64. But Linux-only would be good too. But is there any reason not to do this on all Linux systems? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28328#issuecomment-3705195536 From kbarrett at openjdk.org Fri Jan 2 13:54:02 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 2 Jan 2026 13:54:02 GMT Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact on GCs and JIT performance [v21] In-Reply-To: References: Message-ID: <1HoFAoxwMTDW1GJteYe1Bl3X9erLJtcdjdY7kEqOMgE=.f34e8855-352e-4654-9297-6af29b5f17de@github.com> On Mon, 29 Dec 2025 21:51:20 GMT, Evgeny Astigeevich wrote: >> Arm Neoverse N1 erratum 1542419: "The core might fetch a stale instruction from memory which violates the ordering of instruction fetches". It is fixed in Neoverse N1 r4p1. >> >> Neoverse-N1 implementations mitigate erratum 1542419 with a workaround: >> - Disable coherent icache. >> - Trap IC IVAU instructions. >> - Execute: >> - `tlbi vae3is, xzr` >> - `dsb sy` >> >> `tlbi vae3is, xzr` invalidates translations for all address spaces (global for address). It waits for all memory accesses using in-scope old translation information to complete before it is considered complete. >> >> As this workaround has significant overhead, Arm Neoverse N1 (MP050) Software Developer Errata Notice version 29.0 suggests: >> >> "Since one TLB inner-shareable invalidation is enough to avoid this erratum, the number of injected TLB invalidations should be minimized in the trap handler to mitigate the performance impact due to this workaround." >> >> This PR introduces a mechanism to defer instruction cache (ICache) invalidation for AArch64 to address the Arm Neoverse N1 erratum 1542419, which causes significant performance overhead if ICache invalidation is performed too frequently. The implementation includes detection of affected Neoverse N1 CPUs and automatic enabling of the workaround for relevant Neoverse N1 revisions. >> >> Changes include: >> >> * Added a new diagnostic JVM flag `NeoverseN1Errata1542419` to enable or disable the workaround for the erratum. The flag is automatically enabled for Neoverse N1 CPUs prior to r4p1, as detected during VM initialization. >> * Introduced the `ICacheInvalidationContext` class to manage deferred ICache invalidation, with platform-specific logic for AArch64. This context is used to batch ICache invalidations, reducing performance impact. As the address for icache invalidation is not relevant, we use the nmethod's code start address. >> * Provided a default (no-op) implementation for `ICacheInvalidationContext` on platforms where the workaround is not needed, ensuring portability and minimal impact on other architectures. >> * Modified barrier patching and relocation logic (`ZBarrierSetAssembler`, `ZNMethod`, `RelocIterator`, and related code) to accept a `defer_icache_invalidation` parameter, allowing ICache invalidation to be deferred and later performed in bulk. >> >> Testing results: linux fastdebug build >> - Neoverse-N1 (Graviton 2) >> - [x] tier1: passed >> - [x] tier2: passed >> - [x] tier3: passed >> - [x] tier4: 3 failu... > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Fix linux-cross-compile riscv64 build src/hotspot/share/runtime/icache.hpp line 139: > 137: class DefaultICacheInvalidationContext : StackObj { > 138: private: > 139: NONCOPYABLE(DefaultICacheInvalidationContext); Not a review, just a drive-by comment. @xmas92 suggested moving the `NONCOPYABLE` to the private part of the class, as a style issue. It used to be that `NONCOPYABLE` was best used in the private part of a class, because of how it was implemented. But with the change to using deleted definitions, it's actually better to have it in the public part. That way you get an "attempt to use a deleted function" error rather than possibly getting an "attempt to use an inaccessible function" error. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28328#discussion_r2657751265 From eastigeevich at openjdk.org Fri Jan 2 15:43:15 2026 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Fri, 2 Jan 2026 15:43:15 GMT Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact on GCs and JIT performance [v21] In-Reply-To: <2b8w_8NwTITCCqqyirLgPcfxyQd35yS-MmPlO8rEwS0=.74b73b12-1b0a-4d73-b18f-1f6ac0e5f18d@github.com> References: <15wAKoik-66gfbUzGQEROBTv_cTV_I_6jq96S2ErOyA=.22e19b52-220c-4c35-9aaa-9f08719e16fa@github.com> <2b8w_8NwTITCCqqyirLgPcfxyQd35yS-MmPlO8rEwS0=.74b73b12-1b0a-4d73-b18f-1f6ac0e5f18d@github.com> Message-ID: On Fri, 2 Jan 2026 12:07:57 GMT, Andrew Haley wrote: > > > Sure, I can see that, but is there any reason not to do this by default on all AArch64? > > > > > > Do you mean to do this for all AArch64 OSes, not only for Linux AArch64? > > In a perfect world we'd do this for all AArch64. But Linux-only would be good too. But is there any reason not to do this on all Linux systems? IMO, a reason is that not all AArch64 might have both `ctr_el0.IDC` and `ctr_el0.DIC` set. If either of `ctr_el0.IDC`/`ctr_el0.DIC` or both are not set, we will need to use `DC`/`IC` with real addresses to clean and to invalidate caches. We will need to choose between invalidating modified instructions or the whole nmethod's code. Invalidating modified instructions will need tracking of modified instructions. Invalidating the whole nmethod does not need tracking but it can be expensive vs invalidating particular instructions. IMO cases of Java running on AArch64 CPU where both `ctr_el0.IDC` and `ctr_el0.DIC` are not set, might be rare. Jacob Bramley from Arm has nice blog posts about Caches and Self-Modifying Code: - [Caches and Self-Modifying Code: Implementing `__clear_cache`](https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-implementing-clear-cache) - [Caches and Self-Modifying Code: Working with Threads](https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-working-with-threads) In this PR we optimize two parts invalidating caches: 1. GCs patching code. This is invalidation of modified instructions. 2. Generation and installation of code. This is invalidation of the whole code. The second case can be optimized for all AArch64. Is there anything I am missing? And we can do optimized cache invalidation on all AArch64? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28328#issuecomment-3705607781 From aph at openjdk.org Fri Jan 2 18:06:58 2026 From: aph at openjdk.org (Andrew Haley) Date: Fri, 2 Jan 2026 18:06:58 GMT Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact on GCs and JIT performance [v21] In-Reply-To: References: <15wAKoik-66gfbUzGQEROBTv_cTV_I_6jq96S2ErOyA=.22e19b52-220c-4c35-9aaa-9f08719e16fa@github.com> <2b8w_8NwTITCCqqyirLgPcfxyQd35yS-MmPlO8rEwS0=.74b73b12-1b0a-4d73-b18f-1f6ac0e5f18d@github.com> Message-ID: On Fri, 2 Jan 2026 15:39:50 GMT, Evgeny Astigeevich wrote: > > > > Sure, I can see that, but is there any reason not to do this by default on all AArch64? > > > > > > > > > Do you mean to do this for all AArch64 OSes, not only for Linux AArch64? > > > > > > In a perfect world we'd do this for all AArch64. But Linux-only would be good too. But is there any reason not to do this on all Linux systems? > > IMO, a reason is that not all AArch64 might have both `ctr_el0.IDC` and `ctr_el0.DIC` set. If either of `ctr_el0.IDC`/`ctr_el0.DIC` or both are not set, we will need to use `DC`/`IC` with real addresses to clean and to invalidate caches. We will need to choose between invalidating modified instructions or the whole nmethod's code. Invalidating modified instructions will need tracking of modified instructions. Invalidating the whole nmethod does not need tracking but it can be expensive vs invalidating particular instructions. Ah, I see. So it looks like we'll have to maintain two entirely different bodies of code to do the cache management. That will be a recurring pain, and is disappointing. > > IMO cases of Java running on AArch64 CPU where both `ctr_el0.IDC` and `ctr_el0.DIC` are not set, might be rare. > > Jacob Bramley from Arm has nice blog posts about Caches and Self-Modifying Code: > > * [Caches and Self-Modifying Code: Implementing `__clear_cache`](https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-implementing-clear-cache) That's useful. It's worth taking advantage of cache-coherent implementations (when they're not broken!) by not emitting unnecessary instructions. > * [Caches and Self-Modifying Code: Working with Threads](https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-working-with-threads) Thanks. That's a good read, but no surprises. I'm fairly sure we've been doing most of that for as long as the port has existed. > In this PR we optimize two parts invalidating caches: > > 1. GCs patching code. This is invalidation of modified instructions. > > 2. Generation and installation of code. This is invalidation of the whole code. > > > The second case can be optimized for all AArch64. > > Is there anything I am missing? And we can do optimized cache invalidation on all AArch64? Probably not, but I've been working on a patch to minimize the invalidation we do today. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28328#issuecomment-3705936075 From eastigeevich at openjdk.org Fri Jan 2 22:07:00 2026 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Fri, 2 Jan 2026 22:07:00 GMT Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact on GCs and JIT performance [v21] In-Reply-To: References: <15wAKoik-66gfbUzGQEROBTv_cTV_I_6jq96S2ErOyA=.22e19b52-220c-4c35-9aaa-9f08719e16fa@github.com> <2b8w_8NwTITCCqqyirLgPcfxyQd35yS-MmPlO8rEwS0=.74b73b12-1b0a-4d73-b18f-1f6ac0e5f18d@github.com> Message-ID: On Fri, 2 Jan 2026 18:02:49 GMT, Andrew Haley wrote: >>> > > Sure, I can see that, but is there any reason not to do this by default on all AArch64? >>> > >>> > >>> > Do you mean to do this for all AArch64 OSes, not only for Linux AArch64? >>> >>> In a perfect world we'd do this for all AArch64. But Linux-only would be good too. But is there any reason not to do this on all Linux systems? >> >> IMO, a reason is that not all AArch64 might have both `ctr_el0.IDC` and `ctr_el0.DIC` set. If either of `ctr_el0.IDC`/`ctr_el0.DIC` or both are not set, we will need to use `DC`/`IC` with real addresses to clean and to invalidate caches. We will need to choose between invalidating modified instructions or the whole nmethod's code. Invalidating modified instructions will need tracking of modified instructions. Invalidating the whole nmethod does not need tracking but it can be expensive vs invalidating particular instructions. >> >> IMO cases of Java running on AArch64 CPU where both `ctr_el0.IDC` and `ctr_el0.DIC` are not set, might be rare. >> >> Jacob Bramley from Arm has nice blog posts about Caches and Self-Modifying Code: >> - [Caches and Self-Modifying Code: Implementing `__clear_cache`](https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-implementing-clear-cache) >> - [Caches and Self-Modifying Code: Working with Threads](https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-working-with-threads) >> >> In this PR we optimize two parts invalidating caches: >> 1. GCs patching code. This is invalidation of modified instructions. >> 2. Generation and installation of code. This is invalidation of the whole code. >> >> The second case can be optimized for all AArch64. >> >> Is there anything I am missing? And we can do optimized cache invalidation on all AArch64? > >> > > > Sure, I can see that, but is there any reason not to do this by default on all AArch64? >> > > >> > > >> > > Do you mean to do this for all AArch64 OSes, not only for Linux AArch64? >> > >> > >> > In a perfect world we'd do this for all AArch64. But Linux-only would be good too. But is there any reason not to do this on all Linux systems? >> >> IMO, a reason is that not all AArch64 might have both `ctr_el0.IDC` and `ctr_el0.DIC` set. If either of `ctr_el0.IDC`/`ctr_el0.DIC` or both are not set, we will need to use `DC`/`IC` with real addresses to clean and to invalidate caches. We will need to choose between invalidating modified instructions or the whole nmethod's code. Invalidating modified instructions will need tracking of modified instructions. Invalidating the whole nmethod does not need tracking but it can be expensive vs invalidating particular instructions. > > Ah, I see. So it looks like we'll have to maintain two entirely different bodies of code to do the cache management. That will be a recurring pain, and is disappointing. > >> >> IMO cases of Java running on AArch64 CPU where both `ctr_el0.IDC` and `ctr_el0.DIC` are not set, might be rare. >> >> Jacob Bramley from Arm has nice blog posts about Caches and Self-Modifying Code: >> >> * [Caches and Self-Modifying Code: Implementing `__clear_cache`](https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-implementing-clear-cache) > > That's useful. It's worth taking advantage of cache-coherent implementations (when they're not broken!) by not emitting unnecessary instructions. > >> * [Caches and Self-Modifying Code: Working with Threads](https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-working-with-threads) > > Thanks. That's a good read, but no surprises. I'm fairly sure we've been doing most of that for as long as the port has existed. > >> In this PR we optimize two parts invalidating caches: >> >> 1. GCs patching code. This is invalidation of modified instructions. >> >> 2. Generation and installation of code. This is invalidation of the whole code. >> >> >> The second case can be optimized for all AArch64. >> >> Is there anything I am missing? And we can do optimized cache invalidation on all AArch64? > > Probably not, but I've been working on a patch to minimize the invalidation we do today. @theRealAph > ... > Probably not, but I've been working on a patch to minimize the invalidation we do today. Does this mean we don't need this PR or need to rework it? Could you please provide more details? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28328#issuecomment-3706299227 From aph at openjdk.org Sat Jan 3 09:59:05 2026 From: aph at openjdk.org (Andrew Haley) Date: Sat, 3 Jan 2026 09:59:05 GMT Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact on GCs and JIT performance [v21] In-Reply-To: References: <15wAKoik-66gfbUzGQEROBTv_cTV_I_6jq96S2ErOyA=.22e19b52-220c-4c35-9aaa-9f08719e16fa@github.com> <2b8w_8NwTITCCqqyirLgPcfxyQd35yS-MmPlO8rEwS0=.74b73b12-1b0a-4d73-b18f-1f6ac0e5f18d@github.com> Message-ID: <8hQOV9QhPL_j5g7WpcwzJc_8QPeAzLSIFk3ASRlCXa8=.3e1ac93f-2f6a-4dce-bead-31241240cb6e@github.com> On Fri, 2 Jan 2026 22:04:00 GMT, Evgeny Astigeevich wrote: > > Probably not, but I've been working on a patch to minimize the invalidation we do today. > > Does this mean we don't need this PR or need to rework it? Could you please provide more details? It makes no difference to this patch. I'm still experimenting. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28328#issuecomment-3706937169 From peter.kessler at os.amperecomputing.com Mon Jan 5 05:08:02 2026 From: peter.kessler at os.amperecomputing.com (Peter Kessler OS) Date: Mon, 5 Jan 2026 05:08:02 +0000 Subject: Variability of the performance of Vector Message-ID: I am worried about the variability of the performance of Vector. Worse, I am worried about how to explain to users the variability of the performance of Vector. I started from the second code example from https://docs.oracle.com/en/java/javase/25/docs/api/jdk.incubator.vector/jdk/incubator/vector/package-summary.html. I changed it to compute dot-product (reading two arrays and computing a scalar result) rather than simple multiply (reading two arrays and writing a third array). When I look at the generated native instructions, I see that performance is dominated by the loop-carried dependence updating the result variable. The solution to that is to have each loop compute several independent sum variables, using more vector registers. (That is what they are there for! That also gives the out-of-order engine in the core something to work with.) Using two sum variables runs almost two times as fast as using a single sum variable; three sum variables runs faster than two sum variables; four sum variables runs faster than three sum variables, but there are diminishing returns. More interestingly, and more worryingly, the run time for four sum variables starts to show run-to-run variation. Sometimes a run is fast, sometimes it is only a few percent slower than the fastest time, but some of the time (~30%) a run can be more than 25% slower than the fastest time. Worse, the run times are not a smooth curve between the fastest and slowest runs: the distribution is step function. With no way to predict why some runs are slow. (JMH benchmarks available upon request.) I have tracked the slowdown to the alignment of the input arrays to the L1 cache lines. For example, a `FloatVector.fromArray(FloatVector.SPECIES_PREFERRED, a, offset)` on a machine with 4 vector lanes will try to load 4 floats from the array `a`. If those 4 floats are all in the same cache line, life is good. If the 4 floats are split across 2 cache lines, the load takes longer. How much longer a load takes depends on the microarchitecture of the machine, where in the loads you cross the cache line boundary, and probably other things a Java programmer cannot control. A C programmer can control the alignment of a float arroy by requesting an aligned allocation of the array. A Java programmer cannot control the alignment. The Java case is also complicated by the header on the array, which can vary in size depending on run-time flags for the sizes of the fields in the array header. Since the run-to-run variation is so large and hard to explain, I would like to open a discussion of what the JVM can do about aligning array data so that it can be used reliably by the `Vector` mechanisms. An out-of-the-box experiment I tried was to run with `-XX:ObjectAlignmentInBytes=64` (on a machine with a 64-byte L1 cache line size). The hope was that every array of type E would be aligned the same way relative to the cache lines, so there would be no run-to-run variation in performance. That worked. But increasing the object alignment for all objects wastes a lot of space. Given that confirmation, I thought to try changing just the alignment of arrays of scalars. For example, by allocating filler objects before the array object to get the array base aligned on a cache line boundary. That only solves the problem for newly allocated arrays but does not preserve the alignment when a garbage collector relocates the array. (I have no demographic data on the lifetime of arrays that are used with `Vector`, but it would be disappointing to have good performance only until a collector relocates your array and then have no way to recover the good performance.) Wave hands over large arrays and collectors that allocate large objects in humongous regions and then does not relocate those regions. Not all arrays of scalars should be in humongous regions. The only positive (!) thing I have thought of that might help is that the high-order bit of the length field of an array is always 0, because the length field is an `int` and the maximum length of an array is `Integer.MAX_VALUE`. Maybe there is some way to use the sign-bit of the length field to indicate that an array has an aligned base address. Establish that alignment at allocation time and re-establish it when an array is relocated. At the cost of computing the absolute value of the length field every time it is read. Aligning arrays to avoid occasional 25% performance loss seems like a worthwhile goal. I would like to open a discussion about how that end might be achieved. ??????????????????... peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From tschatzl at openjdk.org Mon Jan 5 06:18:08 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 5 Jan 2026 06:18:08 GMT Subject: RFR: 8292606: G1 and Epsilon header cleanup for JDK-8282729 In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 15:12:39 GMT, Axel Boldt-Christmas wrote: > In [JDK-8282729](https://bugs.openjdk.org/browse/JDK-8282729) a few headers where found which were indirectly included via `#include "gc/shared/blockOffsetTable.hpp", [JDK-8282729](https://bugs.openjdk.org/browse/JDK-8282729) moves the Serial part of `blockOffsetTable` into `gc/serial` so those headers needs to be fixed for G1 and Epsilon. These header fixes were moved out of the issue to make the review processes easier. Here is a list of the files in question. > * `src/hotspot/share/gc/epsilon/epsilonHeap.hpp` > * Uses `VirtualSpace` > * `src/hotspot/share/gc/g1/g1CollectionSetChooser.hpp` > * Uses `G1MixedGCLiveThresholdPercent` > * `src/hotspot/share/gc/g1/g1FullGCScope.cpp` > * Uses `MarkSweepDeadRatio` > * `src/hotspot/share/gc/g1/g1HeapRegionEventSender.cpp` > * Uses `UseG1GC` > * `src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp` > * Uses `GCTimeRatio`, `G1ExpandByPercentOfAvailable`, `MaxHeapSize`, `MinHeapSize`, `MaxHeapFreeRatio`, `MinHeapFreeRatio` > * `src/hotspot/share/gc/g1/g1MemoryPool.cpp` > * Uses `UseG1GC` > * `src/hotspot/share/gc/g1/g1NUMA.cpp` > * Uses `AlwaysPreTouch` > * `src/hotspot/share/gc/g1/g1RegionToSpaceMapper.cpp` > * Uses `AlwaysPreTouch` > * `src/hotspot/share/gc/g1/g1SegmentedArrayFreeMemoryTask.cpp` > * Uses `G1RemSetFreeMemoryStepDurationMillis` (just trying again because of no bot reaction after 10mins) ------------- PR Comment: https://git.openjdk.org/jdk/pull/9921#issuecomment-1220397110 From aboldtch at openjdk.org Mon Jan 5 06:20:40 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 5 Jan 2026 06:20:40 GMT Subject: RFR: 8308500: ZStatSubPhase::register_start should not call register_gc_phase_start if ZAbort::should_abort() In-Reply-To: References: Message-ID: <99gvASfFvM5DutxlGVe2p43XPtx8K53LBoLMmW-nx3A=.85fa8b40-9a7b-4b35-a316-61aa5629272c@github.com> On Mon, 22 May 2023 07:37:19 GMT, Axel Boldt-Christmas wrote: > `ZStatSubPhase::register_start` should not call `register_gc_phase_start` if `ZAbort::should_abort()` is true. This will cause an unbalanced push and pop behaviour of the phase stack as `ZStatSubPhase::register_end` stops popping (and sending events) after the aborting has started. This will create an issue if more subsequent sub-phases are added in-between two abort points as the phase stack may overflow. > > Simply avoid pushing new phases when aborting has started solves this issue. Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14075#issuecomment-1559019723 From aboldtch at openjdk.org Mon Jan 5 06:20:42 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 5 Jan 2026 06:20:42 GMT Subject: Integrated: 8308500: ZStatSubPhase::register_start should not call register_gc_phase_start if ZAbort::should_abort() In-Reply-To: References: Message-ID: On Mon, 22 May 2023 07:37:19 GMT, Axel Boldt-Christmas wrote: > `ZStatSubPhase::register_start` should not call `register_gc_phase_start` if `ZAbort::should_abort()` is true. This will cause an unbalanced push and pop behaviour of the phase stack as `ZStatSubPhase::register_end` stops popping (and sending events) after the aborting has started. This will create an issue if more subsequent sub-phases are added in-between two abort points as the phase stack may overflow. > > Simply avoid pushing new phases when aborting has started solves this issue. This pull request has now been integrated. Changeset: e5596133 Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/e55961331e10884e4255ab152d430ceb3f02748c Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8308500: ZStatSubPhase::register_start should not call register_gc_phase_start if ZAbort::should_abort() Reviewed-by: stefank, eosterlund ------------- PR: https://git.openjdk.org/jdk/pull/14075 From jnorlinder at openjdk.org Mon Jan 5 09:25:18 2026 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Mon, 5 Jan 2026 09:25:18 GMT Subject: RFR: 8373695: G1: Using a value near integer max for ActiveProcessorCount causes fatal crash [v3] In-Reply-To: References: Message-ID: > G1ConcRefinementThreads default value depends on ParallelGCThreads which in turn may depend on ActiveProcessorCount. These have different ranges that are valid. Patch will ensure argument setup code never try to assign a value larger than what G1ConcRefinementThreads expects. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Minimize changeset ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28831/files - new: https://git.openjdk.org/jdk/pull/28831/files/416b88ed..aee11b28 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28831&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28831&range=01-02 Stats: 7 lines in 4 files changed: 3 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28831.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28831/head:pull/28831 PR: https://git.openjdk.org/jdk/pull/28831 From lkorinth at openjdk.org Mon Jan 5 10:33:10 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 5 Jan 2026 10:33:10 GMT Subject: RFR: 8373253: Re-work InjectGCWorkerCreationFailure for future changes [v2] In-Reply-To: <78ejbDKfHkTR88XnHC2t975-zof6vMjdM_M_rTyB0pk=.d5c9798a-b1ca-4299-af35-2caaad2f8106@github.com> References: <78ejbDKfHkTR88XnHC2t975-zof6vMjdM_M_rTyB0pk=.d5c9798a-b1ca-4299-af35-2caaad2f8106@github.com> Message-ID: <2_t0gyjfmYceE5wT_BnCuy1ImoaCaRaKT_BTIz3tHZc=.60e48ca6-07f5-475c-b473-293c22af7206@github.com> > This PR slightly changes when we may `InjectGCWorkerCreationFailure`. At the moment we wait until `is_init_completed()`. I am changing this to instead be after `_created_workers > 0`. The reason is that we might in the future, https://bugs.openjdk.org/browse/JDK-8367993, create even more threads "on demand", and if so, we would fail VM creation if we inject worker creation failures after the VM is initiated but before we have created any of the worker threads. > > This change should not change the current behaviour. But help future improvements. > > I have tested this on `test/hotspot/jtreg/gc/stress/gcold/TestGCOldWithG1.java`, the only place where this flag is tested to my knowledge. Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: Fixup after comment from Ivan. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28719/files - new: https://git.openjdk.org/jdk/pull/28719/files/d45ea881..2aa8aa4b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28719&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28719&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28719.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28719/head:pull/28719 PR: https://git.openjdk.org/jdk/pull/28719 From mdoerr at openjdk.org Mon Jan 5 14:03:46 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 5 Jan 2026 14:03:46 GMT Subject: RFR: 8373429: gc/g1/TestCodeCacheUnloadDuringConcCycle fails on various platforms In-Reply-To: <8iV1ky2iG2BXmnRPupEyw_pxc_RtehJgN28ZaihGsCY=.d2e8ca48-722a-4f08-9952-46824b8462a2@github.com> References: <8iV1ky2iG2BXmnRPupEyw_pxc_RtehJgN28ZaihGsCY=.d2e8ca48-722a-4f08-9952-46824b8462a2@github.com> Message-ID: <-e1_aeRhmFdaUjFhqvsFl3a6sXvxCzESU7i77xRRdqU=.dc78d2d9-fe4c-40e8-9ddf-d058216e4b60@github.com> On Mon, 15 Dec 2025 11:34:55 GMT, Thomas Schatzl wrote: > Hi all, > > this is hopefully the last fix attempt for the [gc/g1/TestCodeCacheUnloadDuringConcCycle.java](https://github.com/openjdk/jdk/pull/28822/files#diff-6ce99d53ba7ea02f2c7f0e878f937acecbd64f3c9a6edebcef79d10983cf3c28) test that proves to be fairly unstable across some platforms. > > The change adds more classes/code to be compiled during the test to fill the code cache faster, and more consistently exercise the code cachec loading. > > I also opted to revert the change from https://bugs.openjdk.org/browse/JDK-8372860 because it (unsuccessfully) tried the same method. There is no need to prolong the test any more. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by mdoerr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28822#pullrequestreview-3626952620 From emanuel.peter at oracle.com Mon Jan 5 15:12:34 2026 From: emanuel.peter at oracle.com (Emanuel Peter) Date: Mon, 5 Jan 2026 15:12:34 +0000 Subject: Variability of the performance of Vector Message-ID: Hi Peter, It seems you are worried about array alignment when using the Vector API. This is a known issue, and comes up from time to time. See for example some detailed explanations in this PR: https://github.com/openjdk/jdk/pull/25065 (it is about auto vectorization, but also has a section on the Vector API). I also mentioned alignment in my JVMLS2025 talk: https://inside.java/2025/08/16/jvmls-hotspot-auto-vectorization/ I think you won't get around explaining alignment to users. It is just a the nature of vector instructions on the hardware. Sometimes you can manage to align and get better performance. In other cases, alignment is not possible for a variety of reasons. There are several issues with array alignment: * ObjectAlignmentInBytes only aligns the header of an object. And not the payload of the array. In some cases, the header size is 12 bytes (for ints with UseCompactObjectHeaders). So even if you set ObjectAlignmentInBytes=64, your elements are still only 12 byte aligned. There has been discussion about at some far time in the future, where we could hyper-align large arrays, and make sure the payload is aligned, instead of the header. But that probably won't happen any time soon. * GC can move your arrays, and change hence alignment can change over time. When I have asked Paul Sandoz and others more involved with the API design, they told me that users should just use native memory, where alignment can be controlled at the allocation. Personally, I'm half-satisfied with this suggestion. I could imagine some users would want to actively set the alignment of an array. That is difficult. Others may be satisfied with querying the alignment relative to the last cache line. So I suggested having something like "Arrays.alignment(arr)" that would give an alignment "hint", so the user could implement an alignment loop, followed by a vectorized loop, followed by a clean-up loop (classic pre-main-post, like the auto vectorizer generates). Others were hesitant, because that would suggest the users should now write 3 loops, which is going to be a nuisance. I think this discussion will come up again, but it is not a priority as far as I gather. And: even if you get a performance penalty for misalignment: it is still very profitable to vectorize in most cases. A 25% regression due to misalignment only loses you a little on the large factors (e.g. 2x, 4x, 8x) you get from vectorizing in the first place. There are also other "variability of performance" issues. For example availability of hardware instructions: if vector instructions are available you get nice speedups in comparison to a scalar implementation. But some instructions are not available, the Vector API falls back to a scalar implementation, which can drastically hurt performance, and even get you much worse performance compared to a scalar implementation of the algorithm. See https://github.com/openjdk/jdk/pull/28639 It could be beneficial to improve the "performance notes" section of the Vector API docs: https://download.java.net/java/early_access/jdk26/docs/api/jdk.incubator.vector/jdk/incubator/vector/package-summary.html#performance-notes-heading Kind regards, Emanuel Confidential- Oracle Internal -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkemper at openjdk.org Mon Jan 5 17:13:08 2026 From: wkemper at openjdk.org (William Kemper) Date: Mon, 5 Jan 2026 17:13:08 GMT Subject: RFR: 8373819: GenShen: Requested generation may be null [v3] In-Reply-To: <8SWpQdaleulzSXfgF4fJ_zgekaijLs53t8Wer6IvKwo=.785abf41-65b7-44f6-90d0-2c63d5bf5981@github.com> References: <8SWpQdaleulzSXfgF4fJ_zgekaijLs53t8Wer6IvKwo=.785abf41-65b7-44f6-90d0-2c63d5bf5981@github.com> Message-ID: > This PR attempts to simplify the generational control thread by decoupling it somewhat from the heap/gc cancellation mechanism. This is meant to prevent the control thread from seeing inconsistencies between `shHeap::_cancelled_gc` and `shGenControlThread::_requested_gc_cause`. William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - Merge remote-tracking branch 'jdk/master' into fix-null-generation-crash - Fix typo in assertion message - Take regulator thread out of STS before requesting GC The request may block while it waits for control thread to stop old marking. If workers are already in the STS, and the regulator thread is still in the STS, but cannot yield, the safepoint will not run. Control, worker and regulator threads deadlock each other. - Add comments - Revert back to what should be on this branch - Merge remote-tracking branch 'jdk/master' into fix-null-generation-crash - Don't know how this file got deleted - Carry over gc cancellation to gc request - Do not let allocation failure requests be overwritten by other requests - Fix degen point handling - ... and 3 more: https://git.openjdk.org/jdk/compare/4458cab4...8f4f55db ------------- Changes: https://git.openjdk.org/jdk/pull/28932/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28932&range=02 Stats: 95 lines in 4 files changed: 45 ins; 17 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/28932.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28932/head:pull/28932 PR: https://git.openjdk.org/jdk/pull/28932 From kdnilsen at openjdk.org Mon Jan 5 19:31:14 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 5 Jan 2026 19:31:14 GMT Subject: RFR: 8312116: JDK GenShen: make instantaneous allocation rate triggers more timely Message-ID: After studying large numbers of GC logs with degenerated cycles that have resulted from "late" triggers, we propose the following general improvements: 1. Track trends in GC times rather than always using the average GC time plus standard deviation. In many situations, GC times trend upward due to, for example, increasing amounts of live data that must be marked as a workload builds up its working set of memory. 2. Sample allocation rates more frequently than once every 100 ms. 3. Track trends in allocation rates. In some situations, the allocation rate trends upwards due to, for example, the start of a new phase of execution or a spike in client workload. 4. When we detect acceleration of workload, predict consumption of memory based on accelerated allocation rates rather than assuming constant allocation rate. ------------- Commit messages: - Change type of command-line args - fix white space - Add override to virtual methods - Fix race between allocation reporting and querying - add debug instrumentation - Merge remote-tracking branch 'jdk/master' into accelerated-triggers - add instrumentation and fix bugs - Merge remote-tracking branch 'jdk/master' into accelerated-triggers - some debug instrumentation - Merge remote-tracking branch 'origin/accelerated-triggers' into accelerated-triggers-gh - ... and 49 more: https://git.openjdk.org/jdk/compare/400d8cfb...c7046b5c Changes: https://git.openjdk.org/jdk/pull/29039/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312116 Stats: 1529 lines in 26 files changed: 1423 ins; 34 del; 72 mod Patch: https://git.openjdk.org/jdk/pull/29039.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29039/head:pull/29039 PR: https://git.openjdk.org/jdk/pull/29039 From kdnilsen at openjdk.org Mon Jan 5 19:31:14 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 5 Jan 2026 19:31:14 GMT Subject: RFR: 8312116: JDK GenShen: make instantaneous allocation rate triggers more timely In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 15:10:52 GMT, Kelvin Nilsen wrote: > After studying large numbers of GC logs with degenerated cycles that have resulted from "late" triggers, we propose the following general improvements: > > 1. Track trends in GC times rather than always using the average GC time plus standard deviation. In many situations, GC times trend upward due to, for example, increasing amounts of live data that must be marked as a workload builds up its working set of memory. > 2. Sample allocation rates more frequently than once every 100 ms. > 3. Track trends in allocation rates. In some situations, the allocation rate trends upwards due to, for example, the start of a new phase of execution or a spike in client workload. > 4. When we detect acceleration of workload, predict consumption of memory based on accelerated allocation rates rather than assuming constant allocation rate. This PR shows very slight improvements on specjbb tests: ~/github/jdk.accelerated-triggers/build/linux-x86_64-server-release/jdk/bin/java \ -XX:+UnlockExperimentalVMOptions \ -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms10g -Xmx10g -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational \ -javaagent:/home/kdnilsen/lib/jHiccup-2.0.10/jHiccup.jar=-l,results/specjbb2015-master-jhiccup.log,-i,1000,-a \ -Xlog:async \ -Xlog:gc*=info \ -Xlog:safepoint*=info \ -Xlog:handshake*=info \ -jar /home/kdnilsen/lib/specjbb2015/specjbb2015.jar \ -m composite -ikv \ -p /home/kdnilsen/lib/specjbb2015/config/specjbb2015.props \ -raw /home/kdnilsen/lib/specjbb2015/config/template-C.raw >$t.accelerated-trigger.specjbb2015.out 2>$t.accelerated-triggers.specjbb2015.err image We have tested this new PR out with several different heap sizes on a particular Extremem workload and provide the results here. With 16GB heap size, both master and accelerated-triggers perform poorly. We consider the JVM to be under provisioned for this workload, and the behavior of accelerated-triggers is considered acceptable compared to master in this configuration. Accelerated-triggers has 0.24% to 30.5% worse latency across reported response-time percentiles. On average, it performs 57% more GC cycles, resulting in 50% fewer degenerated cycles (due to earlier triggers). CPU utilization is 0.60% higher. image With 20GB heap size, the benefits of accelerated-triggers are demonstrated in improved p50, p95, and p99 latencies. Note that accelerated-triggers is able to complete an average of 120% more old GCs than master. In this configuration, master is more vulnerable to starvation of old generation processing. Accelerated-triggers performed 30% fewer degenerated cycles and 30% fewer full GC cycles than master. image With 24GB heap size, both master and accelerated-triggers experienced degraded performance on one of five trials. This appears to have resulted from starvation of old-gen processing in both cases. Even so, the accelerated-triggers run was able to complete 5 old collections vs. only 4 completed old collections with master. For this configuration, we report both average results and trimmed average results. Average results favor accelerated-triggers at most percentiles. Trimmed average results favor master at most percentiles. image At 28GB heap size, accelerated-triggers shows signifcant strength compared to master. Three of five trials with master experienced degenerated cycles, and two of five trials with master experienced full GC. None of the five trials with accelerated-triggers experienced degenerated or full GC cycles. This manifests in generally better latency across all percentiles. image With the 31GB heap size, latencies are very similar between master and accelerated-triggers. Accelerated-triggers consumes 15% more CPU as it is performing 103% more GCs. Note that accelerated-triggers completes one more old GC than master, demonstrating that it is less vulnerable than master to starvation of old-gen processing. image Note that typical service deployments tend to be provisioned with excess resources. This allows the services to operate more reliably under transient spikes in client workload, and avoids "rare" triggering missteps that cause unwanted degenerated and full GC cycles. This particular workload would most typically be deployed today with a 31G heap if it were a production service. A goal of the GenShen engineering team is to enable more frugal use of CPU and memory resources. In the longer term, we would hope to enable reliable production deployment of this workload in 28GB or 24GB of memory. We have observed for some workload that accelerated-triggers increases contention between young-generation and old-generation GC activities, because it often forces more frequent young-generation activities. In practice, this is often balanced by more timely collection of young, which reduces "urgent" young collection efforts that occur when the JVM is under duress. Other development efforts are under way to allow more graceful cooperation between young-generation and old-generation concurrent activities when both feel the need to contend for CPU time. The workload used in the above tests is represented by this script: ~/github/jdk.accelerated-triggers/build/linux-x86_64-server-release/images/jdk/bin/java \ -XX:ActiveProcessorCount=16 \ -XX:+UnlockExperimentalVMOptions \ -XX:+AlwaysPreTouch -XX:+DisableExplicitGC -Xms$m -Xmx$m \ -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational \ -XX:ShenandoahFullGCThreshold=1024 \ -XX:ShenandoahGuaranteedOldGCInterval=0 \ -XX:ShenandoahGuaranteedYoungGCInterval=0 \ -Xlog:"gc*=info,ergo" \ -Xlog:safepoint=trace -Xlog:safepoint=debug -Xlog:safepoint=info \ -XX:+UnlockDiagnosticVMOptions \ -jar ~/github/heapothesys/Extremem/src/main/java/extremem.jar \ -dDictionarySize=3000000 \ -dNumCustomers=9000000 \ -dNumProducts=240000 \ -dCustomerThreads=800 \ -dAllowAnyMatch=false \ -dCustomerPeriod=2s \ -dCustomerThinkTime=300ms \ -dKeywordSearchCount=4 \ -dSelectionCriteriaCount=2 \ -dProductReviewLength=12 \ -dServerThreads=5 \ -dServerPeriod=10s \ -dProductNameLength=10 \ -dBrowsingHistoryQueueCount=5 \ -dSalesTransactionQueueCount=5 \ -dProductDescriptionLength=320 \ -dProductReplacementPeriod=60s \ -dProductReplacementCount=25 \ -dCustomerReplacementPeriod=60s \ -dCustomerReplacementCount=1500 \ -dBrowsingExpiration=1m \ -dPhasedUpdates=true \ -dPhasedUpdateInterval=60s \ -dSimulationDuration=25m \ -dResponseTimeMeasurements=100000 \ >$t.$m.genshen.medium.accelerated.out \ 2>$t.$m.genshen.medium.accelerated.err & job_pid=$! sleep 1500 cpu_percent=$(ps -o cputime -o etime -p $job_pid) rss_kb=$(ps -o rss= -p $job_pid) rss_mb=$((rss_kb / 1024)) wait $job_pid echo "RSS: $rss_mb MB" >>$t.$m.genshen.medium.accelerated.out echo "$cpu_percent" >>$t.$m.genshen.medium.accelerated.out gzip $t.$m.genshen.medium.accelerated.out $t.$m.genshen.medium.accelerated.err ------------- PR Comment: https://git.openjdk.org/jdk/pull/29039#issuecomment-3710878539 PR Comment: https://git.openjdk.org/jdk/pull/29039#issuecomment-3711727740 From kdnilsen at openjdk.org Mon Jan 5 19:57:25 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 5 Jan 2026 19:57:25 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v2] In-Reply-To: References: Message-ID: > After studying large numbers of GC logs with degenerated cycles that have resulted from "late" triggers, we propose the following general improvements: > > 1. Track trends in GC times rather than always using the average GC time plus standard deviation. In many situations, GC times trend upward due to, for example, increasing amounts of live data that must be marked as a workload builds up its working set of memory. > 2. Sample allocation rates more frequently than once every 100 ms. > 3. Track trends in allocation rates. In some situations, the allocation rate trends upwards due to, for example, the start of a new phase of execution or a spike in client workload. > 4. When we detect acceleration of allocation rate, predict consumption of memory based on accelerated allocation rates rather than assuming constant allocation rate. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: add another override ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29039/files - new: https://git.openjdk.org/jdk/pull/29039/files/c7046b5c..43664d66 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29039.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29039/head:pull/29039 PR: https://git.openjdk.org/jdk/pull/29039 From wkemper at openjdk.org Mon Jan 5 19:57:27 2026 From: wkemper at openjdk.org (William Kemper) Date: Mon, 5 Jan 2026 19:57:27 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v2] In-Reply-To: References: Message-ID: <2eKXF6_uIhKFz0g0791S9sJfRhorjlm2ssVUvCpClMc=.4ad1e73b-b0e4-416b-9c33-2cb9d4bceda2@github.com> On Mon, 5 Jan 2026 19:54:04 GMT, Kelvin Nilsen wrote: >> After studying large numbers of GC logs with degenerated cycles that have resulted from "late" triggers, we propose the following general improvements: >> >> 1. Track trends in GC times rather than always using the average GC time plus standard deviation. In many situations, GC times trend upward due to, for example, increasing amounts of live data that must be marked as a workload builds up its working set of memory. >> 2. Sample allocation rates more frequently than once every 100 ms. >> 3. Track trends in allocation rates. In some situations, the allocation rate trends upwards due to, for example, the start of a new phase of execution or a spike in client workload. >> 4. When we detect acceleration of allocation rate, predict consumption of memory based on accelerated allocation rates rather than assuming constant allocation rate. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > add another override Can we remove the `KELVIN_*` macros? Perhaps fine tune some of the logging to `log_trace(gc, ergo)` or `log_debug(gc, ergo)` where appropriate? ------------- Changes requested by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29039#pullrequestreview-3628222792 From kdnilsen at openjdk.org Mon Jan 5 20:25:21 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 5 Jan 2026 20:25:21 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v2] In-Reply-To: <2eKXF6_uIhKFz0g0791S9sJfRhorjlm2ssVUvCpClMc=.4ad1e73b-b0e4-416b-9c33-2cb9d4bceda2@github.com> References: <2eKXF6_uIhKFz0g0791S9sJfRhorjlm2ssVUvCpClMc=.4ad1e73b-b0e4-416b-9c33-2cb9d4bceda2@github.com> Message-ID: On Mon, 5 Jan 2026 19:54:04 GMT, William Kemper wrote: > Can we remove the `KELVIN_*` macros? Perhaps fine tune some of the logging to `log_trace(gc, ergo)` or `log_debug(gc, ergo)` where appropriate? So sorry. Forgot I still had all of that in there. Coming out now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29039#issuecomment-3711960984 From kdnilsen at openjdk.org Mon Jan 5 20:39:03 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 5 Jan 2026 20:39:03 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v3] In-Reply-To: References: Message-ID: > After studying large numbers of GC logs with degenerated cycles that have resulted from "late" triggers, we propose the following general improvements: > > 1. Track trends in GC times rather than always using the average GC time plus standard deviation. In many situations, GC times trend upward due to, for example, increasing amounts of live data that must be marked as a workload builds up its working set of memory. > 2. Sample allocation rates more frequently than once every 100 ms. > 3. Track trends in allocation rates. In some situations, the allocation rate trends upwards due to, for example, the start of a new phase of execution or a spike in client workload. > 4. When we detect acceleration of allocation rate, predict consumption of memory based on accelerated allocation rates rather than assuming constant allocation rate. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Remove develop/debug instrumentation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29039/files - new: https://git.openjdk.org/jdk/pull/29039/files/43664d66..959b274c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=01-02 Stats: 498 lines in 10 files changed: 0 ins; 497 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29039.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29039/head:pull/29039 PR: https://git.openjdk.org/jdk/pull/29039 From xpeng at openjdk.org Mon Jan 5 21:04:45 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 5 Jan 2026 21:04:45 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v20] In-Reply-To: References: Message-ID: <797j9fNWUlV491wWKbFMfthH99o3A5493T0Pcdn_zdc=.417c13b0-8618-4402-aafa-3d86c45c8ff6@github.com> > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 265 commits: - Merge branch 'openjdk:master' into cas-alloc-1 - Fix build error after merging from tip - Merge branch 'master' into cas-alloc-1 - Merge branch 'master' into cas-alloc-1 - Some comments updates as suggested in PR review - Fix build failure after merge - Expend promoted from ShenandoahOldCollectorAllocator - Merge branch 'master' into cas-alloc-1 - Address PR comments - Merge branch 'openjdk:master' into cas-alloc-1 - ... and 255 more: https://git.openjdk.org/jdk/compare/de81d389...cf13b7b5 ------------- Changes: https://git.openjdk.org/jdk/pull/26171/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=19 Stats: 1644 lines in 25 files changed: 1296 ins; 235 del; 113 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From kdnilsen at openjdk.org Mon Jan 5 21:36:11 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 5 Jan 2026 21:36:11 GMT Subject: RFR: 8373714: Shenandoah: Register heuristic penalties following a degenerated GC [v5] In-Reply-To: References: Message-ID: > Add a triggering penalty when we execute degenerated GC cycle. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: touch file to force tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28834/files - new: https://git.openjdk.org/jdk/pull/28834/files/87b41568..7b0efb3e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28834&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28834&range=03-04 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28834.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28834/head:pull/28834 PR: https://git.openjdk.org/jdk/pull/28834 From kdnilsen at openjdk.org Mon Jan 5 21:49:35 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 5 Jan 2026 21:49:35 GMT Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need accurate live_data [v15] In-Reply-To: References: Message-ID: > The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected. In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region. This is typically ok for young regions, where the amount of live data determines whether a region should be added to the collection set during the final-mark safepoint. > > However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated. In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended. > > This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: touch file to force retest ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24319/files - new: https://git.openjdk.org/jdk/pull/24319/files/7b9c4d64..6480fef2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24319&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24319&range=13-14 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24319.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24319/head:pull/24319 PR: https://git.openjdk.org/jdk/pull/24319 From rsunderbabu at openjdk.org Tue Jan 6 10:28:50 2026 From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu) Date: Tue, 6 Jan 2026 10:28:50 GMT Subject: RFR: 8374576: Disable MemoryEaterMT for VirtualThread Message-ID: Background: The test induces OOM and frees memory when OOMError is thrown. However, there is no guarantee that OOM should happen in the same thread for the test to handle the error. OOM can arise in any thread. This logic makes this test fundamentally unreliable. Recently, we are seeing issue with VT usage. This is still useful test to have around. Hence, excluding the test only for VT case. Testing: Ran with and without VT thread. ------------- Commit messages: - 8374576: Disable MemoryEaterMT for VirtualThread Changes: https://git.openjdk.org/jdk/pull/29060/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29060&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374576 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29060.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29060/head:pull/29060 PR: https://git.openjdk.org/jdk/pull/29060 From shade at openjdk.org Tue Jan 6 13:11:35 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 6 Jan 2026 13:11:35 GMT Subject: RFR: 8373941: Epsilon: Robust counter updates in early VM phases Message-ID: See more details in the bug. This PR makes the counters updated on allocation path more robust. New regression test captures the original failure (intermittently). This would be also backported to JDK 26. Additional testing: - [x] Linux x86_64 server fastdebug, `gc/epsilon`, 100x - [x] Linux x86_64 server fastdebug, `runtime/cds/appcds/TestEpsilonGCWithCDS.java`, 100x - [x] Linux x86_64 server fastdebug, `gc/epsilon/TestInitAllocs.java`, 1000x ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/29061/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29061&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373941 Stats: 107 lines in 5 files changed: 94 ins; 1 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/29061.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29061/head:pull/29061 PR: https://git.openjdk.org/jdk/pull/29061 From lmesnik at openjdk.org Tue Jan 6 15:53:38 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 6 Jan 2026 15:53:38 GMT Subject: RFR: 8374576: Disable MemoryEaterMT for VirtualThread In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 10:20:17 GMT, Ramkumar Sunderbabu wrote: > Background: The test induces OOM and frees memory when OOMError is thrown. However, there is no guarantee that OOM should happen in the same thread for the test to handle the error. OOM can arise in any thread. This logic makes this test fundamentally unreliable. > Recently, we are seeing issue with VT usage. > > This is still useful test to have around. Hence, excluding the test only for VT case. > > Testing: > Ran with and without VT thread. Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29060#pullrequestreview-3631428193 From wkemper at openjdk.org Tue Jan 6 20:49:25 2026 From: wkemper at openjdk.org (William Kemper) Date: Tue, 6 Jan 2026 20:49:25 GMT Subject: RFR: 8373714: Shenandoah: Register heuristic penalties following a degenerated GC [v2] In-Reply-To: <_QnV10ychv2AQj3TN6gch1p8B-OGMTsN6FTcbBJSn9U=.cba48ddd-cb45-4e25-9633-5ef7e9cfa4ea@github.com> References: <_QnV10ychv2AQj3TN6gch1p8B-OGMTsN6FTcbBJSn9U=.cba48ddd-cb45-4e25-9633-5ef7e9cfa4ea@github.com> Message-ID: On Tue, 16 Dec 2025 23:30:58 GMT, Y. Srinivas Ramakrishna wrote: >> src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp line 321: >> >>> 319: op_degenerated_futile(); >>> 320: } else { >>> 321: _generation->heuristics()->record_unsuccessful_degenerated(); >> >> Suggestion: >> >> _generation->heuristics()->record_successful_degenerated(); >> >> I think the confusion here is that we are conflating `progress` and `success`. The "progress" notion here is about triggering a full GC or giving up entirely. The degenerated cycle is "successful" because it did not run a full GC. Maybe we should rename `record_successful_degenerated` to `record_degenerated` (or, perhaps even `apply_degenerated_penalty`). I was about to suggest we pull `record_success_degenerated` out of the logic entirely, but that would mean upgraded degen cycles would be penalized again when the full GC completes. > > May be let the heuristics (or the policy) track progress as well, and inform the actuator (i.e. op degenerated) whether it should upgrade to a full gc. It almost feels like heuristics and policy and actuator are leaking abstractions. It feels like heuristics keep track of the model parameters and learn from sensors, and the policy consults a specific heuristic to inform actuator (i.e. actions). > > By that model, you'd have the actuator sending the sensor information to the heuristics and asking the policy (or the heuristics, if you conflate heuristics and policy) to decide which step to take next. It would seem that evaluation of the notion of progress then moves to the policy too. @kdnilsen , what do you think about having a single method called `record_degenerated`. It's a matter of fact without conflating progress and success. I don't like having duplicated code between `record_success_degenerated` and `record_unsuccessful_degenerated`. I understand what @ysramakrishna is saying, and I agree, but I think a change like that is beyond the scope of this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28834#discussion_r2666242735 From wkemper at openjdk.org Tue Jan 6 22:31:38 2026 From: wkemper at openjdk.org (William Kemper) Date: Tue, 6 Jan 2026 22:31:38 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v3] In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 20:39:03 GMT, Kelvin Nilsen wrote: >> After studying large numbers of GC logs with degenerated cycles that have resulted from "late" triggers, we propose the following general improvements: >> >> 1. Track trends in GC times rather than always using the average GC time plus standard deviation. In many situations, GC times trend upward due to, for example, increasing amounts of live data that must be marked as a workload builds up its working set of memory. >> 2. Sample allocation rates more frequently than once every 100 ms. >> 3. Track trends in allocation rates. In some situations, the allocation rate trends upwards due to, for example, the start of a new phase of execution or a spike in client workload. >> 4. When we detect acceleration of allocation rate, predict consumption of memory based on accelerated allocation rates rather than assuming constant allocation rate. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > Remove develop/debug instrumentation Took another look over this. There is a lot to get through. I'll have more later. src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 179: > 177: " after adjusting for spike_headroom: %zu%s" > 178: " and penalties: %zu%s", _is_generational? _space_info->name(): "Global", > 179: byte_size_in_proper_unit(mutator_available), proper_unit_for_byte_size(mutator_available), Can we use the `PROPERFMT/PROPERFMTARGS` macros for these? I find they really improve readability. src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 199: > 197: > 198: // There is no headroom during evacuation and update refs. This information is not used to trigger the next GC. > 199: // Rather, it is made available to support throttling of allocations during GC. Is that true? or is allocation throttling part of another change? src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 275: > 273: } > 274: > 275: void ShenandoahAdaptiveHeuristics::add_gc_time(double timestamp, double gc_time) { Could we use `TruncatedSeq::predict_next` here? src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 1218: > 1216: } else { > 1217: heap->heuristics()->start_idle_span(); > 1218: } Suggestion: _generation->heuristics()->start_idle_span(); ------------- Changes requested by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29039#pullrequestreview-3632535527 PR Review Comment: https://git.openjdk.org/jdk/pull/29039#discussion_r2666483213 PR Review Comment: https://git.openjdk.org/jdk/pull/29039#discussion_r2666485239 PR Review Comment: https://git.openjdk.org/jdk/pull/29039#discussion_r2666489076 PR Review Comment: https://git.openjdk.org/jdk/pull/29039#discussion_r2666310682 From wkemper at openjdk.org Tue Jan 6 23:18:02 2026 From: wkemper at openjdk.org (William Kemper) Date: Tue, 6 Jan 2026 23:18:02 GMT Subject: RFR: 8314599: [GenShen] Couple adaptive tenuring and generation size budgeting [v14] In-Reply-To: References: Message-ID: > Notable changes: > * Improvements to logging > * More accurate tracking of promotion failures > * Use shared allocation for promotions only when the size is above the maximum plab size (not the minimum size) > * Use census information gathered during mark to size promotion reserves and old generation > > With these changes, GenShen is expected to have fewer promotion failures and this is indeed the case. As a result of this, we expect less time to be spent in concurrent marking and update refs for young collections. We may also expect shorter concurrent evacuation phases because GenShen will have fewer densely packed regions stuck in the young generation. With more objects being promoted, we also expect to see longer remembered set scan times. This is generally the case across all benchmarks, but we do also see some counter-intuitive results. > > Here we are comparing 20 executions (10 on x86, 10 on aarch64) of the changes in the PR (experiment) against 20 executions of the same benchmarks results from tip. This is a summary of statistically significant changes of more than 5% across all benchmarks: > > > Concurrent Evacuation: 7 improvements, 3 regressions > ? Best improvements: extremem-large-45g (-29.6%), neo4j-analytics (-26.9%) > ? Worst regression: xalan (+53.7%) > > Concurrent Marking: 15 improvements, 1 regression > ? Best improvements: hyperalloc_a2048_o4096 (-30.1%), crypto.rsa (-27.3%) > ? Only regression: serial (+8.9%) > > Concurrent Scan Remembered Set: 7 improvements, 2 regressions > ? Best improvements: xalan (-49.4%), pmd (-49.0%), crypto.rsa (-41.8%) > ? Worst regression: extremem-phased (+52.4%) > > Concurrent Update Refs: 5 improvements, 4 regressions > ? Best improvements: crypto.rsa (-36.4%), mnemonics (-28.4%) > ? Worst regression: xalan (+89.4%) William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 81 commits: - Merge remote-tracking branch 'jdk/master' into promotion-budget-improvements - Merge remote-tracking branch 'jdk/master' into promotion-budget-improvements - Fix comments, add back an assertion - Merge remote-tracking branch 'jdk/master' into promotion-budget-improvements - Accommodate behavior of global heuristic - Restore missing update for inplace promotion padding - Remove reference to adaptive tuning flag - Remove commented out assertion - Merge remote-tracking branch 'jdk/master' into promotion-budget-improvements - Adaptive tenuring is no longer optional We are using age census data to compute promotion reserves. The tenuring threshold may still be fixed by setting the min/max threshold to the same value. - ... and 71 more: https://git.openjdk.org/jdk/compare/7c979c14...f460f115 ------------- Changes: https://git.openjdk.org/jdk/pull/27632/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27632&range=13 Stats: 398 lines in 11 files changed: 158 ins; 173 del; 67 mod Patch: https://git.openjdk.org/jdk/pull/27632.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27632/head:pull/27632 PR: https://git.openjdk.org/jdk/pull/27632 From kdnilsen at openjdk.org Wed Jan 7 00:36:14 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 7 Jan 2026 00:36:14 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v20] In-Reply-To: <797j9fNWUlV491wWKbFMfthH99o3A5493T0Pcdn_zdc=.417c13b0-8618-4402-aafa-3d86c45c8ff6@github.com> References: <797j9fNWUlV491wWKbFMfthH99o3A5493T0Pcdn_zdc=.417c13b0-8618-4402-aafa-3d86c45c8ff6@github.com> Message-ID: On Mon, 5 Jan 2026 21:04:45 GMT, Xiaolong Peng wrote: >> Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: >> >> * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. >> * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. >> * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. >> * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` >> >> I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: >> >> 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. >> >> java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" >> >> >> Openjdk TIP: >> >> ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== >> ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== >> ===== DaCapo tail ... > > Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 265 commits: > > - Merge branch 'openjdk:master' into cas-alloc-1 > - Fix build error after merging from tip > - Merge branch 'master' into cas-alloc-1 > - Merge branch 'master' into cas-alloc-1 > - Some comments updates as suggested in PR review > - Fix build failure after merge > - Expend promoted from ShenandoahOldCollectorAllocator > - Merge branch 'master' into cas-alloc-1 > - Address PR comments > - Merge branch 'openjdk:master' into cas-alloc-1 > - ... and 255 more: https://git.openjdk.org/jdk/compare/de81d389...cf13b7b5 This is a huge PR. Thanks for working through all the details to get this working. I've identified several issues that I believe require some further attention. We can discuss in a meeting if that would be helpful. src/hotspot/share/gc/shenandoah/heuristics/shenandoahGenerationalHeuristics.cpp line 80: > 78: for (size_t i = 0; i < num_regions; i++) { > 79: ShenandoahHeapRegion* region = heap->get_region(i); > 80: assert(!region->is_active_alloc_region(), "Not expecting any active alloc region at the time"); Might change comment to: "Should be no active alloc regions when choosing collection set" src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 102: > 100: for (size_t i = 0; i < num_regions; i++) { > 101: ShenandoahHeapRegion* region = heap->get_region(i); > 102: assert(!region->is_active_alloc_region(), "Not expecting any active alloc region at the time"); Same suggestion here as with shenandoahGenerationalHeuristics.cpp. src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 110: > 108: } > 109: > 110: uint dummy = 0; Don't call this "dummy". Call it regions_ready_for_refresh. Remember the value and pass it in as a new argument to attempt_allocation_slow() so that we don't have to recompute it later. src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 114: > 112: HeapWord* obj = attempt_allocation_in_alloc_regions(req, in_new_region, alloc_start_index(), dummy); > 113: if (obj != nullptr) { > 114: return obj; Even in the case that we successfully fill our allocation request, if regions_ready_for_refresh is greater than some percentage of _alloc_region_count (e.g. > _alloc_region_count / 4), then we should grab the heap lock and refresh_alloc_regions() here. Otherwise, we will gradually degrade the number of directly_allocatable_regions until we are down to one before we refresh any of them. src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 133: > 131: ShenandoahHeapAccountingUpdater accounting_updater(_free_set, ALLOC_PARTITION); > 132: > 133: if (regions_ready_for_refresh > 0u) { Since we've already taken the heap lock because we failed to allocate "fast", I'm ok to go ahead and refresh any regions that are ready right now, even if it's only 1 region. I'm wondering if we can avoid thrashing in the case that there are no more regions available. We might want to keep a state variable that represents whether there exist free-set regions with which to refresh our cache. This could be updated whenever we "add to" or "rebuild" the free set, and whenever refresh_alloc_regions() find there is insufficient supply to demand. We would want to avoid repeated calls to refresh_alloc_regions() if there are no "refresh_regions_available". src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 192: > 190: uint i = alloc_start_index; > 191: do { > 192: if (ShenandoahHeapRegion* r = nullptr; (r = _alloc_regions[i].address) != nullptr && r->is_active_alloc_region()) { Note that there is a race (and performance overhead) with checking r->is_active_alloc_region(). Though a region might be active when we check it here, it may be inactive by the time we attempt to atomic_allocate_in(). This is one reason I prefer to use "volatile_top == end" to denote !is_active_alloc_region. This way, you only have to check once (rather than checking is_active() and then checking has_available()). And there is no race between when you check and when you attempt to allocate. src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 194: > 192: if (ShenandoahHeapRegion* r = nullptr; (r = _alloc_regions[i].address) != nullptr && r->is_active_alloc_region()) { > 193: bool ready_for_retire = false; > 194: HeapWord* obj = atomic_allocate_in(r, true, req, in_new_region, ready_for_retire); Insert before atomic_allocate_in: int contended Pass this as 6th arg to atomic_allocate_in() Add this code after atomic_allocate_in(): if ((i == alloc_start_index) && (contended > 1)) { randomize_start_index(); // I think this is realized by setting _alloc_start_index to UINT_MAX } src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 203: > 201: } > 202: } else if (r == nullptr || !r->is_active_alloc_region()) { > 203: regions_ready_for_refresh++; Add this code: if (i == alloc_start_index) { randomize_start_index(); } src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 214: > 212: > 213: template > 214: HeapWord* ShenandoahAllocator::atomic_allocate_in(ShenandoahHeapRegion* region, bool const is_alloc_region, ShenandoahAllocRequest &req, bool &in_new_region, bool &ready_for_retire) { Add argument: int &contended src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 219: > 217: size_t actual_size = req.size(); > 218: if (req.is_lab_alloc()) { > 219: obj = region->allocate_lab_atomic(req, actual_size, ready_for_retire); Pass contended arg to allocate_lab_atomic() src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 221: > 219: obj = region->allocate_lab_atomic(req, actual_size, ready_for_retire); > 220: } else { > 221: obj = region->allocate_atomic(actual_size, req, ready_for_retire); Pass contended arg to allocate_lab_atomic() src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 233: > 231: // evacuation are not updated during evacuation. For both young and old regions r, it is essential that all > 232: // PLABs be made parsable at the end of evacuation. This is enabled by retiring all plabs at end of evacuation. > 233: region->concurrent_set_update_watermark(region->top()); There's a race here. Multiple mutators may be updating watermark in parallel. It may be that the mutator who most recently allocated is not the mutator who makes the "most recent" overwrite of set_update_watermark(). I think the better fix is to remove this code. Update refs should just assume that update watermark equals top for any region in the Old gen, and for any region that was in the Collector partition. It may not be easy to know which regions were "in the Collector partition". Maybe we use a Sentinel value for update_watermark on all such regions. Just overwrite update_watermark(nullptr)? And check for this in update-refs? Needs a solution, and solution needs to be documented in code comments. src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 254: > 252: // Step 1: find out the alloc regions which are ready to refresh. > 253: for (uint i = 0; i < _alloc_region_count; i++) { > 254: ShenandoahAllocRegion* alloc_region = &_alloc_regions[i]; We've got the heap lock here. why does this need to be atomic? Comments in the code should make this clear. src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 263: > 261: } > 262: if (ALLOC_PARTITION == ShenandoahFreeSetPartitionId::Mutator) { > 263: if (free_bytes > 0) { We should have counted the entire region's available bytes as allocated when we made this a directly allocatable region. We should not need to further increase bytes allocated here. I would like to see an assert(free_bytes < PLAB::min_size() * HeapWordSize) here. Eventually, I'd want to generalize this code so that we could refresh regions that are not yet ready to be retired. In this case, we would want to unretire the region here. src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 280: > 278: // Step 2: allocate region from FreeSets to fill the alloc regions or satisfy the alloc request. > 279: ShenandoahHeapRegion* reserved[MAX_ALLOC_REGION_COUNT]; > 280: int reserved_regions = _free_set->reserve_alloc_regions(ALLOC_PARTITION, refreshable_alloc_regions, I request we get rid of the min_free_words argument to free_set->reserve_alloc_regions(). See comments in the called function. src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 304: > 302: log_debug(gc, alloc)("%sAllocator: Storing heap region %li to alloc region %i", > 303: _alloc_partition_name, reserved[i]->index(), refreshable[i]->alloc_region_index); > 304: AtomicAccess::store(&refreshable[i]->address, reserved[i]); Should not need to perform AtomicAccess because we hold the heap lock here. src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 316: > 314: HeapWord* ShenandoahAllocator::allocate(ShenandoahAllocRequest &req, bool &in_new_region) { > 315: #ifdef ASSERT > 316: verify(req); Insert a comment above verify(): "Conform that req corresponds to ALLOC_PARTITION" src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 338: > 336: for (uint i = 0; i < _alloc_region_count; i++) { > 337: ShenandoahAllocRegion& alloc_region = _alloc_regions[i]; > 338: ShenandoahHeapRegion* r = AtomicAccess::load(&alloc_region.address); We've got heap lock and at safepoint. Do not need AtomicAccess here. That is more costly than necessary. I prefer to use regular fetch. If you prefer to keep AtomicAccess, please provide a comment in the code explaining why and we will revist. src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 345: > 343: r->unset_active_alloc_region(); > 344: } > 345: AtomicAccess::store(&alloc_region.address, static_cast(nullptr)); Same here. We do not need AtomicAccess. src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 350: > 348: total_free_bytes += free_bytes; > 349: total_regions_to_unretire++; > 350: _free_set->partitions()->unretire_to_partition(r, ALLOC_PARTITION); When we reserved this directly allocatable region, we increased bytes allocated() if the ALLOC_PARTITION was mutator. Here, we need to undo that: if (ALLOC_PARTITION == ShenandoahFreeSetPartitionId::Mutator) { decrease_bytes_allocated(free_bytes); } src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 353: > 351: if (!r->has_allocs()) { > 352: log_debug(gc, alloc)("%sAllocator: Reverting heap region %li to FREE due to no alloc in the region", > 353: _alloc_partition_name, r->index()); This code looks suspect to me. Maybe it works as is only because we are currently doing this only immediately before rebuilding free set. If that's the case, there should be some documentation and maybe even some asserts that confirm it is true. When we release_alloc_regions(), we should be adjusting the range for the associated partitions. The code that most closely resembles this functionality is in ShenandoahFreeSet::move_regions_from_collector_to_mutator(). This is the code that moves collector and old-collector partitions to the mutator partition after evacuation is done. src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 360: > 358: } > 359: } > 360: assert(AtomicAccess::load(&alloc_region.address) == nullptr, "Alloc region is set to nullptr after release"); Do not need AtomicAccess here src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 364: > 362: _free_set->partitions()->decrease_used(ALLOC_PARTITION, total_free_bytes); > 363: _free_set->partitions()->increase_region_counts(ALLOC_PARTITION, total_regions_to_unretire); > 364: accounting_updater._need_update = true; Here is where you know which tallies have been affected by this operation. This is where you should specialize the calls to freeset recompute_total_used() and recompute_total_affiliated(). Either call those from here, or add parameters to your accounting_updater object so that you do not have to overcompute each operation. src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 376: > 374: } > 375: > 376: THREAD_LOCAL uint ShenandoahMutatorAllocator::_alloc_start_index = UINT_MAX; I raised questions about this in a previous review. Have I overlooked your response? What is the tradeoff between declaring this THREAD_LOCAL vs. creating a new field in ShenandoahThreadLocal? I believe we need to use fields of ShenandoahThreadLocal so that we do not incur an overhead on all threads when JVM is not configured for Shenandoah GC. src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 423: > 421: _yield_to_safepoint = false; > 422: } > 423: I suppose ShenandoahCollectorAllocator::randomize_start_index() might be a no-op. On the other hand, it would probably be better to use a random index for ShenandoahCollectorAllocator as well. We don't want to hobble one GC worker more than the others just because its preferred start index happens to hold a retire-ready region. src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 428: > 426: } > 427: > 428: HeapWord* ShenandoahOldCollectorAllocator::allocate(ShenandoahAllocRequest& req, bool& in_new_region) { Confer with William Kemper about this. He is working on a change that may simplify the handling of PLABs, in which case ShenandoahOldCollectorAllocator can behave the same as ShenandoahCollector. src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 436: > 434: // Make sure the old generation has room for either evacuations or promotions before trying to allocate. > 435: auto old_gen = ShenandoahHeap::heap()->old_generation(); > 436: if (req.is_old() && !old_gen->can_allocate(req)) { This test for req.is_old() appears to be unnecessary. The verify(req) assert above requires that req.is_old(). Perhaps the verify() method is too abstract. Add a comment there that says: "Confirm that req.is_old()" src/hotspot/share/gc/shenandoah/shenandoahAllocator.hpp line 56: > 54: virtual uint alloc_start_index() { return 0u; } > 55: > 56: // Attempt to allocate Comment needs to make clear that this is the main entry point for fast-path allocation from a directly allocatable region. This function delegates to slow-path allocation if it is unable to allocate from the directly allocatable regions. Not sure I like the name "attempt_allocation()". All of our allocation routines attempt to allocate and return a sentinel value (nullptr) if the allocation fails. This is no different. Just call it allocate_work(), and clarify that this is the helper routine of allocate() which does the work of allocating from a directly allocatable region without acquiring the heap lock if that is possible, and otherwise does a slow-path allocation which requires acquisition of the heap lock. I see that your comments are trying to say this. But the comments as written are not easy to understand. src/hotspot/share/gc/shenandoah/shenandoahAllocator.hpp line 69: > 67: > 68: // Attempt to allocate in a shared alloc region using atomic operation without holding the heap lock. > 69: // Returns nullptr and overwrites regions_ready_for_refresh with the number of shared alloc regions that are ready Suggest this edit: // Overwrites regions_ready_for_refresh with a lower bound on the number of shared alloc regions that are ready // to be retired during execution of this "do_fast_allocation" function. Returns nullptr if the allocation request could // not be fulfilled after a single traversal of directly allocatable regions. src/hotspot/share/gc/shenandoah/shenandoahAllocator.hpp line 79: > 77: int refresh_alloc_regions(ShenandoahAllocRequest* req = nullptr, bool* in_new_region = nullptr, HeapWord** obj = nullptr); > 78: #ifdef ASSERT > 79: virtual void verify(ShenandoahAllocRequest& req) { } Need a comment to explain what verify does. Is this simply checking to make sure the req is "properly formatted"? I think the intention is to enforce that req affiliation corresponds to ALLOC_PARTITION. Would be good to clarify this in the comment. Do we need this to be virtual? It seems like a single templated implementation would suffice. src/hotspot/share/gc/shenandoah/shenandoahAllocator.hpp line 91: > 89: virtual HeapWord* allocate(ShenandoahAllocRequest& req, bool& in_new_region); > 90: virtual void release_alloc_regions(); > 91: virtual void reserve_alloc_regions(); Need comments on these functions. Clarify pre-conditions and post-conditions. I think the intention is: 1. allocate(): Caller does not hold the heap lock. All allocations by mutator or GC are fulfilled by this function. This function tries to perform a CAS allocation without obtaining the global heap lock. If that fails, it will obtain the global heap lock and do a free-set allocation. As a side effect of doing a free-set allocation, some number of directly allocatable regions may be retired and replaced with new directly allocatable regions. 2. release_alloc_regions(): Caller must hold the heap lock. This causes all directly allocatable regions to be placed into the appropriate ShenandoahFreeSet partition. We do this in preparation for choosing a collection set and/or rebuilding the freeset. 3. reserve_alloc_regions(): Caller must hold the heap lock. This causes us to set aside N regions as directly allocatable by removing these regions from the relevant ShenandoahFreeSet partitions. Explain what happens if there are not N regions available. Clarify: these three function represent the entirety of the "public mutation API" that is exercised by mutators and GC workers as they interact with the free set? (There is another set of functions that could be characterized as the read-only API for obtaining state information about the free set. This provides information such as available memory, allocated bytes since GC start, etc.) src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 3045: > 3043: } > 3044: > 3045: int ShenandoahFreeSet::reserve_alloc_regions(ShenandoahFreeSetPartitionId partition, int regions_to_reserve, size_t min_free_words, ShenandoahHeapRegion** reserved_regions) { I request that we not enforce min_free_words when reserving allocation regions. This defeats the purpose of allocation bias. The objective is to consume fragmented memory early in the GC cycle (when we have more mitigation options if an allocation request ever fails). Note that every region that is in any partition has at least PLAB::min_size() available memory. By requiring that MUTATOR regions have PLAB::max_size() words, we are forcing ourselves to never consume the fragmented memory regions. (Towards the end of GC, when memory is in short supply, we will be unable to find directly allocatable MUTATOR regions. This will force ourselves to obtain the heap lock for every allocation. And these allocations will be inefficient because the remaining memory is highly fragmented.) src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp line 167: > 165: }; > 166: > 167: HeapWord* ShenandoahHeapRegion::allocate_atomic(size_t size, const ShenandoahAllocRequest& req, bool &ready_for_retire) { Suggest we add a fourth arg: int &contended We initialize contended to zero src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp line 187: > 185: return nullptr; > 186: } > 187: } Before iterating, increment contended by 1 src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp line 190: > 188: } > 189: > 190: HeapWord* ShenandoahHeapRegion::allocate_lab_atomic(const ShenandoahAllocRequest& req, size_t &actual_size, bool &ready_for_retire) { Suggest we add a fourth arg: int &contended We initialize contended to zero src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp line 218: > 216: return nullptr; > 217: } > 218: } Before we iterate, we increment contended by 1 src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp line 304: > 302: } > 303: > 304: inline void ShenandoahHeapRegion::concurrent_set_update_watermark(HeapWord* w) { See comment elsewhere in my feedback. I think we may want to use a special sentinel value to denote that watermark for Collector and OldCollector regions. For both of these, there is essentially not watermark value. If we try to set the value to top() from within a CAS-allocating mutator thread, we can end up setting watermark to the not-most-recent value of top(), which would result in misbehavior during update refs. src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 567: > 565: "0 will allow back to back young collections to run during old " \ > 566: "collections.") \ > 567: \ once we resolve the various issues identified in feedback comments, I would be interested in results of experimenting with different values of these two parameters... ------------- Changes requested by kdnilsen (Committer). PR Review: https://git.openjdk.org/jdk/pull/26171#pullrequestreview-3628853514 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2663181721 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2663183357 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2665709301 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2665818148 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2665800328 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2666506691 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2666328083 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2666332994 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2666334248 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2666334844 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2666335529 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2666360404 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2666366038 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2666526965 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2666564758 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2666566961 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2666567671 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2663324871 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2663327493 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2666583027 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2666637281 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2666628228 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2663337002 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2663279917 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2666642051 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2666643974 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2665511567 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2665632758 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2666273440 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2663265276 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2663261232 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2666553882 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2666309782 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2666309888 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2666310835 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2666311617 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2666683738 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2666691665 From kdnilsen at openjdk.org Wed Jan 7 00:36:17 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 7 Jan 2026 00:36:17 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v17] In-Reply-To: <2YVE3uR8bRJ_8qAtXN4WoRmeY0Y9xhzsmKbxqv5oL2M=.2811f02e-35b8-46cf-863a-db4006ca1a78@github.com> References: <2YVE3uR8bRJ_8qAtXN4WoRmeY0Y9xhzsmKbxqv5oL2M=.2811f02e-35b8-46cf-863a-db4006ca1a78@github.com> Message-ID: <4Qs9QlvWQ7gX6RW-rwPVJa-Ndhtx883aImTtiXyCYGk=.1c03a208-d6e5-42bc-bfc3-d1f95e968929@github.com> On Tue, 9 Dec 2025 21:03:21 GMT, Xiaolong Peng wrote: >> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Some comments updates as suggested in PR review > > src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 41: > >> 39: _alloc_region_count(alloc_region_count), _free_set(free_set), _alloc_partition_name(ShenandoahRegionPartitions::partition_name(ALLOC_PARTITION)) { >> 40: if (alloc_region_count > 0) { >> 41: _alloc_regions = PaddedArray::create_unfreeable(alloc_region_count); > > Rethinking about the the PaddedArray used here, we may not really need it. > Allocator has multiple shared alloc regions for CAS, and only refreshes them when all of them run out of usable memory, so _alloc_regions won't be frequently updated, the PaddedArray here should have a negative performance impact. Are you running any experiments (on different hardware configurations) to test your assumptions about this? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2663185400 From kdnilsen at openjdk.org Wed Jan 7 00:36:17 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 7 Jan 2026 00:36:17 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v17] In-Reply-To: <4Qs9QlvWQ7gX6RW-rwPVJa-Ndhtx883aImTtiXyCYGk=.1c03a208-d6e5-42bc-bfc3-d1f95e968929@github.com> References: <2YVE3uR8bRJ_8qAtXN4WoRmeY0Y9xhzsmKbxqv5oL2M=.2811f02e-35b8-46cf-863a-db4006ca1a78@github.com> <4Qs9QlvWQ7gX6RW-rwPVJa-Ndhtx883aImTtiXyCYGk=.1c03a208-d6e5-42bc-bfc3-d1f95e968929@github.com> Message-ID: <6J2xtZ1DLytiwflQ0wbQCtg8tsRAHadSdkZGZllLAxY=.af212eeb-44f7-4955-96ab-d069febe4e0e@github.com> On Tue, 6 Jan 2026 00:33:57 GMT, Kelvin Nilsen wrote: >> src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 41: >> >>> 39: _alloc_region_count(alloc_region_count), _free_set(free_set), _alloc_partition_name(ShenandoahRegionPartitions::partition_name(ALLOC_PARTITION)) { >>> 40: if (alloc_region_count > 0) { >>> 41: _alloc_regions = PaddedArray::create_unfreeable(alloc_region_count); >> >> Rethinking about the the PaddedArray used here, we may not really need it. >> Allocator has multiple shared alloc regions for CAS, and only refreshes them when all of them run out of usable memory, so _alloc_regions won't be frequently updated, the PaddedArray here should have a negative performance impact. > > Are you running any experiments (on different hardware configurations) to test your assumptions about this? Please document the results of any experiments as rationale for the final design. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2666275536 From kdnilsen at openjdk.org Wed Jan 7 00:36:20 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 7 Jan 2026 00:36:20 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v14] In-Reply-To: References: <_mkL6HrCqlS1_qgOmXvEj3vsYgo2idQnbaDdMVFEGUk=.9c71f705-1f96-441e-96d0-c99d3053cffd@github.com> Message-ID: On Wed, 3 Dec 2025 01:09:34 GMT, Xiaolong Peng wrote: >> src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 100: >> >>> 98: HeapWord* ShenandoahAllocator::attempt_allocation(ShenandoahAllocRequest& req, bool& in_new_region) { >>> 99: if (_alloc_region_count == 0u) { >>> 100: ShenandoahHeapLocker locker(ShenandoahHeap::heap()->lock(), _yield_to_safepoint); >> >> Looking for more comments here as well. What does it mean that _alloc_region_count == 0? Does this mean we have not yet initialized the directly allocatable regions (following a particular GC event)? Or does it mean that we have depleted all of the available regions and we are out of memory? In the first case, it seems we would want to replenish our supply of directly allocatable regions while we hold the GC lock. In the second case, it seems there's really no value in even attempting a slow allocation. (If we were unable to refresh our directly allocatable regions, then it will not find allocatable memory even on the other side of the heap lock...) > > I'll add comments on this, _alloc_region_count == 0 means we don't want to use any shared alloc region, it will always allocate with a heap lock, ideally the performance should be same as before, so it always simply find a region with enough space and allocate in the region. Put the comments describing functions in the .hpp file, where they are currently. But we need to enhance those comments. >> src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 158: >> >>> 156: if (r != nullptr) { >>> 157: bool ready_for_retire = false; >>> 158: obj = atomic_allocate_in(r, false, req, in_new_region, ready_for_retire); >> >> Not sure why we use atomic_allocate_in() here. We hold the heap lock so we don't need to use atomic operations. >> We should clarify with comments. > > It is not really necessary to `atomic_allocate_in` here, but I wanted reuse some of the codes in atomic_allocate_in, we can discuss this later, I can change it back to non-atomic version. Would prefer not to use the atomic_allocate code here. If you want to reuse code, maybe you can refactor allocate_in with an template argument. I notice that this PR makes lots of ShenandoahHeapRegion variables volatile: _age, _youth, _top, _tlab_allocs, _gclab_allocs, _plab_allocs. That will cause less efficient code to be generated whenever we are accessing this data from "behind" the GC heap lock, which should be rare, I guess. I raised some concerns/issues about the race that happens when we move a region from the directly-allocatable set into the global-heap-lock-protected ShenandoahFreeSet partition. Here's the scenario that I'm concerned about: 1. A mutator obtains pointer to directly allocatable region R 2. A second mutator performs a refresh, moving region R out of directly allocatable set (for whatever reason) 3. Region R is now eligible to satisfy allocations from behind the global heap lock 4. Some third mutator thread acquires the heap lock and fetches top for region $ 5. The first mutator performs its allocation within the same region R, not recognizing a CAS conflict 6. This third mutator allocates from region R at top, without using CAS. So both mutators think they own the same object I think this is not a problem if the "only" reason at step 2 above that we move region R out of directly allocatable set is because R is ready to be retired. In that case, there will be no subsequent heap-locked allocations in regions R. However, I anticipate the day in not-too-distant future when we will want to refresh regions even when they are not ready to be retired. Specifically, as we move rebuild-freeset out of safepoints, we will want to refresh regions before we acquire heap-lock to do rebuild, with the goal of making sure there is sufficient directly allocatable memory available that no mutator will be stalled because it needs to allocate during the time that the heap remains locked for the rebuild operation. So I suppose that if we always use atomic_allocate() even for allocations that happen while holding the heap lock, we won't have this problem. If we decide to keep this architecture, there should be comments explaining why we are doing it this way. (I am not real happy that we have to "pay the cost" of CAS in addition to paying the cost of global heap lock, but I think these allocations should be very rare. It seems this would only come up if, for example, a mutator wanted to allocate an object that is 1/2 the heap region size, and none of the directly allocatable regions have that much available memory.) My original proposal was to have a volatile_top which is used by CAS allocation and a nonvolatile_top that is used by heap-lock allocation. When we make a region directly allocatable, we copy its nonvolatile_top to the volatile_top. When we take a directly allocatable region and move it into the heap-locked freeset, we use CAS to set its volatile_top to end before we place the region into the freeset partition, assigning to nonvolatile_top the value held in volatile_top before the CAS operation. Whatever solution is used for this needs to be documented in the code. Feel free to copy and paste from this github comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2665714073 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2666236427 From kdnilsen at openjdk.org Wed Jan 7 00:36:21 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 7 Jan 2026 00:36:21 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v14] In-Reply-To: References: <_mkL6HrCqlS1_qgOmXvEj3vsYgo2idQnbaDdMVFEGUk=.9c71f705-1f96-441e-96d0-c99d3053cffd@github.com> Message-ID: <4BVpGlI0mK12KTI6b6l1UoH26vEwytUP1vlYX1Z-UJQ=.374ea1dd-38d7-46ea-b6a5-a99453171059@github.com> On Wed, 3 Dec 2025 01:15:03 GMT, Xiaolong Peng wrote: >> It is not an error, before calling into attempt_allocation_slow, it already called attempt_allocation_in_alloc_regions once and failed to allocate, slow path is always with heap lock. >> >> After taking the lock, we should try the attempt_allocation_in_alloc_regions right away, because other mutator thread may have refreshed the alloc regions while holding the lock. > > accounting_update is required for slow path, but you are right, it can be moved to somewhere later, e.g. line 128. My mistake on first read here. I see now that we only come into this function if fast-allocation failed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2665689002 From kdnilsen at openjdk.org Wed Jan 7 00:36:21 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 7 Jan 2026 00:36:21 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v14] In-Reply-To: <4BVpGlI0mK12KTI6b6l1UoH26vEwytUP1vlYX1Z-UJQ=.374ea1dd-38d7-46ea-b6a5-a99453171059@github.com> References: <_mkL6HrCqlS1_qgOmXvEj3vsYgo2idQnbaDdMVFEGUk=.9c71f705-1f96-441e-96d0-c99d3053cffd@github.com> <4BVpGlI0mK12KTI6b6l1UoH26vEwytUP1vlYX1Z-UJQ=.374ea1dd-38d7-46ea-b6a5-a99453171059@github.com> Message-ID: On Tue, 6 Jan 2026 17:28:27 GMT, Kelvin Nilsen wrote: >> accounting_update is required for slow path, but you are right, it can be moved to somewhere later, e.g. line 128. > > My mistake on first read here. I see now that we only come into this function if fast-allocation failed. But part of the reason for my confusion is that you are trying to do fast allocations while holding the heap lock! The reason we came into attempt_allocation_slow() is because we already failed to attempt_allocation_in_alloc_regions(). There's no need to call this a second time. You should have remembered regions_ready_for_refresh and passed this in as an argument to attempt_allocation_slow(). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2665698471 From kdnilsen at openjdk.org Wed Jan 7 00:36:22 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 7 Jan 2026 00:36:22 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v14] In-Reply-To: References: <_mkL6HrCqlS1_qgOmXvEj3vsYgo2idQnbaDdMVFEGUk=.9c71f705-1f96-441e-96d0-c99d3053cffd@github.com> <4BVpGlI0mK12KTI6b6l1UoH26vEwytUP1vlYX1Z-UJQ=.374ea1dd-38d7-46ea-b6a5-a99453171059@github.com> Message-ID: <0IfaybNazrHlrdcGhk-0080a-KqpdUwN_WXpYVe_fjc=.d68c5098-02b7-4a91-8ad3-4e8b310cba0b@github.com> On Tue, 6 Jan 2026 17:31:57 GMT, Kelvin Nilsen wrote: >> My mistake on first read here. I see now that we only come into this function if fast-allocation failed. > > But part of the reason for my confusion is that you are trying to do fast allocations while holding the heap lock! > > The reason we came into attempt_allocation_slow() is because we already failed to attempt_allocation_in_alloc_regions(). There's no need to call this a second time. You should have remembered regions_ready_for_refresh and passed this in as an argument to attempt_allocation_slow(). I'm not concerned that the count of regions_ready_for_refresh might be stale. If this count is getting incremented "during" our allocation, we will see this result soon enough. If multiple mutators fail fast-path allocation simultaneously, they will each acquire heap lock either way (existing implementation vs. new implementation that does not retry the allocation). Acquiring the heap lock is the "expensive" operation. If the first one refreshes allocation regions, then subsequent invocations will not find any regions to be refreshed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2665704698 From tschatzl at openjdk.org Wed Jan 7 06:32:47 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 7 Jan 2026 06:32:47 GMT Subject: RFR: 8373429: gc/g1/TestCodeCacheUnloadDuringConcCycle fails on various platforms In-Reply-To: References: <8iV1ky2iG2BXmnRPupEyw_pxc_RtehJgN28ZaihGsCY=.d2e8ca48-722a-4f08-9952-46824b8462a2@github.com> Message-ID: On Mon, 15 Dec 2025 15:52:27 GMT, Martin Doerr wrote: >> Hi all, >> >> this is hopefully the last fix attempt for the [gc/g1/TestCodeCacheUnloadDuringConcCycle.java](https://github.com/openjdk/jdk/pull/28822/files#diff-6ce99d53ba7ea02f2c7f0e878f937acecbd64f3c9a6edebcef79d10983cf3c28) test that proves to be fairly unstable across some platforms. >> >> The change adds more classes/code to be compiled during the test to fill the code cache faster, and more consistently exercise the code cachec loading. >> >> I also opted to revert the change from https://bugs.openjdk.org/browse/JDK-8372860 because it (unsuccessfully) tried the same method. There is no need to prolong the test any more. >> >> Testing: gha >> >> Thanks, >> Thomas > > This looks good. I just verified that this fixes the failures on AIX. Thanks @TheRealMDoerr @MBaesken @snazarkin for your testing + reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28822#issuecomment-3717501720 From tschatzl at openjdk.org Wed Jan 7 06:32:48 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 7 Jan 2026 06:32:48 GMT Subject: Integrated: 8373429: gc/g1/TestCodeCacheUnloadDuringConcCycle fails on various platforms In-Reply-To: <8iV1ky2iG2BXmnRPupEyw_pxc_RtehJgN28ZaihGsCY=.d2e8ca48-722a-4f08-9952-46824b8462a2@github.com> References: <8iV1ky2iG2BXmnRPupEyw_pxc_RtehJgN28ZaihGsCY=.d2e8ca48-722a-4f08-9952-46824b8462a2@github.com> Message-ID: On Mon, 15 Dec 2025 11:34:55 GMT, Thomas Schatzl wrote: > Hi all, > > this is hopefully the last fix attempt for the [gc/g1/TestCodeCacheUnloadDuringConcCycle.java](https://github.com/openjdk/jdk/pull/28822/files#diff-6ce99d53ba7ea02f2c7f0e878f937acecbd64f3c9a6edebcef79d10983cf3c28) test that proves to be fairly unstable across some platforms. > > The change adds more classes/code to be compiled during the test to fill the code cache faster, and more consistently exercise the code cachec loading. > > I also opted to revert the change from https://bugs.openjdk.org/browse/JDK-8372860 because it (unsuccessfully) tried the same method. There is no need to prolong the test any more. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 5c6947f7 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/5c6947f736568413d53d5a00de2e865f86e637c4 Stats: 5 lines in 1 file changed: 2 ins; 1 del; 2 mod 8373429: gc/g1/TestCodeCacheUnloadDuringConcCycle fails on various platforms Reviewed-by: mbaesken, mdoerr ------------- PR: https://git.openjdk.org/jdk/pull/28822 From tschatzl at openjdk.org Wed Jan 7 08:43:54 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 7 Jan 2026 08:43:54 GMT Subject: RFR: 8373695: G1: Using a value near integer max for ActiveProcessorCount causes fatal crash [v3] In-Reply-To: References: Message-ID: <8d_vDxs7hDMsHIK_w-iJ7kJoLpVty_vnpRH7vvWIo8w=.4435d57f-24e8-4d43-b46a-841006c34ad0@github.com> On Mon, 5 Jan 2026 09:25:18 GMT, Jonas Norlinder wrote: >> G1ConcRefinementThreads default value depends on ParallelGCThreads which in turn may depend on ActiveProcessorCount. These have different ranges that are valid. Patch will ensure argument setup code never try to assign a value larger than what G1ConcRefinementThreads expects. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Minimize changeset Changes requested by tschatzl (Reviewer). src/hotspot/share/gc/g1/g1Arguments.cpp line 194: > 192: } else if (FLAG_IS_DEFAULT(G1ConcRefinementThreads)) { > 193: constexpr uint MaxG1ConcRefinementThreads = (max_jint - 1) / wordSize; // Derived from flag declaration > 194: FLAG_SET_ERGO(G1ConcRefinementThreads, MIN2(ParallelGCThreads, MaxG1ConcRefinementThreads)); Maybe use the flags API to programmatically get the maximum instead of hardcoding the value, something like this: const JVMTypedFlagLimit* conc_refinement_threads_limits = JVMFlagLimit::get_range_at(FLAG_MEMBER_ENUM(G1ConcRefinementThreads))->cast(); FLAG_SET_ERGO(G1ConcRefinementThreads, MIN2(ParallelGCThreads, conc_refinement_threads_limits->max())); ------------- PR Review: https://git.openjdk.org/jdk/pull/28831#pullrequestreview-3633865050 PR Review Comment: https://git.openjdk.org/jdk/pull/28831#discussion_r2667540751 From lkorinth at openjdk.org Wed Jan 7 10:02:41 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 7 Jan 2026 10:02:41 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v2] In-Reply-To: References: Message-ID: > This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. > > It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. > > This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. > > I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. Leo Korinth has updated the pull request incrementally with 561 additional commits since the last revision: - Merge branch 'master' into _8367993 - 8366058: Outdated comment in WinCAPISeedGenerator Reviewed-by: mullan - 8357258: x86: Improve receiver type profiling reliability Reviewed-by: kvn, vlivanov - 8373704: Improve "SocketException: Protocol family unavailable" message Reviewed-by: lucy, jpai - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently Reviewed-by: jiefu, jbhateja, erfang, qamai - 8343809: Add requires tag to mark tests that are incompatible with exploded image Reviewed-by: alanb, dholmes - 8374465: Spurious dot in documentation for JVMTI ClassLoad Reviewed-by: kbarrett - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket Reviewed-by: djelinski, mpowers, ascarpino - 8374444: Fix simple -Wzero-as-null-pointer-constant warnings Reviewed-by: aboldtch - 8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the ?Nothing? menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test Reviewed-by: serb, aivanov, dnguyen - ... and 551 more: https://git.openjdk.org/jdk/compare/b907b295...0ece3767 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28723/files - new: https://git.openjdk.org/jdk/pull/28723/files/b907b295..0ece3767 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28723&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28723&range=00-01 Stats: 130212 lines in 3962 files changed: 83750 ins; 29714 del; 16748 mod Patch: https://git.openjdk.org/jdk/pull/28723.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28723/head:pull/28723 PR: https://git.openjdk.org/jdk/pull/28723 From lkorinth at openjdk.org Wed Jan 7 12:35:42 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 7 Jan 2026 12:35:42 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 10:02:41 GMT, Leo Korinth wrote: >> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. >> >> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. >> >> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. >> >> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. > > Leo Korinth has updated the pull request incrementally with 561 additional commits since the last revision: > > - Merge branch 'master' into _8367993 > - 8366058: Outdated comment in WinCAPISeedGenerator > > Reviewed-by: mullan > - 8357258: x86: Improve receiver type profiling reliability > > Reviewed-by: kvn, vlivanov > - 8373704: Improve "SocketException: Protocol family unavailable" message > > Reviewed-by: lucy, jpai > - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently > > Reviewed-by: jiefu, jbhateja, erfang, qamai > - 8343809: Add requires tag to mark tests that are incompatible with exploded image > > Reviewed-by: alanb, dholmes > - 8374465: Spurious dot in documentation for JVMTI ClassLoad > > Reviewed-by: kbarrett > - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket > > Reviewed-by: djelinski, mpowers, ascarpino > - 8374444: Fix simple -Wzero-as-null-pointer-constant warnings > > Reviewed-by: aboldtch > - 8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the ?Nothing? menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test > > Reviewed-by: serb, aivanov, dnguyen > - ... and 551 more: https://git.openjdk.org/jdk/compare/b907b295...0ece3767 I will redo the merge, I have done something strange. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28723#issuecomment-3718660595 From lkorinth at openjdk.org Wed Jan 7 12:52:25 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 7 Jan 2026 12:52:25 GMT Subject: RFR: 8373253: Re-work InjectGCWorkerCreationFailure for future changes [v3] In-Reply-To: <78ejbDKfHkTR88XnHC2t975-zof6vMjdM_M_rTyB0pk=.d5c9798a-b1ca-4299-af35-2caaad2f8106@github.com> References: <78ejbDKfHkTR88XnHC2t975-zof6vMjdM_M_rTyB0pk=.d5c9798a-b1ca-4299-af35-2caaad2f8106@github.com> Message-ID: > This PR slightly changes when we may `InjectGCWorkerCreationFailure`. At the moment we wait until `is_init_completed()`. I am changing this to instead be after `_created_workers > 0`. The reason is that we might in the future, https://bugs.openjdk.org/browse/JDK-8367993, create even more threads "on demand", and if so, we would fail VM creation if we inject worker creation failures after the VM is initiated but before we have created any of the worker threads. > > This change should not change the current behaviour. But help future improvements. > > I have tested this on `test/hotspot/jtreg/gc/stress/gcold/TestGCOldWithG1.java`, the only place where this flag is tested to my knowledge. Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into _8373253 - Fixup after comment from Ivan. - 8373253: Re-work InjectGCWorkerCreationFailure for future changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28719/files - new: https://git.openjdk.org/jdk/pull/28719/files/2aa8aa4b..11649b67 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28719&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28719&range=01-02 Stats: 130210 lines in 3962 files changed: 83748 ins; 29714 del; 16748 mod Patch: https://git.openjdk.org/jdk/pull/28719.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28719/head:pull/28719 PR: https://git.openjdk.org/jdk/pull/28719 From lkorinth at openjdk.org Wed Jan 7 12:58:43 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 7 Jan 2026 12:58:43 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v3] In-Reply-To: References: Message-ID: > This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. > > It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. > > This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. > > I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 564 commits: - Merge branch '8373253' into 8367993 - Merge branch 'master' into _8373253 - Merge branch 'master' into _8367993 - 8366058: Outdated comment in WinCAPISeedGenerator Reviewed-by: mullan - 8357258: x86: Improve receiver type profiling reliability Reviewed-by: kvn, vlivanov - 8373704: Improve "SocketException: Protocol family unavailable" message Reviewed-by: lucy, jpai - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently Reviewed-by: jiefu, jbhateja, erfang, qamai - 8343809: Add requires tag to mark tests that are incompatible with exploded image Reviewed-by: alanb, dholmes - 8374465: Spurious dot in documentation for JVMTI ClassLoad Reviewed-by: kbarrett - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket Reviewed-by: djelinski, mpowers, ascarpino - ... and 554 more: https://git.openjdk.org/jdk/compare/2aa8aa4b...28ccbb68 ------------- Changes: https://git.openjdk.org/jdk/pull/28723/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28723&range=02 Stats: 130308 lines in 3967 files changed: 83803 ins; 29735 del; 16770 mod Patch: https://git.openjdk.org/jdk/pull/28723.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28723/head:pull/28723 PR: https://git.openjdk.org/jdk/pull/28723 From jnorlinder at openjdk.org Wed Jan 7 13:13:20 2026 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Wed, 7 Jan 2026 13:13:20 GMT Subject: RFR: 8373695: G1: Using a value near integer max for ActiveProcessorCount causes fatal crash [v4] In-Reply-To: References: Message-ID: <-3BqMYvPOr3yXj3Txfl7j4bM2vbBwVSes4OUaK4lYik=.f93f53ed-03de-4299-a800-033b436214bc@github.com> > G1ConcRefinementThreads default value depends on ParallelGCThreads which in turn may depend on ActiveProcessorCount. These have different ranges that are valid. Patch will ensure argument setup code never try to assign a value larger than what G1ConcRefinementThreads expects. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Use API over hardcoded values ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28831/files - new: https://git.openjdk.org/jdk/pull/28831/files/aee11b28..62f78a13 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28831&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28831&range=02-03 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28831.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28831/head:pull/28831 PR: https://git.openjdk.org/jdk/pull/28831 From kdnilsen at openjdk.org Wed Jan 7 14:54:07 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 7 Jan 2026 14:54:07 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v20] In-Reply-To: References: <797j9fNWUlV491wWKbFMfthH99o3A5493T0Pcdn_zdc=.417c13b0-8618-4402-aafa-3d86c45c8ff6@github.com> Message-ID: On Wed, 7 Jan 2026 00:04:41 GMT, Kelvin Nilsen wrote: >> Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 265 commits: >> >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - Fix build error after merging from tip >> - Merge branch 'master' into cas-alloc-1 >> - Merge branch 'master' into cas-alloc-1 >> - Some comments updates as suggested in PR review >> - Fix build failure after merge >> - Expend promoted from ShenandoahOldCollectorAllocator >> - Merge branch 'master' into cas-alloc-1 >> - Address PR comments >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - ... and 255 more: https://git.openjdk.org/jdk/compare/de81d389...cf13b7b5 > > src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 428: > >> 426: } >> 427: >> 428: HeapWord* ShenandoahOldCollectorAllocator::allocate(ShenandoahAllocRequest& req, bool& in_new_region) { > > Confer with William Kemper about this. He is working on a change that may simplify the handling of PLABs, in which case ShenandoahOldCollectorAllocator can behave the same as ShenandoahCollector. Alternatively, I don't think it would be too terribly difficult to implement try_allocate_aligned() function to support fast (CAS) allocation of aligned PLABs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2668774560 From kdnilsen at openjdk.org Wed Jan 7 14:58:37 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 7 Jan 2026 14:58:37 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v20] In-Reply-To: References: <797j9fNWUlV491wWKbFMfthH99o3A5493T0Pcdn_zdc=.417c13b0-8618-4402-aafa-3d86c45c8ff6@github.com> Message-ID: On Tue, 6 Jan 2026 18:13:09 GMT, Kelvin Nilsen wrote: >> Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 265 commits: >> >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - Fix build error after merging from tip >> - Merge branch 'master' into cas-alloc-1 >> - Merge branch 'master' into cas-alloc-1 >> - Some comments updates as suggested in PR review >> - Fix build failure after merge >> - Expend promoted from ShenandoahOldCollectorAllocator >> - Merge branch 'master' into cas-alloc-1 >> - Address PR comments >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - ... and 255 more: https://git.openjdk.org/jdk/compare/de81d389...cf13b7b5 > > src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 114: > >> 112: HeapWord* obj = attempt_allocation_in_alloc_regions(req, in_new_region, alloc_start_index(), dummy); >> 113: if (obj != nullptr) { >> 114: return obj; > > Even in the case that we successfully fill our allocation request, if regions_ready_for_refresh is greater than some percentage of _alloc_region_count (e.g. > _alloc_region_count / 4), then we should grab the heap lock and refresh_alloc_regions() here. Otherwise, we will gradually degrade the number of directly_allocatable_regions until we are down to one before we refresh any of them. After further thought, am thinking the threshold for refresh_alloc_regions() might be if (regions_ready_for_refresh >= _alloc_region_count / 2). That would reduce the number of slow paths through the allocator. If we can re-randomize the thread-local start indexes when their original start index hits a retire-able region, this might work ok. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2668794471 From tschatzl at openjdk.org Wed Jan 7 15:35:33 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 7 Jan 2026 15:35:33 GMT Subject: RFR: 8373253: Re-work InjectGCWorkerCreationFailure for future changes [v3] In-Reply-To: References: <78ejbDKfHkTR88XnHC2t975-zof6vMjdM_M_rTyB0pk=.d5c9798a-b1ca-4299-af35-2caaad2f8106@github.com> Message-ID: On Wed, 7 Jan 2026 12:52:25 GMT, Leo Korinth wrote: >> This PR slightly changes when we may `InjectGCWorkerCreationFailure`. At the moment we wait until `is_init_completed()`. I am changing this to instead be after `_created_workers > 0`. The reason is that we might in the future, https://bugs.openjdk.org/browse/JDK-8367993, create even more threads "on demand", and if so, we would fail VM creation if we inject worker creation failures after the VM is initiated but before we have created any of the worker threads. >> >> This change should not change the current behaviour. But help future improvements. >> >> I have tested this on `test/hotspot/jtreg/gc/stress/gcold/TestGCOldWithG1.java`, the only place where this flag is tested to my knowledge. > > Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into _8373253 > - Fixup after comment from Ivan. > - 8373253: Re-work InjectGCWorkerCreationFailure for future changes Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28719#pullrequestreview-3635454886 From tschatzl at openjdk.org Wed Jan 7 15:37:08 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 7 Jan 2026 15:37:08 GMT Subject: RFR: 8373695: G1: Using a value near integer max for ActiveProcessorCount causes fatal crash [v4] In-Reply-To: <-3BqMYvPOr3yXj3Txfl7j4bM2vbBwVSes4OUaK4lYik=.f93f53ed-03de-4299-a800-033b436214bc@github.com> References: <-3BqMYvPOr3yXj3Txfl7j4bM2vbBwVSes4OUaK4lYik=.f93f53ed-03de-4299-a800-033b436214bc@github.com> Message-ID: On Wed, 7 Jan 2026 13:13:20 GMT, Jonas Norlinder wrote: >> G1ConcRefinementThreads default value depends on ParallelGCThreads which in turn may depend on ActiveProcessorCount. These have different ranges that are valid. Patch will ensure argument setup code never try to assign a value larger than what G1ConcRefinementThreads expects. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Use API over hardcoded values Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28831#pullrequestreview-3635459293 From kdnilsen at openjdk.org Wed Jan 7 16:37:22 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 7 Jan 2026 16:37:22 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v22] In-Reply-To: References: Message-ID: > Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). > > This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. > > The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. > > ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) > > With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. > > ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) > > At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. > > ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) > > The command line for these comparisons follows: > > > ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jdk/bin/java \ > -XX:+Unlock... Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 76 commits: - Remove note to self - Slight expansion of promo reserve - Remove bad assertion - Merge remote-tracking branch 'jdk/master' into share-collector-reserves-restart-gh - Merge remote-tracking branch 'jdk/master' into share-collector-reserves - fix unsigned arithmetic underflow - Attempt fix for assertion failures - Merge remote-tracking branch 'jdk/master' into share-collector-reserves - Merge remote-tracking branch 'jdk/master' into share-collector-reserves - Remove debug instrumentation - ... and 66 more: https://git.openjdk.org/jdk/compare/2d092840...d0a692ff ------------- Changes: https://git.openjdk.org/jdk/pull/25357/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=21 Stats: 1457 lines in 29 files changed: 777 ins; 286 del; 394 mod Patch: https://git.openjdk.org/jdk/pull/25357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25357/head:pull/25357 PR: https://git.openjdk.org/jdk/pull/25357 From kdnilsen at openjdk.org Wed Jan 7 17:38:09 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 7 Jan 2026 17:38:09 GMT Subject: RFR: 8373714: Shenandoah: Register heuristic penalties following a degenerated GC [v2] In-Reply-To: References: <_QnV10ychv2AQj3TN6gch1p8B-OGMTsN6FTcbBJSn9U=.cba48ddd-cb45-4e25-9633-5ef7e9cfa4ea@github.com> Message-ID: On Tue, 6 Jan 2026 20:46:23 GMT, William Kemper wrote: >> May be let the heuristics (or the policy) track progress as well, and inform the actuator (i.e. op degenerated) whether it should upgrade to a full gc. It almost feels like heuristics and policy and actuator are leaking abstractions. It feels like heuristics keep track of the model parameters and learn from sensors, and the policy consults a specific heuristic to inform actuator (i.e. actions). >> >> By that model, you'd have the actuator sending the sensor information to the heuristics and asking the policy (or the heuristics, if you conflate heuristics and policy) to decide which step to take next. It would seem that evaluation of the notion of progress then moves to the policy too. > > @kdnilsen , what do you think about having a single method called `record_degenerated`. It's a matter of fact without conflating progress and success. I don't like having duplicated code between `record_success_degenerated` and `record_unsuccessful_degenerated`. I understand what @ysramakrishna is saying, and I agree, but I think a change like that is beyond the scope of this PR. I like this idea. I'll try to make that work without breaking anything... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28834#discussion_r2669431913 From kdnilsen at openjdk.org Wed Jan 7 18:19:35 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 7 Jan 2026 18:19:35 GMT Subject: RFR: 8373714: Shenandoah: Register heuristic penalties following a degenerated GC [v6] In-Reply-To: References: Message-ID: > Add a triggering penalty when we execute degenerated GC cycle. Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: - Combine successful and unsuccessful into single method: report_degenerated() - remove gratuitous blank line - Merge remote-tracking branch 'jdk/master' into add-degen-penalty - touch file to force tests - Merge remote-tracking branch 'jdk/master' into add-degen-penalty - Merge remote-tracking branch 'jdk/master' into add-degen-penalty - refactor for reviewer requests - remove redundant code - Increase heuristic penalties following degenerated GC ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28834/files - new: https://git.openjdk.org/jdk/pull/28834/files/7b0efb3e..888f92a4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28834&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28834&range=04-05 Stats: 20369 lines in 1812 files changed: 4196 ins; 2531 del; 13642 mod Patch: https://git.openjdk.org/jdk/pull/28834.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28834/head:pull/28834 PR: https://git.openjdk.org/jdk/pull/28834 From kdnilsen at openjdk.org Wed Jan 7 19:08:27 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 7 Jan 2026 19:08:27 GMT Subject: RFR: 8373714: Shenandoah: Register heuristic penalties following a degenerated GC [v2] In-Reply-To: References: <_QnV10ychv2AQj3TN6gch1p8B-OGMTsN6FTcbBJSn9U=.cba48ddd-cb45-4e25-9633-5ef7e9cfa4ea@github.com> Message-ID: On Wed, 7 Jan 2026 17:35:49 GMT, Kelvin Nilsen wrote: >> @kdnilsen , what do you think about having a single method called `record_degenerated`. It's a matter of fact without conflating progress and success. I don't like having duplicated code between `record_success_degenerated` and `record_unsuccessful_degenerated`. I understand what @ysramakrishna is saying, and I agree, but I think a change like that is beyond the scope of this PR. > > I like this idea. I'll try to make that work without breaking anything... I've committed this change and it is running through the CI pipeline. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28834#discussion_r2669739585 From wkemper at openjdk.org Wed Jan 7 19:20:29 2026 From: wkemper at openjdk.org (William Kemper) Date: Wed, 7 Jan 2026 19:20:29 GMT Subject: RFR: 8373714: Shenandoah: Register heuristic penalties following a degenerated GC [v6] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 18:19:35 GMT, Kelvin Nilsen wrote: >> Add a triggering penalty when we execute degenerated GC cycle. > > Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: > > - Combine successful and unsuccessful into single method: report_degenerated() > - remove gratuitous blank line > - Merge remote-tracking branch 'jdk/master' into add-degen-penalty > - touch file to force tests > - Merge remote-tracking branch 'jdk/master' into add-degen-penalty > - Merge remote-tracking branch 'jdk/master' into add-degen-penalty > - refactor for reviewer requests > - remove redundant code > - Increase heuristic penalties following degenerated GC Looks good to integrate, assuming testing pipelines pass. ------------- Marked as reviewed by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28834#pullrequestreview-3636442278 From xpeng at openjdk.org Wed Jan 7 19:41:07 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 7 Jan 2026 19:41:07 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v14] In-Reply-To: References: <_mkL6HrCqlS1_qgOmXvEj3vsYgo2idQnbaDdMVFEGUk=.9c71f705-1f96-441e-96d0-c99d3053cffd@github.com> Message-ID: On Tue, 6 Jan 2026 20:43:39 GMT, Kelvin Nilsen wrote: >> It is not really necessary to `atomic_allocate_in` here, but I wanted reuse some of the codes in atomic_allocate_in, we can discuss this later, I can change it back to non-atomic version. > > Would prefer not to use the atomic_allocate code here. If you want to reuse code, maybe you can refactor allocate_in with an template argument. > > I notice that this PR makes lots of ShenandoahHeapRegion variables volatile: _age, _youth, _top, _tlab_allocs, _gclab_allocs, _plab_allocs. That will cause less efficient code to be generated whenever we are accessing this data from "behind" the GC heap lock, which should be rare, I guess. > > I raised some concerns/issues about the race that happens when we move a region from the directly-allocatable set into the global-heap-lock-protected ShenandoahFreeSet partition. > > Here's the scenario that I'm concerned about: > > 1. A mutator obtains pointer to directly allocatable region R > 2. A second mutator performs a refresh, moving region R out of directly allocatable set (for whatever reason) > 3. Region R is now eligible to satisfy allocations from behind the global heap lock > 4. Some third mutator thread acquires the heap lock and fetches top for region $ > 5. The first mutator performs its allocation within the same region R, not recognizing a CAS conflict > 6. This third mutator allocates from region R at top, without using CAS. So both mutators think they own the same object > > I think this is not a problem if the "only" reason at step 2 above that we move region R out of directly allocatable set is because R is ready to be retired. In that case, there will be no subsequent heap-locked allocations in regions R. However, I anticipate the day in not-too-distant future when we will want to refresh regions even when they are not ready to be retired. Specifically, as we move rebuild-freeset out of safepoints, we will want to refresh regions before we acquire heap-lock to do rebuild, with the goal of making sure there is sufficient directly allocatable memory available that no mutator will be stalled because it needs to allocate during the time that the heap remains locked for the rebuild operation. > > So I suppose that if we always use atomic_allocate() even for allocations that happen while holding the heap lock, we won't have this problem. If we decide to keep this architecture, there should be comments explaining why we are doing it this way. (I am not real happy that we have to "pay the cost" of CAS in addition to paying the cost of global heap lock, but I think these allocations should be very rare. It seems this would only come up if, for example, a mutator wanted to allocate an object that is 1/2 the heap regio... I will update the PR and not use atomic version here, and also another place in refresh_alloc_regions. Having volatile_top and nonvolatile_top seems necessary, it will make the code more complicated w/o much performance benefits, with CAS allocator, most of alloc request will be handled by the atomic code path, in only few cases we need non-atomic allocation: * After reserving alloc regions from free set before storing to alloc region, it performs obj allocation if the alloc request has not been satisfied yet. * After trying atomic allocation, refresh alloc regions fails, it will try to find a region in free set with enough space for the allocation request. Yes, all the _age, _youth, _top, _tlab_allocs, _gclab_allocs, _plab_allocs are volatile now, out of these fields, I believe I can maybe remove volatile for _age and _youth(?), but the update of the rest must be atomic because mutators will increase the values in the CAS allocation code path w/o heap lock. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2669831418 From kdnilsen at openjdk.org Wed Jan 7 19:58:58 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 7 Jan 2026 19:58:58 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v23] In-Reply-To: References: Message-ID: > Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). > > This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. > > The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. > > ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) > > With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. > > ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) > > At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. > > ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) > > The command line for these comparisons follows: > > > ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jdk/bin/java \ > -XX:+Unlock... Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 78 commits: - Merge remote-tracking branch 'jdk/master' into share-collector-reserves - Fix whitespace and comment - Remove note to self - Slight expansion of promo reserve - Remove bad assertion - Merge remote-tracking branch 'jdk/master' into share-collector-reserves-restart-gh - Merge remote-tracking branch 'jdk/master' into share-collector-reserves - fix unsigned arithmetic underflow - Attempt fix for assertion failures - Merge remote-tracking branch 'jdk/master' into share-collector-reserves - ... and 68 more: https://git.openjdk.org/jdk/compare/dd20e915...9aa4a3e2 ------------- Changes: https://git.openjdk.org/jdk/pull/25357/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=22 Stats: 1456 lines in 29 files changed: 776 ins; 286 del; 394 mod Patch: https://git.openjdk.org/jdk/pull/25357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25357/head:pull/25357 PR: https://git.openjdk.org/jdk/pull/25357 From kdnilsen at openjdk.org Wed Jan 7 20:32:30 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 7 Jan 2026 20:32:30 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v3] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 21:11:42 GMT, William Kemper wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove develop/debug instrumentation > > src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 1218: > >> 1216: } else { >> 1217: heap->heuristics()->start_idle_span(); >> 1218: } > > Suggestion: > > _generation->heuristics()->start_idle_span(); Very nice. Thanks. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29039#discussion_r2669982434 From kdnilsen at openjdk.org Wed Jan 7 20:38:39 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 7 Jan 2026 20:38:39 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v3] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 22:24:44 GMT, William Kemper wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove develop/debug instrumentation > > src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 179: > >> 177: " after adjusting for spike_headroom: %zu%s" >> 178: " and penalties: %zu%s", _is_generational? _space_info->name(): "Global", >> 179: byte_size_in_proper_unit(mutator_available), proper_unit_for_byte_size(mutator_available), > > Can we use the `PROPERFMT/PROPERFMTARGS` macros for these? I find they really improve readability. Agreed. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29039#discussion_r2669994974 From kdnilsen at openjdk.org Wed Jan 7 20:49:04 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 7 Jan 2026 20:49:04 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v3] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 22:25:46 GMT, William Kemper wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove develop/debug instrumentation > > src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 199: > >> 197: >> 198: // There is no headroom during evacuation and update refs. This information is not used to trigger the next GC. >> 199: // Rather, it is made available to support throttling of allocations during GC. > > Is that true? or is allocation throttling part of another change? Sorry. Not true. Fixing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29039#discussion_r2670019293 From kdnilsen at openjdk.org Wed Jan 7 20:56:51 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 7 Jan 2026 20:56:51 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v4] In-Reply-To: References: Message-ID: > After studying large numbers of GC logs with degenerated cycles that have resulted from "late" triggers, we propose the following general improvements: > > 1. Track trends in GC times rather than always using the average GC time plus standard deviation. In many situations, GC times trend upward due to, for example, increasing amounts of live data that must be marked as a workload builds up its working set of memory. > 2. Sample allocation rates more frequently than once every 100 ms. > 3. Track trends in allocation rates. In some situations, the allocation rate trends upwards due to, for example, the start of a new phase of execution or a spike in client workload. > 4. When we detect acceleration of allocation rate, predict consumption of memory based on accelerated allocation rates rather than assuming constant allocation rate. Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits: - Fix comment - Use PROPERFMT macros - Simplify code flow: reviewer suggestion - Merge remote-tracking branch 'jdk/master' into accelerated-triggers - Remove develop/debug instrumentation - add another override - Change type of command-line args - fix white space - Add override to virtual methods - Fix race between allocation reporting and querying - ... and 55 more: https://git.openjdk.org/jdk/compare/dd20e915...7f3a6d1e ------------- Changes: https://git.openjdk.org/jdk/pull/29039/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=03 Stats: 1028 lines in 25 files changed: 921 ins; 35 del; 72 mod Patch: https://git.openjdk.org/jdk/pull/29039.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29039/head:pull/29039 PR: https://git.openjdk.org/jdk/pull/29039 From kdnilsen at openjdk.org Wed Jan 7 20:56:54 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 7 Jan 2026 20:56:54 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v3] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 22:27:41 GMT, William Kemper wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove develop/debug instrumentation > > src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 275: > >> 273: } >> 274: >> 275: void ShenandoahAdaptiveHeuristics::add_gc_time(double timestamp, double gc_time) { > > Could we use `TruncatedSeq::predict_next` here? In this PR, we keep TruncatedSeq::predict_next() functionality as that has proven to be "right" most of the time. TruncatedSeq::predict_next() assumes the next GC time is most effectively predicted as an average over a noisy history of previously measured GC times. This new function adds a new prediction mechanism which kicks in when we observe a "linearly increasing trend in GC times". This has been observed to occur during initialization and startup of new phases of a service workload, where GC(N) takes 400 ms, GC(N+1) takes 425 ms, GC(N+2) takes 465 ms, etc. The typical reason is because the workload is building up data structures and thus requires increasing amounts of time to mark and evacuate and update the increasing amounts of live data. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29039#discussion_r2670036503 From xpeng at openjdk.org Wed Jan 7 21:13:08 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 7 Jan 2026 21:13:08 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v17] In-Reply-To: <6J2xtZ1DLytiwflQ0wbQCtg8tsRAHadSdkZGZllLAxY=.af212eeb-44f7-4955-96ab-d069febe4e0e@github.com> References: <2YVE3uR8bRJ_8qAtXN4WoRmeY0Y9xhzsmKbxqv5oL2M=.2811f02e-35b8-46cf-863a-db4006ca1a78@github.com> <4Qs9QlvWQ7gX6RW-rwPVJa-Ndhtx883aImTtiXyCYGk=.1c03a208-d6e5-42bc-bfc3-d1f95e968929@github.com> <6J2xtZ1DLytiwflQ0wbQCtg8tsRAHadSdkZGZllLAxY=.af212eeb-44f7-4955-96ab-d069febe4e0e@github.com> Message-ID: <1MZQLDhJsqK5ZoPIVDYYRyVg0po67A6wVfIpsAl7Qa0=.d0bfa7e4-f448-4bb1-a386-b8226133e6a7@github.com> On Tue, 6 Jan 2026 21:00:03 GMT, Kelvin Nilsen wrote: >> Are you running any experiments (on different hardware configurations) to test your assumptions about this? > > Please document the results of any experiments as rationale for the final design. I did run some experiments and didn't see significant difference, I will keep keep current code using PaddedArray, meanwhile keep this conversation open and make a decision based metrics later after I address the other comments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2670084604 From kdnilsen at openjdk.org Wed Jan 7 21:26:52 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 7 Jan 2026 21:26:52 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v24] In-Reply-To: References: Message-ID: > Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). > > This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. > > The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. > > ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) > > With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. > > ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) > > At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. > > ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) > > The command line for these comparisons follows: > > > ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jdk/bin/java \ > -XX:+Unlock... Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Add comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25357/files - new: https://git.openjdk.org/jdk/pull/25357/files/9aa4a3e2..026e34df Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=23 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=22-23 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25357/head:pull/25357 PR: https://git.openjdk.org/jdk/pull/25357 From xpeng at openjdk.org Wed Jan 7 21:47:46 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 7 Jan 2026 21:47:46 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v20] In-Reply-To: References: <797j9fNWUlV491wWKbFMfthH99o3A5493T0Pcdn_zdc=.417c13b0-8618-4402-aafa-3d86c45c8ff6@github.com> Message-ID: <3CDzFBUPf-x7Cp4HiQdzwytCJk9kdpDHGB0SjEtD5Kg=.d9833d73-f579-4ddb-bb3e-e7a9ce0743d0@github.com> On Tue, 6 Jan 2026 17:35:56 GMT, Kelvin Nilsen wrote: >> Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 265 commits: >> >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - Fix build error after merging from tip >> - Merge branch 'master' into cas-alloc-1 >> - Merge branch 'master' into cas-alloc-1 >> - Some comments updates as suggested in PR review >> - Fix build failure after merge >> - Expend promoted from ShenandoahOldCollectorAllocator >> - Merge branch 'master' into cas-alloc-1 >> - Address PR comments >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - ... and 255 more: https://git.openjdk.org/jdk/compare/de81d389...cf13b7b5 > > src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 110: > >> 108: } >> 109: >> 110: uint dummy = 0; > > Don't call this "dummy". Call it regions_ready_for_refresh. Remember the value and pass it in as a new argument to attempt_allocation_slow() so that we don't have to recompute it later. The values from fast path won't be used anyway, that why I called it dummy. attempt_allocation_slow has to recompute it after acquiring heap lock. Imaging that have have two mutators, 8 shared alloc regions, both try to allocate the same time: 1. Both threads tried the fast path (attempt_allocation_in_alloc_regions) and failed, both see 8 alloc regions are ready to retire. 2. Both threads will call into attempt_allocation_slow 3. The first thread acquired heap lock refresh all the 8 alloc regions and allocate in one of the region. the thread release heap lock, 4. The 2nd thread acquires heap lock successfully after 1st thread released it, now the regions_ready_for_refresh it saw in fast path is stale and has to be recomputed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2670164993 From kdnilsen at openjdk.org Wed Jan 7 21:54:47 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 7 Jan 2026 21:54:47 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v25] In-Reply-To: References: Message-ID: > Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). > > This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. > > The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. > > ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) > > With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. > > ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) > > At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. > > ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) > > The command line for these comparisons follows: > > > ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jdk/bin/java \ > -XX:+Unlock... Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Fix confusing comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25357/files - new: https://git.openjdk.org/jdk/pull/25357/files/026e34df..b064ecc5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=24 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=23-24 Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25357/head:pull/25357 PR: https://git.openjdk.org/jdk/pull/25357 From kdnilsen at openjdk.org Wed Jan 7 22:16:55 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 7 Jan 2026 22:16:55 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v26] In-Reply-To: References: Message-ID: > Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). > > This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. > > The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. > > ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) > > With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. > > ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) > > At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. > > ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) > > The command line for these comparisons follows: > > > ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jdk/bin/java \ > -XX:+Unlock... Kelvin Nilsen has updated the pull request incrementally with two additional commits since the last revision: - fix another typo - Fix typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25357/files - new: https://git.openjdk.org/jdk/pull/25357/files/b064ecc5..a8520190 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=25 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=24-25 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25357/head:pull/25357 PR: https://git.openjdk.org/jdk/pull/25357 From kdnilsen at openjdk.org Wed Jan 7 22:16:59 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 7 Jan 2026 22:16:59 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v23] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 19:58:58 GMT, Kelvin Nilsen wrote: >> Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). >> >> This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. >> >> The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. >> >> ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) >> >> With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. >> >> ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) >> >> At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. >> >> ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) >> >> The command line for these comparisons follows: >> >> >> ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jd... > > Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 78 commits: > > - Merge remote-tracking branch 'jdk/master' into share-collector-reserves > - Fix whitespace and comment > - Remove note to self > - Slight expansion of promo reserve > - Remove bad assertion > - Merge remote-tracking branch 'jdk/master' into share-collector-reserves-restart-gh > - Merge remote-tracking branch 'jdk/master' into share-collector-reserves > - fix unsigned arithmetic underflow > - Attempt fix for assertion failures > - Merge remote-tracking branch 'jdk/master' into share-collector-reserves > - ... and 68 more: https://git.openjdk.org/jdk/compare/dd20e915...9aa4a3e2 src/hotspot/share/gc/shenandoah/heuristics/shenandoahGenerationalHeuristics.cpp line 183: > 181: // Call the subclasses to add young-gen regions into the collection set. > 182: choose_collection_set_from_regiondata(collection_set, candidates, cand_idx, immediate_garbage + free); > 183: The general idea here is to see give young-gen first dibs at its reserves. But if young does not consumes its reserves, we'll see if we can repurpose some of those reserves to expand our old-gen evacuation efforts. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2670067635 From kdnilsen at openjdk.org Wed Jan 7 22:17:01 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 7 Jan 2026 22:17:01 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v26] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 22:14:21 GMT, Kelvin Nilsen wrote: >> Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). >> >> This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. >> >> The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. >> >> ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) >> >> With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. >> >> ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) >> >> At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. >> >> ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) >> >> The command line for these comparisons follows: >> >> >> ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jd... > > Kelvin Nilsen has updated the pull request incrementally with two additional commits since the last revision: > > - fix another typo > - Fix typo src/hotspot/share/gc/shenandoah/heuristics/shenandoahGenerationalHeuristics.cpp line 213: > 211: // Entire region will be promoted, This region does not impact young-gen or old-gen evacuation reserve. > 212: // This region has been pre-selected and its impact on promotion reserve is already accounted for. > 213: I think this comment is obsolete. The line of code that it describes was removed in a previous PR. IIRC, we used to increment cur_young_garbage by r->garbage() plus r->get_live_data_bytes(). src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 127: > 125: byte_size_in_proper_unit(old_evacuation_budget), proper_unit_for_byte_size(old_evacuation_budget), > 126: unprocessed_old_collection_candidates()); > 127: This code is now used twice for mixed evacuation cycle, so I bundled the code into add_old_regions_to_cset(). The first time is when we prime the collection set. This is called to place certain old-gen regions into the cset before we chose the young-gen regions that are going to be collected. The second time is when we top-off the old collection set. This happens after young-gen regions have been placed into the cset. If there is unused reserve from young generation, we consider repurposing those reserves for old and try to expand the old collection set. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2670076558 PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2670138961 From kdnilsen at openjdk.org Wed Jan 7 22:17:05 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 7 Jan 2026 22:17:05 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v24] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 21:26:52 GMT, Kelvin Nilsen wrote: >> Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). >> >> This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. >> >> The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. >> >> ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) >> >> With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. >> >> ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) >> >> At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. >> >> ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) >> >> The command line for these comparisons follows: >> >> >> ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jd... > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > Add comment src/hotspot/share/gc/shenandoah/heuristics/shenandoahGlobalHeuristics.cpp line 50: > 48: > 49: void ShenandoahGlobalHeuristics::choose_global_collection_set(ShenandoahCollectionSet* cset, > 50: const ShenandoahHeuristics::RegionData* data, The general idea here: For a global GC, our collection set is based on garbage-first heuristic across all of young and all of old. We combine our old and young reserves into a shared pool of reserves. We choose cset regions in garbage-first order. Our choices of which regions to evacuate cause us to dedicate reserves to either old or young. src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 279: > 277: } > 278: > 279: // After an abbreviated cycle, we reclaim immediate garbage. Rebuild the freeset in order to establish With this PR, some apportionment of reserves is done before the idle span. And each idle span is preceded by a freeset rebuild. At the time of rebuild, we make use of information gleaned from recent GC activities to decide how to balance the old and young reserves, such as: 1. Are there candidates for mixed evacuation? 2. What is the potential for promotion? src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1219: > 1217: } > 1218: > 1219: void ShenandoahFreeSet::move_unaffiliated_regions_from_collector_to_old_collector(ssize_t count) { This allows us to "share" from young reserve to old reserve. src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 2571: > 2569: } > 2570: > 2571: Before this PR, we only "have_evacuation_reserves" when we rebuild at start of evacuation. With this PR, we always have_evacuation_reserves. That's because at the start of idle span, we are already anticipating what sort of evacuation will take place during the next GC cycle ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2670125957 PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2670155851 PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2670166464 PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2670192097 From xpeng at openjdk.org Wed Jan 7 22:17:34 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 7 Jan 2026 22:17:34 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v14] In-Reply-To: <0IfaybNazrHlrdcGhk-0080a-KqpdUwN_WXpYVe_fjc=.d68c5098-02b7-4a91-8ad3-4e8b310cba0b@github.com> References: <_mkL6HrCqlS1_qgOmXvEj3vsYgo2idQnbaDdMVFEGUk=.9c71f705-1f96-441e-96d0-c99d3053cffd@github.com> <4BVpGlI0mK12KTI6b6l1UoH26vEwytUP1vlYX1Z-UJQ=.374ea1dd-38d7-46ea-b6a5-a99453171059@github.com> <0IfaybNazrHlrdcGhk-0080a-KqpdUwN_WXpYVe_fjc=.d68c5098-02b7-4a91-8ad3-4e8b310cba0b@github.com> Message-ID: On Tue, 6 Jan 2026 17:34:06 GMT, Kelvin Nilsen wrote: >> But part of the reason for my confusion is that you are trying to do fast allocations while holding the heap lock! >> >> The reason we came into attempt_allocation_slow() is because we already failed to attempt_allocation_in_alloc_regions(). There's no need to call this a second time. You should have remembered regions_ready_for_refresh and passed this in as an argument to attempt_allocation_slow(). > > I'm not concerned that the count of regions_ready_for_refresh might be stale. If this count is getting incremented "during" our allocation, we will see this result soon enough. If multiple mutators fail fast-path allocation simultaneously, they will each acquire heap lock either way (existing implementation vs. new implementation that does not retry the allocation). Acquiring the heap lock is the "expensive" operation. If the first one refreshes allocation regions, then subsequent invocations will not find any regions to be refreshed. The concern is the not "this count is getting incremented "during" our allocation", it is the the case when it get decremented because other mutators may have already refreshed all alloc regions before current mutator getting heap lock, we have call attempt_allocation_in_alloc_regions again after successfully acquiring heap lock because of this. Same design can be also found in G1, Parallel and Serial GC's CAS allocator. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2670238256 From xpeng at openjdk.org Wed Jan 7 22:27:56 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 7 Jan 2026 22:27:56 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v20] In-Reply-To: References: <797j9fNWUlV491wWKbFMfthH99o3A5493T0Pcdn_zdc=.417c13b0-8618-4402-aafa-3d86c45c8ff6@github.com> Message-ID: On Tue, 6 Jan 2026 21:32:30 GMT, Kelvin Nilsen wrote: >> Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 265 commits: >> >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - Fix build error after merging from tip >> - Merge branch 'master' into cas-alloc-1 >> - Merge branch 'master' into cas-alloc-1 >> - Some comments updates as suggested in PR review >> - Fix build failure after merge >> - Expend promoted from ShenandoahOldCollectorAllocator >> - Merge branch 'master' into cas-alloc-1 >> - Address PR comments >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - ... and 255 more: https://git.openjdk.org/jdk/compare/de81d389...cf13b7b5 > > src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 254: > >> 252: // Step 1: find out the alloc regions which are ready to refresh. >> 253: for (uint i = 0; i < _alloc_region_count; i++) { >> 254: ShenandoahAllocRegion* alloc_region = &_alloc_regions[i]; > > We've got the heap lock here. why does this need to be atomic? Comments in the code should make this clear. I believe AtomicAccess::load here is not needed, I'll remove it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2670262454 From xpeng at openjdk.org Wed Jan 7 22:53:26 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 7 Jan 2026 22:53:26 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v21] In-Reply-To: References: Message-ID: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request incrementally with three additional commits since the last revision: - Update code comments - Update assert message - Only use atomic allocation when allocate from shared alloc regions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/cf13b7b5..61d86546 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=20 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=19-20 Stats: 33 lines in 5 files changed: 13 ins; 0 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From xpeng at openjdk.org Wed Jan 7 22:53:29 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 7 Jan 2026 22:53:29 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v20] In-Reply-To: References: <797j9fNWUlV491wWKbFMfthH99o3A5493T0Pcdn_zdc=.417c13b0-8618-4402-aafa-3d86c45c8ff6@github.com> Message-ID: On Tue, 6 Jan 2026 00:32:24 GMT, Kelvin Nilsen wrote: >> Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 265 commits: >> >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - Fix build error after merging from tip >> - Merge branch 'master' into cas-alloc-1 >> - Merge branch 'master' into cas-alloc-1 >> - Some comments updates as suggested in PR review >> - Fix build failure after merge >> - Expend promoted from ShenandoahOldCollectorAllocator >> - Merge branch 'master' into cas-alloc-1 >> - Address PR comments >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - ... and 255 more: https://git.openjdk.org/jdk/compare/de81d389...cf13b7b5 > > src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 102: > >> 100: for (size_t i = 0; i < num_regions; i++) { >> 101: ShenandoahHeapRegion* region = heap->get_region(i); >> 102: assert(!region->is_active_alloc_region(), "Not expecting any active alloc region at the time"); > > Same suggestion here as with shenandoahGenerationalHeuristics.cpp. fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2670313055 From xpeng at openjdk.org Wed Jan 7 22:56:19 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 7 Jan 2026 22:56:19 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v14] In-Reply-To: References: <_mkL6HrCqlS1_qgOmXvEj3vsYgo2idQnbaDdMVFEGUk=.9c71f705-1f96-441e-96d0-c99d3053cffd@github.com> Message-ID: On Wed, 7 Jan 2026 19:37:13 GMT, Xiaolong Peng wrote: >> Would prefer not to use the atomic_allocate code here. If you want to reuse code, maybe you can refactor allocate_in with an template argument. >> >> I notice that this PR makes lots of ShenandoahHeapRegion variables volatile: _age, _youth, _top, _tlab_allocs, _gclab_allocs, _plab_allocs. That will cause less efficient code to be generated whenever we are accessing this data from "behind" the GC heap lock, which should be rare, I guess. >> >> I raised some concerns/issues about the race that happens when we move a region from the directly-allocatable set into the global-heap-lock-protected ShenandoahFreeSet partition. >> >> Here's the scenario that I'm concerned about: >> >> 1. A mutator obtains pointer to directly allocatable region R >> 2. A second mutator performs a refresh, moving region R out of directly allocatable set (for whatever reason) >> 3. Region R is now eligible to satisfy allocations from behind the global heap lock >> 4. Some third mutator thread acquires the heap lock and fetches top for region $ >> 5. The first mutator performs its allocation within the same region R, not recognizing a CAS conflict >> 6. This third mutator allocates from region R at top, without using CAS. So both mutators think they own the same object >> >> I think this is not a problem if the "only" reason at step 2 above that we move region R out of directly allocatable set is because R is ready to be retired. In that case, there will be no subsequent heap-locked allocations in regions R. However, I anticipate the day in not-too-distant future when we will want to refresh regions even when they are not ready to be retired. Specifically, as we move rebuild-freeset out of safepoints, we will want to refresh regions before we acquire heap-lock to do rebuild, with the goal of making sure there is sufficient directly allocatable memory available that no mutator will be stalled because it needs to allocate during the time that the heap remains locked for the rebuild operation. >> >> So I suppose that if we always use atomic_allocate() even for allocations that happen while holding the heap lock, we won't have this problem. If we decide to keep this architecture, there should be comments explaining why we are doing it this way. (I am not real happy that we have to "pay the cost" of CAS in addition to paying the cost of global heap lock, but I think these allocations should be very rare. It seems this would only come up if, for example, a mutator wanted to allocate ... > > I will update the PR and not use atomic version here, and also another place in refresh_alloc_regions. > > Having volatile_top and nonvolatile_top seems necessary, it will make the code more complicated w/o much performance benefits, with CAS allocator, most of alloc request will be handled by the atomic code path, in only few > cases we need non-atomic allocation: > * After reserving alloc regions from free set before storing to alloc region, it performs obj allocation if the alloc request has not been satisfied yet. > * After trying atomic allocation, refresh alloc regions fails, it will try to find a region in free set with enough space for the allocation request. > > Yes, all the _age, _youth, _top, _tlab_allocs, _gclab_allocs, _plab_allocs are volatile now, out of these fields, I believe I can maybe remove volatile for _age and _youth(?), but the update of the rest must be atomic because mutators will increase the values in the CAS allocation code path w/o heap lock. I have updated the method `atomic_allocate_in` with a template parameter ATOMIC, now only when allocating from shared alloc regions the ATOMIC parameter is true to use atomic operations. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2670323493 From xpeng at openjdk.org Wed Jan 7 22:59:04 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 7 Jan 2026 22:59:04 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v22] In-Reply-To: References: Message-ID: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: No need to use Atomic::load to read shared alloc region in refresh_alloc_regions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/61d86546..f5038a3a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=21 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=20-21 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From john.r.rose at oracle.com Wed Jan 7 23:13:02 2026 From: john.r.rose at oracle.com (John Rose) Date: Wed, 07 Jan 2026 15:13:02 -0800 Subject: Variability of the performance of Vector Message-ID: [Resend; sorry for noise.] On 5 Jan 2026, Peter Kessler OS wrote: > I am worried about the variability of the performance of Vector. Worse, I am worried about how to explain to users the variability of the performance of Vector. ? > Aligning arrays to avoid occasional 25% performance loss seems like a worthwhile goal. I would like to open a discussion about how that end might be achieved. full message: https://mail.openjdk.org/pipermail/hotspot-gc-dev/2026-January/056951.html Much of this is a question for panama-dev, where we are very aware of the difficulties of building a user model for vector programming. I appreciate the similar thread from your here on panama-dev: https://mail.openjdk.org/pipermail/panama-dev/2025-September/021141.html But the final question is very important for the GC folks, and is indeed worth a discussion. Actually we have been discussing it one way or another for years, at a low level of urgency. Maybe there are enough concurrent factors to justify taking the plunge (in 2026?) towards hyper-aligned Java heap objects, at least large arrays. Predictable vector performance requires aligned arrays, aligned either to cache lines or to some hardware vector size. For Valhalla, if we decide to work with 128-bit value containers, we would need not only arrays but also class instances that are aligned to 128 bits. (Why 128-bit containers? Well, they are efficiently atomic on ARM and maybe x86, and many Valhalla types would use them if they could. But misaligning them spoils atomicity. Valhalla is limited to 64-bit flattening as long as the existing heap alignment schemes are present.) Aligning an array is not exactly the same task as aligning an object, since for arrays you should align the address &a[0], while for an object o you must align some field &o.f, but you can get away with aligning &o._header (and put padding after the object header). In this space, there are lots of ways to pick out a set of requirements and techniques. Fundamentally, though, the GC needs to recognize that some array or (maybe) object is subject to hyper-alignment, and perform special-case allocation on it. There?s lots of bookkeeping around that fundamental, including sizing logic (might we need more space for inter-object padding?) and of course the initial contracts. (I.e., how does the user request hyper-alignment?) And there is the delicate question of optimization: How do we keep hot loops in the GC from acquiring an extra data-dependent test (for the "hyper-align bit"). Can we hide the test under another pre-existing test? Can be batch things so that normally aligned objects are segregated from the hyper-aligned ones, and version our hot loops accordingly? ("Another pre-existing test" ? I?m thinking something like an object header test that already exists, where some rare object header bit configuration must already be tested for, and is expected to be rare. In that case, all hyper-aligned objects, whether arrays or not, would be put into that rare header state, and on the rarely taken path in the GC loop that handles the pre-existing rare state, we?d also handle the case of hyper-alignment. Seems likely that would be an option?) On top of all that is portability ? we have to do this work several times, once for each GC. Or, if a particular GC configuration cannot support hyper-alignment, the user model must offer a fallback. (The fallback might look like, "If you use the vector API you should really enable Z or G1". And also, "You get better flattening for larger value objects if you run on ARM with Z or G1.") I haven?t even begun to assign header bits here. The problems are deeper than that! I will say one more thing about arrays: I think it would be very reasonable to align all arrays larger than a certain threshold size, fully to the platform cache line size, so that the &a[0] starts at a cache line boundary. This goes for primitives, values, whatever. Call this particular feature "large array hyper alignment". It might be a first feature to implement in this space. I have filed an RFE here: https://bugs.openjdk.org/browse/JDK-8374748 Note that many hot GC loops that process arrays are O(a.length). This means that doing a little extra work for long lengths is almost by definition a negligible overhead. Large array hyper alignment would neatly solve Peter?s problem. And it would give us a head start towards Valhalla atomics, as long as we didn?t paint ourselves into some corner. The RFE mentions some possible follow-on features. From xpeng at openjdk.org Wed Jan 7 23:12:41 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 7 Jan 2026 23:12:41 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v14] In-Reply-To: References: <_mkL6HrCqlS1_qgOmXvEj3vsYgo2idQnbaDdMVFEGUk=.9c71f705-1f96-441e-96d0-c99d3053cffd@github.com> Message-ID: On Tue, 6 Jan 2026 17:37:46 GMT, Kelvin Nilsen wrote: >> I'll add comments on this, _alloc_region_count == 0 means we don't want to use any shared alloc region, it will always allocate with a heap lock, ideally the performance should be same as before, so it always simply find a region with enough space and allocate in the region. > > Put the comments describing functions in the .hpp file, where they are currently. But we need to enhance those comments. I have added comments on those functions, I'll keep adding more for those missing comments; meanwhile I am trying to avoid excessive comment, pleas point out if any of the comments is not clear. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2670355339 From xpeng at openjdk.org Wed Jan 7 23:16:00 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 7 Jan 2026 23:16:00 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v23] In-Reply-To: References: Message-ID: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: No need to use Atomic::load to read shared alloc region in release_alloc_regions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/f5038a3a..917dd8a3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=22 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=21-22 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From xpeng at openjdk.org Wed Jan 7 23:19:28 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 7 Jan 2026 23:19:28 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v20] In-Reply-To: References: <797j9fNWUlV491wWKbFMfthH99o3A5493T0Pcdn_zdc=.417c13b0-8618-4402-aafa-3d86c45c8ff6@github.com> Message-ID: <_vhMVxLnvCdIHO_CJ8kaI3cLNKJSSYvqK7n_wriVhDk=.2d1649e4-512d-4682-842b-29541423b458@github.com> On Tue, 6 Jan 2026 01:55:58 GMT, Kelvin Nilsen wrote: >> Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 265 commits: >> >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - Fix build error after merging from tip >> - Merge branch 'master' into cas-alloc-1 >> - Merge branch 'master' into cas-alloc-1 >> - Some comments updates as suggested in PR review >> - Fix build failure after merge >> - Expend promoted from ShenandoahOldCollectorAllocator >> - Merge branch 'master' into cas-alloc-1 >> - Address PR comments >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - ... and 255 more: https://git.openjdk.org/jdk/compare/de81d389...cf13b7b5 > > src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 338: > >> 336: for (uint i = 0; i < _alloc_region_count; i++) { >> 337: ShenandoahAllocRegion& alloc_region = _alloc_regions[i]; >> 338: ShenandoahHeapRegion* r = AtomicAccess::load(&alloc_region.address); > > We've got heap lock and at safepoint. Do not need AtomicAccess here. That is more costly than necessary. I prefer to use regular fetch. If you prefer to keep AtomicAccess, please provide a comment in the code explaining why and we will revist. The atomic load is not needed, I'll removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2670368014 From kdnilsen at openjdk.org Thu Jan 8 00:14:17 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 8 Jan 2026 00:14:17 GMT Subject: RFR: 8373819: GenShen: Requested generation may be null [v3] In-Reply-To: References: <8SWpQdaleulzSXfgF4fJ_zgekaijLs53t8Wer6IvKwo=.785abf41-65b7-44f6-90d0-2c63d5bf5981@github.com> Message-ID: On Mon, 5 Jan 2026 17:13:08 GMT, William Kemper wrote: >> This PR attempts to simplify the generational control thread by decoupling it somewhat from the heap/gc cancellation mechanism. This is meant to prevent the control thread from seeing inconsistencies between `shHeap::_cancelled_gc` and `shGenControlThread::_requested_gc_cause`. > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: > > - Merge remote-tracking branch 'jdk/master' into fix-null-generation-crash > - Fix typo in assertion message > - Take regulator thread out of STS before requesting GC > > The request may block while it waits for control thread to stop old marking. If workers are already in the STS, and the regulator thread is still in the STS, but cannot yield, the safepoint will not run. Control, worker and regulator threads deadlock each other. > - Add comments > - Revert back to what should be on this branch > - Merge remote-tracking branch 'jdk/master' into fix-null-generation-crash > - Don't know how this file got deleted > - Carry over gc cancellation to gc request > - Do not let allocation failure requests be overwritten by other requests > - Fix degen point handling > - ... and 3 more: https://git.openjdk.org/jdk/compare/4458cab4...8f4f55db Thanks for talking us through this PR. Lots of subtle issues here. Looks good to me. ------------- Marked as reviewed by kdnilsen (Committer). PR Review: https://git.openjdk.org/jdk/pull/28932#pullrequestreview-3637243572 From john.r.rose at oracle.com Thu Jan 8 00:16:03 2026 From: john.r.rose at oracle.com (John Rose) Date: Wed, 07 Jan 2026 16:16:03 -0800 Subject: Variability of the performance of Vector In-Reply-To: <1122429580.10251770.1767828176523.JavaMail.zimbra@univ-eiffel.fr> References: <1122429580.10251770.1767828176523.JavaMail.zimbra@univ-eiffel.fr> Message-ID: The discussion that I am trying to have, at this point, is "What is our first step into the world of hyper-aligned objects?" Making that first step requires the GC team to make a bunch of new cuts in their hot loops, so it?s tricky and expensive. I?d like to focus on the feasibility of large array hyper alignment, or if not that, some better feature, equally limited, in the GC. So, further discussion about field layouts vs. VHs will eventually make sense in the Valhalla project, after we get the possibility of more atomic layouts, after the GC provides an option for hyper-alignment. We can?t yet revisit that discussion IMO; we should just bookmark it. Maybe coupling value VHs to volatile will pay off, maybe not. This is not the venue for discussing it. On 7 Jan 2026, at 15:22, Remi Forax wrote: > For fields, at least from the Java side, at some point in the past, volatile was our marker, > but we lost it when we allowed VarHandle on any fields. > > I wonder if we should not revisit that. > > I think there is a possible future where we first disallow VarHandle on field typed with a value type that are not explicitly tagged as volatile > (i would help to avoid to consider fields in abstract value class as 64 bits) and then disallow VarHandle on all fields that are now marked as volatile (using a runtime warning as for final). > > Basically, the same way we are making final really final, volatile could be used to say please align/pad because we may access that field atomically. > > regards, > R?mi From xpeng at openjdk.org Thu Jan 8 00:26:03 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Thu, 8 Jan 2026 00:26:03 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v24] In-Reply-To: References: Message-ID: <1qqqdCXoW9PWw_ERccC7zh6kMPBJyKHp9wprAEqbMgM=.24431e29-e46f-4a8b-ade6-d27506432169@github.com> > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 271 commits: - Merge branch 'openjdk:master' into cas-alloc-1 - No need to use Atomic::load to read shared alloc region in release_alloc_regions - No need to use Atomic::load to read shared alloc region in refresh_alloc_regions - Update code comments - Update assert message - Only use atomic allocation when allocate from shared alloc regions - Merge branch 'openjdk:master' into cas-alloc-1 - Fix build error after merging from tip - Merge branch 'master' into cas-alloc-1 - Merge branch 'master' into cas-alloc-1 - ... and 261 more: https://git.openjdk.org/jdk/compare/9a944e55...ef10341f ------------- Changes: https://git.openjdk.org/jdk/pull/26171/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=23 Stats: 1656 lines in 25 files changed: 1308 ins; 235 del; 113 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From john.r.rose at oracle.com Thu Jan 8 00:42:34 2026 From: john.r.rose at oracle.com (John Rose) Date: Wed, 07 Jan 2026 16:42:34 -0800 Subject: Variability of the performance of Vector In-Reply-To: References: Message-ID: <41E3A199-A660-4CBE-BDDF-668E08670765@oracle.com> On 7 Jan 2026, at 16:28, Daniel Lemire wrote: > The 25% is real but it affects mostly simple functions that do little compute. Like a memory copy, or a quick scan of an input. > > Daniel Lemire, "Dot product on misaligned data," in *Daniel Lemire's blog*, July 14, 2025, https://urldefense.com/v3/__https://lemire.me/blog/2025/07/14/dot-product-on-misaligned-data/__;!!ACWV5N9M2RV99hQ!K9TplKFS-WUOa0MaUq2AHthEGN65CdQg4SMS7SPHfeftYwG4A2S_2jP9hWf_6B2iBjb6V-MeGAQCO-hOcQ$ . > Good point. We expect such affected functions to be common, right? Surely vectorized hashcode or comparison is affected about as much as dot product. Also, we are in the habit of worrying about micro-benchmarks, which are usually oversimplified, but may well show the 25% effect. This is a sad habit for us platform folks, but a necessary one. Finally, Peter?s very interesting "trip report" showed another common story: The 25% showed up only after he removed some performance bugs (accumulator bottlenecks). It sure would be nice to reward the diligent coder with the full benefit, rather than take away the last 25% due to misalignment. What I think (or hope) is that a large array hyper-alignment feature could silently patch up a number of such artifacts. ? John From wkemper at openjdk.org Thu Jan 8 00:48:58 2026 From: wkemper at openjdk.org (William Kemper) Date: Thu, 8 Jan 2026 00:48:58 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v25] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 21:54:47 GMT, Kelvin Nilsen wrote: >> Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). >> >> This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. >> >> The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. >> >> ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) >> >> With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. >> >> ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) >> >> At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. >> >> ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) >> >> The command line for these comparisons follows: >> >> >> ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jd... > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > Fix confusing comment Just posting my comments for today, more to follow. Also, this will conflict mightily with https://github.com/openjdk/jdk/pull/27632. Though I think using the age census to estimate promotion reserves is conceptually compatible with this PR. src/hotspot/share/gc/shenandoah/heuristics/shenandoahGenerationalHeuristics.cpp line 178: > 176: bool need_to_finalize_mixed = false; > 177: if (_generation->is_young()) { > 178: need_to_finalize_mixed = heap->old_generation()->heuristics()->prime_collection_set(collection_set); We could push this logic for young collections down into `ShenandoahYoungHeuristics::choose_collection_set_from_regiondata` where `_generation` is always `ShenandoahYoungGeneration`. src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 342: > 340: } > 341: > 342: bool ShenandoahOldHeuristics::top_off_collection_set(ssize_t &add_regions_to_old) { Does `add_regions_to_old` really need to be signed? Seems like it will always be non-negative here. src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 282: > 280: // reserves for the next GC cycle. > 281: assert(_abbreviated, "Only rebuild free set for abbreviated and old-marking cycles"); > 282: heap->rebuild_free_set(true /*concurrent*/); Should we move this up in the sequence? If promote in place fails we'd go to a degenerated cycle. After a cursory review of the degenerated cycle, it looks like it only rebuilds the freeset when evacuations are performed. Seems like rebuidling the freeset earlier before checking for cancellation might reduce the chance of a degenerated cycle and also guarantee the freeset is rebuilt. Would it make more sense to do this in `early_cleanup`? ------------- Changes requested by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25357#pullrequestreview-3637002268 PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2670238461 PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2670502843 PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2670279391 From wkemper at openjdk.org Thu Jan 8 00:49:00 2026 From: wkemper at openjdk.org (William Kemper) Date: Thu, 8 Jan 2026 00:49:00 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v26] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 22:16:55 GMT, Kelvin Nilsen wrote: >> Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). >> >> This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. >> >> The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. >> >> ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) >> >> With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. >> >> ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) >> >> At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. >> >> ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) >> >> The command line for these comparisons follows: >> >> >> ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jd... > > Kelvin Nilsen has updated the pull request incrementally with two additional commits since the last revision: > > - fix another typo > - Fix typo src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 165: > 163: } > 164: > 165: assert(heap->is_concurrent_weak_root_in_progress(), "Must be doing weak roots now"); Was there a reason to remove this `assert`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2670259539 From dholmes at openjdk.org Thu Jan 8 07:21:44 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 8 Jan 2026 07:21:44 GMT Subject: RFR: 8374576: Disable MemoryEaterMT for VirtualThread In-Reply-To: References: Message-ID: <0kpALSKalrr5693MiIAn-E7Y9J-C_wi9zOWfd7iVYeE=.f66319c2-008d-42b1-b23b-fae4b37bfc5e@github.com> On Tue, 6 Jan 2026 10:20:17 GMT, Ramkumar Sunderbabu wrote: > Background: The test induces OOM and frees memory when OOMError is thrown. However, there is no guarantee that OOM should happen in the same thread for the test to handle the error. OOM can arise in any thread. This logic makes this test fundamentally unreliable. > Recently, we are seeing issue with VT usage. > > This is still useful test to have around. Hence, excluding the test only for VT case. > > Testing: > Ran with and without VT thread. > Hotspot Tier1 and Tier2 LGTM. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29060#pullrequestreview-3638073887 From duke at openjdk.org Thu Jan 8 07:27:13 2026 From: duke at openjdk.org (duke) Date: Thu, 8 Jan 2026 07:27:13 GMT Subject: RFR: 8374576: Disable MemoryEaterMT for VirtualThread In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 10:20:17 GMT, Ramkumar Sunderbabu wrote: > Background: The test induces OOM and frees memory when OOMError is thrown. However, there is no guarantee that OOM should happen in the same thread for the test to handle the error. OOM can arise in any thread. This logic makes this test fundamentally unreliable. > Recently, we are seeing issue with VT usage. > > This is still useful test to have around. Hence, excluding the test only for VT case. > > Testing: > Ran with and without VT thread. > Hotspot Tier1 and Tier2 @rsunderbabu Your change (at version 85218f672f58eb1ddb4998f204ca2593f2998638) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29060#issuecomment-3722456107 From rsunderbabu at openjdk.org Thu Jan 8 09:28:56 2026 From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu) Date: Thu, 8 Jan 2026 09:28:56 GMT Subject: Integrated: 8374576: Disable MemoryEaterMT for VirtualThread In-Reply-To: References: Message-ID: <2QCcndTYYRNsRzDuNyeJpvm22dbh_kHcrMdkq9_opV4=.cf6b565f-a4d2-44be-b11b-7be50035af9f@github.com> On Tue, 6 Jan 2026 10:20:17 GMT, Ramkumar Sunderbabu wrote: > Background: The test induces OOM and frees memory when OOMError is thrown. However, there is no guarantee that OOM should happen in the same thread for the test to handle the error. OOM can arise in any thread. This logic makes this test fundamentally unreliable. > Recently, we are seeing issue with VT usage. > > This is still useful test to have around. Hence, excluding the test only for VT case. > > Testing: > Ran with and without VT thread. > Hotspot Tier1 and Tier2 This pull request has now been integrated. Changeset: 08ff16f0 Author: Ramkumar Sunderbabu Committer: SendaoYan URL: https://git.openjdk.org/jdk/commit/08ff16f0aa8eaa9596da52d568720c69c897f3c5 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8374576: Disable MemoryEaterMT for VirtualThread Reviewed-by: lmesnik, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/29060 From stefank at openjdk.org Thu Jan 8 09:34:38 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 8 Jan 2026 09:34:38 GMT Subject: RFR: 8373695: G1: Using a value near integer max for ActiveProcessorCount causes fatal crash [v4] In-Reply-To: <-3BqMYvPOr3yXj3Txfl7j4bM2vbBwVSes4OUaK4lYik=.f93f53ed-03de-4299-a800-033b436214bc@github.com> References: <-3BqMYvPOr3yXj3Txfl7j4bM2vbBwVSes4OUaK4lYik=.f93f53ed-03de-4299-a800-033b436214bc@github.com> Message-ID: <1r82BuivcW5WKrkvHCzp97GLRq3ni6aJwwM_KSMjYCQ=.ebe4bd5c-3eaa-4841-96bd-3111d7c0e612@github.com> On Wed, 7 Jan 2026 13:13:20 GMT, Jonas Norlinder wrote: >> G1ConcRefinementThreads default value depends on ParallelGCThreads which in turn may depend on ActiveProcessorCount. These have different ranges that are valid. Patch will ensure argument setup code never try to assign a value larger than what G1ConcRefinementThreads expects. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Use API over hardcoded values Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28831#pullrequestreview-3638559216 From duke at openjdk.org Thu Jan 8 09:34:40 2026 From: duke at openjdk.org (duke) Date: Thu, 8 Jan 2026 09:34:40 GMT Subject: RFR: 8373695: G1: Using a value near integer max for ActiveProcessorCount causes fatal crash [v4] In-Reply-To: <-3BqMYvPOr3yXj3Txfl7j4bM2vbBwVSes4OUaK4lYik=.f93f53ed-03de-4299-a800-033b436214bc@github.com> References: <-3BqMYvPOr3yXj3Txfl7j4bM2vbBwVSes4OUaK4lYik=.f93f53ed-03de-4299-a800-033b436214bc@github.com> Message-ID: On Wed, 7 Jan 2026 13:13:20 GMT, Jonas Norlinder wrote: >> G1ConcRefinementThreads default value depends on ParallelGCThreads which in turn may depend on ActiveProcessorCount. These have different ranges that are valid. Patch will ensure argument setup code never try to assign a value larger than what G1ConcRefinementThreads expects. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Use API over hardcoded values @JonasNorlinder Your change (at version 62f78a133e4c46426c4087d2c6d9b9b7cd37990b) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28831#issuecomment-3722994388 From iwalulya at openjdk.org Thu Jan 8 12:09:49 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 8 Jan 2026 12:09:49 GMT Subject: RFR: 8340470: G1: Adopt PartialArrayState to consolidate marking stack in Full GC Message-ID: Hi, Please review this change adopting `PartialArrayState` introduced by [JDK-8337709](https://bugs.openjdk.org/browse/JDK-8337709) to consolidate marking queue sets (oop queue set and objArray queue set) into single queue set in G1 Full GC. Testing: Tier 1-5 ------------- Commit messages: - cleanup - Merge remote-tracking branch 'upstream/master' into ArrayChuncking - partial array manager Changes: https://git.openjdk.org/jdk/pull/29114/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29114&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340470 Stats: 170 lines in 6 files changed: 47 ins; 70 del; 53 mod Patch: https://git.openjdk.org/jdk/pull/29114.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29114/head:pull/29114 PR: https://git.openjdk.org/jdk/pull/29114 From iwalulya at openjdk.org Thu Jan 8 12:58:07 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 8 Jan 2026 12:58:07 GMT Subject: RFR: 8340470: G1: Adopt PartialArrayState to consolidate marking stack in Full GC [v2] In-Reply-To: References: Message-ID: > Hi, > > Please review this change adopting `PartialArrayState` introduced by [JDK-8337709](https://bugs.openjdk.org/browse/JDK-8337709) to consolidate marking queue sets (oop queue set and objArray queue set) into single queue set in G1 Full GC. > > Testing: Tier 1-5 Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: missing include ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29114/files - new: https://git.openjdk.org/jdk/pull/29114/files/0a218479..ba515949 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29114&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29114&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29114.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29114/head:pull/29114 PR: https://git.openjdk.org/jdk/pull/29114 From tschatzl at openjdk.org Thu Jan 8 13:49:35 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 8 Jan 2026 13:49:35 GMT Subject: RFR: 8340470: G1: Adopt PartialArrayState to consolidate marking stack in Full GC [v2] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 12:58:07 GMT, Ivan Walulya wrote: >> Hi, >> >> Please review this change adopting `PartialArrayState` introduced by [JDK-8337709](https://bugs.openjdk.org/browse/JDK-8337709) to consolidate marking queue sets (oop queue set and objArray queue set) into single queue set in G1 Full GC. >> >> Testing: Tier 1-5 > > Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: > > missing include Looks good. One typo to fix though... src/hotspot/share/gc/g1/g1FullGCMarker.cpp line 78: > 76: follow_marking_stacks(); > 77: ScannerTask stolen_task; > 78: if(task_queues->steal(_worker_id, stolen_task)) { Suggestion: if (task_queues->steal(_worker_id, stolen_task)) { src/hotspot/share/gc/g1/g1FullGCMarker.hpp line 72: > 70: G1RegionMarkStatsCache _mark_stats_cache; > 71: > 72: inline bool task_queue_empty(); Potentially add a verb to the name like `is_task_queue_empty()` to make it abundantly clear what this does. ------------- Changes requested by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29114#pullrequestreview-3639488629 PR Review Comment: https://git.openjdk.org/jdk/pull/29114#discussion_r2672413987 PR Review Comment: https://git.openjdk.org/jdk/pull/29114#discussion_r2672420435 From tschatzl at openjdk.org Thu Jan 8 14:02:38 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 8 Jan 2026 14:02:38 GMT Subject: RFR: 8373894: G1: Count evacuation-failed garbage collections in gc cpu usage Message-ID: Hi all, please review this change that makes evacuation failed garbage collections count in the gc CPU usage calculations. The reason is that currently (since forever), G1 considers garbage collections that experience an evacuation failure to not count in the cpu usage calculations. (Afair this has been introduced because the previously extremely slow evacuation failures would impact cpu usage based calculations too much even if very infrequent. For many releases evacuation failure handling is at least parallel and in the same order of magnitude wrt to performance). This can cause significant distortions in GC behavior. In the worst case, if for some reason all garbage collections experience evacuation failure, gc cpu usage (at least for the young gen evacuation pauses) is considered as (close to) zero, with repercussions on heap sizing. Testing: tier1-5 multiple times to find tests that fail because of the UseGCOverheadLimit flag Thanks, Thomas ------------- Commit messages: - 8373894 Changes: https://git.openjdk.org/jdk/pull/29115/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29115&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373894 Stats: 13 lines in 3 files changed: 0 ins; 4 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/29115.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29115/head:pull/29115 PR: https://git.openjdk.org/jdk/pull/29115 From iwalulya at openjdk.org Thu Jan 8 15:11:03 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 8 Jan 2026 15:11:03 GMT Subject: RFR: 8340470: G1: Adopt PartialArrayState to consolidate marking stack in Full GC [v3] In-Reply-To: References: Message-ID: > Hi, > > Please review this change adopting `PartialArrayState` introduced by [JDK-8337709](https://bugs.openjdk.org/browse/JDK-8337709) to consolidate marking queue sets (oop queue set and objArray queue set) into single queue set in G1 Full GC. > > Testing: Tier 1-5 Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: Thomas Review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29114/files - new: https://git.openjdk.org/jdk/pull/29114/files/ba515949..aca08fbd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29114&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29114&range=01-02 Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/29114.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29114/head:pull/29114 PR: https://git.openjdk.org/jdk/pull/29114 From shade at openjdk.org Thu Jan 8 15:53:46 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 8 Jan 2026 15:53:46 GMT Subject: RFR: 8373941: Epsilon: Robust counter updates in early VM phases In-Reply-To: References: Message-ID: <2h5oH-tp9tkOr3jhFHq0MEaF8H7uixf2WrOQsvpU7DQ=.50f3f95e-f115-43cf-a334-72462e86583b@github.com> On Tue, 6 Jan 2026 10:38:13 GMT, Aleksey Shipilev wrote: > See more details in the bug. This PR makes the counters updated on allocation path more robust. New regression test captures the original failure (intermittently). This would be also backported to JDK 26. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `gc/epsilon`, 100x > - [x] Linux x86_64 server fastdebug, `runtime/cds/appcds/TestEpsilonGCWithCDS.java`, 100x > - [x] Linux x86_64 server fastdebug, `gc/epsilon/TestInitAllocs.java`, 1000x @stefank -- is that what you had in mind as one of the solutions? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29061#issuecomment-3724487007 From kdnilsen at openjdk.org Thu Jan 8 15:54:04 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 8 Jan 2026 15:54:04 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v26] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 22:16:55 GMT, Kelvin Nilsen wrote: >> Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). >> >> This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. >> >> The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. >> >> ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) >> >> With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. >> >> ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) >> >> At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. >> >> ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) >> >> The command line for these comparisons follows: >> >> >> ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jd... > > Kelvin Nilsen has updated the pull request incrementally with two additional commits since the last revision: > > - fix another typo > - Fix typo > Just posting my comments for today, more to follow. Also, this will conflict mightily with #27632. Though I think using the age census to estimate promotion reserves is conceptually compatible with this PR. Agree that these ideas are "conceptually compatible". We'll need to resolve some conflicts between the two efforts. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25357#issuecomment-3724495487 From kdnilsen at openjdk.org Thu Jan 8 16:02:47 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 8 Jan 2026 16:02:47 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v25] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 22:14:15 GMT, William Kemper wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix confusing comment > > src/hotspot/share/gc/shenandoah/heuristics/shenandoahGenerationalHeuristics.cpp line 178: > >> 176: bool need_to_finalize_mixed = false; >> 177: if (_generation->is_young()) { >> 178: need_to_finalize_mixed = heap->old_generation()->heuristics()->prime_collection_set(collection_set); > > We could push this logic for young collections down into `ShenandoahYoungHeuristics::choose_collection_set_from_regiondata` where `_generation` is always `ShenandoahYoungGeneration`. Good catch. Thanks for this suggestion. Much cleaner. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2672932077 From tschatzl at openjdk.org Thu Jan 8 16:37:05 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 8 Jan 2026 16:37:05 GMT Subject: RFR: 8374743: [Leyden] G1 tries to start a concurrent mark allocating a humongous object during initialization Message-ID: Hi all, please review this small change that prevents opportunistic concurrent mark during humongous object allocation when the VM is not initialized yet. Patch provided by @fisk Testing: gha, failing test case Thanks, Thomas ------------- Commit messages: - 8374743 Changes: https://git.openjdk.org/jdk/pull/29119/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29119&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374743 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29119.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29119/head:pull/29119 PR: https://git.openjdk.org/jdk/pull/29119 From eosterlund at openjdk.org Thu Jan 8 16:39:37 2026 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 8 Jan 2026 16:39:37 GMT Subject: RFR: 8374743: [Leyden] G1 tries to start a concurrent mark allocating a humongous object during initialization In-Reply-To: References: Message-ID: <3VkmB9wpThHrZQAE0qdioZQlvUWOfP2L-wV1dWJOwck=.f8b298c5-e335-4324-a555-3f3257d3765d@github.com> On Thu, 8 Jan 2026 16:25:43 GMT, Thomas Schatzl wrote: > Hi all, > > please review this small change that prevents opportunistic concurrent mark during humongous object allocation when the VM is not initialized yet. > > Patch provided by @fisk > > Testing: gha, failing test case > > Thanks, > Thomas Looks great! ------------- Marked as reviewed by eosterlund (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29119#pullrequestreview-3640262276 From iwalulya at openjdk.org Thu Jan 8 17:31:48 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 8 Jan 2026 17:31:48 GMT Subject: RFR: 8374743: [Leyden] G1 tries to start a concurrent mark allocating a humongous object during initialization In-Reply-To: References: Message-ID: <_VK2MhTjQ0n0_rZjDacEsgKLdYhVmLvEkdo4cAE353Q=.1d8d360b-ee91-4b67-9cb5-143ee4143339@github.com> On Thu, 8 Jan 2026 16:25:43 GMT, Thomas Schatzl wrote: > Hi all, > > please review this small change that prevents opportunistic concurrent mark during humongous object allocation when the VM is not initialized yet. > > Patch provided by @fisk > > Testing: gha, failing test case > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29119#pullrequestreview-3640468201 From kdnilsen at openjdk.org Thu Jan 8 17:41:21 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 8 Jan 2026 17:41:21 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v27] In-Reply-To: References: Message-ID: <3iF-Ny42_W-rxUDNFL7LVK4HtcRS8Hf3TiGbYWoWwOo=.55a4093f-c022-410c-8c9f-c0b270bdd194@github.com> > Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). > > This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. > > The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. > > ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) > > With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. > > ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) > > At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. > > ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) > > The command line for these comparisons follows: > > > ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jdk/bin/java \ > -XX:+Unlock... Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Move special handling into ShenandoahYoungHeuristics::choose_collection_set_from_regiondata() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25357/files - new: https://git.openjdk.org/jdk/pull/25357/files/a8520190..1002fb56 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=26 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=25-26 Stats: 100 lines in 22 files changed: 24 ins; 17 del; 59 mod Patch: https://git.openjdk.org/jdk/pull/25357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25357/head:pull/25357 PR: https://git.openjdk.org/jdk/pull/25357 From kdnilsen at openjdk.org Thu Jan 8 17:52:41 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 8 Jan 2026 17:52:41 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v27] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 22:23:05 GMT, William Kemper wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> Move special handling into ShenandoahYoungHeuristics::choose_collection_set_from_regiondata() > > src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 165: > >> 163: } >> 164: >> 165: assert(heap->is_concurrent_weak_root_in_progress(), "Must be doing weak roots now"); > > Was there a reason to remove this `assert`? May have been an accident. I'll put it back in and see what happens. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2673304717 From kdnilsen at openjdk.org Thu Jan 8 17:55:26 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 8 Jan 2026 17:55:26 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v25] In-Reply-To: References: Message-ID: <2eDa-lXiPCUSmVvqX0WSUyuuo9rhH6R8JAzfZhefJeI=.68bb0618-2007-4832-937f-ff999917b941@github.com> On Thu, 8 Jan 2026 00:42:47 GMT, William Kemper wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix confusing comment > > src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 342: > >> 340: } >> 341: >> 342: bool ShenandoahOldHeuristics::top_off_collection_set(ssize_t &add_regions_to_old) { > > Does `add_regions_to_old` really need to be signed? Seems like it will always be non-negative here. Good point. I'm changing to unsigned. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2673318439 From xpeng at openjdk.org Thu Jan 8 17:59:20 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Thu, 8 Jan 2026 17:59:20 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v25] In-Reply-To: References: Message-ID: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Invalid assert ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/ef10341f..47d850d3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=24 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=23-24 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From xpeng at openjdk.org Thu Jan 8 19:42:13 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Thu, 8 Jan 2026 19:42:13 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v20] In-Reply-To: References: <797j9fNWUlV491wWKbFMfthH99o3A5493T0Pcdn_zdc=.417c13b0-8618-4402-aafa-3d86c45c8ff6@github.com> Message-ID: On Wed, 7 Jan 2026 00:03:15 GMT, Kelvin Nilsen wrote: >> Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 265 commits: >> >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - Fix build error after merging from tip >> - Merge branch 'master' into cas-alloc-1 >> - Merge branch 'master' into cas-alloc-1 >> - Some comments updates as suggested in PR review >> - Fix build failure after merge >> - Expend promoted from ShenandoahOldCollectorAllocator >> - Merge branch 'master' into cas-alloc-1 >> - Address PR comments >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - ... and 255 more: https://git.openjdk.org/jdk/compare/de81d389...cf13b7b5 > > src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 423: > >> 421: _yield_to_safepoint = false; >> 422: } >> 423: > > I suppose ShenandoahCollectorAllocator::randomize_start_index() might be a no-op. On the other hand, it would probably be better to use a random index for ShenandoahCollectorAllocator as well. We don't want to hobble one GC worker more than the others just because its preferred start index happens to hold a retire-ready region. The code you put comments on is ShenandoahOldCollectorAllocator, which delegate the allocation to ShenandoahFreeSet in the PR, 0u in passed to ShenandoahAllocator constructor is the number of shared alloc regions, which should be 0. I'll work on ShenandoahOldCollectorAllocator to make it support CAS as well. The start index of ShenandoahCollectorAllocator is slightly different from ShenandoahMutatorAllocator, for GC worker we can always use `worker_id % _alloc_region_count`, but there is some corner cases we need to consider, e.g. Java thread may call into ShenandoahCollectorAllocator from load barrier code. Currently for non worker threads, the start index is always 0, I think this is the part we can change it to random. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2673640072 From xpeng at openjdk.org Thu Jan 8 19:42:15 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Thu, 8 Jan 2026 19:42:15 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v20] In-Reply-To: References: <797j9fNWUlV491wWKbFMfthH99o3A5493T0Pcdn_zdc=.417c13b0-8618-4402-aafa-3d86c45c8ff6@github.com> Message-ID: <8R0cFKoikfdToCQl3attk5YODAjTt3IExowjM8YqnNk=.04470378-016f-474d-9529-7e35b976b154@github.com> On Wed, 7 Jan 2026 14:51:49 GMT, Kelvin Nilsen wrote: >> src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 428: >> >>> 426: } >>> 427: >>> 428: HeapWord* ShenandoahOldCollectorAllocator::allocate(ShenandoahAllocRequest& req, bool& in_new_region) { >> >> Confer with William Kemper about this. He is working on a change that may simplify the handling of PLABs, in which case ShenandoahOldCollectorAllocator can behave the same as ShenandoahCollector. > > Alternatively, I don't think it would be too terribly difficult to implement try_allocate_aligned() function to support fast (CAS) allocation of aligned PLABs. It is doable and not very difficult. I'll work on it in a following PR to make ShenandoahOldCollectorAllocator support CAS. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2673645194 From xpeng at openjdk.org Thu Jan 8 20:01:29 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Thu, 8 Jan 2026 20:01:29 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v20] In-Reply-To: References: <797j9fNWUlV491wWKbFMfthH99o3A5493T0Pcdn_zdc=.417c13b0-8618-4402-aafa-3d86c45c8ff6@github.com> Message-ID: On Tue, 6 Jan 2026 01:21:21 GMT, Kelvin Nilsen wrote: >> Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 265 commits: >> >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - Fix build error after merging from tip >> - Merge branch 'master' into cas-alloc-1 >> - Merge branch 'master' into cas-alloc-1 >> - Some comments updates as suggested in PR review >> - Fix build failure after merge >> - Expend promoted from ShenandoahOldCollectorAllocator >> - Merge branch 'master' into cas-alloc-1 >> - Address PR comments >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - ... and 255 more: https://git.openjdk.org/jdk/compare/de81d389...cf13b7b5 > > src/hotspot/share/gc/shenandoah/shenandoahAllocator.hpp line 79: > >> 77: int refresh_alloc_regions(ShenandoahAllocRequest* req = nullptr, bool* in_new_region = nullptr, HeapWord** obj = nullptr); >> 78: #ifdef ASSERT >> 79: virtual void verify(ShenandoahAllocRequest& req) { } > > Need a comment to explain what verify does. Is this simply checking to make sure the req is "properly formatted"? I think the intention is to enforce that req affiliation corresponds to ALLOC_PARTITION. Would be good to clarify this in the comment. > > Do we need this to be virtual? It seems like a single templated implementation would suffice. Yes, it can be templated implementation, I'll update the implementation to use template. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2673695164 From kdnilsen at openjdk.org Thu Jan 8 20:02:08 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 8 Jan 2026 20:02:08 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v28] In-Reply-To: References: Message-ID: <8sbofUK4dq_bIjHCI_XbpwPqJ8JePmr-b9REQnis5tA=.80b63d85-fe38-4c08-9c9c-e98ff262a557@github.com> > Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). > > This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. > > The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. > > ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) > > With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. > > ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) > > At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. > > ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) > > The command line for these comparisons follows: > > > ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jdk/bin/java \ > -XX:+Unlock... Kelvin Nilsen has updated the pull request incrementally with two additional commits since the last revision: - Move rebuild free set earlier in an abbreviated GC cycle - Restore deleted assert statement ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25357/files - new: https://git.openjdk.org/jdk/pull/25357/files/1002fb56..2013599d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=27 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=26-27 Stats: 12 lines in 1 file changed: 8 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25357/head:pull/25357 PR: https://git.openjdk.org/jdk/pull/25357 From kevinw at openjdk.org Thu Jan 8 20:05:54 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 8 Jan 2026 20:05:54 GMT Subject: RFR: 8374825: vmTestbase comment typo: lunch Message-ID: Trivial but confusing test comment/documentation cleanup. Remove confusing typo and reference to preallocated exceptions in the eatMemory routines. ------------- Commit messages: - 8374825: vmTestbase comment typo: unrelated to lunch Changes: https://git.openjdk.org/jdk/pull/29126/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29126&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374825 Stats: 18 lines in 2 files changed: 0 ins; 12 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/29126.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29126/head:pull/29126 PR: https://git.openjdk.org/jdk/pull/29126 From xpeng at openjdk.org Thu Jan 8 20:41:47 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Thu, 8 Jan 2026 20:41:47 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v20] In-Reply-To: References: <797j9fNWUlV491wWKbFMfthH99o3A5493T0Pcdn_zdc=.417c13b0-8618-4402-aafa-3d86c45c8ff6@github.com> Message-ID: On Tue, 6 Jan 2026 02:04:04 GMT, Kelvin Nilsen wrote: >> Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 265 commits: >> >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - Fix build error after merging from tip >> - Merge branch 'master' into cas-alloc-1 >> - Merge branch 'master' into cas-alloc-1 >> - Some comments updates as suggested in PR review >> - Fix build failure after merge >> - Expend promoted from ShenandoahOldCollectorAllocator >> - Merge branch 'master' into cas-alloc-1 >> - Address PR comments >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - ... and 255 more: https://git.openjdk.org/jdk/compare/de81d389...cf13b7b5 > > src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 364: > >> 362: _free_set->partitions()->decrease_used(ALLOC_PARTITION, total_free_bytes); >> 363: _free_set->partitions()->increase_region_counts(ALLOC_PARTITION, total_regions_to_unretire); >> 364: accounting_updater._need_update = true; > > Here is where you know which tallies have been affected by this operation. This is where you should specialize the calls to freeset recompute_total_used() and recompute_total_affiliated(). Either call those from here, or add parameters to your accounting_updater object so that you do not have to overcompute each operation. This is not the only place, there are many other places in the allocation code path as well, I can specialize the calls to recompute_total_used and recompute_total_affiliated in the places, but that will make the code necessary rambling, I'd rather to solve this issue and simplify it in https://bugs.openjdk.org/browse/JDK-8373371. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2673820942 From kdnilsen at openjdk.org Thu Jan 8 20:49:13 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 8 Jan 2026 20:49:13 GMT Subject: Integrated: 8373714: Shenandoah: Register heuristic penalties following a degenerated GC In-Reply-To: References: Message-ID: On Mon, 15 Dec 2025 21:53:02 GMT, Kelvin Nilsen wrote: > Add a triggering penalty when we execute degenerated GC cycle. This pull request has now been integrated. Changeset: 385c4f81 Author: Kelvin Nilsen URL: https://git.openjdk.org/jdk/commit/385c4f8180d30c0e41b848eb4b2c1c8788211422 Stats: 12 lines in 7 files changed: 4 ins; 0 del; 8 mod 8373714: Shenandoah: Register heuristic penalties following a degenerated GC Reviewed-by: wkemper ------------- PR: https://git.openjdk.org/jdk/pull/28834 From kdnilsen at openjdk.org Thu Jan 8 22:53:43 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 8 Jan 2026 22:53:43 GMT Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need accurate live_data [v16] In-Reply-To: References: Message-ID: <16mCKOBudyw5oGH_yFiwBPCBwsJrjugRyTWDmuA8Q2g=.ee646318-ba2b-4599-8a46-acdc41e5aa78@github.com> > The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected. In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region. This is typically ok for young regions, where the amount of live data determines whether a region should be added to the collection set during the final-mark safepoint. > > However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated. In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended. > > This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions. Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 62 commits: - Merge remote-tracking branch 'jdk/master' into fix-live-data-for-mixed-evac-candidates - touch file to force retest - Finish merge - Merge remote-tracking branch 'jdk/master' into fix-live-data-for-mixed-evac-candidates - Fix mistaken merge resolution - Merge remote-tracking branch 'jdk/master' into fix-live-data-for-mixed-evac-candidates The resulting fastdebug build has 64 failures. I need to debug these. Probably introduced by improper resolution of merge conflicts - fix error in merge conflict resolution - Merge remote-tracking branch 'jdk/master' into fix-live-data-for-mixed-evac-candidates - rework CompressedClassSpaceSizeinJmapHeap.java - fix errors in CompressedClassSpaceSizeInJmapHeap.java - ... and 52 more: https://git.openjdk.org/jdk/compare/385c4f81...6d10ae5a ------------- Changes: https://git.openjdk.org/jdk/pull/24319/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24319&range=15 Stats: 282 lines in 32 files changed: 109 ins; 31 del; 142 mod Patch: https://git.openjdk.org/jdk/pull/24319.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24319/head:pull/24319 PR: https://git.openjdk.org/jdk/pull/24319 From wkemper at openjdk.org Thu Jan 8 22:56:32 2026 From: wkemper at openjdk.org (William Kemper) Date: Thu, 8 Jan 2026 22:56:32 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v4] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 20:56:51 GMT, Kelvin Nilsen wrote: >> After studying large numbers of GC logs with degenerated cycles that have resulted from "late" triggers, we propose the following general improvements: >> >> 1. Track trends in GC times rather than always using the average GC time plus standard deviation. In many situations, GC times trend upward due to, for example, increasing amounts of live data that must be marked as a workload builds up its working set of memory. >> 2. Sample allocation rates more frequently than once every 100 ms. >> 3. Track trends in allocation rates. In some situations, the allocation rate trends upwards due to, for example, the start of a new phase of execution or a spike in client workload. >> 4. When we detect acceleration of allocation rate, predict consumption of memory based on accelerated allocation rates rather than assuming constant allocation rate. > > Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits: > > - Fix comment > - Use PROPERFMT macros > - Simplify code flow: reviewer suggestion > - Merge remote-tracking branch 'jdk/master' into accelerated-triggers > - Remove develop/debug instrumentation > - add another override > - Change type of command-line args > - fix white space > - Add override to virtual methods > - Fix race between allocation reporting and querying > - ... and 55 more: https://git.openjdk.org/jdk/compare/dd20e915...7f3a6d1e Changes requested by wkemper (Reviewer). src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 134: > 132: if (_is_generational) { > 133: _regulator_thread = ShenandoahGenerationalHeap::heap()->regulator_thread(); > 134: size_t young_available = ShenandoahGenerationalHeap::heap()->young_generation()->max_capacity() - Consider pushing this down into `ShenandoahGenerationalHeuristics` src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 145: > 143: } > 144: > 145: double ShenandoahAdaptiveHeuristics::get_most_recent_wake_time() const { This introduces a cyclic dependency between control/regulator threads and the heuristics. Since control/regulator threads already _know_ about heuristics, could we instead have the threads invoke setters on the heuristics to provide these values? src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 192: > 190: > 191: void ShenandoahAdaptiveHeuristics::resume_idle_span() { > 192: size_t mutator_available = _free_set->capacity() - _free_set->used(); This is a little confusing to me. Isn't `available` defined as `capacity - used`? Why do we not use `available` here? src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 715: > 713: > 714: if (ShenandoahHeuristics::should_start_gc()) { > 715: // ShenandoahHeuristics::should_start_gc() has accepted trigger, or declined it. return ShenandoahHeuristics::should_start_gc(); src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp line 73: > 71: bool is_spiking(double rate, double threshold) const; > 72: > 73: double interval() const { Not seeing where these new methods are used. src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp line 316: > 314: if (progress) { > 315: heap->notify_gc_progress(); > 316: heap->shenandoah_policy()->record_success_degenerated(_generation->is_young(), _abbreviated); On line 313 above here, we call `policy->record_degenerated` which does everything (and more) that `record_success_degenerated` does. Calling both of them here will increment the various counters twice and is probably not what we want. I think after https://github.com/openjdk/jdk/pull/28834, we shouldn't need `record_success_degenerated` for `ShenandoahCollectorPolicy` at all. src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 493: > 491: ShenandoahCodeRoots::initialize(); > 492: > 493: // Initialization of controller markes use of varaibles esstablished by initialize_heuristics. Suggestion: // Initialization of controller makes use of variables established by initialize_heuristics. ------------- PR Review: https://git.openjdk.org/jdk/pull/29039#pullrequestreview-3641395012 PR Review Comment: https://git.openjdk.org/jdk/pull/29039#discussion_r2673966020 PR Review Comment: https://git.openjdk.org/jdk/pull/29039#discussion_r2673969760 PR Review Comment: https://git.openjdk.org/jdk/pull/29039#discussion_r2674066185 PR Review Comment: https://git.openjdk.org/jdk/pull/29039#discussion_r2674110503 PR Review Comment: https://git.openjdk.org/jdk/pull/29039#discussion_r2674122093 PR Review Comment: https://git.openjdk.org/jdk/pull/29039#discussion_r2674156144 PR Review Comment: https://git.openjdk.org/jdk/pull/29039#discussion_r2674168920 From xpeng at openjdk.org Thu Jan 8 23:54:32 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Thu, 8 Jan 2026 23:54:32 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v26] In-Reply-To: References: Message-ID: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 273 commits: - Merge branch 'openjdk:master' into cas-alloc-1 - Invalid assert - Merge branch 'openjdk:master' into cas-alloc-1 - No need to use Atomic::load to read shared alloc region in release_alloc_regions - No need to use Atomic::load to read shared alloc region in refresh_alloc_regions - Update code comments - Update assert message - Only use atomic allocation when allocate from shared alloc regions - Merge branch 'openjdk:master' into cas-alloc-1 - Fix build error after merging from tip - ... and 263 more: https://git.openjdk.org/jdk/compare/385c4f81...0b04841f ------------- Changes: https://git.openjdk.org/jdk/pull/26171/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=25 Stats: 1656 lines in 25 files changed: 1308 ins; 235 del; 113 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From xpeng at openjdk.org Fri Jan 9 02:03:23 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 9 Jan 2026 02:03:23 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v27] In-Reply-To: References: Message-ID: <70wd2_KAjCsqW4zFSUowSWL6ajQoRTntUcDkk5NqJmA=.90dfd7dc-3021-4200-b046-26a4f138d712@github.com> > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request incrementally with three additional commits since the last revision: - Merge branch 'cas-alloc-1' of https://github.com/pengxiaolong/jdk into cas-alloc-1 - Use template parameter for ShenandoahAllocator::verify - Avoid AtomicAccess::load in attempt_allocation_in_alloc_regions when called from attempt_allocation_slow ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/0b04841f..4d5722a3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=26 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=25-26 Stats: 49 lines in 2 files changed: 18 ins; 25 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From xpeng at openjdk.org Fri Jan 9 05:42:49 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 9 Jan 2026 05:42:49 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v28] In-Reply-To: References: Message-ID: <9GEqwfh0vWkOCxSOcMcslcvsFG-LVeD9bDaEyWqS7j8=.fc40f588-0df9-4928-b8c3-a3dea1346217@github.com> > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: add include header shenandoahAllocRequest.hpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/4d5722a3..f299e165 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=27 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=26-27 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From xpeng at openjdk.org Fri Jan 9 06:02:02 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 9 Jan 2026 06:02:02 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v29] In-Reply-To: References: Message-ID: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Fix header file order ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/f299e165..dbee5568 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=28 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=27-28 Stats: 3 lines in 1 file changed: 2 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From xpeng at openjdk.org Fri Jan 9 06:36:29 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 9 Jan 2026 06:36:29 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v30] In-Reply-To: References: Message-ID: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Fix include error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/dbee5568..6a8297ac Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=29 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=28-29 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From sjohanss at openjdk.org Fri Jan 9 06:52:07 2026 From: sjohanss at openjdk.org (Stefan Johansson) Date: Fri, 9 Jan 2026 06:52:07 GMT Subject: RFR: 8374743: [Leyden] G1 tries to start a concurrent mark allocating a humongous object during initialization In-Reply-To: References: Message-ID: <3vGK1afPBwwuAwiefryokMaOhKjXsoq-r4ufefec5iI=.57e3a898-1549-404f-90ee-934ad5126c55@github.com> On Thu, 8 Jan 2026 16:25:43 GMT, Thomas Schatzl wrote: > Hi all, > > please review this small change that prevents opportunistic concurrent mark during humongous object allocation when the VM is not initialized yet. > > Patch provided by @fisk > > Testing: gha, failing test case > > Thanks, > Thomas Marked as reviewed by sjohanss (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29119#pullrequestreview-3642623312 From xpeng at openjdk.org Fri Jan 9 08:09:25 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 9 Jan 2026 08:09:25 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v31] In-Reply-To: References: Message-ID: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: 1. Allow to reserve alloc region with free space >= PLAB::min_size() 2. Other minor fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/6a8297ac..7e0a1244 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=30 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=29-30 Stats: 11 lines in 1 file changed: 1 ins; 6 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From tschatzl at openjdk.org Fri Jan 9 08:31:12 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 9 Jan 2026 08:31:12 GMT Subject: RFR: 8374825: vmTestbase comment typo: lunch In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 19:58:21 GMT, Kevin Walls wrote: > Trivial but confusing test comment/documentation cleanup. > > Remove confusing typo and reference to preallocated exceptions in the eatMemory routines. Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29126#pullrequestreview-3642885139 From tschatzl at openjdk.org Fri Jan 9 08:33:55 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 9 Jan 2026 08:33:55 GMT Subject: RFR: 8340470: G1: Adopt PartialArrayState to consolidate marking stack in Full GC [v3] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 15:11:03 GMT, Ivan Walulya wrote: >> Hi, >> >> Please review this change adopting `PartialArrayState` introduced by [JDK-8337709](https://bugs.openjdk.org/browse/JDK-8337709) to consolidate marking queue sets (oop queue set and objArray queue set) into single queue set in G1 Full GC. >> >> Testing: Tier 1-5 > > Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: > > Thomas Review Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29114#pullrequestreview-3642891124 From jnorlinder at openjdk.org Fri Jan 9 08:44:21 2026 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Fri, 9 Jan 2026 08:44:21 GMT Subject: Integrated: 8373695: G1: Using a value near integer max for ActiveProcessorCount causes fatal crash In-Reply-To: References: Message-ID: On Mon, 15 Dec 2025 19:46:14 GMT, Jonas Norlinder wrote: > G1ConcRefinementThreads default value depends on ParallelGCThreads which in turn may depend on ActiveProcessorCount. These have different ranges that are valid. Patch will ensure argument setup code never try to assign a value larger than what G1ConcRefinementThreads expects. This pull request has now been integrated. Changeset: a8552243 Author: Jonas Norlinder Committer: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/a855224305e025aea80165ae63ee921dca299b9c Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8373695: G1: Using a value near integer max for ActiveProcessorCount causes fatal crash Reviewed-by: stefank, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/28831 From sjohanss at openjdk.org Fri Jan 9 08:47:01 2026 From: sjohanss at openjdk.org (Stefan Johansson) Date: Fri, 9 Jan 2026 08:47:01 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v3] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 12:58:43 GMT, Leo Korinth wrote: >> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. >> >> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. >> >> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. >> >> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. > > Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 564 commits: > > - Merge branch '8373253' into 8367993 > - Merge branch 'master' into _8373253 > - Merge branch 'master' into _8367993 > - 8366058: Outdated comment in WinCAPISeedGenerator > > Reviewed-by: mullan > - 8357258: x86: Improve receiver type profiling reliability > > Reviewed-by: kvn, vlivanov > - 8373704: Improve "SocketException: Protocol family unavailable" message > > Reviewed-by: lucy, jpai > - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently > > Reviewed-by: jiefu, jbhateja, erfang, qamai > - 8343809: Add requires tag to mark tests that are incompatible with exploded image > > Reviewed-by: alanb, dholmes > - 8374465: Spurious dot in documentation for JVMTI ClassLoad > > Reviewed-by: kbarrett > - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket > > Reviewed-by: djelinski, mpowers, ascarpino > - ... and 554 more: https://git.openjdk.org/jdk/compare/2aa8aa4b...28ccbb68 Thanks for looking into this Leo. Overall I think it looks good, just some small questions and suggestions. src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1637: > 1635: > 1636: bool G1CollectedHeap::concurrent_mark_is_terminating() const { > 1637: assert(_cm != nullptr, "thread must exist in order to check if mark is terminating"); I think it would make sense to add `&& _cm->is_fully_initialized()` to really make sure the thread has been created. src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2427: > 2425: if (_cm->is_fully_initialized()) { > 2426: tc->do_thread(_cm->cm_thread()); > 2427: } Since the _cm_thread is now in `G1ConcurrentMark` this should be handled in `G1ConcurrentMark::threads_do()` src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2549: > 2547: void G1CollectedHeap::start_concurrent_cycle(bool concurrent_operation_is_full_mark) { > 2548: assert(!_cm->in_progress(), "Can not start concurrent operation while in progress"); > 2549: assert(_cm->is_fully_initialized(), "sanity"); Not sure this sanity assert is needed `_cm->in_progress()` will always return `false` if not fully initialized, so the above assert will cover this. If we still want it, I think it should be moved above the `in_progress()` assert. src/hotspot/share/gc/g1/g1PeriodicGCTask.cpp line 46: > 44: return false; > 45: } > 46: Why is this needed? The initial young collection will make sure concurrent marking gets initialized, right? src/hotspot/share/gc/g1/g1Policy.cpp line 744: > 742: if (!_g1h->concurrent_mark()->is_fully_initialized()) { > 743: return false; > 744: } Is this needed? The `in_progress()` check below makes sure to only check the cm_thread when fully initialized. src/hotspot/share/gc/g1/g1YoungCollector.cpp line 1127: > 1125: > 1126: void G1YoungCollector::collect() { > 1127: _g1h->_cm->fully_initialize(); I think it would make more sense to do this in `G1CollectedHeap::do_collection_pause_at_safepoint()`. There we check if we should start concurrent mark, so maybe the initialization could be done only if we are about to start concurrent mark. If we can do the initialization after the actual young collection, then we could maybe even move the initialization into `G1CollectedHeap::start_concurrent_cycle(...)` ------------- Changes requested by sjohanss (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28723#pullrequestreview-3639436840 PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2672366755 PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675276733 PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675291347 PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675313622 PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675328503 PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675249630 From stefank at openjdk.org Fri Jan 9 08:49:29 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 9 Jan 2026 08:49:29 GMT Subject: RFR: 8373941: Epsilon: Robust counter updates in early VM phases In-Reply-To: References: Message-ID: <1IgEb9XbyZW6cC0B2dk9i_QcE7_HY-haHD1bSC4VK0g=.9f23fcf7-56ff-45cf-8505-f519c16d433e@github.com> On Tue, 6 Jan 2026 10:38:13 GMT, Aleksey Shipilev wrote: > See more details in the bug. This PR makes the counters updated on allocation path more robust. New regression test captures the original failure (intermittently). This would be also backported to JDK 26. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `gc/epsilon`, 100x > - [x] Linux x86_64 server fastdebug, `runtime/cds/appcds/TestEpsilonGCWithCDS.java`, 100x > - [x] Linux x86_64 server fastdebug, `gc/epsilon/TestInitAllocs.java`, 1000x Looks good to me. Kim would probably prefer if you changed the `volatile bool _ready` to use the new `Atomic` class. src/hotspot/share/gc/epsilon/epsilonHeap.cpp line 158: > 156: // At this point, some diagnostic subsystems might not yet be initialized. > 157: // We pretend the printout happened either way. This keeps allocation path > 158: // from obscessively checking the subsystems status on every allocation. Suggestion: // from obsessively checking the subsystem's status on every allocation. ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29061#pullrequestreview-3642939859 PR Review Comment: https://git.openjdk.org/jdk/pull/29061#discussion_r2675335690 From shade at openjdk.org Fri Jan 9 09:08:06 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 9 Jan 2026 09:08:06 GMT Subject: RFR: 8373941: Epsilon: Robust counter updates in early VM phases [v2] In-Reply-To: References: Message-ID: > See more details in the bug. This PR makes the counters updated on allocation path more robust. New regression test captures the original failure (intermittently). This would be also backported to JDK 26. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `gc/epsilon`, 100x > - [x] Linux x86_64 server fastdebug, `runtime/cds/appcds/TestEpsilonGCWithCDS.java`, 100x > - [x] Linux x86_64 server fastdebug, `gc/epsilon/TestInitAllocs.java`, 1000x 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 three additional commits since the last revision: - Merge branch 'master' into JDK-8373941-epsilon-robust-counter-updates - Typos - Fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29061/files - new: https://git.openjdk.org/jdk/pull/29061/files/9a450be5..1c347b7d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29061&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29061&range=00-01 Stats: 17104 lines in 535 files changed: 3289 ins; 2184 del; 11631 mod Patch: https://git.openjdk.org/jdk/pull/29061.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29061/head:pull/29061 PR: https://git.openjdk.org/jdk/pull/29061 From shade at openjdk.org Fri Jan 9 09:08:08 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 9 Jan 2026 09:08:08 GMT Subject: RFR: 8373941: Epsilon: Robust counter updates in early VM phases [v2] In-Reply-To: <1IgEb9XbyZW6cC0B2dk9i_QcE7_HY-haHD1bSC4VK0g=.9f23fcf7-56ff-45cf-8505-f519c16d433e@github.com> References: <1IgEb9XbyZW6cC0B2dk9i_QcE7_HY-haHD1bSC4VK0g=.9f23fcf7-56ff-45cf-8505-f519c16d433e@github.com> Message-ID: <2rSuNCLbhy5C9NbabNoNYU_bsYNm5sY3-I0tWezas64=.4fa361f4-8d0f-42be-a2b9-062a25e3cf24@github.com> On Fri, 9 Jan 2026 08:46:05 GMT, Stefan Karlsson wrote: > Kim would probably prefer if you changed the `volatile bool _ready` to use the new `Atomic` class. Right. There are other cases in Epsilon that would enjoy this conversion. Tell you what, let's do this version (so that is also easily backportable), and then I'll do a cleanup that converts all Epsilon code to `Atomic`: https://bugs.openjdk.org/browse/JDK-8374876 > src/hotspot/share/gc/epsilon/epsilonHeap.cpp line 158: > >> 156: // At this point, some diagnostic subsystems might not yet be initialized. >> 157: // We pretend the printout happened either way. This keeps allocation path >> 158: // from obscessively checking the subsystems status on every allocation. > > Suggestion: > > // from obsessively checking the subsystem's status on every allocation. Done, should really be `subsystems`` :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/29061#issuecomment-3727918649 PR Review Comment: https://git.openjdk.org/jdk/pull/29061#discussion_r2675379600 From shade at openjdk.org Fri Jan 9 10:12:22 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 9 Jan 2026 10:12:22 GMT Subject: RFR: 8374825: vmTestbase comment typo: lunch In-Reply-To: References: Message-ID: <0jMNRNNJkfnXJE6pGtP-vdIWzN-kXMcilpFXqfyCtq8=.b8196894-2d1f-4375-be55-e924bafa0736@github.com> On Thu, 8 Jan 2026 19:58:21 GMT, Kevin Walls wrote: > Trivial but confusing test comment/documentation cleanup. > > Remove confusing typo and reference to preallocated exceptions in the eatMemory routines. Of course, it should have been "dinner" to begin with! ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29126#pullrequestreview-3643262497 From kevinw at openjdk.org Fri Jan 9 10:23:43 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 9 Jan 2026 10:23:43 GMT Subject: RFR: 8374825: vmTestbase comment typo: lunch In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 19:58:21 GMT, Kevin Walls wrote: > Trivial but confusing test comment/documentation cleanup. > > Remove confusing typo and reference to preallocated exceptions in the eatMemory routines. Thanks Thomas and Aleksey! The whole meal-based metaphor was stretched too far... 8-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/29126#issuecomment-3728290931 From kevinw at openjdk.org Fri Jan 9 10:25:32 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 9 Jan 2026 10:25:32 GMT Subject: Integrated: 8374825: vmTestbase comment typo: lunch In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 19:58:21 GMT, Kevin Walls wrote: > Trivial but confusing test comment/documentation cleanup. > > Remove confusing typo and reference to preallocated exceptions in the eatMemory routines. This pull request has now been integrated. Changeset: c8c6e700 Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/c8c6e7007aec9a568c25dcd5d4242b7911a83bfe Stats: 18 lines in 2 files changed: 0 ins; 12 del; 6 mod 8374825: vmTestbase comment typo: lunch Reviewed-by: tschatzl, shade ------------- PR: https://git.openjdk.org/jdk/pull/29126 From iwalulya at openjdk.org Fri Jan 9 11:59:17 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Fri, 9 Jan 2026 11:59:17 GMT Subject: RFR: 8238686: G1 may waste lots of space or fail to uncommit when observing MinHeapFreeRatio during sizing after full gc Message-ID: <2CtP_aXZRdMpMM7MerGDY2WYvgJks7YMVHlQEYgItZI=.50a0dd11-5f58-4780-9a63-55dfe921c03d@github.com> Hi, Please review this change which modifies the defaults for the `MinHeapFreeRatio` and `MaxHeapFreeRatio` flags in G1 so that they do not affect heap sizing unless explicitly set by the user. Previously, these flags could trigger heap resizing at the end of Full GC, potentially overriding the G1 ergonomic heap sizing heuristics, which may be unexpected for the user. In particular, for workloads that frequently invoke `System.gc()`, the heap could shrink at the end of the Full GC and then expand aggressively during subsequent GCs (see image below). shrink_expand_flip_flop With this update, the default values for `MinHeapFreeRatio` and `MaxHeapFreeRatio` no longer affect heap resizing. These flags will only take effect when explicitly set by the user.. Additionally, pause times from user-triggered `System.gc()` invocations will be excluded from the data used to update heap sizing heuristics. Because these GCs are user-initiated and do not reflect actual GC pressure, including their pause times can skew GC Pause Time ratios used for heap sizing decisions. Testing: Tier 1 and JavaPerf. ------------- Commit messages: - update - Merge branch 'master' into G1ResizeAfterFullGC_v1 - Ignore Defaults MinHeapFreeRatio-MaxHeapFreeRatio - init Changes: https://git.openjdk.org/jdk/pull/29137/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29137&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8238686 Stats: 47 lines in 4 files changed: 17 ins; 7 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/29137.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29137/head:pull/29137 PR: https://git.openjdk.org/jdk/pull/29137 From shade at openjdk.org Fri Jan 9 11:59:37 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 9 Jan 2026 11:59:37 GMT Subject: RFR: 8374743: G1 starts a concurrent mark when allocating humongous objects during initialization In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 16:25:43 GMT, Thomas Schatzl wrote: > Hi all, > > please review this small change that prevents opportunistic concurrent mark during humongous object allocation when the VM is not initialized yet. > > Patch provided by @fisk > > Testing: gha, failing test case > > Thanks, > Thomas Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29119#pullrequestreview-3643618479 From stefank at openjdk.org Fri Jan 9 12:07:07 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 9 Jan 2026 12:07:07 GMT Subject: RFR: 8373941: Epsilon: Robust counter updates in early VM phases [v2] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 09:08:06 GMT, Aleksey Shipilev wrote: >> See more details in the bug. This PR makes the counters updated on allocation path more robust. New regression test captures the original failure (intermittently). This would be also backported to JDK 26. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `gc/epsilon`, 100x >> - [x] Linux x86_64 server fastdebug, `runtime/cds/appcds/TestEpsilonGCWithCDS.java`, 100x >> - [x] Linux x86_64 server fastdebug, `gc/epsilon/TestInitAllocs.java`, 1000x > > 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 three additional commits since the last revision: > > - Merge branch 'master' into JDK-8373941-epsilon-robust-counter-updates > - Typos > - Fix Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29061#pullrequestreview-3643647561 From stefank at openjdk.org Fri Jan 9 12:07:12 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 9 Jan 2026 12:07:12 GMT Subject: RFR: 8373941: Epsilon: Robust counter updates in early VM phases [v2] In-Reply-To: <2rSuNCLbhy5C9NbabNoNYU_bsYNm5sY3-I0tWezas64=.4fa361f4-8d0f-42be-a2b9-062a25e3cf24@github.com> References: <1IgEb9XbyZW6cC0B2dk9i_QcE7_HY-haHD1bSC4VK0g=.9f23fcf7-56ff-45cf-8505-f519c16d433e@github.com> <2rSuNCLbhy5C9NbabNoNYU_bsYNm5sY3-I0tWezas64=.4fa361f4-8d0f-42be-a2b9-062a25e3cf24@github.com> Message-ID: On Fri, 9 Jan 2026 09:00:39 GMT, Aleksey Shipilev wrote: >> src/hotspot/share/gc/epsilon/epsilonHeap.cpp line 158: >> >>> 156: // At this point, some diagnostic subsystems might not yet be initialized. >>> 157: // We pretend the printout happened either way. This keeps allocation path >>> 158: // from obscessively checking the subsystems status on every allocation. >> >> Suggestion: >> >> // from obsessively checking the subsystem's status on every allocation. > > Done, should really be `subsystems`` :) :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29061#discussion_r2675943819 From stefank at openjdk.org Fri Jan 9 12:09:22 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 9 Jan 2026 12:09:22 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 12:33:41 GMT, Leo Korinth wrote: >> Leo Korinth has updated the pull request incrementally with 561 additional commits since the last revision: >> >> - Merge branch 'master' into _8367993 >> - 8366058: Outdated comment in WinCAPISeedGenerator >> >> Reviewed-by: mullan >> - 8357258: x86: Improve receiver type profiling reliability >> >> Reviewed-by: kvn, vlivanov >> - 8373704: Improve "SocketException: Protocol family unavailable" message >> >> Reviewed-by: lucy, jpai >> - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently >> >> Reviewed-by: jiefu, jbhateja, erfang, qamai >> - 8343809: Add requires tag to mark tests that are incompatible with exploded image >> >> Reviewed-by: alanb, dholmes >> - 8374465: Spurious dot in documentation for JVMTI ClassLoad >> >> Reviewed-by: kbarrett >> - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket >> >> Reviewed-by: djelinski, mpowers, ascarpino >> - 8374444: Fix simple -Wzero-as-null-pointer-constant warnings >> >> Reviewed-by: aboldtch >> - 8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the ?Nothing? menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test >> >> Reviewed-by: serb, aivanov, dnguyen >> - ... and 551 more: https://git.openjdk.org/jdk/compare/b907b295...0ece3767 > > I will redo the merge, I have done something strange. @lkorinth Something went wrong with your merge and now there's a bunch of unrelated labels, which results in updates being sent to misc mailing lists that has no interest in this PR. Could you remove all those labels? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28723#issuecomment-3728642315 From tschatzl at openjdk.org Fri Jan 9 12:22:40 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 9 Jan 2026 12:22:40 GMT Subject: RFR: 8373941: Epsilon: Robust counter updates in early VM phases [v2] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 09:08:06 GMT, Aleksey Shipilev wrote: >> See more details in the bug. This PR makes the counters updated on allocation path more robust. New regression test captures the original failure (intermittently). This would be also backported to JDK 26. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `gc/epsilon`, 100x >> - [x] Linux x86_64 server fastdebug, `runtime/cds/appcds/TestEpsilonGCWithCDS.java`, 100x >> - [x] Linux x86_64 server fastdebug, `gc/epsilon/TestInitAllocs.java`, 1000x > > 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 three additional commits since the last revision: > > - Merge branch 'master' into JDK-8373941-epsilon-robust-counter-updates > - Typos > - Fix Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29061#pullrequestreview-3643697000 From shade at openjdk.org Fri Jan 9 12:27:15 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 9 Jan 2026 12:27:15 GMT Subject: RFR: 8373941: Epsilon: Robust counter updates in early VM phases [v2] In-Reply-To: References: Message-ID: <6Ehmb4fKRE5V-hjgpJevusM7fjcZXZnqCiysG6YSPFc=.2e592e20-9fa9-452d-991d-a0794b464dcf@github.com> On Fri, 9 Jan 2026 12:03:18 GMT, Stefan Karlsson 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 three additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8373941-epsilon-robust-counter-updates >> - Typos >> - Fix > > Marked as reviewed by stefank (Reviewer). Thanks for reviews, @stefank, @tschatzl! Here goes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29061#issuecomment-3728696991 From lkorinth at openjdk.org Fri Jan 9 15:05:35 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Fri, 9 Jan 2026 15:05:35 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 12:33:41 GMT, Leo Korinth wrote: >> Leo Korinth has updated the pull request incrementally with 561 additional commits since the last revision: >> >> - Merge branch 'master' into _8367993 >> - 8366058: Outdated comment in WinCAPISeedGenerator >> >> Reviewed-by: mullan >> - 8357258: x86: Improve receiver type profiling reliability >> >> Reviewed-by: kvn, vlivanov >> - 8373704: Improve "SocketException: Protocol family unavailable" message >> >> Reviewed-by: lucy, jpai >> - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently >> >> Reviewed-by: jiefu, jbhateja, erfang, qamai >> - 8343809: Add requires tag to mark tests that are incompatible with exploded image >> >> Reviewed-by: alanb, dholmes >> - 8374465: Spurious dot in documentation for JVMTI ClassLoad >> >> Reviewed-by: kbarrett >> - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket >> >> Reviewed-by: djelinski, mpowers, ascarpino >> - 8374444: Fix simple -Wzero-as-null-pointer-constant warnings >> >> Reviewed-by: aboldtch >> - 8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the ?Nothing? menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test >> >> Reviewed-by: serb, aivanov, dnguyen >> - ... and 551 more: https://git.openjdk.org/jdk/compare/b907b295...0ece3767 > > I will redo the merge, I have done something strange. > @lkorinth Something went wrong with your merge and now there's a bunch of unrelated labels, which results in updates being sent to misc mailing lists that has no interest in this PR. Could you remove all those labels? Fixed, sorry. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28723#issuecomment-3729237961 From lkorinth at openjdk.org Fri Jan 9 15:27:55 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Fri, 9 Jan 2026 15:27:55 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v3] In-Reply-To: References: Message-ID: <-mA5gyC9w92WrozDT9R23J5lOQcirGNrsWKQfxonXIE=.d8d28c57-5325-4bce-b59b-3e5df9dafa54@github.com> On Thu, 8 Jan 2026 13:29:25 GMT, Stefan Johansson wrote: >> Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 564 commits: >> >> - Merge branch '8373253' into 8367993 >> - Merge branch 'master' into _8373253 >> - Merge branch 'master' into _8367993 >> - 8366058: Outdated comment in WinCAPISeedGenerator >> >> Reviewed-by: mullan >> - 8357258: x86: Improve receiver type profiling reliability >> >> Reviewed-by: kvn, vlivanov >> - 8373704: Improve "SocketException: Protocol family unavailable" message >> >> Reviewed-by: lucy, jpai >> - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently >> >> Reviewed-by: jiefu, jbhateja, erfang, qamai >> - 8343809: Add requires tag to mark tests that are incompatible with exploded image >> >> Reviewed-by: alanb, dholmes >> - 8374465: Spurious dot in documentation for JVMTI ClassLoad >> >> Reviewed-by: kbarrett >> - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket >> >> Reviewed-by: djelinski, mpowers, ascarpino >> - ... and 554 more: https://git.openjdk.org/jdk/compare/2aa8aa4b...28ccbb68 > > src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1637: > >> 1635: >> 1636: bool G1CollectedHeap::concurrent_mark_is_terminating() const { >> 1637: assert(_cm != nullptr, "thread must exist in order to check if mark is terminating"); > > I think it would make sense to add `&& _cm->is_fully_initialized()` to really make sure the thread has been created. Yes. I will make it two lines instead, easier to see what assertion that fails. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2676599920 From lkorinth at openjdk.org Fri Jan 9 15:37:53 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Fri, 9 Jan 2026 15:37:53 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v3] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 08:22:40 GMT, Stefan Johansson wrote: >> Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 564 commits: >> >> - Merge branch '8373253' into 8367993 >> - Merge branch 'master' into _8373253 >> - Merge branch 'master' into _8367993 >> - 8366058: Outdated comment in WinCAPISeedGenerator >> >> Reviewed-by: mullan >> - 8357258: x86: Improve receiver type profiling reliability >> >> Reviewed-by: kvn, vlivanov >> - 8373704: Improve "SocketException: Protocol family unavailable" message >> >> Reviewed-by: lucy, jpai >> - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently >> >> Reviewed-by: jiefu, jbhateja, erfang, qamai >> - 8343809: Add requires tag to mark tests that are incompatible with exploded image >> >> Reviewed-by: alanb, dholmes >> - 8374465: Spurious dot in documentation for JVMTI ClassLoad >> >> Reviewed-by: kbarrett >> - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket >> >> Reviewed-by: djelinski, mpowers, ascarpino >> - ... and 554 more: https://git.openjdk.org/jdk/compare/2aa8aa4b...28ccbb68 > > src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2427: > >> 2425: if (_cm->is_fully_initialized()) { >> 2426: tc->do_thread(_cm->cm_thread()); >> 2427: } > > Since the _cm_thread is now in `G1ConcurrentMark` this should be handled in `G1ConcurrentMark::threads_do()` I agree that looks better > src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2549: > >> 2547: void G1CollectedHeap::start_concurrent_cycle(bool concurrent_operation_is_full_mark) { >> 2548: assert(!_cm->in_progress(), "Can not start concurrent operation while in progress"); >> 2549: assert(_cm->is_fully_initialized(), "sanity"); > > Not sure this sanity assert is needed `_cm->in_progress()` will always return `false` if not fully initialized, so the above assert will cover this. If we still want it, I think it should be moved above the `in_progress()` assert. Will move it before. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2676638153 PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2676644693 From lkorinth at openjdk.org Fri Jan 9 15:47:02 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Fri, 9 Jan 2026 15:47:02 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v3] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 08:36:29 GMT, Stefan Johansson wrote: >> Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 564 commits: >> >> - Merge branch '8373253' into 8367993 >> - Merge branch 'master' into _8373253 >> - Merge branch 'master' into _8367993 >> - 8366058: Outdated comment in WinCAPISeedGenerator >> >> Reviewed-by: mullan >> - 8357258: x86: Improve receiver type profiling reliability >> >> Reviewed-by: kvn, vlivanov >> - 8373704: Improve "SocketException: Protocol family unavailable" message >> >> Reviewed-by: lucy, jpai >> - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently >> >> Reviewed-by: jiefu, jbhateja, erfang, qamai >> - 8343809: Add requires tag to mark tests that are incompatible with exploded image >> >> Reviewed-by: alanb, dholmes >> - 8374465: Spurious dot in documentation for JVMTI ClassLoad >> >> Reviewed-by: kbarrett >> - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket >> >> Reviewed-by: djelinski, mpowers, ascarpino >> - ... and 554 more: https://git.openjdk.org/jdk/compare/2aa8aa4b...28ccbb68 > > src/hotspot/share/gc/g1/g1PeriodicGCTask.cpp line 46: > >> 44: return false; >> 45: } >> 46: > > Why is this needed? The initial young collection will make sure concurrent marking gets initialized, right? I do not remember if it was `whitebox` or if it was `System.gc()`, or something else. Do you think it is problematic ignoring it or just not needed? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2676669350 From wkemper at openjdk.org Fri Jan 9 17:52:53 2026 From: wkemper at openjdk.org (William Kemper) Date: Fri, 9 Jan 2026 17:52:53 GMT Subject: RFR: 8373819: GenShen: Requested generation may be null [v4] In-Reply-To: <8SWpQdaleulzSXfgF4fJ_zgekaijLs53t8Wer6IvKwo=.785abf41-65b7-44f6-90d0-2c63d5bf5981@github.com> References: <8SWpQdaleulzSXfgF4fJ_zgekaijLs53t8Wer6IvKwo=.785abf41-65b7-44f6-90d0-2c63d5bf5981@github.com> Message-ID: > This PR attempts to simplify the generational control thread by decoupling it somewhat from the heap/gc cancellation mechanism. This is meant to prevent the control thread from seeing inconsistencies between `shHeap::_cancelled_gc` and `shGenControlThread::_requested_gc_cause`. William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - Merge remote-tracking branch 'jdk/master' into fix-null-generation-crash - Merge remote-tracking branch 'jdk/master' into fix-null-generation-crash - Fix typo in assertion message - Take regulator thread out of STS before requesting GC The request may block while it waits for control thread to stop old marking. If workers are already in the STS, and the regulator thread is still in the STS, but cannot yield, the safepoint will not run. Control, worker and regulator threads deadlock each other. - Add comments - Revert back to what should be on this branch - Merge remote-tracking branch 'jdk/master' into fix-null-generation-crash - Don't know how this file got deleted - Carry over gc cancellation to gc request - Do not let allocation failure requests be overwritten by other requests - ... and 4 more: https://git.openjdk.org/jdk/compare/f5fa9e40...2e57f0ac ------------- Changes: https://git.openjdk.org/jdk/pull/28932/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28932&range=03 Stats: 95 lines in 4 files changed: 45 ins; 17 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/28932.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28932/head:pull/28932 PR: https://git.openjdk.org/jdk/pull/28932 From xpeng at openjdk.org Fri Jan 9 19:06:12 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 9 Jan 2026 19:06:12 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v32] In-Reply-To: References: Message-ID: <91iJNkRmHyoVJi79n80-lc7Im_iYvLohWaK1ZnRPZy8=.65e43e65-ee59-46d0-8af4-3fb47951a3ef@github.com> > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request incrementally with two additional commits since the last revision: - Remove necessary atomic load - Add _epoch_id to ShenandoahAllocator to trace the update of shared alloc regions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/7e0a1244..5e8f5998 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=31 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=30-31 Stats: 43 lines in 3 files changed: 19 ins; 4 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From xpeng at openjdk.org Fri Jan 9 19:15:59 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 9 Jan 2026 19:15:59 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v33] In-Reply-To: References: Message-ID: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Add comments for public methods ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/5e8f5998..5646d5b2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=32 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=31-32 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From xpeng at openjdk.org Fri Jan 9 19:16:02 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 9 Jan 2026 19:16:02 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v20] In-Reply-To: References: <797j9fNWUlV491wWKbFMfthH99o3A5493T0Pcdn_zdc=.417c13b0-8618-4402-aafa-3d86c45c8ff6@github.com> Message-ID: On Thu, 8 Jan 2026 19:58:25 GMT, Xiaolong Peng wrote: >> src/hotspot/share/gc/shenandoah/shenandoahAllocator.hpp line 79: >> >>> 77: int refresh_alloc_regions(ShenandoahAllocRequest* req = nullptr, bool* in_new_region = nullptr, HeapWord** obj = nullptr); >>> 78: #ifdef ASSERT >>> 79: virtual void verify(ShenandoahAllocRequest& req) { } >> >> Need a comment to explain what verify does. Is this simply checking to make sure the req is "properly formatted"? I think the intention is to enforce that req affiliation corresponds to ALLOC_PARTITION. Would be good to clarify this in the comment. >> >> Do we need this to be virtual? It seems like a single templated implementation would suffice. > > Yes, it can be templated implementation, I'll update the implementation to use template. verify method use template parameter now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2677338346 From wkemper at openjdk.org Fri Jan 9 19:22:26 2026 From: wkemper at openjdk.org (William Kemper) Date: Fri, 9 Jan 2026 19:22:26 GMT Subject: RFR: 8351892: GenShen: Remove vestigial young generation sizing options Message-ID: GenShen generally tries to keep the young generation as large as possible. The options `ShenandoahMinYoungPercentage` and `ShenandoahMaxYoungPercentage` are no longer used. ------------- Commit messages: - Remove vestigial young gen sizing options Changes: https://git.openjdk.org/jdk/pull/29144/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29144&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351892 Stats: 23 lines in 2 files changed: 0 ins; 23 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29144.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29144/head:pull/29144 PR: https://git.openjdk.org/jdk/pull/29144 From xpeng at openjdk.org Fri Jan 9 19:28:21 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 9 Jan 2026 19:28:21 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v20] In-Reply-To: References: <797j9fNWUlV491wWKbFMfthH99o3A5493T0Pcdn_zdc=.417c13b0-8618-4402-aafa-3d86c45c8ff6@github.com> Message-ID: On Tue, 6 Jan 2026 01:28:42 GMT, Kelvin Nilsen wrote: >> Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 265 commits: >> >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - Fix build error after merging from tip >> - Merge branch 'master' into cas-alloc-1 >> - Merge branch 'master' into cas-alloc-1 >> - Some comments updates as suggested in PR review >> - Fix build failure after merge >> - Expend promoted from ShenandoahOldCollectorAllocator >> - Merge branch 'master' into cas-alloc-1 >> - Address PR comments >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - ... and 255 more: https://git.openjdk.org/jdk/compare/de81d389...cf13b7b5 > > src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 376: > >> 374: } >> 375: >> 376: THREAD_LOCAL uint ShenandoahMutatorAllocator::_alloc_start_index = UINT_MAX; > > I raised questions about this in a previous review. Have I overlooked your response? What is the tradeoff between declaring this THREAD_LOCAL vs. creating a new field in ShenandoahThreadLocal? I believe we need to use fields of ShenandoahThreadLocal so that we do not incur an overhead on all threads when JVM is not configured for Shenandoah GC. I don't have concern to move it to ShenandoahThreadLocalData, the benefit of using THREAD_LOCAL is just better cohesive code because _alloc_start_index is defined in the same namespace where it is used. Performance wise, I don't think there is much benefits. I do see ZGC also use THREAD_LOCAL directly, I guess the overhead on all threads is not a huge concern. But given Shenandoah has ShenandoahThreadLocalData to manage all the thread locals, it make sense to not use THREAD_LOCAL directly, I'll update the PR to move _alloc_start_index to ShenandoahThreadLocalData. > src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 436: > >> 434: // Make sure the old generation has room for either evacuations or promotions before trying to allocate. >> 435: auto old_gen = ShenandoahHeap::heap()->old_generation(); >> 436: if (req.is_old() && !old_gen->can_allocate(req)) { > > This test for req.is_old() appears to be unnecessary. The verify(req) assert above requires that req.is_old(). > > Perhaps the verify() method is too abstract. Add a comment there that says: "Confirm that req.is_old()" Thanks for pointing out this, it is not necessary, I have removed it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2677369816 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2677373200 From xpeng at openjdk.org Fri Jan 9 20:01:38 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 9 Jan 2026 20:01:38 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v20] In-Reply-To: References: <797j9fNWUlV491wWKbFMfthH99o3A5493T0Pcdn_zdc=.417c13b0-8618-4402-aafa-3d86c45c8ff6@github.com> Message-ID: On Fri, 9 Jan 2026 19:24:44 GMT, Xiaolong Peng wrote: >> src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 376: >> >>> 374: } >>> 375: >>> 376: THREAD_LOCAL uint ShenandoahMutatorAllocator::_alloc_start_index = UINT_MAX; >> >> I raised questions about this in a previous review. Have I overlooked your response? What is the tradeoff between declaring this THREAD_LOCAL vs. creating a new field in ShenandoahThreadLocal? I believe we need to use fields of ShenandoahThreadLocal so that we do not incur an overhead on all threads when JVM is not configured for Shenandoah GC. > > I don't have concern to move it to ShenandoahThreadLocalData, the benefit of using THREAD_LOCAL is just better cohesive code because _alloc_start_index is defined in the same namespace where it is used. Performance wise, I don't think there is much benefits. > > I do see ZGC also use THREAD_LOCAL directly, I guess the overhead on all threads is not a huge concern. > But given Shenandoah has ShenandoahThreadLocalData to manage all the thread locals, it make sense to not use THREAD_LOCAL directly, I'll update the PR to move _alloc_start_index to ShenandoahThreadLocalData. While I am trying to use ShenandoahThreadLocalData, I realized that I need to add 2 alloc start index, one for ShenandoahMutatorAllocator, one for ShenandoahCollectorAllocator. Later when I update ShenandoahOldCollectorAllocator to use CAS allocation, one more will be added. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2677462219 From kdnilsen at openjdk.org Fri Jan 9 21:09:58 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Fri, 9 Jan 2026 21:09:58 GMT Subject: RFR: 8351892: GenShen: Remove vestigial young generation sizing options In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 19:13:31 GMT, William Kemper wrote: > GenShen generally tries to keep the young generation as large as possible. The options `ShenandoahMinYoungPercentage` and `ShenandoahMaxYoungPercentage` are no longer used. LGTM ------------- Marked as reviewed by kdnilsen (Committer). PR Review: https://git.openjdk.org/jdk/pull/29144#pullrequestreview-3645575675 From wkemper at openjdk.org Fri Jan 9 22:24:46 2026 From: wkemper at openjdk.org (William Kemper) Date: Fri, 9 Jan 2026 22:24:46 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v4] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 20:56:51 GMT, Kelvin Nilsen wrote: >> After studying large numbers of GC logs with degenerated cycles that have resulted from "late" triggers, we propose the following general improvements: >> >> 1. Track trends in GC times rather than always using the average GC time plus standard deviation. In many situations, GC times trend upward due to, for example, increasing amounts of live data that must be marked as a workload builds up its working set of memory. >> 2. Sample allocation rates more frequently than once every 100 ms. >> 3. Track trends in allocation rates. In some situations, the allocation rate trends upwards due to, for example, the start of a new phase of execution or a spike in client workload. >> 4. When we detect acceleration of allocation rate, predict consumption of memory based on accelerated allocation rates rather than assuming constant allocation rate. > > Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits: > > - Fix comment > - Use PROPERFMT macros > - Simplify code flow: reviewer suggestion > - Merge remote-tracking branch 'jdk/master' into accelerated-triggers > - Remove develop/debug instrumentation > - add another override > - Change type of command-line args > - fix white space > - Add override to virtual methods > - Fix race between allocation reporting and querying > - ... and 55 more: https://git.openjdk.org/jdk/compare/dd20e915...7f3a6d1e Changes requested by wkemper (Reviewer). src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 643: > 641: future_accelerated_planned_gc_time * 1000); > 642: } else { > 643: log_trigger("Momentary spike consumption (%zu%s) exceeds free headroom (%zu%s) at " Should the 'Momentary spike' trigger replace the 'instantaneous spike' trigger? It seems like we now have two spike detecting triggers? ------------- PR Review: https://git.openjdk.org/jdk/pull/29039#pullrequestreview-3645745671 PR Review Comment: https://git.openjdk.org/jdk/pull/29039#discussion_r2677779429 From wkemper at openjdk.org Fri Jan 9 23:51:48 2026 From: wkemper at openjdk.org (William Kemper) Date: Fri, 9 Jan 2026 23:51:48 GMT Subject: RFR: 8369048: GenShen: Defer ShenFreeSet::available() during rebuild [v4] In-Reply-To: References: <_PEoOc0oWb8Vzq16-Or_hykkL4NkIrwEFgLCgCRac5U=.2c23c497-acbe-48f9-a1dc-4eb4e8f25a8d@github.com> Message-ID: <6z8QE0tr_8b3brwl6tfIjQC7J458m9zDIcblpcjs_gc=.ecc3c716-e082-45c1-a4a4-4723ab4bcbda@github.com> On Thu, 11 Dec 2025 23:18:18 GMT, Kelvin Nilsen wrote: >> This code introduces a new rebuild-freeset lock for purposes of coordinating the freeset rebuild activities and queries as to memory available for allocation in the mutator partition. >> >> This addresses a problem that results if available memory is probed while we are rebuilding the freeset. >> >> Rather than using the existing global heap lock to synchronize these activities, a new more narrowly scoped lock is introduced. This allows the available memory to be probed even when other activities hold the global heap lock for reasons other than rebuilding the freeset, such as when they are allocating memory. It is known that the global heap lock is heavily contended for certain workloads, and using this new lock avoids adding to contention for the global heap lock. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > Add rebuild synchronization to capacity() and used() Marked as reviewed by wkemper (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27612#pullrequestreview-3645962594 From ysr at openjdk.org Sat Jan 10 00:17:42 2026 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Sat, 10 Jan 2026 00:17:42 GMT Subject: RFR: 8373819: GenShen: Requested generation may be null [v4] In-Reply-To: References: <8SWpQdaleulzSXfgF4fJ_zgekaijLs53t8Wer6IvKwo=.785abf41-65b7-44f6-90d0-2c63d5bf5981@github.com> Message-ID: On Fri, 9 Jan 2026 17:52:53 GMT, William Kemper wrote: >> This PR simplifies the generational control thread by decoupling it somewhat from the heap/gc cancellation mechanism. This is meant to prevent the control thread from seeing inconsistencies between `shHeap::_cancelled_gc` and `shGenControlThread::_requested_gc_cause`. > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Merge remote-tracking branch 'jdk/master' into fix-null-generation-crash > - Merge remote-tracking branch 'jdk/master' into fix-null-generation-crash > - Fix typo in assertion message > - Take regulator thread out of STS before requesting GC > > The request may block while it waits for control thread to stop old marking. If workers are already in the STS, and the regulator thread is still in the STS, but cannot yield, the safepoint will not run. Control, worker and regulator threads deadlock each other. > - Add comments > - Revert back to what should be on this branch > - Merge remote-tracking branch 'jdk/master' into fix-null-generation-crash > - Don't know how this file got deleted > - Carry over gc cancellation to gc request > - Do not let allocation failure requests be overwritten by other requests > - ... and 4 more: https://git.openjdk.org/jdk/compare/f5fa9e40...2e57f0ac I left a few comments and my uneasiness with the code as structured, mainly because I am not sure I understand the interaction protocol between the interacting threads clearly enough or the state being protected by the locks to be certain that this all works correctly. Piecemeal these all make sense, but I don't have a sufficient overall understanding to say confidently that this code looks good. However, since this has been shown to fix an existing production issue, I'll go ahead and approve it. I would really like this interaction protocol clearly written down and reasoned through to ensure that it's right, and to structure it in a manner that makes it easier to reason about and maintain. src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.cpp line 95: > 93: notify_gc_waiters(); > 94: notify_alloc_failure_waiters(); > 95: set_gc_mode(stopped); Will they "observe the shutdown" if mode isn't "stopped"? Should line 95 move before line 93? Also is `gc_mode`'s state transitions protected in any manner, so they are consistent with any other observable state from the standpoint of threads that may interact with the controller? I see for example that the RegulatorThread looks at the controller thread's gc_mode to make certain GC triggering decisions, but it doesn't look like the reading of the mode and the requesting of a GC are protected by a lock that prevents races/glitches. In general such interactions lead to an increase in the state-space of interactions that the parties need to deal with correctly. src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.cpp line 708: > 706: > 707: void ShenandoahGenerationalControlThread::notify_control_thread(MonitorLocker& ml, GCCause::Cause cause, ShenandoahGeneration* generation) { > 708: assert(_control_lock.is_locked(), "Request lock must be held here"); What is MonitorLocker, and what is `_control_lock`? Why are we checking `_control_lock` here? If ml is being passed here for the purposes of notification on it, it must be the case that it's locked and the assert at line 708 is a leakage of abstraction? I see that your problem here is that along one path you do nothing and and don't post a notification and along another you do some work and post a notification. It sounds like what you want instead is an API of the following shape: bool should_notify_control_thread(cause, generation) { ... }; and callers might do: MonitorLocker ml(...); if (should_notify_control_thread(cause, generation)) { ml.notify(); } ml.wait(); src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.cpp line 721: > 719: } > 720: > 721: void ShenandoahGenerationalControlThread::notify_control_thread(GCCause::Cause cause) { Apropos my comment above, this code has a bad smell that some versions of the method expect the lock to be held, and other methods acquire the lock. It makes reasoning about the code at an abstract level very error-prone, and potentially difficult to maintain correctly over time. ------------- Marked as reviewed by ysr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28932#pullrequestreview-3645834579 PR Review Comment: https://git.openjdk.org/jdk/pull/28932#discussion_r2677970564 PR Review Comment: https://git.openjdk.org/jdk/pull/28932#discussion_r2677861000 PR Review Comment: https://git.openjdk.org/jdk/pull/28932#discussion_r2677882435 From ysr at openjdk.org Sat Jan 10 00:17:43 2026 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Sat, 10 Jan 2026 00:17:43 GMT Subject: RFR: 8373819: GenShen: Requested generation may be null [v4] In-Reply-To: References: <8SWpQdaleulzSXfgF4fJ_zgekaijLs53t8Wer6IvKwo=.785abf41-65b7-44f6-90d0-2c63d5bf5981@github.com> Message-ID: On Fri, 9 Jan 2026 23:57:10 GMT, Y. Srinivas Ramakrishna wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: >> >> - Merge remote-tracking branch 'jdk/master' into fix-null-generation-crash >> - Merge remote-tracking branch 'jdk/master' into fix-null-generation-crash >> - Fix typo in assertion message >> - Take regulator thread out of STS before requesting GC >> >> The request may block while it waits for control thread to stop old marking. If workers are already in the STS, and the regulator thread is still in the STS, but cannot yield, the safepoint will not run. Control, worker and regulator threads deadlock each other. >> - Add comments >> - Revert back to what should be on this branch >> - Merge remote-tracking branch 'jdk/master' into fix-null-generation-crash >> - Don't know how this file got deleted >> - Carry over gc cancellation to gc request >> - Do not let allocation failure requests be overwritten by other requests >> - ... and 4 more: https://git.openjdk.org/jdk/compare/f5fa9e40...2e57f0ac > > src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.cpp line 95: > >> 93: notify_gc_waiters(); >> 94: notify_alloc_failure_waiters(); >> 95: set_gc_mode(stopped); > > Will they "observe the shutdown" if mode isn't "stopped"? Should line 95 move before line 93? Also is `gc_mode`'s state transitions protected in any manner, so they are consistent with any other observable state from the standpoint of threads that may interact with the controller? I see for example that the RegulatorThread looks at the controller thread's gc_mode to make certain GC triggering decisions, but it doesn't look like the reading of the mode and the requesting of a GC are protected by a lock that prevents races/glitches. In general such interactions lead to an increase in the state-space of interactions that the parties need to deal with correctly. The reason I am leaving this comment here is that further above (lines 85-88), and in many of the other mode changes we seem to take care to use the control lock to protect these transitions so that other parties may observe the right state. Perhaps that is not needed in some cases, but the plurality of different forms of update of state that is modifed and may be read by other threads in conjunction with other state leaves me feeling queasy about the possible cracks in the coordination surface that may open us up to trouble. > src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.cpp line 708: > >> 706: >> 707: void ShenandoahGenerationalControlThread::notify_control_thread(MonitorLocker& ml, GCCause::Cause cause, ShenandoahGeneration* generation) { >> 708: assert(_control_lock.is_locked(), "Request lock must be held here"); > > What is MonitorLocker, and what is `_control_lock`? Why are we checking `_control_lock` here? If ml is being passed here for the purposes of notification on it, it must be the case that it's locked and the assert at line 708 is a leakage of abstraction? I see that your problem here is that along one path you do nothing and and don't post a notification and along another you do some work and post a notification. It sounds like what you want instead is an API of the following shape: > > > bool should_notify_control_thread(cause, generation) { ... }; > > > and callers might do: > > > MonitorLocker ml(...); > if (should_notify_control_thread(cause, generation)) { > ml.notify(); > } > ml.wait(); In addition, all of the various flavours of `notify_control_thread()` with optional parameters should ideally call down into the version that has all of the parameters specified. In the cases where these parameters aren't specified, the version of the method fills default parameters. The fully-parameterized version of the method then contains and consolidates the entire logic and any invariant/assertion checking of the various parameters that make sense, and executes the relevant logic to return a boolean result to allow the caller to notify and/or wait on the monitor. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28932#discussion_r2677974288 PR Review Comment: https://git.openjdk.org/jdk/pull/28932#discussion_r2677875997 From ysr at openjdk.org Sat Jan 10 00:17:44 2026 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Sat, 10 Jan 2026 00:17:44 GMT Subject: RFR: 8373819: GenShen: Requested generation may be null [v4] In-Reply-To: References: <8SWpQdaleulzSXfgF4fJ_zgekaijLs53t8Wer6IvKwo=.785abf41-65b7-44f6-90d0-2c63d5bf5981@github.com> Message-ID: On Sat, 10 Jan 2026 00:00:46 GMT, Y. Srinivas Ramakrishna wrote: >> src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.cpp line 95: >> >>> 93: notify_gc_waiters(); >>> 94: notify_alloc_failure_waiters(); >>> 95: set_gc_mode(stopped); >> >> Will they "observe the shutdown" if mode isn't "stopped"? Should line 95 move before line 93? Also is `gc_mode`'s state transitions protected in any manner, so they are consistent with any other observable state from the standpoint of threads that may interact with the controller? I see for example that the RegulatorThread looks at the controller thread's gc_mode to make certain GC triggering decisions, but it doesn't look like the reading of the mode and the requesting of a GC are protected by a lock that prevents races/glitches. In general such interactions lead to an increase in the state-space of interactions that the parties need to deal with correctly. > > The reason I am leaving this comment here is that further above (lines 85-88), and in many of the other mode changes we seem to take care to use the control lock to protect these transitions so that other parties may observe the right state. Perhaps that is not needed in some cases, but the plurality of different forms of update of state that is modifed and may be read by other threads in conjunction with other state leaves me feeling queasy about the possible cracks in the coordination surface that may open us up to trouble. (Note that the "mode" parameter used in the non-generational control thread is completely internal to the control thread and unlike in the case of the generational control thread here, never leaks out of that thread to be consulted by another thread asynchronously.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28932#discussion_r2677985424 From smarks at openjdk.org Sat Jan 10 01:13:28 2026 From: smarks at openjdk.org (Stuart Marks) Date: Sat, 10 Jan 2026 01:13:28 GMT Subject: RFR: 8374922: Build failure after JDK-8372040 In-Reply-To: <4UAdledLaAEtySt6MVHIqDCr5AoKSVP6jXysSYvuCX0=.dc5de4d3-950b-423d-bd18-4529c73292fe@github.com> References: <4UAdledLaAEtySt6MVHIqDCr5AoKSVP6jXysSYvuCX0=.dc5de4d3-950b-423d-bd18-4529c73292fe@github.com> Message-ID: On Sat, 10 Jan 2026 01:02:02 GMT, Kim Barrett wrote: > Please review this trivial change to fix a build failure caused by a missing `#include`. > > Testing: mach5 tier1 Change looks good. I've verified with my local build that this change fixes the compilation error introduced by JDK-8372040. ------------- Marked as reviewed by smarks (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29148#pullrequestreview-3646097974 From kbarrett at openjdk.org Sat Jan 10 01:10:56 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 10 Jan 2026 01:10:56 GMT Subject: RFR: 8374922: Build failure after JDK-8372040 Message-ID: <4UAdledLaAEtySt6MVHIqDCr5AoKSVP6jXysSYvuCX0=.dc5de4d3-950b-423d-bd18-4529c73292fe@github.com> Please review this trivial change to fix a build failure caused by a missing `#include`. Testing: mach5 tier1 ------------- Commit messages: - fix Changes: https://git.openjdk.org/jdk/pull/29148/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29148&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374922 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29148.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29148/head:pull/29148 PR: https://git.openjdk.org/jdk/pull/29148 From kbarrett at openjdk.org Sat Jan 10 01:55:39 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 10 Jan 2026 01:55:39 GMT Subject: RFR: 8374922: Build failure after JDK-8372040 In-Reply-To: References: <4UAdledLaAEtySt6MVHIqDCr5AoKSVP6jXysSYvuCX0=.dc5de4d3-950b-423d-bd18-4529c73292fe@github.com> Message-ID: On Sat, 10 Jan 2026 01:10:18 GMT, Stuart Marks wrote: >> Please review this trivial change to fix a build failure caused by a missing `#include`. >> >> Testing: mach5 tier1 > > Change looks good. I've verified with my local build that this change fixes the compilation error introduced by JDK-8372040. Thanks for the quick review @stuart-marks ------------- PR Comment: https://git.openjdk.org/jdk/pull/29148#issuecomment-3731446742 From kbarrett at openjdk.org Sat Jan 10 01:57:25 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 10 Jan 2026 01:57:25 GMT Subject: Integrated: 8374922: Build failure after JDK-8372040 In-Reply-To: <4UAdledLaAEtySt6MVHIqDCr5AoKSVP6jXysSYvuCX0=.dc5de4d3-950b-423d-bd18-4529c73292fe@github.com> References: <4UAdledLaAEtySt6MVHIqDCr5AoKSVP6jXysSYvuCX0=.dc5de4d3-950b-423d-bd18-4529c73292fe@github.com> Message-ID: On Sat, 10 Jan 2026 01:02:02 GMT, Kim Barrett wrote: > Please review this trivial change to fix a build failure caused by a missing `#include`. > > Testing: mach5 tier1 This pull request has now been integrated. Changeset: 0537a3fa Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/0537a3fae9bd55ab8b7279da7d3ee4b5ce5bc492 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8374922: Build failure after JDK-8372040 Reviewed-by: smarks ------------- PR: https://git.openjdk.org/jdk/pull/29148 From xpeng at openjdk.org Sat Jan 10 06:11:47 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Sat, 10 Jan 2026 06:11:47 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v34] In-Reply-To: References: Message-ID: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Move thread locals to ShenandoahThreadLocalData ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/5646d5b2..c5824564 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=33 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=32-33 Stats: 91 lines in 4 files changed: 60 ins; 29 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From xpeng at openjdk.org Sat Jan 10 06:19:21 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Sat, 10 Jan 2026 06:19:21 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v20] In-Reply-To: References: <797j9fNWUlV491wWKbFMfthH99o3A5493T0Pcdn_zdc=.417c13b0-8618-4402-aafa-3d86c45c8ff6@github.com> Message-ID: On Fri, 9 Jan 2026 19:57:23 GMT, Xiaolong Peng wrote: >> I don't have concern to move it to ShenandoahThreadLocalData, the benefit of using THREAD_LOCAL is just better cohesive code because _alloc_start_index is defined in the same namespace where it is used. Performance wise, I don't think there is much benefits. >> >> I do see ZGC also use THREAD_LOCAL directly, I guess the overhead on all threads is not a huge concern. >> But given Shenandoah has ShenandoahThreadLocalData to manage all the thread locals, it make sense to not use THREAD_LOCAL directly, I'll update the PR to move _alloc_start_index to ShenandoahThreadLocalData. > > While I am trying to use ShenandoahThreadLocalData, I realized that I need to add 2 alloc start index, one for ShenandoahMutatorAllocator, one for ShenandoahCollectorAllocator. Later when I update ShenandoahOldCollectorAllocator to use CAS allocation, one more will be added. I have moved all the THREAD_LOCAL to ShenandoahThreadLocalData, also rewrote `alloc_start_index` function in templated impl to avoid virtual table lookup. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2678364578 From kdnilsen at openjdk.org Sun Jan 11 03:04:44 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Sun, 11 Jan 2026 03:04:44 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v5] In-Reply-To: References: Message-ID: > After studying large numbers of GC logs with degenerated cycles that have resulted from "late" triggers, we propose the following general improvements: > > 1. Track trends in GC times rather than always using the average GC time plus standard deviation. In many situations, GC times trend upward due to, for example, increasing amounts of live data that must be marked as a workload builds up its working set of memory. > 2. Sample allocation rates more frequently than once every 100 ms. > 3. Track trends in allocation rates. In some situations, the allocation rate trends upwards due to, for example, the start of a new phase of execution or a spike in client workload. > 4. When we detect acceleration of allocation rate, predict consumption of memory based on accelerated allocation rates rather than assuming constant allocation rate. Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 66 commits: - Merge remote-tracking branch 'jdk/master' into accelerated-triggers - Fix comment - Use PROPERFMT macros - Simplify code flow: reviewer suggestion - Merge remote-tracking branch 'jdk/master' into accelerated-triggers - Remove develop/debug instrumentation - add another override - Change type of command-line args - fix white space - Add override to virtual methods - ... and 56 more: https://git.openjdk.org/jdk/compare/659b53fe...ac0e8c57 ------------- Changes: https://git.openjdk.org/jdk/pull/29039/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=04 Stats: 1027 lines in 25 files changed: 920 ins; 35 del; 72 mod Patch: https://git.openjdk.org/jdk/pull/29039.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29039/head:pull/29039 PR: https://git.openjdk.org/jdk/pull/29039 From kdnilsen at openjdk.org Sun Jan 11 03:08:48 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Sun, 11 Jan 2026 03:08:48 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v29] In-Reply-To: References: Message-ID: > Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). > > This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. > > The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. > > ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) > > With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. > > ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) > > At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. > > ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) > > The command line for these comparisons follows: > > > ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jdk/bin/java \ > -XX:+Unlock... Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 86 commits: - Merge remote-tracking branch 'jdk/master' into share-collector-reserves - Move rebuild free set earlier in an abbreviated GC cycle - Restore deleted assert statement - Move special handling into ShenandoahYoungHeuristics::choose_collection_set_from_regiondata() - fix another typo - Fix typo - Fix confusing comment - Add comment - Merge remote-tracking branch 'jdk/master' into share-collector-reserves - Fix whitespace and comment - ... and 76 more: https://git.openjdk.org/jdk/compare/659b53fe...27ece3e8 ------------- Changes: https://git.openjdk.org/jdk/pull/25357/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=28 Stats: 1520 lines in 41 files changed: 789 ins; 289 del; 442 mod Patch: https://git.openjdk.org/jdk/pull/25357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25357/head:pull/25357 PR: https://git.openjdk.org/jdk/pull/25357 From tschatzl at openjdk.org Mon Jan 12 08:07:42 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 12 Jan 2026 08:07:42 GMT Subject: RFR: 8374743: G1 starts a concurrent mark when allocating humongous objects during initialization In-Reply-To: <3VkmB9wpThHrZQAE0qdioZQlvUWOfP2L-wV1dWJOwck=.f8b298c5-e335-4324-a555-3f3257d3765d@github.com> References: <3VkmB9wpThHrZQAE0qdioZQlvUWOfP2L-wV1dWJOwck=.f8b298c5-e335-4324-a555-3f3257d3765d@github.com> Message-ID: On Thu, 8 Jan 2026 16:37:02 GMT, Erik ?sterlund wrote: >> Hi all, >> >> please review this small change that prevents opportunistic concurrent mark during humongous object allocation when the VM is not initialized yet. >> >> Patch provided by @fisk >> >> Testing: gha, failing test case >> >> Thanks, >> Thomas > > Looks great! Thanks @fisk @kstefanj @shipilev @walulyai for your reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29119#issuecomment-3737310509 From tschatzl at openjdk.org Mon Jan 12 08:27:15 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 12 Jan 2026 08:27:15 GMT Subject: RFR: 8374743: G1 starts a concurrent mark when allocating humongous objects during initialization In-Reply-To: <3VkmB9wpThHrZQAE0qdioZQlvUWOfP2L-wV1dWJOwck=.f8b298c5-e335-4324-a555-3f3257d3765d@github.com> References: <3VkmB9wpThHrZQAE0qdioZQlvUWOfP2L-wV1dWJOwck=.f8b298c5-e335-4324-a555-3f3257d3765d@github.com> Message-ID: On Thu, 8 Jan 2026 16:37:02 GMT, Erik ?sterlund wrote: >> Hi all, >> >> please review this small change that prevents opportunistic concurrent mark during humongous object allocation when the VM is not initialized yet. >> >> Patch provided by @fisk >> >> Testing: gha, failing test case >> >> Thanks, >> Thomas > > Looks great! Thanks @fisk @kstefanj @shipilev @walulyai for your reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29119#issuecomment-3737371427 From tschatzl at openjdk.org Mon Jan 12 08:30:05 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 12 Jan 2026 08:30:05 GMT Subject: Integrated: 8374743: G1 starts a concurrent mark when allocating humongous objects during initialization In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 16:25:43 GMT, Thomas Schatzl wrote: > Hi all, > > please review this small change that prevents opportunistic concurrent mark during humongous object allocation when the VM is not initialized yet. > > Patch provided by @fisk > > Testing: gha, failing test case > > Thanks, > Thomas This pull request has now been integrated. Changeset: fb13abef Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/fb13abef44d535ebc4535921fd4eb0f285030465 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8374743: G1 starts a concurrent mark when allocating humongous objects during initialization Co-authored-by: Erik ?sterlund Reviewed-by: eosterlund, iwalulya, sjohanss, shade ------------- PR: https://git.openjdk.org/jdk/pull/29119 From tschatzl at openjdk.org Mon Jan 12 08:48:46 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 12 Jan 2026 08:48:46 GMT Subject: [jdk26] RFR: 8374743: G1 starts a concurrent mark when allocating humongous objects during initialization Message-ID: Hi all, This pull request contains a backport of commit [fb13abef](https://github.com/openjdk/jdk/commit/fb13abef44d535ebc4535921fd4eb0f285030465) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Thomas Schatzl on 12 Jan 2026 and was reviewed by Erik ?sterlund, Ivan Walulya, Stefan Johansson and Aleksey Shipilev. Thanks! ------------- Commit messages: - Backport fb13abef44d535ebc4535921fd4eb0f285030465 Changes: https://git.openjdk.org/jdk/pull/29160/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29160&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374743 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29160.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29160/head:pull/29160 PR: https://git.openjdk.org/jdk/pull/29160 From shade at openjdk.org Mon Jan 12 08:57:05 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 12 Jan 2026 08:57:05 GMT Subject: [jdk26] RFR: 8374743: G1 starts a concurrent mark when allocating humongous objects during initialization In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 08:40:30 GMT, Thomas Schatzl wrote: > Hi all, > > This pull request contains a backport of commit [fb13abef](https://github.com/openjdk/jdk/commit/fb13abef44d535ebc4535921fd4eb0f285030465) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Thomas Schatzl on 12 Jan 2026 and was reviewed by Erik ?sterlund, Ivan Walulya, Stefan Johansson and Aleksey Shipilev. > > Thanks! Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29160#pullrequestreview-3649694725 From tschatzl at openjdk.org Mon Jan 12 09:20:53 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 12 Jan 2026 09:20:53 GMT Subject: [jdk26] RFR: 8374743: G1 starts a concurrent mark when allocating humongous objects during initialization In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 08:40:30 GMT, Thomas Schatzl wrote: > Hi all, > > This pull request contains a backport of commit [fb13abef](https://github.com/openjdk/jdk/commit/fb13abef44d535ebc4535921fd4eb0f285030465) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Thomas Schatzl on 12 Jan 2026 and was reviewed by Erik ?sterlund, Ivan Walulya, Stefan Johansson and Aleksey Shipilev. > > Thanks! The linux_x64 gha build error is due to running out of disk space. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29160#issuecomment-3737574467 From sjohanss at openjdk.org Mon Jan 12 09:45:53 2026 From: sjohanss at openjdk.org (Stefan Johansson) Date: Mon, 12 Jan 2026 09:45:53 GMT Subject: RFR: 8373253: Re-work InjectGCWorkerCreationFailure for future changes [v3] In-Reply-To: References: <78ejbDKfHkTR88XnHC2t975-zof6vMjdM_M_rTyB0pk=.d5c9798a-b1ca-4299-af35-2caaad2f8106@github.com> Message-ID: On Wed, 7 Jan 2026 12:52:25 GMT, Leo Korinth wrote: >> This PR slightly changes when we may `InjectGCWorkerCreationFailure`. At the moment we wait until `is_init_completed()`. I am changing this to instead be after `_created_workers > 0`. The reason is that we might in the future, https://bugs.openjdk.org/browse/JDK-8367993, create even more threads "on demand", and if so, we would fail VM creation if we inject worker creation failures after the VM is initiated but before we have created any of the worker threads. >> >> This change should not change the current behaviour. But help future improvements. >> >> I have tested this on `test/hotspot/jtreg/gc/stress/gcold/TestGCOldWithG1.java`, the only place where this flag is tested to my knowledge. > > Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into _8373253 > - Fixup after comment from Ivan. > - 8373253: Re-work InjectGCWorkerCreationFailure for future changes Have an alternative solution, see below. One difference is that with this solution the initialization of a work-gang after `is_init_completed()` starts returning true, will only get one worker before the injected creation failures start occurring. This is only a difference is `UseDynamicNumberOfGCThreads` is disabled and I don't see that as a problem for a testing feature. src/hotspot/share/gc/shared/workerThread.cpp line 123: > 121: return _active_workers; > 122: } > 123: I find adding this logic to `set_active_workers(...)` a bit odd. I see that it will have the desired effect, but the flag is about creation failure and I think keeping the logic in `create_worker(...)` would be better. For the upcoming change to lazy initialize concurrent mark we need a way to make sure at least one worker is created for each work-gang. This is why we add the above check on `_current_workers`, but this check could also be added to the original code path, as an additional requirement similar to `is_init_completed()`. My preferred solution would be to revert this change to `set_active_workers(...)` and instead update the check in `create_worker(...)`. To make the code even clearer we could separate the conditions into a helper like: if (InjectGCWorkerCreationFailure && allow_creation_failure()) { return nullptr; } Where the helper is implemented something like this: bool WorkerThreads::allow_creation_failure() const { if (!is_init_completed()) { // Never allow creation failures during VM init return false; } if (_created_workers == 0) { // Never allow creation failures of the first worker, it will cause the VM to exit return false; } return true; } I've discussed this a bit with Leo and Stefan K offline and I think they more or less agree with this proposal. ------------- Changes requested by sjohanss (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28719#pullrequestreview-3649858223 PR Review Comment: https://git.openjdk.org/jdk/pull/28719#discussion_r2681471572 From shade at openjdk.org Mon Jan 12 09:49:04 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 12 Jan 2026 09:49:04 GMT Subject: [jdk26] RFR: 8374743: G1 starts a concurrent mark when allocating humongous objects during initialization In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 09:18:46 GMT, Thomas Schatzl wrote: > The linux_x64 gha build error is due to running out of disk space. Yeah, known thing, already fixed in mainline. I can see how hard it is to fix in JDK 26. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29160#issuecomment-3737669717 From iwalulya at openjdk.org Mon Jan 12 09:49:03 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 12 Jan 2026 09:49:03 GMT Subject: [jdk26] RFR: 8374743: G1 starts a concurrent mark when allocating humongous objects during initialization In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 08:40:30 GMT, Thomas Schatzl wrote: > Hi all, > > This pull request contains a backport of commit [fb13abef](https://github.com/openjdk/jdk/commit/fb13abef44d535ebc4535921fd4eb0f285030465) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Thomas Schatzl on 12 Jan 2026 and was reviewed by Erik ?sterlund, Ivan Walulya, Stefan Johansson and Aleksey Shipilev. > > Thanks! Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29160#pullrequestreview-3649905640 From shade at openjdk.org Mon Jan 12 10:21:26 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 12 Jan 2026 10:21:26 GMT Subject: RFR: 8374876: Epsilon: Convert to use Atomic Message-ID: Epsilon uses AtomicAccess on volatile data. Convert it to use Atomic. Additional testing: - [x] Linux x86_64 server fastdebug, `gc/epsilon`, 100x ------------- Commit messages: - Atomics Changes: https://git.openjdk.org/jdk/pull/29163/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29163&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374876 Stats: 14 lines in 4 files changed: 2 ins; 3 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/29163.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29163/head:pull/29163 PR: https://git.openjdk.org/jdk/pull/29163 From shade at openjdk.org Mon Jan 12 10:21:28 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 12 Jan 2026 10:21:28 GMT Subject: RFR: 8374876: Epsilon: Convert to use Atomic In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 10:12:08 GMT, Aleksey Shipilev wrote: > Epsilon uses AtomicAccess on volatile data. Convert it to use Atomic. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `gc/epsilon`, 100x src/hotspot/share/gc/epsilon/epsilonMonitoringSupport.cpp line 120: > 118: > 119: void EpsilonMonitoringSupport::mark_ready() { > 120: _ready.release_store(true); Pre-existing: old code was using void return by accident. It does not look to be causing issues. (I am somewhat surprised this syntax is even allowed, but I guess it is useful for ordering pre-return statements.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29163#discussion_r2681615068 From tschatzl at openjdk.org Mon Jan 12 11:33:37 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 12 Jan 2026 11:33:37 GMT Subject: [jdk26] RFR: 8374743: G1 starts a concurrent mark when allocating humongous objects during initialization In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 09:44:20 GMT, Ivan Walulya wrote: >> Hi all, >> >> This pull request contains a backport of commit [fb13abef](https://github.com/openjdk/jdk/commit/fb13abef44d535ebc4535921fd4eb0f285030465) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. >> >> The commit being backported was authored by Thomas Schatzl on 12 Jan 2026 and was reviewed by Erik ?sterlund, Ivan Walulya, Stefan Johansson and Aleksey Shipilev. >> >> Thanks! > > Marked as reviewed by iwalulya (Reviewer). Thanks @walulyai @shipilev for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/29160#issuecomment-3738106444 From tschatzl at openjdk.org Mon Jan 12 11:33:37 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 12 Jan 2026 11:33:37 GMT Subject: [jdk26] Integrated: 8374743: G1 starts a concurrent mark when allocating humongous objects during initialization In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 08:40:30 GMT, Thomas Schatzl wrote: > Hi all, > > This pull request contains a backport of commit [fb13abef](https://github.com/openjdk/jdk/commit/fb13abef44d535ebc4535921fd4eb0f285030465) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Thomas Schatzl on 12 Jan 2026 and was reviewed by Erik ?sterlund, Ivan Walulya, Stefan Johansson and Aleksey Shipilev. > > Thanks! This pull request has now been integrated. Changeset: a90f4b6e Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/a90f4b6e57ed80ba15535dfa498e8d5cd95cc774 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8374743: G1 starts a concurrent mark when allocating humongous objects during initialization Reviewed-by: shade, iwalulya Backport-of: fb13abef44d535ebc4535921fd4eb0f285030465 ------------- PR: https://git.openjdk.org/jdk/pull/29160 From tschatzl at openjdk.org Mon Jan 12 11:42:45 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 12 Jan 2026 11:42:45 GMT Subject: RFR: 8374876: Epsilon: Convert to use Atomic In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 10:12:08 GMT, Aleksey Shipilev wrote: > Epsilon uses AtomicAccess on volatile data. Convert it to use Atomic. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `gc/epsilon`, 100x Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29163#pullrequestreview-3650365601 From stefank at openjdk.org Mon Jan 12 12:14:51 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 12 Jan 2026 12:14:51 GMT Subject: RFR: 8374876: Epsilon: Convert to use Atomic In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 10:12:08 GMT, Aleksey Shipilev wrote: > Epsilon uses AtomicAccess on volatile data. Convert it to use Atomic. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `gc/epsilon`, 100x Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29163#pullrequestreview-3650478548 From aboldtch at openjdk.org Mon Jan 12 13:13:00 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 12 Jan 2026 13:13:00 GMT Subject: RFR: 8372244: ZGC: Split ZTest into a VM and not VM test fixture [v3] In-Reply-To: References: Message-ID: > The `ZTest` GTest fixture is used for both VM and not VM tests, however the implementation requires VM. The not VM tests which use it are only interested in a sub-set of its features. > > I propose we split `ZTest` into a hierarchy of fixtures, one for not VM tests, and the other for VM tests. > > I could not find an easy way to identity which category of test a fixture is used in, so for now we just have to be diligent to use the appropriate fixture. > > We do have an assumption here that `os::next_random` is fine to call without having setup the VM. If this is changes in future we would have to add a not VM dependent prng function. > > Also the VMless fixture do not test if the OS is supported, as it might require VM features to work. But tests which run without VM should not be dependent if the VM is OS is supported. Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'JDK-8372241' into JDK-8372244 - Merge branch 'JDK-8372241' into JDK-8372244 - ZGC: Split ZTest into a VM and not VM test fixture ------------- Changes: https://git.openjdk.org/jdk/pull/28414/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28414&range=02 Stats: 38 lines in 11 files changed: 16 ins; 9 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/28414.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28414/head:pull/28414 PR: https://git.openjdk.org/jdk/pull/28414 From tschatzl at openjdk.org Mon Jan 12 13:34:52 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 12 Jan 2026 13:34:52 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v3] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 08:42:06 GMT, Stefan Johansson wrote: >> Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 564 commits: >> >> - Merge branch '8373253' into 8367993 >> - Merge branch 'master' into _8373253 >> - Merge branch 'master' into _8367993 >> - 8366058: Outdated comment in WinCAPISeedGenerator >> >> Reviewed-by: mullan >> - 8357258: x86: Improve receiver type profiling reliability >> >> Reviewed-by: kvn, vlivanov >> - 8373704: Improve "SocketException: Protocol family unavailable" message >> >> Reviewed-by: lucy, jpai >> - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently >> >> Reviewed-by: jiefu, jbhateja, erfang, qamai >> - 8343809: Add requires tag to mark tests that are incompatible with exploded image >> >> Reviewed-by: alanb, dholmes >> - 8374465: Spurious dot in documentation for JVMTI ClassLoad >> >> Reviewed-by: kbarrett >> - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket >> >> Reviewed-by: djelinski, mpowers, ascarpino >> - ... and 554 more: https://git.openjdk.org/jdk/compare/2aa8aa4b...28ccbb68 > > src/hotspot/share/gc/g1/g1Policy.cpp line 744: > >> 742: if (!_g1h->concurrent_mark()->is_fully_initialized()) { >> 743: return false; >> 744: } > > Is this needed? The `in_progress()` check below makes sure to only check the cm_thread when fully initialized. And this can never return true during initialization as no GC can have happened so that we end up in the Prepare Mixed GC ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2682294852 From sjohanss at openjdk.org Mon Jan 12 14:25:17 2026 From: sjohanss at openjdk.org (Stefan Johansson) Date: Mon, 12 Jan 2026 14:25:17 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v3] In-Reply-To: References: Message-ID: <57b1T2a6eGddz4Epg4zzhLPemdLm83uxN1IeWei-VYU=.36173a35-556c-4481-afdb-8d9d060bfaaa@github.com> On Fri, 9 Jan 2026 15:43:02 GMT, Leo Korinth wrote: >> src/hotspot/share/gc/g1/g1PeriodicGCTask.cpp line 46: >> >>> 44: return false; >>> 45: } >>> 46: >> >> Why is this needed? The initial young collection will make sure concurrent marking gets initialized, right? > > I do not remember if it was `whitebox` or if it was `System.gc()`, or something else. Do you think it is problematic ignoring it or just not needed? I see no reason for skipping a periodic GC because we have not yet initialized concurrent mark. If the user for example configured periodic full gc (not doing a periodic concurrent GC) we should not prevent this, just because no young collection has yet been done. Also, there should be no problem starting a concurrent periodic collection from what I can tell, since this will trigger initialization of concurrent mark. I did a quick test to verify this is ok (and it is), but there can of course be some corner case that I'm missing. In that case I would like to understand the corner case better to see if we can come up with a better approach than skipping the periodic collections until a young GC has been triggered. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2682486918 From tschatzl at openjdk.org Mon Jan 12 15:32:39 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 12 Jan 2026 15:32:39 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v3] In-Reply-To: <57b1T2a6eGddz4Epg4zzhLPemdLm83uxN1IeWei-VYU=.36173a35-556c-4481-afdb-8d9d060bfaaa@github.com> References: <57b1T2a6eGddz4Epg4zzhLPemdLm83uxN1IeWei-VYU=.36173a35-556c-4481-afdb-8d9d060bfaaa@github.com> Message-ID: On Mon, 12 Jan 2026 14:21:06 GMT, Stefan Johansson wrote: >> I do not remember if it was `whitebox` or if it was `System.gc()`, or something else. Do you think it is problematic ignoring it or just not needed? > > I see no reason for skipping a periodic GC because we have not yet initialized concurrent mark. If the user for example configured periodic full gc (not doing a periodic concurrent GC) we should not prevent this, just because no young collection has yet been done. > > Also, there should be no problem starting a concurrent periodic collection from what I can tell, since this will trigger initialization of concurrent mark. I did a quick test to verify this is ok (and it is), but there can of course be some corner case that I'm missing. In that case I would like to understand the corner case better to see if we can come up with a better approach than skipping the periodic collections until a young GC has been triggered. An unrelated issue could be that the task is run too early, before initialization is completed. However `G1ServiceTask` prevents that to happen already. So I also do not think we should keep this unless there is a demonstrated issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2682773138 From shade at openjdk.org Mon Jan 12 16:23:41 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 12 Jan 2026 16:23:41 GMT Subject: RFR: 8373819: GenShen: Requested generation may be null [v4] In-Reply-To: References: <8SWpQdaleulzSXfgF4fJ_zgekaijLs53t8Wer6IvKwo=.785abf41-65b7-44f6-90d0-2c63d5bf5981@github.com> Message-ID: On Fri, 9 Jan 2026 17:52:53 GMT, William Kemper wrote: >> This PR simplifies the generational control thread by decoupling it somewhat from the heap/gc cancellation mechanism. This is meant to prevent the control thread from seeing inconsistencies between `shHeap::_cancelled_gc` and `shGenControlThread::_requested_gc_cause`. > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Merge remote-tracking branch 'jdk/master' into fix-null-generation-crash > - Merge remote-tracking branch 'jdk/master' into fix-null-generation-crash > - Fix typo in assertion message > - Take regulator thread out of STS before requesting GC > > The request may block while it waits for control thread to stop old marking. If workers are already in the STS, and the regulator thread is still in the STS, but cannot yield, the safepoint will not run. Control, worker and regulator threads deadlock each other. > - Add comments > - Revert back to what should be on this branch > - Merge remote-tracking branch 'jdk/master' into fix-null-generation-crash > - Don't know how this file got deleted > - Carry over gc cancellation to gc request > - Do not let allocation failure requests be overwritten by other requests > - ... and 4 more: https://git.openjdk.org/jdk/compare/f5fa9e40...2e57f0ac > /issue add JDK-8373100 OK, why? This issue is already resolved. Why are you linking the new PR to it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28932#issuecomment-3739387975 From eastigeevich at openjdk.org Mon Jan 12 16:50:30 2026 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Mon, 12 Jan 2026 16:50:30 GMT Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact on GCs and JIT performance [v22] In-Reply-To: References: Message-ID: <0es2jUteLFJzSAHjGwnkoW4SDTZ7-7yQXsyloBNMs6E=.3bd217be-e5c3-4d1a-88c0-08e43acdc92b@github.com> > Arm Neoverse N1 erratum 1542419: "The core might fetch a stale instruction from memory which violates the ordering of instruction fetches". It is fixed in Neoverse N1 r4p1. > > Neoverse-N1 implementations mitigate erratum 1542419 with a workaround: > - Disable coherent icache. > - Trap IC IVAU instructions. > - Execute: > - `tlbi vae3is, xzr` > - `dsb sy` > > `tlbi vae3is, xzr` invalidates translations for all address spaces (global for address). It waits for all memory accesses using in-scope old translation information to complete before it is considered complete. > > As this workaround has significant overhead, Arm Neoverse N1 (MP050) Software Developer Errata Notice version 29.0 suggests: > > "Since one TLB inner-shareable invalidation is enough to avoid this erratum, the number of injected TLB invalidations should be minimized in the trap handler to mitigate the performance impact due to this workaround." > > This PR introduces a mechanism to defer instruction cache (ICache) invalidation for AArch64 to address the Arm Neoverse N1 erratum 1542419, which causes significant performance overhead if ICache invalidation is performed too frequently. The implementation includes detection of affected Neoverse N1 CPUs and automatic enabling of the workaround for relevant Neoverse N1 revisions. > > Changes include: > > * Added a new diagnostic AArch64 JVM flag `NeoverseN1Errata1542419` to enable or disable the workaround for the erratum. The flag is automatically enabled for Neoverse N1 CPUs prior to r4p1, as detected during VM initialization. > * Added a new diagnostic JVM flag `UseDeferredICacheInvalidation` to enable or disable defered icache invalidation. The flag is automatically enabled for AArch64 if CPU supports hardware cache coherence. > * Introduced the `ICacheInvalidationContext` class to manage deferred ICache invalidation, with platform-specific logic for AArch64. This context is used to batch ICache invalidations, reducing performance impact. > * Provided a default (no-op) implementation for `DefaultICacheInvalidationContext` on platforms where the workaround is not needed, ensuring portability and minimal impact on other architectures. > > Testing results: linux fastdebug build > - Neoverse-N1 (Graviton 2) > - [x] tier1: passed > - [x] tier2: passed > - [x] tier3: passed > - [x] tier4: 3 failures > - `containers/docker/TestJcmdWithSideCar.java`: JDK-8341518 > - `com/sun/nio/sctp/SctpChannel/CloseDescriptors.java`: JDK-8298466 > - `java/awt/print/PrinterJob/Prin... Evgeny Astigeevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits: - Remove redundant code - Merge branch 'master' into JDK-8370947 - Fix linux-cross-compile riscv64 build - Restore deleted comment - Remove redundant blank line - Remove redundant include - Merge branch 'master' into JDK-8370947 - Fix SpecJVM2008 regressions - Merge branch 'master' into JDK-8370947 - Fix macos and windows aarch64 builds - ... and 23 more: https://git.openjdk.org/jdk/compare/fb13abef...7153eb5c ------------- Changes: https://git.openjdk.org/jdk/pull/28328/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28328&range=21 Stats: 819 lines in 32 files changed: 755 ins; 22 del; 42 mod Patch: https://git.openjdk.org/jdk/pull/28328.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28328/head:pull/28328 PR: https://git.openjdk.org/jdk/pull/28328 From wkemper at openjdk.org Mon Jan 12 17:25:17 2026 From: wkemper at openjdk.org (William Kemper) Date: Mon, 12 Jan 2026 17:25:17 GMT Subject: RFR: 8373819: GenShen: Requested generation may be null [v4] In-Reply-To: References: <8SWpQdaleulzSXfgF4fJ_zgekaijLs53t8Wer6IvKwo=.785abf41-65b7-44f6-90d0-2c63d5bf5981@github.com> Message-ID: <4qJRAn8iSmTI7TPH0Eo_herCgysyVNxyAt7EbHkRwQk=.bbc92e5b-f727-4cc3-9eda-54addc4c83c8@github.com> On Fri, 9 Jan 2026 17:52:53 GMT, William Kemper wrote: >> This PR simplifies the generational control thread by decoupling it somewhat from the heap/gc cancellation mechanism. This is meant to prevent the control thread from seeing inconsistencies between `shHeap::_cancelled_gc` and `shGenControlThread::_requested_gc_cause`. > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Merge remote-tracking branch 'jdk/master' into fix-null-generation-crash > - Merge remote-tracking branch 'jdk/master' into fix-null-generation-crash > - Fix typo in assertion message > - Take regulator thread out of STS before requesting GC > > The request may block while it waits for control thread to stop old marking. If workers are already in the STS, and the regulator thread is still in the STS, but cannot yield, the safepoint will not run. Control, worker and regulator threads deadlock each other. > - Add comments > - Revert back to what should be on this branch > - Merge remote-tracking branch 'jdk/master' into fix-null-generation-crash > - Don't know how this file got deleted > - Carry over gc cancellation to gc request > - Do not let allocation failure requests be overwritten by other requests > - ... and 4 more: https://git.openjdk.org/jdk/compare/f5fa9e40...2e57f0ac We backed out the original "fix" for JDK-8873100 here: https://bugs.openjdk.org/browse/JDK-8374048. I'll remove the issue from the PR and just leave the connections in JBS. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28932#issuecomment-3739644285 From wkemper at openjdk.org Mon Jan 12 18:44:32 2026 From: wkemper at openjdk.org (William Kemper) Date: Mon, 12 Jan 2026 18:44:32 GMT Subject: RFR: 8373819: GenShen: Requested generation may be null [v4] In-Reply-To: References: <8SWpQdaleulzSXfgF4fJ_zgekaijLs53t8Wer6IvKwo=.785abf41-65b7-44f6-90d0-2c63d5bf5981@github.com> Message-ID: On Fri, 9 Jan 2026 23:05:52 GMT, Y. Srinivas Ramakrishna wrote: >> src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.cpp line 708: >> >>> 706: >>> 707: void ShenandoahGenerationalControlThread::notify_control_thread(MonitorLocker& ml, GCCause::Cause cause, ShenandoahGeneration* generation) { >>> 708: assert(_control_lock.is_locked(), "Request lock must be held here"); >> >> What is MonitorLocker, and what is `_control_lock`? Why are we checking `_control_lock` here? If ml is being passed here for the purposes of notification on it, it must be the case that it's locked and the assert at line 708 is a leakage of abstraction? I see that your problem here is that along one path you do nothing and and don't post a notification and along another you do some work and post a notification. It sounds like what you want instead is an API of the following shape: >> >> >> bool should_notify_control_thread(cause, generation) { ... }; >> >> >> and callers might do: >> >> >> MonitorLocker ml(...); >> if (should_notify_control_thread(cause, generation)) { >> ml.notify(); >> } >> ml.wait(); > > In addition, all of the various flavours of `notify_control_thread()` with optional parameters should ideally call down into the version that has all of the parameters specified. In the cases where these parameters aren't specified, the version of the method fills default parameters. > > The fully-parameterized version of the method then contains and consolidates the entire logic and any invariant/assertion checking of the various parameters that make sense, and executes the relevant logic to return a boolean result to allow the caller to notify and/or wait on the monitor. > What is MonitorLocker, and what is _control_lock? >From the declaration of `_control_lock`: // This lock is used to coordinate setting the _requested_gc_cause, _requested generation // and _gc_mode. It is important that these be changed together and have a consistent view. Monitor _control_lock; There are a few different paths into `notify_control_thread`. Rather than expose the locking protocol to callers and duplicating the logic to notify or not, we have an entry point that acquires the lock for the caller before calling down into the method that does the actual work. On some paths, the lock is already held for other reasons, so the overload is provided for these cases (the lock is not reentrant). > optional parameters should ideally call down into the version that has all of the parameters specified. This is what is happening, except in the case of allocation failures where the caller does not "know" the generation being collected (assuming a collection is even running). The implementation here intentionally hides as much information as possible. Some callers do not need to provide the generation. In some cases, only the control thread itself can provide the correct generation. We could expose this piece of data to other threads so that could always include a generation in their request, but the control thread would still end up ignoring it. This would also be confusing on a first read of the code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28932#discussion_r2683457097 From wkemper at openjdk.org Mon Jan 12 18:53:28 2026 From: wkemper at openjdk.org (William Kemper) Date: Mon, 12 Jan 2026 18:53:28 GMT Subject: RFR: 8373819: GenShen: Requested generation may be null [v4] In-Reply-To: References: <8SWpQdaleulzSXfgF4fJ_zgekaijLs53t8Wer6IvKwo=.785abf41-65b7-44f6-90d0-2c63d5bf5981@github.com> Message-ID: <0fM9tDaIfMBZvRsmcCzIduQL83vhSyV6QiXPlaIm1NA=.687fe3bb-c154-4c77-b988-349bb937b61a@github.com> On Fri, 9 Jan 2026 23:08:11 GMT, Y. Srinivas Ramakrishna wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: >> >> - Merge remote-tracking branch 'jdk/master' into fix-null-generation-crash >> - Merge remote-tracking branch 'jdk/master' into fix-null-generation-crash >> - Fix typo in assertion message >> - Take regulator thread out of STS before requesting GC >> >> The request may block while it waits for control thread to stop old marking. If workers are already in the STS, and the regulator thread is still in the STS, but cannot yield, the safepoint will not run. Control, worker and regulator threads deadlock each other. >> - Add comments >> - Revert back to what should be on this branch >> - Merge remote-tracking branch 'jdk/master' into fix-null-generation-crash >> - Don't know how this file got deleted >> - Carry over gc cancellation to gc request >> - Do not let allocation failure requests be overwritten by other requests >> - ... and 4 more: https://git.openjdk.org/jdk/compare/f5fa9e40...2e57f0ac > > src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.cpp line 721: > >> 719: } >> 720: >> 721: void ShenandoahGenerationalControlThread::notify_control_thread(GCCause::Cause cause) { > > Apropos my comment above, this code has a bad smell that some versions of the method expect the lock to be held, and other methods acquire the lock. > > It makes reasoning about the code at an abstract level very error-prone, and potentially difficult to maintain correctly over time. The overload that does the actual work always requires the lock to be held. The other overload is a convenience method that takes the lock and provides the locker to the actual method that does the work. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28932#discussion_r2683485267 From wkemper at openjdk.org Mon Jan 12 19:09:24 2026 From: wkemper at openjdk.org (William Kemper) Date: Mon, 12 Jan 2026 19:09:24 GMT Subject: RFR: 8373819: GenShen: Requested generation may be null [v4] In-Reply-To: References: <8SWpQdaleulzSXfgF4fJ_zgekaijLs53t8Wer6IvKwo=.785abf41-65b7-44f6-90d0-2c63d5bf5981@github.com> Message-ID: On Sat, 10 Jan 2026 00:07:54 GMT, Y. Srinivas Ramakrishna wrote: >> The reason I am leaving this comment here is that further above (lines 85-88), and in many of the other mode changes we seem to take care to use the control lock to protect these transitions so that other parties may observe the right state. Perhaps that is not needed in some cases, but the plurality of different forms of update of state that is modifed and may be read by other threads in conjunction with other state leaves me feeling queasy about the possible cracks in the coordination surface that may open us up to trouble. > > (Note that the "mode" parameter used in the non-generational control thread is completely internal to the control thread and unlike in the case of the generational control thread here, never leaks out of that thread to be consulted by another thread asynchronously.) > Will they "observe the shutdown" if mode isn't "stopped"? Yes, gc waiters are waiting to observe an increment in the GC ID. Alloc failure waiters are waiting for `ShHeap::_cancelled_cause` to stop being an allocation failure. Both groups of waiters will exit their loop if the control thread itself should terminate. Only the regulator thread waits on `gc_mode`. Changing the `gc_mode` is always done when the `_control_lock` is held and will notify any waiters. The regulator thread does read the `gc_mode` without a lock, but only for deciding when to evaluate heuristic triggers. The regulator thread does take the lock and reads `gc_mode` again before making a request to start a GC cycle. > the "mode" parameter used in the non-generational control thread is completely internal to the control thread This is one of the major differences with the non-generational mode. In the non-generational mode, the control thread is responsible for running the collection cycle _and deciding when to start a cycle_. In the non-generational mode, the control thread cannot evaluation heuristics when it is running a cycle (indeed, it would make no sense to because a cycle is already running). However, in the generational mode, these responsibilities are decoupled because we want to continue evaluating heuristics while the control thread is running an old mark. This is how we decide to interrupt an old cycle and start a young cycle. The `gc_mode` is exposed to the regulator thread so that it does not futilely evaluate heuristics when the control thread is running a young or global cycle. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28932#discussion_r2683533455 From xpeng at openjdk.org Mon Jan 12 20:55:18 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 12 Jan 2026 20:55:18 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v20] In-Reply-To: References: <797j9fNWUlV491wWKbFMfthH99o3A5493T0Pcdn_zdc=.417c13b0-8618-4402-aafa-3d86c45c8ff6@github.com> Message-ID: On Tue, 6 Jan 2026 21:11:20 GMT, Kelvin Nilsen wrote: >> Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 265 commits: >> >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - Fix build error after merging from tip >> - Merge branch 'master' into cas-alloc-1 >> - Merge branch 'master' into cas-alloc-1 >> - Some comments updates as suggested in PR review >> - Fix build failure after merge >> - Expend promoted from ShenandoahOldCollectorAllocator >> - Merge branch 'master' into cas-alloc-1 >> - Address PR comments >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - ... and 255 more: https://git.openjdk.org/jdk/compare/de81d389...cf13b7b5 > > src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp line 167: > >> 165: }; >> 166: >> 167: HeapWord* ShenandoahHeapRegion::allocate_atomic(size_t size, const ShenandoahAllocRequest& req, bool &ready_for_retire) { > > Suggest we add a fourth arg: int &contended > We initialize contended to zero What do we want to track with the `contended` arg? If we want to track the number of threads allocating simultaneously from the same region or from same shared alloc region index, we can't archive either of them with the arg `&contended `. Let's discuss this later, I need to understand the intention/idea before making this change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2683872357 From xpeng at openjdk.org Mon Jan 12 21:14:16 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 12 Jan 2026 21:14:16 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v20] In-Reply-To: References: <797j9fNWUlV491wWKbFMfthH99o3A5493T0Pcdn_zdc=.417c13b0-8618-4402-aafa-3d86c45c8ff6@github.com> Message-ID: On Tue, 6 Jan 2026 21:17:57 GMT, Kelvin Nilsen wrote: >> Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 265 commits: >> >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - Fix build error after merging from tip >> - Merge branch 'master' into cas-alloc-1 >> - Merge branch 'master' into cas-alloc-1 >> - Some comments updates as suggested in PR review >> - Fix build failure after merge >> - Expend promoted from ShenandoahOldCollectorAllocator >> - Merge branch 'master' into cas-alloc-1 >> - Address PR comments >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - ... and 255 more: https://git.openjdk.org/jdk/compare/de81d389...cf13b7b5 > > src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 194: > >> 192: if (ShenandoahHeapRegion* r = nullptr; (r = _alloc_regions[i].address) != nullptr && r->is_active_alloc_region()) { >> 193: bool ready_for_retire = false; >> 194: HeapWord* obj = atomic_allocate_in(r, true, req, in_new_region, ready_for_retire); > > Insert before atomic_allocate_in: int contended > Pass this as 6th arg to atomic_allocate_in() > Add this code after atomic_allocate_in(): > if ((i == alloc_start_index) && (contended > 1)) { > randomize_start_index(); // I think this is realized by setting _alloc_start_index to UINT_MAX > } template template HeapWord* ShenandoahAllocator::attempt_allocation_in_alloc_regions(ShenandoahAllocRequest &req, bool &in_new_region, uint const alloc_start_index, uint ®ions_ready_for_refresh) The API attempt_allocation_in_alloc_regions is designed as above, it tries to allocate from shared alloc regions, iterating from `alloc_start_index` in one run, it doesn't make sense to change the starting index inside this method during the loop. Also, the `contended` you are suggesting is actually the number regions it has attempted in `attempt_allocation_in_alloc_regions`, It doesn't reflect the contention. There might be case we truly want to shuffle/re-random the alloc_start_index for mutator threads, e.g. most of mutator threads have same alloc_start_index causing congestion/contention in one shared alloc region, but it is a bit tricky to trace and detects, we could do it in future improvments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2683919611 From xpeng at openjdk.org Mon Jan 12 21:19:49 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 12 Jan 2026 21:19:49 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v20] In-Reply-To: References: <797j9fNWUlV491wWKbFMfthH99o3A5493T0Pcdn_zdc=.417c13b0-8618-4402-aafa-3d86c45c8ff6@github.com> Message-ID: On Tue, 6 Jan 2026 21:30:09 GMT, Kelvin Nilsen wrote: >> Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 265 commits: >> >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - Fix build error after merging from tip >> - Merge branch 'master' into cas-alloc-1 >> - Merge branch 'master' into cas-alloc-1 >> - Some comments updates as suggested in PR review >> - Fix build failure after merge >> - Expend promoted from ShenandoahOldCollectorAllocator >> - Merge branch 'master' into cas-alloc-1 >> - Address PR comments >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - ... and 255 more: https://git.openjdk.org/jdk/compare/de81d389...cf13b7b5 > > src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 233: > >> 231: // evacuation are not updated during evacuation. For both young and old regions r, it is essential that all >> 232: // PLABs be made parsable at the end of evacuation. This is enabled by retiring all plabs at end of evacuation. >> 233: region->concurrent_set_update_watermark(region->top()); > > There's a race here. Multiple mutators may be updating watermark in parallel. It may be that the mutator who most recently allocated is not the mutator who makes the "most recent" overwrite of set_update_watermark(). > > I think the better fix is to remove this code. Update refs should just assume that update watermark equals top for any region in the Old gen, and for any region that was in the Collector partition. It may not be easy to know which regions were "in the Collector partition". Maybe we use a Sentinel value for update_watermark on all such regions. Just overwrite update_watermark(nullptr)? And check for this in update-refs? Needs a solution, and solution needs to be documented in code comments. I don't really know how watermark is used, but based on you comments and explanations I it might be possible to use top instead of watermark if is only used in the old gen, it won't be used in other young gen we could remove concurrent_set_update_watermark, I'll try to make the change and test it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2683935723 From xpeng at openjdk.org Mon Jan 12 21:19:51 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 12 Jan 2026 21:19:51 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v20] In-Reply-To: References: <797j9fNWUlV491wWKbFMfthH99o3A5493T0Pcdn_zdc=.417c13b0-8618-4402-aafa-3d86c45c8ff6@github.com> Message-ID: On Wed, 7 Jan 2026 22:24:23 GMT, Xiaolong Peng wrote: >> src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 254: >> >>> 252: // Step 1: find out the alloc regions which are ready to refresh. >>> 253: for (uint i = 0; i < _alloc_region_count; i++) { >>> 254: ShenandoahAllocRegion* alloc_region = &_alloc_regions[i]; >> >> We've got the heap lock here. why does this need to be atomic? Comments in the code should make this clear. > > I believe AtomicAccess::load here is not needed, I'll remove it. I have removed the AtomicAccess::load here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2683938237 From kdnilsen at openjdk.org Mon Jan 12 21:43:57 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 12 Jan 2026 21:43:57 GMT Subject: RFR: 8369048: GenShen: Defer ShenFreeSet::available() during rebuild [v5] In-Reply-To: <_PEoOc0oWb8Vzq16-Or_hykkL4NkIrwEFgLCgCRac5U=.2c23c497-acbe-48f9-a1dc-4eb4e8f25a8d@github.com> References: <_PEoOc0oWb8Vzq16-Or_hykkL4NkIrwEFgLCgCRac5U=.2c23c497-acbe-48f9-a1dc-4eb4e8f25a8d@github.com> Message-ID: > This code introduces a new rebuild-freeset lock for purposes of coordinating the freeset rebuild activities and queries as to memory available for allocation in the mutator partition. > > This addresses a problem that results if available memory is probed while we are rebuilding the freeset. > > Rather than using the existing global heap lock to synchronize these activities, a new more narrowly scoped lock is introduced. This allows the available memory to be probed even when other activities hold the global heap lock for reasons other than rebuilding the freeset, such as when they are allocating memory. It is known that the global heap lock is heavily contended for certain workloads, and using this new lock avoids adding to contention for the global heap lock. Kelvin Nilsen has updated the pull request incrementally with two additional commits since the last revision: - Use appropriate locks for ShenFreeSet used() and capacity() - Revert "Add rebuild synchronization to capacity() and used()" This reverts commit 3c29dc10b17f1856203135a31b75c3afea16ba50. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27612/files - new: https://git.openjdk.org/jdk/pull/27612/files/3c29dc10..300a256a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27612&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27612&range=03-04 Stats: 16 lines in 4 files changed: 7 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/27612.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27612/head:pull/27612 PR: https://git.openjdk.org/jdk/pull/27612 From xpeng at openjdk.org Mon Jan 12 22:00:26 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 12 Jan 2026 22:00:26 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v20] In-Reply-To: References: <797j9fNWUlV491wWKbFMfthH99o3A5493T0Pcdn_zdc=.417c13b0-8618-4402-aafa-3d86c45c8ff6@github.com> Message-ID: On Tue, 6 Jan 2026 18:09:05 GMT, Kelvin Nilsen wrote: >> Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 265 commits: >> >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - Fix build error after merging from tip >> - Merge branch 'master' into cas-alloc-1 >> - Merge branch 'master' into cas-alloc-1 >> - Some comments updates as suggested in PR review >> - Fix build failure after merge >> - Expend promoted from ShenandoahOldCollectorAllocator >> - Merge branch 'master' into cas-alloc-1 >> - Address PR comments >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - ... and 255 more: https://git.openjdk.org/jdk/compare/de81d389...cf13b7b5 > > src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 133: > >> 131: ShenandoahHeapAccountingUpdater accounting_updater(_free_set, ALLOC_PARTITION); >> 132: >> 133: if (regions_ready_for_refresh > 0u) { > > Since we've already taken the heap lock because we failed to allocate "fast", I'm ok to go ahead and refresh any regions that are ready right now, even if it's only 1 region. > > I'm wondering if we can avoid thrashing in the case that there are no more regions available. We might want to keep a state variable that represents whether there exist free-set regions with which to refresh our cache. This could be updated whenever we "add to" or "rebuild" the free set, and whenever refresh_alloc_regions() find there is insufficient supply to demand. We would want to avoid repeated calls to refresh_alloc_regions() if there are no "refresh_regions_available". To actually track the accurate number of `refresh_regions_available`, we need to add three counters: one for each partition. Since we always retire the region is the free is less than PLAB::min_size(), we may already have it in free set partitions(_region_counts?). There is also complexity here, for Collector and OldCollector, we allow them to transfer regions from Mutator partition, we have to consider FREE regions in mutator partition to calculate "refresh_regions_available" for Collector/OldCollector. It should be rare case when the entire heap is almost filled up, I am wondering how much benefit we could get from doing that, if you are ok with it I'd suggest to consider this optimization later. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2684045131 From ysr at openjdk.org Mon Jan 12 23:03:26 2026 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Mon, 12 Jan 2026 23:03:26 GMT Subject: RFR: 8373819: Genshen: Control thread can miss allocation failure notification (redux) [v4] In-Reply-To: <4qJRAn8iSmTI7TPH0Eo_herCgysyVNxyAt7EbHkRwQk=.bbc92e5b-f727-4cc3-9eda-54addc4c83c8@github.com> References: <8SWpQdaleulzSXfgF4fJ_zgekaijLs53t8Wer6IvKwo=.785abf41-65b7-44f6-90d0-2c63d5bf5981@github.com> <4qJRAn8iSmTI7TPH0Eo_herCgysyVNxyAt7EbHkRwQk=.bbc92e5b-f727-4cc3-9eda-54addc4c83c8@github.com> Message-ID: On Mon, 12 Jan 2026 17:22:29 GMT, William Kemper wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: >> >> - Merge remote-tracking branch 'jdk/master' into fix-null-generation-crash >> - Merge remote-tracking branch 'jdk/master' into fix-null-generation-crash >> - Fix typo in assertion message >> - Take regulator thread out of STS before requesting GC >> >> The request may block while it waits for control thread to stop old marking. If workers are already in the STS, and the regulator thread is still in the STS, but cannot yield, the safepoint will not run. Control, worker and regulator threads deadlock each other. >> - Add comments >> - Revert back to what should be on this branch >> - Merge remote-tracking branch 'jdk/master' into fix-null-generation-crash >> - Don't know how this file got deleted >> - Carry over gc cancellation to gc request >> - Do not let allocation failure requests be overwritten by other requests >> - ... and 4 more: https://git.openjdk.org/jdk/compare/f5fa9e40...2e57f0ac > > We backed out the original "fix" for JDK-8373100 here: https://bugs.openjdk.org/browse/JDK-8374048. I'll remove the issue from the PR and just leave the connections in JBS. Thanks for your responses/explanation, @earthling-amzn. They all make sense; we can defer the documentation and any refactor/clean-ups for a future PR, since these changes are needed to fix the existing behaviour and it makes sense to land this change sooner rather than later. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28932#issuecomment-3740894838 From wkemper at openjdk.org Mon Jan 12 23:39:23 2026 From: wkemper at openjdk.org (William Kemper) Date: Mon, 12 Jan 2026 23:39:23 GMT Subject: Integrated: 8373819: Genshen: Control thread can miss allocation failure notification (redux) In-Reply-To: <8SWpQdaleulzSXfgF4fJ_zgekaijLs53t8Wer6IvKwo=.785abf41-65b7-44f6-90d0-2c63d5bf5981@github.com> References: <8SWpQdaleulzSXfgF4fJ_zgekaijLs53t8Wer6IvKwo=.785abf41-65b7-44f6-90d0-2c63d5bf5981@github.com> Message-ID: On Fri, 19 Dec 2025 19:09:01 GMT, William Kemper wrote: > This PR simplifies the generational control thread by decoupling it somewhat from the heap/gc cancellation mechanism. This is meant to prevent the control thread from seeing inconsistencies between `shHeap::_cancelled_gc` and `shGenControlThread::_requested_gc_cause`. This pull request has now been integrated. Changeset: 15b7a425 Author: William Kemper URL: https://git.openjdk.org/jdk/commit/15b7a4252b8d3595b7bc409e20d4c617e89240e8 Stats: 95 lines in 4 files changed: 45 ins; 17 del; 33 mod 8373819: Genshen: Control thread can miss allocation failure notification (redux) Reviewed-by: kdnilsen, ysr ------------- PR: https://git.openjdk.org/jdk/pull/28932 From shade at openjdk.org Tue Jan 13 07:30:06 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 13 Jan 2026 07:30:06 GMT Subject: RFR: 8374876: Epsilon: Convert to use Atomic In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 10:12:08 GMT, Aleksey Shipilev wrote: > Epsilon uses AtomicAccess on volatile data. Convert it to use Atomic. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `gc/epsilon`, 100x Thanks for reviews, here goes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29163#issuecomment-3742483842 From shade at openjdk.org Tue Jan 13 07:33:58 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 13 Jan 2026 07:33:58 GMT Subject: Integrated: 8374876: Epsilon: Convert to use Atomic In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 10:12:08 GMT, Aleksey Shipilev wrote: > Epsilon uses AtomicAccess on volatile data. Convert it to use Atomic. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `gc/epsilon`, 100x This pull request has now been integrated. Changeset: c000343b Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/c000343bbb1d822d2cee37e1a27672cfb3128bee Stats: 14 lines in 4 files changed: 2 ins; 3 del; 9 mod 8374876: Epsilon: Convert to use Atomic Reviewed-by: tschatzl, stefank ------------- PR: https://git.openjdk.org/jdk/pull/29163 From eastigeevich at openjdk.org Tue Jan 13 12:36:16 2026 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Tue, 13 Jan 2026 12:36:16 GMT Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact on GCs and JIT performance [v23] In-Reply-To: References: Message-ID: > Arm Neoverse N1 erratum 1542419: "The core might fetch a stale instruction from memory which violates the ordering of instruction fetches". It is fixed in Neoverse N1 r4p1. > > Neoverse-N1 implementations mitigate erratum 1542419 with a workaround: > - Disable coherent icache. > - Trap IC IVAU instructions. > - Execute: > - `tlbi vae3is, xzr` > - `dsb sy` > > `tlbi vae3is, xzr` invalidates translations for all address spaces (global for address). It waits for all memory accesses using in-scope old translation information to complete before it is considered complete. > > As this workaround has significant overhead, Arm Neoverse N1 (MP050) Software Developer Errata Notice version 29.0 suggests: > > "Since one TLB inner-shareable invalidation is enough to avoid this erratum, the number of injected TLB invalidations should be minimized in the trap handler to mitigate the performance impact due to this workaround." > > This PR introduces a mechanism to defer instruction cache (ICache) invalidation for AArch64 to address the Arm Neoverse N1 erratum 1542419, which causes significant performance overhead if ICache invalidation is performed too frequently. The implementation includes detection of affected Neoverse N1 CPUs and automatic enabling of the workaround for relevant Neoverse N1 revisions. > > Changes include: > > * Added a new diagnostic AArch64 JVM flag `NeoverseN1Errata1542419` to enable or disable the workaround for the erratum. The flag is automatically enabled for Neoverse N1 CPUs prior to r4p1, as detected during VM initialization. > * Added a new diagnostic JVM flag `UseDeferredICacheInvalidation` to enable or disable defered icache invalidation. The flag is automatically enabled for AArch64 if CPU supports hardware cache coherence. > * Introduced the `ICacheInvalidationContext` class to manage deferred ICache invalidation, with platform-specific logic for AArch64. This context is used to batch ICache invalidations, reducing performance impact. > * Provided a default (no-op) implementation for `DefaultICacheInvalidationContext` on platforms where the workaround is not needed, ensuring portability and minimal impact on other architectures. > > Testing results: linux fastdebug build > - Neoverse-N1 (Graviton 2) > - [x] tier1: passed > - [x] tier2: passed > - [x] tier3: passed > - [x] tier4: 3 failures > - `containers/docker/TestJcmdWithSideCar.java`: JDK-8341518 > - `com/sun/nio/sctp/SctpChannel/CloseDescriptors.java`: JDK-8298466 > - `java/awt/print/PrinterJob/Prin... Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: Fix macos and windows aarch64 debug builds ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28328/files - new: https://git.openjdk.org/jdk/pull/28328/files/7153eb5c..3abb6de4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28328&range=22 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28328&range=21-22 Stats: 10 lines in 3 files changed: 6 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28328.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28328/head:pull/28328 PR: https://git.openjdk.org/jdk/pull/28328 From kbarrett at openjdk.org Tue Jan 13 17:56:14 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 13 Jan 2026 17:56:14 GMT Subject: RFR: 8374984: Convert workerUtils to use Atomic Message-ID: <537jC3DpvLxPUOPm3Q6f1y6uplIYqd2KrVGUP2CRiJ0=.e7bbf6ef-692b-4533-87b2-3f14d28be771@github.com> Please review this change to make SubTasksDone and SequentialSubTasksDone use Atomic instead of AtomicAccess. Testing: mach5 tier1 ------------- Commit messages: - worker utils Changes: https://git.openjdk.org/jdk/pull/29201/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29201&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374984 Stats: 20 lines in 2 files changed: 3 ins; 0 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/29201.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29201/head:pull/29201 PR: https://git.openjdk.org/jdk/pull/29201 From shade at openjdk.org Tue Jan 13 19:38:27 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 13 Jan 2026 19:38:27 GMT Subject: RFR: 8375209: Xcheck:jni should check when GC is about to deadlock in JNI critical section Message-ID: Related to [JDK-8375188](https://bugs.openjdk.org/browse/JDK-8375188), and regardless what happens with the implementations, I think we really want to have `-Xcheck:jni` to tell us when we are about to deadlock. This is useful to diagnose the issue in the field. We used to have this capability in Serial/Parallel prior to [JDK-8192647](https://bugs.openjdk.org/browse/JDK-8192647), AFAICS: https://github.com/openjdk/jdk/commit/a9c9f7f0cbb2f2395fef08348bf867ffa8875d73#diff-d27fc793db1bf9314b322d494cd1c3269629fe27a605b4441de08d543d020fc3L341-L344 ZGC never had this check, AFAICS. I am not sure if I put the check in the right place. I believe it is in the right one, as we want to check that Java thread is not blocked waiting for GC driver to respond while being in JNI critical section itself. Current placement works well with the test. I opted to add the checking at the paths that are really affected by the issue, because it is really about what implementations are doing in this case. But we can also summarily check this in all `CollectedHeap::collect` overrides -- similar to ZGC case -- so that testing with `-Xcheck:jni` with Epsilon/G1/Shenandoah would also cover every other GC that might run into trouble. Additional testing: - [x] New test, 100x repetitions ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/29206/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29206&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375209 Stats: 187 lines in 5 files changed: 187 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29206.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29206/head:pull/29206 PR: https://git.openjdk.org/jdk/pull/29206 From xpeng at openjdk.org Tue Jan 13 19:42:35 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 13 Jan 2026 19:42:35 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v35] In-Reply-To: References: Message-ID: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request incrementally with five additional commits since the last revision: - Add virtual back for release_alloc_regions and reserve_alloc_regions to fix link error - Eagerly refresh alloc region if there are 1/2 or more of alloc regions ready for retire - Update comments for function alloc_start_index - UUpdate the comments on method allocate - Make release_alloc_regions and reserve_alloc_regions non-virtual methods ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/c5824564..73e6e8da Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=34 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=33-34 Stats: 32 lines in 2 files changed: 24 ins; 2 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From shade at openjdk.org Tue Jan 13 19:44:23 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 13 Jan 2026 19:44:23 GMT Subject: RFR: 8375209: Xcheck:jni should check when GC is about to deadlock in JNI critical section [v2] In-Reply-To: References: Message-ID: > Related to [JDK-8375188](https://bugs.openjdk.org/browse/JDK-8375188), and regardless what happens with the implementations, I think we really want to have `-Xcheck:jni` to tell us when we are about to deadlock. This is useful to diagnose the issue in the field. > > We used to have this capability in Serial/Parallel prior to [JDK-8192647](https://bugs.openjdk.org/browse/JDK-8192647), AFAICS: https://github.com/openjdk/jdk/commit/a9c9f7f0cbb2f2395fef08348bf867ffa8875d73#diff-d27fc793db1bf9314b322d494cd1c3269629fe27a605b4441de08d543d020fc3L341-L344 > > ZGC never had this check, AFAICS. I am not sure if I put the check in the right place. I believe it is in the right one, as we want to check that Java thread is not blocked waiting for GC driver to respond while being in JNI critical section itself. Current placement works well with the test. > > I opted to add the checking at the paths that are really affected by the issue, because it is really about what implementations are doing in this case. But we can also summarily check this in all `CollectedHeap::collect` overrides -- similar to ZGC case -- so that testing with `-Xcheck:jni` with Epsilon/G1/Shenandoah would also cover every other GC that might run into trouble. > > Additional testing: > - [x] New test, 100x repetitions Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Terminology ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29206/files - new: https://git.openjdk.org/jdk/pull/29206/files/ad6a8c28..4eeb4a04 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29206&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29206&range=00-01 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/29206.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29206/head:pull/29206 PR: https://git.openjdk.org/jdk/pull/29206 From xpeng at openjdk.org Tue Jan 13 20:10:10 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 13 Jan 2026 20:10:10 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v36] In-Reply-To: References: Message-ID: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 290 commits: - Merge branch 'openjdk:master' into cas-alloc-1 - Add virtual back for release_alloc_regions and reserve_alloc_regions to fix link error - Eagerly refresh alloc region if there are 1/2 or more of alloc regions ready for retire - Update comments for function alloc_start_index - UUpdate the comments on method allocate - Make release_alloc_regions and reserve_alloc_regions non-virtual methods - Move thread locals to ShenandoahThreadLocalData - Add comments for public methods - Remove necessary atomic load - Add _epoch_id to ShenandoahAllocator to trace the update of shared alloc regions - ... and 280 more: https://git.openjdk.org/jdk/compare/4d0ad0a4...9e0520ba ------------- Changes: https://git.openjdk.org/jdk/pull/26171/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=35 Stats: 1724 lines in 28 files changed: 1375 ins; 235 del; 114 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From jvernee at openjdk.org Tue Jan 13 21:42:19 2026 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 13 Jan 2026 21:42:19 GMT Subject: RFR: 8375209: Xcheck:jni should check when GC is about to deadlock in JNI critical section [v2] In-Reply-To: References: Message-ID: <_ejJfMSsqwY2tDnp_uiwa3zup4iIXvdmkeURyGHtC6Y=.14d99d36-d495-4bfd-bb2f-be7e5a7d3a78@github.com> On Tue, 13 Jan 2026 19:44:23 GMT, Aleksey Shipilev wrote: >> Related to [JDK-8375188](https://bugs.openjdk.org/browse/JDK-8375188), and regardless what happens with the implementations, I think we really want to have `-Xcheck:jni` to tell us when we are about to deadlock. This is useful to diagnose the issue in the field. >> >> We used to have this capability in Serial/Parallel prior to [JDK-8192647](https://bugs.openjdk.org/browse/JDK-8192647), AFAICS: https://github.com/openjdk/jdk/commit/a9c9f7f0cbb2f2395fef08348bf867ffa8875d73#diff-d27fc793db1bf9314b322d494cd1c3269629fe27a605b4441de08d543d020fc3L341-L344 >> >> ZGC never had this check, AFAICS. I am not sure if I put the check in the right place. I believe it is in the right one, as we want to check that Java thread is not blocked waiting for GC driver to respond while being in JNI critical section itself. Current placement works well with the test. >> >> I opted to add the checking at the paths that are really affected by the issue, because it is really about what implementations are doing in this case. But we can also summarily check this in all `CollectedHeap::collect` overrides -- similar to ZGC case -- so that testing with `-Xcheck:jni` with Epsilon/G1/Shenandoah would also cover every other GC that might run into trouble. >> >> Additional testing: >> - [x] New test, 100x repetitions > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Terminology Given the restriction that no other JNI functions should be called inside a critical region, I was wondering how a thread running plain native code could ever get blocked by the GC. I see in the test that you are returning to Java during a critical region. I don't think we should be leaving the native thread state at all during a critical region. The spec of `GetPrimitiveArrayCritical` also implies this by specifically talking about _native code_: > Inside a critical region, **native code** must not call other JNI functions, or any system call that may cause the current thread to block and wait for another Java thread. (Of course, once we return to Java, the user no longer has control over whether the thread calls JNI functions or blocking system calls either) Have you considered adding this check in the thread state transition code instead? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29206#issuecomment-3746681978 From xpeng at openjdk.org Tue Jan 13 22:13:51 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 13 Jan 2026 22:13:51 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v37] In-Reply-To: References: Message-ID: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request incrementally with two additional commits since the last revision: - Fix assert when after eagerly refresh alloc regions after fast allocation - Remove the support of 0 for flags ShenandoahMutatorAllocRegions and ShenandoahCollectorAllocRegions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/9e0520ba..8879ec52 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=36 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=35-36 Stats: 15 lines in 2 files changed: 0 ins; 11 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From wkemper at openjdk.org Tue Jan 13 22:21:02 2026 From: wkemper at openjdk.org (William Kemper) Date: Tue, 13 Jan 2026 22:21:02 GMT Subject: RFR: 8369048: GenShen: Defer ShenFreeSet::available() during rebuild [v5] In-Reply-To: References: <_PEoOc0oWb8Vzq16-Or_hykkL4NkIrwEFgLCgCRac5U=.2c23c497-acbe-48f9-a1dc-4eb4e8f25a8d@github.com> Message-ID: On Mon, 12 Jan 2026 21:43:57 GMT, Kelvin Nilsen wrote: >> This code introduces a new rebuild-freeset lock for purposes of coordinating the freeset rebuild activities and queries as to memory available for allocation in the mutator partition. >> >> This addresses a problem that results if available memory is probed while we are rebuilding the freeset. >> >> Rather than using the existing global heap lock to synchronize these activities, a new more narrowly scoped lock is introduced. This allows the available memory to be probed even when other activities hold the global heap lock for reasons other than rebuilding the freeset, such as when they are allocating memory. It is known that the global heap lock is heavily contended for certain workloads, and using this new lock avoids adding to contention for the global heap lock. > > Kelvin Nilsen has updated the pull request incrementally with two additional commits since the last revision: > > - Use appropriate locks for ShenFreeSet used() and capacity() > - Revert "Add rebuild synchronization to capacity() and used()" > > This reverts commit 3c29dc10b17f1856203135a31b75c3afea16ba50. GHA failure looks unrelated to these changes. Internal tests are succeeding. ------------- Marked as reviewed by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27612#pullrequestreview-3658154746 From xpeng at openjdk.org Tue Jan 13 22:56:00 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 13 Jan 2026 22:56:00 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v20] In-Reply-To: References: <797j9fNWUlV491wWKbFMfthH99o3A5493T0Pcdn_zdc=.417c13b0-8618-4402-aafa-3d86c45c8ff6@github.com> Message-ID: <3u3UesPyV_o1bI2aQFwwMOW3zOh2ES5K8OSUszdhxuo=.07a4dcff-885a-4b0e-8cb2-d236cdd5ed75@github.com> On Wed, 7 Jan 2026 14:56:15 GMT, Kelvin Nilsen wrote: >> src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 114: >> >>> 112: HeapWord* obj = attempt_allocation_in_alloc_regions(req, in_new_region, alloc_start_index(), dummy); >>> 113: if (obj != nullptr) { >>> 114: return obj; >> >> Even in the case that we successfully fill our allocation request, if regions_ready_for_refresh is greater than some percentage of _alloc_region_count (e.g. > _alloc_region_count / 4), then we should grab the heap lock and refresh_alloc_regions() here. Otherwise, we will gradually degrade the number of directly_allocatable_regions until we are down to one before we refresh any of them. > > After further thought, am thinking the threshold for refresh_alloc_regions() might be if (regions_ready_for_refresh >= _alloc_region_count / 2). That would reduce the number of slow paths through the allocator. If we can re-randomize the thread-local start indexes when their original start index hits a retire-able region, this might work ok. I have added support for this, it works as: obj = fast-path-alloc(); if (obj != nullptr && regions_ready_for_refresh < _alloc_region_count / 2) { return obj; } if (obj = nullptr) { obj = slow-path-alloc(); } else { ShenandoahHeapLocker locker(ShenandoahHeap::heap()->lock(), false); refresh_alloc_regions(); } If fast-path-alloc succeeds but determines that there are more than 50% of alloc regions are ready for retiring, when it take heap heap lock to refresh alloc regions, it CANNOT yield to safepoint, because the thread is holding uninitialized obj. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2688380076 From xpeng at openjdk.org Tue Jan 13 22:59:31 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 13 Jan 2026 22:59:31 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v38] In-Reply-To: References: Message-ID: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: While eagerly refresh alloc regions, thread should not yield to safepoint because it is holding uninitialized new object ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/8879ec52..475bdac7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=37 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=36-37 Stats: 21 lines in 2 files changed: 9 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From wkemper at openjdk.org Tue Jan 13 23:33:13 2026 From: wkemper at openjdk.org (William Kemper) Date: Tue, 13 Jan 2026 23:33:13 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v29] In-Reply-To: References: Message-ID: On Sun, 11 Jan 2026 03:08:48 GMT, Kelvin Nilsen wrote: >> Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). >> >> This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. >> >> The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. >> >> ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) >> >> With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. >> >> ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) >> >> At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. >> >> ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) >> >> The command line for these comparisons follows: >> >> >> ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jd... > > Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 86 commits: > > - Merge remote-tracking branch 'jdk/master' into share-collector-reserves > - Move rebuild free set earlier in an abbreviated GC cycle > - Restore deleted assert statement > - Move special handling into ShenandoahYoungHeuristics::choose_collection_set_from_regiondata() > - fix another typo > - Fix typo > - Fix confusing comment > - Add comment > - Merge remote-tracking branch 'jdk/master' into share-collector-reserves > - Fix whitespace and comment > - ... and 76 more: https://git.openjdk.org/jdk/compare/659b53fe...27ece3e8 src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 71: > 69: ShenandoahAdaptiveHeuristics::~ShenandoahAdaptiveHeuristics() {} > 70: > 71: size_t ShenandoahAdaptiveHeuristics::choose_collection_set_from_regiondata(ShenandoahCollectionSet* cset, It would be nice if we didn't need to change this API for every heuristic just to support the mixed evacuation case. It is perhaps not in scope for an already huge PR, but I think we should move `ShenandoahGeneration::compute_evacuation_budgets` and `ShenandoahGeneration::adjust_evacuation_budgets` into `ShenandoahGenerationalHeuristic`. Logically, both these methods are involved in choosing the collection set and both are only used in the generational mode. I think it's fine to defer this refactoring to another PR. It's hard for me to accept that a change such as this would touch 41 files. It seems we do not have the right abstractions or encapsulations here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2688445439 From wkemper at openjdk.org Tue Jan 13 23:43:12 2026 From: wkemper at openjdk.org (William Kemper) Date: Tue, 13 Jan 2026 23:43:12 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v29] In-Reply-To: References: Message-ID: <9Hggsj2zW9VafwI8DdJbN_v0yTmbEpUyYE8QRFMNU5E=.71bc2233-2812-4482-94b1-9796a5c24594@github.com> On Sun, 11 Jan 2026 03:08:48 GMT, Kelvin Nilsen wrote: >> Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). >> >> This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. >> >> The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. >> >> ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) >> >> With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. >> >> ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) >> >> At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. >> >> ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) >> >> The command line for these comparisons follows: >> >> >> ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jd... > > Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 86 commits: > > - Merge remote-tracking branch 'jdk/master' into share-collector-reserves > - Move rebuild free set earlier in an abbreviated GC cycle > - Restore deleted assert statement > - Move special handling into ShenandoahYoungHeuristics::choose_collection_set_from_regiondata() > - fix another typo > - Fix typo > - Fix confusing comment > - Add comment > - Merge remote-tracking branch 'jdk/master' into share-collector-reserves > - Fix whitespace and comment > - ... and 76 more: https://git.openjdk.org/jdk/compare/659b53fe...27ece3e8 src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 688: > 686: void move_unaffiliated_regions_from_collector_to_old_collector(ssize_t regions); > 687: > 688: inline size_t global_unaffiliated_regions() { A nit, but all functions defined in the class declaration are implicitly `inline` and the keyword is unnecessary here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2688460138 From xpeng at openjdk.org Tue Jan 13 23:46:03 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 13 Jan 2026 23:46:03 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v39] In-Reply-To: References: Message-ID: <5eJEsoXB-qciYhfKa9zd-Qmty2wbphLo0-CDvasIZYk=.97281066-bb8f-4137-b9cc-f2a1890fe39a@github.com> > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: More eagerly to refresh alloc regions in attempt_allocation_slow since it is holding heap lock ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/475bdac7..6cc1834b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=38 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=37-38 Stats: 19 lines in 2 files changed: 10 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From kdnilsen at openjdk.org Tue Jan 13 23:52:21 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 13 Jan 2026 23:52:21 GMT Subject: Integrated: 8369048: GenShen: Defer ShenFreeSet::available() during rebuild In-Reply-To: <_PEoOc0oWb8Vzq16-Or_hykkL4NkIrwEFgLCgCRac5U=.2c23c497-acbe-48f9-a1dc-4eb4e8f25a8d@github.com> References: <_PEoOc0oWb8Vzq16-Or_hykkL4NkIrwEFgLCgCRac5U=.2c23c497-acbe-48f9-a1dc-4eb4e8f25a8d@github.com> Message-ID: On Thu, 2 Oct 2025 17:58:48 GMT, Kelvin Nilsen wrote: > This code introduces a new rebuild-freeset lock for purposes of coordinating the freeset rebuild activities and queries as to memory available for allocation in the mutator partition. > > This addresses a problem that results if available memory is probed while we are rebuilding the freeset. > > Rather than using the existing global heap lock to synchronize these activities, a new more narrowly scoped lock is introduced. This allows the available memory to be probed even when other activities hold the global heap lock for reasons other than rebuilding the freeset, such as when they are allocating memory. It is known that the global heap lock is heavily contended for certain workloads, and using this new lock avoids adding to contention for the global heap lock. This pull request has now been integrated. Changeset: 0d19d91b Author: Kelvin Nilsen URL: https://git.openjdk.org/jdk/commit/0d19d91b44e5232dbd99d34dcdf6500f892e3048 Stats: 113 lines in 7 files changed: 60 ins; 29 del; 24 mod 8369048: GenShen: Defer ShenFreeSet::available() during rebuild Reviewed-by: wkemper, ysr ------------- PR: https://git.openjdk.org/jdk/pull/27612 From kdnilsen at openjdk.org Wed Jan 14 00:14:44 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 14 Jan 2026 00:14:44 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v29] In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 23:31:03 GMT, William Kemper wrote: >> Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 86 commits: >> >> - Merge remote-tracking branch 'jdk/master' into share-collector-reserves >> - Move rebuild free set earlier in an abbreviated GC cycle >> - Restore deleted assert statement >> - Move special handling into ShenandoahYoungHeuristics::choose_collection_set_from_regiondata() >> - fix another typo >> - Fix typo >> - Fix confusing comment >> - Add comment >> - Merge remote-tracking branch 'jdk/master' into share-collector-reserves >> - Fix whitespace and comment >> - ... and 76 more: https://git.openjdk.org/jdk/compare/659b53fe...27ece3e8 > > src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 71: > >> 69: ShenandoahAdaptiveHeuristics::~ShenandoahAdaptiveHeuristics() {} >> 70: >> 71: size_t ShenandoahAdaptiveHeuristics::choose_collection_set_from_regiondata(ShenandoahCollectionSet* cset, > > It would be nice if we didn't need to change this API for every heuristic just to support the mixed evacuation case. It is perhaps not in scope for an already huge PR, but I think we should move `ShenandoahGeneration::compute_evacuation_budgets` and `ShenandoahGeneration::adjust_evacuation_budgets` into `ShenandoahGenerationalHeuristic`. Logically, both these methods are involved in choosing the collection set and both are only used in the generational mode. I think it's fine to defer this refactoring to another PR. It's hard for me to accept that a change such as this would touch 41 files. It seems we do not have the right abstractions or encapsulations here. > > I have made this refactoring on a branch based off https://github.com/openjdk/jdk/pull/27632, I will rebase it on this PR once it is integrated. Thanks for sorting through the bigger picture here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2688509896 From kdnilsen at openjdk.org Wed Jan 14 00:20:58 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 14 Jan 2026 00:20:58 GMT Subject: [jdk26] RFR: 8373714: Shenandoah: Register heuristic penalties following a degenerated GC Message-ID: <1omJK6dwl0H8dVgBnjjqsZS0KdT1ToM9ntCPh_tRNSs=.9d2f99bb-ed9f-48f7-98be-465b90782157@github.com> Hi all, This pull request contains a backport of commit [385c4f81](https://github.com/openjdk/jdk/commit/385c4f8180d30c0e41b848eb4b2c1c8788211422) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Kelvin Nilsen on 8 Jan 2026 and was reviewed by William Kemper. Thanks! ------------- Commit messages: - Backport 385c4f8180d30c0e41b848eb4b2c1c8788211422 Changes: https://git.openjdk.org/jdk/pull/29213/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29213&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373714 Stats: 12 lines in 7 files changed: 4 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/29213.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29213/head:pull/29213 PR: https://git.openjdk.org/jdk/pull/29213 From wkemper at openjdk.org Wed Jan 14 00:28:56 2026 From: wkemper at openjdk.org (William Kemper) Date: Wed, 14 Jan 2026 00:28:56 GMT Subject: [jdk26] RFR: 8373714: Shenandoah: Register heuristic penalties following a degenerated GC In-Reply-To: <1omJK6dwl0H8dVgBnjjqsZS0KdT1ToM9ntCPh_tRNSs=.9d2f99bb-ed9f-48f7-98be-465b90782157@github.com> References: <1omJK6dwl0H8dVgBnjjqsZS0KdT1ToM9ntCPh_tRNSs=.9d2f99bb-ed9f-48f7-98be-465b90782157@github.com> Message-ID: On Wed, 14 Jan 2026 00:14:46 GMT, Kelvin Nilsen wrote: > Hi all, > > This pull request contains a backport of commit [385c4f81](https://github.com/openjdk/jdk/commit/385c4f8180d30c0e41b848eb4b2c1c8788211422) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Kelvin Nilsen on 8 Jan 2026 and was reviewed by William Kemper. > > Thanks! Marked as reviewed by wkemper (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29213#pullrequestreview-3658400623 From kdnilsen at openjdk.org Wed Jan 14 00:47:19 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 14 Jan 2026 00:47:19 GMT Subject: [jdk26] Integrated: 8373714: Shenandoah: Register heuristic penalties following a degenerated GC In-Reply-To: <1omJK6dwl0H8dVgBnjjqsZS0KdT1ToM9ntCPh_tRNSs=.9d2f99bb-ed9f-48f7-98be-465b90782157@github.com> References: <1omJK6dwl0H8dVgBnjjqsZS0KdT1ToM9ntCPh_tRNSs=.9d2f99bb-ed9f-48f7-98be-465b90782157@github.com> Message-ID: On Wed, 14 Jan 2026 00:14:46 GMT, Kelvin Nilsen wrote: > Hi all, > > This pull request contains a backport of commit [385c4f81](https://github.com/openjdk/jdk/commit/385c4f8180d30c0e41b848eb4b2c1c8788211422) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Kelvin Nilsen on 8 Jan 2026 and was reviewed by William Kemper. > > Thanks! This pull request has now been integrated. Changeset: aae9f926 Author: Kelvin Nilsen URL: https://git.openjdk.org/jdk/commit/aae9f9269a3755684dd6ee292ff9e2f223b62b34 Stats: 12 lines in 7 files changed: 4 ins; 0 del; 8 mod 8373714: Shenandoah: Register heuristic penalties following a degenerated GC Reviewed-by: wkemper Backport-of: 385c4f8180d30c0e41b848eb4b2c1c8788211422 ------------- PR: https://git.openjdk.org/jdk/pull/29213 From xpeng at openjdk.org Wed Jan 14 01:49:41 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 14 Jan 2026 01:49:41 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v40] In-Reply-To: References: Message-ID: <5NYvQkLEavrwqeS9kK_ez2AeZghuM7VZjpWL3LGtWk0=.bc92fb79-f29d-44f0-8d66-a760ce8ed745@github.com> > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request incrementally with three additional commits since the last revision: - More accurate census noise - Code format - typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/6cc1834b..a26849bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=39 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=38-39 Stats: 18 lines in 3 files changed: 10 ins; 1 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From shade at openjdk.org Wed Jan 14 07:21:33 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 14 Jan 2026 07:21:33 GMT Subject: RFR: 8374984: Convert workerUtils to use Atomic In-Reply-To: <537jC3DpvLxPUOPm3Q6f1y6uplIYqd2KrVGUP2CRiJ0=.e7bbf6ef-692b-4533-87b2-3f14d28be771@github.com> References: <537jC3DpvLxPUOPm3Q6f1y6uplIYqd2KrVGUP2CRiJ0=.e7bbf6ef-692b-4533-87b2-3f14d28be771@github.com> Message-ID: On Tue, 13 Jan 2026 17:50:39 GMT, Kim Barrett wrote: > Please review this change to make SubTasksDone and SequentialSubTasksDone use > Atomic instead of AtomicAccess. > > Testing: mach5 tier1 Marked as reviewed by shade (Reviewer). src/hotspot/share/gc/shared/workerUtils.cpp line 120: > 118: bool SubTasksDone::try_claim_task(uint t) { > 119: assert(t < _n_tasks, "bad task id."); > 120: return !_tasks[t].load_relaxed() && !_tasks[t].compare_exchange(false, true); This is one of those cases where `compare_set` is somewhat cleaner: return !_tasks[t].load_relaxed() && _tasks[t].compare_set(false, true); ------------- PR Review: https://git.openjdk.org/jdk/pull/29201#pullrequestreview-3659208016 PR Review Comment: https://git.openjdk.org/jdk/pull/29201#discussion_r2689245483 From shade at openjdk.org Wed Jan 14 07:36:47 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 14 Jan 2026 07:36:47 GMT Subject: RFR: 8375209: Xcheck:jni should check when GC is about to deadlock in JNI critical section [v2] In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 19:44:23 GMT, Aleksey Shipilev wrote: >> Related to [JDK-8375188](https://bugs.openjdk.org/browse/JDK-8375188), and regardless what happens with the implementations, I think we really want to have `-Xcheck:jni` to tell us when we are about to deadlock. This is useful to diagnose the issue in the field. >> >> We used to have this capability in Serial/Parallel prior to [JDK-8192647](https://bugs.openjdk.org/browse/JDK-8192647), AFAICS: https://github.com/openjdk/jdk/commit/a9c9f7f0cbb2f2395fef08348bf867ffa8875d73#diff-d27fc793db1bf9314b322d494cd1c3269629fe27a605b4441de08d543d020fc3L341-L344 >> >> ZGC never had this check, AFAICS. I am not sure if I put the check in the right place. I believe it is in the right one, as we want to check that Java thread is not blocked waiting for GC driver to respond while being in JNI critical section itself. Current placement works well with the test. >> >> I opted to add the checking at the paths that are really affected by the issue, because it is really about what implementations are doing in this case. But we can also summarily check this in all `CollectedHeap::collect` overrides -- similar to ZGC case -- so that testing with `-Xcheck:jni` with Epsilon/G1/Shenandoah would also cover every other GC that might run into trouble. >> >> Additional testing: >> - [x] New test, 100x repetitions > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Terminology I agree the spec is lenient to JVM in this regard, this is a programming error to do extra things in JNI critical region. `Xcheck:jni` is the facility to help nail programming errors like this, hence the PR. I suppose it is borderline possible/acceptable to have native code return while being in JNI critical region, as long as you don't do anything else. But maybe I am short on imagination: sounds like JNI transition can actually block for GC _while_ the code in question in JNI critical region? IIRC, we never block on Java->native transition, we block on native->Java transition when safepoint is pending. So something like: native_getCritical(); // enters JNI critical region, leaves native code // GC is announced somewhere aroudn here, safepoint is armed native_doWhatever(); // in and out, discovers safepoint is armed on transition back to Java, blocks native_releaseCritical(); // exits JNI critical region, but we never get here If so, checking we are not holding JNI critical when doing native->Java transition would indeed cover more ground. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29206#issuecomment-3748210048 From xpeng at openjdk.org Wed Jan 14 07:38:20 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 14 Jan 2026 07:38:20 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v41] In-Reply-To: References: Message-ID: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 298 commits: - Merge branch 'master' into cas-alloc-1 - More accurate census noise - Code format - typo - More eagerly to refresh alloc regions in attempt_allocation_slow since it is holding heap lock - While eagerly refresh alloc regions, thread should not yield to safepoint because it is holding uninitialized new object - Fix assert when after eagerly refresh alloc regions after fast allocation - Remove the support of 0 for flags ShenandoahMutatorAllocRegions and ShenandoahCollectorAllocRegions - Merge branch 'openjdk:master' into cas-alloc-1 - Add virtual back for release_alloc_regions and reserve_alloc_regions to fix link error - ... and 288 more: https://git.openjdk.org/jdk/compare/624d7144...6de6789f ------------- Changes: https://git.openjdk.org/jdk/pull/26171/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=40 Stats: 1739 lines in 28 files changed: 1390 ins; 236 del; 113 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From aboldtch at openjdk.org Wed Jan 14 07:59:16 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 14 Jan 2026 07:59:16 GMT Subject: RFR: 8374676: ZGC: Convert zAbort to use Atomic Message-ID: <3WJ0EqDX5JbpbMwnGu_Q8NO9UA3yHHdIEQI7elKt5a0=.44251ee2-a4b5-4440-bcdc-b89b7bc3da75@github.com> Convert usages of AtomicAccess to Atomic in zAbort. Testing: * GHA * HotSpot GC tests with ZGC linux x64 and linux aarch64 ------------- Commit messages: - ZGC: Convert zAbort to use Atomic Changes: https://git.openjdk.org/jdk/pull/29217/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29217&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374676 Stats: 11 lines in 3 files changed: 1 ins; 3 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/29217.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29217/head:pull/29217 PR: https://git.openjdk.org/jdk/pull/29217 From aboldtch at openjdk.org Wed Jan 14 08:06:35 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 14 Jan 2026 08:06:35 GMT Subject: RFR: 8374677: ZGC: Convert zArray to use Atomic Message-ID: Convert usages of AtomicAccess to Atomic in zArray. Not sure about `NextType` name. Unclear how we want to name our using type aliases in the ZGC code. Testing: * GHA * HotSpot GC tests with ZGC linux x64 and linux aarch64 ------------- Commit messages: - ZGC: Convert zArray to use Atomic Changes: https://git.openjdk.org/jdk/pull/29218/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29218&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374677 Stats: 9 lines in 2 files changed: 2 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/29218.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29218/head:pull/29218 PR: https://git.openjdk.org/jdk/pull/29218 From aboldtch at openjdk.org Wed Jan 14 08:17:06 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 14 Jan 2026 08:17:06 GMT Subject: RFR: 8374678: ZGC: Convert zForwarding to use Atomic Message-ID: Convert usages of AtomicAccess to Atomic in zForwarding. `_ref_count` is unused by the SA. There is currently no implementation of Atomic in SA. Testing: * GHA * Tier 1-2 with ZGC linux x64 and linux aarch64 * Stress tests with ZGC linux x64 and linux aarch64 ------------- Commit messages: - ZGC: Convert zForwarding to use Atomic Changes: https://git.openjdk.org/jdk/pull/29220/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29220&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374678 Stats: 39 lines in 4 files changed: 1 ins; 2 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/29220.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29220/head:pull/29220 PR: https://git.openjdk.org/jdk/pull/29220 From stefank at openjdk.org Wed Jan 14 08:22:51 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 14 Jan 2026 08:22:51 GMT Subject: RFR: 8374676: ZGC: Convert zAbort to use Atomic In-Reply-To: <3WJ0EqDX5JbpbMwnGu_Q8NO9UA3yHHdIEQI7elKt5a0=.44251ee2-a4b5-4440-bcdc-b89b7bc3da75@github.com> References: <3WJ0EqDX5JbpbMwnGu_Q8NO9UA3yHHdIEQI7elKt5a0=.44251ee2-a4b5-4440-bcdc-b89b7bc3da75@github.com> Message-ID: On Wed, 14 Jan 2026 07:52:31 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zAbort. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29217#pullrequestreview-3659443530 From stefank at openjdk.org Wed Jan 14 08:23:21 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 14 Jan 2026 08:23:21 GMT Subject: RFR: 8374677: ZGC: Convert zArray to use Atomic In-Reply-To: References: Message-ID: <1i30D69INOpwKFSxJfpIfU9DYrZCBrPQNyjdTTZIhkc=.d106f18e-3eca-4f10-893b-778095ff773d@github.com> On Wed, 14 Jan 2026 07:57:52 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zArray. > > Not sure about `NextType` name. Unclear how we want to name our using type aliases in the ZGC code. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29218#pullrequestreview-3659449103 From stefank at openjdk.org Wed Jan 14 08:26:27 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 14 Jan 2026 08:26:27 GMT Subject: RFR: 8374678: ZGC: Convert zForwarding to use Atomic In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 08:07:12 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zForwarding. > > `_ref_count` is unused by the SA. There is currently no implementation of Atomic in SA. > > Testing: > * GHA > * Tier 1-2 with ZGC linux x64 and linux aarch64 > * Stress tests with ZGC linux x64 and linux aarch64 Marked as reviewed by stefank (Reviewer). src/hotspot/share/gc/z/zForwarding.cpp line 52: > 50: > 51: bool ZForwarding::claim() { > 52: return _claimed.compare_exchange(false, true) == false; Can this be the new compare_set? ------------- PR Review: https://git.openjdk.org/jdk/pull/29220#pullrequestreview-3659454614 PR Review Comment: https://git.openjdk.org/jdk/pull/29220#discussion_r2689439598 From stefank at openjdk.org Wed Jan 14 08:27:54 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 14 Jan 2026 08:27:54 GMT Subject: RFR: 8374984: Convert workerUtils to use Atomic In-Reply-To: <537jC3DpvLxPUOPm3Q6f1y6uplIYqd2KrVGUP2CRiJ0=.e7bbf6ef-692b-4533-87b2-3f14d28be771@github.com> References: <537jC3DpvLxPUOPm3Q6f1y6uplIYqd2KrVGUP2CRiJ0=.e7bbf6ef-692b-4533-87b2-3f14d28be771@github.com> Message-ID: On Tue, 13 Jan 2026 17:50:39 GMT, Kim Barrett wrote: > Please review this change to make SubTasksDone and SequentialSubTasksDone use > Atomic instead of AtomicAccess. > > Testing: mach5 tier1 Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29201#pullrequestreview-3659466935 From stefank at openjdk.org Wed Jan 14 08:27:56 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 14 Jan 2026 08:27:56 GMT Subject: RFR: 8374984: Convert workerUtils to use Atomic In-Reply-To: References: <537jC3DpvLxPUOPm3Q6f1y6uplIYqd2KrVGUP2CRiJ0=.e7bbf6ef-692b-4533-87b2-3f14d28be771@github.com> Message-ID: On Wed, 14 Jan 2026 07:16:34 GMT, Aleksey Shipilev wrote: >> Please review this change to make SubTasksDone and SequentialSubTasksDone use >> Atomic instead of AtomicAccess. >> >> Testing: mach5 tier1 > > src/hotspot/share/gc/shared/workerUtils.cpp line 120: > >> 118: bool SubTasksDone::try_claim_task(uint t) { >> 119: assert(t < _n_tasks, "bad task id."); >> 120: return !_tasks[t].load_relaxed() && !_tasks[t].compare_exchange(false, true); > > This is one of those cases where `compare_set` is somewhat cleaner: > > > return !_tasks[t].load_relaxed() && _tasks[t].compare_set(false, true); And maybe the same for `all_tasks_claimed_impl`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29201#discussion_r2689449288 From aboldtch at openjdk.org Wed Jan 14 08:36:20 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 14 Jan 2026 08:36:20 GMT Subject: RFR: 8374679: ZGC: Convert zForwardingAllocator to use Atomic Message-ID: Convert usages of AtomicAccess to Atomic in zForwardingAllocator. We currently use plain loads and stores which are synchronised and ordered with respect to the allocation by means of us starting worker threads which allocate and awaiting them to finish. This patch changes everything to have atomic semantics, but the loads and stores are still relaxed. Testing: * GHA * HotSpot GC tests with ZGC linux x64 and linux aarch64 ------------- Commit messages: - ZGC: Convert zForwardingAllocator to use Atomic Changes: https://git.openjdk.org/jdk/pull/29221/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29221&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374679 Stats: 12 lines in 3 files changed: 2 ins; 1 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/29221.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29221/head:pull/29221 PR: https://git.openjdk.org/jdk/pull/29221 From aboldtch at openjdk.org Wed Jan 14 08:39:22 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 14 Jan 2026 08:39:22 GMT Subject: RFR: 8374680: ZGC: Convert zGeneration to use Atomic Message-ID: Convert usages of AtomicAccess to Atomic in zGeneration. Testing: * GHA * HotSpot GC tests with ZGC linux x64 and linux aarch64 ------------- Commit messages: - ZGC: Convert zGeneration to use Atomic Changes: https://git.openjdk.org/jdk/pull/29222/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29222&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374680 Stats: 16 lines in 2 files changed: 1 ins; 1 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/29222.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29222/head:pull/29222 PR: https://git.openjdk.org/jdk/pull/29222 From aboldtch at openjdk.org Wed Jan 14 09:22:51 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 14 Jan 2026 09:22:51 GMT Subject: RFR: 8374681: ZGC: Convert zJNICritical to use Atomic Message-ID: Convert usages of AtomicAccess to Atomic in zJNICritical. Testing: * GHA * HotSpot GC tests with ZGC linux x64 and linux aarch64 ------------- Commit messages: - ZGC: Convert zJNICritical to use Atomic Changes: https://git.openjdk.org/jdk/pull/29223/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29223&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374681 Stats: 21 lines in 2 files changed: 1 ins; 1 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/29223.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29223/head:pull/29223 PR: https://git.openjdk.org/jdk/pull/29223 From aboldtch at openjdk.org Wed Jan 14 09:36:37 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 14 Jan 2026 09:36:37 GMT Subject: RFR: 8374678: ZGC: Convert zForwarding to use Atomic [v2] In-Reply-To: References: Message-ID: > Convert usages of AtomicAccess to Atomic in zForwarding. > > `_ref_count` is unused by the SA. There is currently no implementation of Atomic in SA. > > Testing: > * GHA > * Tier 1-2 with ZGC linux x64 and linux aarch64 > * Stress tests with ZGC linux x64 and linux aarch64 Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Use compare_set - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8374678 - ZGC: Convert zForwarding to use Atomic ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29220/files - new: https://git.openjdk.org/jdk/pull/29220/files/e981013a..e10b6142 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29220&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29220&range=00-01 Stats: 35662 lines in 505 files changed: 22535 ins; 8490 del; 4637 mod Patch: https://git.openjdk.org/jdk/pull/29220.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29220/head:pull/29220 PR: https://git.openjdk.org/jdk/pull/29220 From aboldtch at openjdk.org Wed Jan 14 09:36:38 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 14 Jan 2026 09:36:38 GMT Subject: RFR: 8374678: ZGC: Convert zForwarding to use Atomic [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 08:21:27 GMT, Stefan Karlsson wrote: >> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Use compare_set >> - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8374678 >> - ZGC: Convert zForwarding to use Atomic > > src/hotspot/share/gc/z/zForwarding.cpp line 52: > >> 50: >> 51: bool ZForwarding::claim() { >> 52: return _claimed.compare_exchange(false, true) == false; > > Can this be the new compare_set? Yeah, implemented this before that was available. I'll change the compare_exchange to compare_set where applicable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29220#discussion_r2689662752 From stefank at openjdk.org Wed Jan 14 10:04:25 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 14 Jan 2026 10:04:25 GMT Subject: RFR: 8374679: ZGC: Convert zForwardingAllocator to use Atomic In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 08:29:43 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zForwardingAllocator. > > We currently use plain loads and stores which are synchronised and ordered with respect to the allocation by means of us starting worker threads which allocate and awaiting them to finish. This patch changes everything to have atomic semantics, but the loads and stores are still relaxed. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29221#pullrequestreview-3659864495 From stefank at openjdk.org Wed Jan 14 10:04:56 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 14 Jan 2026 10:04:56 GMT Subject: RFR: 8374680: ZGC: Convert zGeneration to use Atomic In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 08:31:24 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zGeneration. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29222#pullrequestreview-3659869705 From aboldtch at openjdk.org Wed Jan 14 10:09:35 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 14 Jan 2026 10:09:35 GMT Subject: RFR: 8375209: Strengthen Xcheck:jni for JNI critical regions [v2] In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 19:44:23 GMT, Aleksey Shipilev wrote: >> [JDK-8375188](https://bugs.openjdk.org/browse/JDK-8375188) shows that misuse for JNI critical is able to deadlock the GC. Therefore, I think we really want to have `-Xcheck:jni` to preempt these cases and allow us to diagnose the issues in the field. >> >> G1 and Shenandoah are not exactly affected by this deadlock. ZGC never had this check, AFAICS, and is affected by the deadlock. We used to have some capability in Serial/Parallel prior to [JDK-8192647](https://bugs.openjdk.org/browse/JDK-8192647), AFAICS: https://github.com/openjdk/jdk/commit/a9c9f7f0cbb2f2395fef08348bf867ffa8875d73#diff-d27fc793db1bf9314b322d494cd1c3269629fe27a605b4441de08d543d020fc3L341-L344 >> >> Additional testing: >> - [x] New test, 100x repetitions >> - [ ] Linux x86_64 server fastdebug, `all` with `-XX:+UseParallelGC -Xcheck:jni` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Terminology Ideally `Xcheck:jni` should identify transitions which could respond to a GC, regardless of GC implementation. `native -> vm` transition will as far as I can tell poll for safepoints even if it is in a JNI critical region. This currently is an issue with `Release*Critical` which has a `native -> vm` transition before releasing the critical region. And the fact that we allow for nested critical regions. So the two consecutive calls to `Get*Critical` will have a `native -> vm` transition in the second call. I did some quick and dirty prototyping of a solution for this a while back https://github.com/openjdk/jdk/compare/master...xmas92:jdk:fix-jni-critical ------------- PR Comment: https://git.openjdk.org/jdk/pull/29206#issuecomment-3748757385 From stefank at openjdk.org Wed Jan 14 10:09:59 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 14 Jan 2026 10:09:59 GMT Subject: RFR: 8374681: ZGC: Convert zJNICritical to use Atomic In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 09:15:32 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zJNICritical. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29223#pullrequestreview-3659883775 From stefank at openjdk.org Wed Jan 14 10:13:15 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 14 Jan 2026 10:13:15 GMT Subject: RFR: 8374678: ZGC: Convert zForwarding to use Atomic [v2] In-Reply-To: References: Message-ID: <41t8Cq2T5TvR6KpCqvuaj55zrqJMsucm8e2iTByfDeM=.ed122c6f-b5ca-42c1-9d15-c94ea48f3079@github.com> On Wed, 14 Jan 2026 09:36:37 GMT, Axel Boldt-Christmas wrote: >> Convert usages of AtomicAccess to Atomic in zForwarding. >> >> `_ref_count` is unused by the SA. There is currently no implementation of Atomic in SA. >> >> Testing: >> * GHA >> * Tier 1-2 with ZGC linux x64 and linux aarch64 >> * Stress tests with ZGC linux x64 and linux aarch64 > > Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Use compare_set > - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8374678 > - ZGC: Convert zForwarding to use Atomic Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29220#pullrequestreview-3659903614 From shade at openjdk.org Wed Jan 14 10:22:35 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 14 Jan 2026 10:22:35 GMT Subject: RFR: 8375209: Strengthen Xcheck:jni for JNI critical regions [v3] In-Reply-To: References: Message-ID: > [JDK-8375188](https://bugs.openjdk.org/browse/JDK-8375188) shows that misuse for JNI critical is able to deadlock the GC. Therefore, I think we really want to have `-Xcheck:jni` to preempt these cases and allow us to diagnose the issues in the field. > > G1 and Shenandoah are not exactly affected by this deadlock. ZGC never had this check, AFAICS, and is affected by the deadlock. We used to have some capability in Serial/Parallel prior to [JDK-8192647](https://bugs.openjdk.org/browse/JDK-8192647), AFAICS: https://github.com/openjdk/jdk/commit/a9c9f7f0cbb2f2395fef08348bf867ffa8875d73#diff-d27fc793db1bf9314b322d494cd1c3269629fe27a605b4441de08d543d020fc3L341-L344 > > Additional testing: > - [x] New test, 100x repetitions > - [ ] Linux x86_64 server fastdebug, `all` with `-XX:+UseParallelGC -Xcheck:jni` Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Capture bad state at the end of JNI transition, check criticality on JNI function enters Move the check to native->Java transition ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29206/files - new: https://git.openjdk.org/jdk/pull/29206/files/4eeb4a04..765ef9d0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29206&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29206&range=01-02 Stats: 46 lines in 8 files changed: 26 ins; 9 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/29206.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29206/head:pull/29206 PR: https://git.openjdk.org/jdk/pull/29206 From shade at openjdk.org Wed Jan 14 10:22:37 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 14 Jan 2026 10:22:37 GMT Subject: RFR: 8375209: Strengthen Xcheck:jni for JNI critical regions [v2] In-Reply-To: References: Message-ID: <9J23vzOj_QalT_MgSo4KXdWZg2g4F82ojnGUndc6V-w=.767a9a88-3873-4dca-b1d8-90e9a9e9f2c7@github.com> On Tue, 13 Jan 2026 19:44:23 GMT, Aleksey Shipilev wrote: >> [JDK-8375188](https://bugs.openjdk.org/browse/JDK-8375188) shows that misuse for JNI critical is able to deadlock the GC. Therefore, I think we really want to have `-Xcheck:jni` to preempt these cases and allow us to diagnose the issues in the field. >> >> G1 and Shenandoah are not exactly affected by this deadlock. ZGC never had this check, AFAICS, and is affected by the deadlock. We used to have some capability in Serial/Parallel prior to [JDK-8192647](https://bugs.openjdk.org/browse/JDK-8192647), AFAICS: https://github.com/openjdk/jdk/commit/a9c9f7f0cbb2f2395fef08348bf867ffa8875d73#diff-d27fc793db1bf9314b322d494cd1c3269629fe27a605b4441de08d543d020fc3L341-L344 >> >> Additional testing: >> - [x] New test, 100x repetitions >> - [ ] Linux x86_64 server fastdebug, `all` with `-XX:+UseParallelGC -Xcheck:jni` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Terminology Yes, it looks to me that there are "normal" native->VM transitions here and there. We can be more precise and check for JNI Critical state at the end of the actual JNI transition in interpreted/compiled adapters and native->Java transitions on VM side. This unfortunately means some checks are in platform-specific code. See the new PR version for a stab at how that might look like. I'll run more tests to see if anything in JDK depends on current (broken) behavior. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29206#issuecomment-3748810279 From tschatzl at openjdk.org Wed Jan 14 11:16:15 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 14 Jan 2026 11:16:15 GMT Subject: RFR: 8375282: G1: Fix wrong indendation introduced by JDK-8374743 Message-ID: Hi all, please review this trivial fix to indendation introduced by JDK-8375282. Testing: local compilation, gha Thanks, Thomas ------------- Commit messages: - 8375282 Changes: https://git.openjdk.org/jdk/pull/29227/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29227&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375282 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29227.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29227/head:pull/29227 PR: https://git.openjdk.org/jdk/pull/29227 From iwalulya at openjdk.org Wed Jan 14 11:56:03 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 14 Jan 2026 11:56:03 GMT Subject: RFR: 8238686: G1 may waste lots of space or fail to uncommit when observing MinHeapFreeRatio during sizing after full gc [v2] In-Reply-To: <2CtP_aXZRdMpMM7MerGDY2WYvgJks7YMVHlQEYgItZI=.50a0dd11-5f58-4780-9a63-55dfe921c03d@github.com> References: <2CtP_aXZRdMpMM7MerGDY2WYvgJks7YMVHlQEYgItZI=.50a0dd11-5f58-4780-9a63-55dfe921c03d@github.com> Message-ID: <72aUcX7imX7IUt5wSDdYYpJOZoN2NDQqBHg04iy6bpc=.138a6c79-c59a-4d80-a00a-26cb5bdc7f3d@github.com> > Hi, > > Please review this change which modifies the defaults for the `MinHeapFreeRatio` and `MaxHeapFreeRatio` flags in G1 so that they do not affect heap sizing unless explicitly set by the user. > > Previously, these flags could trigger heap resizing at the end of Full GC, potentially overriding the G1 ergonomic heap sizing heuristics, which may be unexpected for the user. In particular, for workloads that frequently invoke `System.gc()`, the heap could shrink at the end of the Full GC and then expand aggressively during subsequent GCs (see image below). > > shrink_expand_flip_flop > > With this update, the default values for `MinHeapFreeRatio` and `MaxHeapFreeRatio` no longer affect heap resizing. These flags will only take effect when explicitly set by the user.. > > Additionally, pause times from user-triggered `System.gc()` invocations will be excluded from the data used to update heap sizing heuristics. Because these GCs are user-initiated and do not reflect actual GC pressure, including their pause times can skew GC Pause Time ratios used for heap sizing decisions. > > > Testing: Tier 1 and JavaPerf. Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into G1ResizeAfterFullGC_v1 - update - Merge branch 'master' into G1ResizeAfterFullGC_v1 - Ignore Defaults MinHeapFreeRatio-MaxHeapFreeRatio - init ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29137/files - new: https://git.openjdk.org/jdk/pull/29137/files/c4ec4b58..c60fed23 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29137&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29137&range=00-01 Stats: 34141 lines in 412 files changed: 21926 ins; 7900 del; 4315 mod Patch: https://git.openjdk.org/jdk/pull/29137.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29137/head:pull/29137 PR: https://git.openjdk.org/jdk/pull/29137 From iwalulya at openjdk.org Wed Jan 14 11:58:01 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 14 Jan 2026 11:58:01 GMT Subject: RFR: 8238686: G1 may waste lots of space or fail to uncommit when observing MinHeapFreeRatio during sizing after full gc [v3] In-Reply-To: <2CtP_aXZRdMpMM7MerGDY2WYvgJks7YMVHlQEYgItZI=.50a0dd11-5f58-4780-9a63-55dfe921c03d@github.com> References: <2CtP_aXZRdMpMM7MerGDY2WYvgJks7YMVHlQEYgItZI=.50a0dd11-5f58-4780-9a63-55dfe921c03d@github.com> Message-ID: > Hi, > > Please review this change which modifies the defaults for the `MinHeapFreeRatio` and `MaxHeapFreeRatio` flags in G1 so that they do not affect heap sizing unless explicitly set by the user. > > Previously, these flags could trigger heap resizing at the end of Full GC, potentially overriding the G1 ergonomic heap sizing heuristics, which may be unexpected for the user. In particular, for workloads that frequently invoke `System.gc()`, the heap could shrink at the end of the Full GC and then expand aggressively during subsequent GCs (see image below). > > shrink_expand_flip_flop > > With this update, the default values for `MinHeapFreeRatio` and `MaxHeapFreeRatio` no longer affect heap resizing. These flags will only take effect when explicitly set by the user.. > > Additionally, pause times from user-triggered `System.gc()` invocations will be excluded from the data used to update heap sizing heuristics. Because these GCs are user-initiated and do not reflect actual GC pressure, including their pause times can skew GC Pause Time ratios used for heap sizing decisions. > > > Testing: Tier 1 and JavaPerf. Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: Factor out change in flag defaults ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29137/files - new: https://git.openjdk.org/jdk/pull/29137/files/c60fed23..15f46662 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29137&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29137&range=01-02 Stats: 35 lines in 3 files changed: 7 ins; 6 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/29137.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29137/head:pull/29137 PR: https://git.openjdk.org/jdk/pull/29137 From iwalulya at openjdk.org Wed Jan 14 12:01:54 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 14 Jan 2026 12:01:54 GMT Subject: RFR: 8238686: G1 may waste lots of space or fail to uncommit when observing MinHeapFreeRatio during sizing after full gc [v3] In-Reply-To: References: <2CtP_aXZRdMpMM7MerGDY2WYvgJks7YMVHlQEYgItZI=.50a0dd11-5f58-4780-9a63-55dfe921c03d@github.com> Message-ID: On Wed, 14 Jan 2026 11:58:01 GMT, Ivan Walulya wrote: >> Hi, >> >> Please review this change which modifies the defaults for the `MinHeapFreeRatio` and `MaxHeapFreeRatio` flags in G1 so that they do not affect heap sizing unless explicitly set by the user. >> >> Previously, these flags could trigger heap resizing at the end of Full GC, potentially overriding the G1 ergonomic heap sizing heuristics, which may be unexpected for the user. In particular, for workloads that frequently invoke `System.gc()`, the heap could shrink at the end of the Full GC and then expand aggressively during subsequent GCs (see image below). >> >> shrink_expand_flip_flop >> >> With this update, the default values for `MinHeapFreeRatio` and `MaxHeapFreeRatio` no longer affect heap resizing. These flags will only take effect when explicitly set by the user.. >> >> ~~Additionally, pause times from user-triggered `System.gc()` invocations will be excluded from the data used to update heap sizing heuristics. Because these GCs are user-initiated and do not reflect actual GC pressure, including their pause times can skew GC Pause Time ratios used for heap sizing decisions.~~ >> >> >> Testing: Tier 1 and JavaPerf. > > Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: > > Factor out change in flag defaults Split the changes because the change in flag defaults needs to have a compatibility review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29137#issuecomment-3749231641 From tschatzl at openjdk.org Wed Jan 14 12:16:01 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 14 Jan 2026 12:16:01 GMT Subject: RFR: 8238686: G1 may waste lots of space or fail to uncommit when observing MinHeapFreeRatio during sizing after full gc [v3] In-Reply-To: References: <2CtP_aXZRdMpMM7MerGDY2WYvgJks7YMVHlQEYgItZI=.50a0dd11-5f58-4780-9a63-55dfe921c03d@github.com> Message-ID: On Wed, 14 Jan 2026 11:58:01 GMT, Ivan Walulya wrote: >> Hi, >> >> Please review this change which modifies the defaults for the `MinHeapFreeRatio` and `MaxHeapFreeRatio` flags in G1 so that they do not affect heap sizing unless explicitly set by the user. >> >> Previously, these flags could trigger heap resizing at the end of Full GC, potentially overriding the G1 ergonomic heap sizing heuristics, which may be unexpected for the user. In particular, for workloads that frequently invoke `System.gc()`, the heap could shrink at the end of the Full GC and then expand aggressively during subsequent GCs (see image below). >> >> shrink_expand_flip_flop >> >> With this update, the default values for `MinHeapFreeRatio` and `MaxHeapFreeRatio` no longer affect heap resizing. These flags will only take effect when explicitly set by the user.. >> >> ~~Additionally, pause times from user-triggered `System.gc()` invocations will be excluded from the data used to update heap sizing heuristics. Because these GCs are user-initiated and do not reflect actual GC pressure, including their pause times can skew GC Pause Time ratios used for heap sizing decisions.~~ >> >> >> Testing: Tier 1 and JavaPerf. > > Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: > > Factor out change in flag defaults Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29137#pullrequestreview-3660442964 From jvernee at openjdk.org Wed Jan 14 14:08:08 2026 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 14 Jan 2026 14:08:08 GMT Subject: RFR: 8375209: Strengthen Xcheck:jni for JNI critical regions [v3] In-Reply-To: References: Message-ID: <3MXcawHFhCVI0hAqC2d4w83fiHfTJkhzkGHTKdD6P_Y=.ad9be4d9-b639-455a-bac4-1e213c890bce@github.com> On Wed, 14 Jan 2026 10:22:35 GMT, Aleksey Shipilev wrote: >> [JDK-8375188](https://bugs.openjdk.org/browse/JDK-8375188) shows that misuse for JNI critical is able to deadlock the GC. Therefore, I think we really want to have `-Xcheck:jni` to preempt these cases and allow us to diagnose the issues in the field. >> >> G1 and Shenandoah are not exactly affected by this deadlock. ZGC never had this check, AFAICS, and is affected by the deadlock. We used to have some capability in Serial/Parallel prior to [JDK-8192647](https://bugs.openjdk.org/browse/JDK-8192647), AFAICS: https://github.com/openjdk/jdk/commit/a9c9f7f0cbb2f2395fef08348bf867ffa8875d73#diff-d27fc793db1bf9314b322d494cd1c3269629fe27a605b4441de08d543d020fc3L341-L344 >> >> Additional testing: >> - [x] New test, 100x repetitions >> - [ ] Linux x86_64 server fastdebug, `all` with `-XX:+UseParallelGC -Xcheck:jni` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Capture bad state at the end of JNI transition, check criticality on JNI function enters > Move the check to native->Java transition Thanks for taking a stab at this. Yes, unfortunately not everything uses the nice helper functions to do thread state transitions. Particularly, Java -> native calls do this in platform specific assembly code. One place you've missed is in `TemplateInterpreterGenerator::generate_native_entry`. The code is similar to the compiled native wrapper, with an `if (CheckJNICalls) { ... }`, so I think you can just add the same change there. There are also Java -> native -> Java transitions in the downcall stub we generate for FFM calls, but we don't expect native code at the other end of a downcall to interact with JNI, so it's not really important to check there (we also don't check for pending exceptions). AFAIK we need to do a safepoint poll any time we go from a safe state (native or blocked) to an unsafe sate (java or vm), since a safepoint might be in progress during the transition. The fact that `Get*Critical` and `Release*Critical` transition to the vm state seems like an issue to me, since that transition also includes a safepoint poll. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29206#issuecomment-3749714795 From jvernee at openjdk.org Wed Jan 14 14:15:25 2026 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 14 Jan 2026 14:15:25 GMT Subject: RFR: 8375209: Strengthen Xcheck:jni for JNI critical regions [v3] In-Reply-To: <3MXcawHFhCVI0hAqC2d4w83fiHfTJkhzkGHTKdD6P_Y=.ad9be4d9-b639-455a-bac4-1e213c890bce@github.com> References: <3MXcawHFhCVI0hAqC2d4w83fiHfTJkhzkGHTKdD6P_Y=.ad9be4d9-b639-455a-bac4-1e213c890bce@github.com> Message-ID: On Wed, 14 Jan 2026 14:04:36 GMT, Jorn Vernee wrote: > One place you've missed is in `TemplateInterpreterGenerator::generate_native_entry`. The code is similar to the compiled native wrapper, with an `if (CheckJNICalls) { ... }`, so I think you can just add the same change there. Sorry, I'm blind, you already did that ------------- PR Comment: https://git.openjdk.org/jdk/pull/29206#issuecomment-3749747588 From jnorlinder at openjdk.org Wed Jan 14 14:35:51 2026 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Wed, 14 Jan 2026 14:35:51 GMT Subject: RFR: 8375297: ZGC: Remove obsolete O_CLOEXEC definition Message-ID: With [JDK-8375006](https://bugs.openjdk.org/browse/JDK-8375006) integrated we are no longer supporting building with on a system with kernel headers < 2.6.23 and glibc < 2.7. ------------- Commit messages: - Remove explicit define for O_CLOEXEC Changes: https://git.openjdk.org/jdk/pull/29230/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29230&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375297 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29230.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29230/head:pull/29230 PR: https://git.openjdk.org/jdk/pull/29230 From tschatzl at openjdk.org Wed Jan 14 14:35:51 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 14 Jan 2026 14:35:51 GMT Subject: RFR: 8375297: ZGC: Remove obsolete O_CLOEXEC definition In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 12:14:06 GMT, Jonas Norlinder wrote: > With [JDK-8375006](https://bugs.openjdk.org/browse/JDK-8375006) integrated we are no longer supporting building with on a system with kernel headers < 2.6.23 and glibc < 2.7. Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29230#pullrequestreview-3660732321 From eosterlund at openjdk.org Wed Jan 14 15:11:35 2026 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 14 Jan 2026 15:11:35 GMT Subject: RFR: 8375297: ZGC: Remove obsolete O_CLOEXEC definition In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 12:14:06 GMT, Jonas Norlinder wrote: > With [JDK-8375006](https://bugs.openjdk.org/browse/JDK-8375006) integrated we are no longer supporting building with on a system with kernel headers < 2.6.23 and glibc < 2.7. Marked as reviewed by eosterlund (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29230#pullrequestreview-3661218087 From duke at openjdk.org Wed Jan 14 15:11:36 2026 From: duke at openjdk.org (duke) Date: Wed, 14 Jan 2026 15:11:36 GMT Subject: RFR: 8375297: ZGC: Remove obsolete O_CLOEXEC definition In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 12:14:06 GMT, Jonas Norlinder wrote: > With [JDK-8375006](https://bugs.openjdk.org/browse/JDK-8375006) integrated we are no longer supporting building with on a system with kernel headers < 2.6.23 and glibc < 2.7. @JonasNorlinder Your change (at version cab7cc476fe558c086ae5e16b0ed9616b52fc801) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29230#issuecomment-3750003824 From eosterlund at openjdk.org Wed Jan 14 16:03:19 2026 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 14 Jan 2026 16:03:19 GMT Subject: RFR: 8374678: ZGC: Convert zForwarding to use Atomic [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 09:36:37 GMT, Axel Boldt-Christmas wrote: >> Convert usages of AtomicAccess to Atomic in zForwarding. >> >> `_ref_count` is unused by the SA. There is currently no implementation of Atomic in SA. >> >> Testing: >> * GHA >> * Tier 1-2 with ZGC linux x64 and linux aarch64 >> * Stress tests with ZGC linux x64 and linux aarch64 > > Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Use compare_set > - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8374678 > - ZGC: Convert zForwarding to use Atomic Marked as reviewed by eosterlund (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29220#pullrequestreview-3661511714 From jnorlinder at openjdk.org Wed Jan 14 16:58:22 2026 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Wed, 14 Jan 2026 16:58:22 GMT Subject: Integrated: 8375297: ZGC: Remove obsolete O_CLOEXEC definition In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 12:14:06 GMT, Jonas Norlinder wrote: > With [JDK-8375006](https://bugs.openjdk.org/browse/JDK-8375006) integrated we are no longer supporting building with on a system with kernel headers < 2.6.23 and glibc < 2.7. This pull request has now been integrated. Changeset: 56545328 Author: Jonas Norlinder Committer: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/56545328f849c3ebf062e3ff601224084fa3b46e Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod 8375297: ZGC: Remove obsolete O_CLOEXEC definition Reviewed-by: tschatzl, eosterlund ------------- PR: https://git.openjdk.org/jdk/pull/29230 From kbarrett at openjdk.org Wed Jan 14 17:15:27 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 14 Jan 2026 17:15:27 GMT Subject: RFR: 8375282: G1: Fix wrong indendation introduced by JDK-8374743 In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 11:09:20 GMT, Thomas Schatzl wrote: > Hi all, > > please review this trivial fix to indendation introduced by JDK-8375282. > > Testing: local compilation, gha > > Thanks, > Thomas Good and trivial. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29227#pullrequestreview-3661826340 From kdnilsen at openjdk.org Wed Jan 14 20:25:47 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 14 Jan 2026 20:25:47 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v30] In-Reply-To: References: Message-ID: > Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). > > This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. > > The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. > > ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) > > With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. > > ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) > > At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. > > ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) > > The command line for these comparisons follows: > > > ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jdk/bin/java \ > -XX:+Unlock... Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Use PROPERFMTARGS ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25357/files - new: https://git.openjdk.org/jdk/pull/25357/files/27ece3e8..b8d9cca9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=29 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=28-29 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25357/head:pull/25357 PR: https://git.openjdk.org/jdk/pull/25357 From kdnilsen at openjdk.org Wed Jan 14 21:59:13 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 14 Jan 2026 21:59:13 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v6] In-Reply-To: References: Message-ID: > After studying large numbers of GC logs with degenerated cycles that have resulted from "late" triggers, we propose the following general improvements: > > 1. Track trends in GC times rather than always using the average GC time plus standard deviation. In many situations, GC times trend upward due to, for example, increasing amounts of live data that must be marked as a workload builds up its working set of memory. > 2. Sample allocation rates more frequently than once every 100 ms. > 3. Track trends in allocation rates. In some situations, the allocation rate trends upwards due to, for example, the start of a new phase of execution or a spike in client workload. > 4. When we detect acceleration of allocation rate, predict consumption of memory based on accelerated allocation rates rather than assuming constant allocation rate. Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 68 commits: - move some post_initialize() work into subclass ShenandoahGenerationalHeuristics - Merge remote-tracking branch 'jdk/master' into accelerated-triggers - Merge remote-tracking branch 'jdk/master' into accelerated-triggers - Fix comment - Use PROPERFMT macros - Simplify code flow: reviewer suggestion - Merge remote-tracking branch 'jdk/master' into accelerated-triggers - Remove develop/debug instrumentation - add another override - Change type of command-line args - ... and 58 more: https://git.openjdk.org/jdk/compare/49f72658...ea38ec15 ------------- Changes: https://git.openjdk.org/jdk/pull/29039/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=05 Stats: 1034 lines in 27 files changed: 927 ins; 35 del; 72 mod Patch: https://git.openjdk.org/jdk/pull/29039.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29039/head:pull/29039 PR: https://git.openjdk.org/jdk/pull/29039 From kdnilsen at openjdk.org Wed Jan 14 22:36:53 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 14 Jan 2026 22:36:53 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v4] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 21:27:57 GMT, William Kemper wrote: >> Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits: >> >> - Fix comment >> - Use PROPERFMT macros >> - Simplify code flow: reviewer suggestion >> - Merge remote-tracking branch 'jdk/master' into accelerated-triggers >> - Remove develop/debug instrumentation >> - add another override >> - Change type of command-line args >> - fix white space >> - Add override to virtual methods >> - Fix race between allocation reporting and querying >> - ... and 55 more: https://git.openjdk.org/jdk/compare/dd20e915...7f3a6d1e > > src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 134: > >> 132: if (_is_generational) { >> 133: _regulator_thread = ShenandoahGenerationalHeap::heap()->regulator_thread(); >> 134: size_t young_available = ShenandoahGenerationalHeap::heap()->young_generation()->max_capacity() - > > Consider pushing this down into `ShenandoahGenerationalHeuristics` Most recent commit has this change. It's a bit clumsy. Feel free to guide further. (I'm not real happy with making direct call to super of super class from ShenandoahGenerationalHeuristics. What do you think?) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29039#discussion_r2692303227 From kbarrett at openjdk.org Wed Jan 14 22:45:19 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 14 Jan 2026 22:45:19 GMT Subject: RFR: 8374984: Convert workerUtils to use Atomic [v2] In-Reply-To: <537jC3DpvLxPUOPm3Q6f1y6uplIYqd2KrVGUP2CRiJ0=.e7bbf6ef-692b-4533-87b2-3f14d28be771@github.com> References: <537jC3DpvLxPUOPm3Q6f1y6uplIYqd2KrVGUP2CRiJ0=.e7bbf6ef-692b-4533-87b2-3f14d28be771@github.com> Message-ID: > Please review this change to make SubTasksDone and SequentialSubTasksDone use > Atomic instead of AtomicAccess. > > Testing: mach5 tier1 Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into worker-utils-atomic - use compare_set - worker utils ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29201/files - new: https://git.openjdk.org/jdk/pull/29201/files/741013a1..83bbe806 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29201&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29201&range=00-01 Stats: 17728 lines in 184 files changed: 9716 ins; 4258 del; 3754 mod Patch: https://git.openjdk.org/jdk/pull/29201.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29201/head:pull/29201 PR: https://git.openjdk.org/jdk/pull/29201 From kbarrett at openjdk.org Wed Jan 14 22:45:21 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 14 Jan 2026 22:45:21 GMT Subject: RFR: 8374984: Convert workerUtils to use Atomic [v2] In-Reply-To: References: <537jC3DpvLxPUOPm3Q6f1y6uplIYqd2KrVGUP2CRiJ0=.e7bbf6ef-692b-4533-87b2-3f14d28be771@github.com> Message-ID: On Wed, 14 Jan 2026 08:25:02 GMT, Stefan Karlsson wrote: >> src/hotspot/share/gc/shared/workerUtils.cpp line 120: >> >>> 118: bool SubTasksDone::try_claim_task(uint t) { >>> 119: assert(t < _n_tasks, "bad task id."); >>> 120: return !_tasks[t].load_relaxed() && !_tasks[t].compare_exchange(false, true); >> >> This is one of those cases where `compare_set` is somewhat cleaner: >> >> >> return !_tasks[t].load_relaxed() && _tasks[t].compare_set(false, true); > > And maybe the same for `all_tasks_claimed_impl`? Agreed for both cases. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29201#discussion_r2692320650 From kdnilsen at openjdk.org Wed Jan 14 22:48:09 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 14 Jan 2026 22:48:09 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v4] In-Reply-To: References: Message-ID: <_Z1mAtwznDVN-HPcTTr_kN0snC4i2Yrxw-e5bPdiCno=.351f037b-10c3-4391-876e-31b2db2900a6@github.com> On Thu, 8 Jan 2026 22:06:01 GMT, William Kemper wrote: >> Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits: >> >> - Fix comment >> - Use PROPERFMT macros >> - Simplify code flow: reviewer suggestion >> - Merge remote-tracking branch 'jdk/master' into accelerated-triggers >> - Remove develop/debug instrumentation >> - add another override >> - Change type of command-line args >> - fix white space >> - Add override to virtual methods >> - Fix race between allocation reporting and querying >> - ... and 55 more: https://git.openjdk.org/jdk/compare/dd20e915...7f3a6d1e > > src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 192: > >> 190: >> 191: void ShenandoahAdaptiveHeuristics::resume_idle_span() { >> 192: size_t mutator_available = _free_set->capacity() - _free_set->used(); > > This is a little confusing to me. Isn't `available` defined as `capacity - used`? Why do we not use `available` here? Agree. Making this change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29039#discussion_r2692329526 From kdnilsen at openjdk.org Thu Jan 15 00:05:55 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 15 Jan 2026 00:05:55 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v4] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 22:23:31 GMT, William Kemper wrote: >> Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits: >> >> - Fix comment >> - Use PROPERFMT macros >> - Simplify code flow: reviewer suggestion >> - Merge remote-tracking branch 'jdk/master' into accelerated-triggers >> - Remove develop/debug instrumentation >> - add another override >> - Change type of command-line args >> - fix white space >> - Add override to virtual methods >> - Fix race between allocation reporting and querying >> - ... and 55 more: https://git.openjdk.org/jdk/compare/dd20e915...7f3a6d1e > > src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 715: > >> 713: >> 714: if (ShenandoahHeuristics::should_start_gc()) { >> 715: // ShenandoahHeuristics::should_start_gc() has accepted trigger, or declined it. > > return ShenandoahHeuristics::should_start_gc(); Thanks. Changing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29039#discussion_r2692488816 From aboldtch at openjdk.org Thu Jan 15 06:06:24 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 15 Jan 2026 06:06:24 GMT Subject: RFR: 8374681: ZGC: Convert zJNICritical to use Atomic [v2] In-Reply-To: References: Message-ID: > Convert usages of AtomicAccess to Atomic in zJNICritical. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Use compare_set - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8374681 - ZGC: Convert zJNICritical to use Atomic ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29223/files - new: https://git.openjdk.org/jdk/pull/29223/files/d50ca0dd..18166661 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29223&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29223&range=00-01 Stats: 37961 lines in 637 files changed: 23743 ins; 8857 del; 5361 mod Patch: https://git.openjdk.org/jdk/pull/29223.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29223/head:pull/29223 PR: https://git.openjdk.org/jdk/pull/29223 From aboldtch at openjdk.org Thu Jan 15 06:14:24 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 15 Jan 2026 06:14:24 GMT Subject: RFR: 8374683: ZGC: Convert zLock to use Atomic Message-ID: Convert usages of AtomicAccess to Atomic in zLock. Testing: * GHA * HotSpot GC tests with ZGC linux x64 and linux aarch64 ------------- Commit messages: - ZGC: Convert zLock to use Atomic Changes: https://git.openjdk.org/jdk/pull/29244/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29244&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374683 Stats: 11 lines in 2 files changed: 1 ins; 1 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/29244.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29244/head:pull/29244 PR: https://git.openjdk.org/jdk/pull/29244 From aboldtch at openjdk.org Thu Jan 15 06:14:34 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 15 Jan 2026 06:14:34 GMT Subject: RFR: 8374682: ZGC: Convert zLiveMap to use Atomic Message-ID: Convert usages of AtomicAccess to Atomic in zLiveMap. Testing: * GHA * HotSpot GC tests with ZGC linux x64 and linux aarch64 ------------- Commit messages: - Use compare_set - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8374682 - ZGC: Convert zLiveMap to use Atomic Changes: https://git.openjdk.org/jdk/pull/29243/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29243&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374682 Stats: 22 lines in 3 files changed: 1 ins; 2 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/29243.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29243/head:pull/29243 PR: https://git.openjdk.org/jdk/pull/29243 From aboldtch at openjdk.org Thu Jan 15 06:16:48 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 15 Jan 2026 06:16:48 GMT Subject: RFR: 8374684: ZGC: Convert zMark to use Atomic Message-ID: <2-6Q_cMDlDBi4NKK_IN_QmIcSuUZNsN8vGEqX8z1fkY=.c968e317-5ea1-4338-9003-ef1df3c89a3c@github.com> Convert usages of AtomicAccess to Atomic in zMark. Testing: * GHA * HotSpot GC tests with ZGC linux x64 and linux aarch64 ------------- Commit messages: - ZGC: Convert zMark to use Atomic Changes: https://git.openjdk.org/jdk/pull/29245/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29245&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374684 Stats: 13 lines in 2 files changed: 2 ins; 1 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/29245.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29245/head:pull/29245 PR: https://git.openjdk.org/jdk/pull/29245 From aboldtch at openjdk.org Thu Jan 15 06:54:24 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 15 Jan 2026 06:54:24 GMT Subject: RFR: 8374686: ZGC: Convert zMarkTerminate to use Atomic Message-ID: Convert usages of AtomicAccess to Atomic in zMarkTerminate. There are a few things that potentially should be changed here. First the `_nworkers` variable was accessed through the AtomicAccess API in a handful of places. In this patch I changed it to always be an Atomic. However, this variable is only ever read concurrently. It only gets modified before we schedule a task on the workers (either for a new task, or after all workers have stopped working because we are resizing the work gang size). So potentially this could just be changed to a uint with plain loads and stores. The other variables have mutual exclusion when updated, but are read concurrently without synchronisation. In this patch I changed the volatile load + sub/add + atomic relaxed store [+ volatile load] into a simple atomic relaxed add/sub [and fetch]. The main reason being that I thought the code became less verbose, easier to read and understand. Testing: * GHA * HotSpot GC tests with ZGC linux x64 and linux aarch64 ------------- Commit messages: - ZGC: Convert zMarkTerminate to use Atomic Changes: https://git.openjdk.org/jdk/pull/29246/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29246&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374686 Stats: 29 lines in 2 files changed: 1 ins; 3 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/29246.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29246/head:pull/29246 PR: https://git.openjdk.org/jdk/pull/29246 From shade at openjdk.org Thu Jan 15 07:30:00 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 15 Jan 2026 07:30:00 GMT Subject: RFR: 8374984: Convert workerUtils to use Atomic [v2] In-Reply-To: References: <537jC3DpvLxPUOPm3Q6f1y6uplIYqd2KrVGUP2CRiJ0=.e7bbf6ef-692b-4533-87b2-3f14d28be771@github.com> Message-ID: On Wed, 14 Jan 2026 22:45:19 GMT, Kim Barrett wrote: >> Please review this change to make SubTasksDone and SequentialSubTasksDone use >> Atomic instead of AtomicAccess. >> >> Testing: mach5 tier1 > > Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into worker-utils-atomic > - use compare_set > - worker utils Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29201#pullrequestreview-3664250781 From stefank at openjdk.org Thu Jan 15 09:04:56 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 15 Jan 2026 09:04:56 GMT Subject: RFR: 8374683: ZGC: Convert zLock to use Atomic In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 06:08:04 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zLock. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29244#pullrequestreview-3664546811 From stefank at openjdk.org Thu Jan 15 09:06:56 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 15 Jan 2026 09:06:56 GMT Subject: RFR: 8374684: ZGC: Convert zMark to use Atomic In-Reply-To: <2-6Q_cMDlDBi4NKK_IN_QmIcSuUZNsN8vGEqX8z1fkY=.c968e317-5ea1-4338-9003-ef1df3c89a3c@github.com> References: <2-6Q_cMDlDBi4NKK_IN_QmIcSuUZNsN8vGEqX8z1fkY=.c968e317-5ea1-4338-9003-ef1df3c89a3c@github.com> Message-ID: <-WBsJfWouCRoKy963a8ibFfYEr1s6dC4pVb979NU00w=.a1377416-87c7-4652-b21b-0d4c98bc6e1b@github.com> On Thu, 15 Jan 2026 06:09:25 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zMark. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29245#pullrequestreview-3664556257 From stefank at openjdk.org Thu Jan 15 09:06:59 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 15 Jan 2026 09:06:59 GMT Subject: RFR: 8374682: ZGC: Convert zLiveMap to use Atomic In-Reply-To: References: Message-ID: <_D7ZESaU1qNvJo-nuQvaZ9J6es-7N4hC5Genk0xkRaM=.a5ae5f2d-bc95-47cd-bdc4-afbcc634cdb9@github.com> On Thu, 15 Jan 2026 06:06:10 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zLiveMap. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29243#pullrequestreview-3664553490 From stefank at openjdk.org Thu Jan 15 09:18:56 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 15 Jan 2026 09:18:56 GMT Subject: RFR: 8374984: Convert workerUtils to use Atomic [v2] In-Reply-To: References: <537jC3DpvLxPUOPm3Q6f1y6uplIYqd2KrVGUP2CRiJ0=.e7bbf6ef-692b-4533-87b2-3f14d28be771@github.com> Message-ID: On Wed, 14 Jan 2026 22:45:19 GMT, Kim Barrett wrote: >> Please review this change to make SubTasksDone and SequentialSubTasksDone use >> Atomic instead of AtomicAccess. >> >> Testing: mach5 tier1 > > Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into worker-utils-atomic > - use compare_set > - worker utils Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29201#pullrequestreview-3664620449 From aboldtch at openjdk.org Thu Jan 15 09:35:24 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 15 Jan 2026 09:35:24 GMT Subject: RFR: 8374686: ZGC: Convert zMarkTerminate to use Atomic [v2] In-Reply-To: References: Message-ID: > Convert usages of AtomicAccess to Atomic in zMarkTerminate. > > There are a few things that potentially should be changed here. > > First the `_nworkers` variable was accessed through the AtomicAccess API in a handful of places. In this patch I changed it to always be an Atomic. However, this variable is only ever read concurrently. It only gets modified before we schedule a task on the workers (either for a new task, or after all workers have stopped working because we are resizing the work gang size). So potentially this could just be changed to a uint with plain loads and stores. > > The other variables have mutual exclusion when updated, but are read concurrently without synchronisation. In this patch I changed the volatile load + sub/add + atomic relaxed store [+ volatile load] into a simple atomic relaxed add/sub [and fetch]. The main reason being that I thought the code became less verbose, easier to read and understand. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Remove unnecessary atomic on _nworkers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29246/files - new: https://git.openjdk.org/jdk/pull/29246/files/fb7a9e69..2a87be98 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29246&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29246&range=00-01 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/29246.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29246/head:pull/29246 PR: https://git.openjdk.org/jdk/pull/29246 From iwalulya at openjdk.org Thu Jan 15 10:17:51 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 15 Jan 2026 10:17:51 GMT Subject: RFR: 8340470: G1: Adopt PartialArrayState to consolidate marking stack in Full GC [v4] In-Reply-To: References: Message-ID: > Hi, > > Please review this change adopting `PartialArrayState` introduced by [JDK-8337709](https://bugs.openjdk.org/browse/JDK-8337709) to consolidate marking queue sets (oop queue set and objArray queue set) into single queue set in G1 Full GC. > > Testing: Tier 1-5 Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - cleanup after merge - Merge remote-tracking branch 'upstream/master' into ArrayChuncking - Thomas Review - missing include - cleanup - Merge remote-tracking branch 'upstream/master' into ArrayChuncking - partial array manager ------------- Changes: https://git.openjdk.org/jdk/pull/29114/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29114&range=03 Stats: 171 lines in 6 files changed: 48 ins; 70 del; 53 mod Patch: https://git.openjdk.org/jdk/pull/29114.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29114/head:pull/29114 PR: https://git.openjdk.org/jdk/pull/29114 From tschatzl at openjdk.org Thu Jan 15 11:17:59 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 15 Jan 2026 11:17:59 GMT Subject: RFR: 8340470: G1: Adopt PartialArrayState to consolidate marking stack in Full GC [v4] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 10:17:51 GMT, Ivan Walulya wrote: >> Hi, >> >> Please review this change adopting `PartialArrayState` introduced by [JDK-8337709](https://bugs.openjdk.org/browse/JDK-8337709) to consolidate marking queue sets (oop queue set and objArray queue set) into single queue set in G1 Full GC. >> >> Testing: Tier 1-5 > > Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - cleanup after merge > - Merge remote-tracking branch 'upstream/master' into ArrayChuncking > - Thomas Review > - missing include > - cleanup > - Merge remote-tracking branch 'upstream/master' into ArrayChuncking > - partial array manager Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29114#pullrequestreview-3665120556 From tschatzl at openjdk.org Thu Jan 15 11:19:22 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 15 Jan 2026 11:19:22 GMT Subject: RFR: 8375282: G1: Fix wrong indendation introduced by JDK-8374743 In-Reply-To: References: Message-ID: <7_q_R8VXGAOUKoEZWi0xMBOFzGv3xu29g4OHk39YzFY=.8ceaca30-3eb1-4c41-b823-90cf39c00d53@github.com> On Wed, 14 Jan 2026 17:12:54 GMT, Kim Barrett wrote: >> Hi all, >> >> please review this trivial fix to indendation introduced by JDK-8375282. >> >> Testing: local compilation, gha >> >> Thanks, >> Thomas > > Good and trivial. Thanks @kimbarrett for your review ------------- PR Comment: https://git.openjdk.org/jdk/pull/29227#issuecomment-3754233301 From tschatzl at openjdk.org Thu Jan 15 11:19:24 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 15 Jan 2026 11:19:24 GMT Subject: Integrated: 8375282: G1: Fix wrong indendation introduced by JDK-8374743 In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 11:09:20 GMT, Thomas Schatzl wrote: > Hi all, > > please review this trivial fix to indendation introduced by JDK-8375282. > > Testing: local compilation, gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: f6e5c885 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/f6e5c885e7ca90da2f9fd9ec1c00b4a955ccdf29 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8375282: G1: Fix wrong indendation introduced by JDK-8374743 Reviewed-by: kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/29227 From iwalulya at openjdk.org Thu Jan 15 11:52:05 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 15 Jan 2026 11:52:05 GMT Subject: RFR: 8341630: G1: Adopt PartialArrayState to consolidate marking stack in concurrent marking Message-ID: Hi, Please review this change which adopts the `PartialArrayState` mechanism for G1 concurrent marking. The `PartialArrayState` mechanism can push multiple continuations to the task queues, so it also solves the single-continuation limitation issue in [JDK-8167480](https://bugs.openjdk.org/browse/JDK-8167480). Testing: Mach5 Tier 1-3. ------------- Commit messages: - cleanup after merge - Merge remote-tracking branch 'upstream/master' into CMArrayChuck_V1 - Merge remote-tracking branch 'upstream/master' into CMArrayChuck_V1 - cleanups - space - Merge remote-tracking branch 'upstream/master' into CMArrayChuck_V1 - Reset Partial Array State Manager - init Changes: https://git.openjdk.org/jdk/pull/29249/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29249&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8341630 Stats: 387 lines in 7 files changed: 132 ins; 219 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/29249.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29249/head:pull/29249 PR: https://git.openjdk.org/jdk/pull/29249 From dholmes at openjdk.org Thu Jan 15 11:53:58 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 Jan 2026 11:53:58 GMT Subject: RFR: 8375209: Strengthen Xcheck:jni for JNI critical regions [v3] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 10:22:35 GMT, Aleksey Shipilev wrote: >> [JDK-8375188](https://bugs.openjdk.org/browse/JDK-8375188) shows that misuse for JNI critical is able to deadlock the GC. Therefore, I think we really want to have `-Xcheck:jni` to preempt these cases and allow us to diagnose the issues in the field. >> >> G1 and Shenandoah are not exactly affected by this deadlock. ZGC never had this check, AFAICS, and is affected by the deadlock. We used to have some capability in Serial/Parallel prior to [JDK-8192647](https://bugs.openjdk.org/browse/JDK-8192647), AFAICS: https://github.com/openjdk/jdk/commit/a9c9f7f0cbb2f2395fef08348bf867ffa8875d73#diff-d27fc793db1bf9314b322d494cd1c3269629fe27a605b4441de08d543d020fc3L341-L344 >> >> Additional testing: >> - [x] New test, 100x repetitions >> - [ ] Linux x86_64 server fastdebug, `all` with `-XX:+UseParallelGC -Xcheck:jni` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Capture bad state at the end of JNI transition, check criticality on JNI function enters > Move the check to native->Java transition Somehow I missed this PR before now so need to take a look. src/hotspot/share/prims/jniCheck.cpp line 218: > 216: tty->print_cr("%s", fatal_other_function_in_critical); > 217: // Ideally the following, but at least AWT code triggers this (ouch!): > 218: // NativeReportJNIFatalError(thr, fatal_other_function_in_critical); So it isn't fatal it is still just a warning. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29206#issuecomment-3754338824 PR Review Comment: https://git.openjdk.org/jdk/pull/29206#discussion_r2694082591 From shade at openjdk.org Thu Jan 15 12:05:14 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 15 Jan 2026 12:05:14 GMT Subject: RFR: 8375209: Strengthen Xcheck:jni for JNI critical regions [v3] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 11:50:40 GMT, David Holmes wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Capture bad state at the end of JNI transition, check criticality on JNI function enters >> Move the check to native->Java transition > > src/hotspot/share/prims/jniCheck.cpp line 218: > >> 216: tty->print_cr("%s", fatal_other_function_in_critical); >> 217: // Ideally the following, but at least AWT code triggers this (ouch!): >> 218: // NativeReportJNIFatalError(thr, fatal_other_function_in_critical); > > So it isn't fatal it is still just a warning. Yeah, so I am undecided if we want to make it a part this PR: should we turn these warnings into fatal? We can do it separately, since it likely requires fixing the JDK code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29206#discussion_r2694115296 From shade at openjdk.org Thu Jan 15 12:16:15 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 15 Jan 2026 12:16:15 GMT Subject: RFR: 8375209: Strengthen Xcheck:jni for JNI critical regions [v3] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 11:46:32 GMT, David Holmes wrote: > Somehow I missed this PR before now so need to take a look. Thanks! I think we are in exploration mode now; we also need to complete other architectures. So, high-level question: does adding such a check makes sense to you? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29206#issuecomment-3754429926 From aboldtch at openjdk.org Thu Jan 15 12:35:13 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 15 Jan 2026 12:35:13 GMT Subject: RFR: 8374686: ZGC: Convert zMarkTerminate to use Atomic [v3] In-Reply-To: References: Message-ID: <5QEVviODr8X9ahpUTb3XDJXLRolS-6vrBQBK5mvsNRI=.dd403b39-8a39-4ed2-be21-efa61f2b2832@github.com> > Convert usages of AtomicAccess to Atomic in zMarkTerminate. > > There are a few things that potentially should be changed here. > > First the `_nworkers` variable was accessed through the AtomicAccess API in a handful of places. In this patch I changed it to always be an Atomic. However, this variable is only ever read concurrently. It only gets modified before we schedule a task on the workers (either for a new task, or after all workers have stopped working because we are resizing the work gang size). So potentially this could just be changed to a uint with plain loads and stores. > > The other variables have mutual exclusion when updated, but are read concurrently without synchronisation. In this patch I changed the volatile load + sub/add + atomic relaxed store [+ volatile load] into a simple atomic relaxed add/sub [and fetch]. The main reason being that I thought the code became less verbose, easier to read and understand. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Const the locals ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29246/files - new: https://git.openjdk.org/jdk/pull/29246/files/2a87be98..9030cdd7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29246&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29246&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/29246.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29246/head:pull/29246 PR: https://git.openjdk.org/jdk/pull/29246 From kbarrett at openjdk.org Thu Jan 15 12:40:58 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 15 Jan 2026 12:40:58 GMT Subject: RFR: 8374984: Convert workerUtils to use Atomic [v2] In-Reply-To: References: <537jC3DpvLxPUOPm3Q6f1y6uplIYqd2KrVGUP2CRiJ0=.e7bbf6ef-692b-4533-87b2-3f14d28be771@github.com> Message-ID: On Thu, 15 Jan 2026 07:26:46 GMT, Aleksey Shipilev wrote: >> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge branch 'master' into worker-utils-atomic >> - use compare_set >> - worker utils > > Marked as reviewed by shade (Reviewer). Thanks for reviews @shipilev and @stefank ------------- PR Comment: https://git.openjdk.org/jdk/pull/29201#issuecomment-3754527821 From kbarrett at openjdk.org Thu Jan 15 12:40:59 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 15 Jan 2026 12:40:59 GMT Subject: Integrated: 8374984: Convert workerUtils to use Atomic In-Reply-To: <537jC3DpvLxPUOPm3Q6f1y6uplIYqd2KrVGUP2CRiJ0=.e7bbf6ef-692b-4533-87b2-3f14d28be771@github.com> References: <537jC3DpvLxPUOPm3Q6f1y6uplIYqd2KrVGUP2CRiJ0=.e7bbf6ef-692b-4533-87b2-3f14d28be771@github.com> Message-ID: On Tue, 13 Jan 2026 17:50:39 GMT, Kim Barrett wrote: > Please review this change to make SubTasksDone and SequentialSubTasksDone use > Atomic instead of AtomicAccess. > > Testing: mach5 tier1 This pull request has now been integrated. Changeset: 8ad8920a Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/8ad8920aae5c27de947532ba3cd2b57213208d1e Stats: 20 lines in 2 files changed: 3 ins; 0 del; 17 mod 8374984: Convert workerUtils to use Atomic Reviewed-by: shade, stefank ------------- PR: https://git.openjdk.org/jdk/pull/29201 From eastigeevich at openjdk.org Thu Jan 15 13:48:32 2026 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Thu, 15 Jan 2026 13:48:32 GMT Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact on GCs and JIT performance [v24] In-Reply-To: References: Message-ID: <4hKdtUvRkeh2Y4slayxr8RXerBau9DSqjsBP6FPpWdU=.30d43b6b-e99c-4bc9-92a7-af9fef12ce01@github.com> > Arm Neoverse N1 erratum 1542419: "The core might fetch a stale instruction from memory which violates the ordering of instruction fetches". It is fixed in Neoverse N1 r4p1. > > Neoverse-N1 implementations mitigate erratum 1542419 with a workaround: > - Disable coherent icache. > - Trap IC IVAU instructions. > - Execute: > - `tlbi vae3is, xzr` > - `dsb sy` > > `tlbi vae3is, xzr` invalidates translations for all address spaces (global for address). It waits for all memory accesses using in-scope old translation information to complete before it is considered complete. > > As this workaround has significant overhead, Arm Neoverse N1 (MP050) Software Developer Errata Notice version 29.0 suggests: > > "Since one TLB inner-shareable invalidation is enough to avoid this erratum, the number of injected TLB invalidations should be minimized in the trap handler to mitigate the performance impact due to this workaround." > > This PR introduces a mechanism to defer instruction cache (ICache) invalidation for AArch64 to address the Arm Neoverse N1 erratum 1542419, which causes significant performance overhead if ICache invalidation is performed too frequently. The implementation includes detection of affected Neoverse N1 CPUs and automatic enabling of the workaround for relevant Neoverse N1 revisions. > > Changes include: > > * Added a new diagnostic AArch64 JVM flag `NeoverseN1Errata1542419` to enable or disable the workaround for the erratum. The flag is automatically enabled for Neoverse N1 CPUs prior to r4p1, as detected during VM initialization. > * Added a new diagnostic JVM flag `UseDeferredICacheInvalidation` to enable or disable defered icache invalidation. The flag is automatically enabled for AArch64 if CPU supports hardware cache coherence. > * Introduced the `ICacheInvalidationContext` class to manage deferred ICache invalidation, with platform-specific logic for AArch64. This context is used to batch ICache invalidations, reducing performance impact. > * Provided a default (no-op) implementation for `DefaultICacheInvalidationContext` on platforms where the workaround is not needed, ensuring portability and minimal impact on other architectures. > > **Testing results: linux fastdebug build** > - Neoverse-N1 (Graviton 2) > - [x] tier1: passed > - [x] tier2: passed > - [x] tier3: passed > - [x] tier4: 3 failures > - `containers/docker/TestJcmdWithSideCar.java`: JDK-8341518 > - `com/sun/nio/sctp/SctpChannel/CloseDescriptors.java`: JDK-8298466 > - `java/awt/print/PrinterJob/... Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: Use SingleShotTime mode with multiple iterations for GCPatchingNmethodCost ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28328/files - new: https://git.openjdk.org/jdk/pull/28328/files/3abb6de4..086b1bf4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28328&range=23 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28328&range=22-23 Stats: 16 lines in 1 file changed: 7 ins; 6 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28328.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28328/head:pull/28328 PR: https://git.openjdk.org/jdk/pull/28328 From eastigeevich at openjdk.org Thu Jan 15 13:51:04 2026 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Thu, 15 Jan 2026 13:51:04 GMT Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact on GCs and JIT performance [v13] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 18:50:44 GMT, Aleksey Shipilev wrote: >> The current algorithm: >> - Create an object used in Java methods. >> - Run the methods in the interpreter. >> - Compile the methods. >> - Make the object garbage collectable. >> - Run GC (we measure this). >> >> There are not many things to warm-up. And setting up everything for multiple iterations of GC runs might be expensive. Instead we use forks. >> >> IMO, Yes it is `@BenchmarkMode(OneShot)`. > > Yeah, but first GC would likely be slower, because it would have more real work to do. So you probably want OneShot with the default number of iterations. It will warmup by doing a few GCs, and then do a few other GCs for measurement. @shipilev I updated the microbenchmark to use `Mode.SingleShotTime` and to have multiple iterations. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28328#discussion_r2694464012 From eastigeevich at openjdk.org Thu Jan 15 13:54:01 2026 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Thu, 15 Jan 2026 13:54:01 GMT Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact on GCs and JIT performance [v25] In-Reply-To: References: Message-ID: > Arm Neoverse N1 erratum 1542419: "The core might fetch a stale instruction from memory which violates the ordering of instruction fetches". It is fixed in Neoverse N1 r4p1. > > Neoverse-N1 implementations mitigate erratum 1542419 with a workaround: > - Disable coherent icache. > - Trap IC IVAU instructions. > - Execute: > - `tlbi vae3is, xzr` > - `dsb sy` > > `tlbi vae3is, xzr` invalidates translations for all address spaces (global for address). It waits for all memory accesses using in-scope old translation information to complete before it is considered complete. > > As this workaround has significant overhead, Arm Neoverse N1 (MP050) Software Developer Errata Notice version 29.0 suggests: > > "Since one TLB inner-shareable invalidation is enough to avoid this erratum, the number of injected TLB invalidations should be minimized in the trap handler to mitigate the performance impact due to this workaround." > > This PR introduces a mechanism to defer instruction cache (ICache) invalidation for AArch64 to address the Arm Neoverse N1 erratum 1542419, which causes significant performance overhead if ICache invalidation is performed too frequently. The implementation includes detection of affected Neoverse N1 CPUs and automatic enabling of the workaround for relevant Neoverse N1 revisions. > > Changes include: > > * Added a new diagnostic AArch64 JVM flag `NeoverseN1Errata1542419` to enable or disable the workaround for the erratum. The flag is automatically enabled for Neoverse N1 CPUs prior to r4p1, as detected during VM initialization. > * Added a new diagnostic JVM flag `UseDeferredICacheInvalidation` to enable or disable defered icache invalidation. The flag is automatically enabled for AArch64 if CPU supports hardware cache coherence. > * Introduced the `ICacheInvalidationContext` class to manage deferred ICache invalidation, with platform-specific logic for AArch64. This context is used to batch ICache invalidations, reducing performance impact. > * Provided a default (no-op) implementation for `DefaultICacheInvalidationContext` on platforms where the workaround is not needed, ensuring portability and minimal impact on other architectures. > > **Testing results: linux fastdebug build** > - Neoverse-N1 (Graviton 2) > - [x] tier1: passed > - [x] tier2: passed > - [x] tier3: passed > - [x] tier4: 3 failures > - `containers/docker/TestJcmdWithSideCar.java`: JDK-8341518 > - `com/sun/nio/sctp/SctpChannel/CloseDescriptors.java`: JDK-8298466 > - `java/awt/print/PrinterJob/... Evgeny Astigeevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits: - Merge branch 'master' into JDK-8370947 - Use SingleShotTime mode with multiple iterations for GCPatchingNmethodCost - Fix macos and windows aarch64 debug builds - Remove redundant code - Merge branch 'master' into JDK-8370947 - Fix linux-cross-compile riscv64 build - Restore deleted comment - Remove redundant blank line - Remove redundant include - Merge branch 'master' into JDK-8370947 - ... and 26 more: https://git.openjdk.org/jdk/compare/78a106ff...b0ede0a8 ------------- Changes: https://git.openjdk.org/jdk/pull/28328/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28328&range=24 Stats: 826 lines in 32 files changed: 762 ins; 22 del; 42 mod Patch: https://git.openjdk.org/jdk/pull/28328.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28328/head:pull/28328 PR: https://git.openjdk.org/jdk/pull/28328 From eastigeevich at openjdk.org Thu Jan 15 13:57:47 2026 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Thu, 15 Jan 2026 13:57:47 GMT Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact on GCs and JIT performance [v13] In-Reply-To: References: Message-ID: <4x96d2l_emyQYWXaRWJq5lKPo5-fa1i9Ps1RysUmVDM=.7999c815-7452-4e3e-aa89-7195fe3c060f@github.com> On Wed, 3 Dec 2025 16:11:14 GMT, Aleksey Shipilev wrote: >> Evgeny Astigeevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: >> >> - Fix linux-cross-compile build aarch64 >> - Merge branch 'master' into JDK-8370947 >> - Remove trailing whitespaces >> - Add support of deferred icache invalidation to other GCs and JIT >> - Add UseDeferredICacheInvalidation to defer invalidation on CPU with hardware cache coherence >> - Add jtreg test >> - Fix linux-cross-compile aarch64 build >> - Fix regressions for Java methods without field accesses >> - Fix code style >> - Correct ifdef; Add dsb after ic >> - ... and 9 more: https://git.openjdk.org/jdk/compare/3d54a802...4b04496f > > Interesting work! I was able to look through it very briefly: @shipilev @theRealAph @fisk Could you please review the PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28328#issuecomment-3755001247 From stefank at openjdk.org Thu Jan 15 15:39:55 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 15 Jan 2026 15:39:55 GMT Subject: RFR: 8374686: ZGC: Convert zMarkTerminate to use Atomic [v3] In-Reply-To: <5QEVviODr8X9ahpUTb3XDJXLRolS-6vrBQBK5mvsNRI=.dd403b39-8a39-4ed2-be21-efa61f2b2832@github.com> References: <5QEVviODr8X9ahpUTb3XDJXLRolS-6vrBQBK5mvsNRI=.dd403b39-8a39-4ed2-be21-efa61f2b2832@github.com> Message-ID: On Thu, 15 Jan 2026 12:35:13 GMT, Axel Boldt-Christmas wrote: >> Convert usages of AtomicAccess to Atomic in zMarkTerminate. >> >> There are a few things that potentially should be changed here. >> >> First the `_nworkers` variable was accessed through the AtomicAccess API in a handful of places. In this patch I changed it to always be an Atomic. However, this variable is only ever read concurrently. It only gets modified before we schedule a task on the workers (either for a new task, or after all workers have stopped working because we are resizing the work gang size). So potentially this could just be changed to a uint with plain loads and stores. >> >> The other variables have mutual exclusion when updated, but are read concurrently without synchronisation. In this patch I changed the volatile load + sub/add + atomic relaxed store [+ volatile load] into a simple atomic relaxed add/sub [and fetch]. The main reason being that I thought the code became less verbose, easier to read and understand. >> >> Testing: >> * GHA >> * HotSpot GC tests with ZGC linux x64 and linux aarch64 > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Const the locals Thanks! ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29246#pullrequestreview-3666237029 From tschatzl at openjdk.org Thu Jan 15 15:41:55 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 15 Jan 2026 15:41:55 GMT Subject: RFR: 8375455: G1: Remove unused G1HeapRegionStats::coarsen_stats() Message-ID: Hi all, please review this trivial removal of an unused method. Testing: local compilation Thanks, Thomas ------------- Commit messages: - 8375455 Changes: https://git.openjdk.org/jdk/pull/29253/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29253&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375455 Stats: 9 lines in 2 files changed: 0 ins; 7 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29253.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29253/head:pull/29253 PR: https://git.openjdk.org/jdk/pull/29253 From kdnilsen at openjdk.org Thu Jan 15 17:24:12 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 15 Jan 2026 17:24:12 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v7] In-Reply-To: References: Message-ID: > After studying large numbers of GC logs with degenerated cycles that have resulted from "late" triggers, we propose the following general improvements: > > 1. Track trends in GC times rather than always using the average GC time plus standard deviation. In many situations, GC times trend upward due to, for example, increasing amounts of live data that must be marked as a workload builds up its working set of memory. > 2. Sample allocation rates more frequently than once every 100 ms. > 3. Track trends in allocation rates. In some situations, the allocation rate trends upwards due to, for example, the start of a new phase of execution or a spike in client workload. > 4. When we detect acceleration of allocation rate, predict consumption of memory based on accelerated allocation rates rather than assuming constant allocation rate. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Changes requested by reviewers 1. Change coordination between ShenandoahAdaptiveHeuristics and ShenandoahController/ShenandoahRegulator. Before, ShenandoahAdaptiveHeuristics would poll ShenandoahController or ShenandoahRegulator to obtain most recent wake time and planned sleep time. Now ShnandoahController and and ShenandoahRegulator notify ShenandoahAdaptiveHeuristics each time the values of these variables change. 2. Use available() instead of capacity() - used() when recalculating trigger threshold from within ShenandoahAdaptiveHeuristcs::resume_idle_span(). ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29039/files - new: https://git.openjdk.org/jdk/pull/29039/files/ea38ec15..70b7ebf8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=05-06 Stats: 81 lines in 9 files changed: 25 ins; 49 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/29039.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29039/head:pull/29039 PR: https://git.openjdk.org/jdk/pull/29039 From kdnilsen at openjdk.org Thu Jan 15 17:34:49 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 15 Jan 2026 17:34:49 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v4] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 21:29:23 GMT, William Kemper wrote: >> Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits: >> >> - Fix comment >> - Use PROPERFMT macros >> - Simplify code flow: reviewer suggestion >> - Merge remote-tracking branch 'jdk/master' into accelerated-triggers >> - Remove develop/debug instrumentation >> - add another override >> - Change type of command-line args >> - fix white space >> - Add override to virtual methods >> - Fix race between allocation reporting and querying >> - ... and 55 more: https://git.openjdk.org/jdk/compare/dd20e915...7f3a6d1e > > src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 145: > >> 143: } >> 144: >> 145: double ShenandoahAdaptiveHeuristics::get_most_recent_wake_time() const { > > This introduces a cyclic dependency between control/regulator threads and the heuristics. Since control/regulator threads already _know_ about heuristics, could we instead have the threads invoke setters on the heuristics to provide these values? I've refactored this code now according to your suggestion. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29039#discussion_r2695322992 From kdnilsen at openjdk.org Thu Jan 15 17:40:57 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 15 Jan 2026 17:40:57 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v4] In-Reply-To: References: Message-ID: <7gJpIsl8hdcq9FAXD_ar0TQPC6QvX7R0jrsq_Jj9tZ4=.6605e23e-c200-4266-b96b-7f05a3fa5ef3@github.com> On Thu, 8 Jan 2026 22:28:41 GMT, William Kemper wrote: >> Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits: >> >> - Fix comment >> - Use PROPERFMT macros >> - Simplify code flow: reviewer suggestion >> - Merge remote-tracking branch 'jdk/master' into accelerated-triggers >> - Remove develop/debug instrumentation >> - add another override >> - Change type of command-line args >> - fix white space >> - Add override to virtual methods >> - Fix race between allocation reporting and querying >> - ... and 55 more: https://git.openjdk.org/jdk/compare/dd20e915...7f3a6d1e > > src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp line 73: > >> 71: bool is_spiking(double rate, double threshold) const; >> 72: >> 73: double interval() const { > > Not seeing where these new methods are used. You are correct. Removing interval() and last_sample_time(). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29039#discussion_r2695341304 From kdnilsen at openjdk.org Thu Jan 15 17:55:33 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 15 Jan 2026 17:55:33 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v4] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 22:46:20 GMT, William Kemper wrote: >> Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits: >> >> - Fix comment >> - Use PROPERFMT macros >> - Simplify code flow: reviewer suggestion >> - Merge remote-tracking branch 'jdk/master' into accelerated-triggers >> - Remove develop/debug instrumentation >> - add another override >> - Change type of command-line args >> - fix white space >> - Add override to virtual methods >> - Fix race between allocation reporting and querying >> - ... and 55 more: https://git.openjdk.org/jdk/compare/dd20e915...7f3a6d1e > > src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp line 316: > >> 314: if (progress) { >> 315: heap->notify_gc_progress(); >> 316: heap->shenandoah_policy()->record_success_degenerated(_generation->is_young(), _abbreviated); > > On line 313 above here, we call `policy->record_degenerated` which does everything (and more) that `record_success_degenerated` does. Calling both of them here will increment the various counters twice and is probably not what we want. I think after https://github.com/openjdk/jdk/pull/28834, we shouldn't need `record_success_degenerated` for `ShenandoahCollectorPolicy` at all. Good catch. Thanks. Remove record_success_degenerated(). > src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 493: > >> 491: ShenandoahCodeRoots::initialize(); >> 492: >> 493: // Initialization of controller markes use of varaibles esstablished by initialize_heuristics. > > Suggestion: > > // Initialization of controller makes use of variables established by initialize_heuristics. Thanks. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29039#discussion_r2695380538 PR Review Comment: https://git.openjdk.org/jdk/pull/29039#discussion_r2695384440 From kdnilsen at openjdk.org Thu Jan 15 18:31:51 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 15 Jan 2026 18:31:51 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v8] In-Reply-To: References: Message-ID: > After studying large numbers of GC logs with degenerated cycles that have resulted from "late" triggers, we propose the following general improvements: > > 1. Track trends in GC times rather than always using the average GC time plus standard deviation. In many situations, GC times trend upward due to, for example, increasing amounts of live data that must be marked as a workload builds up its working set of memory. > 2. Sample allocation rates more frequently than once every 100 ms. > 3. Track trends in allocation rates. In some situations, the allocation rate trends upwards due to, for example, the start of a new phase of execution or a spike in client workload. > 4. When we detect acceleration of allocation rate, predict consumption of memory based on accelerated allocation rates rather than assuming constant allocation rate. Kelvin Nilsen has updated the pull request incrementally with two additional commits since the last revision: - Respond to reviewer feedback - Remove unneeded functions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29039/files - new: https://git.openjdk.org/jdk/pull/29039/files/70b7ebf8..1ed1ba66 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=06-07 Stats: 21 lines in 6 files changed: 0 ins; 19 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29039.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29039/head:pull/29039 PR: https://git.openjdk.org/jdk/pull/29039 From xpeng at openjdk.org Thu Jan 15 18:37:22 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Thu, 15 Jan 2026 18:37:22 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v41] In-Reply-To: References: Message-ID: On Tue, 8 Jul 2025 18:26:37 GMT, Kelvin Nilsen wrote: >> Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 298 commits: >> >> - Merge branch 'master' into cas-alloc-1 >> - More accurate census noise >> - Code format >> - typo >> - More eagerly to refresh alloc regions in attempt_allocation_slow since it is holding heap lock >> - While eagerly refresh alloc regions, thread should not yield to safepoint because it is holding uninitialized new object >> - Fix assert when after eagerly refresh alloc regions after fast allocation >> - Remove the support of 0 for flags ShenandoahMutatorAllocRegions and ShenandoahCollectorAllocRegions >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - Add virtual back for release_alloc_regions and reserve_alloc_regions to fix link error >> - ... and 288 more: https://git.openjdk.org/jdk/compare/624d7144...6de6789f > > src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 615: > >> 613: size_t capacity = _free_set->alloc_capacity(i); >> 614: bool is_empty = (capacity == _region_size_bytes); >> 615: // TODO remove assert, not possible to pass when allow mutator to allocate w/o lock. > > Probably the preferred approach here is to "pre-retire" regions when they are made directly allocatable. When the region is pre-retired, it is taken out of the partition, so assert_bounds no longer applies to this region. The new impl always pre-retire when reserve a region from free set. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2695516917 From kbarrett at openjdk.org Thu Jan 15 18:42:53 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 15 Jan 2026 18:42:53 GMT Subject: RFR: 8374686: ZGC: Convert zMarkTerminate to use Atomic [v3] In-Reply-To: <5QEVviODr8X9ahpUTb3XDJXLRolS-6vrBQBK5mvsNRI=.dd403b39-8a39-4ed2-be21-efa61f2b2832@github.com> References: <5QEVviODr8X9ahpUTb3XDJXLRolS-6vrBQBK5mvsNRI=.dd403b39-8a39-4ed2-be21-efa61f2b2832@github.com> Message-ID: On Thu, 15 Jan 2026 12:35:13 GMT, Axel Boldt-Christmas wrote: >> Convert usages of AtomicAccess to Atomic in zMarkTerminate. >> >> There are a few things that potentially should be changed here. >> >> First the `_nworkers` variable was accessed through the AtomicAccess API in a handful of places. In this patch I changed it to always be an Atomic. However, this variable is only ever read concurrently. It only gets modified before we schedule a task on the workers (either for a new task, or after all workers have stopped working because we are resizing the work gang size). So potentially this could just be changed to a uint with plain loads and stores. >> >> The other variables have mutual exclusion when updated, but are read concurrently without synchronisation. In this patch I changed the volatile load + sub/add + atomic relaxed store [+ volatile load] into a simple atomic relaxed add/sub [and fetch]. The main reason being that I thought the code became less verbose, easier to read and understand. >> >> Testing: >> * GHA >> * HotSpot GC tests with ZGC linux x64 and linux aarch64 > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Const the locals Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29246#pullrequestreview-3667052167 From kdnilsen at openjdk.org Thu Jan 15 18:43:01 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 15 Jan 2026 18:43:01 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v4] In-Reply-To: References: Message-ID: <3DyscJVMFCspRM4nseoxI0KASi1uWFAnxWZ6n9dFw0k=.72ddc436-3b2b-489b-ade9-1efbf6ee4a52@github.com> On Fri, 9 Jan 2026 22:20:51 GMT, William Kemper wrote: >> Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits: >> >> - Fix comment >> - Use PROPERFMT macros >> - Simplify code flow: reviewer suggestion >> - Merge remote-tracking branch 'jdk/master' into accelerated-triggers >> - Remove develop/debug instrumentation >> - add another override >> - Change type of command-line args >> - fix white space >> - Add override to virtual methods >> - Fix race between allocation reporting and querying >> - ... and 55 more: https://git.openjdk.org/jdk/compare/dd20e915...7f3a6d1e > > src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 643: > >> 641: future_accelerated_planned_gc_time * 1000); >> 642: } else { >> 643: log_trigger("Momentary spike consumption (%zu%s) exceeds free headroom (%zu%s) at " > > Should the 'Momentary spike' trigger replace the 'instantaneous spike' trigger? It seems like we now have two spike detecting triggers? We could maybe. The conditions under which each triggers are slightly different. I have seen situations where the new Momentary spike consumption triggers when the old "instantaneous spike" did not trigger. Potentially, the other could also happen, though I have not observed it, where the old "instantaneous spike" triggers but momentary spike does not. (Momentary spike is evaluated every 15 ms, whereas instantaneous spike is evaluated every 100 ms. At the time we evaluate a momentary spike, there might be an abundance of runway so we do not trigger. A less extreme instantaneous spike might be observed at a later time, when runway is less plentiful, and that would trigger. Out of an abundance of caution (belts and suspenders), I was thinking to keep both triggers in place. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29039#discussion_r2695536563 From xpeng at openjdk.org Thu Jan 15 18:43:11 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Thu, 15 Jan 2026 18:43:11 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v5] In-Reply-To: References: Message-ID: <3VD5OaZ_TbI3IXCLwJms4bhGAqeH90YCX5E4-b-4kew=.f6e1e8be-5bf9-4151-b3b5-b4614b210408@github.com> On Fri, 7 Nov 2025 19:45:46 GMT, Xiaolong Peng wrote: >> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 2204: >> >>> 2202: i++; >>> 2203: } >>> 2204: return obj; >> >> I think obj always equals nullptr at this point. Seems the code would be easier to understand (and would depend less on effective compiler optimization) if we just made that explicit. Can we just say: >> >> return nullptr? > > Yes, it is always `nullptr`, `return nullptr` will make the code more readable. Resolving this, the code has been refactored, all allocation related codes are in ShenandoahAllocator ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2695539186 From kdnilsen at openjdk.org Thu Jan 15 18:43:19 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 15 Jan 2026 18:43:19 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v29] In-Reply-To: <9Hggsj2zW9VafwI8DdJbN_v0yTmbEpUyYE8QRFMNU5E=.71bc2233-2812-4482-94b1-9796a5c24594@github.com> References: <9Hggsj2zW9VafwI8DdJbN_v0yTmbEpUyYE8QRFMNU5E=.71bc2233-2812-4482-94b1-9796a5c24594@github.com> Message-ID: On Tue, 13 Jan 2026 23:39:46 GMT, William Kemper wrote: >> Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 86 commits: >> >> - Merge remote-tracking branch 'jdk/master' into share-collector-reserves >> - Move rebuild free set earlier in an abbreviated GC cycle >> - Restore deleted assert statement >> - Move special handling into ShenandoahYoungHeuristics::choose_collection_set_from_regiondata() >> - fix another typo >> - Fix typo >> - Fix confusing comment >> - Add comment >> - Merge remote-tracking branch 'jdk/master' into share-collector-reserves >> - Fix whitespace and comment >> - ... and 76 more: https://git.openjdk.org/jdk/compare/659b53fe...27ece3e8 > > src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 688: > >> 686: void move_unaffiliated_regions_from_collector_to_old_collector(ssize_t regions); >> 687: >> 688: inline size_t global_unaffiliated_regions() { > > A nit, but all functions defined in the class declaration are implicitly `inline` and the keyword is unnecessary here. Should I remove inline keyword from all such functions? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2695532295 From kbarrett at openjdk.org Thu Jan 15 18:45:25 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 15 Jan 2026 18:45:25 GMT Subject: RFR: 8375455: G1: Remove unused G1HeapRegionStats::coarsen_stats() In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 15:34:54 GMT, Thomas Schatzl wrote: > Hi all, > > please review this trivial removal of an unused method. > > Testing: local compilation > > Thanks, > Thomas Looks good, and trivial. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29253#pullrequestreview-3667061272 From xpeng at openjdk.org Thu Jan 15 19:01:09 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Thu, 15 Jan 2026 19:01:09 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v17] In-Reply-To: <1MZQLDhJsqK5ZoPIVDYYRyVg0po67A6wVfIpsAl7Qa0=.d0bfa7e4-f448-4bb1-a386-b8226133e6a7@github.com> References: <2YVE3uR8bRJ_8qAtXN4WoRmeY0Y9xhzsmKbxqv5oL2M=.2811f02e-35b8-46cf-863a-db4006ca1a78@github.com> <4Qs9QlvWQ7gX6RW-rwPVJa-Ndhtx883aImTtiXyCYGk=.1c03a208-d6e5-42bc-bfc3-d1f95e968929@github.com> <6J2xtZ1DLytiwflQ0wbQCtg8tsRAHadSdkZGZllLAxY=.af212eeb-44f7-4955-96ab-d069febe4e0e@github.com> <1MZQLDhJsqK5ZoPIVDYYRyVg0po67A6wVfIpsAl7Qa0=.d0bfa7e4-f448-4bb1-a386-b8226133e6a7@github.com> Message-ID: On Wed, 7 Jan 2026 21:09:55 GMT, Xiaolong Peng wrote: >> Please document the results of any experiments as rationale for the final design. > > I did run some experiments and didn't see significant difference, I will keep keep current code using PaddedArray, meanwhile keep this conversation open and make a decision based metrics later after I address the other comments. Here is specjbb results I got, heap size is 8G, 8 cores: | | PaddedArray | Raw array | | | ------------------- | -------------- | --------- | ------- | | 1st | Max jOPS | 17893 | 18092 | 1.11% | | Critical jOPS | 15490 | 15765 | 1.78% | | 2nd | Max jOPS | 18219 | 18092 | -0.70% | | Critical jOPS | 15625 | 15498 | -0.81% | | Average | Max jOPS | 18056 | 18092 | 0.20% | | Critical jOPS | 15557.5 | 15631.5 | 0.48% | | Standard deviation | Max jOPS Stdev | 163 | 0 | | | Critical jOPS Stdev | 67.5 | 133.5 | | I didn't see huge difference, using raw array tends to be slightly better. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2695586099 From dholmes at openjdk.org Thu Jan 15 22:00:34 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 Jan 2026 22:00:34 GMT Subject: RFR: 8375209: Strengthen Xcheck:jni for JNI critical regions [v3] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 12:02:05 GMT, Aleksey Shipilev wrote: >> src/hotspot/share/prims/jniCheck.cpp line 218: >> >>> 216: tty->print_cr("%s", fatal_other_function_in_critical); >>> 217: // Ideally the following, but at least AWT code triggers this (ouch!): >>> 218: // NativeReportJNIFatalError(thr, fatal_other_function_in_critical); >> >> So it isn't fatal it is still just a warning. > > Yeah, so I am undecided if we want to make it a part this PR: should we turn these warnings into fatal? We can do it separately, since it likely requires fixing the JDK code. I think warnings are okay here. The JDK code may still need fixing regardless. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29206#discussion_r2696099539 From dholmes at openjdk.org Thu Jan 15 22:04:40 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 Jan 2026 22:04:40 GMT Subject: RFR: 8375209: Strengthen Xcheck:jni for JNI critical regions [v3] In-Reply-To: References: Message-ID: <_Vx4ouwlnOXEmj-eQUgrdrrMF4vYwhC14G-2kwEH7Wc=.5c795ed1-97ac-4902-8555-b5deaf276e3a@github.com> On Wed, 14 Jan 2026 10:22:35 GMT, Aleksey Shipilev wrote: >> [JDK-8375188](https://bugs.openjdk.org/browse/JDK-8375188) shows that misuse for JNI critical is able to deadlock the GC. Therefore, I think we really want to have `-Xcheck:jni` to preempt these cases and allow us to diagnose the issues in the field. >> >> G1 and Shenandoah are not exactly affected by this deadlock. ZGC never had this check, AFAICS, and is affected by the deadlock. We used to have some capability in Serial/Parallel prior to [JDK-8192647](https://bugs.openjdk.org/browse/JDK-8192647), AFAICS: https://github.com/openjdk/jdk/commit/a9c9f7f0cbb2f2395fef08348bf867ffa8875d73#diff-d27fc793db1bf9314b322d494cd1c3269629fe27a605b4441de08d543d020fc3L341-L344 >> >> Additional testing: >> - [x] New test, 100x repetitions >> - [ ] Linux x86_64 server fastdebug, `all` with `-XX:+UseParallelGC -Xcheck:jni` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Capture bad state at the end of JNI transition, check criticality on JNI function enters > Move the check to native->Java transition I think warning that the native code that has started a critical region either returns (to Java) whilst the critical region is still active, or calls another JNI function, is a good thing. The return part has to be handled by the native call wrapper mechanics unfortunately. The JNI calls can be handled by augmenting the JNI entry macros. I would look at doing that rather than making this GC-centric or trying to handle it at the thread-state-transitions (assuming we can issue a JNI warning whilst still _thread_in_native). ------------- PR Comment: https://git.openjdk.org/jdk/pull/29206#issuecomment-3757087207 From ysr at openjdk.org Thu Jan 15 22:27:11 2026 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Thu, 15 Jan 2026 22:27:11 GMT Subject: RFR: 8351892: GenShen: Remove vestigial young generation sizing options In-Reply-To: References: Message-ID: <2LFLZ5iFczKaAQtZHaD31768YrQaM0rwPrK0j-XmlnI=.b10ebb78-3672-4512-8124-c51a2115f8c3@github.com> On Fri, 9 Jan 2026 19:13:31 GMT, William Kemper wrote: > GenShen generally tries to keep the young generation as large as possible. The options `ShenandoahMinYoungPercentage` and `ShenandoahMaxYoungPercentage` are no longer used. Marked as reviewed by ysr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29144#pullrequestreview-3667884276 From xpeng at openjdk.org Thu Jan 15 22:29:55 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Thu, 15 Jan 2026 22:29:55 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v42] In-Reply-To: References: Message-ID: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request incrementally with two additional commits since the last revision: - Update code as suggested during the review meeting - Use simple array instead of PaddedArray to store alloc regions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/6de6789f..3e8ab717 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=41 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=40-41 Stats: 59 lines in 3 files changed: 16 ins; 26 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From wkemper at openjdk.org Thu Jan 15 22:38:05 2026 From: wkemper at openjdk.org (William Kemper) Date: Thu, 15 Jan 2026 22:38:05 GMT Subject: Integrated: 8351892: GenShen: Remove vestigial young generation sizing options In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 19:13:31 GMT, William Kemper wrote: > GenShen generally tries to keep the young generation as large as possible. The options `ShenandoahMinYoungPercentage` and `ShenandoahMaxYoungPercentage` are no longer used. This pull request has now been integrated. Changeset: 87cbcada Author: William Kemper URL: https://git.openjdk.org/jdk/commit/87cbcadacfa20b24e9ba0bf8374ecbcd331d2b35 Stats: 23 lines in 2 files changed: 0 ins; 23 del; 0 mod 8351892: GenShen: Remove vestigial young generation sizing options Reviewed-by: kdnilsen, ysr ------------- PR: https://git.openjdk.org/jdk/pull/29144 From xpeng at openjdk.org Thu Jan 15 22:42:45 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Thu, 15 Jan 2026 22:42:45 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v14] In-Reply-To: References: <_mkL6HrCqlS1_qgOmXvEj3vsYgo2idQnbaDdMVFEGUk=.9c71f705-1f96-441e-96d0-c99d3053cffd@github.com> Message-ID: On Wed, 7 Jan 2026 23:09:16 GMT, Xiaolong Peng wrote: >> Put the comments describing functions in the .hpp file, where they are currently. But we need to enhance those comments. > > I have added comments on those functions, I'll keep adding more for those missing comments; meanwhile I am trying to avoid excessive comment, pleas point out if any of the comments is not clear. I have removed the branch handling _alloc_region_count == 0, also updated comments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2696214206 From xpeng at openjdk.org Thu Jan 15 22:58:53 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Thu, 15 Jan 2026 22:58:53 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v43] In-Reply-To: References: Message-ID: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Only to set update_watermark when allocate from collector/old collector partition ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/3e8ab717..42770e08 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=42 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=41-42 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From xpeng at openjdk.org Fri Jan 16 00:56:03 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 16 Jan 2026 00:56:03 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v44] In-Reply-To: References: Message-ID: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request incrementally with two additional commits since the last revision: - Code format - Add _volatile_top for atomic allocation in heap region w/o heap lock to address potential race condition when refresh alloc regions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/42770e08..18aa3a38 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=43 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=42-43 Stats: 65 lines in 6 files changed: 35 ins; 7 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From xpeng at openjdk.org Fri Jan 16 00:59:04 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 16 Jan 2026 00:59:04 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v45] In-Reply-To: References: Message-ID: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Remove refreshed_regions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/18aa3a38..65770cfd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=44 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=43-44 Stats: 6 lines in 1 file changed: 0 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From xpeng at openjdk.org Fri Jan 16 01:20:36 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 16 Jan 2026 01:20:36 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v17] In-Reply-To: References: <2YVE3uR8bRJ_8qAtXN4WoRmeY0Y9xhzsmKbxqv5oL2M=.2811f02e-35b8-46cf-863a-db4006ca1a78@github.com> <4Qs9QlvWQ7gX6RW-rwPVJa-Ndhtx883aImTtiXyCYGk=.1c03a208-d6e5-42bc-bfc3-d1f95e968929@github.com> <6J2xtZ1DLytiwflQ0wbQCtg8tsRAHadSdkZGZllLAxY=.af212eeb-44f7-4955-96ab-d069febe4e0e@github.com> <1MZQLDhJsqK5ZoPIVDYYRyVg0po67A6wVfIpsAl7Qa0=.d0bfa7e4-f448-4bb1-a386-b8226133e6a7@github.com> Message-ID: On Thu, 15 Jan 2026 18:57:28 GMT, Xiaolong Peng wrote: >> I did run some experiments and didn't see significant difference, I will keep keep current code using PaddedArray, meanwhile keep this conversation open and make a decision based metrics later after I address the other comments. > > Here is specjbb results I got, heap size is 8G, 8 cores: > > | | | PaddedArray | Raw array | | > | ------------------ | ------------- | ----------- | --------- | ------- | > | 1st | Max jOPS | 17893 | 18092 | 1.11% | > | | Critical jOPS | 15490 | 15765 | 1.78% | > | 2nd | Max jOPS | 18219 | 18092 | -0.70% | > | | Critical jOPS | 15625 | 15498 | -0.81% | > | Average | Max jOPS | 18056 | 18092 | 0.20% | > | | Critical jOPS | 15557.5 | 15631.5 | 0.48% | > | Standard deviation | Max jOPS | 163 | 0 | | > | | Critical jOPS | 67.5 | 133.5 | | > > > I didn't see huge difference, using raw array tends to be slightly better. Based on the test result, I have updated the PR to use raw array type instead of PaddedArray. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2696511915 From xpeng at openjdk.org Fri Jan 16 01:20:37 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 16 Jan 2026 01:20:37 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v14] In-Reply-To: References: <_mkL6HrCqlS1_qgOmXvEj3vsYgo2idQnbaDdMVFEGUk=.9c71f705-1f96-441e-96d0-c99d3053cffd@github.com> Message-ID: On Wed, 7 Jan 2026 22:54:13 GMT, Xiaolong Peng wrote: >> I will update the PR and not use atomic version here, and also another place in refresh_alloc_regions. >> >> Having volatile_top and nonvolatile_top seems necessary, it will make the code more complicated w/o much performance benefits, with CAS allocator, most of alloc request will be handled by the atomic code path, in only few >> cases we need non-atomic allocation: >> * After reserving alloc regions from free set before storing to alloc region, it performs obj allocation if the alloc request has not been satisfied yet. >> * After trying atomic allocation, refresh alloc regions fails, it will try to find a region in free set with enough space for the allocation request. >> >> Yes, all the _age, _youth, _top, _tlab_allocs, _gclab_allocs, _plab_allocs are volatile now, out of these fields, I believe I can maybe remove volatile for _age and _youth(?), but the update of the rest must be atomic because mutators will increase the values in the CAS allocation code path w/o heap lock. > > I have updated the method `atomic_allocate_in` with a template parameter IS_SHARED_ALLOC_REGION, now only when allocating from shared alloc regions the IS_SHARED_ALLOC_REGION parameter is set to true to use atomic operations. I have updated the code to use _volatile_top for CAS allocation, and keep _top nonvolatile, this addresses your concern about the race condition between threads doing CAS allocation and the thread trying to refresh alloc regions, thanks for the suggestion! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2696510211 From xpeng at openjdk.org Fri Jan 16 01:20:42 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 16 Jan 2026 01:20:42 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v20] In-Reply-To: References: <797j9fNWUlV491wWKbFMfthH99o3A5493T0Pcdn_zdc=.417c13b0-8618-4402-aafa-3d86c45c8ff6@github.com> Message-ID: On Tue, 6 Jan 2026 01:19:29 GMT, Kelvin Nilsen wrote: >> Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 265 commits: >> >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - Fix build error after merging from tip >> - Merge branch 'master' into cas-alloc-1 >> - Merge branch 'master' into cas-alloc-1 >> - Some comments updates as suggested in PR review >> - Fix build failure after merge >> - Expend promoted from ShenandoahOldCollectorAllocator >> - Merge branch 'master' into cas-alloc-1 >> - Address PR comments >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - ... and 255 more: https://git.openjdk.org/jdk/compare/de81d389...cf13b7b5 > > src/hotspot/share/gc/shenandoah/shenandoahAllocator.hpp line 91: > >> 89: virtual HeapWord* allocate(ShenandoahAllocRequest& req, bool& in_new_region); >> 90: virtual void release_alloc_regions(); >> 91: virtual void reserve_alloc_regions(); > > Need comments on these functions. Clarify pre-conditions and post-conditions. I think the intention is: > > 1. allocate(): Caller does not hold the heap lock. All allocations by mutator or GC are fulfilled by this function. This function tries to perform a CAS allocation without obtaining the global heap lock. If that fails, it will obtain the global heap lock and do a free-set allocation. As a side effect of doing a free-set allocation, some number of directly allocatable regions may be retired and replaced with new directly allocatable regions. > 2. release_alloc_regions(): Caller must hold the heap lock. This causes all directly allocatable regions to be placed into the appropriate ShenandoahFreeSet partition. We do this in preparation for choosing a collection set and/or rebuilding the freeset. > 3. reserve_alloc_regions(): Caller must hold the heap lock. This causes us to set aside N regions as directly allocatable by removing these regions from the relevant ShenandoahFreeSet partitions. Explain what happens if there are not N regions available. > > Clarify: these three function represent the entirety of the "public mutation API" that is exercised by mutators and GC workers as they interact with the free set? (There is another set of functions that could be characterized as the read-only API for obtaining state information about the free set. This provides information such as available memory, allocated bytes since GC start, etc.) Thanks, I have updated the comments on these public APIs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2696512842 From xpeng at openjdk.org Fri Jan 16 01:25:51 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 16 Jan 2026 01:25:51 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v20] In-Reply-To: References: <797j9fNWUlV491wWKbFMfthH99o3A5493T0Pcdn_zdc=.417c13b0-8618-4402-aafa-3d86c45c8ff6@github.com> Message-ID: On Tue, 6 Jan 2026 22:37:02 GMT, Kelvin Nilsen wrote: >> Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 265 commits: >> >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - Fix build error after merging from tip >> - Merge branch 'master' into cas-alloc-1 >> - Merge branch 'master' into cas-alloc-1 >> - Some comments updates as suggested in PR review >> - Fix build failure after merge >> - Expend promoted from ShenandoahOldCollectorAllocator >> - Merge branch 'master' into cas-alloc-1 >> - Address PR comments >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - ... and 255 more: https://git.openjdk.org/jdk/compare/de81d389...cf13b7b5 > > src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 192: > >> 190: uint i = alloc_start_index; >> 191: do { >> 192: if (ShenandoahHeapRegion* r = nullptr; (r = _alloc_regions[i].address) != nullptr && r->is_active_alloc_region()) { > > Note that there is a race (and performance overhead) with checking r->is_active_alloc_region(). Though a region might be active when we check it here, it may be inactive by the time we attempt to atomic_allocate_in(). > > This is one reason I prefer to use "volatile_top == end" to denote !is_active_alloc_region. This way, you only have to check once (rather than checking is_active() and then checking has_available()). And there is no race between when you check and when you attempt to allocate. I have updated the code to use volatile_top in fast path to allocate from shared alloc regions, it won't test is_active_alloc_region any more, as you suggested, volatile_top is set to the end of region if is it not an active alloc region. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2696520518 From xpeng at openjdk.org Fri Jan 16 01:39:18 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 16 Jan 2026 01:39:18 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v20] In-Reply-To: References: <797j9fNWUlV491wWKbFMfthH99o3A5493T0Pcdn_zdc=.417c13b0-8618-4402-aafa-3d86c45c8ff6@github.com> Message-ID: <0GOCAyyQx8bolR-axUuJIUCGqVPqVfYDwvFvQbDBnJg=.d52a66c0-b8ca-42a6-8539-c4886e391b0a@github.com> On Tue, 6 Jan 2026 23:11:19 GMT, Kelvin Nilsen wrote: >> Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 265 commits: >> >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - Fix build error after merging from tip >> - Merge branch 'master' into cas-alloc-1 >> - Merge branch 'master' into cas-alloc-1 >> - Some comments updates as suggested in PR review >> - Fix build failure after merge >> - Expend promoted from ShenandoahOldCollectorAllocator >> - Merge branch 'master' into cas-alloc-1 >> - Address PR comments >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - ... and 255 more: https://git.openjdk.org/jdk/compare/de81d389...cf13b7b5 > > src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 280: > >> 278: // Step 2: allocate region from FreeSets to fill the alloc regions or satisfy the alloc request. >> 279: ShenandoahHeapRegion* reserved[MAX_ALLOC_REGION_COUNT]; >> 280: int reserved_regions = _free_set->reserve_alloc_regions(ALLOC_PARTITION, refreshable_alloc_regions, > > I request we get rid of the min_free_words argument to free_set->reserve_alloc_regions(). See comments in the called function. I have replied in previous comments, we keep it but passing PLAB::min_size() value for now. > src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 304: > >> 302: log_debug(gc, alloc)("%sAllocator: Storing heap region %li to alloc region %i", >> 303: _alloc_partition_name, reserved[i]->index(), refreshable[i]->alloc_region_index); >> 304: AtomicAccess::store(&refreshable[i]->address, reserved[i]); > > Should not need to perform AtomicAccess because we hold the heap lock here. When we store a region to alloc region array, AtomicAccess::store will ensure other threads can see it immediately, but the read after holding heap lock has been updated to not AtomicAccess::load. > src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 3045: > >> 3043: } >> 3044: >> 3045: int ShenandoahFreeSet::reserve_alloc_regions(ShenandoahFreeSetPartitionId partition, int regions_to_reserve, size_t min_free_words, ShenandoahHeapRegion** reserved_regions) { > > I request that we not enforce min_free_words when reserving allocation regions. This defeats the purpose of allocation bias. The objective is to consume fragmented memory early in the GC cycle (when we have more mitigation options if an allocation request ever fails). Note that every region that is in any partition has at least PLAB::min_size() available memory. > > By requiring that MUTATOR regions have PLAB::max_size() words, we are forcing ourselves to never consume the fragmented memory regions. (Towards the end of GC, when memory is in short supply, we will be unable to find directly allocatable MUTATOR regions. This will force ourselves to obtain the heap lock for every allocation. And these allocations will be inefficient because the remaining memory is highly fragmented.) Thanks, I have updated the PR to pass PLAB::min_size() when reserving allocation regions, basically any region with more than PLAB::min_size() can be reserved as shared alloc region, which is same behavior as you are suggesting. But I will keep the argument `min_free_words` just in case want to change the behavior in future, if a region has very small amount of memory to barely fit one smallest TLAB/GCLAB, most of allocation in the region may not succeed, we may want to avoid putting regions which are almost ready to retire into CAS allocator. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2696536658 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2696541519 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2696534165 From tschatzl at openjdk.org Fri Jan 16 07:52:48 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 16 Jan 2026 07:52:48 GMT Subject: RFR: 8375455: G1: Remove unused G1HeapRegionStats::coarsen_stats() In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 18:42:12 GMT, Kim Barrett wrote: >> Hi all, >> >> please review this trivial removal of an unused method. >> >> Testing: local compilation >> >> Thanks, >> Thomas > > Looks good, and trivial. Thanks @kimbarrett for your review ------------- PR Comment: https://git.openjdk.org/jdk/pull/29253#issuecomment-3758612595 From tschatzl at openjdk.org Fri Jan 16 07:52:50 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 16 Jan 2026 07:52:50 GMT Subject: Integrated: 8375455: G1: Remove unused G1HeapRegionStats::coarsen_stats() In-Reply-To: References: Message-ID: <38xEJl_ChjjcbtVUQ2rycA8wS9tBxZOJgcK10ir6DsY=.4b1333e5-4200-476f-8d7b-f18c89d2ebc7@github.com> On Thu, 15 Jan 2026 15:34:54 GMT, Thomas Schatzl wrote: > Hi all, > > please review this trivial removal of an unused method. > > Testing: local compilation > > Thanks, > Thomas This pull request has now been integrated. Changeset: fda8d050 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/fda8d0506a511c00e65c3f97aaaf6f018945b213 Stats: 9 lines in 2 files changed: 0 ins; 7 del; 2 mod 8375455: G1: Remove unused G1HeapRegionStats::coarsen_stats() Reviewed-by: kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/29253 From xpeng at openjdk.org Fri Jan 16 08:19:31 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 16 Jan 2026 08:19:31 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v46] In-Reply-To: References: Message-ID: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request incrementally with two additional commits since the last revision: - Fix assert in recycle_internal - Set _volatile_top to nullptr(instead of end of region) for region that is not active for CAS alloc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/65770cfd..6c1a5c40 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=45 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=44-45 Stats: 49 lines in 3 files changed: 29 ins; 4 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From aboldtch at openjdk.org Fri Jan 16 08:57:02 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 16 Jan 2026 08:57:02 GMT Subject: RFR: 8374687: ZGC: Convert zNMethodTableIteration to use Atomic Message-ID: Convert usages of AtomicAccess to Atomic in zNMethodTableIteration. Testing: * GHA * HotSpot GC tests with ZGC linux x64 and linux aarch64 ------------- Commit messages: - ZGC: Convert zNMethodTableIteration to use Atomic Changes: https://git.openjdk.org/jdk/pull/29267/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29267&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374687 Stats: 10 lines in 2 files changed: 1 ins; 1 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/29267.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29267/head:pull/29267 PR: https://git.openjdk.org/jdk/pull/29267 From aboldtch at openjdk.org Fri Jan 16 09:09:41 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 16 Jan 2026 09:09:41 GMT Subject: RFR: 8374690: ZGC: Convert zRelocate to use Atomic Message-ID: Convert usages of AtomicAccess to Atomic in zRelocate. Testing: * GHA * HotSpot GC tests with ZGC linux x64 and linux aarch64 ------------- Commit messages: - ZGC: Convert zRelocate to use Atomic Changes: https://git.openjdk.org/jdk/pull/29268/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29268&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374690 Stats: 17 lines in 2 files changed: 1 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/29268.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29268/head:pull/29268 PR: https://git.openjdk.org/jdk/pull/29268 From aboldtch at openjdk.org Fri Jan 16 09:11:27 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 16 Jan 2026 09:11:27 GMT Subject: RFR: 8374692: ZGC: Convert zRemembered to use Atomic Message-ID: Convert usages of AtomicAccess to Atomic in zRemembered. Testing: * GHA * HotSpot GC tests with ZGC linux x64 and linux aarch64 ------------- Commit messages: - ZGC: Convert zRemembered to use Atomic Changes: https://git.openjdk.org/jdk/pull/29269/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29269&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374692 Stats: 8 lines in 2 files changed: 1 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/29269.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29269/head:pull/29269 PR: https://git.openjdk.org/jdk/pull/29269 From aboldtch at openjdk.org Fri Jan 16 09:16:03 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 16 Jan 2026 09:16:03 GMT Subject: RFR: 8374694: ZGC: Convert zRootsIterator to use Atomic Message-ID: Convert usages of AtomicAccess to Atomic in zRootsIterator. Testing: * GHA * HotSpot GC tests with ZGC linux x64 and linux aarch64 ------------- Commit messages: - ZGC: Convert zRootsIterator to use Atomic Changes: https://git.openjdk.org/jdk/pull/29270/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29270&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374694 Stats: 10 lines in 2 files changed: 1 ins; 1 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/29270.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29270/head:pull/29270 PR: https://git.openjdk.org/jdk/pull/29270 From aboldtch at openjdk.org Fri Jan 16 09:19:41 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 16 Jan 2026 09:19:41 GMT Subject: RFR: 8374695: ZGC: Convert zTLABUsage to use Atomic Message-ID: Convert usages of AtomicAccess to Atomic in zTLABUsage. Testing: * GHA * HotSpot GC tests with ZGC linux x64 and linux aarch64 ------------- Commit messages: - ZGC: Convert zTLABUsage to use Atomic Changes: https://git.openjdk.org/jdk/pull/29271/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29271&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374695 Stats: 9 lines in 2 files changed: 1 ins; 1 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/29271.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29271/head:pull/29271 PR: https://git.openjdk.org/jdk/pull/29271 From stefank at openjdk.org Fri Jan 16 09:20:18 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 16 Jan 2026 09:20:18 GMT Subject: RFR: 8374690: ZGC: Convert zRelocate to use Atomic In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 09:00:48 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zRelocate. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29268#pullrequestreview-3669710592 From stefank at openjdk.org Fri Jan 16 09:20:24 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 16 Jan 2026 09:20:24 GMT Subject: RFR: 8374687: ZGC: Convert zNMethodTableIteration to use Atomic In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 08:46:12 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zNMethodTableIteration. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29267#pullrequestreview-3669705252 From stefank at openjdk.org Fri Jan 16 09:22:41 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 16 Jan 2026 09:22:41 GMT Subject: RFR: 8374692: ZGC: Convert zRemembered to use Atomic In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 09:04:38 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zRemembered. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Looks good. Added a possible simplification. src/hotspot/share/gc/z/zRemembered.cpp line 419: > 417: } > 418: > 419: const BitMap::idx_t res = _claimed.compare_exchange(prev, page_index + 1, memory_order_relaxed); If this were changed to `compare_set` then we could get rid of the `res` local. ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29269#pullrequestreview-3669725250 PR Review Comment: https://git.openjdk.org/jdk/pull/29269#discussion_r2697634900 From xpeng at openjdk.org Fri Jan 16 09:22:45 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 16 Jan 2026 09:22:45 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v47] In-Reply-To: References: Message-ID: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request incrementally with two additional commits since the last revision: - Load _volatile_top once in free_bytes_for_atomic_alloc - Fix assert in concurrent_set_update_watermark ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/6c1a5c40..d8f7e51f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=46 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=45-46 Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From stefank at openjdk.org Fri Jan 16 09:34:33 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 16 Jan 2026 09:34:33 GMT Subject: RFR: 8374694: ZGC: Convert zRootsIterator to use Atomic In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 09:07:59 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zRootsIterator. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 src/hotspot/share/gc/z/zRootsIterator.hpp line 38: > 36: private: > 37: Iterator _iter; > 38: Atomic _completed; Could you remove one space from all member indentations here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29270#discussion_r2697680474 From stefank at openjdk.org Fri Jan 16 09:36:41 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 16 Jan 2026 09:36:41 GMT Subject: RFR: 8374695: ZGC: Convert zTLABUsage to use Atomic In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 09:11:09 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zTLABUsage. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 src/hotspot/share/gc/z/zTLABUsage.hpp line 46: > 44: private: > 45: // Accounting TLAB used until the next GC cycle > 46: Atomic _used; Extra space in member indentation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29271#discussion_r2697693949 From tschatzl at openjdk.org Fri Jan 16 09:40:45 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 16 Jan 2026 09:40:45 GMT Subject: RFR: 8375437: G1: Convert G1EvacFailureRegions to use Atomic Message-ID: Hi all, please review the conversion of `G1EvacFailureRegions` to use `Atomic` instead of `AtomicAccess`. Nothing particularly unusual with this change I believe. Testing: gha Thanks, Thomas ------------- Commit messages: - 8375437 Changes: https://git.openjdk.org/jdk/pull/29275/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29275&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375437 Stats: 12 lines in 3 files changed: 4 ins; 2 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/29275.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29275/head:pull/29275 PR: https://git.openjdk.org/jdk/pull/29275 From aboldtch at openjdk.org Fri Jan 16 09:43:30 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 16 Jan 2026 09:43:30 GMT Subject: RFR: 8374693: ZGC: Convert zResurrection to use Atomic Message-ID: Convert usages of AtomicAccess to Atomic in zResurrection. Testing: * GHA * HotSpot GC tests with ZGC linux x64 and linux aarch64 ------------- Commit messages: - ZGC: Convert zResurrection to use Atomic Changes: https://git.openjdk.org/jdk/pull/29276/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29276&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374693 Stats: 12 lines in 3 files changed: 1 ins; 3 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/29276.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29276/head:pull/29276 PR: https://git.openjdk.org/jdk/pull/29276 From stefank at openjdk.org Fri Jan 16 10:13:03 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 16 Jan 2026 10:13:03 GMT Subject: RFR: 8374693: ZGC: Convert zResurrection to use Atomic In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 09:34:07 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zResurrection. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29276#pullrequestreview-3670015757 From stefank at openjdk.org Fri Jan 16 10:14:03 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 16 Jan 2026 10:14:03 GMT Subject: RFR: 8375437: G1: Convert G1EvacFailureRegions to use Atomic In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 09:33:05 GMT, Thomas Schatzl wrote: > Hi all, > > please review the conversion of `G1EvacFailureRegions` to use `Atomic` instead of `AtomicAccess`. Nothing particularly unusual with this change I believe. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29275#pullrequestreview-3670022153 From iwalulya at openjdk.org Fri Jan 16 10:34:40 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Fri, 16 Jan 2026 10:34:40 GMT Subject: RFR: 8375437: G1: Convert G1EvacFailureRegions to use Atomic In-Reply-To: References: Message-ID: <7BXgEKMsj9yTsXdXTQOlTp9ZWP8O1hku18qnQb2ZFLM=.618f2f81-38c4-4a19-96be-0fe3f9ec5dd7@github.com> On Fri, 16 Jan 2026 09:33:05 GMT, Thomas Schatzl wrote: > Hi all, > > please review the conversion of `G1EvacFailureRegions` to use `Atomic` instead of `AtomicAccess`. Nothing particularly unusual with this change I believe. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29275#pullrequestreview-3670127934 From tschatzl at openjdk.org Fri Jan 16 11:22:24 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 16 Jan 2026 11:22:24 GMT Subject: RFR: 8341630: G1: Adopt PartialArrayState to consolidate marking stack in concurrent marking In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 10:23:40 GMT, Ivan Walulya wrote: > Hi, > > Please review this change which adopts the `PartialArrayState` mechanism for G1 concurrent marking. > > The `PartialArrayState` mechanism can push multiple continuations to the task queues, so it also solves the single-continuation limitation issue in [JDK-8167480](https://bugs.openjdk.org/browse/JDK-8167480). > > Testing: Mach5 Tier 1-3. lgtm. src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 679: > 677: } > 678: #endif > 679: Extra newline. ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29249#pullrequestreview-3670387477 PR Review Comment: https://git.openjdk.org/jdk/pull/29249#discussion_r2698117149 From iwalulya at openjdk.org Fri Jan 16 12:17:09 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Fri, 16 Jan 2026 12:17:09 GMT Subject: RFR: 8341630: G1: Adopt PartialArrayState to consolidate marking stack in concurrent marking [v2] In-Reply-To: References: Message-ID: > Hi, > > Please review this change which adopts the `PartialArrayState` mechanism for G1 concurrent marking. > > The `PartialArrayState` mechanism can push multiple continuations to the task queues, so it also solves the single-continuation limitation issue in [JDK-8167480](https://bugs.openjdk.org/browse/JDK-8167480). > > Testing: Mach5 Tier 1-3. Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: Extra newline ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29249/files - new: https://git.openjdk.org/jdk/pull/29249/files/92eb32b8..6a340321 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29249&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29249&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29249.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29249/head:pull/29249 PR: https://git.openjdk.org/jdk/pull/29249 From tschatzl at openjdk.org Fri Jan 16 15:29:40 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 16 Jan 2026 15:29:40 GMT Subject: RFR: 8341630: G1: Adopt PartialArrayState to consolidate marking stack in concurrent marking [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 12:17:09 GMT, Ivan Walulya wrote: >> Hi, >> >> Please review this change which adopts the `PartialArrayState` mechanism for G1 concurrent marking. >> >> The `PartialArrayState` mechanism can push multiple continuations to the task queues, so it also solves the single-continuation limitation issue in [JDK-8167480](https://bugs.openjdk.org/browse/JDK-8167480). >> >> Testing: Mach5 Tier 1-3. > > Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: > > Extra newline Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29249#pullrequestreview-3671433050 From tschatzl at openjdk.org Fri Jan 16 15:32:23 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 16 Jan 2026 15:32:23 GMT Subject: RFR: 8375439: G1: Convert G1MonotonicArena class to use Atomic Message-ID: Hi all, please review the change to use `Atomic` in `G1MonotonicArena`. Testing: gha Thanks, Thomas ------------- Commit messages: - * copyright update - 8375439 Changes: https://git.openjdk.org/jdk/pull/29277/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29277&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375439 Stats: 58 lines in 3 files changed: 1 ins; 2 del; 55 mod Patch: https://git.openjdk.org/jdk/pull/29277.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29277/head:pull/29277 PR: https://git.openjdk.org/jdk/pull/29277 From tschatzl at openjdk.org Fri Jan 16 15:33:12 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 16 Jan 2026 15:33:12 GMT Subject: RFR: 8375463: G1: Remove AtomicAccess include from files that do not use it Message-ID: <9sWsyG0Hc1noL5OJDnEvn4guCbKwHCXvifd0OO_qg3A=.6551620f-f348-471e-b5e1-25c25dea8d77@github.com> Hi all, please review this trivial removal of unnecessary `AtomicAccess.hpp` includes. These files do not use any part of it. The one in `g1CardSetMemory.hpp` is handled in another PR. Testing: gha Thanks, Thomas ------------- Commit messages: - 8375463 Changes: https://git.openjdk.org/jdk/pull/29278/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29278&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375463 Stats: 12 lines in 7 files changed: 0 ins; 7 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/29278.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29278/head:pull/29278 PR: https://git.openjdk.org/jdk/pull/29278 From stefank at openjdk.org Fri Jan 16 15:46:06 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 16 Jan 2026 15:46:06 GMT Subject: RFR: 8375439: G1: Convert G1MonotonicArena class to use Atomic In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 11:06:03 GMT, Thomas Schatzl wrote: > Hi all, > > please review the change to use `Atomic` in `G1MonotonicArena`. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29277#pullrequestreview-3671507416 From stefank at openjdk.org Fri Jan 16 15:47:46 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 16 Jan 2026 15:47:46 GMT Subject: RFR: 8375463: G1: Remove AtomicAccess include from files that do not use it In-Reply-To: <9sWsyG0Hc1noL5OJDnEvn4guCbKwHCXvifd0OO_qg3A=.6551620f-f348-471e-b5e1-25c25dea8d77@github.com> References: <9sWsyG0Hc1noL5OJDnEvn4guCbKwHCXvifd0OO_qg3A=.6551620f-f348-471e-b5e1-25c25dea8d77@github.com> Message-ID: On Fri, 16 Jan 2026 11:06:26 GMT, Thomas Schatzl wrote: > Hi all, > > please review this trivial removal of unnecessary `AtomicAccess.hpp` includes. These files do not use any part of it. > > The one in `g1CardSetMemory.hpp` is handled in another PR. > > Testing: gha > > Thanks, > Thomas Looks good as long as it compiles without precompiled headers. ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29278#pullrequestreview-3671515806 From kdnilsen at openjdk.org Fri Jan 16 15:48:05 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Fri, 16 Jan 2026 15:48:05 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v9] In-Reply-To: References: Message-ID: > After studying large numbers of GC logs with degenerated cycles that have resulted from "late" triggers, we propose the following general improvements: > > 1. Track trends in GC times rather than always using the average GC time plus standard deviation. In many situations, GC times trend upward due to, for example, increasing amounts of live data that must be marked as a workload builds up its working set of memory. > 2. Sample allocation rates more frequently than once every 100 ms. > 3. Track trends in allocation rates. In some situations, the allocation rate trends upwards due to, for example, the start of a new phase of execution or a spike in client workload. > 4. When we detect acceleration of allocation rate, predict consumption of memory based on accelerated allocation rates rather than assuming constant allocation rate. Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 73 commits: - Fix compile errors following merge from master But there are still many correctness failures following this merge. Still debugging. - Merge remote-tracking branch 'jdk/master' into accelerated-triggers - Respond to reviewer feedback - Remove unneeded functions - Changes requested by reviewers 1. Change coordination between ShenandoahAdaptiveHeuristics and ShenandoahController/ShenandoahRegulator. Before, ShenandoahAdaptiveHeuristics would poll ShenandoahController or ShenandoahRegulator to obtain most recent wake time and planned sleep time. Now ShnandoahController and and ShenandoahRegulator notify ShenandoahAdaptiveHeuristics each time the values of these variables change. 2. Use available() instead of capacity() - used() when recalculating trigger threshold from within ShenandoahAdaptiveHeuristcs::resume_idle_span(). - move some post_initialize() work into subclass ShenandoahGenerationalHeuristics - Merge remote-tracking branch 'jdk/master' into accelerated-triggers - Merge remote-tracking branch 'jdk/master' into accelerated-triggers - Fix comment - Use PROPERFMT macros - ... and 63 more: https://git.openjdk.org/jdk/compare/34705a77...ce54e38d ------------- Changes: https://git.openjdk.org/jdk/pull/29039/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=08 Stats: 1004 lines in 24 files changed: 893 ins; 41 del; 70 mod Patch: https://git.openjdk.org/jdk/pull/29039.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29039/head:pull/29039 PR: https://git.openjdk.org/jdk/pull/29039 From kdnilsen at openjdk.org Fri Jan 16 17:30:30 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Fri, 16 Jan 2026 17:30:30 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v10] In-Reply-To: References: Message-ID: > After studying large numbers of GC logs with degenerated cycles that have resulted from "late" triggers, we propose the following general improvements: > > 1. Track trends in GC times rather than always using the average GC time plus standard deviation. In many situations, GC times trend upward due to, for example, increasing amounts of live data that must be marked as a workload builds up its working set of memory. > 2. Sample allocation rates more frequently than once every 100 ms. > 3. Track trends in allocation rates. In some situations, the allocation rate trends upwards due to, for example, the start of a new phase of execution or a spike in client workload. > 4. When we detect acceleration of allocation rate, predict consumption of memory based on accelerated allocation rates rather than assuming constant allocation rate. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Fix full gc bug introduced by merge from master ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29039/files - new: https://git.openjdk.org/jdk/pull/29039/files/ce54e38d..e2c0ab1c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=08-09 Stats: 4 lines in 1 file changed: 1 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29039.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29039/head:pull/29039 PR: https://git.openjdk.org/jdk/pull/29039 From tschatzl at openjdk.org Fri Jan 16 19:00:19 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 16 Jan 2026 19:00:19 GMT Subject: RFR: 8375436: G1: Convert G1CardSet classes to use Atomic Message-ID: Hi all, please review this removal of use of the AtomicAccess class in G1 card set related classes, replacing with use of Atomic. Although a bit on the large side, it would be hard to do the card set changes separately per class. Other than that I think it is fairly straightforward, except for the addition of a copy constructor for `G1CardSetHashTableValue` because the `ConcurrentHashTable` requires it. Testing: gha Thanks, Thomas ------------- Commit messages: - * fix whitespace - 8375436 Changes: https://git.openjdk.org/jdk/pull/29274/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29274&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375436 Stats: 119 lines in 6 files changed: 9 ins; 4 del; 106 mod Patch: https://git.openjdk.org/jdk/pull/29274.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29274/head:pull/29274 PR: https://git.openjdk.org/jdk/pull/29274 From xpeng at openjdk.org Fri Jan 16 19:37:36 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 16 Jan 2026 19:37:36 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v48] In-Reply-To: References: Message-ID: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Fix new race condition in unset_active_alloc_region which sync _atomic_top back to _top, other threads may see stale _top if not holding heap lock ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/d8f7e51f..83fe3bc2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=47 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=46-47 Stats: 36 lines in 5 files changed: 3 ins; 0 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From xpeng at openjdk.org Fri Jan 16 19:40:25 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 16 Jan 2026 19:40:25 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v49] In-Reply-To: References: Message-ID: <9zKqYUxiHA4avkGfUq2TeSMbc43_qYcn9IZo8jQlUlI=.1cccb57b-0d28-444f-a87f-c3870816a748@github.com> > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Add more code comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/83fe3bc2..e6192824 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=48 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=47-48 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From kdnilsen at openjdk.org Fri Jan 16 19:43:16 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Fri, 16 Jan 2026 19:43:16 GMT Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need accurate live_data (Original revision) Message-ID: <7JK4muPbya1kL85_zTdJly1jGLlkv39bISYDeKhWtOo=.a16ac8ec-f411-4a2e-b5a4-62f999fe78e1@github.com> This is the originally proposed PR to address https://bugs.openjdk.org/browse/JDK-8353115 At the time this proposed PR was reviewed, a suggestion for refactoring was proposed and explored, resulting in https://github.com/openjdk/jdk/pull/24319 Though the refactored implementation may have some desirable characteristics, this original implementation appears to have better performance. The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected. In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region. This is typically ok for young regions, where the amount of live data determines whether a region should be added to the collection set during the final-mark safepoint. However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated. In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended. This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions. ------------- Commit messages: - reset _mixed_candidate_garbage_words in recycle_internal() - Merge remote-tracking branch 'jdk/master' into revA-fix-live-data-for-mixed-evac-candidates - touch file to force retests - Merge remote-tracking branch 'jdk/master' into revA-fix-live-data-for-mixed-evac-candidates - fix asserts - Use shenandoah_assert_safepoint() instead of is_at_safepoint() - Track live and garbage for mixed-evac regions Changes: https://git.openjdk.org/jdk/pull/29127/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29127&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353115 Stats: 52 lines in 5 files changed: 52 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29127.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29127/head:pull/29127 PR: https://git.openjdk.org/jdk/pull/29127 From wkemper at openjdk.org Fri Jan 16 19:43:17 2026 From: wkemper at openjdk.org (William Kemper) Date: Fri, 16 Jan 2026 19:43:17 GMT Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need accurate live_data (Original revision) In-Reply-To: <7JK4muPbya1kL85_zTdJly1jGLlkv39bISYDeKhWtOo=.a16ac8ec-f411-4a2e-b5a4-62f999fe78e1@github.com> References: <7JK4muPbya1kL85_zTdJly1jGLlkv39bISYDeKhWtOo=.a16ac8ec-f411-4a2e-b5a4-62f999fe78e1@github.com> Message-ID: On Thu, 8 Jan 2026 21:05:36 GMT, Kelvin Nilsen wrote: > This is the originally proposed PR to address https://bugs.openjdk.org/browse/JDK-8353115 > At the time this proposed PR was reviewed, a suggestion for refactoring was proposed and explored, resulting in https://github.com/openjdk/jdk/pull/24319 > > Though the refactored implementation may have some desirable characteristics, this original implementation appears to have better performance. > > The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected. In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region. This is typically ok for young regions, where the amount of live data determines whether a region should be added to the collection set during the final-mark safepoint. > > However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated. In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended. > > This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions. Changes requested by wkemper (Reviewer). src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 78: > 76: _live_data(0), > 77: _critical_pins(0), > 78: _mixed_candidate_garbage_words(0), Can we zero this out in `ShHeapRegion::recycle_internal`? Perhaps not strictly necessary, but seems like good hygiene. ------------- PR Review: https://git.openjdk.org/jdk/pull/29127#pullrequestreview-3658125456 PR Review Comment: https://git.openjdk.org/jdk/pull/29127#discussion_r2688278457 From kdnilsen at openjdk.org Fri Jan 16 19:43:19 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Fri, 16 Jan 2026 19:43:19 GMT Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need accurate live_data (Original revision) In-Reply-To: References: <7JK4muPbya1kL85_zTdJly1jGLlkv39bISYDeKhWtOo=.a16ac8ec-f411-4a2e-b5a4-62f999fe78e1@github.com> Message-ID: <2cXg1cIZMsioz60GjE16T4sf4mTf8OL66JdVOBFeObw=.12835667-63ba-438a-a231-6411cb41fe4f@github.com> On Tue, 13 Jan 2026 22:06:48 GMT, William Kemper wrote: >> This is the originally proposed PR to address https://bugs.openjdk.org/browse/JDK-8353115 >> At the time this proposed PR was reviewed, a suggestion for refactoring was proposed and explored, resulting in https://github.com/openjdk/jdk/pull/24319 >> >> Though the refactored implementation may have some desirable characteristics, this original implementation appears to have better performance. >> >> The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected. In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region. This is typically ok for young regions, where the amount of live data determines whether a region should be added to the collection set during the final-mark safepoint. >> >> However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated. In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended. >> >> This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions. > > src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 78: > >> 76: _live_data(0), >> 77: _critical_pins(0), >> 78: _mixed_candidate_garbage_words(0), > > Can we zero this out in `ShHeapRegion::recycle_internal`? Perhaps not strictly necessary, but seems like good hygiene. Done. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29127#discussion_r2699733050 From kdnilsen at openjdk.org Fri Jan 16 20:04:18 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Fri, 16 Jan 2026 20:04:18 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v11] In-Reply-To: References: Message-ID: > After studying large numbers of GC logs with degenerated cycles that have resulted from "late" triggers, we propose the following general improvements: > > 1. Track trends in GC times rather than always using the average GC time plus standard deviation. In many situations, GC times trend upward due to, for example, increasing amounts of live data that must be marked as a workload builds up its working set of memory. > 2. Sample allocation rates more frequently than once every 100 ms. > 3. Track trends in allocation rates. In some situations, the allocation rate trends upwards due to, for example, the start of a new phase of execution or a spike in client workload. > 4. When we detect acceleration of allocation rate, predict consumption of memory based on accelerated allocation rates rather than assuming constant allocation rate. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: reorder trigger evaulation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29039/files - new: https://git.openjdk.org/jdk/pull/29039/files/e2c0ab1c..19cd3dd6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=09-10 Stats: 102 lines in 1 file changed: 52 ins; 50 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29039.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29039/head:pull/29039 PR: https://git.openjdk.org/jdk/pull/29039 From wkemper at openjdk.org Fri Jan 16 21:00:35 2026 From: wkemper at openjdk.org (William Kemper) Date: Fri, 16 Jan 2026 21:00:35 GMT Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need accurate live_data (Original revision) In-Reply-To: <7JK4muPbya1kL85_zTdJly1jGLlkv39bISYDeKhWtOo=.a16ac8ec-f411-4a2e-b5a4-62f999fe78e1@github.com> References: <7JK4muPbya1kL85_zTdJly1jGLlkv39bISYDeKhWtOo=.a16ac8ec-f411-4a2e-b5a4-62f999fe78e1@github.com> Message-ID: On Thu, 8 Jan 2026 21:05:36 GMT, Kelvin Nilsen wrote: > This is the originally proposed PR to address https://bugs.openjdk.org/browse/JDK-8353115 > At the time this proposed PR was reviewed, a suggestion for refactoring was proposed and explored, resulting in https://github.com/openjdk/jdk/pull/24319 > > Though the refactored implementation may have some desirable characteristics, this original implementation appears to have better performance. > > The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected. In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region. This is typically ok for young regions, where the amount of live data determines whether a region should be added to the collection set during the final-mark safepoint. > > However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated. In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended. > > This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions. LGTM, sorry for the churn. ------------- Marked as reviewed by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29127#pullrequestreview-3672702229 From wkemper at openjdk.org Fri Jan 16 21:09:30 2026 From: wkemper at openjdk.org (William Kemper) Date: Fri, 16 Jan 2026 21:09:30 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v29] In-Reply-To: References: <9Hggsj2zW9VafwI8DdJbN_v0yTmbEpUyYE8QRFMNU5E=.71bc2233-2812-4482-94b1-9796a5c24594@github.com> Message-ID: On Thu, 15 Jan 2026 18:38:36 GMT, Kelvin Nilsen wrote: >> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 688: >> >>> 686: void move_unaffiliated_regions_from_collector_to_old_collector(ssize_t regions); >>> 687: >>> 688: inline size_t global_unaffiliated_regions() { >> >> A nit, but all functions defined in the class declaration are implicitly `inline` and the keyword is unnecessary here. > > Should I remove inline keyword from all such functions? Some popular IDE's will give a warning for the redundant keyword in their default configuration. The hotspot style guide is silent on the issue. I'm not suggesting we remove the redundant keyword from all files, but if a header has a mix, I'd rather take out the redundant keyword. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2699967403 From xpeng at openjdk.org Sat Jan 17 00:31:28 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Sat, 17 Jan 2026 00:31:28 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v50] In-Reply-To: References: Message-ID: <64D5JxKeHWZRaJ1hFC80vMR6Buq1-AiVFTGYuOmmpO4=.c399a656-9ae4-4e3c-a97e-982d565d205a@github.com> > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Enforce memory order by adding fence ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/e6192824..5e080fb5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=49 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=48-49 Stats: 18 lines in 3 files changed: 12 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From kdnilsen at openjdk.org Sat Jan 17 03:47:47 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Sat, 17 Jan 2026 03:47:47 GMT Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need accurate live_data (Original revision) [v2] In-Reply-To: <7JK4muPbya1kL85_zTdJly1jGLlkv39bISYDeKhWtOo=.a16ac8ec-f411-4a2e-b5a4-62f999fe78e1@github.com> References: <7JK4muPbya1kL85_zTdJly1jGLlkv39bISYDeKhWtOo=.a16ac8ec-f411-4a2e-b5a4-62f999fe78e1@github.com> Message-ID: > This is the originally proposed PR to address https://bugs.openjdk.org/browse/JDK-8353115 > At the time this proposed PR was reviewed, a suggestion for refactoring was proposed and explored, resulting in https://github.com/openjdk/jdk/pull/24319 > > Though the refactored implementation may have some desirable characteristics, this original implementation appears to have better performance. > > The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected. In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region. This is typically ok for young regions, where the amount of live data determines whether a region should be added to the collection set during the final-mark safepoint. > > However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated. In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended. > > This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: fix typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29127/files - new: https://git.openjdk.org/jdk/pull/29127/files/2782260b..f2b7e15a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29127&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29127&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29127.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29127/head:pull/29127 PR: https://git.openjdk.org/jdk/pull/29127 From xpeng at openjdk.org Sat Jan 17 06:11:30 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Sat, 17 Jan 2026 06:11:30 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v51] In-Reply-To: References: Message-ID: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request incrementally with two additional commits since the last revision: - More comments - Remove one redundant fence ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/5e080fb5..bee032ee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=50 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=49-50 Stats: 6 lines in 2 files changed: 3 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From kdnilsen at openjdk.org Sun Jan 18 03:32:25 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Sun, 18 Jan 2026 03:32:25 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v31] In-Reply-To: References: Message-ID: > Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). > > This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. > > The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. > > ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) > > With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. > > ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) > > At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. > > ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) > > The command line for these comparisons follows: > > > ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jdk/bin/java \ > -XX:+Unlock... Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 89 commits: - Add debugging instrumentation - Merge remote-tracking branch 'jdk/master' into share-collector-reserves - Use PROPERFMTARGS - Merge remote-tracking branch 'jdk/master' into share-collector-reserves - Move rebuild free set earlier in an abbreviated GC cycle - Restore deleted assert statement - Move special handling into ShenandoahYoungHeuristics::choose_collection_set_from_regiondata() - fix another typo - Fix typo - Fix confusing comment - ... and 79 more: https://git.openjdk.org/jdk/compare/a0e6f028...eb97b843 ------------- Changes: https://git.openjdk.org/jdk/pull/25357/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=30 Stats: 1520 lines in 41 files changed: 793 ins; 281 del; 446 mod Patch: https://git.openjdk.org/jdk/pull/25357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25357/head:pull/25357 PR: https://git.openjdk.org/jdk/pull/25357 From kdnilsen at openjdk.org Sun Jan 18 16:11:33 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Sun, 18 Jan 2026 16:11:33 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v32] In-Reply-To: References: Message-ID: > Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). > > This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. > > The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. > > ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) > > With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. > > ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) > > At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. > > ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) > > The command line for these comparisons follows: > > > ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jdk/bin/java \ > -XX:+Unlock... Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Fix uninitialized variable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25357/files - new: https://git.openjdk.org/jdk/pull/25357/files/eb97b843..e7cf9541 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=31 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=30-31 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25357/head:pull/25357 PR: https://git.openjdk.org/jdk/pull/25357 From aboldtch at openjdk.org Mon Jan 19 06:20:09 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 19 Jan 2026 06:20:09 GMT Subject: RFR: 8374695: ZGC: Convert zTLABUsage to use Atomic [v2] In-Reply-To: References: Message-ID: > Convert usages of AtomicAccess to Atomic in zTLABUsage. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Remove superfluous space ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29271/files - new: https://git.openjdk.org/jdk/pull/29271/files/4306b21d..9998cc64 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29271&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29271&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29271.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29271/head:pull/29271 PR: https://git.openjdk.org/jdk/pull/29271 From tschatzl at openjdk.org Mon Jan 19 08:34:30 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 19 Jan 2026 08:34:30 GMT Subject: RFR: 8375437: G1: Convert G1EvacFailureRegions to use Atomic In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 10:11:15 GMT, Stefan Karlsson wrote: >> Hi all, >> >> please review the conversion of `G1EvacFailureRegions` to use `Atomic` instead of `AtomicAccess`. Nothing particularly unusual with this change I believe. >> >> Testing: gha >> >> Thanks, >> Thomas > > Marked as reviewed by stefank (Reviewer). Thanks @stefank @walulyai for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/29275#issuecomment-3767077086 From tschatzl at openjdk.org Mon Jan 19 08:36:26 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 19 Jan 2026 08:36:26 GMT Subject: Integrated: 8375437: G1: Convert G1EvacFailureRegions to use Atomic In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 09:33:05 GMT, Thomas Schatzl wrote: > Hi all, > > please review the conversion of `G1EvacFailureRegions` to use `Atomic` instead of `AtomicAccess`. Nothing particularly unusual with this change I believe. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 9d7ecd51 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/9d7ecd51d72a1a9f34a19c07813e8b5530e6a944 Stats: 12 lines in 3 files changed: 4 ins; 2 del; 6 mod 8375437: G1: Convert G1EvacFailureRegions to use Atomic Reviewed-by: stefank, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/29275 From lkorinth at openjdk.org Mon Jan 19 08:39:09 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 19 Jan 2026 08:39:09 GMT Subject: RFR: 8373253: Re-work InjectGCWorkerCreationFailure for future changes [v4] In-Reply-To: <78ejbDKfHkTR88XnHC2t975-zof6vMjdM_M_rTyB0pk=.d5c9798a-b1ca-4299-af35-2caaad2f8106@github.com> References: <78ejbDKfHkTR88XnHC2t975-zof6vMjdM_M_rTyB0pk=.d5c9798a-b1ca-4299-af35-2caaad2f8106@github.com> Message-ID: > This PR slightly changes when we may `InjectGCWorkerCreationFailure`. At the moment we wait until `is_init_completed()`. I am changing this to instead be after `_created_workers > 0`. The reason is that we might in the future, https://bugs.openjdk.org/browse/JDK-8367993, create even more threads "on demand", and if so, we would fail VM creation if we inject worker creation failures after the VM is initiated but before we have created any of the worker threads. > > This change should not change the current behaviour. But help future improvements. > > I have tested this on `test/hotspot/jtreg/gc/stress/gcold/TestGCOldWithG1.java`, the only place where this flag is tested to my knowledge. Leo Korinth has updated the pull request incrementally with four additional commits since the last revision: - Proposal by Stefan J - wip - Revert "8373253: Re-work InjectGCWorkerCreationFailure for future changes" This reverts commit d45ea8817ab2303b2decd8cbb2cd1bf5280aa181. - Revert "Fixup after comment from Ivan." This reverts commit 2aa8aa4b68027b62a8d4be1b86720fadfa48dda5. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28719/files - new: https://git.openjdk.org/jdk/pull/28719/files/11649b67..5703deb1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28719&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28719&range=02-03 Stats: 25 lines in 2 files changed: 18 ins; 7 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28719.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28719/head:pull/28719 PR: https://git.openjdk.org/jdk/pull/28719 From iwalulya at openjdk.org Mon Jan 19 08:45:22 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 19 Jan 2026 08:45:22 GMT Subject: RFR: 8373894: G1: Count evacuation-failed garbage collections in gc cpu usage In-Reply-To: References: Message-ID: <-HiKmD5SHw5cWaPBZxfcDB4dGKnuGFJeTKCJfWB4GCs=.6bfa7d13-4ac3-4dfa-a014-57b51243a5d0@github.com> On Thu, 8 Jan 2026 13:51:24 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that makes evacuation failed garbage collections count in the gc CPU usage calculations. > > The reason is that currently (since forever), G1 considers garbage collections that experience an evacuation failure to not count in the cpu usage calculations. > > (Afair this has been introduced because the previously extremely slow evacuation failures would impact cpu usage based calculations too much even if very infrequent. For many releases evacuation failure handling is at least parallel and in the same order of magnitude wrt to performance). > > This can cause significant distortions in GC behavior. > > In the worst case, if for some reason all garbage collections experience evacuation failure, gc cpu usage (at least for the young gen evacuation pauses) is considered as (close to) zero, with repercussions on heap sizing. > > Testing: tier1-5 multiple times to find tests that fail because of the UseGCOverheadLimit flag > > Thanks, > Thomas Nit: A comment in the PR about the changes in the test would have been helpful. ------------- Marked as reviewed by iwalulya (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29115#pullrequestreview-3676922588 From tschatzl at openjdk.org Mon Jan 19 08:48:29 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 19 Jan 2026 08:48:29 GMT Subject: RFR: 8375463: G1: Remove AtomicAccess include from files that do not use it In-Reply-To: <9sWsyG0Hc1noL5OJDnEvn4guCbKwHCXvifd0OO_qg3A=.6551620f-f348-471e-b5e1-25c25dea8d77@github.com> References: <9sWsyG0Hc1noL5OJDnEvn4guCbKwHCXvifd0OO_qg3A=.6551620f-f348-471e-b5e1-25c25dea8d77@github.com> Message-ID: <_E7NNNl0PoDrSjSEGoTT4ljYs-hRDpZvtQ-scYQDwQI=.99968360-f3a0-423c-89e8-52a1b598c2f2@github.com> On Fri, 16 Jan 2026 11:06:26 GMT, Thomas Schatzl wrote: > Hi all, > > please review this trivial removal of unnecessary `AtomicAccess.hpp` includes. These files do not use any part of it. > > The one in `g1CardSetMemory.hpp` is handled in another PR. > > Testing: gha > > Thanks, > Thomas I always compile without PCH locally. Checked again for all interesting builds (slow/fastdebug, release) and it is fine. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29278#issuecomment-3767130406 From iwalulya at openjdk.org Mon Jan 19 08:56:02 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 19 Jan 2026 08:56:02 GMT Subject: RFR: 8375439: G1: Convert G1MonotonicArena class to use Atomic In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 11:06:03 GMT, Thomas Schatzl wrote: > Hi all, > > please review the change to use `Atomic` in `G1MonotonicArena`. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29277#pullrequestreview-3676966367 From lkorinth at openjdk.org Mon Jan 19 08:57:59 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 19 Jan 2026 08:57:59 GMT Subject: RFR: 8373253: Re-work InjectGCWorkerCreationFailure for future changes [v4] In-Reply-To: References: <78ejbDKfHkTR88XnHC2t975-zof6vMjdM_M_rTyB0pk=.d5c9798a-b1ca-4299-af35-2caaad2f8106@github.com> Message-ID: On Mon, 19 Jan 2026 08:39:09 GMT, Leo Korinth wrote: >> This PR slightly changes when we may `InjectGCWorkerCreationFailure`. At the moment we wait until `is_init_completed()`. I am changing this to instead be after `_created_workers > 0`. The reason is that we might in the future, https://bugs.openjdk.org/browse/JDK-8367993, create even more threads "on demand", and if so, we would fail VM creation if we inject worker creation failures after the VM is initiated but before we have created any of the worker threads. >> >> This change should not change the current behaviour. But help future improvements. >> >> I have tested this on `test/hotspot/jtreg/gc/stress/gcold/TestGCOldWithG1.java`, the only place where this flag is tested to my knowledge. > > Leo Korinth has updated the pull request incrementally with four additional commits since the last revision: > > - Proposal by Stefan J > - wip > - Revert "8373253: Re-work InjectGCWorkerCreationFailure for future changes" > > This reverts commit d45ea8817ab2303b2decd8cbb2cd1bf5280aa181. > - Revert "Fixup after comment from Ivan." > > This reverts commit 2aa8aa4b68027b62a8d4be1b86720fadfa48dda5. So I reverted all my earlier changes and used Stefan J's suggestion. The "wip" commit includes a temporary version that did not make it from me (using De Morgan rewrite), and you can ignore it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28719#issuecomment-3767160448 From tschatzl at openjdk.org Mon Jan 19 09:04:00 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 19 Jan 2026 09:04:00 GMT Subject: RFR: 8375439: G1: Convert G1MonotonicArena class to use Atomic In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 08:53:00 GMT, Ivan Walulya wrote: >> Hi all, >> >> please review the change to use `Atomic` in `G1MonotonicArena`. >> >> Testing: gha >> >> Thanks, >> Thomas > > Marked as reviewed by iwalulya (Reviewer). Thanks @walulyai @stefank for your review ------------- PR Comment: https://git.openjdk.org/jdk/pull/29277#issuecomment-3767199796 From tschatzl at openjdk.org Mon Jan 19 09:09:22 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 19 Jan 2026 09:09:22 GMT Subject: Integrated: 8375439: G1: Convert G1MonotonicArena class to use Atomic In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 11:06:03 GMT, Thomas Schatzl wrote: > Hi all, > > please review the change to use `Atomic` in `G1MonotonicArena`. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 3e181485 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/3e181485709d108ef3d1e6b595fbd95ecc8ef74a Stats: 58 lines in 3 files changed: 1 ins; 2 del; 55 mod 8375439: G1: Convert G1MonotonicArena class to use Atomic Reviewed-by: stefank, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/29277 From sjohanss at openjdk.org Mon Jan 19 09:23:39 2026 From: sjohanss at openjdk.org (Stefan Johansson) Date: Mon, 19 Jan 2026 09:23:39 GMT Subject: RFR: 8238686: G1 may waste lots of space or fail to uncommit when observing MinHeapFreeRatio during sizing after full gc [v3] In-Reply-To: References: <2CtP_aXZRdMpMM7MerGDY2WYvgJks7YMVHlQEYgItZI=.50a0dd11-5f58-4780-9a63-55dfe921c03d@github.com> Message-ID: On Wed, 14 Jan 2026 11:58:01 GMT, Ivan Walulya wrote: >> Hi, >> >> Please review this change which modifies the defaults for the `MinHeapFreeRatio` and `MaxHeapFreeRatio` flags in G1 so that they do not affect heap sizing unless explicitly set by the user. >> >> Previously, these flags could trigger heap resizing at the end of Full GC, potentially overriding the G1 ergonomic heap sizing heuristics, which may be unexpected for the user. In particular, for workloads that frequently invoke `System.gc()`, the heap could shrink at the end of the Full GC and then expand aggressively during subsequent GCs (see image below). >> >> shrink_expand_flip_flop >> >> With this update, the default values for `MinHeapFreeRatio` and `MaxHeapFreeRatio` no longer affect heap resizing. These flags will only take effect when explicitly set by the user.. >> >> ~~Additionally, pause times from user-triggered `System.gc()` invocations will be excluded from the data used to update heap sizing heuristics. Because these GCs are user-initiated and do not reflect actual GC pressure, including their pause times can skew GC Pause Time ratios used for heap sizing decisions.~~ >> >> >> Testing: Tier 1 and JavaPerf. > > Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: > > Factor out change in flag defaults Marked as reviewed by sjohanss (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29137#pullrequestreview-3677088883 From iwalulya at openjdk.org Mon Jan 19 10:09:49 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 19 Jan 2026 10:09:49 GMT Subject: RFR: 8375463: G1: Remove AtomicAccess include from files that do not use it In-Reply-To: <9sWsyG0Hc1noL5OJDnEvn4guCbKwHCXvifd0OO_qg3A=.6551620f-f348-471e-b5e1-25c25dea8d77@github.com> References: <9sWsyG0Hc1noL5OJDnEvn4guCbKwHCXvifd0OO_qg3A=.6551620f-f348-471e-b5e1-25c25dea8d77@github.com> Message-ID: On Fri, 16 Jan 2026 11:06:26 GMT, Thomas Schatzl wrote: > Hi all, > > please review this trivial removal of unnecessary `AtomicAccess.hpp` includes. These files do not use any part of it. > > The one in `g1CardSetMemory.hpp` is handled in another PR. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29278#pullrequestreview-3677294524 From sjohanss at openjdk.org Mon Jan 19 11:40:18 2026 From: sjohanss at openjdk.org (Stefan Johansson) Date: Mon, 19 Jan 2026 11:40:18 GMT Subject: RFR: 8373253: Re-work InjectGCWorkerCreationFailure for future changes [v4] In-Reply-To: References: <78ejbDKfHkTR88XnHC2t975-zof6vMjdM_M_rTyB0pk=.d5c9798a-b1ca-4299-af35-2caaad2f8106@github.com> Message-ID: On Mon, 19 Jan 2026 08:39:09 GMT, Leo Korinth wrote: >> This PR slightly changes when we may `InjectGCWorkerCreationFailure`. At the moment we wait until `is_init_completed()`. I am changing this to instead be after `_created_workers > 0`. The reason is that we might in the future, https://bugs.openjdk.org/browse/JDK-8367993, create even more threads "on demand", and if so, we would fail VM creation if we inject worker creation failures after the VM is initiated but before we have created any of the worker threads. >> >> This change should not change the current behaviour. But help future improvements. >> >> I have tested this on `test/hotspot/jtreg/gc/stress/gcold/TestGCOldWithG1.java`, the only place where this flag is tested to my knowledge. > > Leo Korinth has updated the pull request incrementally with four additional commits since the last revision: > > - Proposal by Stefan J > - wip > - Revert "8373253: Re-work InjectGCWorkerCreationFailure for future changes" > > This reverts commit d45ea8817ab2303b2decd8cbb2cd1bf5280aa181. > - Revert "Fixup after comment from Ivan." > > This reverts commit 2aa8aa4b68027b62a8d4be1b86720fadfa48dda5. Marked as reviewed by sjohanss (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28719#pullrequestreview-3677660324 From tschatzl at openjdk.org Mon Jan 19 11:43:26 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 19 Jan 2026 11:43:26 GMT Subject: RFR: 8375620: G1: Convert G1CardTableClaimTable to use Atomic Message-ID: Hi all, please review this change to convert `G1CardTableClaimTable` to use `Atomic`. Testing: gha, Thanks, Thomas ------------- Commit messages: - 8375620 Changes: https://git.openjdk.org/jdk/pull/29297/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29297&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375620 Stats: 13 lines in 3 files changed: 1 ins; 1 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/29297.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29297/head:pull/29297 PR: https://git.openjdk.org/jdk/pull/29297 From tschatzl at openjdk.org Mon Jan 19 11:44:00 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 19 Jan 2026 11:44:00 GMT Subject: RFR: 8375622: G1: Convert G1CodeRootSet to use Atomic Message-ID: Hi all, please review this change to convert `G1CodeRootSet` to use `Atomic` instead of `AtomicAccess`. Testing: gha, Thanks, Thomas ------------- Commit messages: - 8375622 Changes: https://git.openjdk.org/jdk/pull/29296/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29296&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375622 Stats: 9 lines in 2 files changed: 1 ins; 1 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/29296.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29296/head:pull/29296 PR: https://git.openjdk.org/jdk/pull/29296 From tschatzl at openjdk.org Mon Jan 19 12:04:05 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 19 Jan 2026 12:04:05 GMT Subject: RFR: 8375626: G1: Convert G1CollectionSetChooser to use Atomic Message-ID: Hi all, please review this change to use `Atomic` for the `G1CollectionSetChooser` class. Testing: gha Thanks, Thomas ------------- Commit messages: - 8375626 Changes: https://git.openjdk.org/jdk/pull/29298/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29298&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375626 Stats: 11 lines in 2 files changed: 2 ins; 1 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/29298.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29298/head:pull/29298 PR: https://git.openjdk.org/jdk/pull/29298 From tschatzl at openjdk.org Mon Jan 19 12:06:04 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 19 Jan 2026 12:06:04 GMT Subject: RFR: 8375624: G1: Convert G1JavaThreadsListClaimer to use Atomic Message-ID: <5vi-2xWtcToPfEnbJyYdVpQJl6oAzkbx6LLXxKQqfcY=.2cd9a5a3-075e-4479-b6c1-83f81ca90162@github.com> Hi all, please review this change that makes `G1JavaThreadsListClaimer` use `Atomic` instead of `AtomicAccess'. Testing: gha Thanks, Thomas ------------- Commit messages: - 8375624 Changes: https://git.openjdk.org/jdk/pull/29299/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29299&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375624 Stats: 7 lines in 2 files changed: 1 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/29299.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29299/head:pull/29299 PR: https://git.openjdk.org/jdk/pull/29299 From stefank at openjdk.org Mon Jan 19 12:15:41 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 19 Jan 2026 12:15:41 GMT Subject: RFR: 8374695: ZGC: Convert zTLABUsage to use Atomic [v2] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 06:20:09 GMT, Axel Boldt-Christmas wrote: >> Convert usages of AtomicAccess to Atomic in zTLABUsage. >> >> Testing: >> * GHA >> * HotSpot GC tests with ZGC linux x64 and linux aarch64 > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Remove superfluous space Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29271#pullrequestreview-3677800671 From stefank at openjdk.org Mon Jan 19 12:32:56 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 19 Jan 2026 12:32:56 GMT Subject: RFR: 8373253: Re-work InjectGCWorkerCreationFailure for future changes [v4] In-Reply-To: References: <78ejbDKfHkTR88XnHC2t975-zof6vMjdM_M_rTyB0pk=.d5c9798a-b1ca-4299-af35-2caaad2f8106@github.com> Message-ID: On Mon, 19 Jan 2026 08:39:09 GMT, Leo Korinth wrote: >> This PR slightly changes when we may `InjectGCWorkerCreationFailure`. At the moment we wait until `is_init_completed()`. I am changing this to instead be after `_created_workers > 0`. The reason is that we might in the future, https://bugs.openjdk.org/browse/JDK-8367993, create even more threads "on demand", and if so, we would fail VM creation if we inject worker creation failures after the VM is initiated but before we have created any of the worker threads. >> >> This change should not change the current behaviour. But help future improvements. >> >> I have tested this on `test/hotspot/jtreg/gc/stress/gcold/TestGCOldWithG1.java`, the only place where this flag is tested to my knowledge. > > Leo Korinth has updated the pull request incrementally with four additional commits since the last revision: > > - Proposal by Stefan J > - wip > - Revert "8373253: Re-work InjectGCWorkerCreationFailure for future changes" > > This reverts commit d45ea8817ab2303b2decd8cbb2cd1bf5280aa181. > - Revert "Fixup after comment from Ivan." > > This reverts commit 2aa8aa4b68027b62a8d4be1b86720fadfa48dda5. Looks good to me. I have one suggestion that you could consider: I proposed the name `allow_creation_failure`, but on a second thought this might not be the best name. Maybe a more precise name would be `allow_inject_creation_failure. I'm leaving this up to you t decide if you agree or not. ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28719#pullrequestreview-3677868816 From lkorinth at openjdk.org Mon Jan 19 12:57:00 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 19 Jan 2026 12:57:00 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v3] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 12:58:43 GMT, Leo Korinth wrote: >> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. >> >> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. >> >> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. >> >> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. > > Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 564 commits: > > - Merge branch '8373253' into 8367993 > - Merge branch 'master' into _8373253 > - Merge branch 'master' into _8367993 > - 8366058: Outdated comment in WinCAPISeedGenerator > > Reviewed-by: mullan > - 8357258: x86: Improve receiver type profiling reliability > > Reviewed-by: kvn, vlivanov > - 8373704: Improve "SocketException: Protocol family unavailable" message > > Reviewed-by: lucy, jpai > - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently > > Reviewed-by: jiefu, jbhateja, erfang, qamai > - 8343809: Add requires tag to mark tests that are incompatible with exploded image > > Reviewed-by: alanb, dholmes > - 8374465: Spurious dot in documentation for JVMTI ClassLoad > > Reviewed-by: kbarrett > - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket > > Reviewed-by: djelinski, mpowers, ascarpino > - ... and 554 more: https://git.openjdk.org/jdk/compare/2aa8aa4b...28ccbb68 I just want to give an update that I look at a failure that I can not reproduce on Linux. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28723#issuecomment-3768201778 From tschatzl at openjdk.org Mon Jan 19 13:01:43 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 19 Jan 2026 13:01:43 GMT Subject: RFR: 8375463: G1: Remove AtomicAccess include from files that do not use it In-Reply-To: References: <9sWsyG0Hc1noL5OJDnEvn4guCbKwHCXvifd0OO_qg3A=.6551620f-f348-471e-b5e1-25c25dea8d77@github.com> Message-ID: <5dTfXY-00aNR3swUTK-FSdur-mZ7AAWoA3cOSWo8VTo=.e3d67573-857d-45db-83c9-ec041228b2e8@github.com> On Mon, 19 Jan 2026 10:07:30 GMT, Ivan Walulya wrote: >> Hi all, >> >> please review this trivial removal of unnecessary `AtomicAccess.hpp` includes. These files do not use any part of it. >> >> The one in `g1CardSetMemory.hpp` is handled in another PR. >> >> Testing: gha >> >> Thanks, >> Thomas > > Marked as reviewed by iwalulya (Reviewer). Thanks @walulyai @stefank for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/29278#issuecomment-3768212266 From tschatzl at openjdk.org Mon Jan 19 13:01:44 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 19 Jan 2026 13:01:44 GMT Subject: Integrated: 8375463: G1: Remove AtomicAccess include from files that do not use it In-Reply-To: <9sWsyG0Hc1noL5OJDnEvn4guCbKwHCXvifd0OO_qg3A=.6551620f-f348-471e-b5e1-25c25dea8d77@github.com> References: <9sWsyG0Hc1noL5OJDnEvn4guCbKwHCXvifd0OO_qg3A=.6551620f-f348-471e-b5e1-25c25dea8d77@github.com> Message-ID: On Fri, 16 Jan 2026 11:06:26 GMT, Thomas Schatzl wrote: > Hi all, > > please review this trivial removal of unnecessary `AtomicAccess.hpp` includes. These files do not use any part of it. > > The one in `g1CardSetMemory.hpp` is handled in another PR. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: e0edc656 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/e0edc656240d18b4468212c38f136084a50be301 Stats: 12 lines in 7 files changed: 0 ins; 7 del; 5 mod 8375463: G1: Remove AtomicAccess include from files that do not use it Reviewed-by: stefank, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/29278 From lkorinth at openjdk.org Mon Jan 19 13:31:44 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 19 Jan 2026 13:31:44 GMT Subject: RFR: 8373253: Re-work InjectGCWorkerCreationFailure for future changes [v5] In-Reply-To: <78ejbDKfHkTR88XnHC2t975-zof6vMjdM_M_rTyB0pk=.d5c9798a-b1ca-4299-af35-2caaad2f8106@github.com> References: <78ejbDKfHkTR88XnHC2t975-zof6vMjdM_M_rTyB0pk=.d5c9798a-b1ca-4299-af35-2caaad2f8106@github.com> Message-ID: > This PR slightly changes when we may `InjectGCWorkerCreationFailure`. At the moment we wait until `is_init_completed()`. I am changing this to instead be after `_created_workers > 0`. The reason is that we might in the future, https://bugs.openjdk.org/browse/JDK-8367993, create even more threads "on demand", and if so, we would fail VM creation if we inject worker creation failures after the VM is initiated but before we have created any of the worker threads. > > This change should not change the current behaviour. But help future improvements. > > I have tested this on `test/hotspot/jtreg/gc/stress/gcold/TestGCOldWithG1.java`, the only place where this flag is tested to my knowledge. Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: rename of method ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28719/files - new: https://git.openjdk.org/jdk/pull/28719/files/5703deb1..7aa1f7e8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28719&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28719&range=03-04 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28719.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28719/head:pull/28719 PR: https://git.openjdk.org/jdk/pull/28719 From stefank at openjdk.org Mon Jan 19 13:31:45 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 19 Jan 2026 13:31:45 GMT Subject: RFR: 8373253: Re-work InjectGCWorkerCreationFailure for future changes [v5] In-Reply-To: References: <78ejbDKfHkTR88XnHC2t975-zof6vMjdM_M_rTyB0pk=.d5c9798a-b1ca-4299-af35-2caaad2f8106@github.com> Message-ID: On Mon, 19 Jan 2026 13:27:24 GMT, Leo Korinth wrote: >> This PR slightly changes when we may `InjectGCWorkerCreationFailure`. At the moment we wait until `is_init_completed()`. I am changing this to instead be after `_created_workers > 0`. The reason is that we might in the future, https://bugs.openjdk.org/browse/JDK-8367993, create even more threads "on demand", and if so, we would fail VM creation if we inject worker creation failures after the VM is initiated but before we have created any of the worker threads. >> >> This change should not change the current behaviour. But help future improvements. >> >> I have tested this on `test/hotspot/jtreg/gc/stress/gcold/TestGCOldWithG1.java`, the only place where this flag is tested to my knowledge. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > rename of method Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28719#pullrequestreview-3678088509 From kdnilsen at openjdk.org Mon Jan 19 14:55:19 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 19 Jan 2026 14:55:19 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v33] In-Reply-To: References: Message-ID: > Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). > > This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. > > The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. > > ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) > > With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. > > ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) > > At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. > > ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) > > The command line for these comparisons follows: > > > ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jdk/bin/java \ > -XX:+Unlock... Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: remove debug instrumentation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25357/files - new: https://git.openjdk.org/jdk/pull/25357/files/e7cf9541..5b6ae5c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=32 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=31-32 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25357/head:pull/25357 PR: https://git.openjdk.org/jdk/pull/25357 From tschatzl at openjdk.org Mon Jan 19 15:14:42 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 19 Jan 2026 15:14:42 GMT Subject: RFR: 8375630: G1: Convert G1ConcurrentMark to use Atomic Message-ID: <3mZAg_h4VMGfFSQxHPCKuu8Xcd6j69EFyuZHbsB0WiU=.51d855f1-3de0-48a6-8629-644613292af6@github.com> Hi all, please review this change to `G1ConcurrentMark` to use `Atomic`. Testing: gha Thanks, Thomas ------------- Commit messages: - 8375630 Changes: https://git.openjdk.org/jdk/pull/29300/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29300&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375630 Stats: 19 lines in 2 files changed: 1 ins; 1 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/29300.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29300/head:pull/29300 PR: https://git.openjdk.org/jdk/pull/29300 From shade at openjdk.org Mon Jan 19 15:40:26 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 19 Jan 2026 15:40:26 GMT Subject: RFR: 8375622: G1: Convert G1CodeRootSet to use Atomic In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 11:35:39 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to convert `G1CodeRootSet` to use `Atomic` instead of `AtomicAccess`. > > Testing: gha, > > Thanks, > Thomas Looks fine with nit. src/hotspot/share/gc/g1/g1CodeRootSet.hpp line 29: > 27: > 28: #include "code/codeCache.hpp" > 29: #include "runtime/atomic.hpp" Yeah, but why here? The `Atomic` is fully in `.cpp`, so better include in there, instead of (potentially popular) header? ------------- PR Review: https://git.openjdk.org/jdk/pull/29296#pullrequestreview-3678649724 PR Review Comment: https://git.openjdk.org/jdk/pull/29296#discussion_r2705247477 From kdnilsen at openjdk.org Mon Jan 19 16:33:10 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 19 Jan 2026 16:33:10 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v12] In-Reply-To: References: Message-ID: > After studying large numbers of GC logs with degenerated cycles that have resulted from "late" triggers, we propose the following general improvements: > > 1. Track trends in GC times rather than always using the average GC time plus standard deviation. In many situations, GC times trend upward due to, for example, increasing amounts of live data that must be marked as a workload builds up its working set of memory. > 2. Sample allocation rates more frequently than once every 100 ms. > 3. Track trends in allocation rates. In some situations, the allocation rate trends upwards due to, for example, the start of a new phase of execution or a spike in client workload. > 4. When we detect acceleration of allocation rate, predict consumption of memory based on accelerated allocation rates rather than assuming constant allocation rate. Kelvin Nilsen has updated the pull request incrementally with two additional commits since the last revision: - Insert instrumentation to diagnose bad scheduling decisions - Revert "reorder trigger evaulation" This reverts commit 19cd3dd60f26fef9e15b39c3ee54b121452f888b. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29039/files - new: https://git.openjdk.org/jdk/pull/29039/files/19cd3dd6..80868d82 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=10-11 Stats: 322 lines in 2 files changed: 266 ins; 54 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29039.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29039/head:pull/29039 PR: https://git.openjdk.org/jdk/pull/29039 From tschatzl at openjdk.org Mon Jan 19 17:03:40 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 19 Jan 2026 17:03:40 GMT Subject: RFR: 8375643: G1: Convert G1RegionMarkStatsCache to use Atomic Message-ID: <52JFJVawH8TfssAKR4-8UlrNL-_kzoAFp4Lc6dhBu8s=.fa54fcef-4cd2-4aab-80f6-53d816e9b0ff@github.com> Hi all, please review this change to make `G1RegionMarkStatsCache` use `Atomic`. The only unusual part is that I added two getters to that class to avoid the repeated `.load_relaxed()` typing. Testing: gha Thanks, Thomas ------------- Commit messages: - 8375643 Changes: https://git.openjdk.org/jdk/pull/29303/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29303&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375643 Stats: 25 lines in 4 files changed: 4 ins; 2 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/29303.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29303/head:pull/29303 PR: https://git.openjdk.org/jdk/pull/29303 From kbarrett at openjdk.org Mon Jan 19 18:22:32 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 19 Jan 2026 18:22:32 GMT Subject: RFR: 8375643: G1: Convert G1RegionMarkStatsCache to use Atomic In-Reply-To: <52JFJVawH8TfssAKR4-8UlrNL-_kzoAFp4Lc6dhBu8s=.fa54fcef-4cd2-4aab-80f6-53d816e9b0ff@github.com> References: <52JFJVawH8TfssAKR4-8UlrNL-_kzoAFp4Lc6dhBu8s=.fa54fcef-4cd2-4aab-80f6-53d816e9b0ff@github.com> Message-ID: On Mon, 19 Jan 2026 16:56:09 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to make `G1RegionMarkStatsCache` use `Atomic`. > > The only unusual part is that I added two getters to that class to avoid the repeated `.load_relaxed()` typing. > > Testing: gha > > Thanks, > Thomas Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29303#pullrequestreview-3679205978 From kbarrett at openjdk.org Mon Jan 19 18:58:21 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 19 Jan 2026 18:58:21 GMT Subject: RFR: 8375630: G1: Convert G1ConcurrentMark to use Atomic In-Reply-To: <3mZAg_h4VMGfFSQxHPCKuu8Xcd6j69EFyuZHbsB0WiU=.51d855f1-3de0-48a6-8629-644613292af6@github.com> References: <3mZAg_h4VMGfFSQxHPCKuu8Xcd6j69EFyuZHbsB0WiU=.51d855f1-3de0-48a6-8629-644613292af6@github.com> Message-ID: <7YWD-zxT3l5nqh03_eKIItWKZNKaHwfE-tmYlTzenA8=.e41b5997-e39b-4f25-b925-5bdeb3f86afc@github.com> On Mon, 19 Jan 2026 13:25:48 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to `G1ConcurrentMark` to use `Atomic`. > > Testing: gha > > Thanks, > Thomas Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29300#pullrequestreview-3679279757 From kbarrett at openjdk.org Mon Jan 19 19:06:30 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 19 Jan 2026 19:06:30 GMT Subject: RFR: 8375624: G1: Convert G1JavaThreadsListClaimer to use Atomic In-Reply-To: <5vi-2xWtcToPfEnbJyYdVpQJl6oAzkbx6LLXxKQqfcY=.2cd9a5a3-075e-4479-b6c1-83f81ca90162@github.com> References: <5vi-2xWtcToPfEnbJyYdVpQJl6oAzkbx6LLXxKQqfcY=.2cd9a5a3-075e-4479-b6c1-83f81ca90162@github.com> Message-ID: <6SKSb7VfR4knLOXoARLVMQYP3-58I_HIznh7eMk_lGM=.8496152c-c5ed-4a4c-a36b-712e547b2c95@github.com> On Mon, 19 Jan 2026 11:58:13 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that makes `G1JavaThreadsListClaimer` use `Atomic` instead of `AtomicAccess'. > > Testing: gha > > Thanks, > Thomas Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29299#pullrequestreview-3679295203 From kbarrett at openjdk.org Mon Jan 19 19:10:34 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 19 Jan 2026 19:10:34 GMT Subject: RFR: 8375626: G1: Convert G1CollectionSetChooser to use Atomic In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 11:56:19 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to use `Atomic` for the `G1CollectionSetChooser` class. > > Testing: gha > > Thanks, > Thomas Changes requested by kbarrett (Reviewer). src/hotspot/share/gc/g1/g1CollectionSetChooser.hpp line 31: > 29: #include "gc/shared/gc_globals.hpp" > 30: #include "memory/allStatic.hpp" > 31: #include "runtime/atomic.hpp" atomic isn't used in the header, only the the .cpp. Add to the latter instead. That makes this file unmodified, so no need to update copyright either. ------------- PR Review: https://git.openjdk.org/jdk/pull/29298#pullrequestreview-3679299325 PR Review Comment: https://git.openjdk.org/jdk/pull/29298#discussion_r2705832473 From kbarrett at openjdk.org Mon Jan 19 19:13:38 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 19 Jan 2026 19:13:38 GMT Subject: RFR: 8373894: G1: Count evacuation-failed garbage collections in gc cpu usage In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 13:51:24 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that makes evacuation failed garbage collections count in the gc CPU usage calculations. > > The reason is that currently (since forever), G1 considers garbage collections that experience an evacuation failure to not count in the cpu usage calculations. > > (Afair this has been introduced because the previously extremely slow evacuation failures would impact cpu usage based calculations too much even if very infrequent. For many releases evacuation failure handling is at least parallel and in the same order of magnitude wrt to performance). > > This can cause significant distortions in GC behavior. > > In the worst case, if for some reason all garbage collections experience evacuation failure, gc cpu usage (at least for the young gen evacuation pauses) is considered as (close to) zero, with repercussions on heap sizing. > > Testing: tier1-5 multiple times to find tests that fail because of the UseGCOverheadLimit flag and fix them adding `-XX:-UseGCOverheadLimit` > > Thanks, > Thomas Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29115#pullrequestreview-3679307237 From kbarrett at openjdk.org Tue Jan 20 04:30:27 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 20 Jan 2026 04:30:27 GMT Subject: RFR: 8375620: G1: Convert G1CardTableClaimTable to use Atomic In-Reply-To: References: Message-ID: <_xpa-s8yIZ3rgpIsu32ostMtWzSkOYTaY0hnX8zpvM8=.0e214faf-bed6-4425-bfc7-477abdf15c60@github.com> On Mon, 19 Jan 2026 11:35:48 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to convert `G1CardTableClaimTable` to use `Atomic`. > > Testing: gha, > > Thanks, > Thomas Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29297#pullrequestreview-3680300202 From kbarrett at openjdk.org Tue Jan 20 04:45:11 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 20 Jan 2026 04:45:11 GMT Subject: RFR: 8375436: G1: Convert G1CardSet classes to use Atomic In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 09:31:59 GMT, Thomas Schatzl wrote: > Hi all, > > please review this removal of use of the AtomicAccess class in G1 card set related classes, replacing with use of Atomic. > > Although a bit on the large side, it would be hard to do the card set changes separately per class. Other than that I think it is fairly straightforward, except for the addition of a copy constructor for `G1CardSetHashTableValue` because the `ConcurrentHashTable` requires it. > > Testing: gha > > Thanks, > Thomas Looks good, but for one trivial whitespace issue. src/hotspot/share/gc/g1/g1CardSet.hpp line 158: > 156: private: > 157: // Indices are "from" indices. > 158: Atomic_coarsen_from[NumCoarsenCategories]; Missing space between type an variable. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29274#pullrequestreview-3680310484 PR Review Comment: https://git.openjdk.org/jdk/pull/29274#discussion_r2706721901 From tschatzl at openjdk.org Tue Jan 20 08:04:26 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 20 Jan 2026 08:04:26 GMT Subject: RFR: 8373894: G1: Count evacuation-failed garbage collections in gc cpu usage In-Reply-To: <-HiKmD5SHw5cWaPBZxfcDB4dGKnuGFJeTKCJfWB4GCs=.6bfa7d13-4ac3-4dfa-a014-57b51243a5d0@github.com> References: <-HiKmD5SHw5cWaPBZxfcDB4dGKnuGFJeTKCJfWB4GCs=.6bfa7d13-4ac3-4dfa-a014-57b51243a5d0@github.com> Message-ID: <3BJsJ5OKSSfvy-Z3dfYaC-UP8NUCKwITOM0szk3v5Jw=.1eb94ffe-0efc-44be-9500-aa6aa06690fa@github.com> On Mon, 19 Jan 2026 08:42:07 GMT, Ivan Walulya wrote: >> Hi all, >> >> please review this change that makes evacuation failed garbage collections count in the gc CPU usage calculations. >> >> The reason is that currently (since forever), G1 considers garbage collections that experience an evacuation failure to not count in the cpu usage calculations. >> >> (Afair this has been introduced because the previously extremely slow evacuation failures would impact cpu usage based calculations too much even if very infrequent. For many releases evacuation failure handling is at least parallel and in the same order of magnitude wrt to performance). >> >> This can cause significant distortions in GC behavior. >> >> In the worst case, if for some reason all garbage collections experience evacuation failure, gc cpu usage (at least for the young gen evacuation pauses) is considered as (close to) zero, with repercussions on heap sizing. >> >> Testing: tier1-5 multiple times to find tests that fail because of the UseGCOverheadLimit flag and fix them adding `-XX:-UseGCOverheadLimit` >> >> Thanks, >> Thomas > > Nit: > > A comment in the PR about the changes in the test would have been helpful. Thanks @walulyai @kimbarrett for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/29115#issuecomment-3771540055 From tschatzl at openjdk.org Tue Jan 20 08:04:27 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 20 Jan 2026 08:04:27 GMT Subject: Integrated: 8373894: G1: Count evacuation-failed garbage collections in gc cpu usage In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 13:51:24 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that makes evacuation failed garbage collections count in the gc CPU usage calculations. > > The reason is that currently (since forever), G1 considers garbage collections that experience an evacuation failure to not count in the cpu usage calculations. > > (Afair this has been introduced because the previously extremely slow evacuation failures would impact cpu usage based calculations too much even if very infrequent. For many releases evacuation failure handling is at least parallel and in the same order of magnitude wrt to performance). > > This can cause significant distortions in GC behavior. > > In the worst case, if for some reason all garbage collections experience evacuation failure, gc cpu usage (at least for the young gen evacuation pauses) is considered as (close to) zero, with repercussions on heap sizing. > > Testing: tier1-5 multiple times to find tests that fail because of the UseGCOverheadLimit flag and fix them adding `-XX:-UseGCOverheadLimit` > > Thanks, > Thomas This pull request has now been integrated. Changeset: d9db4fb3 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/d9db4fb36e4f90546dc3fc19b5923b8be6a2f518 Stats: 13 lines in 3 files changed: 0 ins; 4 del; 9 mod 8373894: G1: Count evacuation-failed garbage collections in gc cpu usage Reviewed-by: iwalulya, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/29115 From tschatzl at openjdk.org Tue Jan 20 08:06:04 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 20 Jan 2026 08:06:04 GMT Subject: RFR: 8375436: G1: Convert G1CardSet classes to use Atomic [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review this removal of use of the AtomicAccess class in G1 card set related classes, replacing with use of Atomic. > > Although a bit on the large side, it would be hard to do the card set changes separately per class. Other than that I think it is fairly straightforward, except for the addition of a copy constructor for `G1CardSetHashTableValue` because the `ConcurrentHashTable` requires it. > > Testing: gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * kbarrett review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29274/files - new: https://git.openjdk.org/jdk/pull/29274/files/35b924d7..a697555b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29274&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29274&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29274.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29274/head:pull/29274 PR: https://git.openjdk.org/jdk/pull/29274 From tschatzl at openjdk.org Tue Jan 20 08:07:32 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 20 Jan 2026 08:07:32 GMT Subject: RFR: 8375622: G1: Convert G1CodeRootSet to use Atomic In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 15:37:35 GMT, Aleksey Shipilev wrote: >> Hi all, >> >> please review this change to convert `G1CodeRootSet` to use `Atomic` instead of `AtomicAccess`. >> >> Testing: gha, >> >> Thanks, >> Thomas > > src/hotspot/share/gc/g1/g1CodeRootSet.hpp line 29: > >> 27: >> 28: #include "code/codeCache.hpp" >> 29: #include "runtime/atomic.hpp" > > Yeah, but why here? The `Atomic` is fully in `.cpp`, so better include in there, instead of (potentially popular) header? Because of mechanical conversion, no particular intent. Will fix. :( ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29296#discussion_r2707212126 From tschatzl at openjdk.org Tue Jan 20 08:07:50 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 20 Jan 2026 08:07:50 GMT Subject: RFR: 8375626: G1: Convert G1CollectionSetChooser to use Atomic [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review this change to use `Atomic` for the `G1CollectionSetChooser` class. > > Testing: gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * kbarrett review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29298/files - new: https://git.openjdk.org/jdk/pull/29298/files/6a29e1cf..e8ce53a5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29298&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29298&range=00-01 Stats: 3 lines in 2 files changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29298.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29298/head:pull/29298 PR: https://git.openjdk.org/jdk/pull/29298 From tschatzl at openjdk.org Tue Jan 20 08:09:55 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 20 Jan 2026 08:09:55 GMT Subject: RFR: 8375622: G1: Convert G1CodeRootSet to use Atomic [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review this change to convert `G1CodeRootSet` to use `Atomic` instead of `AtomicAccess`. > > Testing: gha, > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * shade review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29296/files - new: https://git.openjdk.org/jdk/pull/29296/files/b76b4df8..ce402ea6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29296&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29296&range=00-01 Stats: 3 lines in 2 files changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29296.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29296/head:pull/29296 PR: https://git.openjdk.org/jdk/pull/29296 From tschatzl at openjdk.org Tue Jan 20 08:23:49 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 20 Jan 2026 08:23:49 GMT Subject: RFR: 8375541: G1: Race in G1BarrierSet::write_ref_field_post() Message-ID: Hi all, during conversion of card table code to use `Atomic` I think I found the following error: the code in `G1BarrierSet::write_ref_field_post` is wrong in that it allows reload of the `_card_table` value, which is exactly what the existing code imo wrongly fails to ensure. even if it does not, making the load explicit improves reading. To not let this change get lost in that conversion, and potentially for backport to 26, I factored it out in this change. There is no known issue caused by this code in particular, one other bug I'm working on that just looks like what could be caused by this is not fixed. Testing: gha Thanks, Thomas ------------- Commit messages: - 8375541 Changes: https://git.openjdk.org/jdk/pull/29311/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29311&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375541 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29311.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29311/head:pull/29311 PR: https://git.openjdk.org/jdk/pull/29311 From shade at openjdk.org Tue Jan 20 09:29:35 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 20 Jan 2026 09:29:35 GMT Subject: RFR: 8375622: G1: Convert G1CodeRootSet to use Atomic [v2] In-Reply-To: References: Message-ID: <-4f_Z6IzL4pG8lzz2tPUfPh7Sv1jgJVZgFKH4sEoO6A=.eb42f930-6ac3-44d3-905e-79b5a4edc622@github.com> On Tue, 20 Jan 2026 08:09:55 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change to convert `G1CodeRootSet` to use `Atomic` instead of `AtomicAccess`. >> >> Testing: gha, >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * shade review Looks good! I think your other PRs also suffer from the same include oddity. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29296#pullrequestreview-3681191955 From lkorinth at openjdk.org Tue Jan 20 09:33:01 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 20 Jan 2026 09:33:01 GMT Subject: RFR: 8373253: Re-work InjectGCWorkerCreationFailure for future changes [v5] In-Reply-To: References: <78ejbDKfHkTR88XnHC2t975-zof6vMjdM_M_rTyB0pk=.d5c9798a-b1ca-4299-af35-2caaad2f8106@github.com> Message-ID: On Mon, 19 Jan 2026 13:31:44 GMT, Leo Korinth wrote: >> This PR slightly changes when we may `InjectGCWorkerCreationFailure`. At the moment we wait until `is_init_completed()`. I am changing this to instead be after `_created_workers > 0`. The reason is that we might in the future, https://bugs.openjdk.org/browse/JDK-8367993, create even more threads "on demand", and if so, we would fail VM creation if we inject worker creation failures after the VM is initiated but before we have created any of the worker threads. >> >> This change should not change the current behaviour. But help future improvements. >> >> I have tested this on `test/hotspot/jtreg/gc/stress/gcold/TestGCOldWithG1.java`, the only place where this flag is tested to my knowledge. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > rename of method Thanks everyone for your reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28719#issuecomment-3771882921 From lkorinth at openjdk.org Tue Jan 20 09:33:03 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 20 Jan 2026 09:33:03 GMT Subject: Integrated: 8373253: Re-work InjectGCWorkerCreationFailure for future changes In-Reply-To: <78ejbDKfHkTR88XnHC2t975-zof6vMjdM_M_rTyB0pk=.d5c9798a-b1ca-4299-af35-2caaad2f8106@github.com> References: <78ejbDKfHkTR88XnHC2t975-zof6vMjdM_M_rTyB0pk=.d5c9798a-b1ca-4299-af35-2caaad2f8106@github.com> Message-ID: On Tue, 9 Dec 2025 13:39:54 GMT, Leo Korinth wrote: > This PR slightly changes when we may `InjectGCWorkerCreationFailure`. At the moment we wait until `is_init_completed()`. I am changing this to instead be after `_created_workers > 0`. The reason is that we might in the future, https://bugs.openjdk.org/browse/JDK-8367993, create even more threads "on demand", and if so, we would fail VM creation if we inject worker creation failures after the VM is initiated but before we have created any of the worker threads. > > This change should not change the current behaviour. But help future improvements. > > I have tested this on `test/hotspot/jtreg/gc/stress/gcold/TestGCOldWithG1.java`, the only place where this flag is tested to my knowledge. This pull request has now been integrated. Changeset: c5f288e2 Author: Leo Korinth URL: https://git.openjdk.org/jdk/commit/c5f288e2ae2ebe6ee4a0d39d91348f746bd0e353 Stats: 16 lines in 2 files changed: 15 ins; 0 del; 1 mod 8373253: Re-work InjectGCWorkerCreationFailure for future changes Reviewed-by: stefank, tschatzl, iwalulya, sjohanss ------------- PR: https://git.openjdk.org/jdk/pull/28719 From shade at openjdk.org Tue Jan 20 10:02:31 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 20 Jan 2026 10:02:31 GMT Subject: RFR: 8375626: G1: Convert G1CollectionSetChooser to use Atomic [v2] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 08:07:50 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change to use `Atomic` for the `G1CollectionSetChooser` class. >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * kbarrett review Looks right. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29298#pullrequestreview-3681344363 From shade at openjdk.org Tue Jan 20 10:04:05 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 20 Jan 2026 10:04:05 GMT Subject: RFR: 8375620: G1: Convert G1CardTableClaimTable to use Atomic In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 11:35:48 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to convert `G1CardTableClaimTable` to use `Atomic`. > > Testing: gha, > > Thanks, > Thomas Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29297#pullrequestreview-3681347926 From shade at openjdk.org Tue Jan 20 10:04:07 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 20 Jan 2026 10:04:07 GMT Subject: RFR: 8375624: G1: Convert G1JavaThreadsListClaimer to use Atomic In-Reply-To: <5vi-2xWtcToPfEnbJyYdVpQJl6oAzkbx6LLXxKQqfcY=.2cd9a5a3-075e-4479-b6c1-83f81ca90162@github.com> References: <5vi-2xWtcToPfEnbJyYdVpQJl6oAzkbx6LLXxKQqfcY=.2cd9a5a3-075e-4479-b6c1-83f81ca90162@github.com> Message-ID: On Mon, 19 Jan 2026 11:58:13 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that makes `G1JavaThreadsListClaimer` use `Atomic` instead of `AtomicAccess'. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29299#pullrequestreview-3681349930 From shade at openjdk.org Tue Jan 20 10:04:37 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 20 Jan 2026 10:04:37 GMT Subject: RFR: 8375630: G1: Convert G1ConcurrentMark to use Atomic In-Reply-To: <3mZAg_h4VMGfFSQxHPCKuu8Xcd6j69EFyuZHbsB0WiU=.51d855f1-3de0-48a6-8629-644613292af6@github.com> References: <3mZAg_h4VMGfFSQxHPCKuu8Xcd6j69EFyuZHbsB0WiU=.51d855f1-3de0-48a6-8629-644613292af6@github.com> Message-ID: On Mon, 19 Jan 2026 13:25:48 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to `G1ConcurrentMark` to use `Atomic`. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29300#pullrequestreview-3681353001 From shade at openjdk.org Tue Jan 20 10:25:20 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 20 Jan 2026 10:25:20 GMT Subject: RFR: 8375643: G1: Convert G1RegionMarkStatsCache to use Atomic In-Reply-To: <52JFJVawH8TfssAKR4-8UlrNL-_kzoAFp4Lc6dhBu8s=.fa54fcef-4cd2-4aab-80f6-53d816e9b0ff@github.com> References: <52JFJVawH8TfssAKR4-8UlrNL-_kzoAFp4Lc6dhBu8s=.fa54fcef-4cd2-4aab-80f6-53d816e9b0ff@github.com> Message-ID: On Mon, 19 Jan 2026 16:56:09 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to make `G1RegionMarkStatsCache` use `Atomic`. > > The only unusual part is that I added two getters to that class to avoid the repeated `.load_relaxed()` typing. > > Testing: gha > > Thanks, > Thomas Questions... src/hotspot/share/gc/g1/g1RegionMarkStatsCache.hpp line 119: > 117: void add_live_words(uint region_idx, size_t live_words) { > 118: G1RegionMarkStatsCacheEntry* const cur = find_for_add(region_idx); > 119: cur->_stats._live_words.store_relaxed(cur->_stats.live_words() + live_words); Is this just `add_then_fetch` with `memory_order_relaxed` then? Or are we trying to dodge some performance penalty avoiding the atomic RMW instructions? I suspect x86 still implicitly does CAS memory effects when doing `cmpxchg` on memory location; `memory_order_relaxed` would not help there. src/hotspot/share/gc/g1/g1RegionMarkStatsCache.hpp line 124: > 122: void inc_incoming_refs(uint region_idx) { > 123: G1RegionMarkStatsCacheEntry* const cur = find_for_add(region_idx); > 124: cur->_stats._incoming_refs.store_relaxed(cur->_stats.incoming_refs() + 1u); Same, `add_then_fetch`? ------------- PR Review: https://git.openjdk.org/jdk/pull/29303#pullrequestreview-3681419236 PR Review Comment: https://git.openjdk.org/jdk/pull/29303#discussion_r2707686756 PR Review Comment: https://git.openjdk.org/jdk/pull/29303#discussion_r2707687279 From shade at openjdk.org Tue Jan 20 10:25:21 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 20 Jan 2026 10:25:21 GMT Subject: RFR: 8375643: G1: Convert G1RegionMarkStatsCache to use Atomic In-Reply-To: References: <52JFJVawH8TfssAKR4-8UlrNL-_kzoAFp4Lc6dhBu8s=.fa54fcef-4cd2-4aab-80f6-53d816e9b0ff@github.com> Message-ID: On Tue, 20 Jan 2026 10:16:18 GMT, Aleksey Shipilev wrote: >> Hi all, >> >> please review this change to make `G1RegionMarkStatsCache` use `Atomic`. >> >> The only unusual part is that I added two getters to that class to avoid the repeated `.load_relaxed()` typing. >> >> Testing: gha >> >> Thanks, >> Thomas > > src/hotspot/share/gc/g1/g1RegionMarkStatsCache.hpp line 119: > >> 117: void add_live_words(uint region_idx, size_t live_words) { >> 118: G1RegionMarkStatsCacheEntry* const cur = find_for_add(region_idx); >> 119: cur->_stats._live_words.store_relaxed(cur->_stats.live_words() + live_words); > > Is this just `add_then_fetch` with `memory_order_relaxed` then? Or are we trying to dodge some performance penalty avoiding the atomic RMW instructions? I suspect x86 still implicitly does CAS memory effects when doing `cmpxchg` on memory location; `memory_order_relaxed` would not help there. Actually, what _are_ the atomicity requirements here? Is this code supposed to be called on same region stats by multiple threads? Or is this single threaded? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29303#discussion_r2707705008 From iwalulya at openjdk.org Tue Jan 20 10:26:23 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 20 Jan 2026 10:26:23 GMT Subject: RFR: 8340470: G1: Adopt PartialArrayState to consolidate marking stack in Full GC [v5] In-Reply-To: References: Message-ID: > Hi, > > Please review this change adopting `PartialArrayState` introduced by [JDK-8337709](https://bugs.openjdk.org/browse/JDK-8337709) to consolidate marking queue sets (oop queue set and objArray queue set) into single queue set in G1 Full GC. > > Testing: Tier 1-5 Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: kstefanj refactor rename ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29114/files - new: https://git.openjdk.org/jdk/pull/29114/files/ab200f8b..32e2aa0d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29114&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29114&range=03-04 Stats: 21 lines in 6 files changed: 0 ins; 0 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/29114.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29114/head:pull/29114 PR: https://git.openjdk.org/jdk/pull/29114 From tschatzl at openjdk.org Tue Jan 20 10:34:09 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 20 Jan 2026 10:34:09 GMT Subject: RFR: 8375620: G1: Convert G1CardTableClaimTable to use Atomic In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 10:01:14 GMT, Aleksey Shipilev wrote: >> Hi all, >> >> please review this change to convert `G1CardTableClaimTable` to use `Atomic`. >> >> Testing: gha, >> >> Thanks, >> Thomas > > Marked as reviewed by shade (Reviewer). Thanks @shipilev @kimbarrett for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/29297#issuecomment-3772156691 From tschatzl at openjdk.org Tue Jan 20 10:34:11 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 20 Jan 2026 10:34:11 GMT Subject: Integrated: 8375620: G1: Convert G1CardTableClaimTable to use Atomic In-Reply-To: References: Message-ID: <3zGbtuYb-ybSzkjjBJMB1quNdzcNVqfrVl2Mjqwnh8s=.80ef233a-c7f4-49fc-b80f-8117210d7909@github.com> On Mon, 19 Jan 2026 11:35:48 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to convert `G1CardTableClaimTable` to use `Atomic`. > > Testing: gha, > > Thanks, > Thomas This pull request has now been integrated. Changeset: afbb3a04 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/afbb3a041545ea11ee1514d329c1a6cc4cb969d2 Stats: 13 lines in 3 files changed: 1 ins; 1 del; 11 mod 8375620: G1: Convert G1CardTableClaimTable to use Atomic Reviewed-by: kbarrett, shade ------------- PR: https://git.openjdk.org/jdk/pull/29297 From tschatzl at openjdk.org Tue Jan 20 10:35:02 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 20 Jan 2026 10:35:02 GMT Subject: RFR: 8375630: G1: Convert G1ConcurrentMark to use Atomic In-Reply-To: References: <3mZAg_h4VMGfFSQxHPCKuu8Xcd6j69EFyuZHbsB0WiU=.51d855f1-3de0-48a6-8629-644613292af6@github.com> Message-ID: On Tue, 20 Jan 2026 10:02:26 GMT, Aleksey Shipilev wrote: >> Hi all, >> >> please review this change to `G1ConcurrentMark` to use `Atomic`. >> >> Testing: gha >> >> Thanks, >> Thomas > > Marked as reviewed by shade (Reviewer). Thanks @shipilev @kimbarrett for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/29300#issuecomment-3772163577 From tschatzl at openjdk.org Tue Jan 20 10:37:52 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 20 Jan 2026 10:37:52 GMT Subject: Integrated: 8375630: G1: Convert G1ConcurrentMark to use Atomic In-Reply-To: <3mZAg_h4VMGfFSQxHPCKuu8Xcd6j69EFyuZHbsB0WiU=.51d855f1-3de0-48a6-8629-644613292af6@github.com> References: <3mZAg_h4VMGfFSQxHPCKuu8Xcd6j69EFyuZHbsB0WiU=.51d855f1-3de0-48a6-8629-644613292af6@github.com> Message-ID: On Mon, 19 Jan 2026 13:25:48 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to `G1ConcurrentMark` to use `Atomic`. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: fe102918 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/fe102918dd4f33ba030c4c4301a676ac8497fd90 Stats: 19 lines in 2 files changed: 1 ins; 1 del; 17 mod 8375630: G1: Convert G1ConcurrentMark to use Atomic Reviewed-by: kbarrett, shade ------------- PR: https://git.openjdk.org/jdk/pull/29300 From tschatzl at openjdk.org Tue Jan 20 10:37:56 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 20 Jan 2026 10:37:56 GMT Subject: RFR: 8375624: G1: Convert G1JavaThreadsListClaimer to use Atomic In-Reply-To: References: <5vi-2xWtcToPfEnbJyYdVpQJl6oAzkbx6LLXxKQqfcY=.2cd9a5a3-075e-4479-b6c1-83f81ca90162@github.com> Message-ID: On Tue, 20 Jan 2026 10:01:42 GMT, Aleksey Shipilev wrote: >> Hi all, >> >> please review this change that makes `G1JavaThreadsListClaimer` use `Atomic` instead of `AtomicAccess'. >> >> Testing: gha >> >> Thanks, >> Thomas > > Marked as reviewed by shade (Reviewer). Thanks @shipilev @kimbarrett for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/29299#issuecomment-3772161361 From tschatzl at openjdk.org Tue Jan 20 10:37:57 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 20 Jan 2026 10:37:57 GMT Subject: Integrated: 8375624: G1: Convert G1JavaThreadsListClaimer to use Atomic In-Reply-To: <5vi-2xWtcToPfEnbJyYdVpQJl6oAzkbx6LLXxKQqfcY=.2cd9a5a3-075e-4479-b6c1-83f81ca90162@github.com> References: <5vi-2xWtcToPfEnbJyYdVpQJl6oAzkbx6LLXxKQqfcY=.2cd9a5a3-075e-4479-b6c1-83f81ca90162@github.com> Message-ID: On Mon, 19 Jan 2026 11:58:13 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that makes `G1JavaThreadsListClaimer` use `Atomic` instead of `AtomicAccess'. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 8c615190 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/8c615190e69ee6e521990595fc23197f38ad6f14 Stats: 7 lines in 2 files changed: 1 ins; 1 del; 5 mod 8375624: G1: Convert G1JavaThreadsListClaimer to use Atomic Reviewed-by: kbarrett, shade ------------- PR: https://git.openjdk.org/jdk/pull/29299 From tschatzl at openjdk.org Tue Jan 20 10:40:19 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 20 Jan 2026 10:40:19 GMT Subject: RFR: 8375643: G1: Convert G1RegionMarkStatsCache to use Atomic In-Reply-To: References: <52JFJVawH8TfssAKR4-8UlrNL-_kzoAFp4Lc6dhBu8s=.fa54fcef-4cd2-4aab-80f6-53d816e9b0ff@github.com> Message-ID: <2-VC_9ghQIkigTdipDiIqDJBS7HlDtxl6drK6m9G8O0=.5b33d692-9e18-4b6b-aeb9-a75dbf583782@github.com> On Tue, 20 Jan 2026 10:21:07 GMT, Aleksey Shipilev wrote: >> src/hotspot/share/gc/g1/g1RegionMarkStatsCache.hpp line 119: >> >>> 117: void add_live_words(uint region_idx, size_t live_words) { >>> 118: G1RegionMarkStatsCacheEntry* const cur = find_for_add(region_idx); >>> 119: cur->_stats._live_words.store_relaxed(cur->_stats.live_words() + live_words); >> >> Is this just `add_then_fetch` with `memory_order_relaxed` then? Or are we trying to dodge some performance penalty avoiding the atomic RMW instructions? I suspect x86 still implicitly does CAS memory effects when doing `cmpxchg` on memory location; `memory_order_relaxed` would not help there. > > Actually, what _are_ the atomicity requirements here? Is this code supposed to be called on same region stats by multiple threads? Or is this single threaded? In this method there are no atomic requirements. It is only called by a single thread. The only atomic requirements is when merging it down to a global table using `evict()`. However since that method requires an `Atomic`, we need to use `load/store_relaxed()` here anyway. It took me some time too to understand that the code is correct too. Should I add some comments? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29303#discussion_r2707763319 From tschatzl at openjdk.org Tue Jan 20 10:40:21 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 20 Jan 2026 10:40:21 GMT Subject: RFR: 8375643: G1: Convert G1RegionMarkStatsCache to use Atomic In-Reply-To: References: <52JFJVawH8TfssAKR4-8UlrNL-_kzoAFp4Lc6dhBu8s=.fa54fcef-4cd2-4aab-80f6-53d816e9b0ff@github.com> Message-ID: On Tue, 20 Jan 2026 10:16:27 GMT, Aleksey Shipilev wrote: >> Hi all, >> >> please review this change to make `G1RegionMarkStatsCache` use `Atomic`. >> >> The only unusual part is that I added two getters to that class to avoid the repeated `.load_relaxed()` typing. >> >> Testing: gha >> >> Thanks, >> Thomas > > src/hotspot/share/gc/g1/g1RegionMarkStatsCache.hpp line 124: > >> 122: void inc_incoming_refs(uint region_idx) { >> 123: G1RegionMarkStatsCacheEntry* const cur = find_for_add(region_idx); >> 124: cur->_stats._incoming_refs.store_relaxed(cur->_stats.incoming_refs() + 1u); > > Same, `add_then_fetch`? See above. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29303#discussion_r2707763600 From sjohanss at openjdk.org Tue Jan 20 10:42:13 2026 From: sjohanss at openjdk.org (Stefan Johansson) Date: Tue, 20 Jan 2026 10:42:13 GMT Subject: RFR: 8340470: G1: Adopt PartialArrayState to consolidate marking stack in Full GC [v5] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 10:26:23 GMT, Ivan Walulya wrote: >> Hi, >> >> Please review this change adopting `PartialArrayState` introduced by [JDK-8337709](https://bugs.openjdk.org/browse/JDK-8337709) to consolidate marking queue sets (oop queue set and objArray queue set) into single queue set in G1 Full GC. >> >> Testing: Tier 1-5 > > Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: > > kstefanj refactor rename Looks good. Me and Ivan discussed moving a couple of more functions into the inline.hpp file but left that for later, see [JDK-8375690](https://bugs.openjdk.org/browse/JDK-8375690). ------------- Marked as reviewed by sjohanss (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29114#pullrequestreview-3681511258 From tschatzl at openjdk.org Tue Jan 20 10:44:01 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 20 Jan 2026 10:44:01 GMT Subject: RFR: 8375622: G1: Convert G1CodeRootSet to use Atomic [v2] In-Reply-To: <-4f_Z6IzL4pG8lzz2tPUfPh7Sv1jgJVZgFKH4sEoO6A=.eb42f930-6ac3-44d3-905e-79b5a4edc622@github.com> References: <-4f_Z6IzL4pG8lzz2tPUfPh7Sv1jgJVZgFKH4sEoO6A=.eb42f930-6ac3-44d3-905e-79b5a4edc622@github.com> Message-ID: <6mW-g1_FzcqA9GMCOKzsPrMAt5htN8OSsNRVB0Vjugo=.48be71ea-ea76-4d37-805e-46df6a54c989@github.com> On Tue, 20 Jan 2026 09:26:07 GMT, Aleksey Shipilev wrote: > Looks good! > > I think your other PRs also suffer from the same include oddity. I checked the others, they are good. I'll put this on my check list to look at too for the future changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29296#issuecomment-3772190454 From iwalulya at openjdk.org Tue Jan 20 11:00:13 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 20 Jan 2026 11:00:13 GMT Subject: RFR: 8341630: G1: Adopt PartialArrayState to consolidate marking stack in concurrent marking [v3] In-Reply-To: References: Message-ID: > Hi, > > Please review this change which adopts the `PartialArrayState` mechanism for G1 concurrent marking. > > The `PartialArrayState` mechanism can push multiple continuations to the task queues, so it also solves the single-continuation limitation issue in [JDK-8167480](https://bugs.openjdk.org/browse/JDK-8167480). > > Testing: Mach5 Tier 1-3. Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: kstefanj refactor rename ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29249/files - new: https://git.openjdk.org/jdk/pull/29249/files/6a340321..2f082613 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29249&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29249&range=01-02 Stats: 10 lines in 3 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/29249.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29249/head:pull/29249 PR: https://git.openjdk.org/jdk/pull/29249 From sjohanss at openjdk.org Tue Jan 20 11:11:17 2026 From: sjohanss at openjdk.org (Stefan Johansson) Date: Tue, 20 Jan 2026 11:11:17 GMT Subject: RFR: 8341630: G1: Adopt PartialArrayState to consolidate marking stack in concurrent marking [v3] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 11:00:13 GMT, Ivan Walulya wrote: >> Hi, >> >> Please review this change which adopts the `PartialArrayState` mechanism for G1 concurrent marking. >> >> The `PartialArrayState` mechanism can push multiple continuations to the task queues, so it also solves the single-continuation limitation issue in [JDK-8167480](https://bugs.openjdk.org/browse/JDK-8167480). >> >> Testing: Mach5 Tier 1-3. > > Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: > > kstefanj refactor rename Looks good, but I realized there was an additional opportunity for streamlining the naming. Do the below change if you agree. src/hotspot/share/gc/g1/g1ConcurrentMark.hpp line 905: > 903: > 904: // Scans an object and visits its children. > 905: inline void scan_task_entry(G1TaskQueueEntry task_entry, bool stolen); Suggestion: inline void process_entry(G1TaskQueueEntry task_entry, bool stolen); ------------- Marked as reviewed by sjohanss (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29249#pullrequestreview-3681630599 PR Review Comment: https://git.openjdk.org/jdk/pull/29249#discussion_r2707868691 From shade at openjdk.org Tue Jan 20 11:27:12 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 20 Jan 2026 11:27:12 GMT Subject: RFR: 8375643: G1: Convert G1RegionMarkStatsCache to use Atomic In-Reply-To: <2-VC_9ghQIkigTdipDiIqDJBS7HlDtxl6drK6m9G8O0=.5b33d692-9e18-4b6b-aeb9-a75dbf583782@github.com> References: <52JFJVawH8TfssAKR4-8UlrNL-_kzoAFp4Lc6dhBu8s=.fa54fcef-4cd2-4aab-80f6-53d816e9b0ff@github.com> <2-VC_9ghQIkigTdipDiIqDJBS7HlDtxl6drK6m9G8O0=.5b33d692-9e18-4b6b-aeb9-a75dbf583782@github.com> Message-ID: On Tue, 20 Jan 2026 10:37:05 GMT, Thomas Schatzl wrote: >> Actually, what _are_ the atomicity requirements here? Is this code supposed to be called on same region stats by multiple threads? Or is this single threaded? > > In this method there are no atomic requirements. It is only called by a single thread. The only atomic requirements is when merging it down to a global table using `evict()`. However since that method requires an `Atomic`, we need to use `load/store_relaxed()` here anyway. > > It took me some time too to understand that the code is correct too. Should I add some comments? Well, maybe comment that this is a single-thread code, we do not need atomic RMW here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29303#discussion_r2707929787 From iwalulya at openjdk.org Tue Jan 20 11:34:46 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 20 Jan 2026 11:34:46 GMT Subject: RFR: 8341630: G1: Adopt PartialArrayState to consolidate marking stack in concurrent marking [v4] In-Reply-To: References: Message-ID: > Hi, > > Please review this change which adopts the `PartialArrayState` mechanism for G1 concurrent marking. > > The `PartialArrayState` mechanism can push multiple continuations to the task queues, so it also solves the single-continuation limitation issue in [JDK-8167480](https://bugs.openjdk.org/browse/JDK-8167480). > > Testing: Mach5 Tier 1-3. Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: Refactor ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29249/files - new: https://git.openjdk.org/jdk/pull/29249/files/2f082613..0f3df5f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29249&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29249&range=02-03 Stats: 7 lines in 3 files changed: 2 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/29249.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29249/head:pull/29249 PR: https://git.openjdk.org/jdk/pull/29249 From tschatzl at openjdk.org Tue Jan 20 11:58:24 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 20 Jan 2026 11:58:24 GMT Subject: RFR: 8375643: G1: Convert G1RegionMarkStatsCache to use Atomic [v2] In-Reply-To: <52JFJVawH8TfssAKR4-8UlrNL-_kzoAFp4Lc6dhBu8s=.fa54fcef-4cd2-4aab-80f6-53d816e9b0ff@github.com> References: <52JFJVawH8TfssAKR4-8UlrNL-_kzoAFp4Lc6dhBu8s=.fa54fcef-4cd2-4aab-80f6-53d816e9b0ff@github.com> Message-ID: > Hi all, > > please review this change to make `G1RegionMarkStatsCache` use `Atomic`. > > The only unusual part is that I added two getters to that class to avoid the repeated `.load_relaxed()` typing. > > Testing: gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * shade review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29303/files - new: https://git.openjdk.org/jdk/pull/29303/files/3929f90b..13264bf3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29303&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29303&range=00-01 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29303.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29303/head:pull/29303 PR: https://git.openjdk.org/jdk/pull/29303 From sjohanss at openjdk.org Tue Jan 20 12:58:08 2026 From: sjohanss at openjdk.org (Stefan Johansson) Date: Tue, 20 Jan 2026 12:58:08 GMT Subject: RFR: 8341630: G1: Adopt PartialArrayState to consolidate marking stack in concurrent marking [v4] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 11:34:46 GMT, Ivan Walulya wrote: >> Hi, >> >> Please review this change which adopts the `PartialArrayState` mechanism for G1 concurrent marking. >> >> The `PartialArrayState` mechanism can push multiple continuations to the task queues, so it also solves the single-continuation limitation issue in [JDK-8167480](https://bugs.openjdk.org/browse/JDK-8167480). >> >> Testing: Mach5 Tier 1-3. > > Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: > > Refactor Marked as reviewed by sjohanss (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29249#pullrequestreview-3682051173 From shade at openjdk.org Tue Jan 20 13:14:12 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 20 Jan 2026 13:14:12 GMT Subject: RFR: 8375643: G1: Convert G1RegionMarkStatsCache to use Atomic [v2] In-Reply-To: References: <52JFJVawH8TfssAKR4-8UlrNL-_kzoAFp4Lc6dhBu8s=.fa54fcef-4cd2-4aab-80f6-53d816e9b0ff@github.com> Message-ID: <4IXfrgnEJcDQPhfICgJM3sGeN9N0_4HoSuE72vjByB4=.bca4d19a-8ab4-4835-ba15-8195fc00d9fe@github.com> On Tue, 20 Jan 2026 11:58:24 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change to make `G1RegionMarkStatsCache` use `Atomic`. >> >> The only unusual part is that I added two getters to that class to avoid the repeated `.load_relaxed()` typing. >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * shade review Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29303#pullrequestreview-3682115798 From tschatzl at openjdk.org Tue Jan 20 13:25:04 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 20 Jan 2026 13:25:04 GMT Subject: RFR: 8375643: G1: Convert G1RegionMarkStatsCache to use Atomic [v2] In-Reply-To: <4IXfrgnEJcDQPhfICgJM3sGeN9N0_4HoSuE72vjByB4=.bca4d19a-8ab4-4835-ba15-8195fc00d9fe@github.com> References: <52JFJVawH8TfssAKR4-8UlrNL-_kzoAFp4Lc6dhBu8s=.fa54fcef-4cd2-4aab-80f6-53d816e9b0ff@github.com> <4IXfrgnEJcDQPhfICgJM3sGeN9N0_4HoSuE72vjByB4=.bca4d19a-8ab4-4835-ba15-8195fc00d9fe@github.com> Message-ID: On Tue, 20 Jan 2026 13:09:24 GMT, Aleksey Shipilev wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * shade review > > Marked as reviewed by shade (Reviewer). Thanks @shipilev @kimbarrett for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/29303#issuecomment-3772863296 From tschatzl at openjdk.org Tue Jan 20 13:25:06 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 20 Jan 2026 13:25:06 GMT Subject: Integrated: 8375643: G1: Convert G1RegionMarkStatsCache to use Atomic In-Reply-To: <52JFJVawH8TfssAKR4-8UlrNL-_kzoAFp4Lc6dhBu8s=.fa54fcef-4cd2-4aab-80f6-53d816e9b0ff@github.com> References: <52JFJVawH8TfssAKR4-8UlrNL-_kzoAFp4Lc6dhBu8s=.fa54fcef-4cd2-4aab-80f6-53d816e9b0ff@github.com> Message-ID: On Mon, 19 Jan 2026 16:56:09 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to make `G1RegionMarkStatsCache` use `Atomic`. > > The only unusual part is that I added two getters to that class to avoid the repeated `.load_relaxed()` typing. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 03704012 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/037040129e82958bd023e0b24d962627e8653710 Stats: 29 lines in 4 files changed: 8 ins; 2 del; 19 mod 8375643: G1: Convert G1RegionMarkStatsCache to use Atomic Reviewed-by: shade, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/29303 From tschatzl at openjdk.org Tue Jan 20 13:27:31 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 20 Jan 2026 13:27:31 GMT Subject: RFR: 8374693: ZGC: Convert zResurrection to use Atomic In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 09:34:07 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zResurrection. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29276#pullrequestreview-3682177755 From tschatzl at openjdk.org Tue Jan 20 14:13:40 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 20 Jan 2026 14:13:40 GMT Subject: RFR: 8375616: G1: Convert G1BatchedTask to use Atomic Message-ID: Hi all, please review the use of `Atomic` for the `G1BatchedTask` class. Testing: gha Thanks, Thomas ------------- Commit messages: - 8375616 Changes: https://git.openjdk.org/jdk/pull/29321/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29321&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375616 Stats: 8 lines in 2 files changed: 1 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/29321.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29321/head:pull/29321 PR: https://git.openjdk.org/jdk/pull/29321 From wkemper at openjdk.org Tue Jan 20 16:47:37 2026 From: wkemper at openjdk.org (William Kemper) Date: Tue, 20 Jan 2026 16:47:37 GMT Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need accurate live_data [v2] In-Reply-To: References: <7JK4muPbya1kL85_zTdJly1jGLlkv39bISYDeKhWtOo=.a16ac8ec-f411-4a2e-b5a4-62f999fe78e1@github.com> Message-ID: On Sat, 17 Jan 2026 03:47:47 GMT, Kelvin Nilsen wrote: >> This is the originally proposed PR to address https://bugs.openjdk.org/browse/JDK-8353115 >> At the time this proposed PR was reviewed, a suggestion for refactoring was proposed and explored, resulting in https://github.com/openjdk/jdk/pull/24319 >> >> Though the refactored implementation may have some desirable characteristics, this original implementation appears to have better performance. >> >> The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected. In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region. This is typically ok for young regions, where the amount of live data determines whether a region should be added to the collection set during the final-mark safepoint. >> >> However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated. In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended. >> >> This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > fix typo Marked as reviewed by wkemper (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29127#pullrequestreview-3683186087 From kdnilsen at openjdk.org Tue Jan 20 16:51:21 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 20 Jan 2026 16:51:21 GMT Subject: Integrated: 8353115: GenShen: mixed evacuation candidate regions need accurate live_data In-Reply-To: <7JK4muPbya1kL85_zTdJly1jGLlkv39bISYDeKhWtOo=.a16ac8ec-f411-4a2e-b5a4-62f999fe78e1@github.com> References: <7JK4muPbya1kL85_zTdJly1jGLlkv39bISYDeKhWtOo=.a16ac8ec-f411-4a2e-b5a4-62f999fe78e1@github.com> Message-ID: On Thu, 8 Jan 2026 21:05:36 GMT, Kelvin Nilsen wrote: > This is the originally proposed PR to address https://bugs.openjdk.org/browse/JDK-8353115 > At the time this proposed PR was reviewed, a suggestion for refactoring was proposed and explored, resulting in https://github.com/openjdk/jdk/pull/24319 > > Though the refactored implementation may have some desirable characteristics, this original implementation appears to have better performance. > > The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected. In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region. This is typically ok for young regions, where the amount of live data determines whether a region should be added to the collection set during the final-mark safepoint. > > However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated. In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended. > > This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions. This pull request has now been integrated. Changeset: 72bf0bb6 Author: Kelvin Nilsen URL: https://git.openjdk.org/jdk/commit/72bf0bb6f6eaf61b3800d885733e23b7b42bf9c9 Stats: 52 lines in 5 files changed: 52 ins; 0 del; 0 mod 8353115: GenShen: mixed evacuation candidate regions need accurate live_data Reviewed-by: wkemper ------------- PR: https://git.openjdk.org/jdk/pull/29127 From kbarrett at openjdk.org Tue Jan 20 18:01:32 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 20 Jan 2026 18:01:32 GMT Subject: RFR: 8375626: G1: Convert G1CollectionSetChooser to use Atomic [v2] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 08:07:50 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change to use `Atomic` for the `G1CollectionSetChooser` class. >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * kbarrett review Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29298#pullrequestreview-3683557833 From kbarrett at openjdk.org Tue Jan 20 18:04:22 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 20 Jan 2026 18:04:22 GMT Subject: RFR: 8375436: G1: Convert G1CardSet classes to use Atomic [v2] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 08:06:04 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this removal of use of the AtomicAccess class in G1 card set related classes, replacing with use of Atomic. >> >> Although a bit on the large side, it would be hard to do the card set changes separately per class. Other than that I think it is fairly straightforward, except for the addition of a copy constructor for `G1CardSetHashTableValue` because the `ConcurrentHashTable` requires it. >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * kbarrett review Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29274#pullrequestreview-3683567966 From tschatzl at openjdk.org Tue Jan 20 18:16:42 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 20 Jan 2026 18:16:42 GMT Subject: RFR: 8375626: G1: Convert G1CollectionSetChooser to use Atomic [v2] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 17:58:00 GMT, Kim Barrett wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * kbarrett review > > Looks good. Thanks @kimbarrett @shipilev for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/29298#issuecomment-3774290857 From tschatzl at openjdk.org Tue Jan 20 18:17:54 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 20 Jan 2026 18:17:54 GMT Subject: RFR: 8375541: G1: Race in G1BarrierSet::write_ref_field_post() [v2] In-Reply-To: References: Message-ID: > Hi all, > > during conversion of card table code to use `Atomic` I think I found the following error: the code in `G1BarrierSet::write_ref_field_post` is wrong in that it allows reload of the `_card_table` value, which is exactly what the existing code imo wrongly fails to ensure. even if it does not, making the load explicit improves reading. > > To not let this change get lost in that conversion, and potentially for backport to 26, I factored it out in this change. > > There is no known issue caused by this code in particular, one other bug I'm working on that just looks like what could be caused by this is not fixed. > > Testing: gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * fix copmilation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29311/files - new: https://git.openjdk.org/jdk/pull/29311/files/f7965b1f..36e1b2bb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29311&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29311&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29311.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29311/head:pull/29311 PR: https://git.openjdk.org/jdk/pull/29311 From tschatzl at openjdk.org Tue Jan 20 18:21:47 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 20 Jan 2026 18:21:47 GMT Subject: Integrated: 8375626: G1: Convert G1CollectionSetChooser to use Atomic In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 11:56:19 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to use `Atomic` for the `G1CollectionSetChooser` class. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 5f8cb30f Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/5f8cb30fc0296a2b487edf9dee63e810f4861e8e Stats: 9 lines in 1 file changed: 1 ins; 0 del; 8 mod 8375626: G1: Convert G1CollectionSetChooser to use Atomic Reviewed-by: kbarrett, shade ------------- PR: https://git.openjdk.org/jdk/pull/29298 From wkemper at openjdk.org Tue Jan 20 20:53:25 2026 From: wkemper at openjdk.org (William Kemper) Date: Tue, 20 Jan 2026 20:53:25 GMT Subject: RFR: 8374449: Shenandoah: Leaf locks used by Shenandoah need lower ranks Message-ID: <4IGKlFzk930jR8ejTkoYOC-eQvpvxlr0HfzJ5Hgr1gI=.7edc9d4e-10b3-4df6-ab8a-7d74dc0abe51@github.com> Reduce the rank of `safepoint` locks and rename them to avoid confusion with `nosafepoint` ranked locks. ------------- Commit messages: - Add constant for control lock rank - More lock rank tweaks - Go even lower, don't check for safepoint when taking the locks - Merge remote-tracking branch 'jdk/master' into lower-controller-lock-ranks - Use an even lower rank - Lower controller lock ranks to avoid false deadlock detection Changes: https://git.openjdk.org/jdk/pull/29333/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29333&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374449 Stats: 7 lines in 3 files changed: 3 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29333.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29333/head:pull/29333 PR: https://git.openjdk.org/jdk/pull/29333 From kdnilsen at openjdk.org Tue Jan 20 20:57:28 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 20 Jan 2026 20:57:28 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v13] In-Reply-To: References: Message-ID: > After studying large numbers of GC logs with degenerated cycles that have resulted from "late" triggers, we propose the following general improvements: > > 1. Track trends in GC times rather than always using the average GC time plus standard deviation. In many situations, GC times trend upward due to, for example, increasing amounts of live data that must be marked as a workload builds up its working set of memory. > 2. Sample allocation rates more frequently than once every 100 ms. > 3. Track trends in allocation rates. In some situations, the allocation rate trends upwards due to, for example, the start of a new phase of execution or a spike in client workload. > 4. When we detect acceleration of allocation rate, predict consumption of memory based on accelerated allocation rates rather than assuming constant allocation rate. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Remove redundant sample for spike rate ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29039/files - new: https://git.openjdk.org/jdk/pull/29039/files/80868d82..2f72c2a4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=11-12 Stats: 42 lines in 1 file changed: 9 ins; 3 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/29039.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29039/head:pull/29039 PR: https://git.openjdk.org/jdk/pull/29039 From kdnilsen at openjdk.org Tue Jan 20 23:12:46 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 20 Jan 2026 23:12:46 GMT Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need accurate live_data [v16] In-Reply-To: <16mCKOBudyw5oGH_yFiwBPCBwsJrjugRyTWDmuA8Q2g=.ee646318-ba2b-4599-8a46-acdc41e5aa78@github.com> References: <16mCKOBudyw5oGH_yFiwBPCBwsJrjugRyTWDmuA8Q2g=.ee646318-ba2b-4599-8a46-acdc41e5aa78@github.com> Message-ID: On Thu, 8 Jan 2026 22:53:43 GMT, Kelvin Nilsen wrote: >> The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected. In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region. This is typically ok for young regions, where the amount of live data determines whether a region should be added to the collection set during the final-mark safepoint. >> >> However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated. In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended. >> >> This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions. > > Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 62 commits: > > - Merge remote-tracking branch 'jdk/master' into fix-live-data-for-mixed-evac-candidates > - touch file to force retest > - Finish merge > - Merge remote-tracking branch 'jdk/master' into fix-live-data-for-mixed-evac-candidates > - Fix mistaken merge resolution > - Merge remote-tracking branch 'jdk/master' into fix-live-data-for-mixed-evac-candidates > > The resulting fastdebug build has 64 failures. I need to debug these. > Probably introduced by improper resolution of merge conflicts > - fix error in merge conflict resolution > - Merge remote-tracking branch 'jdk/master' into fix-live-data-for-mixed-evac-candidates > - rework CompressedClassSpaceSizeinJmapHeap.java > - fix errors in CompressedClassSpaceSizeInJmapHeap.java > - ... and 52 more: https://git.openjdk.org/jdk/compare/385c4f81...6d10ae5a We have decided to reject this implementation as an alternative approach offers better performance. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24319#issuecomment-3775372622 From kdnilsen at openjdk.org Tue Jan 20 23:51:25 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 20 Jan 2026 23:51:25 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v34] In-Reply-To: References: Message-ID: > Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). > > This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. > > The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. > > ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) > > With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. > > ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) > > At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. > > ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) > > The command line for these comparisons follows: > > > ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jdk/bin/java \ > -XX:+Unlock... Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 92 commits: - Merge remote-tracking branch 'jdk/master' into share-collector-reserves - remove debug instrumentation - Fix uninitialized variable - Add debugging instrumentation - Merge remote-tracking branch 'jdk/master' into share-collector-reserves - Use PROPERFMTARGS - Merge remote-tracking branch 'jdk/master' into share-collector-reserves - Move rebuild free set earlier in an abbreviated GC cycle - Restore deleted assert statement - Move special handling into ShenandoahYoungHeuristics::choose_collection_set_from_regiondata() - ... and 82 more: https://git.openjdk.org/jdk/compare/4fd7595f...c574f0b5 ------------- Changes: https://git.openjdk.org/jdk/pull/25357/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=33 Stats: 1510 lines in 41 files changed: 789 ins; 275 del; 446 mod Patch: https://git.openjdk.org/jdk/pull/25357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25357/head:pull/25357 PR: https://git.openjdk.org/jdk/pull/25357 From ysr at openjdk.org Wed Jan 21 02:14:32 2026 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Wed, 21 Jan 2026 02:14:32 GMT Subject: RFR: 8374449: Shenandoah: Leaf locks used by Shenandoah need lower ranks In-Reply-To: <4IGKlFzk930jR8ejTkoYOC-eQvpvxlr0HfzJ5Hgr1gI=.7edc9d4e-10b3-4df6-ab8a-7d74dc0abe51@github.com> References: <4IGKlFzk930jR8ejTkoYOC-eQvpvxlr0HfzJ5Hgr1gI=.7edc9d4e-10b3-4df6-ab8a-7d74dc0abe51@github.com> Message-ID: On Tue, 20 Jan 2026 20:47:24 GMT, William Kemper wrote: > Reduce the rank of `safepoint` locks and rename them to avoid confusion with `nosafepoint` ranked locks. src/hotspot/share/gc/shenandoah/shenandoahController.hpp line 47: > 45: const Mutex::Rank WAITERS_LOCK_RANK = Mutex::safepoint - 5; > 46: const Mutex::Rank CONTROL_LOCK_RANK = Mutex::nosafepoint - 2; > 47: I see code where we lock gc waiters lock then proceed to take control lock, e.g. https://github.com/openjdk/jdk/blob/e25a5a4821d03680d00ab6bdbec727732add8206/src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.cpp#L767 which calls: https://github.com/openjdk/jdk/blob/e25a5a4821d03680d00ab6bdbec727732add8206/src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.cpp#L703 Wouldn't that mean we should rank the latter lower than the former? May be I am confusing myself on the direction of locking rank. I thought that we can only take locks in reducing order of rank (so can't take (safepoint - 2) while holding (safepoint - 5))? https://github.com/openjdk/jdk/blob/e25a5a4821d03680d00ab6bdbec727732add8206/src/hotspot/share/runtime/mutex.cpp#L452 Can you run all of the jtreg tests to see if we are safe across all paths, or if locks need reranking? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29333#discussion_r2710699984 From sjohanss at openjdk.org Wed Jan 21 08:16:29 2026 From: sjohanss at openjdk.org (Stefan Johansson) Date: Wed, 21 Jan 2026 08:16:29 GMT Subject: RFR: 8375616: G1: Convert G1BatchedTask to use Atomic In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 14:06:04 GMT, Thomas Schatzl wrote: > Hi all, > > please review the use of `Atomic` for the `G1BatchedTask` class. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by sjohanss (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29321#pullrequestreview-3685870442 From sjohanss at openjdk.org Wed Jan 21 08:49:25 2026 From: sjohanss at openjdk.org (Stefan Johansson) Date: Wed, 21 Jan 2026 08:49:25 GMT Subject: RFR: 8375622: G1: Convert G1CodeRootSet to use Atomic [v2] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 08:09:55 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change to convert `G1CodeRootSet` to use `Atomic` instead of `AtomicAccess`. >> >> Testing: gha, >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * shade review Marked as reviewed by sjohanss (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29296#pullrequestreview-3685982560 From tschatzl at openjdk.org Wed Jan 21 09:02:25 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 21 Jan 2026 09:02:25 GMT Subject: RFR: 8375622: G1: Convert G1CodeRootSet to use Atomic [v2] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 08:44:28 GMT, Stefan Johansson wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * shade review > > Marked as reviewed by sjohanss (Reviewer). Thanks @kstefanj @shipilev for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/29296#issuecomment-3776932032 From tschatzl at openjdk.org Wed Jan 21 09:06:27 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 21 Jan 2026 09:06:27 GMT Subject: Integrated: 8375622: G1: Convert G1CodeRootSet to use Atomic In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 11:35:39 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to convert `G1CodeRootSet` to use `Atomic` instead of `AtomicAccess`. > > Testing: gha, > > Thanks, > Thomas This pull request has now been integrated. Changeset: 4f87fb53 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/4f87fb53ee5c6071fa57dfe9452eca9fe7b460ee Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod 8375622: G1: Convert G1CodeRootSet to use Atomic Reviewed-by: shade, sjohanss ------------- PR: https://git.openjdk.org/jdk/pull/29296 From tschatzl at openjdk.org Wed Jan 21 09:21:04 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 21 Jan 2026 09:21:04 GMT Subject: RFR: 8375314: =?UTF-8?B?77u/77u/UGFyYWxsZWw6?= Crash iterating over unloaded classes for ObjectCountAfterGC event Message-ID: Hi all, please review this change that avoids crashes when gathering `ObjectCountAfterGC` JFR statisics. The cause for the crash is that the code purges metaspace after class unloading/purging after https://bugs.openjdk.org/browse/JDK-8361404. The heap iteration code walks the heap with classes that were unloaded and purged, eventually crashing if for some reason the data is invalid due to metaspace purging potentially uncommitting memory. Since it is somewhat ugly that we walk objects with dead klasses in them (as it was before the mentioned change), I moved the iteration to after the heap has been compacted, skipping filler objects that might be in there. Unfortunately I did not manage to write a good reproducer. Testing: gha, tier1-5, test case succeeding Thanks, Thomas ------------- Commit messages: - * kstefanj review - * add test - 8375314 Changes: https://git.openjdk.org/jdk/pull/29318/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29318&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375314 Stats: 152 lines in 7 files changed: 136 ins; 11 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/29318.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29318/head:pull/29318 PR: https://git.openjdk.org/jdk/pull/29318 From sjohanss at openjdk.org Wed Jan 21 09:21:05 2026 From: sjohanss at openjdk.org (Stefan Johansson) Date: Wed, 21 Jan 2026 09:21:05 GMT Subject: RFR: 8375314: =?UTF-8?B?77u/77u/UGFyYWxsZWw6?= Crash iterating over unloaded classes for ObjectCountAfterGC event In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 13:08:07 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that avoids crashes when gathering `ObjectCountAfterGC` JFR statisics. > > The cause for the crash is that the code purges metaspace after class unloading/purging after https://bugs.openjdk.org/browse/JDK-8361404. The heap iteration code walks the heap with classes that were unloaded and purged, eventually crashing if for some reason the data is invalid due to metaspace purging potentially uncommitting memory. > > Since it is somewhat ugly that we walk objects with dead klasses in them (as it was before the mentioned change), I moved the iteration to after the heap has been compacted, skipping filler objects that might be in there. > > Unfortunately I did not manage to write a good reproducer. > > Testing: gha, tier1-5, test case succeeding > > Thanks, > Thomas Looks good, thanks for handling this. Just a small suggestion. src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1041: > 1039: _gc_tracer.report_object_count_after_gc(&cl, &ParallelScavengeHeap::heap()->workers()); > 1040: } > 1041: What do you think about extracting this to a helper to avoid the closure definition in the middle of this already very long function? ------------- Marked as reviewed by sjohanss (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29318#pullrequestreview-3685962200 PR Review Comment: https://git.openjdk.org/jdk/pull/29318#discussion_r2711511941 From iwalulya at openjdk.org Wed Jan 21 09:51:15 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 21 Jan 2026 09:51:15 GMT Subject: RFR: 8238686: G1 may waste lots of space or fail to uncommit when observing MinHeapFreeRatio during sizing after full gc [v3] In-Reply-To: References: <2CtP_aXZRdMpMM7MerGDY2WYvgJks7YMVHlQEYgItZI=.50a0dd11-5f58-4780-9a63-55dfe921c03d@github.com> Message-ID: On Mon, 19 Jan 2026 09:21:28 GMT, Stefan Johansson wrote: >> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: >> >> Factor out change in flag defaults > > Marked as reviewed by sjohanss (Reviewer). Thanks @kstefanj and @tschatzl for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29137#issuecomment-3777143552 From iwalulya at openjdk.org Wed Jan 21 09:53:26 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 21 Jan 2026 09:53:26 GMT Subject: Integrated: 8238686: G1 may waste lots of space or fail to uncommit when observing MinHeapFreeRatio during sizing after full gc In-Reply-To: <2CtP_aXZRdMpMM7MerGDY2WYvgJks7YMVHlQEYgItZI=.50a0dd11-5f58-4780-9a63-55dfe921c03d@github.com> References: <2CtP_aXZRdMpMM7MerGDY2WYvgJks7YMVHlQEYgItZI=.50a0dd11-5f58-4780-9a63-55dfe921c03d@github.com> Message-ID: On Fri, 9 Jan 2026 11:39:24 GMT, Ivan Walulya wrote: > Hi, > > Please review this change which modifies the defaults for the `MinHeapFreeRatio` and `MaxHeapFreeRatio` flags in G1 so that they do not affect heap sizing unless explicitly set by the user. > > Previously, these flags could trigger heap resizing at the end of Full GC, potentially overriding the G1 ergonomic heap sizing heuristics, which may be unexpected for the user. In particular, for workloads that frequently invoke `System.gc()`, the heap could shrink at the end of the Full GC and then expand aggressively during subsequent GCs (see image below). > > shrink_expand_flip_flop > > With this update, the default values for `MinHeapFreeRatio` and `MaxHeapFreeRatio` no longer affect heap resizing. These flags will only take effect when explicitly set by the user.. > > ~~Additionally, pause times from user-triggered `System.gc()` invocations will be excluded from the data used to update heap sizing heuristics. Because these GCs are user-initiated and do not reflect actual GC pressure, including their pause times can skew GC Pause Time ratios used for heap sizing decisions.~~ > > > Testing: Tier 1 and JavaPerf. This pull request has now been integrated. Changeset: b1340305 Author: Ivan Walulya URL: https://git.openjdk.org/jdk/commit/b1340305c8f5ea53b45b8bd3bd2ebe8f74864d40 Stats: 12 lines in 1 file changed: 11 ins; 0 del; 1 mod 8238686: G1 may waste lots of space or fail to uncommit when observing MinHeapFreeRatio during sizing after full gc Reviewed-by: tschatzl, sjohanss ------------- PR: https://git.openjdk.org/jdk/pull/29137 From tschatzl at openjdk.org Wed Jan 21 10:08:23 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 21 Jan 2026 10:08:23 GMT Subject: RFR: 8374695: ZGC: Convert zTLABUsage to use Atomic [v2] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 06:20:09 GMT, Axel Boldt-Christmas wrote: >> Convert usages of AtomicAccess to Atomic in zTLABUsage. >> >> Testing: >> * GHA >> * HotSpot GC tests with ZGC linux x64 and linux aarch64 > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Remove superfluous space Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29271#pullrequestreview-3686366052 From tschatzl at openjdk.org Wed Jan 21 10:09:52 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 21 Jan 2026 10:09:52 GMT Subject: RFR: 8374690: ZGC: Convert zRelocate to use Atomic In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 09:00:48 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zRelocate. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29268#pullrequestreview-3686378289 From tschatzl at openjdk.org Wed Jan 21 10:09:54 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 21 Jan 2026 10:09:54 GMT Subject: RFR: 8374692: ZGC: Convert zRemembered to use Atomic In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 09:04:38 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zRemembered. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Lgtm. Maybe use `compare_set` in the one case Stefan mentioned. ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29269#pullrequestreview-3686374687 From tschatzl at openjdk.org Wed Jan 21 10:11:25 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 21 Jan 2026 10:11:25 GMT Subject: RFR: 8374687: ZGC: Convert zNMethodTableIteration to use Atomic In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 08:46:12 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zNMethodTableIteration. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29267#pullrequestreview-3686380552 From tschatzl at openjdk.org Wed Jan 21 10:13:35 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 21 Jan 2026 10:13:35 GMT Subject: RFR: 8341630: G1: Adopt PartialArrayState to consolidate marking stack in concurrent marking [v4] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 11:34:46 GMT, Ivan Walulya wrote: >> Hi, >> >> Please review this change which adopts the `PartialArrayState` mechanism for G1 concurrent marking. >> >> The `PartialArrayState` mechanism can push multiple continuations to the task queues, so it also solves the single-continuation limitation issue in [JDK-8167480](https://bugs.openjdk.org/browse/JDK-8167480). >> >> Testing: Mach5 Tier 1-3. > > Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: > > Refactor Still good. ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29249#pullrequestreview-3686386229 From tschatzl at openjdk.org Wed Jan 21 10:14:40 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 21 Jan 2026 10:14:40 GMT Subject: RFR: 8374684: ZGC: Convert zMark to use Atomic In-Reply-To: <2-6Q_cMDlDBi4NKK_IN_QmIcSuUZNsN8vGEqX8z1fkY=.c968e317-5ea1-4338-9003-ef1df3c89a3c@github.com> References: <2-6Q_cMDlDBi4NKK_IN_QmIcSuUZNsN8vGEqX8z1fkY=.c968e317-5ea1-4338-9003-ef1df3c89a3c@github.com> Message-ID: On Thu, 15 Jan 2026 06:09:25 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zMark. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29245#pullrequestreview-3686390068 From tschatzl at openjdk.org Wed Jan 21 10:14:44 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 21 Jan 2026 10:14:44 GMT Subject: RFR: 8374683: ZGC: Convert zLock to use Atomic In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 06:08:04 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zLock. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29244#pullrequestreview-3686392770 From tschatzl at openjdk.org Wed Jan 21 10:15:18 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 21 Jan 2026 10:15:18 GMT Subject: RFR: 8374682: ZGC: Convert zLiveMap to use Atomic In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 06:06:10 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zLiveMap. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29243#pullrequestreview-3686396195 From tschatzl at openjdk.org Wed Jan 21 10:16:17 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 21 Jan 2026 10:16:17 GMT Subject: RFR: 8374680: ZGC: Convert zGeneration to use Atomic In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 08:31:24 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zGeneration. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29222#pullrequestreview-3686404639 From tschatzl at openjdk.org Wed Jan 21 10:16:18 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 21 Jan 2026 10:16:18 GMT Subject: RFR: 8374681: ZGC: Convert zJNICritical to use Atomic [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 06:06:24 GMT, Axel Boldt-Christmas wrote: >> Convert usages of AtomicAccess to Atomic in zJNICritical. >> >> Testing: >> * GHA >> * HotSpot GC tests with ZGC linux x64 and linux aarch64 > > Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Use compare_set > - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8374681 > - ZGC: Convert zJNICritical to use Atomic Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29223#pullrequestreview-3686401737 From tschatzl at openjdk.org Wed Jan 21 10:18:55 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 21 Jan 2026 10:18:55 GMT Subject: RFR: 8374679: ZGC: Convert zForwardingAllocator to use Atomic In-Reply-To: References: Message-ID: <2aSoy3iW796ofWruy5lFUzFjOncqTkZAIZdE2QbJ0pA=.1f5850d9-3788-454e-b59b-90f21f54115e@github.com> On Wed, 14 Jan 2026 08:29:43 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zForwardingAllocator. > > We currently use plain loads and stores which are synchronised and ordered with respect to the allocation by means of us starting worker threads which allocate and awaiting them to finish. This patch changes everything to have atomic semantics, but the loads and stores are still relaxed. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29221#pullrequestreview-3686408745 From tschatzl at openjdk.org Wed Jan 21 10:20:29 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 21 Jan 2026 10:20:29 GMT Subject: RFR: 8374676: ZGC: Convert zAbort to use Atomic In-Reply-To: <3WJ0EqDX5JbpbMwnGu_Q8NO9UA3yHHdIEQI7elKt5a0=.44251ee2-a4b5-4440-bcdc-b89b7bc3da75@github.com> References: <3WJ0EqDX5JbpbMwnGu_Q8NO9UA3yHHdIEQI7elKt5a0=.44251ee2-a4b5-4440-bcdc-b89b7bc3da75@github.com> Message-ID: <2E490INrsNqaQsZLtpKmq9qmaZhiHMhEsx6Arvjnsag=.a337d833-806b-44b8-ba70-eb6c64ec2384@github.com> On Wed, 14 Jan 2026 07:52:31 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zAbort. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29217#pullrequestreview-3686421378 From tschatzl at openjdk.org Wed Jan 21 10:21:40 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 21 Jan 2026 10:21:40 GMT Subject: RFR: 8374677: ZGC: Convert zArray to use Atomic In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 07:57:52 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zArray. > > Not sure about `NextType` name. Unclear how we want to name our using type aliases in the ZGC code. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29218#pullrequestreview-3686419118 From tschatzl at openjdk.org Wed Jan 21 10:57:37 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 21 Jan 2026 10:57:37 GMT Subject: RFR: 8375364: [macos] Some jpackage signing tests fail after JDK-8375240 Message-ID: <-AQiYq3R3DDkNgH-BG7L245lx6Rz1ezlizPt3CNmhvw=.decaa9ff-3daf-45eb-aa0a-ebd4a7ba346e@github.com> Hi all, please review the changes to let `G1BuildCandidateRegionsTask` use `Atomic`. Testing: gha Thanks, Thomas ------------- Commit messages: - 8375364 Changes: https://git.openjdk.org/jdk/pull/29339/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29339&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375364 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/29339.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29339/head:pull/29339 PR: https://git.openjdk.org/jdk/pull/29339 From tschatzl at openjdk.org Wed Jan 21 11:05:39 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 21 Jan 2026 11:05:39 GMT Subject: RFR: 8375966: G1: Convert G1UpdateRegionLivenessAndSelectForRebuildTask to use Atomic Message-ID: Hi all, please review this change to convert `G1UpdateRegionLivenessAndSelectForRebuildTask` to use `Atomic`. Testing: gha Thanks, Thomas ------------- Commit messages: - 8375966 Changes: https://git.openjdk.org/jdk/pull/29340/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29340&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375966 Stats: 7 lines in 2 files changed: 1 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/29340.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29340/head:pull/29340 PR: https://git.openjdk.org/jdk/pull/29340 From tschatzl at openjdk.org Wed Jan 21 11:29:45 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 21 Jan 2026 11:29:45 GMT Subject: RFR: 8375971: G1: Convert G1EvacStats. to use Atomic Message-ID: Hi all, please review this change that moves `G1EvacStats` to use `Atomic`. Testing: gha Thanks, Thomas ------------- Commit messages: - 8375971 Changes: https://git.openjdk.org/jdk/pull/29341/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29341&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375971 Stats: 67 lines in 3 files changed: 24 ins; 9 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/29341.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29341/head:pull/29341 PR: https://git.openjdk.org/jdk/pull/29341 From tschatzl at openjdk.org Wed Jan 21 11:41:51 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 21 Jan 2026 11:41:51 GMT Subject: RFR: 8375974: G1: Convert G1FullCollector to use Atomic Message-ID: <6WLOSv0nfMvvwt_nov7cwNo6Zx-_BX4EkZ735UZZCt0=.82351a7b-6c64-4214-90f8-e7173e095bc7@github.com> Hi all, please review this change to convert `G1FullCollector` to use `Atomic`. Testing: gha Thanks, Thomas ------------- Commit messages: - 8375974 Changes: https://git.openjdk.org/jdk/pull/29342/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29342&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375974 Stats: 8 lines in 3 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/29342.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29342/head:pull/29342 PR: https://git.openjdk.org/jdk/pull/29342 From tschatzl at openjdk.org Wed Jan 21 11:57:16 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 21 Jan 2026 11:57:16 GMT Subject: RFR: 8375977: G1: Convert JVMCICleaningTask to use Atomic Message-ID: Hi all, please review this conversion of `JVMCICleaningTask` to use `Atomic`. Testing: gha Thanks, Thomas ------------- Commit messages: - 8375977 Changes: https://git.openjdk.org/jdk/pull/29343/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29343&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375977 Stats: 9 lines in 2 files changed: 3 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/29343.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29343/head:pull/29343 PR: https://git.openjdk.org/jdk/pull/29343 From tschatzl at openjdk.org Wed Jan 21 12:06:30 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 21 Jan 2026 12:06:30 GMT Subject: RFR: 8375978: G1: Convert G1Policy to use Atomic Message-ID: Hi all, please review this conversion of `G1Policy` to use `Atomic`. Also removed the unused `_young_list_max_length` instead of unnecessarily converting it. Testing: gha Thanks, Thomas ------------- Commit messages: - 8375978 Changes: https://git.openjdk.org/jdk/pull/29344/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29344&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375978 Stats: 10 lines in 2 files changed: 0 ins; 3 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/29344.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29344/head:pull/29344 PR: https://git.openjdk.org/jdk/pull/29344 From sjohanss at openjdk.org Wed Jan 21 12:28:12 2026 From: sjohanss at openjdk.org (Stefan Johansson) Date: Wed, 21 Jan 2026 12:28:12 GMT Subject: RFR: 8375314: Parallel: Crash iterating over unloaded classes for ObjectCountAfterGC event In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 13:08:07 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that avoids crashes when gathering `ObjectCountAfterGC` JFR statisics. > > The cause for the crash is that the code purges metaspace after class unloading/purging after https://bugs.openjdk.org/browse/JDK-8361404. The heap iteration code walks the heap with classes that were unloaded and purged, eventually crashing if for some reason the data is invalid due to metaspace purging potentially uncommitting memory. > > Since it is somewhat ugly that we walk objects with dead klasses in them (as it was before the mentioned change), I moved the iteration to after the heap has been compacted, skipping filler objects that might be in there. > > Unfortunately I did not manage to write a good reproducer. > > Testing: gha, tier1-5, test case succeeding > > Thanks, > Thomas Marked as reviewed by sjohanss (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29318#pullrequestreview-3686950455 From tschatzl at openjdk.org Wed Jan 21 12:56:29 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 21 Jan 2026 12:56:29 GMT Subject: RFR: 8375982: G1: Convert G1YoungCollector helper classes to use Atomic Message-ID: <6eX4PZ5crpZ8tZeUJHdYO3Q_vLS7cx9ESJZbLrG6Bbo=.071f6b55-0f1b-4c4f-92d1-040496396fbe@github.com> Hi all, please review these changes to convert uses of `Atomic` in some `G1YoungCollector` helper classes. Testing: gha Thanks, Thomas ------------- Commit messages: - 8375982 Changes: https://git.openjdk.org/jdk/pull/29346/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29346&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375982 Stats: 14 lines in 2 files changed: 2 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/29346.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29346/head:pull/29346 PR: https://git.openjdk.org/jdk/pull/29346 From tschatzl at openjdk.org Wed Jan 21 13:31:42 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 21 Jan 2026 13:31:42 GMT Subject: RFR: 8375983: G1: Convert G1ConcurrentRefineStats to use Atomic Message-ID: Hi all, please review this change that converts `G1ConcurrentRefineStats` to use `Atomic`. The only notable thing is that there has been need to expand the assignment in `reset()` since the assignment operator for `Atomic` is not defined, and I did not see it worth adding one. Testing: gha Thanks, Thomas ------------- Commit messages: - 8375983 Changes: https://git.openjdk.org/jdk/pull/29347/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29347&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375983 Stats: 50 lines in 2 files changed: 9 ins; 0 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/29347.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29347/head:pull/29347 PR: https://git.openjdk.org/jdk/pull/29347 From iwalulya at openjdk.org Wed Jan 21 13:48:53 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 21 Jan 2026 13:48:53 GMT Subject: RFR: 8375314: Parallel: Crash iterating over unloaded classes for ObjectCountAfterGC event In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 13:08:07 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that avoids crashes when gathering `ObjectCountAfterGC` JFR statisics. > > The cause for the crash is that the code purges metaspace after class unloading/purging after https://bugs.openjdk.org/browse/JDK-8361404. The heap iteration code walks the heap with classes that were unloaded and purged, eventually crashing if for some reason the data is invalid due to metaspace purging potentially uncommitting memory. > > Since it is somewhat ugly that we walk objects with dead klasses in them (as it was before the mentioned change), I moved the iteration to after the heap has been compacted, skipping filler objects that might be in there. > > Unfortunately I did not manage to write a good reproducer. > > Testing: gha, tier1-5, test case succeeding > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29318#pullrequestreview-3687331841 From iwalulya at openjdk.org Wed Jan 21 13:54:15 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 21 Jan 2026 13:54:15 GMT Subject: RFR: 8375541: G1: Race in G1BarrierSet::write_ref_field_post() [v2] In-Reply-To: References: Message-ID: <-q3GjU6EYmG-2B3ZTQOsdGoLoP6lO3PzB63lzfvkfGQ=.95d36835-0403-4d98-b9ff-b8f8df9c51b9@github.com> On Tue, 20 Jan 2026 18:17:54 GMT, Thomas Schatzl wrote: >> Hi all, >> >> during conversion of card table code to use `Atomic` I think I found the following error: the code in `G1BarrierSet::write_ref_field_post` is wrong in that it allows reload of the `_card_table` value, which is exactly what the existing code imo wrongly fails to ensure. even if it does not, making the load explicit improves reading. >> >> To not let this change get lost in that conversion, and potentially for backport to 26, I factored it out in this change. >> >> There is no known issue caused by this code in particular, one other bug I'm working on that just looks like what could be caused by this is not fixed. >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * fix copmilation Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29311#pullrequestreview-3687356570 From tschatzl at openjdk.org Wed Jan 21 14:02:31 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 21 Jan 2026 14:02:31 GMT Subject: RFR: 8375541: G1: Race in G1BarrierSet::write_ref_field_post() [v3] In-Reply-To: References: Message-ID: <5dwpiJA36VF157--z9mZhD0EOQgtopK3iEo5xqzP3YU=.14feb170-5a35-477f-8c1c-e3e4607992c2@github.com> > Hi all, > > during conversion of card table code to use `Atomic` I think I found the following error: the code in `G1BarrierSet::write_ref_field_post` is wrong in that it allows reload of the `_card_table` value, which is exactly what the existing code imo wrongly fails to ensure. even if it does not, making the load explicit improves reading. > > To not let this change get lost in that conversion, and potentially for backport to 26, I factored it out in this change. > > There is no known issue caused by this code in particular, one other bug I'm working on that just looks like what could be caused by this is not fixed. > > Testing: gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * walulyai review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29311/files - new: https://git.openjdk.org/jdk/pull/29311/files/36e1b2bb..07e3f385 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29311&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29311&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29311.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29311/head:pull/29311 PR: https://git.openjdk.org/jdk/pull/29311 From iwalulya at openjdk.org Wed Jan 21 14:09:03 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 21 Jan 2026 14:09:03 GMT Subject: RFR: 8375541: G1: Race in G1BarrierSet::write_ref_field_post() [v3] In-Reply-To: <5dwpiJA36VF157--z9mZhD0EOQgtopK3iEo5xqzP3YU=.14feb170-5a35-477f-8c1c-e3e4607992c2@github.com> References: <5dwpiJA36VF157--z9mZhD0EOQgtopK3iEo5xqzP3YU=.14feb170-5a35-477f-8c1c-e3e4607992c2@github.com> Message-ID: On Wed, 21 Jan 2026 14:02:31 GMT, Thomas Schatzl wrote: >> Hi all, >> >> during conversion of card table code to use `Atomic` I think I found the following error: the code in `G1BarrierSet::write_ref_field_post` is wrong in that it allows reload of the `_card_table` value, which is exactly what the existing code imo wrongly fails to ensure. even if it does not, making the load explicit improves reading. >> >> To not let this change get lost in that conversion, and potentially for backport to 26, I factored it out in this change. >> >> There is no known issue caused by this code in particular, one other bug I'm working on that just looks like what could be caused by this is not fixed. >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * walulyai review Still good! ------------- Marked as reviewed by iwalulya (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29311#pullrequestreview-3687426435 From kdnilsen at openjdk.org Wed Jan 21 15:53:56 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 21 Jan 2026 15:53:56 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v14] In-Reply-To: References: Message-ID: <4CBd4iZp_q2hXY9OprLlNbsW1rvdqDNo42uOnNkRtZ8=.c8c655ab-54ee-4c18-a5fb-0e31c37a8334@github.com> > After studying large numbers of GC logs with degenerated cycles that have resulted from "late" triggers, we propose the following general improvements: > > 1. Track trends in GC times rather than always using the average GC time plus standard deviation. In many situations, GC times trend upward due to, for example, increasing amounts of live data that must be marked as a workload builds up its working set of memory. > 2. Sample allocation rates more frequently than once every 100 ms. > 3. Track trends in allocation rates. In some situations, the allocation rate trends upwards due to, for example, the start of a new phase of execution or a spike in client workload. > 4. When we detect acceleration of allocation rate, predict consumption of memory based on accelerated allocation rates rather than assuming constant allocation rate. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: remove tab ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29039/files - new: https://git.openjdk.org/jdk/pull/29039/files/2f72c2a4..9a77852a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=12-13 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29039.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29039/head:pull/29039 PR: https://git.openjdk.org/jdk/pull/29039 From tschatzl at openjdk.org Wed Jan 21 16:32:21 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 21 Jan 2026 16:32:21 GMT Subject: RFR: 8375314: Parallel: Crash iterating over unloaded classes for ObjectCountAfterGC event [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that avoids crashes when gathering `ObjectCountAfterGC` JFR statisics. > > The cause for the crash is that the code purges metaspace after class unloading/purging after https://bugs.openjdk.org/browse/JDK-8361404. The heap iteration code walks the heap with classes that were unloaded and purged, eventually crashing if for some reason the data is invalid due to metaspace purging potentially uncommitting memory. > > Since it is somewhat ugly that we walk objects with dead klasses in them (as it was before the mentioned change), I moved the iteration to after the heap has been compacted, skipping filler objects that might be in there. > > Unfortunately I did not manage to write a good reproducer. > > Testing: gha, tier1-5, test case succeeding > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * remove WhiteBox references from test, not needed any more ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29318/files - new: https://git.openjdk.org/jdk/pull/29318/files/16118b68..595e04b1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29318&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29318&range=00-01 Stats: 8 lines in 1 file changed: 0 ins; 7 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29318.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29318/head:pull/29318 PR: https://git.openjdk.org/jdk/pull/29318 From kbarrett at openjdk.org Wed Jan 21 16:43:51 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 21 Jan 2026 16:43:51 GMT Subject: RFR: 8375966: G1: Convert G1UpdateRegionLivenessAndSelectForRebuildTask to use Atomic In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 10:56:51 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to convert `G1UpdateRegionLivenessAndSelectForRebuildTask` to use `Atomic`. > > Testing: gha > > Thanks, > Thomas Looks good, with an optional whitespace adjustment. src/hotspot/share/gc/g1/g1ConcurrentMarkRemarkTasks.hpp line 61: > 59: void work(uint worker_id) override; > 60: > 61: uint total_selected_for_rebuild() const { return _total_selected_for_rebuild.load_relaxed(); } Consider adding some line breaks to make this not such a long line. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29340#pullrequestreview-3688256831 PR Review Comment: https://git.openjdk.org/jdk/pull/29340#discussion_r2713411963 From kbarrett at openjdk.org Wed Jan 21 16:51:08 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 21 Jan 2026 16:51:08 GMT Subject: RFR: 8375974: G1: Convert G1FullCollector to use Atomic In-Reply-To: <6WLOSv0nfMvvwt_nov7cwNo6Zx-_BX4EkZ735UZZCt0=.82351a7b-6c64-4214-90f8-e7173e095bc7@github.com> References: <6WLOSv0nfMvvwt_nov7cwNo6Zx-_BX4EkZ735UZZCt0=.82351a7b-6c64-4214-90f8-e7173e095bc7@github.com> Message-ID: On Wed, 21 Jan 2026 11:34:33 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to convert `G1FullCollector` to use `Atomic`. > > Testing: gha > > Thanks, > Thomas Changes requested by kbarrett (Reviewer). src/hotspot/share/gc/g1/g1FullCollector.cpp line 140: > 138: for (uint j = 0; j < heap->max_num_regions(); j++) { > 139: _live_stats[j].clear(); > 140: _compaction_tops[j].store_relaxed(nullptr); We haven't constructed any objects here yet, so technically this is UB. Better is something like ::new (&_compaction_tops[j]) Atomic{} src/hotspot/share/gc/g1/g1FullCollector.inline.hpp line 66: > 64: > 65: void G1FullCollector::set_compaction_top(G1HeapRegion* r, HeapWord* value) { > 66: _compaction_tops[r->hrm_index()].store_relaxed(value); We seem to only be doing relaxed load/store. What is the concurrent usage model here that needs atomics? ------------- PR Review: https://git.openjdk.org/jdk/pull/29342#pullrequestreview-3688280858 PR Review Comment: https://git.openjdk.org/jdk/pull/29342#discussion_r2713431501 PR Review Comment: https://git.openjdk.org/jdk/pull/29342#discussion_r2713447533 From kbarrett at openjdk.org Wed Jan 21 16:53:43 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 21 Jan 2026 16:53:43 GMT Subject: RFR: 8375977: G1: Convert JVMCICleaningTask to use Atomic In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 11:49:56 GMT, Thomas Schatzl wrote: > Hi all, > > please review this conversion of `JVMCICleaningTask` to use `Atomic`. > > Testing: gha > > Thanks, > Thomas Looks good, and trivial. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29343#pullrequestreview-3688316000 From kbarrett at openjdk.org Wed Jan 21 16:55:53 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 21 Jan 2026 16:55:53 GMT Subject: RFR: 8375978: G1: Convert G1Policy to use Atomic In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 11:59:23 GMT, Thomas Schatzl wrote: > Hi all, > > please review this conversion of `G1Policy` to use `Atomic`. > > Also removed the unused `_young_list_max_length` instead of unnecessarily converting it. > > Testing: gha > > Thanks, > Thomas Looks good, and trivial. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29344#pullrequestreview-3688328888 From kbarrett at openjdk.org Wed Jan 21 17:00:36 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 21 Jan 2026 17:00:36 GMT Subject: RFR: 8375983: G1: Convert G1ConcurrentRefineStats to use Atomic In-Reply-To: References: Message-ID: <9IleoLJcVUyX50SRUEnkvcNBOOm0SLXTbk3h366iUWY=.b188bfe5-8ccf-461c-8aea-cce6acfabf22@github.com> On Wed, 21 Jan 2026 13:22:07 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that converts `G1ConcurrentRefineStats` to use `Atomic`. > > The only notable thing is that there has been need to expand the assignment in `reset()` since the assignment operator for `Atomic` is not defined, and I did not see it worth adding one. > > Testing: gha > > Thanks, > Thomas Looks good. Some optional whitespace adjustments. src/hotspot/share/gc/g1/g1ConcurrentRefineStats.hpp line 56: > 54: // but not yield time). > 55: jlong sweep_duration() const { return _sweep_duration.load_relaxed() - yield_during_sweep_duration(); } > 56: jlong yield_during_sweep_duration() const { return _yield_during_sweep_duration.load_relaxed(); } Consider some line breaks to reduce line lengths. There are some more long lines below too. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29347#pullrequestreview-3688346706 PR Review Comment: https://git.openjdk.org/jdk/pull/29347#discussion_r2713482620 From kbarrett at openjdk.org Wed Jan 21 17:03:33 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 21 Jan 2026 17:03:33 GMT Subject: RFR: 8375616: G1: Convert G1BatchedTask to use Atomic In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 14:06:04 GMT, Thomas Schatzl wrote: > Hi all, > > please review the use of `Atomic` for the `G1BatchedTask` class. > > Testing: gha > > Thanks, > Thomas Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29321#pullrequestreview-3688375604 From kbarrett at openjdk.org Wed Jan 21 17:07:28 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 21 Jan 2026 17:07:28 GMT Subject: RFR: 8375982: G1: Convert G1YoungCollector helper classes to use Atomic In-Reply-To: <6eX4PZ5crpZ8tZeUJHdYO3Q_vLS7cx9ESJZbLrG6Bbo=.071f6b55-0f1b-4c4f-92d1-040496396fbe@github.com> References: <6eX4PZ5crpZ8tZeUJHdYO3Q_vLS7cx9ESJZbLrG6Bbo=.071f6b55-0f1b-4c4f-92d1-040496396fbe@github.com> Message-ID: On Wed, 21 Jan 2026 12:48:49 GMT, Thomas Schatzl wrote: > Hi all, > > please review these changes to convert uses of `Atomic` in some `G1YoungCollector` helper classes. > > Testing: gha > > Thanks, > Thomas Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29346#pullrequestreview-3688389285 From tschatzl at openjdk.org Wed Jan 21 17:17:08 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 21 Jan 2026 17:17:08 GMT Subject: RFR: 8375974: G1: Convert G1FullCollector to use Atomic In-Reply-To: References: <6WLOSv0nfMvvwt_nov7cwNo6Zx-_BX4EkZ735UZZCt0=.82351a7b-6c64-4214-90f8-e7173e095bc7@github.com> Message-ID: On Wed, 21 Jan 2026 16:48:10 GMT, Kim Barrett wrote: >> Hi all, >> >> please review this change to convert `G1FullCollector` to use `Atomic`. >> >> Testing: gha >> >> Thanks, >> Thomas > > src/hotspot/share/gc/g1/g1FullCollector.inline.hpp line 66: > >> 64: >> 65: void G1FullCollector::set_compaction_top(G1HeapRegion* r, HeapWord* value) { >> 66: _compaction_tops[r->hrm_index()].store_relaxed(value); > > We seem to only be doing relaxed load/store. What is the concurrent usage model here that > needs atomics? Idk. I think it is just about the `_compaction_tops` being aligned, i.e. can be atomically read. Also to just indicate that the array is accessed concurrently. I can remove these completely if wanted. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29342#discussion_r2713560016 From kbarrett at openjdk.org Wed Jan 21 18:04:33 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 21 Jan 2026 18:04:33 GMT Subject: RFR: 8375974: G1: Convert G1FullCollector to use Atomic In-Reply-To: References: <6WLOSv0nfMvvwt_nov7cwNo6Zx-_BX4EkZ735UZZCt0=.82351a7b-6c64-4214-90f8-e7173e095bc7@github.com> Message-ID: On Wed, 21 Jan 2026 17:15:04 GMT, Thomas Schatzl wrote: >> src/hotspot/share/gc/g1/g1FullCollector.inline.hpp line 66: >> >>> 64: >>> 65: void G1FullCollector::set_compaction_top(G1HeapRegion* r, HeapWord* value) { >>> 66: _compaction_tops[r->hrm_index()].store_relaxed(value); >> >> We seem to only be doing relaxed load/store. What is the concurrent usage model here that >> needs atomics? > > Idk. I think it is just about the `_compaction_tops` being aligned, i.e. can be atomically read. Also to just indicate that the array is accessed concurrently. > > I can remove these completely if wanted. There wasn't any alignment futzing in the old code, so I don't think that's it. I've not looked to see if it can be removed; I was asking if you knew the answer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29342#discussion_r2713719994 From tschatzl at openjdk.org Wed Jan 21 18:04:33 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 21 Jan 2026 18:04:33 GMT Subject: RFR: 8375974: G1: Convert G1FullCollector to use Atomic In-Reply-To: References: <6WLOSv0nfMvvwt_nov7cwNo6Zx-_BX4EkZ735UZZCt0=.82351a7b-6c64-4214-90f8-e7173e095bc7@github.com> Message-ID: On Wed, 21 Jan 2026 17:58:47 GMT, Kim Barrett wrote: >> Idk. I think it is just about the `_compaction_tops` being aligned, i.e. can be atomically read. Also to just indicate that the array is accessed concurrently. >> >> I can remove these completely if wanted. > > There wasn't any alignment futzing in the old code, so I don't think that's it. > I've not looked to see if it can be removed; I was asking if you knew the answer. The compaction_tops are written in one phase of full gc, and read in other phases, both in parallel, but the writing is non-overlapping (and reads do not matter). The only reason I can think of is to indicate that the elements are accessed in parallel. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29342#discussion_r2713729502 From wkemper at openjdk.org Wed Jan 21 18:46:05 2026 From: wkemper at openjdk.org (William Kemper) Date: Wed, 21 Jan 2026 18:46:05 GMT Subject: RFR: 8374449: Shenandoah: Leaf locks used by Shenandoah need lower ranks In-Reply-To: References: <4IGKlFzk930jR8ejTkoYOC-eQvpvxlr0HfzJ5Hgr1gI=.7edc9d4e-10b3-4df6-ab8a-7d74dc0abe51@github.com> Message-ID: On Wed, 21 Jan 2026 02:10:14 GMT, Y. Srinivas Ramakrishna wrote: >> Reduce the rank of `safepoint` locks and rename them to avoid confusion with `nosafepoint` ranked locks. > > src/hotspot/share/gc/shenandoah/shenandoahController.hpp line 47: > >> 45: const Mutex::Rank WAITERS_LOCK_RANK = Mutex::safepoint - 5; >> 46: const Mutex::Rank CONTROL_LOCK_RANK = Mutex::nosafepoint - 2; >> 47: > > I see code where we lock gc waiters lock then proceed to take control lock, e.g. > > https://github.com/openjdk/jdk/blob/e25a5a4821d03680d00ab6bdbec727732add8206/src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.cpp#L767 > > which calls: > > https://github.com/openjdk/jdk/blob/e25a5a4821d03680d00ab6bdbec727732add8206/src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.cpp#L703 > > Wouldn't that mean we should rank the latter lower than the former? > > May be I am confusing myself on the direction of locking rank. I thought that we can only take locks in reducing order of rank (so can't take (safepoint - 2) while holding (safepoint - 5))? > > https://github.com/openjdk/jdk/blob/e25a5a4821d03680d00ab6bdbec727732add8206/src/hotspot/share/runtime/mutex.cpp#L452 > > Can you run all of the jtreg tests to see if we are safe across all paths, or if locks need reranking? You are correct on all accounts here, except the basis for control lock is `Mutex::nosafepoint` and the basis for the waiter's locks is `Mutex::safepoint`. `safepoint` is defined as `nosafepoint + 20` so `nosafepoint` _is_ lower. I didn't actually change the rank of the control lock, just pulled it into a shared constant as both `ShControlThread` and `ShGenerationalControlThread` share the value. This branch passed GHA and internal testing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29333#discussion_r2713824630 From ysr at openjdk.org Wed Jan 21 20:44:51 2026 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Wed, 21 Jan 2026 20:44:51 GMT Subject: RFR: 8374449: Shenandoah: Leaf locks used by Shenandoah need lower ranks In-Reply-To: References: <4IGKlFzk930jR8ejTkoYOC-eQvpvxlr0HfzJ5Hgr1gI=.7edc9d4e-10b3-4df6-ab8a-7d74dc0abe51@github.com> Message-ID: On Wed, 21 Jan 2026 18:26:38 GMT, William Kemper wrote: >> src/hotspot/share/gc/shenandoah/shenandoahController.hpp line 47: >> >>> 45: const Mutex::Rank WAITERS_LOCK_RANK = Mutex::safepoint - 5; >>> 46: const Mutex::Rank CONTROL_LOCK_RANK = Mutex::nosafepoint - 2; >>> 47: >> >> I see code where we lock gc waiters lock then proceed to take control lock, e.g. >> >> https://github.com/openjdk/jdk/blob/e25a5a4821d03680d00ab6bdbec727732add8206/src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.cpp#L767 >> >> which calls: >> >> https://github.com/openjdk/jdk/blob/e25a5a4821d03680d00ab6bdbec727732add8206/src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.cpp#L703 >> >> Wouldn't that mean we should rank the latter lower than the former? >> >> May be I am confusing myself on the direction of locking rank. I thought that we can only take locks in reducing order of rank (so can't take (safepoint - 2) while holding (safepoint - 5))? >> >> https://github.com/openjdk/jdk/blob/e25a5a4821d03680d00ab6bdbec727732add8206/src/hotspot/share/runtime/mutex.cpp#L452 >> >> Can you run all of the jtreg tests to see if we are safe across all paths, or if locks need reranking? > > You are correct on all accounts here, except the basis for control lock is `Mutex::nosafepoint` and the basis for the waiter's locks is `Mutex::safepoint`. `safepoint` is defined as `nosafepoint + 20` so `nosafepoint` _is_ lower. I didn't actually change the rank of the control lock, just pulled it into a shared constant as both `ShControlThread` and `ShGenerationalControlThread` share the value. This branch passed GHA and internal testing. Thanks, sorry for my confusion and my sloppy reading of the, ahem, minuend :-) I'll reread more carefully and approve; the ranks now make sense of course. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29333#discussion_r2714270228 From xpeng at openjdk.org Wed Jan 21 23:40:37 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 21 Jan 2026 23:40:37 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v52] In-Reply-To: References: Message-ID: <-1pnCLD-HtBX4HHoFmky8n2-Sl3LQJBUruzFPwIzEoI=.0a9bf502-fe5b-4601-ad39-43f396b8aae2@github.com> > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request incrementally with four additional commits since the last revision: - Rename function is_active_alloc_region to is_atomic_alloc_region - Remove _active_alloc_region flag and directly use field _atomic_top to determine atomic alloc region - Merge branch 'cas-alloc-1' of https://github.com/pengxiaolong/jdk into cas-alloc-1 - Enforce memory ordering for read/write of _atomic_top to fix crash on MacOS ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/bee032ee..bacdb925 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=51 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=50-51 Stats: 53 lines in 11 files changed: 15 ins; 7 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From xpeng at openjdk.org Thu Jan 22 00:09:40 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Thu, 22 Jan 2026 00:09:40 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v53] In-Reply-To: References: Message-ID: <12HyTUOKfTLmGDhBo_C6ca_RQUOOkk2YVo97wyhyZEE=.e2c75f55-e3cb-457b-baf7-fb2b8536a6fb@github.com> > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Missed place calling function is_active_alloc_region ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/bacdb925..07feee51 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=52 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=51-52 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From iwalulya at openjdk.org Thu Jan 22 05:41:45 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 22 Jan 2026 05:41:45 GMT Subject: RFR: 8341630: G1: Adopt PartialArrayState to consolidate marking stack in concurrent marking [v4] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 12:54:36 GMT, Stefan Johansson wrote: >> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactor > > Marked as reviewed by sjohanss (Reviewer). Thanks @kstefanj and @tschatzl for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29249#issuecomment-3782583072 From iwalulya at openjdk.org Thu Jan 22 05:41:47 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 22 Jan 2026 05:41:47 GMT Subject: Integrated: 8341630: G1: Adopt PartialArrayState to consolidate marking stack in concurrent marking In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 10:23:40 GMT, Ivan Walulya wrote: > Hi, > > Please review this change which adopts the `PartialArrayState` mechanism for G1 concurrent marking. > > The `PartialArrayState` mechanism can push multiple continuations to the task queues, so it also solves the single-continuation limitation issue in [JDK-8167480](https://bugs.openjdk.org/browse/JDK-8167480). > > Testing: Mach5 Tier 1-3. This pull request has now been integrated. Changeset: 38a8309b Author: Ivan Walulya URL: https://git.openjdk.org/jdk/commit/38a8309b3f2544fa13448f5217e4227f0e2fe171 Stats: 386 lines in 7 files changed: 133 ins; 219 del; 34 mod 8341630: G1: Adopt PartialArrayState to consolidate marking stack in concurrent marking Co-authored-by: Stefan Johansson Reviewed-by: tschatzl, sjohanss ------------- PR: https://git.openjdk.org/jdk/pull/29249 From xpeng at openjdk.org Thu Jan 22 06:10:04 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Thu, 22 Jan 2026 06:10:04 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v54] In-Reply-To: References: Message-ID: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Remove use AtomicAccess for _top if permits ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/07feee51..1009d847 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=53 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=52-53 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From syan at openjdk.org Thu Jan 22 06:44:09 2026 From: syan at openjdk.org (SendaoYan) Date: Thu, 22 Jan 2026 06:44:09 GMT Subject: RFR: 8376051: gc/stress/TestStressG1Uncommit.java fails assertLessThan: expected that xxx < xxx Message-ID: Hi all, [JDK-8238686](https://bugs.openjdk.org/browse/JDK-8238686) change the default value MinHeapFreeRatio/MaxHeapFreeRatio to 0/100, this change make G1 never uncommit heap memory to OS system, this will make test test/hotspot/jtreg/gc/stress/TestStressG1Uncommit.java fails "assertLessThan: expected that xxx < xxx", and the tested java process never print "Uncommit regions" which checked by this test. This PR set MinHeapFreeRatio/MaxHeapFreeRatio to the original value 40/70 to make this test work expectly, and Use WhileBox.fullGC() instead of System.gc() which will make test more robustness. Change has been verified locally on linux-x64 by run this tests both with release build and fastdebug build. ------------- Commit messages: - 8376051: gc/stress/TestStressG1Uncommit.java fails assertLessThan: expected that xxx < xxx Changes: https://git.openjdk.org/jdk/pull/29357/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29357&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376051 Stats: 14 lines in 1 file changed: 11 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29357/head:pull/29357 PR: https://git.openjdk.org/jdk/pull/29357 From rkennke at openjdk.org Thu Jan 22 07:42:32 2026 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 22 Jan 2026 07:42:32 GMT Subject: RFR: 8375314: Parallel: Crash iterating over unloaded classes for ObjectCountAfterGC event [v2] In-Reply-To: References: Message-ID: <454JhotstVXAoYCPgKyHsyBJU2WywzUgL1uIGzkIIrM=.1d5f261a-dbb4-454c-a348-abff65d1e634@github.com> On Wed, 21 Jan 2026 16:32:21 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that avoids crashes when gathering `ObjectCountAfterGC` JFR statisics. >> >> The cause for the crash is that the code purges metaspace after class unloading/purging after https://bugs.openjdk.org/browse/JDK-8361404. The heap iteration code walks the heap with classes that were unloaded and purged, eventually crashing if for some reason the data is invalid due to metaspace purging potentially uncommitting memory. >> >> Since it is somewhat ugly that we walk objects with dead klasses in them (as it was before the mentioned change), I moved the iteration to after the heap has been compacted, skipping filler objects that might be in there. >> >> Unfortunately I did not manage to write a good reproducer. >> >> Testing: gha, tier1-5, test case succeeding >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * remove WhiteBox references from test, not needed any more The change looks good, thank you! ------------- Marked as reviewed by rkennke (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29318#pullrequestreview-3691037431 From xpeng at openjdk.org Thu Jan 22 07:57:55 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Thu, 22 Jan 2026 07:57:55 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v55] In-Reply-To: References: Message-ID: <8xg_bNa4cDzJr-Rff8QHLvPxaZsRL-PloCG5Y9Ae13g=.c9169438-3a3c-4f0c-8624-52e9a473089c@github.com> > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request incrementally with two additional commits since the last revision: - Not update accounting if no region is unretired to partition - Invoke assert_bounds after updating accounting from ShenandoahAllocator ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/1009d847..f47d086a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=54 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=53-54 Stats: 16 lines in 6 files changed: 8 ins; 4 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From tschatzl at openjdk.org Thu Jan 22 08:10:50 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 22 Jan 2026 08:10:50 GMT Subject: RFR: 8376051: gc/stress/TestStressG1Uncommit.java fails assertLessThan: expected that xxx < xxx In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 06:33:13 GMT, SendaoYan wrote: > Hi all, > > [JDK-8238686](https://bugs.openjdk.org/browse/JDK-8238686) change the default value MinHeapFreeRatio/MaxHeapFreeRatio to 0/100, this change make G1 never uncommit heap memory to OS system, this will make test test/hotspot/jtreg/gc/stress/TestStressG1Uncommit.java fails "assertLessThan: expected that xxx < xxx", and the tested java process never print "Uncommit regions" which checked by this test. > > This PR set MinHeapFreeRatio/MaxHeapFreeRatio to the original value 40/70 to make this test work expectly, and Use WhileBox.fullGC() instead of System.gc() which will make test more robustness. > > Change has been verified locally on linux-x64 by run this tests both with release build and fastdebug build. Looks good. > [JDK-8238686](https://bugs.openjdk.org/browse/JDK-8238686) change the default value MinHeapFreeRatio/MaxHeapFreeRatio to 0/100, this change make G1 never uncommit heap memory to OS system, Fwiw, G1 will still uncommit memory to give back to the OS, just not automatically implied by full gcs. ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29357#pullrequestreview-3691122823 PR Comment: https://git.openjdk.org/jdk/pull/29357#issuecomment-3783074926 From tschatzl at openjdk.org Thu Jan 22 08:27:17 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 22 Jan 2026 08:27:17 GMT Subject: RFR: 8376051: gc/stress/TestStressG1Uncommit.java fails assertLessThan: expected that xxx < xxx In-Reply-To: References: Message-ID: <5tONvebbyF8XOfBP79P-Oyn6ZywqOYF0jQPsQs2Vo4A=.bb24586b-3b7b-455e-ad09-64756cf75d4e@github.com> On Thu, 22 Jan 2026 08:08:01 GMT, Thomas Schatzl wrote: > > [JDK-8238686](https://bugs.openjdk.org/browse/JDK-8238686) change the default value MinHeapFreeRatio/MaxHeapFreeRatio to 0/100, this change make G1 never uncommit heap memory to OS system, > > Fwiw, G1 will still uncommit memory to give back to the OS, just not automatically implied by full gcs. It will re-evaluate and resize the heap at every young gc, based on GC cpu usage. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29357#issuecomment-3783142936 From tschatzl at openjdk.org Thu Jan 22 08:29:29 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 22 Jan 2026 08:29:29 GMT Subject: RFR: 8375314: Parallel: Crash iterating over unloaded classes for ObjectCountAfterGC event [v2] In-Reply-To: <454JhotstVXAoYCPgKyHsyBJU2WywzUgL1uIGzkIIrM=.1d5f261a-dbb4-454c-a348-abff65d1e634@github.com> References: <454JhotstVXAoYCPgKyHsyBJU2WywzUgL1uIGzkIIrM=.1d5f261a-dbb4-454c-a348-abff65d1e634@github.com> Message-ID: On Thu, 22 Jan 2026 07:39:41 GMT, Roman Kennke wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * remove WhiteBox references from test, not needed any more > > The change looks good, thank you! Thanks for your reviews @rkennke @kstefanj @walulyai ------------- PR Comment: https://git.openjdk.org/jdk/pull/29318#issuecomment-3783152251 From tschatzl at openjdk.org Thu Jan 22 08:33:09 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 22 Jan 2026 08:33:09 GMT Subject: Integrated: 8375616: G1: Convert G1BatchedTask to use Atomic In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 14:06:04 GMT, Thomas Schatzl wrote: > Hi all, > > please review the use of `Atomic` for the `G1BatchedTask` class. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: e50bf1f2 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/e50bf1f2a4702ef48cf16cc4f45d034a652bf358 Stats: 8 lines in 2 files changed: 1 ins; 1 del; 6 mod 8375616: G1: Convert G1BatchedTask to use Atomic Reviewed-by: sjohanss, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/29321 From tschatzl at openjdk.org Thu Jan 22 08:33:07 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 22 Jan 2026 08:33:07 GMT Subject: Integrated: 8375314: Parallel: Crash iterating over unloaded classes for ObjectCountAfterGC event In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 13:08:07 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that avoids crashes when gathering `ObjectCountAfterGC` JFR statisics. > > The cause for the crash is that the code purges metaspace after class unloading/purging after https://bugs.openjdk.org/browse/JDK-8361404. The heap iteration code walks the heap with classes that were unloaded and purged, eventually crashing if for some reason the data is invalid due to metaspace purging potentially uncommitting memory. > > Since it is somewhat ugly that we walk objects with dead klasses in them (as it was before the mentioned change), I moved the iteration to after the heap has been compacted, skipping filler objects that might be in there. > > Unfortunately I did not manage to write a good reproducer. > > Testing: gha, tier1-5, test case succeeding > > Thanks, > Thomas This pull request has now been integrated. Changeset: f3381f0f Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/f3381f0ffe2207e1765558f6f49e5a0280a3f920 Stats: 145 lines in 7 files changed: 129 ins; 11 del; 5 mod 8375314: Parallel: Crash iterating over unloaded classes for ObjectCountAfterGC event Reviewed-by: rkennke, sjohanss, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/29318 From tschatzl at openjdk.org Thu Jan 22 08:33:08 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 22 Jan 2026 08:33:08 GMT Subject: RFR: 8375616: G1: Convert G1BatchedTask to use Atomic In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 08:14:17 GMT, Stefan Johansson wrote: >> Hi all, >> >> please review the use of `Atomic` for the `G1BatchedTask` class. >> >> Testing: gha >> >> Thanks, >> Thomas > > Marked as reviewed by sjohanss (Reviewer). Thanks @kstefanj @kimbarrett for your review ------------- PR Comment: https://git.openjdk.org/jdk/pull/29321#issuecomment-3783156142 From tschatzl at openjdk.org Thu Jan 22 08:35:06 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 22 Jan 2026 08:35:06 GMT Subject: RFR: 8375977: G1: Convert JVMCICleaningTask to use Atomic In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 16:50:27 GMT, Kim Barrett wrote: >> Hi all, >> >> please review this conversion of `JVMCICleaningTask` to use `Atomic`. >> >> Testing: gha >> >> Thanks, >> Thomas > > Looks good, and trivial. Thanks @kimbarrett for your review ------------- PR Comment: https://git.openjdk.org/jdk/pull/29343#issuecomment-3783173555 From tschatzl at openjdk.org Thu Jan 22 08:37:31 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 22 Jan 2026 08:37:31 GMT Subject: RFR: 8375982: G1: Convert G1YoungCollector helper classes to use Atomic In-Reply-To: <6eX4PZ5crpZ8tZeUJHdYO3Q_vLS7cx9ESJZbLrG6Bbo=.071f6b55-0f1b-4c4f-92d1-040496396fbe@github.com> References: <6eX4PZ5crpZ8tZeUJHdYO3Q_vLS7cx9ESJZbLrG6Bbo=.071f6b55-0f1b-4c4f-92d1-040496396fbe@github.com> Message-ID: On Wed, 21 Jan 2026 12:48:49 GMT, Thomas Schatzl wrote: > Hi all, > > please review these changes to convert uses of `Atomic` in some `G1YoungCollector` helper classes. > > Testing: gha > > Thanks, > Thomas The failure is about code compilation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29346#issuecomment-3783179624 From tschatzl at openjdk.org Thu Jan 22 08:38:49 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 22 Jan 2026 08:38:49 GMT Subject: RFR: 8375978: G1: Convert G1Policy to use Atomic In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 16:52:41 GMT, Kim Barrett wrote: >> Hi all, >> >> please review this conversion of `G1Policy` to use `Atomic`. >> >> Also removed the unused `_young_list_max_length` instead of unnecessarily converting it. >> >> Testing: gha >> >> Thanks, >> Thomas > > Looks good, and trivial. Thanks @kimbarrett for your review ------------- PR Comment: https://git.openjdk.org/jdk/pull/29344#issuecomment-3783174821 From tschatzl at openjdk.org Thu Jan 22 08:38:51 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 22 Jan 2026 08:38:51 GMT Subject: Integrated: 8375978: G1: Convert G1Policy to use Atomic In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 11:59:23 GMT, Thomas Schatzl wrote: > Hi all, > > please review this conversion of `G1Policy` to use `Atomic`. > > Also removed the unused `_young_list_max_length` instead of unnecessarily converting it. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 03038d80 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/03038d802cc43b7694f554978ac9de8edca8a954 Stats: 10 lines in 2 files changed: 0 ins; 3 del; 7 mod 8375978: G1: Convert G1Policy to use Atomic Reviewed-by: kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/29344 From tschatzl at openjdk.org Thu Jan 22 08:38:51 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 22 Jan 2026 08:38:51 GMT Subject: Integrated: 8375977: G1: Convert JVMCICleaningTask to use Atomic In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 11:49:56 GMT, Thomas Schatzl wrote: > Hi all, > > please review this conversion of `JVMCICleaningTask` to use `Atomic`. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 63be87d7 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/63be87d7f38a83c5fcdf59b54c6d63e0f0ca34d6 Stats: 9 lines in 2 files changed: 3 ins; 1 del; 5 mod 8375977: G1: Convert JVMCICleaningTask to use Atomic Reviewed-by: kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/29343 From tschatzl at openjdk.org Thu Jan 22 08:40:56 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 22 Jan 2026 08:40:56 GMT Subject: RFR: 8375981: G1: Convert G1RemSet helper classes to use Atomic Message-ID: Hi all, please review this conversion of `G1RemSet` helper classes to use `Atomic<>`. There has been one additional non-volatile member that has been converted to use `Atomic`. Testing: gha, tier1 Thanks, Thomas ------------- Commit messages: - 8375981 Changes: https://git.openjdk.org/jdk/pull/29345/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29345&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375981 Stats: 28 lines in 1 file changed: 6 ins; 0 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/29345.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29345/head:pull/29345 PR: https://git.openjdk.org/jdk/pull/29345 From sjohanss at openjdk.org Thu Jan 22 08:46:00 2026 From: sjohanss at openjdk.org (Stefan Johansson) Date: Thu, 22 Jan 2026 08:46:00 GMT Subject: RFR: 8375541: G1: Race in G1BarrierSet::write_ref_field_post() [v3] In-Reply-To: <5dwpiJA36VF157--z9mZhD0EOQgtopK3iEo5xqzP3YU=.14feb170-5a35-477f-8c1c-e3e4607992c2@github.com> References: <5dwpiJA36VF157--z9mZhD0EOQgtopK3iEo5xqzP3YU=.14feb170-5a35-477f-8c1c-e3e4607992c2@github.com> Message-ID: On Wed, 21 Jan 2026 14:02:31 GMT, Thomas Schatzl wrote: >> Hi all, >> >> during conversion of card table code to use `Atomic` I think I found the following error: the code in `G1BarrierSet::write_ref_field_post` is wrong in that it allows reload of the `_card_table` value, which is exactly what the existing code imo wrongly fails to ensure. even if it does not, making the load explicit improves reading. >> >> To not let this change get lost in that conversion, and potentially for backport to 26, I factored it out in this change. >> >> There is no known issue caused by this code in particular, one other bug I'm working on that just looks like what could be caused by this is not fixed. >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * walulyai review Marked as reviewed by sjohanss (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29311#pullrequestreview-3691252433 From syan at openjdk.org Thu Jan 22 08:59:37 2026 From: syan at openjdk.org (SendaoYan) Date: Thu, 22 Jan 2026 08:59:37 GMT Subject: RFR: 8376051: gc/stress/TestStressG1Uncommit.java fails assertLessThan: expected that xxx < xxx In-Reply-To: <5tONvebbyF8XOfBP79P-Oyn6ZywqOYF0jQPsQs2Vo4A=.bb24586b-3b7b-455e-ad09-64756cf75d4e@github.com> References: <5tONvebbyF8XOfBP79P-Oyn6ZywqOYF0jQPsQs2Vo4A=.bb24586b-3b7b-455e-ad09-64756cf75d4e@github.com> Message-ID: On Thu, 22 Jan 2026 08:24:08 GMT, Thomas Schatzl wrote: > It will re-evaluate and resize the heap at every young gc, based on GC cpu usage. What I meant is the free heap memory ratio will never greater than 100%, so when the value of MaxHeapFreeRatio is seted to 100, G1 will never give back memory to OS? I am not familiar with GC. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29357#issuecomment-3783269812 From shade at openjdk.org Thu Jan 22 09:19:56 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 22 Jan 2026 09:19:56 GMT Subject: RFR: 8376051: gc/stress/TestStressG1Uncommit.java fails assertLessThan: expected that xxx < xxx In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 06:33:13 GMT, SendaoYan wrote: > Hi all, > > [JDK-8238686](https://bugs.openjdk.org/browse/JDK-8238686) change the default value MinHeapFreeRatio/MaxHeapFreeRatio to 0/100, this change make G1 never uncommit heap memory to OS system, this will make test test/hotspot/jtreg/gc/stress/TestStressG1Uncommit.java fails "assertLessThan: expected that xxx < xxx", and the tested java process never print "Uncommit regions" which checked by this test. > > This PR set MinHeapFreeRatio/MaxHeapFreeRatio to the original value 40/70 to make this test work expectly, and Use WhileBox.fullGC() instead of System.gc() which will make test more robustness. > > Change has been verified locally on linux-x64 by run this tests both with release build and fastdebug build. I don't see why do we need `WhiteBox` for this? Why wouldn't `System.gc()` suffice? ------------- PR Review: https://git.openjdk.org/jdk/pull/29357#pullrequestreview-3691418923 From shade at openjdk.org Thu Jan 22 09:21:59 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 22 Jan 2026 09:21:59 GMT Subject: RFR: 8375982: G1: Convert G1YoungCollector helper classes to use Atomic In-Reply-To: <6eX4PZ5crpZ8tZeUJHdYO3Q_vLS7cx9ESJZbLrG6Bbo=.071f6b55-0f1b-4c4f-92d1-040496396fbe@github.com> References: <6eX4PZ5crpZ8tZeUJHdYO3Q_vLS7cx9ESJZbLrG6Bbo=.071f6b55-0f1b-4c4f-92d1-040496396fbe@github.com> Message-ID: On Wed, 21 Jan 2026 12:48:49 GMT, Thomas Schatzl wrote: > Hi all, > > please review these changes to convert uses of `Atomic` in some `G1YoungCollector` helper classes. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29346#pullrequestreview-3691426133 From shade at openjdk.org Thu Jan 22 09:26:09 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 22 Jan 2026 09:26:09 GMT Subject: RFR: 8375981: G1: Convert G1RemSet helper classes to use Atomic In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 12:31:34 GMT, Thomas Schatzl wrote: > Hi all, > > please review this conversion of `G1RemSet` helper classes to use `Atomic<>`. > > There has been one additional non-volatile member that has been converted to use `Atomic`. > > Testing: gha, tier1 > > Thanks, > Thomas src/hotspot/share/gc/g1/g1RemSet.cpp line 234: > 232: // either. > 233: } > 234: cur = next; Wait a second, is it really the same? `next` is from fetch-then-add, so it is "old" value? Original code re-reads `_cur_dirty_regions`, which looks more like "new" value after fetch-then-add? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29345#discussion_r2716035412 From shade at openjdk.org Thu Jan 22 09:27:02 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 22 Jan 2026 09:27:02 GMT Subject: RFR: 8375966: G1: Convert G1UpdateRegionLivenessAndSelectForRebuildTask to use Atomic In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 10:56:51 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to convert `G1UpdateRegionLivenessAndSelectForRebuildTask` to use `Atomic`. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29340#pullrequestreview-3691452219 From shade at openjdk.org Thu Jan 22 09:27:02 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 22 Jan 2026 09:27:02 GMT Subject: RFR: 8375964: G1: Convert G1BuildCandidateRegionsTask to use Atomic In-Reply-To: <-AQiYq3R3DDkNgH-BG7L245lx6Rz1ezlizPt3CNmhvw=.decaa9ff-3daf-45eb-aa0a-ebd4a7ba346e@github.com> References: <-AQiYq3R3DDkNgH-BG7L245lx6Rz1ezlizPt3CNmhvw=.decaa9ff-3daf-45eb-aa0a-ebd4a7ba346e@github.com> Message-ID: On Wed, 21 Jan 2026 10:50:41 GMT, Thomas Schatzl wrote: > Hi all, > > please review the changes to let `G1BuildCandidateRegionsTask` use `Atomic`. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29339#pullrequestreview-3691453770 From tschatzl at openjdk.org Thu Jan 22 09:34:51 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 22 Jan 2026 09:34:51 GMT Subject: RFR: 8375981: G1: Convert G1RemSet helper classes to use Atomic [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review this conversion of `G1RemSet` helper classes to use `Atomic<>`. > > There has been one additional non-volatile member that has been converted to use `Atomic`. > > Testing: gha, tier1 > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * shade review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29345/files - new: https://git.openjdk.org/jdk/pull/29345/files/ebc28c33..9cd2c155 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29345&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29345&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29345.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29345/head:pull/29345 PR: https://git.openjdk.org/jdk/pull/29345 From tschatzl at openjdk.org Thu Jan 22 09:34:53 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 22 Jan 2026 09:34:53 GMT Subject: RFR: 8375981: G1: Convert G1RemSet helper classes to use Atomic [v2] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 09:23:20 GMT, Aleksey Shipilev wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * shade review > > src/hotspot/share/gc/g1/g1RemSet.cpp line 234: > >> 232: // either. >> 233: } >> 234: cur = next; > > Wait a second, is it really the same? `next` is from fetch-then-add, so it is "old" value? Original code re-reads `_cur_dirty_regions`, which looks more like "new" value after fetch-then-add? Thanks for catching this. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29345#discussion_r2716066124 From shade at openjdk.org Thu Jan 22 09:42:09 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 22 Jan 2026 09:42:09 GMT Subject: RFR: 8375981: G1: Convert G1RemSet helper classes to use Atomic [v2] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 09:34:51 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this conversion of `G1RemSet` helper classes to use `Atomic<>`. >> >> There has been one additional non-volatile member that has been converted to use `Atomic`. >> >> Testing: gha, tier1 >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * shade review Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29345#pullrequestreview-3691519896 From syan at openjdk.org Thu Jan 22 10:09:56 2026 From: syan at openjdk.org (SendaoYan) Date: Thu, 22 Jan 2026 10:09:56 GMT Subject: RFR: 8376051: gc/stress/TestStressG1Uncommit.java fails assertLessThan: expected that xxx < xxx In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 09:17:19 GMT, Aleksey Shipilev wrote: > I don't see why do we need `WhiteBox` for this? Why wouldn't `System.gc()` suffice? I do not observed this test fails intermittently. Maybe `System.gc()` will be suffice, I think `WhiteBox` will make test more robustness. I think revert the `WhiteBox` change also acceptable. Should I do that? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29357#issuecomment-3783559487 From shade at openjdk.org Thu Jan 22 10:25:26 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 22 Jan 2026 10:25:26 GMT Subject: RFR: 8376051: gc/stress/TestStressG1Uncommit.java fails assertLessThan: expected that xxx < xxx In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 10:07:20 GMT, SendaoYan wrote: > I think revert the `WhiteBox` change also acceptable. Should I do that? Yes, I think `System.gc()` is still cleaner. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29357#issuecomment-3783623124 From shade at openjdk.org Thu Jan 22 10:44:28 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 22 Jan 2026 10:44:28 GMT Subject: RFR: 8375541: G1: Race in G1BarrierSet::write_ref_field_post() [v3] In-Reply-To: <5dwpiJA36VF157--z9mZhD0EOQgtopK3iEo5xqzP3YU=.14feb170-5a35-477f-8c1c-e3e4607992c2@github.com> References: <5dwpiJA36VF157--z9mZhD0EOQgtopK3iEo5xqzP3YU=.14feb170-5a35-477f-8c1c-e3e4607992c2@github.com> Message-ID: On Wed, 21 Jan 2026 14:02:31 GMT, Thomas Schatzl wrote: >> Hi all, >> >> during conversion of card table code to use `Atomic` I think I found the following error: the code in `G1BarrierSet::write_ref_field_post` is wrong in that it allows reload of the `_card_table` value, which is exactly what the existing code imo wrongly fails to ensure. even if it does not, making the load explicit improves reading. >> >> To not let this change get lost in that conversion, and potentially for backport to 26, I factored it out in this change. >> >> There is no known issue caused by this code in particular, one other bug I'm working on that just looks like what could be caused by this is not fixed. >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * walulyai review Not sure how much this actually saves us from C++ UB behavior wrt data races, but the fix does not hurt either. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29311#pullrequestreview-3691778816 From tschatzl at openjdk.org Thu Jan 22 10:45:48 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 22 Jan 2026 10:45:48 GMT Subject: RFR: 8376051: gc/stress/TestStressG1Uncommit.java fails assertLessThan: expected that xxx < xxx In-Reply-To: References: <5tONvebbyF8XOfBP79P-Oyn6ZywqOYF0jQPsQs2Vo4A=.bb24586b-3b7b-455e-ad09-64756cf75d4e@github.com> Message-ID: <4_WqCEjqY1XPn0yGR1CxVLW7HhhLYI5FL3BFQdjl_lQ=.1c1c1fbd-82e5-47d1-9946-48d82c2dc2a3@github.com> On Thu, 22 Jan 2026 08:57:03 GMT, SendaoYan wrote: > > It will re-evaluate and resize the heap at every young gc, based on GC cpu usage. > > What I meant is the free heap memory ratio will never greater than 100%, so when the value of MaxHeapFreeRatio is seted to 100, G1 will never give back memory to OS? I am not familiar with GC. These ratios (actually percentages) only every applied to full gcs, and only for Serial/Parallel/G1 and maybe Shenandoah. Since JDK 26, G1 will re-evaluate the "best" heap size based on GC cpu usage. So if lots of time, more than the goal, `GCTimeRatio`, is spent in GC activity, G1 will shrink the heap and give back memory to the OS. (Actually, in many applications, G1 is keeping a smaller footprint now). G1 will re-evaluate and shrink/expand at every young gc (https://bugs.openjdk.org/browse/JDK-8238687), not only full gc/System.gc() based on arbitrary Min/MaxHeapFreeRatio. The [CSR](https://bugs.openjdk.org/browse/JDK-8375300) for the change causing this test failure hopefully explains the reason for this change well enough. Actually we are not sure how/why this test failure slipped through. > > I think revert the WhiteBox change also acceptable. Should I do that? > Yes, I think System.gc() is still cleaner. In this case, `System.gc()` and `WhiteBox.fullGC()` act exactly the same so I would also keep `System.gc()` just to keep the code simpler. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29357#issuecomment-3783709625 From tschatzl at openjdk.org Thu Jan 22 11:07:18 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 22 Jan 2026 11:07:18 GMT Subject: RFR: 8375541: G1: Race in G1BarrierSet::write_ref_field_post() [v3] In-Reply-To: References: <5dwpiJA36VF157--z9mZhD0EOQgtopK3iEo5xqzP3YU=.14feb170-5a35-477f-8c1c-e3e4607992c2@github.com> Message-ID: On Thu, 22 Jan 2026 10:41:51 GMT, Aleksey Shipilev wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * walulyai review > > Not sure how much this actually saves us from C++ UB behavior wrt data races, but the fix does not hurt either. Thanks @shipilev @kstefanj @walulyai for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/29311#issuecomment-3783798995 From tschatzl at openjdk.org Thu Jan 22 11:07:20 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 22 Jan 2026 11:07:20 GMT Subject: Integrated: 8375541: G1: Race in G1BarrierSet::write_ref_field_post() In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 08:17:05 GMT, Thomas Schatzl wrote: > Hi all, > > during conversion of card table code to use `Atomic` I think I found the following error: the code in `G1BarrierSet::write_ref_field_post` is wrong in that it allows reload of the `_card_table` value, which is exactly what the existing code imo wrongly fails to ensure. even if it does not, making the load explicit improves reading. > > To not let this change get lost in that conversion, and potentially for backport to 26, I factored it out in this change. > > There is no known issue caused by this code in particular, one other bug I'm working on that just looks like what could be caused by this is not fixed. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 0ad81fbd Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/0ad81fbd161edbc8479e5af5c0f8d6098f6c72d1 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8375541: G1: Race in G1BarrierSet::write_ref_field_post() Reviewed-by: iwalulya, sjohanss, shade ------------- PR: https://git.openjdk.org/jdk/pull/29311 From iwalulya at openjdk.org Thu Jan 22 11:11:02 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 22 Jan 2026 11:11:02 GMT Subject: RFR: 8340470: G1: Adopt PartialArrayState to consolidate marking stack in Full GC [v5] In-Reply-To: References: Message-ID: <8yO85p3OtGdy28zdxfq-Zgq_OPmP0FTXXdrduwSYEGw=.d3094af1-ef69-414b-8a23-41071ec6ca11@github.com> On Tue, 20 Jan 2026 10:39:29 GMT, Stefan Johansson wrote: >> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: >> >> kstefanj refactor rename > > Looks good. > > Me and Ivan discussed moving a couple of more functions into the inline.hpp file but left that for later, see [JDK-8375690](https://bugs.openjdk.org/browse/JDK-8375690). Thanks @kstefanj and @tschatzl for the reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/29114#issuecomment-3783810101 From iwalulya at openjdk.org Thu Jan 22 11:11:04 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 22 Jan 2026 11:11:04 GMT Subject: Integrated: 8340470: G1: Adopt PartialArrayState to consolidate marking stack in Full GC In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 11:18:23 GMT, Ivan Walulya wrote: > Hi, > > Please review this change adopting `PartialArrayState` introduced by [JDK-8337709](https://bugs.openjdk.org/browse/JDK-8337709) to consolidate marking queue sets (oop queue set and objArray queue set) into single queue set in G1 Full GC. > > Testing: Tier 1-5 This pull request has now been integrated. Changeset: 66e950e9 Author: Ivan Walulya URL: https://git.openjdk.org/jdk/commit/66e950e9b6414617952d22200831be5b0cafee85 Stats: 180 lines in 8 files changed: 48 ins; 70 del; 62 mod 8340470: G1: Adopt PartialArrayState to consolidate marking stack in Full GC Co-authored-by: Stefan Johansson Reviewed-by: sjohanss, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/29114 From tschatzl at openjdk.org Thu Jan 22 11:54:41 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 22 Jan 2026 11:54:41 GMT Subject: RFR: 8375982: G1: Convert G1YoungCollector helper classes to use Atomic In-Reply-To: References: <6eX4PZ5crpZ8tZeUJHdYO3Q_vLS7cx9ESJZbLrG6Bbo=.071f6b55-0f1b-4c4f-92d1-040496396fbe@github.com> Message-ID: <8yXyXz5zkX4NCTHBJ278_Bah0_xM1hHJedohrTEN3cQ=.04708659-326c-4168-aec3-d50af7c16440@github.com> On Thu, 22 Jan 2026 09:19:07 GMT, Aleksey Shipilev wrote: >> Hi all, >> >> please review these changes to convert uses of `Atomic` in some `G1YoungCollector` helper classes. >> >> Testing: gha >> >> Thanks, >> Thomas > > Marked as reviewed by shade (Reviewer). Thanks @shipilev @kimbarrett for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/29346#issuecomment-3783981886 From tschatzl at openjdk.org Thu Jan 22 11:54:43 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 22 Jan 2026 11:54:43 GMT Subject: Integrated: 8375982: G1: Convert G1YoungCollector helper classes to use Atomic In-Reply-To: <6eX4PZ5crpZ8tZeUJHdYO3Q_vLS7cx9ESJZbLrG6Bbo=.071f6b55-0f1b-4c4f-92d1-040496396fbe@github.com> References: <6eX4PZ5crpZ8tZeUJHdYO3Q_vLS7cx9ESJZbLrG6Bbo=.071f6b55-0f1b-4c4f-92d1-040496396fbe@github.com> Message-ID: On Wed, 21 Jan 2026 12:48:49 GMT, Thomas Schatzl wrote: > Hi all, > > please review these changes to convert uses of `Atomic` in some `G1YoungCollector` helper classes. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 5e0ed3f4 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/5e0ed3f408b6afd7496e0e0da207f7e372b0d446 Stats: 14 lines in 2 files changed: 2 ins; 0 del; 12 mod 8375982: G1: Convert G1YoungCollector helper classes to use Atomic Reviewed-by: kbarrett, shade ------------- PR: https://git.openjdk.org/jdk/pull/29346 From syan at openjdk.org Thu Jan 22 12:03:45 2026 From: syan at openjdk.org (SendaoYan) Date: Thu, 22 Jan 2026 12:03:45 GMT Subject: RFR: 8376051: gc/stress/TestStressG1Uncommit.java fails assertLessThan: expected that xxx < xxx [v2] In-Reply-To: References: Message-ID: > Hi all, > > [JDK-8238686](https://bugs.openjdk.org/browse/JDK-8238686) change the default value MinHeapFreeRatio/MaxHeapFreeRatio to 0/100, this change make G1 never uncommit heap memory to OS system, this will make test test/hotspot/jtreg/gc/stress/TestStressG1Uncommit.java fails "assertLessThan: expected that xxx < xxx", and the tested java process never print "Uncommit regions" which checked by this test. > > This PR set MinHeapFreeRatio/MaxHeapFreeRatio to the original value 40/70 to make this test work expectly. > > Change has been verified locally on linux-x64 by run this tests both with release build and fastdebug build. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Revert the use of WhiteBox.fullGC() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29357/files - new: https://git.openjdk.org/jdk/pull/29357/files/6083d958..9035a0b3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29357&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29357&range=00-01 Stats: 11 lines in 1 file changed: 0 ins; 9 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29357/head:pull/29357 PR: https://git.openjdk.org/jdk/pull/29357 From syan at openjdk.org Thu Jan 22 12:13:50 2026 From: syan at openjdk.org (SendaoYan) Date: Thu, 22 Jan 2026 12:13:50 GMT Subject: RFR: 8376051: gc/stress/TestStressG1Uncommit.java fails assertLessThan: expected that xxx < xxx In-Reply-To: <4_WqCEjqY1XPn0yGR1CxVLW7HhhLYI5FL3BFQdjl_lQ=.1c1c1fbd-82e5-47d1-9946-48d82c2dc2a3@github.com> References: <5tONvebbyF8XOfBP79P-Oyn6ZywqOYF0jQPsQs2Vo4A=.bb24586b-3b7b-455e-ad09-64756cf75d4e@github.com> <4_WqCEjqY1XPn0yGR1CxVLW7HhhLYI5FL3BFQdjl_lQ=.1c1c1fbd-82e5-47d1-9946-48d82c2dc2a3@github.com> Message-ID: On Thu, 22 Jan 2026 10:42:38 GMT, Thomas Schatzl wrote: > In this case, `System.gc()` and `WhiteBox.fullGC()` act exactly the same so I would also keep `System.gc()` just to keep the code simpler. Thanks your detail explain. The `WhiteBox` change has been revert. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29357#issuecomment-3784063988 From lkorinth at openjdk.org Thu Jan 22 12:32:55 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 22 Jan 2026 12:32:55 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v4] In-Reply-To: References: Message-ID: > This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. > > It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. > > This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. > > I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - remove commented out code - Stefan J 4 - Stefan J 3 - Stefan J 2 - Stefan J 1 - Merge branch '8373253' into 8367993 - Merge branch 'master' into _8373253 - Fixup after comment from Ivan. - Merge branch 'master' into _8367993 - 8367993: G1: Speed up ConcurrentMark initialization - ... and 1 more: https://git.openjdk.org/jdk/compare/eee58545...9d9df671 ------------- Changes: https://git.openjdk.org/jdk/pull/28723/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28723&range=03 Stats: 102 lines in 10 files changed: 54 ins; 25 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/28723.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28723/head:pull/28723 PR: https://git.openjdk.org/jdk/pull/28723 From lkorinth at openjdk.org Thu Jan 22 12:32:57 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 22 Jan 2026 12:32:57 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v3] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 12:58:43 GMT, Leo Korinth wrote: >> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. >> >> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. >> >> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. >> >> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. > > Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 564 commits: > > - Merge branch '8373253' into 8367993 > - Merge branch 'master' into _8373253 > - Merge branch 'master' into _8367993 > - 8366058: Outdated comment in WinCAPISeedGenerator > > Reviewed-by: mullan > - 8357258: x86: Improve receiver type profiling reliability > > Reviewed-by: kvn, vlivanov > - 8373704: Improve "SocketException: Protocol family unavailable" message > > Reviewed-by: lucy, jpai > - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently > > Reviewed-by: jiefu, jbhateja, erfang, qamai > - 8343809: Add requires tag to mark tests that are incompatible with exploded image > > Reviewed-by: alanb, dholmes > - 8374465: Spurious dot in documentation for JVMTI ClassLoad > > Reviewed-by: kbarrett > - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket > > Reviewed-by: djelinski, mpowers, ascarpino > - ... and 554 more: https://git.openjdk.org/jdk/compare/2aa8aa4b...28ccbb68 I have tested this with tier1-5 without related failures. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28723#issuecomment-3784140286 From lkorinth at openjdk.org Thu Jan 22 12:32:58 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 22 Jan 2026 12:32:58 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v3] In-Reply-To: References: <57b1T2a6eGddz4Epg4zzhLPemdLm83uxN1IeWei-VYU=.36173a35-556c-4481-afdb-8d9d060bfaaa@github.com> Message-ID: On Mon, 12 Jan 2026 15:29:03 GMT, Thomas Schatzl wrote: >> I see no reason for skipping a periodic GC because we have not yet initialized concurrent mark. If the user for example configured periodic full gc (not doing a periodic concurrent GC) we should not prevent this, just because no young collection has yet been done. >> >> Also, there should be no problem starting a concurrent periodic collection from what I can tell, since this will trigger initialization of concurrent mark. I did a quick test to verify this is ok (and it is), but there can of course be some corner case that I'm missing. In that case I would like to understand the corner case better to see if we can come up with a better approach than skipping the periodic collections until a young GC has been triggered. > > An unrelated issue could be that the task is run too early, before initialization is completed. However `G1ServiceTask` prevents that to happen already. So I also do not think we should keep this unless there is a demonstrated issue. I removed it, and it seems to work. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2716694240 From lkorinth at openjdk.org Thu Jan 22 12:33:01 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 22 Jan 2026 12:33:01 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v3] In-Reply-To: References: Message-ID: <1ukUbAGP1rEI9iLFClTCAzoV05DehttEMxKK6c6JWFA=.e15e1ec4-80ff-481c-8f68-950e8ae8ff91@github.com> On Mon, 12 Jan 2026 13:32:35 GMT, Thomas Schatzl wrote: >> src/hotspot/share/gc/g1/g1Policy.cpp line 744: >> >>> 742: if (!_g1h->concurrent_mark()->is_fully_initialized()) { >>> 743: return false; >>> 744: } >> >> Is this needed? The `in_progress()` check below makes sure to only check the cm_thread when fully initialized. > > And this can never return true during initialization as no GC can have happened so that we end up in the Prepare Mixed GC I removed it, and it seems to work. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2716695044 From lkorinth at openjdk.org Thu Jan 22 12:36:42 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 22 Jan 2026 12:36:42 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v5] In-Reply-To: References: Message-ID: > This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. > > It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. > > This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. > > I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. Leo Korinth has updated the pull request incrementally with six additional commits since the last revision: - Merge branch '_8373253' into _8367993 - rename of method - Proposal by Stefan J - wip - Revert "8373253: Re-work InjectGCWorkerCreationFailure for future changes" This reverts commit d45ea8817ab2303b2decd8cbb2cd1bf5280aa181. - Revert "Fixup after comment from Ivan." This reverts commit 2aa8aa4b68027b62a8d4be1b86720fadfa48dda5. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28723/files - new: https://git.openjdk.org/jdk/pull/28723/files/9d9df671..2e370ce1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28723&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28723&range=03-04 Stats: 25 lines in 2 files changed: 18 ins; 7 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28723.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28723/head:pull/28723 PR: https://git.openjdk.org/jdk/pull/28723 From shade at openjdk.org Thu Jan 22 12:54:11 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 22 Jan 2026 12:54:11 GMT Subject: RFR: 8376051: gc/stress/TestStressG1Uncommit.java fails assertLessThan: expected that xxx < xxx [v2] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 12:03:45 GMT, SendaoYan wrote: >> Hi all, >> >> [JDK-8238686](https://bugs.openjdk.org/browse/JDK-8238686) change the default value MinHeapFreeRatio/MaxHeapFreeRatio to 0/100, this change make G1 do less uncommit heap memory to OS system, this will make test test/hotspot/jtreg/gc/stress/TestStressG1Uncommit.java fails "assertLessThan: expected that xxx < xxx", and the tested java process never print "Uncommit regions" which checked by this test. >> >> This PR set MinHeapFreeRatio/MaxHeapFreeRatio to the original value 40/70 to make this test work expectly. >> >> Change has been verified locally on linux-x64 by run this tests both with release build and fastdebug build. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Revert the use of WhiteBox.fullGC() Looks fine to me, thanks! ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29357#pullrequestreview-3692301173 From tschatzl at openjdk.org Thu Jan 22 13:08:58 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 22 Jan 2026 13:08:58 GMT Subject: RFR: 8375966: G1: Convert G1UpdateRegionLivenessAndSelectForRebuildTask to use Atomic [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review this change to convert `G1UpdateRegionLivenessAndSelectForRebuildTask` to use `Atomic`. > > Testing: gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * kbarrett review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29340/files - new: https://git.openjdk.org/jdk/pull/29340/files/549c519d..7a17ca02 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29340&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29340&range=00-01 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29340.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29340/head:pull/29340 PR: https://git.openjdk.org/jdk/pull/29340 From tschatzl at openjdk.org Thu Jan 22 13:25:02 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 22 Jan 2026 13:25:02 GMT Subject: RFR: 8375974: G1: Convert G1FullCollector to use Atomic [v2] In-Reply-To: <6WLOSv0nfMvvwt_nov7cwNo6Zx-_BX4EkZ735UZZCt0=.82351a7b-6c64-4214-90f8-e7173e095bc7@github.com> References: <6WLOSv0nfMvvwt_nov7cwNo6Zx-_BX4EkZ735UZZCt0=.82351a7b-6c64-4214-90f8-e7173e095bc7@github.com> Message-ID: > Hi all, > > please review this change to convert `G1FullCollector` to use `Atomic`. > > Testing: gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * kbarrett review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29342/files - new: https://git.openjdk.org/jdk/pull/29342/files/e7be9c41..c139f731 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29342&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29342&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29342.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29342/head:pull/29342 PR: https://git.openjdk.org/jdk/pull/29342 From tschatzl at openjdk.org Thu Jan 22 13:52:57 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 22 Jan 2026 13:52:57 GMT Subject: RFR: 8375983: G1: Convert G1ConcurrentRefineStats to use Atomic [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that converts `G1ConcurrentRefineStats` to use `Atomic`. > > The only notable thing is that there has been need to expand the assignment in `reset()` since the assignment operator for `Atomic` is not defined, and I did not see it worth adding one. > > Testing: gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * move changes to inline.hpp files to reduce line lengths of hpp file * adjust includes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29347/files - new: https://git.openjdk.org/jdk/pull/29347/files/1d017660..8b6d3106 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29347&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29347&range=00-01 Stats: 34 lines in 9 files changed: 3 ins; 4 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/29347.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29347/head:pull/29347 PR: https://git.openjdk.org/jdk/pull/29347 From tschatzl at openjdk.org Thu Jan 22 13:54:41 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 22 Jan 2026 13:54:41 GMT Subject: RFR: 8376051: gc/stress/TestStressG1Uncommit.java fails assertLessThan: expected that xxx < xxx [v2] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 12:03:45 GMT, SendaoYan wrote: >> Hi all, >> >> [JDK-8238686](https://bugs.openjdk.org/browse/JDK-8238686) change the default value MinHeapFreeRatio/MaxHeapFreeRatio to 0/100, this change make G1 do less uncommit heap memory to OS system, this will make test test/hotspot/jtreg/gc/stress/TestStressG1Uncommit.java fails "assertLessThan: expected that xxx < xxx", and the tested java process never print "Uncommit regions" which checked by this test. >> >> This PR set MinHeapFreeRatio/MaxHeapFreeRatio to the original value 40/70 to make this test work expectly. >> >> Change has been verified locally on linux-x64 by run this tests both with release build and fastdebug build. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Revert the use of WhiteBox.fullGC() Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29357#pullrequestreview-3692559799 From tschatzl at openjdk.org Thu Jan 22 14:38:50 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 22 Jan 2026 14:38:50 GMT Subject: RFR: 8375983: G1: Convert G1ConcurrentRefineStats to use Atomic [v3] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that converts `G1ConcurrentRefineStats` to use `Atomic`. > > The only notable thing is that there has been need to expand the assignment in `reset()` since the assignment operator for `Atomic` is not defined, and I did not see it worth adding one. > > Testing: gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * add .inline.hpp file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29347/files - new: https://git.openjdk.org/jdk/pull/29347/files/8b6d3106..b95d14c9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29347&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29347&range=01-02 Stats: 118 lines in 1 file changed: 118 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29347.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29347/head:pull/29347 PR: https://git.openjdk.org/jdk/pull/29347 From sjohanss at openjdk.org Thu Jan 22 14:52:13 2026 From: sjohanss at openjdk.org (Stefan Johansson) Date: Thu, 22 Jan 2026 14:52:13 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v5] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 12:36:42 GMT, Leo Korinth wrote: >> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. >> >> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. >> >> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. >> >> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. > > Leo Korinth has updated the pull request incrementally with six additional commits since the last revision: > > - Merge branch '_8373253' into _8367993 > - rename of method > - Proposal by Stefan J > - wip > - Revert "8373253: Re-work InjectGCWorkerCreationFailure for future changes" > > This reverts commit d45ea8817ab2303b2decd8cbb2cd1bf5280aa181. > - Revert "Fixup after comment from Ivan." > > This reverts commit 2aa8aa4b68027b62a8d4be1b86720fadfa48dda5. Thanks for addressing my comments, I think this looks good now. Only one comment about an additional (and optional) change, if we can do the CM initialization after the young collection and only when we start the concurrent mark cycle. But there might be things preventing this. src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2745: > 2743: // without its logging output interfering with the logging output > 2744: // that came from the pause. > 2745: if (should_start_concurrent_mark_operation) { Did you try doing the initialization here? Would be kind of nice to only initialize CM if ever needed. ------------- Marked as reviewed by sjohanss (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28723#pullrequestreview-3692812069 PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2717200084 From tschatzl at openjdk.org Thu Jan 22 15:09:50 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 22 Jan 2026 15:09:50 GMT Subject: RFR: 8376115: G1: Convert G1CMRootRegions to use Atomic Message-ID: Hi all, please review this change to convert `G1CMRootRegions` to use `Atomic`. Testing: gha Thanks, Thomas ------------- Commit messages: - 8376115 Changes: https://git.openjdk.org/jdk/pull/29363/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29363&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376115 Stats: 21 lines in 2 files changed: 0 ins; 0 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/29363.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29363/head:pull/29363 PR: https://git.openjdk.org/jdk/pull/29363 From tschatzl at openjdk.org Thu Jan 22 16:08:04 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 22 Jan 2026 16:08:04 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v5] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 14:42:06 GMT, Stefan Johansson wrote: > Did you try doing the initialization here? Would be kind of nice to only initialize CM if ever needed. This currently does not work because `G1ClearBitmapClosure` unnecessarily calls `G1ConcurrentMark::clear_statistics()` (and `reset_top_at_mark_start()`). There is a CR out for fixing this (https://bugs.openjdk.org/browse/JDK-8376115), but I suggest to not further delay this change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2717568059 From tschatzl at openjdk.org Thu Jan 22 16:10:36 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 22 Jan 2026 16:10:36 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v5] In-Reply-To: References: Message-ID: <5hNytk10uZXtSTGH8wXf8ZipZ48GVmW-RHaTd3RV0vU=.624f0c29-d0d0-42bf-8914-bcc9ce8c866b@github.com> On Thu, 22 Jan 2026 12:36:42 GMT, Leo Korinth wrote: >> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. >> >> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. >> >> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. >> >> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. > > Leo Korinth has updated the pull request incrementally with six additional commits since the last revision: > > - Merge branch '_8373253' into _8367993 > - rename of method > - Proposal by Stefan J > - wip > - Revert "8373253: Re-work InjectGCWorkerCreationFailure for future changes" > > This reverts commit d45ea8817ab2303b2decd8cbb2cd1bf5280aa181. > - Revert "Fixup after comment from Ivan." > > This reverts commit 2aa8aa4b68027b62a8d4be1b86720fadfa48dda5. Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28723#pullrequestreview-3693281140 From shade at openjdk.org Thu Jan 22 16:30:20 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 22 Jan 2026 16:30:20 GMT Subject: RFR: 8375966: G1: Convert G1UpdateRegionLivenessAndSelectForRebuildTask to use Atomic [v2] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 13:08:58 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change to convert `G1UpdateRegionLivenessAndSelectForRebuildTask` to use `Atomic`. >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * kbarrett review Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29340#pullrequestreview-3693369480 From kbarrett at openjdk.org Thu Jan 22 18:27:40 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 22 Jan 2026 18:27:40 GMT Subject: RFR: 8375966: G1: Convert G1UpdateRegionLivenessAndSelectForRebuildTask to use Atomic [v2] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 13:08:58 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change to convert `G1UpdateRegionLivenessAndSelectForRebuildTask` to use `Atomic`. >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * kbarrett review Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29340#pullrequestreview-3693910713 From kbarrett at openjdk.org Thu Jan 22 18:30:45 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 22 Jan 2026 18:30:45 GMT Subject: RFR: 8375983: G1: Convert G1ConcurrentRefineStats to use Atomic [v3] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 14:38:50 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that converts `G1ConcurrentRefineStats` to use `Atomic`. >> >> The only notable thing is that there has been need to expand the assignment in `reset()` since the assignment operator for `Atomic` is not defined, and I did not see it worth adding one. >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * add .inline.hpp file Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29347#pullrequestreview-3693921851 From kbarrett at openjdk.org Thu Jan 22 18:33:54 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 22 Jan 2026 18:33:54 GMT Subject: RFR: 8375974: G1: Convert G1FullCollector to use Atomic [v2] In-Reply-To: References: <6WLOSv0nfMvvwt_nov7cwNo6Zx-_BX4EkZ735UZZCt0=.82351a7b-6c64-4214-90f8-e7173e095bc7@github.com> Message-ID: On Thu, 22 Jan 2026 13:25:02 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change to convert `G1FullCollector` to use `Atomic`. >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * kbarrett review Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29342#pullrequestreview-3693934052 From xpeng at openjdk.org Thu Jan 22 19:21:16 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Thu, 22 Jan 2026 19:21:16 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v56] In-Reply-To: References: Message-ID: <10VArYKEoCRdoWEwPowRcMfrDkO7XssZWrgPIQQV8wE=.4b3f8f8f-b310-4b14-aaa0-2a7fdb5ba6de@github.com> To protect against unauthorized use of the Oracle email brand, we will be implementing a strict DMARC policy as part of our email security. DMARC (Domain-based Message Authentication, Reporting and Conformance) will help protect against phishing attacks, spam campaigns, and other malicious activities. With this implementation, emails sent on behalf of ANY Oracle owned domain will be restricted if they fail DMARC compliance. DMARC Info : Record= v=DMARC1;p=none;rua=mailto:dmarc_rua at emaildefense.proofpoint.com;ruf=mailto:dmarc_ruf at emaildefense.proofpoint.com;fo=1 Result= none Questions and more information: * You may need to take action if you're responsible for email flow from Oracle Cloud, OCI, or acquisition domains. Senders in this category are treated as external emails since they operate outside of Oracle's internal network. * If you are using the OCI Email Delivery Service, ensure you generate DKIM for your related Header From Domain - refer to https://docs.oracle.com/en-us/iaas/Content/Email/Tasks/configuredkim.htm more info can be found here https://confluence.oraclecorp.com/confluence/display/EMAIL/DMARC+for+Oracle+IT+and+Email+Delivery+Frequently+Asked+Questions * Refer to the DMARC FAQ https://confluence.oraclecorp.com/confluence/display/OITGLOBAL/DMARC+Global+FAQ to learn more about DMARC, if your emails may be affected, and actions you need to take. * If you have questions, reach out to the #oracle-owned-domains-dmarc Slack channel. Thank you in advance for your attention to this matter. > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: FullGC should not update accounting when release alloc regions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/f47d086a..64ac804d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=55 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=54-55 Stats: 9 lines in 4 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From xpeng at openjdk.org Thu Jan 22 19:47:21 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Thu, 22 Jan 2026 19:47:21 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v20] In-Reply-To: References: <797j9fNWUlV491wWKbFMfthH99o3A5493T0Pcdn_zdc=.417c13b0-8618-4402-aafa-3d86c45c8ff6@github.com> Message-ID: <8Y40KAqmSFRikCct67Wo4UYE7HS7DSza4OxOL1XOyTE=.77bb9e4b-7eaa-4a83-91f6-ed6bfffd0ac2@github.com> On Tue, 6 Jan 2026 23:59:32 GMT, Kelvin Nilsen wrote: >> Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 265 commits: >> >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - Fix build error after merging from tip >> - Merge branch 'master' into cas-alloc-1 >> - Merge branch 'master' into cas-alloc-1 >> - Some comments updates as suggested in PR review >> - Fix build failure after merge >> - Expend promoted from ShenandoahOldCollectorAllocator >> - Merge branch 'master' into cas-alloc-1 >> - Address PR comments >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - ... and 255 more: https://git.openjdk.org/jdk/compare/de81d389...cf13b7b5 > > src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 353: > >> 351: if (!r->has_allocs()) { >> 352: log_debug(gc, alloc)("%sAllocator: Reverting heap region %li to FREE due to no alloc in the region", >> 353: _alloc_partition_name, r->index()); > > This code looks suspect to me. Maybe it works as is only because we are currently doing this only immediately before rebuilding free set. If that's the case, there should be some documentation and maybe even some asserts that confirm it is true. > > When we release_alloc_regions(), we should be adjusting the range for the associated partitions. The code that most closely resembles this functionality is in ShenandoahFreeSet::move_regions_from_collector_to_mutator(). This is the code that moves collector and old-collector partitions to the mutator partition after evacuation is done. It could happen with CAS allocator, e.g. right before final mark, mutator refreshed alloc regions and reserved some empty regions w/o any allocations in them, then at final mark, GC thread will release alloc regions to prepare for free set rebuild. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2718360651 From kdnilsen at openjdk.org Thu Jan 22 20:37:36 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 22 Jan 2026 20:37:36 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v15] In-Reply-To: References: Message-ID: > After studying large numbers of GC logs with degenerated cycles that have resulted from "late" triggers, we propose the following general improvements: > > 1. Track trends in GC times rather than always using the average GC time plus standard deviation. In many situations, GC times trend upward due to, for example, increasing amounts of live data that must be marked as a workload builds up its working set of memory. > 2. Sample allocation rates more frequently than once every 100 ms. > 3. Track trends in allocation rates. In some situations, the allocation rate trends upwards due to, for example, the start of a new phase of execution or a spike in client workload. > 4. When we detect acceleration of allocation rate, predict consumption of memory based on accelerated allocation rates rather than assuming constant allocation rate. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Turn on trigger trace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29039/files - new: https://git.openjdk.org/jdk/pull/29039/files/9a77852a..ef654d3c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=13-14 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29039.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29039/head:pull/29039 PR: https://git.openjdk.org/jdk/pull/29039 From wkemper at openjdk.org Thu Jan 22 21:26:07 2026 From: wkemper at openjdk.org (William Kemper) Date: Thu, 22 Jan 2026 21:26:07 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v34] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 23:51:25 GMT, Kelvin Nilsen wrote: >> Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). >> >> This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. >> >> The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. >> >> ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) >> >> With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. >> >> ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) >> >> At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. >> >> ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) >> >> The command line for these comparisons follows: >> >> >> ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jd... > > Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 92 commits: > > - Merge remote-tracking branch 'jdk/master' into share-collector-reserves > - remove debug instrumentation > - Fix uninitialized variable > - Add debugging instrumentation > - Merge remote-tracking branch 'jdk/master' into share-collector-reserves > - Use PROPERFMTARGS > - Merge remote-tracking branch 'jdk/master' into share-collector-reserves > - Move rebuild free set earlier in an abbreviated GC cycle > - Restore deleted assert statement > - Move special handling into ShenandoahYoungHeuristics::choose_collection_set_from_regiondata() > - ... and 82 more: https://git.openjdk.org/jdk/compare/4fd7595f...c574f0b5 Marked as reviewed by wkemper (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25357#pullrequestreview-3694653782 From kdnilsen at openjdk.org Thu Jan 22 21:32:43 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 22 Jan 2026 21:32:43 GMT Subject: Integrated: 8357471: GenShen: Share collector reserves between young and old In-Reply-To: References: Message-ID: On Wed, 21 May 2025 15:29:09 GMT, Kelvin Nilsen wrote: > Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). > > This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. > > The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. > > ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) > > With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. > > ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) > > At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. > > ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) > > The command line for these comparisons follows: > > > ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jdk/bin/java \ > -XX:+Unlock... This pull request has now been integrated. Changeset: d6ebcf8a Author: Kelvin Nilsen URL: https://git.openjdk.org/jdk/commit/d6ebcf8a4f42b8e157083be90271e0df3b631033 Stats: 1510 lines in 41 files changed: 789 ins; 275 del; 446 mod 8357471: GenShen: Share collector reserves between young and old Reviewed-by: wkemper ------------- PR: https://git.openjdk.org/jdk/pull/25357 From syan at openjdk.org Fri Jan 23 01:00:26 2026 From: syan at openjdk.org (SendaoYan) Date: Fri, 23 Jan 2026 01:00:26 GMT Subject: Integrated: 8376051: gc/stress/TestStressG1Uncommit.java fails assertLessThan: expected that xxx < xxx In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 06:33:13 GMT, SendaoYan wrote: > Hi all, > > [JDK-8238686](https://bugs.openjdk.org/browse/JDK-8238686) change the default value MinHeapFreeRatio/MaxHeapFreeRatio to 0/100, this change make G1 do less uncommit heap memory to OS system, this will make test test/hotspot/jtreg/gc/stress/TestStressG1Uncommit.java fails "assertLessThan: expected that xxx < xxx", and the tested java process never print "Uncommit regions" which checked by this test. > > This PR set MinHeapFreeRatio/MaxHeapFreeRatio to the original value 40/70 to make this test work expectly. > > Change has been verified locally on linux-x64 by run this tests both with release build and fastdebug build. This pull request has now been integrated. Changeset: 0f087a7f Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/0f087a7fef2d3979badefde02a1e85351379f18c Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8376051: gc/stress/TestStressG1Uncommit.java fails assertLessThan: expected that xxx < xxx Reviewed-by: tschatzl, shade ------------- PR: https://git.openjdk.org/jdk/pull/29357 From syan at openjdk.org Fri Jan 23 01:00:24 2026 From: syan at openjdk.org (SendaoYan) Date: Fri, 23 Jan 2026 01:00:24 GMT Subject: RFR: 8376051: gc/stress/TestStressG1Uncommit.java fails assertLessThan: expected that xxx < xxx In-Reply-To: <4_WqCEjqY1XPn0yGR1CxVLW7HhhLYI5FL3BFQdjl_lQ=.1c1c1fbd-82e5-47d1-9946-48d82c2dc2a3@github.com> References: <5tONvebbyF8XOfBP79P-Oyn6ZywqOYF0jQPsQs2Vo4A=.bb24586b-3b7b-455e-ad09-64756cf75d4e@github.com> <4_WqCEjqY1XPn0yGR1CxVLW7HhhLYI5FL3BFQdjl_lQ=.1c1c1fbd-82e5-47d1-9946-48d82c2dc2a3@github.com> Message-ID: On Thu, 22 Jan 2026 10:42:38 GMT, Thomas Schatzl wrote: >>> It will re-evaluate and resize the heap at every young gc, based on GC cpu usage. >> >> What I meant is the free heap memory ratio will never greater than 100%, so when the value of MaxHeapFreeRatio is seted to 100, G1 will never give back memory to OS? I am not familiar with GC. > >> > It will re-evaluate and resize the heap at every young gc, based on GC cpu usage. >> >> What I meant is the free heap memory ratio will never greater than 100%, so when the value of MaxHeapFreeRatio is seted to 100, G1 will never give back memory to OS? I am not familiar with GC. > > These ratios (actually percentages) only every applied to full gcs, and only for Serial/Parallel/G1 and maybe Shenandoah. > > Since JDK 26, G1 will re-evaluate the "best" heap size based on GC cpu usage. So if lots of time, more than the goal, `GCTimeRatio`, is spent in GC activity, G1 will shrink the heap and give back memory to the OS. (Actually, in many applications, G1 is keeping a smaller footprint now). > > G1 will re-evaluate and shrink/expand at every young gc (https://bugs.openjdk.org/browse/JDK-8238687), not only full gc/System.gc() based on arbitrary Min/MaxHeapFreeRatio. The [CSR](https://bugs.openjdk.org/browse/JDK-8375300) for the change causing this test failure hopefully explains the reason for this change well enough. > > Actually we are not sure how/why this test failure slipped through. > >> > I think revert the WhiteBox change also acceptable. Should I do that? >> Yes, I think System.gc() is still cleaner. > > In this case, `System.gc()` and `WhiteBox.fullGC()` act exactly the same so I would also keep `System.gc()` just to keep the code simpler. Thanks for the suggestions and reviews @tschatzl @shipilev ------------- PR Comment: https://git.openjdk.org/jdk/pull/29357#issuecomment-3787615943 From xpeng at openjdk.org Fri Jan 23 07:30:12 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 23 Jan 2026 07:30:12 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v57] In-Reply-To: References: Message-ID: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 325 commits: - Fix crash after merging from tip(due to the new free-set rebuild calls) - Fix build error after merging tip - Merge branch 'master' into cas-alloc-1 - FullGC should not update accounting when release alloc regions - Not update accounting if no region is unretired to partition - Invoke assert_bounds after updating accounting from ShenandoahAllocator - Remove use AtomicAccess for _top if permits - Missed place calling function is_active_alloc_region - Rename function is_active_alloc_region to is_atomic_alloc_region - Remove _active_alloc_region flag and directly use field _atomic_top to determine atomic alloc region - ... and 315 more: https://git.openjdk.org/jdk/compare/0f087a7f...9ba19e42 ------------- Changes: https://git.openjdk.org/jdk/pull/26171/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=56 Stats: 1832 lines in 29 files changed: 1461 ins; 237 del; 134 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From sjohanss at openjdk.org Fri Jan 23 08:01:45 2026 From: sjohanss at openjdk.org (Stefan Johansson) Date: Fri, 23 Jan 2026 08:01:45 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v5] In-Reply-To: References: Message-ID: <_tPpzMeOlZdYZkZobcjRvLuI2hOjiA3DHWW01ypa00c=.c91c9b7a-17f4-4b4d-bad1-1d90258be720@github.com> On Thu, 22 Jan 2026 16:04:46 GMT, Thomas Schatzl wrote: >> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2745: >> >>> 2743: // without its logging output interfering with the logging output >>> 2744: // that came from the pause. >>> 2745: if (should_start_concurrent_mark_operation) { >> >> Did you try doing the initialization here? Would be kind of nice to only initialize CM if ever needed. > >> Did you try doing the initialization here? Would be kind of nice to only initialize CM if ever needed. > > This currently does not work because `G1ClearBitmapClosure` unnecessarily calls `G1ConcurrentMark::clear_statistics()` (and `reset_top_at_mark_start()`). There is a CR out for fixing this (https://bugs.openjdk.org/browse/JDK-8371720), but I suggest to not further delay this change. > > Edit: fixed link Thanks for the details Thomas. Totally agree, this can be investigated and tested further as a follow-up. Ship it! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2720029706 From tschatzl at openjdk.org Fri Jan 23 08:34:38 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 23 Jan 2026 08:34:38 GMT Subject: RFR: 8375966: G1: Convert G1UpdateRegionLivenessAndSelectForRebuildTask to use Atomic [v2] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 18:24:48 GMT, Kim Barrett wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * kbarrett review > > Looks good. Thanks @kimbarrett @shipilev for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/29340#issuecomment-3789036732 From tschatzl at openjdk.org Fri Jan 23 08:34:39 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 23 Jan 2026 08:34:39 GMT Subject: Integrated: 8375966: G1: Convert G1UpdateRegionLivenessAndSelectForRebuildTask to use Atomic In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 10:56:51 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to convert `G1UpdateRegionLivenessAndSelectForRebuildTask` to use `Atomic`. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: fa20391e Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/fa20391e73102a5d6a5b0a760d95a4225c673e04 Stats: 9 lines in 2 files changed: 3 ins; 1 del; 5 mod 8375966: G1: Convert G1UpdateRegionLivenessAndSelectForRebuildTask to use Atomic Reviewed-by: kbarrett, shade ------------- PR: https://git.openjdk.org/jdk/pull/29340 From tschatzl at openjdk.org Fri Jan 23 08:34:48 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 23 Jan 2026 08:34:48 GMT Subject: RFR: 8375971: G1: Convert G1EvacStats to use Atomic [v2] In-Reply-To: References: Message-ID: <43AJOC20jQlNXNixPx5hbS5Ocb2XlHKepZkrvh7oFlc=.9422947c-a783-40eb-8c85-8bb1c2cdafe5@github.com> > Hi all, > > please review this change that moves `G1EvacStats` to use `Atomic`. > > Testing: gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision: - * reformatting, avoid long lines - * fix compilation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29341/files - new: https://git.openjdk.org/jdk/pull/29341/files/510601bb..5df23350 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29341&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29341&range=00-01 Stats: 23 lines in 3 files changed: 15 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/29341.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29341/head:pull/29341 PR: https://git.openjdk.org/jdk/pull/29341 From tschatzl at openjdk.org Fri Jan 23 08:38:03 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 23 Jan 2026 08:38:03 GMT Subject: RFR: 8376119: G1: Convert volatiles in G1CMMarkStack to Atomic Message-ID: <4KamrOFSNhCYCMO7mEj_e3wRlzx2k3FTypc_pfU2Vp4=.d61da684-f1ce-470d-9106-312d39da9f26@github.com> Hi all, please review this conversion of volatiles that do not use any `AtomicAccess` method in `G1CMMarkStack` but are marked as such to indicate potential concurrency when accessing them. Typically we do some phased access, i.e. one (single-threaded) phase writes them, another only reads from them. Testing: gha Thanks, Thomas ------------- Commit messages: - 8376119 Changes: https://git.openjdk.org/jdk/pull/29365/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29365&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376119 Stats: 14 lines in 3 files changed: 0 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/29365.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29365/head:pull/29365 PR: https://git.openjdk.org/jdk/pull/29365 From tschatzl at openjdk.org Fri Jan 23 08:38:08 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 23 Jan 2026 08:38:08 GMT Subject: RFR: 8376126: G1: Convert remaining volatiles in G1ConcurrentMark to Atomic Message-ID: Hi all, please convert remaining volatile declarations in `G1ConcurrentMark` to use `Atomic`. These volatiles are used to indicate concurrent phased access (like changing the variable in thread A, then reading the variable in thread B while A is dormant, or only ever updating it in one direction) where concurrency safety is provided by barriers between these phases. But there are also other cases) The exception is `G1ConcurrentMark::_finger` that has apparently been overlooked in an earlier changes. Testing: gha Thanks, Thomas ------------- Commit messages: - 8376126 Changes: https://git.openjdk.org/jdk/pull/29368/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29368&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376126 Stats: 55 lines in 3 files changed: 1 ins; 0 del; 54 mod Patch: https://git.openjdk.org/jdk/pull/29368.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29368/head:pull/29368 PR: https://git.openjdk.org/jdk/pull/29368 From tschatzl at openjdk.org Fri Jan 23 08:41:20 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 23 Jan 2026 08:41:20 GMT Subject: [jdk26] RFR: 8375541: G1: Race in G1BarrierSet::write_ref_field_post() Message-ID: <0KtsS7nbUtuxJd6bHR9SXKG9jT9F51am7adXNqLMHOg=.92621457-bfd3-4344-b157-97b4a3fb51cf@github.com> Hi all, This pull request contains a backport of commit [0ad81fbd](https://github.com/openjdk/jdk/commit/0ad81fbd161edbc8479e5af5c0f8d6098f6c72d1) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Thomas Schatzl on 22 Jan 2026 and was reviewed by Ivan Walulya, Stefan Johansson and Aleksey Shipilev. Thanks! ------------- Commit messages: - Backport 0ad81fbd161edbc8479e5af5c0f8d6098f6c72d1 Changes: https://git.openjdk.org/jdk/pull/29378/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29378&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375541 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29378.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29378/head:pull/29378 PR: https://git.openjdk.org/jdk/pull/29378 From tschatzl at openjdk.org Fri Jan 23 09:14:33 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 23 Jan 2026 09:14:33 GMT Subject: [jdk26] RFR: 8375314: Parallel: Crash iterating over unloaded classes for ObjectCountAfterGC event Message-ID: Hi all, This pull request contains a backport of commit [f3381f0f](https://github.com/openjdk/jdk/commit/f3381f0ffe2207e1765558f6f49e5a0280a3f920) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Thomas Schatzl on 22 Jan 2026 and was reviewed by Roman Kennke, Stefan Johansson and Ivan Walulya. There has been a merge error in `collectedHeap.inline.hpp` in the copyright line, the dates did not match up. Thanks! ------------- Commit messages: - 8375314: Parallel: Crash iterating over unloaded classes for ObjectCountAfterGC event Changes: https://git.openjdk.org/jdk/pull/29381/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29381&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375314 Stats: 145 lines in 7 files changed: 129 ins; 11 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/29381.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29381/head:pull/29381 PR: https://git.openjdk.org/jdk/pull/29381 From iwalulya at openjdk.org Fri Jan 23 11:46:37 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Fri, 23 Jan 2026 11:46:37 GMT Subject: RFR: 8375436: G1: Convert G1CardSet classes to use Atomic [v2] In-Reply-To: References: Message-ID: <367VmJxFS1FmO3VutQT25OzTnW6UlooVhrDlhQlZm60=.bbbd0ff2-5eac-4d2f-9d6f-b469c2a20226@github.com> On Tue, 20 Jan 2026 08:06:04 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this removal of use of the AtomicAccess class in G1 card set related classes, replacing with use of Atomic. >> >> Although a bit on the large side, it would be hard to do the card set changes separately per class. Other than that I think it is fairly straightforward, except for the addition of a copy constructor for `G1CardSetHashTableValue` because the `ConcurrentHashTable` requires it. >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * kbarrett review Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29274#pullrequestreview-3697122646 From iwalulya at openjdk.org Fri Jan 23 11:47:49 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Fri, 23 Jan 2026 11:47:49 GMT Subject: RFR: 8375964: G1: Convert G1BuildCandidateRegionsTask to use Atomic In-Reply-To: <-AQiYq3R3DDkNgH-BG7L245lx6Rz1ezlizPt3CNmhvw=.decaa9ff-3daf-45eb-aa0a-ebd4a7ba346e@github.com> References: <-AQiYq3R3DDkNgH-BG7L245lx6Rz1ezlizPt3CNmhvw=.decaa9ff-3daf-45eb-aa0a-ebd4a7ba346e@github.com> Message-ID: On Wed, 21 Jan 2026 10:50:41 GMT, Thomas Schatzl wrote: > Hi all, > > please review the changes to let `G1BuildCandidateRegionsTask` use `Atomic`. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29339#pullrequestreview-3697125384 From iwalulya at openjdk.org Fri Jan 23 11:54:34 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Fri, 23 Jan 2026 11:54:34 GMT Subject: RFR: 8375974: G1: Convert G1FullCollector to use Atomic [v2] In-Reply-To: References: <6WLOSv0nfMvvwt_nov7cwNo6Zx-_BX4EkZ735UZZCt0=.82351a7b-6c64-4214-90f8-e7173e095bc7@github.com> Message-ID: On Thu, 22 Jan 2026 13:25:02 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change to convert `G1FullCollector` to use `Atomic`. >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * kbarrett review Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29342#pullrequestreview-3697147475 From iwalulya at openjdk.org Fri Jan 23 12:01:04 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Fri, 23 Jan 2026 12:01:04 GMT Subject: RFR: 8375971: G1: Convert G1EvacStats to use Atomic [v2] In-Reply-To: <43AJOC20jQlNXNixPx5hbS5Ocb2XlHKepZkrvh7oFlc=.9422947c-a783-40eb-8c85-8bb1c2cdafe5@github.com> References: <43AJOC20jQlNXNixPx5hbS5Ocb2XlHKepZkrvh7oFlc=.9422947c-a783-40eb-8c85-8bb1c2cdafe5@github.com> Message-ID: On Fri, 23 Jan 2026 08:34:48 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that moves `G1EvacStats` to use `Atomic`. >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision: > > - * reformatting, avoid long lines > - * fix compilation Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29341#pullrequestreview-3697167999 From iwalulya at openjdk.org Fri Jan 23 12:10:13 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Fri, 23 Jan 2026 12:10:13 GMT Subject: RFR: 8375981: G1: Convert G1RemSet helper classes to use Atomic [v2] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 09:34:51 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this conversion of `G1RemSet` helper classes to use `Atomic<>`. >> >> There has been one additional non-volatile member that has been converted to use `Atomic`. >> >> Testing: gha, tier1 >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * shade review Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29345#pullrequestreview-3697198570 From iwalulya at openjdk.org Fri Jan 23 12:16:44 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Fri, 23 Jan 2026 12:16:44 GMT Subject: RFR: 8375983: G1: Convert G1ConcurrentRefineStats to use Atomic [v3] In-Reply-To: References: Message-ID: <3cvZDzd-pTcvmpOJzAt09K8dmjfWHPN0nev_Be_NFiY=.99a26c1f-e8f8-4141-b7cb-9c622b986441@github.com> On Thu, 22 Jan 2026 14:38:50 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that converts `G1ConcurrentRefineStats` to use `Atomic`. >> >> The only notable thing is that there has been need to expand the assignment in `reset()` since the assignment operator for `Atomic` is not defined, and I did not see it worth adding one. >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * add .inline.hpp file Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29347#pullrequestreview-3697219965 From iwalulya at openjdk.org Fri Jan 23 12:27:41 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Fri, 23 Jan 2026 12:27:41 GMT Subject: RFR: 8376115: G1: Convert G1CMRootRegions to use Atomic In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 15:00:17 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to convert `G1CMRootRegions` to use `Atomic`. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29363#pullrequestreview-3697256391 From iwalulya at openjdk.org Fri Jan 23 12:37:28 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Fri, 23 Jan 2026 12:37:28 GMT Subject: RFR: 8376119: G1: Convert volatiles in G1CMMarkStack to Atomic In-Reply-To: <4KamrOFSNhCYCMO7mEj_e3wRlzx2k3FTypc_pfU2Vp4=.d61da684-f1ce-470d-9106-312d39da9f26@github.com> References: <4KamrOFSNhCYCMO7mEj_e3wRlzx2k3FTypc_pfU2Vp4=.d61da684-f1ce-470d-9106-312d39da9f26@github.com> Message-ID: On Thu, 22 Jan 2026 15:35:05 GMT, Thomas Schatzl wrote: > Hi all, > > please review this conversion of volatiles that do not use any `AtomicAccess` method in `G1CMMarkStack` but are marked as such to indicate potential concurrency when accessing them. Typically we do some phased access, i.e. one (single-threaded) phase writes them, another only reads from them. > > Testing: gha > > Thanks, > Thomas ` struct TaskQueueEntryChunk { TaskQueueEntryChunk* next; G1TaskQueueEntry data[EntriesPerChunk]; }; ` In this case, should we also have `TaskQueueEntryChunk* next;` as Atomic? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29365#issuecomment-3790040545 From iwalulya at openjdk.org Fri Jan 23 12:46:08 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Fri, 23 Jan 2026 12:46:08 GMT Subject: RFR: 8376126: G1: Convert remaining volatiles in G1ConcurrentMark to Atomic In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 16:36:08 GMT, Thomas Schatzl wrote: > Hi all, > > please convert remaining volatile declarations in `G1ConcurrentMark` to use `Atomic`. These volatiles are used to indicate concurrent phased access (like changing the variable in thread A, then reading the variable in thread B while A is dormant, or only ever updating it in one direction) where concurrency safety is provided by barriers between these phases. But there are also other cases) > > The exception is `G1ConcurrentMark::_finger` that has apparently been overlooked in an earlier changes. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). src/hotspot/share/gc/g1/g1ConcurrentMark.hpp line 679: > 677: uint completed_mark_cycles() const; > 678: > 679: bool has_aborted() { return _has_aborted.load_relaxed(); } Suggestion: bool has_aborted() { return _has_aborted.load_relaxed(); } ------------- PR Review: https://git.openjdk.org/jdk/pull/29368#pullrequestreview-3697312733 PR Review Comment: https://git.openjdk.org/jdk/pull/29368#discussion_r2721051786 From kbarrett at openjdk.org Fri Jan 23 18:52:50 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 23 Jan 2026 18:52:50 GMT Subject: RFR: 8375971: G1: Convert G1EvacStats to use Atomic [v2] In-Reply-To: <43AJOC20jQlNXNixPx5hbS5Ocb2XlHKepZkrvh7oFlc=.9422947c-a783-40eb-8c85-8bb1c2cdafe5@github.com> References: <43AJOC20jQlNXNixPx5hbS5Ocb2XlHKepZkrvh7oFlc=.9422947c-a783-40eb-8c85-8bb1c2cdafe5@github.com> Message-ID: <9z5dFmKyYo2NBQKlVBic3jb6GR1SZRaVbRB9Pa6_lRw=.5d50d88d-2864-4d17-accd-0081b4362e0c@github.com> On Fri, 23 Jan 2026 08:34:48 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that moves `G1EvacStats` to use `Atomic`. >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision: > > - * reformatting, avoid long lines > - * fix compilation Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29341#pullrequestreview-3699081501 From kbarrett at openjdk.org Fri Jan 23 19:03:06 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 23 Jan 2026 19:03:06 GMT Subject: RFR: 8376115: G1: Convert G1CMRootRegions to use Atomic In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 15:00:17 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to convert `G1CMRootRegions` to use `Atomic`. > > Testing: gha > > Thanks, > Thomas A couple of optional small changes, otherwise looks good. src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 419: > 417: > 418: size_t claimed_index = _claimed_root_regions.fetch_then_add(1u); > 419: if (claimed_index < num_root_regions()) { [pre-existing] Consider putting `num_root_regions()` in a variable for use both here and a few lines above. The compiler can't CSE them, because of volatile/atomic accesses. src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 430: > 428: > 429: bool G1CMRootMemRegions::contains(const MemRegion mr) const { > 430: for (uint i = 0; i < num_root_regions(); i++) { [pre-existing] Consider hoisting the loop limit out of the loop. Compiler can't do that here, because of volatile/atomic accesses. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29363#pullrequestreview-3699103240 PR Review Comment: https://git.openjdk.org/jdk/pull/29363#discussion_r2722457622 PR Review Comment: https://git.openjdk.org/jdk/pull/29363#discussion_r2722450369 From kbarrett at openjdk.org Fri Jan 23 19:10:48 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 23 Jan 2026 19:10:48 GMT Subject: RFR: 8376119: G1: Convert volatiles in G1CMMarkStack to Atomic In-Reply-To: <4KamrOFSNhCYCMO7mEj_e3wRlzx2k3FTypc_pfU2Vp4=.d61da684-f1ce-470d-9106-312d39da9f26@github.com> References: <4KamrOFSNhCYCMO7mEj_e3wRlzx2k3FTypc_pfU2Vp4=.d61da684-f1ce-470d-9106-312d39da9f26@github.com> Message-ID: On Thu, 22 Jan 2026 15:35:05 GMT, Thomas Schatzl wrote: > Hi all, > > please review this conversion of volatiles that do not use any `AtomicAccess` method in `G1CMMarkStack` but are marked as such to indicate potential concurrency when accessing them. Typically we do some phased access, i.e. one (single-threaded) phase writes them, another only reads from them. > > Testing: gha > > Thanks, > Thomas Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29365#pullrequestreview-3699153144 From kbarrett at openjdk.org Fri Jan 23 19:18:06 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 23 Jan 2026 19:18:06 GMT Subject: RFR: 8376119: G1: Convert volatiles in G1CMMarkStack to Atomic In-Reply-To: References: <4KamrOFSNhCYCMO7mEj_e3wRlzx2k3FTypc_pfU2Vp4=.d61da684-f1ce-470d-9106-312d39da9f26@github.com> Message-ID: On Fri, 23 Jan 2026 12:34:41 GMT, Ivan Walulya wrote: > `struct TaskQueueEntryChunk { TaskQueueEntryChunk* next; G1TaskQueueEntry data[EntriesPerChunk]; };` > > In this case, should we also have `TaskQueueEntryChunk* next;` as Atomic? I only found uses of `next` while holding `G1MarkStackChunkList_lock`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29365#issuecomment-3791904793 From kbarrett at openjdk.org Fri Jan 23 19:26:37 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 23 Jan 2026 19:26:37 GMT Subject: RFR: 8376126: G1: Convert remaining volatiles in G1ConcurrentMark to Atomic In-Reply-To: References: Message-ID: <9sCIoSS-yCyA-wT3GnrasVdAdKkp3V8PaNiqILdbyKY=.ed7246e3-a40d-4364-95cb-4e89598f2921@github.com> On Thu, 22 Jan 2026 16:36:08 GMT, Thomas Schatzl wrote: > Hi all, > > please convert remaining volatile declarations in `G1ConcurrentMark` to use `Atomic`. These volatiles are used to indicate concurrent phased access (like changing the variable in thread A, then reading the variable in thread B while A is dormant, or only ever updating it in one direction) where concurrency safety is provided by barriers between these phases. But there are also other cases) > > The exception is `G1ConcurrentMark::_finger` that has apparently been overlooked in an earlier changes. > > Testing: gha > > Thanks, > Thomas One minor nit. Otherwise looks good. src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 580: > 578: uint max_num_regions = _g1h->max_num_regions(); > 579: for (uint i = 0; i < max_num_regions; i++) { > 580: ::new (&_top_at_rebuild_starts[i]) Atomic{}; Should add include of "cppstdlib/new.hpp". ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29368#pullrequestreview-3699196035 PR Review Comment: https://git.openjdk.org/jdk/pull/29368#discussion_r2722517093 From xpeng at openjdk.org Fri Jan 23 19:43:50 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 23 Jan 2026 19:43:50 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v58] In-Reply-To: References: Message-ID: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Update ProblemList to enable the tests affected by the change for accounting update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/9ba19e42..6f40d778 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=57 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=56-57 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From iwalulya at openjdk.org Sat Jan 24 06:08:49 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Sat, 24 Jan 2026 06:08:49 GMT Subject: RFR: 8376119: G1: Convert volatiles in G1CMMarkStack to Atomic In-Reply-To: <4KamrOFSNhCYCMO7mEj_e3wRlzx2k3FTypc_pfU2Vp4=.d61da684-f1ce-470d-9106-312d39da9f26@github.com> References: <4KamrOFSNhCYCMO7mEj_e3wRlzx2k3FTypc_pfU2Vp4=.d61da684-f1ce-470d-9106-312d39da9f26@github.com> Message-ID: On Thu, 22 Jan 2026 15:35:05 GMT, Thomas Schatzl wrote: > Hi all, > > please review this conversion of volatiles that do not use any `AtomicAccess` method in `G1CMMarkStack` but are marked as such to indicate potential concurrency when accessing them. Typically we do some phased access, i.e. one (single-threaded) phase writes them, another only reads from them. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29365#pullrequestreview-3700773702 From jeffery.wsj at outlook.com Sat Jan 24 07:28:36 2026 From: jeffery.wsj at outlook.com (shaojun wang) Date: Sat, 24 Jan 2026 07:28:36 +0000 Subject: One question about hotspot g1 heap adaptive resizing feature Message-ID: Hi Men Cao I read one openjdk bug which discuss G1 heap adaptive resizing feature, and I noticed that you mention one question like this: [image.png] and then you mentioned that you were convinced that the proposed approach does not suffer from this issue. This is because the proposed approach does not rely on the total process CPU usage, and does not measure "GC CPU overhead", i.e., a ratio of GC CPU usage over total CPU usage. [image.png] my question is that even with GCTimeRatio(gc time / (gc time + app time)) , the problem will still exist if the application fall into a very low cpu cost state. for example, gc_time = 30, app_time=40?GCTimeRatio is: 30/(30+40)= 0.42, the g1 heap size policy will try to extend heap size to scale down GCTimeRatio?But actually the application doesn't care about its performance at all under the state?because there is basically no or merely request for the app. Do you have idea about it? https://github.com/openjdk/jdk/pull/24211 https://bugs.openjdk.org/browse/JDK-8359348 >From shaojun wang ByteDance -------------- next part -------------- An HTML attachment was scrubbed... URL: From kdnilsen at openjdk.org Mon Jan 26 04:13:32 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 26 Jan 2026 04:13:32 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v16] In-Reply-To: References: Message-ID: > After studying large numbers of GC logs with degenerated cycles that have resulted from "late" triggers, we propose the following general improvements: > > 1. Track trends in GC times rather than always using the average GC time plus standard deviation. In many situations, GC times trend upward due to, for example, increasing amounts of live data that must be marked as a workload builds up its working set of memory. > 2. Sample allocation rates more frequently than once every 100 ms. > 3. Track trends in allocation rates. In some situations, the allocation rate trends upwards due to, for example, the start of a new phase of execution or a spike in client workload. > 4. When we detect acceleration of allocation rate, predict consumption of memory based on accelerated allocation rates rather than assuming constant allocation rate. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: More detailed instrumentation and simpler allocatable calculation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29039/files - new: https://git.openjdk.org/jdk/pull/29039/files/ef654d3c..e75b83ec Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=14-15 Stats: 44 lines in 2 files changed: 31 ins; 2 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/29039.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29039/head:pull/29039 PR: https://git.openjdk.org/jdk/pull/29039 From iwalulya at openjdk.org Mon Jan 26 08:35:39 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 26 Jan 2026 08:35:39 GMT Subject: [jdk26] RFR: 8375541: G1: Race in G1BarrierSet::write_ref_field_post() In-Reply-To: <0KtsS7nbUtuxJd6bHR9SXKG9jT9F51am7adXNqLMHOg=.92621457-bfd3-4344-b157-97b4a3fb51cf@github.com> References: <0KtsS7nbUtuxJd6bHR9SXKG9jT9F51am7adXNqLMHOg=.92621457-bfd3-4344-b157-97b4a3fb51cf@github.com> Message-ID: <0d-4WBVaBtZv7ubFuB8wumXctFPKnsXPr9prfZm2UEQ=.a4624f08-29eb-4652-881c-f32a4de133c7@github.com> On Fri, 23 Jan 2026 08:32:18 GMT, Thomas Schatzl wrote: > Hi all, > > This pull request contains a backport of commit [0ad81fbd](https://github.com/openjdk/jdk/commit/0ad81fbd161edbc8479e5af5c0f8d6098f6c72d1) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Thomas Schatzl on 22 Jan 2026 and was reviewed by Ivan Walulya, Stefan Johansson and Aleksey Shipilev. > > Thanks! Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29378#pullrequestreview-3705047750 From iwalulya at openjdk.org Mon Jan 26 08:36:52 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 26 Jan 2026 08:36:52 GMT Subject: [jdk26] RFR: 8375314: Parallel: Crash iterating over unloaded classes for ObjectCountAfterGC event In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 09:07:04 GMT, Thomas Schatzl wrote: > Hi all, > > This pull request contains a backport of commit [f3381f0f](https://github.com/openjdk/jdk/commit/f3381f0ffe2207e1765558f6f49e5a0280a3f920) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Thomas Schatzl on 22 Jan 2026 and was reviewed by Roman Kennke, Stefan Johansson and Ivan Walulya. > > There has been a merge error in `collectedHeap.inline.hpp` in the copyright line, the dates did not match up. > > Thanks! Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29381#pullrequestreview-3705050678 From tschatzl at openjdk.org Mon Jan 26 09:14:53 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 26 Jan 2026 09:14:53 GMT Subject: RFR: 8375964: G1: Convert G1BuildCandidateRegionsTask to use Atomic In-Reply-To: References: <-AQiYq3R3DDkNgH-BG7L245lx6Rz1ezlizPt3CNmhvw=.decaa9ff-3daf-45eb-aa0a-ebd4a7ba346e@github.com> Message-ID: On Thu, 22 Jan 2026 09:24:47 GMT, Aleksey Shipilev wrote: >> Hi all, >> >> please review the changes to let `G1BuildCandidateRegionsTask` use `Atomic`. >> >> Testing: gha >> >> Thanks, >> Thomas > > Marked as reviewed by shade (Reviewer). Thanks @shipilev @walulyai for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/29339#issuecomment-3798566761 From tschatzl at openjdk.org Mon Jan 26 09:15:09 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 26 Jan 2026 09:15:09 GMT Subject: Integrated: 8375436: G1: Convert G1CardSet classes to use Atomic In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 09:31:59 GMT, Thomas Schatzl wrote: > Hi all, > > please review this removal of use of the AtomicAccess class in G1 card set related classes, replacing with use of Atomic. > > Although a bit on the large side, it would be hard to do the card set changes separately per class. Other than that I think it is fairly straightforward, except for the addition of a copy constructor for `G1CardSetHashTableValue` because the `ConcurrentHashTable` requires it. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 2af271e5 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/2af271e5e64260f05c01cb94bcf95f80fd69b4ff Stats: 119 lines in 6 files changed: 9 ins; 4 del; 106 mod 8375436: G1: Convert G1CardSet classes to use Atomic Reviewed-by: kbarrett, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/29274 From tschatzl at openjdk.org Mon Jan 26 09:15:08 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 26 Jan 2026 09:15:08 GMT Subject: RFR: 8375436: G1: Convert G1CardSet classes to use Atomic [v2] In-Reply-To: References: Message-ID: <9SntdNIjPgbGj4IjP5UEQBjW65hK9HCrshT3p4uOsbg=.a90b7618-bcb5-4c60-a3cb-b32a7083f0a4@github.com> On Tue, 20 Jan 2026 18:00:17 GMT, Kim Barrett wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * kbarrett review > > Looks good. Thanks @kimbarrett @walulyai for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/29274#issuecomment-3798563311 From tschatzl at openjdk.org Mon Jan 26 09:16:03 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 26 Jan 2026 09:16:03 GMT Subject: RFR: 8375974: G1: Convert G1FullCollector to use Atomic [v2] In-Reply-To: References: <6WLOSv0nfMvvwt_nov7cwNo6Zx-_BX4EkZ735UZZCt0=.82351a7b-6c64-4214-90f8-e7173e095bc7@github.com> Message-ID: On Thu, 22 Jan 2026 18:31:24 GMT, Kim Barrett wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * kbarrett review > > Looks good. Thanks @kimbarrett @walulyai for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/29342#issuecomment-3798571377 From tschatzl at openjdk.org Mon Jan 26 09:16:06 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 26 Jan 2026 09:16:06 GMT Subject: RFR: 8375971: G1: Convert G1EvacStats to use Atomic [v2] In-Reply-To: <9z5dFmKyYo2NBQKlVBic3jb6GR1SZRaVbRB9Pa6_lRw=.5d50d88d-2864-4d17-accd-0081b4362e0c@github.com> References: <43AJOC20jQlNXNixPx5hbS5Ocb2XlHKepZkrvh7oFlc=.9422947c-a783-40eb-8c85-8bb1c2cdafe5@github.com> <9z5dFmKyYo2NBQKlVBic3jb6GR1SZRaVbRB9Pa6_lRw=.5d50d88d-2864-4d17-accd-0081b4362e0c@github.com> Message-ID: On Fri, 23 Jan 2026 18:49:52 GMT, Kim Barrett wrote: >> Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision: >> >> - * reformatting, avoid long lines >> - * fix compilation > > Looks good. Thanks @kimbarrett @walulyai for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/29341#issuecomment-3798569657 From tschatzl at openjdk.org Mon Jan 26 09:16:14 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 26 Jan 2026 09:16:14 GMT Subject: RFR: 8376191: Remove AtomicAccess include from files that do not use it in gc/shared Message-ID: Hi all, please review this trivial change to remove the `AtomicAccess.hpp` include to files that do not use anything from that file. Testing: gha, local compilation with disabled precompiled headers on linux-aarch64 Thanks, Thomas ------------- Commit messages: - 8376191 Changes: https://git.openjdk.org/jdk/pull/29384/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29384&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376191 Stats: 7 lines in 7 files changed: 0 ins; 7 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29384.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29384/head:pull/29384 PR: https://git.openjdk.org/jdk/pull/29384 From tschatzl at openjdk.org Mon Jan 26 09:17:24 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 26 Jan 2026 09:17:24 GMT Subject: RFR: 8375983: G1: Convert G1ConcurrentRefineStats to use Atomic [v3] In-Reply-To: References: Message-ID: <5rYLf07OYO1HaTKqq7baKujge-gL-x_dNXprYs5BWhE=.06696fa9-531b-41e2-8375-2228b8f92b3b@github.com> On Thu, 22 Jan 2026 18:27:47 GMT, Kim Barrett wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * add .inline.hpp file > > Looks good. Thanks @kimbarrett @walulyai for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/29347#issuecomment-3798576623 From tschatzl at openjdk.org Mon Jan 26 09:18:51 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 26 Jan 2026 09:18:51 GMT Subject: RFR: 8375981: G1: Convert G1RemSet helper classes to use Atomic [v2] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 09:39:52 GMT, Aleksey Shipilev wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * shade review > > Marked as reviewed by shade (Reviewer). Thanks @shipilev @walulyai for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/29345#issuecomment-3798575284 From tschatzl at openjdk.org Mon Jan 26 09:18:52 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 26 Jan 2026 09:18:52 GMT Subject: Integrated: 8375981: G1: Convert G1RemSet helper classes to use Atomic In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 12:31:34 GMT, Thomas Schatzl wrote: > Hi all, > > please review this conversion of `G1RemSet` helper classes to use `Atomic<>`. > > There has been one additional non-volatile member that has been converted to use `Atomic`. > > Testing: gha, tier1 > > Thanks, > Thomas This pull request has now been integrated. Changeset: e7cadd90 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/e7cadd90b2872364443873aa4b4b4664bcf02f4d Stats: 28 lines in 1 file changed: 6 ins; 0 del; 22 mod 8375981: G1: Convert G1RemSet helper classes to use Atomic Reviewed-by: shade, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/29345 From tschatzl at openjdk.org Mon Jan 26 09:19:48 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 26 Jan 2026 09:19:48 GMT Subject: [jdk26] RFR: 8375541: G1: Race in G1BarrierSet::write_ref_field_post() In-Reply-To: <0d-4WBVaBtZv7ubFuB8wumXctFPKnsXPr9prfZm2UEQ=.a4624f08-29eb-4652-881c-f32a4de133c7@github.com> References: <0KtsS7nbUtuxJd6bHR9SXKG9jT9F51am7adXNqLMHOg=.92621457-bfd3-4344-b157-97b4a3fb51cf@github.com> <0d-4WBVaBtZv7ubFuB8wumXctFPKnsXPr9prfZm2UEQ=.a4624f08-29eb-4652-881c-f32a4de133c7@github.com> Message-ID: On Mon, 26 Jan 2026 08:33:13 GMT, Ivan Walulya wrote: >> Hi all, >> >> This pull request contains a backport of commit [0ad81fbd](https://github.com/openjdk/jdk/commit/0ad81fbd161edbc8479e5af5c0f8d6098f6c72d1) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. >> >> The commit being backported was authored by Thomas Schatzl on 22 Jan 2026 and was reviewed by Ivan Walulya, Stefan Johansson and Aleksey Shipilev. >> >> Thanks! > > Marked as reviewed by iwalulya (Reviewer). Thanks @walulyai for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/29378#issuecomment-3798587418 From tschatzl at openjdk.org Mon Jan 26 09:19:52 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 26 Jan 2026 09:19:52 GMT Subject: [jdk26] RFR: 8375314: Parallel: Crash iterating over unloaded classes for ObjectCountAfterGC event In-Reply-To: References: Message-ID: <6TQe8OMeumspky0IvKLK2IZB5aH96AfbeBCcqX8ctRE=.c1fa93f6-2a2a-441d-af5c-22cc4c7958a5@github.com> On Mon, 26 Jan 2026 08:34:13 GMT, Ivan Walulya wrote: >> Hi all, >> >> This pull request contains a backport of commit [f3381f0f](https://github.com/openjdk/jdk/commit/f3381f0ffe2207e1765558f6f49e5a0280a3f920) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. >> >> The commit being backported was authored by Thomas Schatzl on 22 Jan 2026 and was reviewed by Roman Kennke, Stefan Johansson and Ivan Walulya. >> >> There has been a merge error in `collectedHeap.inline.hpp` in the copyright line, the dates did not match up. >> >> Thanks! > > Marked as reviewed by iwalulya (Reviewer). Thanks @walulyai for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/29381#issuecomment-3798589291 From tschatzl at openjdk.org Mon Jan 26 09:20:08 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 26 Jan 2026 09:20:08 GMT Subject: Integrated: 8375974: G1: Convert G1FullCollector to use Atomic In-Reply-To: <6WLOSv0nfMvvwt_nov7cwNo6Zx-_BX4EkZ735UZZCt0=.82351a7b-6c64-4214-90f8-e7173e095bc7@github.com> References: <6WLOSv0nfMvvwt_nov7cwNo6Zx-_BX4EkZ735UZZCt0=.82351a7b-6c64-4214-90f8-e7173e095bc7@github.com> Message-ID: On Wed, 21 Jan 2026 11:34:33 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to convert `G1FullCollector` to use `Atomic`. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 45970469 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/4597046984dedfd28bd76bd00dfc4b13ccb38dd4 Stats: 7 lines in 3 files changed: 0 ins; 0 del; 7 mod 8375974: G1: Convert G1FullCollector to use Atomic Reviewed-by: kbarrett, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/29342 From tschatzl at openjdk.org Mon Jan 26 09:20:11 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 26 Jan 2026 09:20:11 GMT Subject: Integrated: 8375983: G1: Convert G1ConcurrentRefineStats to use Atomic In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 13:22:07 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that converts `G1ConcurrentRefineStats` to use `Atomic`. > > The only notable thing is that there has been need to expand the assignment in `reset()` since the assignment operator for `Atomic` is not defined, and I did not see it worth adding one. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: c3360ff5 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/c3360ff51155bdd62b758c163351f57f4b410606 Stats: 181 lines in 10 files changed: 130 ins; 4 del; 47 mod 8375983: G1: Convert G1ConcurrentRefineStats to use Atomic Reviewed-by: kbarrett, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/29347 From tschatzl at openjdk.org Mon Jan 26 09:20:15 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 26 Jan 2026 09:20:15 GMT Subject: Integrated: 8375964: G1: Convert G1BuildCandidateRegionsTask to use Atomic In-Reply-To: <-AQiYq3R3DDkNgH-BG7L245lx6Rz1ezlizPt3CNmhvw=.decaa9ff-3daf-45eb-aa0a-ebd4a7ba346e@github.com> References: <-AQiYq3R3DDkNgH-BG7L245lx6Rz1ezlizPt3CNmhvw=.decaa9ff-3daf-45eb-aa0a-ebd4a7ba346e@github.com> Message-ID: <7zHqfA0so21mJburMYS_sahT4F6EpAeS-7-YDKIXKpc=.c04eb8b9-c82b-46bd-a1b6-0f778dae7c0a@github.com> On Wed, 21 Jan 2026 10:50:41 GMT, Thomas Schatzl wrote: > Hi all, > > please review the changes to let `G1BuildCandidateRegionsTask` use `Atomic`. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: a49986c6 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/a49986c62f4bcc4656f4ce0c7804a96875e9b6c6 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod 8375964: G1: Convert G1BuildCandidateRegionsTask to use Atomic Reviewed-by: shade, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/29339 From tschatzl at openjdk.org Mon Jan 26 09:21:26 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 26 Jan 2026 09:21:26 GMT Subject: Integrated: 8375971: G1: Convert G1EvacStats to use Atomic In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 11:21:48 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that moves `G1EvacStats` to use `Atomic`. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 0bc2dc34 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/0bc2dc3401f01b4727077a9844194d1654c3138c Stats: 83 lines in 4 files changed: 39 ins; 9 del; 35 mod 8375971: G1: Convert G1EvacStats to use Atomic Reviewed-by: iwalulya, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/29341 From tschatzl at openjdk.org Mon Jan 26 09:22:37 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 26 Jan 2026 09:22:37 GMT Subject: [jdk26] Integrated: 8375314: Parallel: Crash iterating over unloaded classes for ObjectCountAfterGC event In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 09:07:04 GMT, Thomas Schatzl wrote: > Hi all, > > This pull request contains a backport of commit [f3381f0f](https://github.com/openjdk/jdk/commit/f3381f0ffe2207e1765558f6f49e5a0280a3f920) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Thomas Schatzl on 22 Jan 2026 and was reviewed by Roman Kennke, Stefan Johansson and Ivan Walulya. > > There has been a merge error in `collectedHeap.inline.hpp` in the copyright line, the dates did not match up. > > Thanks! This pull request has now been integrated. Changeset: d0fd898a Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/d0fd898a96eb0bb8b463d3f44e300e58d0ec46ee Stats: 145 lines in 7 files changed: 129 ins; 11 del; 5 mod 8375314: Parallel: Crash iterating over unloaded classes for ObjectCountAfterGC event Reviewed-by: iwalulya Backport-of: f3381f0ffe2207e1765558f6f49e5a0280a3f920 ------------- PR: https://git.openjdk.org/jdk/pull/29381 From tschatzl at openjdk.org Mon Jan 26 09:23:39 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 26 Jan 2026 09:23:39 GMT Subject: [jdk26] Integrated: 8375541: G1: Race in G1BarrierSet::write_ref_field_post() In-Reply-To: <0KtsS7nbUtuxJd6bHR9SXKG9jT9F51am7adXNqLMHOg=.92621457-bfd3-4344-b157-97b4a3fb51cf@github.com> References: <0KtsS7nbUtuxJd6bHR9SXKG9jT9F51am7adXNqLMHOg=.92621457-bfd3-4344-b157-97b4a3fb51cf@github.com> Message-ID: On Fri, 23 Jan 2026 08:32:18 GMT, Thomas Schatzl wrote: > Hi all, > > This pull request contains a backport of commit [0ad81fbd](https://github.com/openjdk/jdk/commit/0ad81fbd161edbc8479e5af5c0f8d6098f6c72d1) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Thomas Schatzl on 22 Jan 2026 and was reviewed by Ivan Walulya, Stefan Johansson and Aleksey Shipilev. > > Thanks! This pull request has now been integrated. Changeset: 47c58dc6 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/47c58dc66b56cb486dd891a95636e71654994c46 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8375541: G1: Race in G1BarrierSet::write_ref_field_post() Reviewed-by: iwalulya Backport-of: 0ad81fbd161edbc8479e5af5c0f8d6098f6c72d1 ------------- PR: https://git.openjdk.org/jdk/pull/29378 From tschatzl at openjdk.org Mon Jan 26 09:45:46 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 26 Jan 2026 09:45:46 GMT Subject: RFR: 8376115: G1: Convert G1CMRootRegions to use Atomic [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review this change to convert `G1CMRootRegions` to use `Atomic`. > > Testing: gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * kbarrett review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29363/files - new: https://git.openjdk.org/jdk/pull/29363/files/bcc72bdb..d4625551 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29363&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29363&range=00-01 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29363.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29363/head:pull/29363 PR: https://git.openjdk.org/jdk/pull/29363 From tschatzl at openjdk.org Mon Jan 26 09:47:36 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 26 Jan 2026 09:47:36 GMT Subject: RFR: 8376119: G1: Convert volatiles in G1CMMarkStack to Atomic In-Reply-To: References: <4KamrOFSNhCYCMO7mEj_e3wRlzx2k3FTypc_pfU2Vp4=.d61da684-f1ce-470d-9106-312d39da9f26@github.com> Message-ID: On Fri, 23 Jan 2026 19:15:47 GMT, Kim Barrett wrote: >> ` >> struct TaskQueueEntryChunk { >> TaskQueueEntryChunk* next; >> G1TaskQueueEntry data[EntriesPerChunk]; >> }; >> ` >> >> In this case, should we also have `TaskQueueEntryChunk* next;` as Atomic? > >> `struct TaskQueueEntryChunk { TaskQueueEntryChunk* next; G1TaskQueueEntry data[EntriesPerChunk]; };` >> >> In this case, should we also have `TaskQueueEntryChunk* next;` as Atomic? > > I only found uses of `next` while holding `G1MarkStackChunkList_lock`. Thanks @kimbarrett @walulyai for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/29365#issuecomment-3798691614 From tschatzl at openjdk.org Mon Jan 26 09:51:01 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 26 Jan 2026 09:51:01 GMT Subject: Integrated: 8376119: G1: Convert volatiles in G1CMMarkStack to Atomic In-Reply-To: <4KamrOFSNhCYCMO7mEj_e3wRlzx2k3FTypc_pfU2Vp4=.d61da684-f1ce-470d-9106-312d39da9f26@github.com> References: <4KamrOFSNhCYCMO7mEj_e3wRlzx2k3FTypc_pfU2Vp4=.d61da684-f1ce-470d-9106-312d39da9f26@github.com> Message-ID: On Thu, 22 Jan 2026 15:35:05 GMT, Thomas Schatzl wrote: > Hi all, > > please review this conversion of volatiles that do not use any `AtomicAccess` method in `G1CMMarkStack` but are marked as such to indicate potential concurrency when accessing them. Typically we do some phased access, i.e. one (single-threaded) phase writes them, another only reads from them. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 42c0126f Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/42c0126fb2067b5f792e99af9ad131bab7502c08 Stats: 14 lines in 3 files changed: 0 ins; 0 del; 14 mod 8376119: G1: Convert volatiles in G1CMMarkStack to Atomic Reviewed-by: kbarrett, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/29365 From tschatzl at openjdk.org Mon Jan 26 10:03:18 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 26 Jan 2026 10:03:18 GMT Subject: RFR: 8376126: G1: Convert remaining volatiles in G1ConcurrentMark to Atomic [v2] In-Reply-To: References: Message-ID: > Hi all, > > please convert remaining volatile declarations in `G1ConcurrentMark` to use `Atomic`. These volatiles are used to indicate concurrent phased access (like changing the variable in thread A, then reading the variable in thread B while A is dormant, or only ever updating it in one direction) where concurrency safety is provided by barriers between these phases. But there are also other cases) > > The exception is `G1ConcurrentMark::_finger` that has apparently been overlooked in an earlier changes. > > Testing: gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * reviews ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29368/files - new: https://git.openjdk.org/jdk/pull/29368/files/47925be9..d7126996 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29368&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29368&range=00-01 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29368.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29368/head:pull/29368 PR: https://git.openjdk.org/jdk/pull/29368 From lkorinth at openjdk.org Mon Jan 26 10:10:59 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 26 Jan 2026 10:10:59 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v6] In-Reply-To: References: Message-ID: > This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. > > It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. > > This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. > > I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: - Merge branch 'master' into _8367993 - Merge branch '_master_jdk' into _8367993 - Merge branch '_8373253' into _8367993 - rename of method - Proposal by Stefan J - wip - Revert "8373253: Re-work InjectGCWorkerCreationFailure for future changes" This reverts commit d45ea8817ab2303b2decd8cbb2cd1bf5280aa181. - Revert "Fixup after comment from Ivan." This reverts commit 2aa8aa4b68027b62a8d4be1b86720fadfa48dda5. - remove commented out code - Stefan J 4 - ... and 9 more: https://git.openjdk.org/jdk/compare/90b54692...b41d4a0e ------------- Changes: https://git.openjdk.org/jdk/pull/28723/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28723&range=05 Stats: 57 lines in 9 files changed: 30 ins; 6 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/28723.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28723/head:pull/28723 PR: https://git.openjdk.org/jdk/pull/28723 From tschatzl at openjdk.org Mon Jan 26 10:13:03 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 26 Jan 2026 10:13:03 GMT Subject: RFR: 8376293: Bad copyright header in g1ConcurrentRefineStats.inline.hpp breaks the build Message-ID: Hi all, please review this change to fix the copyright header that added an additional word due to carelessness. Testing: local compilation, checking that source validation passes in CI Thanks, Thomas ------------- Commit messages: - 8376293 Changes: https://git.openjdk.org/jdk/pull/29410/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29410&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376293 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29410.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29410/head:pull/29410 PR: https://git.openjdk.org/jdk/pull/29410 From mhaessig at openjdk.org Mon Jan 26 10:13:04 2026 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Mon, 26 Jan 2026 10:13:04 GMT Subject: RFR: 8376293: Bad copyright header in g1ConcurrentRefineStats.inline.hpp breaks the build In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 10:03:26 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to fix the copyright header that added an additional word due to carelessness. > > Testing: local compilation, checking that source validation passes in CI > > Thanks, > Thomas Looks good. Thank you for the quick reaction! ------------- Marked as reviewed by mhaessig (Committer). PR Review: https://git.openjdk.org/jdk/pull/29410#pullrequestreview-3705374054 From chagedorn at openjdk.org Mon Jan 26 10:13:05 2026 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Mon, 26 Jan 2026 10:13:05 GMT Subject: RFR: 8376293: Bad copyright header in g1ConcurrentRefineStats.inline.hpp breaks the build In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 10:03:26 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to fix the copyright header that added an additional word due to carelessness. > > Testing: local compilation, checking that source validation passes in CI > > Thanks, > Thomas Looks good and trivial, thanks for quickly fixing it! ------------- Marked as reviewed by chagedorn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29410#pullrequestreview-3705378875 From lkorinth at openjdk.org Mon Jan 26 10:17:55 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 26 Jan 2026 10:17:55 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v6] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 10:10:59 GMT, Leo Korinth wrote: >> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. >> >> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. >> >> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. >> >> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. > > Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: > > - Merge branch 'master' into _8367993 > - Merge branch '_master_jdk' into _8367993 > - Merge branch '_8373253' into _8367993 > - rename of method > - Proposal by Stefan J > - wip > - Revert "8373253: Re-work InjectGCWorkerCreationFailure for future changes" > > This reverts commit d45ea8817ab2303b2decd8cbb2cd1bf5280aa181. > - Revert "Fixup after comment from Ivan." > > This reverts commit 2aa8aa4b68027b62a8d4be1b86720fadfa48dda5. > - remove commented out code > - Stefan J 4 > - ... and 9 more: https://git.openjdk.org/jdk/compare/90b54692...b41d4a0e Please wait with reviewing my latest changes, I think I am doing the initialisation too early now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28723#issuecomment-3798823060 From tschatzl at openjdk.org Mon Jan 26 10:21:19 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 26 Jan 2026 10:21:19 GMT Subject: RFR: 8376293: Bad copyright header in g1ConcurrentRefineStats.inline.hpp breaks the build In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 10:09:30 GMT, Christian Hagedorn wrote: >> Hi all, >> >> please review this change to fix the copyright header that added an additional word due to carelessness. >> >> Testing: local compilation, checking that source validation passes in CI >> >> Thanks, >> Thomas > > Looks good and trivial, thanks for quickly fixing it! Thanks @chhagedorn @mhaessig for your reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29410#issuecomment-3798824526 From tschatzl at openjdk.org Mon Jan 26 10:21:21 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 26 Jan 2026 10:21:21 GMT Subject: Integrated: 8376293: Bad copyright header in g1ConcurrentRefineStats.inline.hpp breaks the build In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 10:03:26 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to fix the copyright header that added an additional word due to carelessness. > > Testing: local compilation, checking that source validation passes in CI > > Thanks, > Thomas This pull request has now been integrated. Changeset: 48d63687 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/48d636872f1bd239d12823bf2f9d4aa32384f5e5 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8376293: Bad copyright header in g1ConcurrentRefineStats.inline.hpp breaks the build Reviewed-by: mhaessig, chagedorn ------------- PR: https://git.openjdk.org/jdk/pull/29410 From lkorinth at openjdk.org Mon Jan 26 10:57:43 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 26 Jan 2026 10:57:43 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v7] In-Reply-To: References: Message-ID: <9QqfS1DnQ-WBbHf62xd5r2EnCno34rR1KMebqDmIKg8=.7ba8bc23-12c0-49ad-911c-b622d91382ed@github.com> > This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. > > It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. > > This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. > > I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - rename of method - Proposal by Stefan J - wip - Revert "8373253: Re-work InjectGCWorkerCreationFailure for future changes" This reverts commit d45ea8817ab2303b2decd8cbb2cd1bf5280aa181. - Revert "Fixup after comment from Ivan." This reverts commit 2aa8aa4b68027b62a8d4be1b86720fadfa48dda5. - Merge branch 'master' into _8373253 - Fixup after comment from Ivan. - 8373253: Re-work InjectGCWorkerCreationFailure for future changes ------------- Changes: https://git.openjdk.org/jdk/pull/28723/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28723&range=06 Stats: 16 lines in 2 files changed: 15 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28723.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28723/head:pull/28723 PR: https://git.openjdk.org/jdk/pull/28723 From stefank at openjdk.org Mon Jan 26 12:02:33 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 26 Jan 2026 12:02:33 GMT Subject: RFR: 8376191: Remove AtomicAccess include from files that do not use it in gc/shared In-Reply-To: References: Message-ID: <-NxTu4AdV4ufRmv9HWHZim4BeBF3SdaYk_Dy_eWUFGQ=.488c8a08-0856-4272-85f0-f9bfd88278ba@github.com> On Fri, 23 Jan 2026 12:00:48 GMT, Thomas Schatzl wrote: > Hi all, > > please review this trivial change to remove the `AtomicAccess.hpp` include to files that do not use anything from that file. > > Testing: gha, local compilation with disabled precompiled headers on linux-aarch64 > > Thanks, > Thomas src/hotspot/share/gc/shared/preservedMarks.cpp line 32: > 30: #include "memory/resourceArea.hpp" > 31: #include "oops/oop.inline.hpp" > 32: #include "runtime/atomicAccess.hpp" There's an AtomicAccess usage in this file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29384#discussion_r2727337468 From aboldtch at openjdk.org Mon Jan 26 12:16:19 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 26 Jan 2026 12:16:19 GMT Subject: RFR: 8374676: ZGC: Convert zAbort to use Atomic In-Reply-To: <3WJ0EqDX5JbpbMwnGu_Q8NO9UA3yHHdIEQI7elKt5a0=.44251ee2-a4b5-4440-bcdc-b89b7bc3da75@github.com> References: <3WJ0EqDX5JbpbMwnGu_Q8NO9UA3yHHdIEQI7elKt5a0=.44251ee2-a4b5-4440-bcdc-b89b7bc3da75@github.com> Message-ID: On Wed, 14 Jan 2026 07:52:31 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zAbort. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Thanks for the reviews. Compiled locally with latest master merged. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29217#issuecomment-3799272057 From aboldtch at openjdk.org Mon Jan 26 12:19:49 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 26 Jan 2026 12:19:49 GMT Subject: Integrated: 8374676: ZGC: Convert zAbort to use Atomic In-Reply-To: <3WJ0EqDX5JbpbMwnGu_Q8NO9UA3yHHdIEQI7elKt5a0=.44251ee2-a4b5-4440-bcdc-b89b7bc3da75@github.com> References: <3WJ0EqDX5JbpbMwnGu_Q8NO9UA3yHHdIEQI7elKt5a0=.44251ee2-a4b5-4440-bcdc-b89b7bc3da75@github.com> Message-ID: On Wed, 14 Jan 2026 07:52:31 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zAbort. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 This pull request has now been integrated. Changeset: de5c7a9e Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/de5c7a9e8607b2a6219d98f9b81ddce4ca92baef Stats: 11 lines in 3 files changed: 1 ins; 3 del; 7 mod 8374676: ZGC: Convert zAbort to use Atomic Reviewed-by: stefank, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/29217 From aboldtch at openjdk.org Mon Jan 26 13:44:35 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 26 Jan 2026 13:44:35 GMT Subject: RFR: 8374677: ZGC: Convert zArray to use Atomic In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 07:57:52 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zArray. > > Not sure about `NextType` name. Unclear how we want to name our using type aliases in the ZGC code. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Thanks for the reviews. Compiled locally with latest master merged. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29218#issuecomment-3799678837 From aboldtch at openjdk.org Mon Jan 26 13:46:59 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 26 Jan 2026 13:46:59 GMT Subject: Integrated: 8374677: ZGC: Convert zArray to use Atomic In-Reply-To: References: Message-ID: <55O2QC4MM9gF9chN8t1NC0zLuuJ-fGcUGmPKtp_M7RA=.72a846e8-f33e-4466-ac01-4d15c0728d07@github.com> On Wed, 14 Jan 2026 07:57:52 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zArray. > > Not sure about `NextType` name. Unclear how we want to name our using type aliases in the ZGC code. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 This pull request has now been integrated. Changeset: 319e21e9 Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/319e21e9b48b4a9646c803e23d16f0b7df827d3f Stats: 9 lines in 2 files changed: 2 ins; 1 del; 6 mod 8374677: ZGC: Convert zArray to use Atomic Reviewed-by: stefank, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/29218 From aboldtch at openjdk.org Mon Jan 26 13:57:01 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 26 Jan 2026 13:57:01 GMT Subject: RFR: 8374678: ZGC: Convert zForwarding to use Atomic [v2] In-Reply-To: References: Message-ID: <8fi7Ls38jbIHnIzGUSWVKrN3JlKJILHYdZSpRsKo6aY=.fa8f01a2-4dff-4935-bb6c-ae90ebfb545c@github.com> On Wed, 14 Jan 2026 09:36:37 GMT, Axel Boldt-Christmas wrote: >> Convert usages of AtomicAccess to Atomic in zForwarding. >> >> `_ref_count` is unused by the SA. There is currently no implementation of Atomic in SA. >> >> Testing: >> * GHA >> * Tier 1-2 with ZGC linux x64 and linux aarch64 >> * Stress tests with ZGC linux x64 and linux aarch64 > > Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Use compare_set > - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8374678 > - ZGC: Convert zForwarding to use Atomic Thanks for the reviews. Compiled locally with latest master merged. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29220#issuecomment-3799725398 From aboldtch at openjdk.org Mon Jan 26 13:57:02 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 26 Jan 2026 13:57:02 GMT Subject: Integrated: 8374678: ZGC: Convert zForwarding to use Atomic In-Reply-To: References: Message-ID: <8OjzCd86l6RwNbBAhXsTQSzeoh4BCPNhPq72HOZIip8=.7ad0e8d2-74fd-456f-8f3d-c34a73142ee7@github.com> On Wed, 14 Jan 2026 08:07:12 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zForwarding. > > `_ref_count` is unused by the SA. There is currently no implementation of Atomic in SA. > > Testing: > * GHA > * Tier 1-2 with ZGC linux x64 and linux aarch64 > * Stress tests with ZGC linux x64 and linux aarch64 This pull request has now been integrated. Changeset: 512f95cf Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/512f95cf2632167149e2118853ab4d6d636fe0a3 Stats: 39 lines in 4 files changed: 1 ins; 2 del; 36 mod 8374678: ZGC: Convert zForwarding to use Atomic Reviewed-by: stefank, eosterlund ------------- PR: https://git.openjdk.org/jdk/pull/29220 From tschatzl at openjdk.org Mon Jan 26 13:59:44 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 26 Jan 2026 13:59:44 GMT Subject: RFR: 8376191: Remove AtomicAccess include from files that do not use it in gc/shared [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review this trivial change to remove the `AtomicAccess.hpp` include to files that do not use anything from that file. > > Testing: gha, local compilation with disabled precompiled headers on linux-aarch64 > > Thanks, > Thomas Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - * stefank review - Merge branch 'master' into 8376191-remove-atomicaccess-shared - 8376191 Hi all, please review this trivial change to remove the `AtomicAccess.hpp` include to files that do not use anything from that file. Testing: gha, local compilation with disabled precompiled headers on linux-aarch64 Thanks, Thomas ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29384/files - new: https://git.openjdk.org/jdk/pull/29384/files/8b30f33b..c5dba82d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29384&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29384&range=00-01 Stats: 10468 lines in 277 files changed: 3074 ins; 1796 del; 5598 mod Patch: https://git.openjdk.org/jdk/pull/29384.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29384/head:pull/29384 PR: https://git.openjdk.org/jdk/pull/29384 From aboldtch at openjdk.org Mon Jan 26 14:16:59 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 26 Jan 2026 14:16:59 GMT Subject: RFR: 8374679: ZGC: Convert zForwardingAllocator to use Atomic In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 08:29:43 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zForwardingAllocator. > > We currently use plain loads and stores which are synchronised and ordered with respect to the allocation by means of us starting worker threads which allocate and awaiting them to finish. This patch changes everything to have atomic semantics, but the loads and stores are still relaxed. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Thanks for the reviews. Compiled locally with latest master merged. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29221#issuecomment-3799808669 From aboldtch at openjdk.org Mon Jan 26 14:17:00 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 26 Jan 2026 14:17:00 GMT Subject: Integrated: 8374679: ZGC: Convert zForwardingAllocator to use Atomic In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 08:29:43 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zForwardingAllocator. > > We currently use plain loads and stores which are synchronised and ordered with respect to the allocation by means of us starting worker threads which allocate and awaiting them to finish. This patch changes everything to have atomic semantics, but the loads and stores are still relaxed. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 This pull request has now been integrated. Changeset: fef85ff9 Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/fef85ff932055cd5385633f3b283e6201cdcaa68 Stats: 12 lines in 3 files changed: 2 ins; 1 del; 9 mod 8374679: ZGC: Convert zForwardingAllocator to use Atomic Reviewed-by: stefank, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/29221 From aboldtch at openjdk.org Mon Jan 26 14:27:50 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 26 Jan 2026 14:27:50 GMT Subject: RFR: 8374680: ZGC: Convert zGeneration to use Atomic In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 08:31:24 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zGeneration. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Thanks for the reviews. Compiled locally with latest master merged. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29222#issuecomment-3799874103 From aboldtch at openjdk.org Mon Jan 26 14:31:28 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 26 Jan 2026 14:31:28 GMT Subject: Integrated: 8374680: ZGC: Convert zGeneration to use Atomic In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 08:31:24 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zGeneration. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 This pull request has now been integrated. Changeset: b59f49a1 Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/b59f49a1c3e370f794291a1f948e67d2651ece11 Stats: 16 lines in 2 files changed: 1 ins; 1 del; 14 mod 8374680: ZGC: Convert zGeneration to use Atomic Reviewed-by: stefank, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/29222 From aboldtch at openjdk.org Mon Jan 26 14:48:16 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 26 Jan 2026 14:48:16 GMT Subject: RFR: 8374681: ZGC: Convert zJNICritical to use Atomic [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 06:06:24 GMT, Axel Boldt-Christmas wrote: >> Convert usages of AtomicAccess to Atomic in zJNICritical. >> >> Testing: >> * GHA >> * HotSpot GC tests with ZGC linux x64 and linux aarch64 > > Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Use compare_set > - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8374681 > - ZGC: Convert zJNICritical to use Atomic Thanks for the reviews. Compiled locally with latest master merged. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29223#issuecomment-3799961787 From aboldtch at openjdk.org Mon Jan 26 14:48:17 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 26 Jan 2026 14:48:17 GMT Subject: Integrated: 8374681: ZGC: Convert zJNICritical to use Atomic In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 09:15:32 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zJNICritical. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 This pull request has now been integrated. Changeset: 61b722d5 Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/61b722d59a799ba943476a03be3a1c7649aa0c27 Stats: 21 lines in 2 files changed: 1 ins; 1 del; 19 mod 8374681: ZGC: Convert zJNICritical to use Atomic Reviewed-by: tschatzl, stefank ------------- PR: https://git.openjdk.org/jdk/pull/29223 From tschatzl at openjdk.org Mon Jan 26 14:50:25 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 26 Jan 2026 14:50:25 GMT Subject: RFR: 8376328: Convert PLABStats to use Atomic Message-ID: Hi all, please review this change to convert the `PLABStats` class to use `Atomic`. Testing: gha Thanks, Thomas ------------- Commit messages: - 8376328 Changes: https://git.openjdk.org/jdk/pull/29420/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29420&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376328 Stats: 27 lines in 3 files changed: 2 ins; 2 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/29420.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29420/head:pull/29420 PR: https://git.openjdk.org/jdk/pull/29420 From aboldtch at openjdk.org Mon Jan 26 15:05:44 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 26 Jan 2026 15:05:44 GMT Subject: RFR: 8374682: ZGC: Convert zLiveMap to use Atomic In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 06:06:10 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zLiveMap. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Thanks for the reviews. Compiled locally with latest master merged. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29243#issuecomment-3800048563 From aboldtch at openjdk.org Mon Jan 26 15:08:25 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 26 Jan 2026 15:08:25 GMT Subject: Integrated: 8374682: ZGC: Convert zLiveMap to use Atomic In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 06:06:10 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zLiveMap. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 This pull request has now been integrated. Changeset: 99b4e05d Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/99b4e05d502b68844699faa025e0d5bd51135d8f Stats: 22 lines in 3 files changed: 1 ins; 2 del; 19 mod 8374682: ZGC: Convert zLiveMap to use Atomic Reviewed-by: stefank, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/29243 From aboldtch at openjdk.org Mon Jan 26 15:14:51 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 26 Jan 2026 15:14:51 GMT Subject: RFR: 8374683: ZGC: Convert zLock to use Atomic In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 06:08:04 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zLock. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Thanks for the reviews. Compiled locally with latest master merged. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29244#issuecomment-3800090038 From aboldtch at openjdk.org Mon Jan 26 15:17:38 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 26 Jan 2026 15:17:38 GMT Subject: Integrated: 8374683: ZGC: Convert zLock to use Atomic In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 06:08:04 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zLock. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 This pull request has now been integrated. Changeset: 66485675 Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/664856757405e149bb98474872938e3a62b62302 Stats: 11 lines in 2 files changed: 1 ins; 1 del; 9 mod 8374683: ZGC: Convert zLock to use Atomic Reviewed-by: stefank, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/29244 From aboldtch at openjdk.org Mon Jan 26 15:39:11 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 26 Jan 2026 15:39:11 GMT Subject: RFR: 8374684: ZGC: Convert zMark to use Atomic In-Reply-To: <2-6Q_cMDlDBi4NKK_IN_QmIcSuUZNsN8vGEqX8z1fkY=.c968e317-5ea1-4338-9003-ef1df3c89a3c@github.com> References: <2-6Q_cMDlDBi4NKK_IN_QmIcSuUZNsN8vGEqX8z1fkY=.c968e317-5ea1-4338-9003-ef1df3c89a3c@github.com> Message-ID: On Thu, 15 Jan 2026 06:09:25 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zMark. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Thanks for the reviews. Compiled locally with latest master merged. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29245#issuecomment-3800231772 From aboldtch at openjdk.org Mon Jan 26 15:39:12 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 26 Jan 2026 15:39:12 GMT Subject: Integrated: 8374684: ZGC: Convert zMark to use Atomic In-Reply-To: <2-6Q_cMDlDBi4NKK_IN_QmIcSuUZNsN8vGEqX8z1fkY=.c968e317-5ea1-4338-9003-ef1df3c89a3c@github.com> References: <2-6Q_cMDlDBi4NKK_IN_QmIcSuUZNsN8vGEqX8z1fkY=.c968e317-5ea1-4338-9003-ef1df3c89a3c@github.com> Message-ID: On Thu, 15 Jan 2026 06:09:25 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zMark. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 This pull request has now been integrated. Changeset: f4607ed0 Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/f4607ed0a7ea2504c1d72dd3dab0b21e583fa0e7 Stats: 13 lines in 2 files changed: 2 ins; 1 del; 10 mod 8374684: ZGC: Convert zMark to use Atomic Reviewed-by: stefank, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/29245 From tschatzl at openjdk.org Mon Jan 26 16:03:17 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 26 Jan 2026 16:03:17 GMT Subject: RFR: 8376350: Convert ReferenceProcessorPhaseTimes to use Atomic Message-ID: <2wZjpooawLKkrLsy4Z1MHU2dv8DeF8oxWMLqsCD8KXE=.2a356189-9302-4c17-88ab-b7a7b3e5e1cb@github.com> Hi all, please review this change to convert `ReferenceProcessorPhaseTimes` to use `Atomic`. Testing: gha Thanks, Thomas ------------- Commit messages: - 8376350 Changes: https://git.openjdk.org/jdk/pull/29423/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29423&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376350 Stats: 9 lines in 2 files changed: 2 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/29423.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29423/head:pull/29423 PR: https://git.openjdk.org/jdk/pull/29423 From kdnilsen at openjdk.org Mon Jan 26 16:36:03 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 26 Jan 2026 16:36:03 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v17] In-Reply-To: References: Message-ID: > After studying large numbers of GC logs with degenerated cycles that have resulted from "late" triggers, we propose the following general improvements: > > 1. Track trends in GC times rather than always using the average GC time plus standard deviation. In many situations, GC times trend upward due to, for example, increasing amounts of live data that must be marked as a workload builds up its working set of memory. > 2. Sample allocation rates more frequently than once every 100 ms. > 3. Track trends in allocation rates. In some situations, the allocation rate trends upwards due to, for example, the start of a new phase of execution or a spike in client workload. > 4. When we detect acceleration of allocation rate, predict consumption of memory based on accelerated allocation rates rather than assuming constant allocation rate. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: remove problematic debug messages ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29039/files - new: https://git.openjdk.org/jdk/pull/29039/files/e75b83ec..468104fa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=15-16 Stats: 13 lines in 1 file changed: 0 ins; 13 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29039.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29039/head:pull/29039 PR: https://git.openjdk.org/jdk/pull/29039 From tschatzl at openjdk.org Mon Jan 26 16:39:28 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 26 Jan 2026 16:39:28 GMT Subject: RFR: 8376351: Parallel: Convert ParallelScavengeHeap to use Atomic Message-ID: Hi all, please review this change to use `Atomic` in `ParallelScavengeHeap`. Testing: gha Thanks, Thomas ------------- Commit messages: - 8376351 Changes: https://git.openjdk.org/jdk/pull/29424/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29424&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376351 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29424.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29424/head:pull/29424 PR: https://git.openjdk.org/jdk/pull/29424 From tschatzl at openjdk.org Mon Jan 26 17:04:22 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 26 Jan 2026 17:04:22 GMT Subject: RFR: 8376199: Convert CodeCacheUnloadingTask to use Atomic Message-ID: Hi all, please review this change to convert usages of `AtomicAccess` to `Atomic` in the `CodeCacheUnloadingTask` class. Testing: gha Thanks, Thomas ------------- Commit messages: - 8376199 Changes: https://git.openjdk.org/jdk/pull/29418/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29418&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376199 Stats: 7 lines in 2 files changed: 1 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/29418.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29418/head:pull/29418 PR: https://git.openjdk.org/jdk/pull/29418 From tschatzl at openjdk.org Mon Jan 26 17:30:28 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 26 Jan 2026 17:30:28 GMT Subject: RFR: 8376356: Parallel: Convert PSCardTable to use Atomic Message-ID: Hi all, please review this change to convert `PSCardTable` to use `Atomic`. Testing: gha Thanks, Thomas ------------- Commit messages: - 8376356 Changes: https://git.openjdk.org/jdk/pull/29428/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29428&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376356 Stats: 6 lines in 2 files changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/29428.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29428/head:pull/29428 PR: https://git.openjdk.org/jdk/pull/29428 From manc at google.com Mon Jan 26 20:50:16 2026 From: manc at google.com (Man Cao) Date: Mon, 26 Jan 2026 12:50:16 -0800 Subject: One question about hotspot g1 heap adaptive resizing feature In-Reply-To: References: Message-ID: Since hotspot-gc-dev does not support pictures/screenshots, here is the context based on a previous email that Shaojun sent to me directly. First screenshot is from https://github.com/openjdk/jdk/pull/24211#issuecomment-2777769994: > Somewhat related to above, our experience with our internal algorithm that adjusts SoftMaxHeapSize based on GC CPU overhead, encountered cases that it behaves poorly. The problem is that some workload have large variance in mutator's CPU usage (e.g. peak hours vs off-peak hours), but smaller variance in GC CPU usage. Then it does not make much sense to maintain a constant % for GC CPU overhead, which could cause excessive heap expansion when mutator CPU usage is low. The workaround is to take live size into consideration when calculating SoftMaxHeapSize, which is similar to how Min/MaxHeapFreeRatio works. > I'm not sure if GCTimeRatio using wall time and pause time could run into similar issues. I'm happy to experiment when we make progress on JDK-8238687/JDK-8248324/JDK-8349978. Second screenshot is from https://bugs.openjdk.org/browse/JDK-8359348?focusedId=14802633#comment-14802633 : > Regarding to the fluctuating mutator CPU usage issue, upon reviewing https://github.com/openjdk/jdk/pull/26351, I'm convinced that the proposed approach does not suffer from this issue. This is because the proposed approach does not rely on the total process CPU usage, and does not measure "GC CPU overhead", i.e., a ratio of GC CPU usage over total CPU usage. -Man On Fri, Jan 23, 2026 at 11:28?PM shaojun wang wrote: > Hi Men Cao > > I read one openjdk bug which discuss G1 heap adaptive resizing feature, > and I noticed that you mention one question like this: > > [image: image.png] > > and then you mentioned that you were convinced that the proposed approach > does not suffer from this issue. This is because the proposed approach > does not rely on the total process CPU usage, and does not measure "GC CPU > overhead", i.e., a ratio of GC CPU usage over total CPU usage. > > [image: image.png] > > my question is that even with GCTimeRatio(gc time / (gc time + app time)) > , the problem will still exist if the application > fall into a very low cpu cost state. for example, gc_time = 30, > app_time=40?GCTimeRatio is: 30/(30+40)= 0.42, the g1 > heap size policy will try to extend heap size to scale down > GCTimeRatio?But actually the application doesn't care about > its performance at all under the state?because there is basically no or > merely request for the app. Do you have idea about > it? > > https://github.com/openjdk/jdk/pull/24211 > https://bugs.openjdk.org/browse/JDK-8359348 > > From shaojun wang > ByteDance > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkemper at openjdk.org Mon Jan 26 21:43:21 2026 From: wkemper at openjdk.org (William Kemper) Date: Mon, 26 Jan 2026 21:43:21 GMT Subject: RFR: 8374449: Shenandoah: Leaf locks used by Shenandoah need lower ranks [v2] In-Reply-To: <4IGKlFzk930jR8ejTkoYOC-eQvpvxlr0HfzJ5Hgr1gI=.7edc9d4e-10b3-4df6-ab8a-7d74dc0abe51@github.com> References: <4IGKlFzk930jR8ejTkoYOC-eQvpvxlr0HfzJ5Hgr1gI=.7edc9d4e-10b3-4df6-ab8a-7d74dc0abe51@github.com> Message-ID: > Reduce the rank of `safepoint` locks and rename them to avoid confusion with `nosafepoint` ranked locks. William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Merge remote-tracking branch 'jdk/master' into lower-controller-lock-ranks - Add constant for control lock rank - More lock rank tweaks - Go even lower, don't check for safepoint when taking the locks - Merge remote-tracking branch 'jdk/master' into lower-controller-lock-ranks - Use an even lower rank - Lower controller lock ranks to avoid false deadlock detection ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29333/files - new: https://git.openjdk.org/jdk/pull/29333/files/e3086a85..e8f32655 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29333&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29333&range=00-01 Stats: 26446 lines in 791 files changed: 12573 ins; 4503 del; 9370 mod Patch: https://git.openjdk.org/jdk/pull/29333.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29333/head:pull/29333 PR: https://git.openjdk.org/jdk/pull/29333 From manc at google.com Mon Jan 26 22:13:48 2026 From: manc at google.com (Man Cao) Date: Mon, 26 Jan 2026 14:13:48 -0800 Subject: One question about hotspot g1 heap adaptive resizing feature In-Reply-To: References: Message-ID: > my question is that even with GCTimeRatio(gc time / (gc time + app time)) , the problem will still exist if the application fall into a very low cpu cost state. for example, gc_time = 30, app_time=40?GCTimeRatio is: 30/(30+40)= 0.42, the g1 heap size policy will try to extend heap size to scale down GCTimeRatio?But actually the application doesn't care about its performance at all under the state?because there is basically no or merely request for the app. Do you have idea about it? The rationale for https://bugs.openjdk.org/browse/JDK-8359348?focusedId=14802633#comment-14802633 is that the GCTimeRatio approach is mostly based on pause times, instead of CPU time. The pause-time approach is more stable and less prone to drastic fluctuations. A simplified view for these two approaches is: - GCTimeRatio approach: GC_pause_time / total_wall_time - GC CPU overhead approach: GC_CPU_time / total_CPU_time total_wall_time elapses at a constant rate, so it is a more stable denominator. I experimented with a synthetic workload that exhibits this problem using the GC CPU overhead approach. This problem did not appear with the GCTimeRatio approach. For Shaojun's case, the application spends 42% of its wall time inside GC pauses. It's close to GC thrashing, so the JVM expands the heap to prevent that. Does this behavior cause large heap size growth in JDK 26, compared to JDK 25? Could you provide a reproducer program or GC logs? If the application has a small heap, https://bugs.openjdk.org/browse/JDK-8349978 is a known issue with the GCTimeRatio approach for small heaps. Incidentally, we noticed some applications grow to a larger heap with JDK 26 compared to JDK 25. We have not yet examined this issue in depth. -Man On Mon, Jan 26, 2026 at 12:50?PM Man Cao wrote: > Since hotspot-gc-dev does not support pictures/screenshots, here is the > context based on a previous email that Shaojun sent to me directly. > > First screenshot is from > https://github.com/openjdk/jdk/pull/24211#issuecomment-2777769994: > > > Somewhat related to above, our experience with our internal algorithm > that adjusts SoftMaxHeapSize based on GC CPU overhead, encountered cases > that it behaves poorly. The problem is that some workload have large > variance in mutator's CPU usage (e.g. peak hours vs off-peak hours), but > smaller variance in GC CPU usage. Then it does not make much sense to > maintain a constant % for GC CPU overhead, which could cause excessive heap > expansion when mutator CPU usage is low. The workaround is to take live > size into consideration when calculating SoftMaxHeapSize, which is similar > to how Min/MaxHeapFreeRatio works. > > I'm not sure if GCTimeRatio using wall time and pause time could run > into similar issues. I'm happy to experiment when we make progress on > JDK-8238687/JDK-8248324/JDK-8349978. > > Second screenshot is from > https://bugs.openjdk.org/browse/JDK-8359348?focusedId=14802633#comment-14802633 > : > > > Regarding to the fluctuating mutator CPU usage issue, upon reviewing > https://github.com/openjdk/jdk/pull/26351, I'm convinced that the > proposed approach does not suffer from this issue. This is because the > proposed approach does not rely on the total process CPU usage, and does > not measure "GC CPU overhead", i.e., a ratio of GC CPU usage over total CPU > usage. > > -Man > > > On Fri, Jan 23, 2026 at 11:28?PM shaojun wang > wrote: > >> Hi Men Cao >> >> I read one openjdk bug which discuss G1 heap adaptive resizing feature, >> and I noticed that you mention one question like this: >> >> [image: image.png] >> >> and then you mentioned that you were convinced that the proposed approach >> does not suffer from this issue. This is because the proposed approach >> does not rely on the total process CPU usage, and does not measure "GC >> CPU overhead", i.e., a ratio of GC CPU usage over total CPU usage. >> >> [image: image.png] >> >> my question is that even with GCTimeRatio(gc time / (gc time + app time)) >> , the problem will still exist if the application >> fall into a very low cpu cost state. for example, gc_time = 30, >> app_time=40?GCTimeRatio is: 30/(30+40)= 0.42, the g1 >> heap size policy will try to extend heap size to scale down >> GCTimeRatio?But actually the application doesn't care about >> its performance at all under the state?because there is basically no or >> merely request for the app. Do you have idea about >> it? >> >> https://github.com/openjdk/jdk/pull/24211 >> https://bugs.openjdk.org/browse/JDK-8359348 >> >> From shaojun wang >> ByteDance >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kdnilsen at openjdk.org Mon Jan 26 23:33:43 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 26 Jan 2026 23:33:43 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v18] In-Reply-To: References: Message-ID: > After studying large numbers of GC logs with degenerated cycles that have resulted from "late" triggers, we propose the following general improvements: > > 1. Track trends in GC times rather than always using the average GC time plus standard deviation. In many situations, GC times trend upward due to, for example, increasing amounts of live data that must be marked as a workload builds up its working set of memory. > 2. Sample allocation rates more frequently than once every 100 ms. > 3. Track trends in allocation rates. In some situations, the allocation rate trends upwards due to, for example, the start of a new phase of execution or a spike in client workload. > 4. When we detect acceleration of allocation rate, predict consumption of memory based on accelerated allocation rates rather than assuming constant allocation rate. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: align log messages for trigger trace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29039/files - new: https://git.openjdk.org/jdk/pull/29039/files/468104fa..5c611594 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=16-17 Stats: 30 lines in 1 file changed: 0 ins; 14 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/29039.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29039/head:pull/29039 PR: https://git.openjdk.org/jdk/pull/29039 From jeffery.wsj at outlook.com Tue Jan 27 06:40:14 2026 From: jeffery.wsj at outlook.com (shaojun wang) Date: Tue, 27 Jan 2026 06:40:14 +0000 Subject: One question about hotspot g1 heap adaptive resizing feature In-Reply-To: References: Message-ID: Hi Men Cao I read one paper which its link is here: https://dl.acm.org/doi/epdf/10.1145/3617651.3622988, it adopts GC_CPU_time / App_CPU_time as the key standard to resize ZGC's heap. While in jdk26 G1 adopts GC CPU overhead approach: GC_CPU_time / total_CPU_time. In summary there are three kind of approches are: * GCTimeRatio approach: GC_pause_time / total_wall_time * GC CPU overhead approach_1: GC_CPU_time / total_CPU_time * GC CPU overhead approach_2: GC_CPU_time / App_CPU_time > For Shaojun's case, the application spends 42% of its wall time inside GC pauses. It's close to GC thrashing, so the JVM expands the heap to prevent that. Does this behavior cause large heap size growth in JDK 26, compared to JDK 25? Could you provide a reproducer program or GC logs? If the application has a small heap, https://bugs.openjdk.org/browse/JDK-8349978 is a known issue with the GCTimeRatio approach for small heaps. I didn't encounter this issue, but just made a though experiment base on the assumption with GC CPU overhead approach_2. Personally, I think GCTimeRatio approach is not very reasonable to G1 and ZGC, maybe it's good to PSGC. From shaojun wang ByteDance ________________________________ From: Man Cao Sent: Monday, January 26, 2026 2:13 PM To: hotspot-gc-dev at openjdk.org Cc: shaojun wang Subject: Re: One question about hotspot g1 heap adaptive resizing feature > my question is that even with GCTimeRatio(gc time / (gc time + app time)) , the problem will still exist if the application fall into a very low cpu cost state. for example, gc_time = 30, app_time=40?GCTimeRatio is: 30/(30+40)= 0.42, the g1 heap size policy will try to extend heap size to scale down GCTimeRatio?But actually the application doesn't care about its performance at all under the state?because there is basically no or merely request for the app. Do you have idea about it? The rationale for https://bugs.openjdk.org/browse/JDK-8359348?focusedId=14802633#comment-14802633 is that the GCTimeRatio approach is mostly based on pause times, instead of CPU time. The pause-time approach is more stable and less prone to drastic fluctuations. A simplified view for these two approaches is: - GCTimeRatio approach: GC_pause_time / total_wall_time - GC CPU overhead approach: GC_CPU_time / total_CPU_time total_wall_time elapses at a constant rate, so it is a more stable denominator. I experimented with a synthetic workload that exhibits this problem using the GC CPU overhead approach. This problem did not appear with the GCTimeRatio approach. For Shaojun's case, the application spends 42% of its wall time inside GC pauses. It's close to GC thrashing, so the JVM expands the heap to prevent that. Does this behavior cause large heap size growth in JDK 26, compared to JDK 25? Could you provide a reproducer program or GC logs? If the application has a small heap, https://bugs.openjdk.org/browse/JDK-8349978 is a known issue with the GCTimeRatio approach for small heaps. Incidentally, we noticed some applications grow to a larger heap with JDK 26 compared to JDK 25. We have not yet examined this issue in depth. -Man On Mon, Jan 26, 2026 at 12:50?PM Man Cao > wrote: Since hotspot-gc-dev does not support pictures/screenshots, here is the context based on a previous email that Shaojun sent to me directly. First screenshot is from https://github.com/openjdk/jdk/pull/24211#issuecomment-2777769994: > Somewhat related to above, our experience with our internal algorithm that adjusts SoftMaxHeapSize based on GC CPU overhead, encountered cases that it behaves poorly. The problem is that some workload have large variance in mutator's CPU usage (e.g. peak hours vs off-peak hours), but smaller variance in GC CPU usage. Then it does not make much sense to maintain a constant % for GC CPU overhead, which could cause excessive heap expansion when mutator CPU usage is low. The workaround is to take live size into consideration when calculating SoftMaxHeapSize, which is similar to how Min/MaxHeapFreeRatio works. > I'm not sure if GCTimeRatio using wall time and pause time could run into similar issues. I'm happy to experiment when we make progress on JDK-8238687/JDK-8248324/JDK-8349978. Second screenshot is from https://bugs.openjdk.org/browse/JDK-8359348?focusedId=14802633#comment-14802633: > Regarding to the fluctuating mutator CPU usage issue, upon reviewing https://github.com/openjdk/jdk/pull/26351, I'm convinced that the proposed approach does not suffer from this issue. This is because the proposed approach does not rely on the total process CPU usage, and does not measure "GC CPU overhead", i.e., a ratio of GC CPU usage over total CPU usage. -Man On Fri, Jan 23, 2026 at 11:28?PM shaojun wang > wrote: Hi Men Cao I read one openjdk bug which discuss G1 heap adaptive resizing feature, and I noticed that you mention one question like this: [image.png] and then you mentioned that you were convinced that the proposed approach does not suffer from this issue. This is because the proposed approach does not rely on the total process CPU usage, and does not measure "GC CPU overhead", i.e., a ratio of GC CPU usage over total CPU usage. [image.png] my question is that even with GCTimeRatio(gc time / (gc time + app time)) , the problem will still exist if the application fall into a very low cpu cost state. for example, gc_time = 30, app_time=40?GCTimeRatio is: 30/(30+40)= 0.42, the g1 heap size policy will try to extend heap size to scale down GCTimeRatio?But actually the application doesn't care about its performance at all under the state?because there is basically no or merely request for the app. Do you have idea about it? https://github.com/openjdk/jdk/pull/24211 https://bugs.openjdk.org/browse/JDK-8359348 From shaojun wang ByteDance -------------- next part -------------- An HTML attachment was scrubbed... URL: From aboldtch at openjdk.org Tue Jan 27 08:26:21 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 27 Jan 2026 08:26:21 GMT Subject: RFR: 8374686: ZGC: Convert zMarkTerminate to use Atomic [v3] In-Reply-To: <5QEVviODr8X9ahpUTb3XDJXLRolS-6vrBQBK5mvsNRI=.dd403b39-8a39-4ed2-be21-efa61f2b2832@github.com> References: <5QEVviODr8X9ahpUTb3XDJXLRolS-6vrBQBK5mvsNRI=.dd403b39-8a39-4ed2-be21-efa61f2b2832@github.com> Message-ID: On Thu, 15 Jan 2026 12:35:13 GMT, Axel Boldt-Christmas wrote: >> Convert usages of AtomicAccess to Atomic in zMarkTerminate. >> >> There are a few things that potentially should be changed here. >> >> First the `_nworkers` variable was accessed through the AtomicAccess API in a handful of places. In this patch I changed it to always be an Atomic. However, this variable is only ever read concurrently. It only gets modified before we schedule a task on the workers (either for a new task, or after all workers have stopped working because we are resizing the work gang size). So potentially this could just be changed to a uint with plain loads and stores. >> >> The other variables have mutual exclusion when updated, but are read concurrently without synchronisation. In this patch I changed the volatile load + sub/add + atomic relaxed store [+ volatile load] into a simple atomic relaxed add/sub [and fetch]. The main reason being that I thought the code became less verbose, easier to read and understand. >> >> Testing: >> * GHA >> * HotSpot GC tests with ZGC linux x64 and linux aarch64 > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Const the locals Thanks for the reviews. Compiled locally with latest master merged. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29246#issuecomment-3803793390 From aboldtch at openjdk.org Tue Jan 27 08:29:26 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 27 Jan 2026 08:29:26 GMT Subject: Integrated: 8374686: ZGC: Convert zMarkTerminate to use Atomic In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 06:46:10 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zMarkTerminate. > > There are a few things that potentially should be changed here. > > First the `_nworkers` variable was accessed through the AtomicAccess API in a handful of places. In this patch I changed it to always be an Atomic. However, this variable is only ever read concurrently. It only gets modified before we schedule a task on the workers (either for a new task, or after all workers have stopped working because we are resizing the work gang size). So potentially this could just be changed to a uint with plain loads and stores. > > The other variables have mutual exclusion when updated, but are read concurrently without synchronisation. In this patch I changed the volatile load + sub/add + atomic relaxed store [+ volatile load] into a simple atomic relaxed add/sub [and fetch]. The main reason being that I thought the code became less verbose, easier to read and understand. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 This pull request has now been integrated. Changeset: 5c05d6f2 Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/5c05d6f230e34cf409529d87b71f768a384ae4b4 Stats: 29 lines in 2 files changed: 1 ins; 3 del; 25 mod 8374686: ZGC: Convert zMarkTerminate to use Atomic Reviewed-by: stefank, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/29246 From aboldtch at openjdk.org Tue Jan 27 08:36:41 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 27 Jan 2026 08:36:41 GMT Subject: RFR: 8374687: ZGC: Convert zNMethodTableIteration to use Atomic In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 08:46:12 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zNMethodTableIteration. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Thanks for the reviews. Compiled locally with latest master merged. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29267#issuecomment-3803842029 From aboldtch at openjdk.org Tue Jan 27 08:39:49 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 27 Jan 2026 08:39:49 GMT Subject: Integrated: 8374687: ZGC: Convert zNMethodTableIteration to use Atomic In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 08:46:12 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zNMethodTableIteration. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 This pull request has now been integrated. Changeset: bd92c68e Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/bd92c68ef0aa7615c62626eb6baf4496b0137cad Stats: 10 lines in 2 files changed: 1 ins; 1 del; 8 mod 8374687: ZGC: Convert zNMethodTableIteration to use Atomic Reviewed-by: stefank, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/29267 From aboldtch at openjdk.org Tue Jan 27 08:45:36 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 27 Jan 2026 08:45:36 GMT Subject: RFR: 8374690: ZGC: Convert zRelocate to use Atomic In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 09:00:48 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zRelocate. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Thanks for the reviews. Compiled locally with latest master merged. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29268#issuecomment-3803868515 From aboldtch at openjdk.org Tue Jan 27 08:45:37 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 27 Jan 2026 08:45:37 GMT Subject: Integrated: 8374690: ZGC: Convert zRelocate to use Atomic In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 09:00:48 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zRelocate. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 This pull request has now been integrated. Changeset: 6fda4417 Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/6fda44172e955d4e1d181598a97902ed5b16c57b Stats: 17 lines in 2 files changed: 1 ins; 0 del; 16 mod 8374690: ZGC: Convert zRelocate to use Atomic Reviewed-by: stefank, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/29268 From aboldtch at openjdk.org Tue Jan 27 08:49:06 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 27 Jan 2026 08:49:06 GMT Subject: RFR: 8374694: ZGC: Convert zRootsIterator to use Atomic [v2] In-Reply-To: References: Message-ID: > Convert usages of AtomicAccess to Atomic in zRootsIterator. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Remove unnecessary whitespace - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8374694 - ZGC: Convert zRootsIterator to use Atomic ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29270/files - new: https://git.openjdk.org/jdk/pull/29270/files/c21b49dc..8c735e82 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29270&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29270&range=00-01 Stats: 64708 lines in 1319 files changed: 36563 ins; 13389 del; 14756 mod Patch: https://git.openjdk.org/jdk/pull/29270.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29270/head:pull/29270 PR: https://git.openjdk.org/jdk/pull/29270 From aboldtch at openjdk.org Tue Jan 27 09:08:02 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 27 Jan 2026 09:08:02 GMT Subject: RFR: 8374692: ZGC: Convert zRemembered to use Atomic In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 09:20:02 GMT, Stefan Karlsson wrote: >> Convert usages of AtomicAccess to Atomic in zRemembered. >> >> Testing: >> * GHA >> * HotSpot GC tests with ZGC linux x64 and linux aarch64 > > src/hotspot/share/gc/z/zRemembered.cpp line 419: > >> 417: } >> 418: >> 419: const BitMap::idx_t res = _claimed.compare_exchange(prev, page_index + 1, memory_order_relaxed); > > If this were changed to `compare_set` then we could get rid of the `res` local. And move `BitMap::idx_t prev = _claimed.load_relaxed();` inside the loop and make it `const`? I think that would be fine, in most of our CAS loops we use that pattern of reading the prev value twice, rather than use the value read by the CAS. It is already a bit strange that we reload the _claimed value when finding the next bit. Rather than just read it once. And also why are we using a CAS to set the terminal state. I wonder if we could write this loops as follows: ```C++ for (;;) { const BitMap::idx_t prev = _claimed.load_relaxed(); if (prev == _bm->size()) { // Terminal state return false; } const BitMap::idx_t page_index = _bm->find_first_set_bit(prev); if (page_index == _bm->size()) { // No more bit, set terminal state _claimed.store_relaxed(page_index); return false; } if (!_claimed.compare_set(prev, page_index + 1, memory_order_relaxed)) { // Interference, retry continue; } // Found bit - look around for page or forwarding to scan ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29269#discussion_r2730981068 From iwalulya at openjdk.org Tue Jan 27 09:16:27 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 27 Jan 2026 09:16:27 GMT Subject: RFR: 8376351: Parallel: Convert ParallelScavengeHeap to use Atomic In-Reply-To: References: Message-ID: <4RbLpvRH92c9rYYGCyzuc7cR3MlJFrd7rFpYpWZQffI=.26fa4e4b-7343-4aa1-a8aa-7db5806f2016@github.com> On Mon, 26 Jan 2026 16:28:45 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to use `Atomic` in `ParallelScavengeHeap`. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29424#pullrequestreview-3710021040 From iwalulya at openjdk.org Tue Jan 27 09:23:04 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 27 Jan 2026 09:23:04 GMT Subject: RFR: 8376356: Parallel: Convert PSCardTable to use Atomic In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 17:21:13 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to convert `PSCardTable` to use `Atomic`. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29428#pullrequestreview-3710045301 From iwalulya at openjdk.org Tue Jan 27 09:28:28 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 27 Jan 2026 09:28:28 GMT Subject: RFR: 8376191: Remove AtomicAccess include from files that do not use it in gc/shared [v2] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 13:59:44 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this trivial change to remove the `AtomicAccess.hpp` include to files that do not use anything from that file. >> >> Testing: gha, local compilation with disabled precompiled headers on linux-aarch64 >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - * stefank review > - Merge branch 'master' into 8376191-remove-atomicaccess-shared > - 8376191 > > Hi all, > > please review this trivial change to remove the `AtomicAccess.hpp` include to files that do not use anything from that file. > > Testing: gha, local compilation with disabled precompiled headers on linux-aarch64 > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29384#pullrequestreview-3710069301 From aboldtch at openjdk.org Tue Jan 27 10:26:02 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 27 Jan 2026 10:26:02 GMT Subject: RFR: 8374695: ZGC: Convert zTLABUsage to use Atomic [v2] In-Reply-To: References: Message-ID: <960TmCcSTXzvLwLAje160ZpfthawRIdzEzGG-TXquYM=.d5986538-763c-46d8-b89d-db103c80fdf7@github.com> On Mon, 19 Jan 2026 06:20:09 GMT, Axel Boldt-Christmas wrote: >> Convert usages of AtomicAccess to Atomic in zTLABUsage. >> >> Testing: >> * GHA >> * HotSpot GC tests with ZGC linux x64 and linux aarch64 > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Remove superfluous space Thanks for the reviews. Compiled locally with latest master merged. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29271#issuecomment-3804337176 From aboldtch at openjdk.org Tue Jan 27 10:29:58 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 27 Jan 2026 10:29:58 GMT Subject: Integrated: 8374695: ZGC: Convert zTLABUsage to use Atomic In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 09:11:09 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zTLABUsage. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 This pull request has now been integrated. Changeset: b1aea552 Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/b1aea5520592e835e33762e349615fe616576103 Stats: 10 lines in 2 files changed: 1 ins; 1 del; 8 mod 8374695: ZGC: Convert zTLABUsage to use Atomic Reviewed-by: stefank, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/29271 From aboldtch at openjdk.org Tue Jan 27 11:03:17 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 27 Jan 2026 11:03:17 GMT Subject: RFR: 8374685: ZGC: Convert zMarkStack to use Atomic Message-ID: Convert usages of AtomicAccess to Atomic in zMarkStack. I kept the old `compare_exchange` instead of doing a `compare_set` followed by a reload. We could probably support either. We would need to be careful in the `pop` loop, not sure if we gain much in readability from that change. Testing: * GHA * HotSpot GC tests with ZGC linux x64 and linux aarch64 ------------- Commit messages: - Use compare_set - ZGC: Convert zMarkStack to use Atomic Changes: https://git.openjdk.org/jdk/pull/29446/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29446&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374685 Stats: 37 lines in 5 files changed: 2 ins; 2 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/29446.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29446/head:pull/29446 PR: https://git.openjdk.org/jdk/pull/29446 From stefank at openjdk.org Tue Jan 27 11:09:37 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 27 Jan 2026 11:09:37 GMT Subject: RFR: 8374685: ZGC: Convert zMarkStack to use Atomic In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 10:56:16 GMT, Axel Boldt-Christmas wrote: > Convert usages of AtomicAccess to Atomic in zMarkStack. > > I kept the old `compare_exchange` instead of doing a `compare_set` followed by a reload. We could probably support either. We would need to be careful in the `pop` loop, not sure if we gain much in readability from that change. > > Testing: > * GHA > * HotSpot GC tests with ZGC linux x64 and linux aarch64 Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29446#pullrequestreview-3710551798 From stefank at openjdk.org Tue Jan 27 11:12:51 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 27 Jan 2026 11:12:51 GMT Subject: RFR: 8376191: Remove AtomicAccess include from files that do not use it in gc/shared [v2] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 13:59:44 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this trivial change to remove the `AtomicAccess.hpp` include to files that do not use anything from that file. >> >> Testing: gha, local compilation with disabled precompiled headers on linux-aarch64 >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - * stefank review > - Merge branch 'master' into 8376191-remove-atomicaccess-shared > - 8376191 > > Hi all, > > please review this trivial change to remove the `AtomicAccess.hpp` include to files that do not use anything from that file. > > Testing: gha, local compilation with disabled precompiled headers on linux-aarch64 > > Thanks, > Thomas Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29384#pullrequestreview-3710562167 From stefank at openjdk.org Tue Jan 27 12:30:21 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 27 Jan 2026 12:30:21 GMT Subject: RFR: 8376350: Convert ReferenceProcessorPhaseTimes to use Atomic In-Reply-To: <2wZjpooawLKkrLsy4Z1MHU2dv8DeF8oxWMLqsCD8KXE=.2a356189-9302-4c17-88ab-b7a7b3e5e1cb@github.com> References: <2wZjpooawLKkrLsy4Z1MHU2dv8DeF8oxWMLqsCD8KXE=.2a356189-9302-4c17-88ab-b7a7b3e5e1cb@github.com> Message-ID: On Mon, 26 Jan 2026 15:52:10 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to convert `ReferenceProcessorPhaseTimes` to use `Atomic`. > > Testing: gha > > Thanks, > Thomas Changes requested by stefank (Reviewer). src/hotspot/share/gc/shared/referenceProcessorPhaseTimes.cpp line 199: > 197: > 198: for (int i = 0; i < number_of_subclasses_of_ref; i++) { > 199: ::new (&_ref_dropped[i]) Atomic{}; I had some offline discussions with @jdksjolen and @walulyai about if we really should be using placement new to reset `Atomic`s, and if this is the correct way, should we also call the destructor on the old object? That discussion ended up with suggesting the following instead: Suggestion: _ref_dropped[i].store_relaxed(0); ------------- PR Review: https://git.openjdk.org/jdk/pull/29423#pullrequestreview-3710905054 PR Review Comment: https://git.openjdk.org/jdk/pull/29423#discussion_r2731775781 From stefank at openjdk.org Tue Jan 27 12:37:18 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 27 Jan 2026 12:37:18 GMT Subject: RFR: 8376126: G1: Convert remaining volatiles in G1ConcurrentMark to Atomic [v2] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 10:03:18 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please convert remaining volatile declarations in `G1ConcurrentMark` to use `Atomic`. These volatiles are used to indicate concurrent phased access (like changing the variable in thread A, then reading the variable in thread B while A is dormant, or only ever updating it in one direction) where concurrency safety is provided by barriers between these phases. But there are also other cases) >> >> The exception is `G1ConcurrentMark::_finger` that has apparently been overlooked in an earlier changes. >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * reviews Changes requested by stefank (Reviewer). src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 581: > 579: uint max_num_regions = _g1h->max_num_regions(); > 580: for (uint i = 0; i < max_num_regions; i++) { > 581: ::new (&_top_at_rebuild_starts[i]) Atomic{}; I added a comment about a similar usage of placement new here: https://github.com/openjdk/jdk/pull/29423#discussion_r2731775781 Could you please take a look at that suggestion and if you agree with it also make that change here? ------------- PR Review: https://git.openjdk.org/jdk/pull/29368#pullrequestreview-3710929608 PR Review Comment: https://git.openjdk.org/jdk/pull/29368#discussion_r2731795259 From tschatzl at openjdk.org Tue Jan 27 12:52:20 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 27 Jan 2026 12:52:20 GMT Subject: RFR: 8376335: Convert PreservedMarks classes to use Atomic Message-ID: Hi all, please review this change to make the `PreservedMarks` classes use `Atomic`. Some refactoring allowed removal of a now unnecessary function, and imo improved the code, avoiding the somewhat awkward passing of the atomic variable. Testing: gha, tier1-5 Thanks, Thomas ------------- Commit messages: - 8376335 Changes: https://git.openjdk.org/jdk/pull/29422/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29422&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376335 Stats: 29 lines in 2 files changed: 8 ins; 11 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/29422.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29422/head:pull/29422 PR: https://git.openjdk.org/jdk/pull/29422 From tschatzl at openjdk.org Tue Jan 27 12:52:20 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 27 Jan 2026 12:52:20 GMT Subject: RFR: 8376335: Convert PreservedMarks classes to use Atomic In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 15:15:23 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to make the `PreservedMarks` classes use `Atomic`. > > Some refactoring allowed removal of a now unnecessary function, and imo improved the code, avoiding the somewhat awkward passing of the atomic variable. > > Testing: gha, tier1-5 > > Thanks, > Thomas The GHA windows failures are very very strange and have nothing to do with this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29422#issuecomment-3805045910 From tschatzl at openjdk.org Tue Jan 27 12:54:36 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 27 Jan 2026 12:54:36 GMT Subject: RFR: 8376191: Remove AtomicAccess include from files that do not use it in gc/shared [v2] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 11:10:05 GMT, Stefan Karlsson 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. The pull request contains three additional commits since the last revision: >> >> - * stefank review >> - Merge branch 'master' into 8376191-remove-atomicaccess-shared >> - 8376191 >> >> Hi all, >> >> please review this trivial change to remove the `AtomicAccess.hpp` include to files that do not use anything from that file. >> >> Testing: gha, local compilation with disabled precompiled headers on linux-aarch64 >> >> Thanks, >> Thomas > > Marked as reviewed by stefank (Reviewer). Thanks @stefank @walulyai for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/29384#issuecomment-3805050760 From tschatzl at openjdk.org Tue Jan 27 12:54:37 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 27 Jan 2026 12:54:37 GMT Subject: Integrated: 8376191: Remove AtomicAccess include from files that do not use it in gc/shared In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 12:00:48 GMT, Thomas Schatzl wrote: > Hi all, > > please review this trivial change to remove the `AtomicAccess.hpp` include to files that do not use anything from that file. > > Testing: gha, local compilation with disabled precompiled headers on linux-aarch64 > > Thanks, > Thomas This pull request has now been integrated. Changeset: 40d1b642 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/40d1b642a43fbc5c6ad21417f2f9d62d99db0201 Stats: 6 lines in 6 files changed: 0 ins; 6 del; 0 mod 8376191: Remove AtomicAccess include from files that do not use it in gc/shared Reviewed-by: iwalulya, stefank ------------- PR: https://git.openjdk.org/jdk/pull/29384 From tschatzl at openjdk.org Tue Jan 27 12:55:33 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 27 Jan 2026 12:55:33 GMT Subject: RFR: 8376350: Convert ReferenceProcessorPhaseTimes to use Atomic In-Reply-To: References: <2wZjpooawLKkrLsy4Z1MHU2dv8DeF8oxWMLqsCD8KXE=.2a356189-9302-4c17-88ab-b7a7b3e5e1cb@github.com> Message-ID: On Tue, 27 Jan 2026 12:26:59 GMT, Stefan Karlsson wrote: >> Hi all, >> >> please review this change to convert `ReferenceProcessorPhaseTimes` to use `Atomic`. >> >> Testing: gha >> >> Thanks, >> Thomas > > src/hotspot/share/gc/shared/referenceProcessorPhaseTimes.cpp line 199: > >> 197: >> 198: for (int i = 0; i < number_of_subclasses_of_ref; i++) { >> 199: ::new (&_ref_dropped[i]) Atomic{}; > > I had some offline discussions with @jdksjolen and @walulyai about if we really should be using placement new to reset `Atomic`s, and if this is the correct way, should we also call the destructor on the old object? > > That discussion ended up with suggesting the following instead: > Suggestion: > > _ref_dropped[i].store_relaxed(0); Last time Kim noted that since this (and that other) store would be initialization, and the first time this occurs this would be (technically) undefined behavior. I am good either way. It may be that last time it had been a more complex data structure than a size_t. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29423#discussion_r2731871581 From stefank at openjdk.org Tue Jan 27 12:59:52 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 27 Jan 2026 12:59:52 GMT Subject: RFR: 8376335: Convert PreservedMarks classes to use Atomic In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 15:15:23 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to make the `PreservedMarks` classes use `Atomic`. > > Some refactoring allowed removal of a now unnecessary function, and imo improved the code, avoiding the somewhat awkward passing of the atomic variable. > > Testing: gha, tier1-5 > > Thanks, > Thomas src/hotspot/share/gc/shared/preservedMarks.cpp line 36: > 34: > 35: size_t PreservedMarks::restore() { > 36: size_t result = size(); It seems to me that this is something the caller should do instead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29422#discussion_r2731887927 From aboldtch at openjdk.org Tue Jan 27 13:30:52 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 27 Jan 2026 13:30:52 GMT Subject: RFR: 8374688: ZGC: Convert zObjectAllocator to use Atomic Message-ID: <8eWbG4-2kj2c0Vz9qzQwu2_xD3NdepzQ9ZFqyD66fOQ=.7eba85ad-836d-4dda-a5e9-f57b7949cb00@github.com> Convert usages of AtomicAccess to Atomic in zObjectAllocator. Atomic are not copy constructible so `retire_pages` does relaxed stores rather than a copy constructor (the previous version did plain stores). The compiler should have to emit similar instructions for these two versions. But will run some extra verification and check that the change is not noticeable in the pause times. Testing: * GHA * HotSpot GC tests with ZGC linux x64 and linux aarch64 ------------- Commit messages: - ZGC: Convert zObjectAllocator to use Atomic Changes: https://git.openjdk.org/jdk/pull/29447/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29447&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374688 Stats: 31 lines in 2 files changed: 4 ins; 0 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/29447.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29447/head:pull/29447 PR: https://git.openjdk.org/jdk/pull/29447 From tschatzl at openjdk.org Tue Jan 27 14:04:53 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 27 Jan 2026 14:04:53 GMT Subject: RFR: 8376350: Convert ReferenceProcessorPhaseTimes to use Atomic [v2] In-Reply-To: <2wZjpooawLKkrLsy4Z1MHU2dv8DeF8oxWMLqsCD8KXE=.2a356189-9302-4c17-88ab-b7a7b3e5e1cb@github.com> References: <2wZjpooawLKkrLsy4Z1MHU2dv8DeF8oxWMLqsCD8KXE=.2a356189-9302-4c17-88ab-b7a7b3e5e1cb@github.com> Message-ID: <81OYYiIaCB895cWxMOcnvAvJqm48lrE_Ip1aLfOZuQA=.6f7564ad-dcc8-45bf-be21-76f4dcfe9f70@github.com> > Hi all, > > please review this change to convert `ReferenceProcessorPhaseTimes` to use `Atomic`. > > Testing: gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision: - Apply suggestion from @tschatzl - Update src/hotspot/share/gc/shared/referenceProcessorPhaseTimes.cpp Co-authored-by: Stefan Karlsson ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29423/files - new: https://git.openjdk.org/jdk/pull/29423/files/97b28c38..511204d2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29423&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29423&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29423.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29423/head:pull/29423 PR: https://git.openjdk.org/jdk/pull/29423 From tschatzl at openjdk.org Tue Jan 27 14:04:55 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 27 Jan 2026 14:04:55 GMT Subject: RFR: 8376350: Convert ReferenceProcessorPhaseTimes to use Atomic [v2] In-Reply-To: <81OYYiIaCB895cWxMOcnvAvJqm48lrE_Ip1aLfOZuQA=.6f7564ad-dcc8-45bf-be21-76f4dcfe9f70@github.com> References: <2wZjpooawLKkrLsy4Z1MHU2dv8DeF8oxWMLqsCD8KXE=.2a356189-9302-4c17-88ab-b7a7b3e5e1cb@github.com> <81OYYiIaCB895cWxMOcnvAvJqm48lrE_Ip1aLfOZuQA=.6f7564ad-dcc8-45bf-be21-76f4dcfe9f70@github.com> Message-ID: On Tue, 27 Jan 2026 14:01:57 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change to convert `ReferenceProcessorPhaseTimes` to use `Atomic`. >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision: > > - Apply suggestion from @tschatzl > - Update src/hotspot/share/gc/shared/referenceProcessorPhaseTimes.cpp > > Co-authored-by: Stefan Karlsson src/hotspot/share/gc/shared/referenceProcessorPhaseTimes.cpp line 25: > 23: */ > 24: > 25: #include "cppstdlib/new.hpp" Suggestion: ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29423#discussion_r2732148847 From stefank at openjdk.org Tue Jan 27 14:16:02 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 27 Jan 2026 14:16:02 GMT Subject: RFR: 8376126: G1: Convert remaining volatiles in G1ConcurrentMark to Atomic [v2] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 12:32:14 GMT, Stefan Karlsson wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * reviews > > src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 581: > >> 579: uint max_num_regions = _g1h->max_num_regions(); >> 580: for (uint i = 0; i < max_num_regions; i++) { >> 581: ::new (&_top_at_rebuild_starts[i]) Atomic{}; > > I added a comment about a similar usage of placement new here: > https://github.com/openjdk/jdk/pull/29423#discussion_r2731775781 > > Could you please take a look at that suggestion and if you agree with it also make that change here? Thomas pointed out that this was also acting as the initialization for these elements. I wonder if it wouldn't be nicer to separate this and have proper initialization in the constructor and let the reset function only reset the values? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29368#discussion_r2732208197 From stefank at openjdk.org Tue Jan 27 14:27:09 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 27 Jan 2026 14:27:09 GMT Subject: RFR: 8376126: G1: Convert remaining volatiles in G1ConcurrentMark to Atomic [v2] In-Reply-To: References: Message-ID: <6vntgVB9OD4mj43gmLKDCcEeK9xwmKDoVnd3T5JR1Zc=.2242bc04-5260-44f7-ae60-fc3c7933b7c7@github.com> On Mon, 26 Jan 2026 10:03:18 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please convert remaining volatile declarations in `G1ConcurrentMark` to use `Atomic`. These volatiles are used to indicate concurrent phased access (like changing the variable in thread A, then reading the variable in thread B while A is dormant, or only ever updating it in one direction) where concurrency safety is provided by barriers between these phases. But there are also other cases) >> >> The exception is `G1ConcurrentMark::_finger` that has apparently been overlooked in an earlier changes. >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * reviews Clearing "Request changes" Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29368#pullrequestreview-3711503253 PR Review: https://git.openjdk.org/jdk/pull/29368#pullrequestreview-3711506378 From stuefe at openjdk.org Tue Jan 27 16:44:59 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 27 Jan 2026 16:44:59 GMT Subject: RFR: 8372566: Genshen: crash at ShenandoahScanRemembered::process_clusters after JDK-8371667 [v2] In-Reply-To: References: <9K39uUxWtW6O-UsFRqrUXttqHu1K29lVAYNHcFMTaoc=.ab3856ff-55ff-4a23-ab33-870c9713e6ab@github.com> <6Y104R2wl_Z1TSFnYaYXRQdOzZGCCxXigrwBK8RM_r4=.265e3f37-88ff-4189-865b-8c17b6b8317a@github.com> Message-ID: On Mon, 1 Dec 2025 18:28:34 GMT, Xiaolong Peng wrote: >> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Use member function is_lab_alloc() instead of test the value of type() > > Thanks all for the reviews! Hi, @pengxiaolong , I have user error reports for JDK 25. Cannot reproduce them myself, but they have in common - Lilliput + GenShen - SIGSEGV during marking phase - disassembly seems to indicate we crash when trying in Klass::is_array_klass(). Crash address always in the narrow Klass decoding range. Most likely cause is reading a garbage markword from the heap, extracting a garbage narrow Klass pointer, then decoding it. The second hs-err file in your JBS issue (the one with the segfault) looks similar, at least for the latter point. Even though the crash was in a different GC phase. So, question: could this error happen in JDK 25? If yes, should the fix be downported? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28521#issuecomment-3806257209 From tschatzl at openjdk.org Tue Jan 27 17:53:57 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 27 Jan 2026 17:53:57 GMT Subject: RFR: 8376353: Parallel: Convert PSParallelCompact classes to use Atomic Message-ID: <-5nTZabTnBZ5xbkLyrYTPKb7qYHO5FFrnHCaWYHWGSI=.be644ab7-3373-4ab0-9549-29290a532bdb@github.com> Hi all, please review this change to convert `PSParallelCompact` to use `Atomic`. Testing: tier1-5,gha Thanks, Thomas ------------- Commit messages: - 8376353 Changes: https://git.openjdk.org/jdk/pull/29425/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29425&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376353 Stats: 51 lines in 2 files changed: 7 ins; 1 del; 43 mod Patch: https://git.openjdk.org/jdk/pull/29425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29425/head:pull/29425 PR: https://git.openjdk.org/jdk/pull/29425 From thomas.schatzl at oracle.com Tue Jan 27 18:00:04 2026 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 27 Jan 2026 19:00:04 +0100 Subject: One question about hotspot g1 heap adaptive resizing feature In-Reply-To: References: Message-ID: Hi all, On 24.01.26 08:28, shaojun wang wrote: > Hi Men Cao > > I read one openjdk bug which discuss? G1 heap adaptive resizing feature, > and I noticed that you mention one question like this: > > image.png > > and then you mentioned that you were convinced that the proposed > approach does not suffer from this issue. This is because the proposed > approach > does not rely on the total process CPU usage, and does not measure "GC > CPU overhead", i.e., a ratio of GC CPU usage over total CPU usage. > > image.png > > my question is that even with GCTimeRatio(gc time / (gc time + app > time)) , the problem will still exist if the application > fall into a very low cpu cost state. for example, gc_time = 30, > app_time=40?GCTimeRatio is: 30/(30+40)= 0.42, the g1 > heap size policy will try to extend heap size to scale down > GCTimeRatio?But actually the application doesn't care about > its performance at all under the state?because there is basically no or > merely request for the app. Do you have idea about > it? > > https://github.com/openjdk/jdk/pull/24211 jdk/pull/24211> > https://bugs.openjdk.org/browse/JDK-8359348 browse/JDK-8359348> > just to confirm your use case: - The application is doing nothing ("because there is basically no or merely [rarely?] request for [from?] the app.") - _GC_ cpu usage is high. The failure is that G1 would expand the heap due to the GCTimeRatio based heap sizing? Or keep heap size as is, at a probably too large value, compared to pre-GCTimeRatio sizing? My request is to give an example where GC cpu usage is high and there is little application activity? Considering "activity" as memory allocation activity, as GC only triggers lazily because of allocation. Thanks, Thomas From xpeng at openjdk.org Tue Jan 27 18:04:28 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 27 Jan 2026 18:04:28 GMT Subject: RFR: 8372566: Genshen: crash at ShenandoahScanRemembered::process_clusters after JDK-8371667 [v2] In-Reply-To: References: <9K39uUxWtW6O-UsFRqrUXttqHu1K29lVAYNHcFMTaoc=.ab3856ff-55ff-4a23-ab33-870c9713e6ab@github.com> <6Y104R2wl_Z1TSFnYaYXRQdOzZGCCxXigrwBK8RM_r4=.265e3f37-88ff-4189-865b-8c17b6b8317a@github.com> Message-ID: On Mon, 1 Dec 2025 18:28:34 GMT, Xiaolong Peng wrote: >> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Use member function is_lab_alloc() instead of test the value of type() > > Thanks all for the reviews! > Hi, @pengxiaolong , > > I have user error reports for JDK 25. Cannot reproduce them myself, but they have in common > > * Lilliput + GenShen > * SIGSEGV during marking phase > * disassembly seems to indicate we crash when trying in Klass::is_array_klass(). Crash address always in the narrow Klass decoding range. Most likely cause is reading a garbage markword from the heap, extracting a garbage narrow Klass pointer, then decoding it. > > The second hs-err file in your JBS issue (the one with the segfault) looks similar, at least for the latter point. Even though the crash was in a different GC phase. > > So, question: could this error happen in JDK 25? If yes, should the fix be downported? Hi @tstuefe, I believe it is a different bug in JDK25, this PR fix the bug caused by https://github.com/openjdk/jdk/pull/28247, which has not been backported to JDK25 yet. Could you share more details of the crash? the hs-err file would be great, I can try to run the test and reproduce it. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28521#issuecomment-3806666014 From lkorinth at openjdk.org Tue Jan 27 18:42:51 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 27 Jan 2026 18:42:51 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v8] In-Reply-To: References: Message-ID: > This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. > > It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. > > This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. > > I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: - Revert "Stefan J 4" This reverts commit 203d11979524126add9ee5d04174bde07a5a3f5a. - Revert "remove commented out code" This reverts commit 9d9df671574be7a15a30ef0af452629330cb4fd1. - Merge branch 'master' into _8367993 - Merge branch '_master_jdk' into _8367993 - Merge branch '_8373253' into _8367993 - rename of method - Proposal by Stefan J - wip - Revert "8373253: Re-work InjectGCWorkerCreationFailure for future changes" This reverts commit d45ea8817ab2303b2decd8cbb2cd1bf5280aa181. - Revert "Fixup after comment from Ivan." This reverts commit 2aa8aa4b68027b62a8d4be1b86720fadfa48dda5. - ... and 11 more: https://git.openjdk.org/jdk/compare/90b54692...c5a7e2bb ------------- Changes: https://git.openjdk.org/jdk/pull/28723/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28723&range=07 Stats: 56 lines in 10 files changed: 29 ins; 6 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/28723.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28723/head:pull/28723 PR: https://git.openjdk.org/jdk/pull/28723 From lkorinth at openjdk.org Tue Jan 27 18:49:50 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 27 Jan 2026 18:49:50 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v8] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 18:42:51 GMT, Leo Korinth wrote: >> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. >> >> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. >> >> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. >> >> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. > > Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: > > - Revert "Stefan J 4" > > This reverts commit 203d11979524126add9ee5d04174bde07a5a3f5a. > - Revert "remove commented out code" > > This reverts commit 9d9df671574be7a15a30ef0af452629330cb4fd1. > - Merge branch 'master' into _8367993 > - Merge branch '_master_jdk' into _8367993 > - Merge branch '_8373253' into _8367993 > - rename of method > - Proposal by Stefan J > - wip > - Revert "8373253: Re-work InjectGCWorkerCreationFailure for future changes" > > This reverts commit d45ea8817ab2303b2decd8cbb2cd1bf5280aa181. > - Revert "Fixup after comment from Ivan." > > This reverts commit 2aa8aa4b68027b62a8d4be1b86720fadfa48dda5. > - ... and 11 more: https://git.openjdk.org/jdk/compare/90b54692...c5a7e2bb I think the current state is okay, sorry for the messy history (the last two commits was pushed by mistake, now reverted). Rerunning tier 1 - 5, they are not through yet. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28723#issuecomment-3806877202 From kdnilsen at openjdk.org Tue Jan 27 19:53:24 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 27 Jan 2026 19:53:24 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v19] In-Reply-To: References: Message-ID: <83Jd95L2oafEMHL9aUCeLB4_iKEe93emHHI8k71rp_w=.1a19bafd-56e1-4010-b76e-0850f681f82d@github.com> > After studying large numbers of GC logs with degenerated cycles that have resulted from "late" triggers, we propose the following general improvements: > > 1. Track trends in GC times rather than always using the average GC time plus standard deviation. In many situations, GC times trend upward due to, for example, increasing amounts of live data that must be marked as a workload builds up its working set of memory. > 2. Sample allocation rates more frequently than once every 100 ms. > 3. Track trends in allocation rates. In some situations, the allocation rate trends upwards due to, for example, the start of a new phase of execution or a spike in client workload. > 4. When we detect acceleration of allocation rate, predict consumption of memory based on accelerated allocation rates rather than assuming constant allocation rate. Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 86 commits: - Merge remote-tracking branch 'jdk/master' into accelerated-triggers - some cosmetic improvements - Use fewer samples to detect acceleration - align log messages for trigger trace - remove problematic debug messages - More detailed instrumentation and simpler allocatable calculation - Turn on trigger trace - remove tab - Remove redundant sample for spike rate - Insert instrumentation to diagnose bad scheduling decisions - ... and 76 more: https://git.openjdk.org/jdk/compare/eb6e74b1...ca6b9625 ------------- Changes: https://git.openjdk.org/jdk/pull/29039/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=18 Stats: 1179 lines in 24 files changed: 1078 ins; 35 del; 66 mod Patch: https://git.openjdk.org/jdk/pull/29039.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29039/head:pull/29039 PR: https://git.openjdk.org/jdk/pull/29039 From kdnilsen at openjdk.org Tue Jan 27 19:56:49 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 27 Jan 2026 19:56:49 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v20] In-Reply-To: References: Message-ID: > After studying large numbers of GC logs with degenerated cycles that have resulted from "late" triggers, we propose the following general improvements: > > 1. Track trends in GC times rather than always using the average GC time plus standard deviation. In many situations, GC times trend upward due to, for example, increasing amounts of live data that must be marked as a workload builds up its working set of memory. > 2. Sample allocation rates more frequently than once every 100 ms. > 3. Track trends in allocation rates. In some situations, the allocation rate trends upwards due to, for example, the start of a new phase of execution or a spike in client workload. > 4. When we detect acceleration of allocation rate, predict consumption of memory based on accelerated allocation rates rather than assuming constant allocation rate. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: no need to set_mutator_free_after_updaterefs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29039/files - new: https://git.openjdk.org/jdk/pull/29039/files/ca6b9625..26296f5d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=18-19 Stats: 14 lines in 4 files changed: 0 ins; 8 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/29039.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29039/head:pull/29039 PR: https://git.openjdk.org/jdk/pull/29039 From xpeng at openjdk.org Tue Jan 27 22:29:22 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 27 Jan 2026 22:29:22 GMT Subject: RFR: 8376531: Genshen: Missing volatile modifier on multiple fields of ShenandoahOldGeneration Message-ID: Came across the source code of ShenandoahOldGeneration, and noticed that we use AtomicAccess to read/write to fields `_promoted_expended`, `_promotion_failure_count`, `_promotion_failure_words` but non of them is declared with volatile modifier. Given that OpenJDK has introduced `Atomic` to replace the idiom of volatile var plus AtomicAccess:: operations(see details [here](https://bugs.openjdk.org/browse/JDK-8367013), I decided to convert these fields to `Atomic` instead of adding `volatile`. ### Test - [x] hotshpot_gc_shenandoah - [ ] GHA ------------- Commit messages: - Merge branch 'openjdk:master' into JDK-8376531 - 8376531: Genshen: Missing volatile modifier on multiple fields of ShenandoahOldGeneration Changes: https://git.openjdk.org/jdk/pull/29456/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29456&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376531 Stats: 16 lines in 2 files changed: 0 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/29456.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29456/head:pull/29456 PR: https://git.openjdk.org/jdk/pull/29456 From wkemper at openjdk.org Tue Jan 27 23:38:05 2026 From: wkemper at openjdk.org (William Kemper) Date: Tue, 27 Jan 2026 23:38:05 GMT Subject: RFR: 8376531: Genshen: Missing volatile modifier on multiple fields of ShenandoahOldGeneration In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 22:19:15 GMT, Xiaolong Peng wrote: > Came across the source code of ShenandoahOldGeneration, and noticed that we use AtomicAccess to read/write to fields `_promoted_expended`, `_promotion_failure_count`, `_promotion_failure_words` but non of them is declared with volatile modifier. > > Given that OpenJDK has introduced `Atomic` to replace the idiom of volatile var plus AtomicAccess:: operations(see details [here](https://bugs.openjdk.org/browse/JDK-8367013), I decided to convert these fields to `Atomic` instead of adding `volatile`. > > ### Test > - [x] hotshpot_gc_shenandoah > - [ ] GHA Changes requested by wkemper (Reviewer). src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 585: > 583: > 584: void ShenandoahOldGeneration::handle_failed_promotion(Thread* thread, size_t size) { > 585: _promotion_failure_count.add_then_fetch(static_cast(1)); Can this be `1UL` instead of `static_cast(1)`? ------------- PR Review: https://git.openjdk.org/jdk/pull/29456#pullrequestreview-3713954434 PR Review Comment: https://git.openjdk.org/jdk/pull/29456#discussion_r2734254725 From xpeng at openjdk.org Tue Jan 27 23:43:23 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 27 Jan 2026 23:43:23 GMT Subject: RFR: 8376531: Genshen: Missing volatile modifier on multiple fields of ShenandoahOldGeneration In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 23:34:52 GMT, William Kemper wrote: >> Came across the source code of ShenandoahOldGeneration, and noticed that we use AtomicAccess to read/write to fields `_promoted_expended`, `_promotion_failure_count`, `_promotion_failure_words` but non of them is declared with volatile modifier. >> >> Given that OpenJDK has introduced `Atomic` to replace the idiom of volatile var plus AtomicAccess:: operations(see details [here](https://bugs.openjdk.org/browse/JDK-8367013), I decided to convert these fields to `Atomic` instead of adding `volatile`. >> >> ### Test >> - [x] hotshpot_gc_shenandoah >> - [ ] GHA > > src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 585: > >> 583: >> 584: void ShenandoahOldGeneration::handle_failed_promotion(Thread* thread, size_t size) { >> 585: _promotion_failure_count.add_then_fetch(static_cast(1)); > > Can this be `1UL` instead of `static_cast(1)`? Thanks, it should work, at least CLION doesn't complain. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29456#discussion_r2734266721 From xpeng at openjdk.org Tue Jan 27 23:49:18 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 27 Jan 2026 23:49:18 GMT Subject: RFR: 8376531: Genshen: Missing volatile modifier on multiple fields of ShenandoahOldGeneration [v2] In-Reply-To: References: Message-ID: > Came across the source code of ShenandoahOldGeneration, and noticed that we use AtomicAccess to read/write to fields `_promoted_expended`, `_promotion_failure_count`, `_promotion_failure_words` but non of them is declared with volatile modifier. > > Given that OpenJDK has introduced `Atomic` to replace the idiom of volatile var plus AtomicAccess:: operations(see details [here](https://bugs.openjdk.org/browse/JDK-8367013), I decided to convert these fields to `Atomic` instead of adding `volatile`. > > ### Test > - [x] hotshpot_gc_shenandoah > - [ ] GHA Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Use `1UL` instead of `static_cast(1)` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29456/files - new: https://git.openjdk.org/jdk/pull/29456/files/e6087ad1..76675c54 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29456&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29456&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29456.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29456/head:pull/29456 PR: https://git.openjdk.org/jdk/pull/29456 From xpeng at openjdk.org Wed Jan 28 00:34:44 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 28 Jan 2026 00:34:44 GMT Subject: RFR: 8376531: Genshen: Missing volatile modifier on multiple fields of ShenandoahOldGeneration [v2] In-Reply-To: References: Message-ID: <9JhRtxfB8OuVYfxiXEhnQrY3FmSlL559MbIAHxfoegs=.e25b6858-50f6-46ed-abd9-91727a818a27@github.com> On Tue, 27 Jan 2026 23:41:05 GMT, Xiaolong Peng wrote: >> src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 585: >> >>> 583: >>> 584: void ShenandoahOldGeneration::handle_failed_promotion(Thread* thread, size_t size) { >>> 585: _promotion_failure_count.add_then_fetch(static_cast(1)); >> >> Can this be `1UL` instead of `static_cast(1)`? > > Thanks, it should work, at least CLION doesn't complain. `1UL` is working fine, I have updated the code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29456#discussion_r2734363277 From ghan at openjdk.org Wed Jan 28 07:30:20 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Wed, 28 Jan 2026 07:30:20 GMT Subject: RFR: 8376491: ZGC: crash in __memset_evex_unaligned_erms when initializing heap using high values for -XX:ConcGCThreads Message-ID: Please review this change. Thanks! **Description:** This change fixes a crash during ZGC initialization when -XX:ConcGCThreads is set to an extremely large value. ZThreadLocalAllocBuffer::initialize() creates a ZPerWorker, which uses ZValueStorage::alloc to allocate per-worker storage which size is related to ConcGCThreads https://github.com/openjdk/jdk/blob/1161a640abe454b47de95ed73452a78535160deb/src/hotspot/share/gc/z/zThreadLocalAllocBuffer.cpp#L35-L38 https://github.com/openjdk/jdk/blob/1161a640abe454b47de95ed73452a78535160deb/src/hotspot/share/gc/z/zValue.hpp#L111 https://github.com/openjdk/jdk/blob/1161a640abe454b47de95ed73452a78535160deb/src/hotspot/share/gc/z/zValue.inline.hpp#L125-L127 https://github.com/openjdk/jdk/blob/1161a640abe454b47de95ed73452a78535160deb/src/hotspot/share/gc/z/zValue.inline.hpp#L60-L61 https://github.com/openjdk/jdk/blob/1161a640abe454b47de95ed73452a78535160deb/src/hotspot/share/gc/z/zValue.inline.hpp#L108-L110 For very large ConcGCThreads, the calculated block_size becomes huge and os::malloc() inside ZUtils::alloc_aligned_unfreeable() may fail. https://github.com/openjdk/jdk/blob/1161a640abe454b47de95ed73452a78535160deb/src/hotspot/share/gc/z/zUtils.inline.hpp#L37-L42 The current code does not check the returned pointer and unconditionally aligns and memset()s it, which can lead to a segmentation fault. **Fix:** The fix adds a NULL check after os::malloc() and terminates the VM with a proper OutOfMemoryError message instead of crashing. **Test:** GHA ------------- Commit messages: - fix test func - fix bug 8376491 Changes: https://git.openjdk.org/jdk/pull/29460/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29460&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376491 Stats: 50 lines in 2 files changed: 49 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29460.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29460/head:pull/29460 PR: https://git.openjdk.org/jdk/pull/29460 From shade at openjdk.org Wed Jan 28 08:13:24 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 28 Jan 2026 08:13:24 GMT Subject: RFR: 8376531: Genshen: Missing volatile modifier on multiple fields of ShenandoahOldGeneration [v2] In-Reply-To: References: Message-ID: <8t3StQRKmKczkS2fcA6q0YqGSVD7PHHbW43arjS4b7U=.bdd34e09-a707-4d63-88a7-267ed4d6ae40@github.com> On Tue, 27 Jan 2026 23:49:18 GMT, Xiaolong Peng wrote: >> Came across the source code of ShenandoahOldGeneration, and noticed that we use AtomicAccess to read/write to fields `_promoted_expended`, `_promotion_failure_count`, `_promotion_failure_words` but non of them is declared with volatile modifier. >> >> Given that OpenJDK has introduced `Atomic` to replace the idiom of volatile var plus AtomicAccess:: operations(see details [here](https://bugs.openjdk.org/browse/JDK-8367013), I decided to convert these fields to `Atomic` instead of adding `volatile`. >> >> ### Test >> - [x] hotshpot_gc_shenandoah >> - [x] GHA > > Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: > > Use `1UL` instead of `static_cast(1)` OK, so this sounds like the usual `Convert ShenandoahOldGeneration to Atomic` issue type that have been flying around. Consider renaming it, and maybe work on other places too, in separate PRs? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29456#issuecomment-3809668808 From shade at openjdk.org Wed Jan 28 08:16:38 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 28 Jan 2026 08:16:38 GMT Subject: RFR: 8376531: Genshen: Missing volatile modifier on multiple fields of ShenandoahOldGeneration [v2] In-Reply-To: References: Message-ID: <4oz_z4eDy1cLyjnDPwN1B4Bjhz8PbKbiknBgHsntdj8=.ab8b02cf-2fb4-4cd0-85a8-b0c6fe9cff2f@github.com> On Tue, 27 Jan 2026 23:49:18 GMT, Xiaolong Peng wrote: >> Came across the source code of ShenandoahOldGeneration, and noticed that we use AtomicAccess to read/write to fields `_promoted_expended`, `_promotion_failure_count`, `_promotion_failure_words` but non of them is declared with volatile modifier. >> >> Given that OpenJDK has introduced `Atomic` to replace the idiom of volatile var plus AtomicAccess:: operations(see details [here](https://bugs.openjdk.org/browse/JDK-8367013), I decided to convert these fields to `Atomic` instead of adding `volatile`. >> >> ### Test >> - [x] hotshpot_gc_shenandoah >> - [x] GHA > > Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: > > Use `1UL` instead of `static_cast(1)` Otherwise looks okay. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29456#pullrequestreview-3715178408 From sjohanss at openjdk.org Wed Jan 28 11:06:29 2026 From: sjohanss at openjdk.org (Stefan Johansson) Date: Wed, 28 Jan 2026 11:06:29 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v8] In-Reply-To: References: Message-ID: <1yNQc7QkIDbQ7WvVCHICL4dDN036pPD373wE3H200R4=.43d38367-6988-4531-829f-349d206250f8@github.com> On Tue, 27 Jan 2026 18:42:51 GMT, Leo Korinth wrote: >> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. >> >> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. >> >> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. >> >> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. > > Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: > > - Revert "Stefan J 4" > > This reverts commit 203d11979524126add9ee5d04174bde07a5a3f5a. > - Revert "remove commented out code" > > This reverts commit 9d9df671574be7a15a30ef0af452629330cb4fd1. > - Merge branch 'master' into _8367993 > - Merge branch '_master_jdk' into _8367993 > - Merge branch '_8373253' into _8367993 > - rename of method > - Proposal by Stefan J > - wip > - Revert "8373253: Re-work InjectGCWorkerCreationFailure for future changes" > > This reverts commit d45ea8817ab2303b2decd8cbb2cd1bf5280aa181. > - Revert "Fixup after comment from Ivan." > > This reverts commit 2aa8aa4b68027b62a8d4be1b86720fadfa48dda5. > - ... and 11 more: https://git.openjdk.org/jdk/compare/90b54692...c5a7e2bb Changes requested by sjohanss (Reviewer). src/hotspot/share/gc/g1/g1YoungCollector.cpp line 1128: > 1126: > 1127: void G1YoungCollector::collect() { > 1128: _g1h->_cm->fully_initialize(); Why did you revert the call to this location? Instead of having it in G1CollectedHeap::do_collection_pause_at_safepoint()? ------------- PR Review: https://git.openjdk.org/jdk/pull/28723#pullrequestreview-3716074772 PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2736113065 From tschatzl at openjdk.org Wed Jan 28 11:35:51 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 28 Jan 2026 11:35:51 GMT Subject: RFR: 8376126: G1: Convert remaining volatiles in G1ConcurrentMark to Atomic [v3] In-Reply-To: References: Message-ID: > Hi all, > > please convert remaining volatile declarations in `G1ConcurrentMark` to use `Atomic`. These volatiles are used to indicate concurrent phased access (like changing the variable in thread A, then reading the variable in thread B while A is dormant, or only ever updating it in one direction) where concurrency safety is provided by barriers between these phases. But there are also other cases) > > The exception is `G1ConcurrentMark::_finger` that has apparently been overlooked in an earlier changes. > > Testing: gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * separate initialization and reset for _top_at_rebuild_starts * add initialization for _top_at_mark_starts, _region_mark_stats ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29368/files - new: https://git.openjdk.org/jdk/pull/29368/files/d7126996..d10ecb18 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29368&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29368&range=01-02 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29368.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29368/head:pull/29368 PR: https://git.openjdk.org/jdk/pull/29368 From tschatzl at openjdk.org Wed Jan 28 11:50:29 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 28 Jan 2026 11:50:29 GMT Subject: RFR: 8376335: Convert PreservedMarks classes to use Atomic [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review this change to make the `PreservedMarks` classes use `Atomic`. > > Some refactoring allowed removal of a now unnecessary function, and imo improved the code, avoiding the somewhat awkward passing of the atomic variable. > > Testing: gha, tier1-5 > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision: - * improve docs - * stefank review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29422/files - new: https://git.openjdk.org/jdk/pull/29422/files/a811bc09..226cd455 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29422&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29422&range=00-01 Stats: 10 lines in 2 files changed: 2 ins; 4 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29422.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29422/head:pull/29422 PR: https://git.openjdk.org/jdk/pull/29422 From stefank at openjdk.org Wed Jan 28 12:27:53 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 28 Jan 2026 12:27:53 GMT Subject: RFR: 8376335: Convert PreservedMarks classes to use Atomic [v2] In-Reply-To: References: Message-ID: <4JPk4zpgtxrTE92DVAazbhbOl4fNsBoKAYsMt1W58Ao=.4b23b7ef-4ee4-4601-8592-d6a50d34eaad@github.com> On Wed, 28 Jan 2026 11:50:29 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change to make the `PreservedMarks` classes use `Atomic`. >> >> Some refactoring allowed removal of a now unnecessary function, and imo improved the code, avoiding the somewhat awkward passing of the atomic variable. >> >> Testing: gha, tier1-5 >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision: > > - * improve docs > - * stefank review Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29422#pullrequestreview-3716439969 From stefank at openjdk.org Wed Jan 28 12:29:05 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 28 Jan 2026 12:29:05 GMT Subject: RFR: 8376350: Convert ReferenceProcessorPhaseTimes to use Atomic [v2] In-Reply-To: <81OYYiIaCB895cWxMOcnvAvJqm48lrE_Ip1aLfOZuQA=.6f7564ad-dcc8-45bf-be21-76f4dcfe9f70@github.com> References: <2wZjpooawLKkrLsy4Z1MHU2dv8DeF8oxWMLqsCD8KXE=.2a356189-9302-4c17-88ab-b7a7b3e5e1cb@github.com> <81OYYiIaCB895cWxMOcnvAvJqm48lrE_Ip1aLfOZuQA=.6f7564ad-dcc8-45bf-be21-76f4dcfe9f70@github.com> Message-ID: On Tue, 27 Jan 2026 14:04:53 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change to convert `ReferenceProcessorPhaseTimes` to use `Atomic`. >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision: > > - Apply suggestion from @tschatzl > - Update src/hotspot/share/gc/shared/referenceProcessorPhaseTimes.cpp > > Co-authored-by: Stefan Karlsson Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29423#pullrequestreview-3716443001 From erik.osterlund at oracle.com Wed Jan 28 12:41:46 2026 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Wed, 28 Jan 2026 12:41:46 +0000 Subject: One question about hotspot g1 heap adaptive resizing feature In-Reply-To: References: Message-ID: Hi Thomas, If I understand the conversation, what is referred to is something like this in ZGC style AHS: https://github.com/openjdk/zgc/blob/c87666fbda432c9c9d19d6871859b8c195476f6c/src/hotspot/share/gc/z/zAdaptiveHeap.cpp#L505 and: https://github.com/openjdk/zgc/blob/c87666fbda432c9c9d19d6871859b8c195476f6c/src/hotspot/share/gc/z/zAdaptiveHeap.cpp#L515 The reasoning here is that if you have a process that utilizes 1% of the machine CPU resources but 50% of the memory resources, you might not want to bloat memory with lots of garbage to reduce fraction of that 1% that is spent of GC. In that situation, having a 100% CPU overhead so that the JVM uses 2% of the overall machine CPU, while saving a huge amount of the available RAM, is preferable. In other words, the CPU overhead target depends on the resource balance of unused machine resources, as well as a resource balance of the process used resources. In terms of use cases, containers without resource constraints or partial resource constraints, is one application. Multi process situations would be another one. /Erik On 27 Jan 2026, at 19:00, Thomas Schatzl wrote: Hi all, On 24.01.26 08:28, shaojun wang wrote: Hi Men Cao I read one openjdk bug which discuss G1 heap adaptive resizing feature, and I noticed that you mention one question like this: image.png and then you mentioned that you were convinced that the proposed approach does not suffer from this issue. This is because the proposed approach does not rely on the total process CPU usage, and does not measure "GC CPU overhead", i.e., a ratio of GC CPU usage over total CPU usage. image.png my question is that even with GCTimeRatio(gc time / (gc time + app time)) , the problem will still exist if the application fall into a very low cpu cost state. for example, gc_time = 30, app_time=40?GCTimeRatio is: 30/(30+40)= 0.42, the g1 heap size policy will try to extend heap size to scale down GCTimeRatio?But actually the application doesn't care about its performance at all under the state?because there is basically no or merely request for the app. Do you have idea about it? https://github.com/openjdk/jdk/pull/24211 https://bugs.openjdk.org/browse/JDK-8359348 just to confirm your use case: - The application is doing nothing ("because there is basically no or merely [rarely?] request for [from?] the app.") - _GC_ cpu usage is high. The failure is that G1 would expand the heap due to the GCTimeRatio based heap sizing? Or keep heap size as is, at a probably too large value, compared to pre-GCTimeRatio sizing? My request is to give an example where GC cpu usage is high and there is little application activity? Considering "activity" as memory allocation activity, as GC only triggers lazily because of allocation. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From tschatzl at openjdk.org Wed Jan 28 12:54:52 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 28 Jan 2026 12:54:52 GMT Subject: RFR: 8376126: G1: Convert remaining volatiles in G1ConcurrentMark to Atomic [v4] In-Reply-To: References: Message-ID: <0ksKxc3kj_pqlRLKTKLNjqVBu-f9kz7HYwaqa7-wQIs=.4cc463ce-de77-4682-807c-66cf13612748@github.com> > Hi all, > > please convert remaining volatile declarations in `G1ConcurrentMark` to use `Atomic`. These volatiles are used to indicate concurrent phased access (like changing the variable in thread A, then reading the variable in thread B while A is dormant, or only ever updating it in one direction) where concurrency safety is provided by barriers between these phases. But there are also other cases) > > The exception is `G1ConcurrentMark::_finger` that has apparently been overlooked in an earlier changes. > > Testing: gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * try to fix non-gcc build failures ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29368/files - new: https://git.openjdk.org/jdk/pull/29368/files/d10ecb18..99bd8cac Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29368&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29368&range=02-03 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29368.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29368/head:pull/29368 PR: https://git.openjdk.org/jdk/pull/29368 From iwalulya at openjdk.org Wed Jan 28 13:03:27 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 28 Jan 2026 13:03:27 GMT Subject: RFR: 8376335: Convert PreservedMarks classes to use Atomic [v2] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 11:50:29 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change to make the `PreservedMarks` classes use `Atomic`. >> >> Some refactoring allowed removal of a now unnecessary function, and imo improved the code, avoiding the somewhat awkward passing of the atomic variable. >> >> Testing: gha, tier1-5 >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision: > > - * improve docs > - * stefank review Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29422#pullrequestreview-3716581335 From iwalulya at openjdk.org Wed Jan 28 13:05:57 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 28 Jan 2026 13:05:57 GMT Subject: RFR: 8376350: Convert ReferenceProcessorPhaseTimes to use Atomic [v2] In-Reply-To: <81OYYiIaCB895cWxMOcnvAvJqm48lrE_Ip1aLfOZuQA=.6f7564ad-dcc8-45bf-be21-76f4dcfe9f70@github.com> References: <2wZjpooawLKkrLsy4Z1MHU2dv8DeF8oxWMLqsCD8KXE=.2a356189-9302-4c17-88ab-b7a7b3e5e1cb@github.com> <81OYYiIaCB895cWxMOcnvAvJqm48lrE_Ip1aLfOZuQA=.6f7564ad-dcc8-45bf-be21-76f4dcfe9f70@github.com> Message-ID: On Tue, 27 Jan 2026 14:04:53 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change to convert `ReferenceProcessorPhaseTimes` to use `Atomic`. >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision: > > - Apply suggestion from @tschatzl > - Update src/hotspot/share/gc/shared/referenceProcessorPhaseTimes.cpp > > Co-authored-by: Stefan Karlsson Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29423#pullrequestreview-3716594588 From duke at openjdk.org Wed Jan 28 16:29:05 2026 From: duke at openjdk.org (duke) Date: Wed, 28 Jan 2026 16:29:05 GMT Subject: Withdrawn: 8236073: G1: Use SoftMaxHeapSize to guide GC heuristics In-Reply-To: <8jjBh52pZlAjsLJ4ce1oacnDVdu8qCe2pJYApXsU5HM=.462adbdd-e3b7-4d4a-a130-aecadba36b00@github.com> References: <8jjBh52pZlAjsLJ4ce1oacnDVdu8qCe2pJYApXsU5HM=.462adbdd-e3b7-4d4a-a130-aecadba36b00@github.com> Message-ID: On Fri, 26 Sep 2025 11:45:52 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to implement `SoftMaxHeapSize` for G1. > > Main change is that `SoftMaxHeapSize` now impacts the `G1IHOPControl::target_occupancy()`, i.e. the amount of bytes G1 when reclaim should start. > > Most of the other changes are just about updating logging/JFR and making sure that the `SoftMaxHeapSize` values are consistent across calls. > > Testing: tier1-5 > > Thanks, > Thomas This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27524 From xpeng at openjdk.org Wed Jan 28 16:32:59 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 28 Jan 2026 16:32:59 GMT Subject: RFR: 8376531: Genshen: Missing volatile modifier on multiple fields of ShenandoahOldGeneration [v2] In-Reply-To: <8t3StQRKmKczkS2fcA6q0YqGSVD7PHHbW43arjS4b7U=.bdd34e09-a707-4d63-88a7-267ed4d6ae40@github.com> References: <8t3StQRKmKczkS2fcA6q0YqGSVD7PHHbW43arjS4b7U=.bdd34e09-a707-4d63-88a7-267ed4d6ae40@github.com> Message-ID: <1MtYnnkZ28Ejgv8LEMw9kYriXNWTrsTWbN4_Dc_c6io=.93ebf9ed-208d-4324-a8b9-837d00d04f29@github.com> On Wed, 28 Jan 2026 08:10:12 GMT, Aleksey Shipilev wrote: > OK, so this sounds like the usual `Convert ShenandoahOldGeneration to Atomic` issue type that have been flying around. Consider renaming it, and maybe work on other places too, in separate PRs? Yes, but the purpose is to fix the minor bug in ShenandoahOldGeneration(Not sure if missing volatile will cause any problem or not), I'll create JBS bug and PRs for the other places. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29456#issuecomment-3812331703 From wkemper at openjdk.org Wed Jan 28 18:06:56 2026 From: wkemper at openjdk.org (William Kemper) Date: Wed, 28 Jan 2026 18:06:56 GMT Subject: RFR: 8376531: Genshen: Missing volatile modifier on multiple fields of ShenandoahOldGeneration [v2] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 23:49:18 GMT, Xiaolong Peng wrote: >> Came across the source code of ShenandoahOldGeneration, and noticed that we use AtomicAccess to read/write to fields `_promoted_expended`, `_promotion_failure_count`, `_promotion_failure_words` but non of them is declared with volatile modifier. >> >> Given that OpenJDK has introduced `Atomic` to replace the idiom of volatile var plus AtomicAccess:: operations(see details [here](https://bugs.openjdk.org/browse/JDK-8367013), I decided to convert these fields to `Atomic` instead of adding `volatile`. >> >> ### Test >> - [x] hotshpot_gc_shenandoah >> - [x] GHA > > Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: > > Use `1UL` instead of `static_cast(1)` Is `volatile` really required for fields that are only accessed atomically? That is to say, are we actually fixing a bug here, or are we just converting `AtomicAccess` to an `Atomic` variable? Should the title of the PR reflect that as Aleksey suggests? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29456#issuecomment-3812937970 From shade at openjdk.org Wed Jan 28 18:39:17 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 28 Jan 2026 18:39:17 GMT Subject: RFR: 8376531: Genshen: Missing volatile modifier on multiple fields of ShenandoahOldGeneration [v2] In-Reply-To: References: Message-ID: <5hmla6LdfpTL566lScBoo6q7N7diX2cQd0jkP2Ig1hI=.0476df25-0b91-44e9-8291-9e968763f394@github.com> On Tue, 27 Jan 2026 23:49:18 GMT, Xiaolong Peng wrote: >> Came across the source code of ShenandoahOldGeneration, and noticed that we use AtomicAccess to read/write to fields `_promoted_expended`, `_promotion_failure_count`, `_promotion_failure_words` but non of them is declared with volatile modifier. >> >> Given that OpenJDK has introduced `Atomic` to replace the idiom of volatile var plus AtomicAccess:: operations(see details [here](https://bugs.openjdk.org/browse/JDK-8367013), I decided to convert these fields to `Atomic` instead of adding `volatile`. >> >> ### Test >> - [x] hotshpot_gc_shenandoah >> - [x] GHA > > Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: > > Use `1UL` instead of `static_cast(1)` Missing `volatile` is unlikely to cause problems, as long as all accesses are via atomics. Declaring things as `Atomic` is mostly for consistency, IMO. So yeah, this can be treated as cleanup improvement, really. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29456#issuecomment-3813116424 From wkemper at openjdk.org Wed Jan 28 18:43:59 2026 From: wkemper at openjdk.org (William Kemper) Date: Wed, 28 Jan 2026 18:43:59 GMT Subject: RFR: 8376531: Genshen: Missing volatile modifier on multiple fields of ShenandoahOldGeneration [v2] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 23:49:18 GMT, Xiaolong Peng wrote: >> Came across the source code of ShenandoahOldGeneration, and noticed that we use AtomicAccess to read/write to fields `_promoted_expended`, `_promotion_failure_count`, `_promotion_failure_words` but non of them is declared with volatile modifier. >> >> Given that OpenJDK has introduced `Atomic` to replace the idiom of volatile var plus AtomicAccess:: operations(see details [here](https://bugs.openjdk.org/browse/JDK-8367013), I decided to convert these fields to `Atomic` instead of adding `volatile`. >> >> ### Test >> - [x] hotshpot_gc_shenandoah >> - [x] GHA > > Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: > > Use `1UL` instead of `static_cast(1)` Approved, but let's change the PR title. ------------- Marked as reviewed by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29456#pullrequestreview-3718395735 From stefank at openjdk.org Wed Jan 28 20:28:06 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 28 Jan 2026 20:28:06 GMT Subject: RFR: 8375747: ZGC: ZForwardingTest is unable to commit memory on Windows Message-ID: <6daw9JcPvbNGfGoIgZi0cW-yA4JQ8nCTbpKjwYEbMoI=.0caaf56d-a1c0-4fb8-8b73-66175b2c267d@github.com> The ZForwardingTest gtest first reserves memory via the ZGC APIs to do so and then uses the generic `os::commit_memory(...)` to commit the memory. That is problematic on Windows because the two APIs are not compatible there. I've updated the test to use ZGC's APIs to commit and map memory instead. Thanks to @roberttoyonaga for finding this and helping out diagnosing this issue! The patch also adds some tiny fixes to the assert code that mislead me while prototyping this. I'll run this through tier1 testing. ------------- Commit messages: - Add missing constructor - Commit via ZGC infrastructure instead of os::commit Changes: https://git.openjdk.org/jdk/pull/29471/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29471&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375747 Stats: 74 lines in 3 files changed: 61 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/29471.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29471/head:pull/29471 PR: https://git.openjdk.org/jdk/pull/29471 From eosterlund at openjdk.org Wed Jan 28 20:34:51 2026 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 28 Jan 2026 20:34:51 GMT Subject: RFR: 8375747: ZGC: ZForwardingTest is unable to commit memory on Windows In-Reply-To: <6daw9JcPvbNGfGoIgZi0cW-yA4JQ8nCTbpKjwYEbMoI=.0caaf56d-a1c0-4fb8-8b73-66175b2c267d@github.com> References: <6daw9JcPvbNGfGoIgZi0cW-yA4JQ8nCTbpKjwYEbMoI=.0caaf56d-a1c0-4fb8-8b73-66175b2c267d@github.com> Message-ID: On Wed, 28 Jan 2026 20:20:28 GMT, Stefan Karlsson wrote: > The ZForwardingTest gtest first reserves memory via the ZGC APIs to do so and then uses the generic `os::commit_memory(...)` to commit the memory. That is problematic on Windows because the two APIs are not compatible there. I've updated the test to use ZGC's APIs to commit and map memory instead. > > Thanks to @roberttoyonaga for finding this and helping out diagnosing this issue! > > The patch also adds some tiny fixes to the assert code that mislead me while prototyping this. > > I'll run this through tier1 testing. Marked as reviewed by eosterlund (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29471#pullrequestreview-3719028483 From xpeng at openjdk.org Wed Jan 28 20:38:46 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 28 Jan 2026 20:38:46 GMT Subject: RFR: 8376531: Genshen: Missing volatile modifier on multiple fields of ShenandoahOldGeneration [v2] In-Reply-To: References: Message-ID: <1-dtJxsPuT1Zuop712SzkGDBOJNftH9MLNw2d0c7f1w=.9eb4825e-1edf-442e-aaf6-06675f18c264@github.com> On Tue, 27 Jan 2026 23:49:18 GMT, Xiaolong Peng wrote: >> Came across the source code of ShenandoahOldGeneration, and noticed that we use AtomicAccess to read/write to fields `_promoted_expended`, `_promotion_failure_count`, `_promotion_failure_words` but non of them is declared with volatile modifier. >> >> Given that OpenJDK has introduced `Atomic` to replace the idiom of volatile var plus AtomicAccess:: operations(see details [here](https://bugs.openjdk.org/browse/JDK-8367013), I decided to convert these fields to `Atomic` instead of adding `volatile`. >> >> ### Test >> - [x] hotshpot_gc_shenandoah >> - [x] GHA > > Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: > > Use `1UL` instead of `static_cast(1)` Thanks, I'll update the title, also the information of JBS bug. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29456#issuecomment-3813811006 From jsikstro at openjdk.org Wed Jan 28 20:47:46 2026 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 28 Jan 2026 20:47:46 GMT Subject: RFR: 8375747: ZGC: ZForwardingTest is unable to commit memory on Windows In-Reply-To: <6daw9JcPvbNGfGoIgZi0cW-yA4JQ8nCTbpKjwYEbMoI=.0caaf56d-a1c0-4fb8-8b73-66175b2c267d@github.com> References: <6daw9JcPvbNGfGoIgZi0cW-yA4JQ8nCTbpKjwYEbMoI=.0caaf56d-a1c0-4fb8-8b73-66175b2c267d@github.com> Message-ID: On Wed, 28 Jan 2026 20:20:28 GMT, Stefan Karlsson wrote: > The ZForwardingTest gtest first reserves memory via the ZGC APIs to do so and then uses the generic `os::commit_memory(...)` to commit the memory. That is problematic on Windows because the two APIs are not compatible there. I've updated the test to use ZGC's APIs to commit and map memory instead. > > Thanks to @roberttoyonaga for finding this and helping out diagnosing this issue! > > The patch also adds some tiny fixes to the assert code that mislead me while prototyping this. > > I'll run this through tier1 testing. test/hotspot/gtest/gc/z/zunittest.hpp line 140: > 138: > 139: char* mem = (char*)os::malloc(sizeof(ZPhysicalMemoryBacking), mtTest); > 140: _backing = new (mem) ZPhysicalMemoryBacking(max_capacity); Should we call `create_backing` here instead? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29471#discussion_r2738536027 From stefank at openjdk.org Wed Jan 28 21:02:52 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 28 Jan 2026 21:02:52 GMT Subject: RFR: 8375747: ZGC: ZForwardingTest is unable to commit memory on Windows In-Reply-To: References: <6daw9JcPvbNGfGoIgZi0cW-yA4JQ8nCTbpKjwYEbMoI=.0caaf56d-a1c0-4fb8-8b73-66175b2c267d@github.com> Message-ID: On Wed, 28 Jan 2026 20:45:08 GMT, Joel Sikstr?m wrote: >> The ZForwardingTest gtest first reserves memory via the ZGC APIs to do so and then uses the generic `os::commit_memory(...)` to commit the memory. That is problematic on Windows because the two APIs are not compatible there. I've updated the test to use ZGC's APIs to commit and map memory instead. >> >> Thanks to @roberttoyonaga for finding this and helping out diagnosing this issue! >> >> The patch also adds some tiny fixes to the assert code that mislead me while prototyping this. >> >> I'll run this through tier1 testing. > > test/hotspot/gtest/gc/z/zunittest.hpp line 140: > >> 138: >> 139: char* mem = (char*)os::malloc(sizeof(ZPhysicalMemoryBacking), mtTest); >> 140: _backing = new (mem) ZPhysicalMemoryBacking(max_capacity); > > Should we call `create_backing` here instead? Ahh, thanks. These are left-overs from an earlier version. I'll fix this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29471#discussion_r2738588149 From stefank at openjdk.org Wed Jan 28 21:14:06 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 28 Jan 2026 21:14:06 GMT Subject: RFR: 8375747: ZGC: ZForwardingTest is unable to commit memory on Windows [v2] In-Reply-To: <6daw9JcPvbNGfGoIgZi0cW-yA4JQ8nCTbpKjwYEbMoI=.0caaf56d-a1c0-4fb8-8b73-66175b2c267d@github.com> References: <6daw9JcPvbNGfGoIgZi0cW-yA4JQ8nCTbpKjwYEbMoI=.0caaf56d-a1c0-4fb8-8b73-66175b2c267d@github.com> Message-ID: > The ZForwardingTest gtest first reserves memory via the ZGC APIs to do so and then uses the generic `os::commit_memory(...)` to commit the memory. That is problematic on Windows because the two APIs are not compatible there. I've updated the test to use ZGC's APIs to commit and map memory instead. > > Thanks to @roberttoyonaga for finding this and helping out diagnosing this issue! > > The patch also adds some tiny fixes to the assert code that mislead me while prototyping this. > > I'll run this through tier1 testing. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Restructure setup and teardown ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29471/files - new: https://git.openjdk.org/jdk/pull/29471/files/7180a1d7..ec3120cd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29471&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29471&range=00-01 Stats: 15 lines in 1 file changed: 6 ins; 7 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29471.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29471/head:pull/29471 PR: https://git.openjdk.org/jdk/pull/29471 From stefank at openjdk.org Wed Jan 28 21:16:41 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 28 Jan 2026 21:16:41 GMT Subject: RFR: 8375747: ZGC: ZForwardingTest is unable to commit memory on Windows In-Reply-To: <6daw9JcPvbNGfGoIgZi0cW-yA4JQ8nCTbpKjwYEbMoI=.0caaf56d-a1c0-4fb8-8b73-66175b2c267d@github.com> References: <6daw9JcPvbNGfGoIgZi0cW-yA4JQ8nCTbpKjwYEbMoI=.0caaf56d-a1c0-4fb8-8b73-66175b2c267d@github.com> Message-ID: On Wed, 28 Jan 2026 20:20:28 GMT, Stefan Karlsson wrote: > The ZForwardingTest gtest first reserves memory via the ZGC APIs to do so and then uses the generic `os::commit_memory(...)` to commit the memory. That is problematic on Windows because the two APIs are not compatible there. I've updated the test to use ZGC's APIs to commit and map memory instead. > > Thanks to @roberttoyonaga for finding this and helping out diagnosing this issue! > > The patch also adds some tiny fixes to the assert code that mislead me while prototyping this. > > I'll run this through tier1 testing. I removed the "create_backing" function and restructured the TearDown to tear down in the opposite order of how the variables are set up in SetUp. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29471#issuecomment-3813965895 From xpeng at openjdk.org Wed Jan 28 21:27:09 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 28 Jan 2026 21:27:09 GMT Subject: RFR: 8376531: Genshen: Convert ShenandoahOldGeneration to use Atomic [v2] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 23:49:18 GMT, Xiaolong Peng wrote: >> Came across the source code of ShenandoahOldGeneration, and noticed that we use AtomicAccess to read/write to fields `_promoted_expended`, `_promotion_failure_count`, `_promotion_failure_words` but non of them is declared with volatile modifier. >> >> Given that OpenJDK has introduced `Atomic` to replace the idiom of volatile var plus AtomicAccess:: operations(see details [here](https://bugs.openjdk.org/browse/JDK-8367013), I decided to convert these fields to `Atomic` instead of adding `volatile`. >> >> ### Test >> - [x] hotshpot_gc_shenandoah >> - [x] GHA > > Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: > > Use `1UL` instead of `static_cast(1)` Both PR and JBS bug have been updated, thanks all! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29456#issuecomment-3814010592 From duke at openjdk.org Wed Jan 28 21:29:05 2026 From: duke at openjdk.org (Robert Toyonaga) Date: Wed, 28 Jan 2026 21:29:05 GMT Subject: RFR: 8375747: ZGC: ZForwardingTest is unable to commit memory on Windows [v2] In-Reply-To: References: <6daw9JcPvbNGfGoIgZi0cW-yA4JQ8nCTbpKjwYEbMoI=.0caaf56d-a1c0-4fb8-8b73-66175b2c267d@github.com> Message-ID: <07TlzpT2FYXuYAMhoT9hNHuu2Rwfytvv2kQ0GG0gwXg=.b7970522-422d-4dd1-9b50-f47296fb3515@github.com> On Wed, 28 Jan 2026 21:14:06 GMT, Stefan Karlsson wrote: >> The ZForwardingTest gtest first reserves memory via the ZGC APIs to do so and then uses the generic `os::commit_memory(...)` to commit the memory. That is problematic on Windows because the two APIs are not compatible there. I've updated the test to use ZGC's APIs to commit and map memory instead. >> >> Thanks to @roberttoyonaga for finding this and helping out diagnosing this issue! >> >> The patch also adds some tiny fixes to the assert code that mislead me while prototyping this. >> >> I'll run this through tier1 testing. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Restructure setup and teardown Thanks! This looks good to me. ------------- Marked as reviewed by roberttoyonaga at github.com (no known OpenJDK username). PR Review: https://git.openjdk.org/jdk/pull/29471#pullrequestreview-3719245366 From xpeng at openjdk.org Wed Jan 28 21:31:30 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 28 Jan 2026 21:31:30 GMT Subject: Integrated: 8376531: Genshen: Convert ShenandoahOldGeneration to use Atomic In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 22:19:15 GMT, Xiaolong Peng wrote: > Came across the source code of ShenandoahOldGeneration, and noticed that we use AtomicAccess to read/write to fields `_promoted_expended`, `_promotion_failure_count`, `_promotion_failure_words` but non of them is declared with volatile modifier. > > Given that OpenJDK has introduced `Atomic` to replace the idiom of volatile var plus AtomicAccess:: operations(see details [here](https://bugs.openjdk.org/browse/JDK-8367013), I decided to convert these fields to `Atomic` instead of adding `volatile`. > > ### Test > - [x] hotshpot_gc_shenandoah > - [x] GHA This pull request has now been integrated. Changeset: 09ed8e66 Author: Xiaolong Peng URL: https://git.openjdk.org/jdk/commit/09ed8e66dc7a788763a2c7c24f54e93ec8eafedb Stats: 16 lines in 2 files changed: 0 ins; 0 del; 16 mod 8376531: Genshen: Convert ShenandoahOldGeneration to use Atomic Reviewed-by: wkemper, shade ------------- PR: https://git.openjdk.org/jdk/pull/29456 From ghan at openjdk.org Thu Jan 29 03:52:40 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 29 Jan 2026 03:52:40 GMT Subject: RFR: 8376287: Crash in G1CMTask::start_partial_array_processing(oop) when using invalid value for -XX:ObjArrayMarkingStride Message-ID: Please review this change, it addresses a trivial issue. Thanks! **Description:** This is a trivial issue caused by the invalid value of -XX:ObjArrayMarkingStride=0, which results in a division by zero in the PartialArrayTaskStepper::start() method. https://github.com/openjdk/jdk/blob/2529e2fe8dfe9685033bb0ae558266b8bc3cf95c/src/hotspot/share/gc/shared/partialArrayTaskStepper.inline.hpp#L39-L40 **Fix:** Restrict the ObjArrayMarkingStride to positive values. **Test:** GHA ------------- Commit messages: - fix 8376287 Changes: https://git.openjdk.org/jdk/pull/29479/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29479&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376287 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29479.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29479/head:pull/29479 PR: https://git.openjdk.org/jdk/pull/29479 From jsikstro at openjdk.org Thu Jan 29 07:50:44 2026 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Thu, 29 Jan 2026 07:50:44 GMT Subject: RFR: 8375747: ZGC: ZForwardingTest is unable to commit memory on Windows [v2] In-Reply-To: References: <6daw9JcPvbNGfGoIgZi0cW-yA4JQ8nCTbpKjwYEbMoI=.0caaf56d-a1c0-4fb8-8b73-66175b2c267d@github.com> Message-ID: On Wed, 28 Jan 2026 21:14:06 GMT, Stefan Karlsson wrote: >> The ZForwardingTest gtest first reserves memory via the ZGC APIs to do so and then uses the generic `os::commit_memory(...)` to commit the memory. That is problematic on Windows because the two APIs are not compatible there. I've updated the test to use ZGC's APIs to commit and map memory instead. >> >> Thanks to @roberttoyonaga for finding this and helping out diagnosing this issue! >> >> The patch also adds some tiny fixes to the assert code that mislead me while prototyping this. >> >> I'll run this through tier1 testing. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Restructure setup and teardown Looks good. ------------- Marked as reviewed by jsikstro (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29471#pullrequestreview-3721176293 From tschatzl at openjdk.org Thu Jan 29 08:30:42 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 29 Jan 2026 08:30:42 GMT Subject: RFR: 8376287: Crash in G1CMTask::start_partial_array_processing(oop) when using invalid value for -XX:ObjArrayMarkingStride In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 03:46:29 GMT, Guanqiang Han wrote: > Please review this change, it addresses a trivial issue. Thanks! > > **Description:** > > This is a trivial issue caused by the invalid value of -XX:ObjArrayMarkingStride=0, which results in a division by zero in the PartialArrayTaskStepper::start() method. > https://github.com/openjdk/jdk/blob/2529e2fe8dfe9685033bb0ae558266b8bc3cf95c/src/hotspot/share/gc/shared/partialArrayTaskStepper.inline.hpp#L39-L40 > > **Fix:** > > Restrict the ObjArrayMarkingStride to positive values. > > **Test:** > > GHA Looks good, but the corresponding sanity assert (ObjArrayMarkingStride > 0) could be removed in Shenandoah now. After some investigation we found that not only G1 is affected, but also Serial and Parallel GC to a varying degree, so the summary of the CR changed. ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29479#pullrequestreview-3721321325 From stefank at openjdk.org Thu Jan 29 08:39:40 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 29 Jan 2026 08:39:40 GMT Subject: RFR: 8375747: ZGC: ZForwardingTest is unable to commit memory on Windows [v2] In-Reply-To: References: <6daw9JcPvbNGfGoIgZi0cW-yA4JQ8nCTbpKjwYEbMoI=.0caaf56d-a1c0-4fb8-8b73-66175b2c267d@github.com> Message-ID: <92HW4tIYYHdx0OjKMxEjAS3loLo04pLv6pnlNCtOX3k=.80685dd9-81ec-4f60-9093-bc2daceb03c2@github.com> On Wed, 28 Jan 2026 21:14:06 GMT, Stefan Karlsson wrote: >> The ZForwardingTest gtest first reserves memory via the ZGC APIs to do so and then uses the generic `os::commit_memory(...)` to commit the memory. That is problematic on Windows because the two APIs are not compatible there. I've updated the test to use ZGC's APIs to commit and map memory instead. >> >> Thanks to @roberttoyonaga for finding this and helping out diagnosing this issue! >> >> The patch also adds some tiny fixes to the assert code that mislead me while prototyping this. >> >> I'll run this through tier1 testing. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Restructure setup and teardown Thanks for all the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29471#issuecomment-3816261002 From stefank at openjdk.org Thu Jan 29 08:43:08 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 29 Jan 2026 08:43:08 GMT Subject: Integrated: 8375747: ZGC: ZForwardingTest is unable to commit memory on Windows In-Reply-To: <6daw9JcPvbNGfGoIgZi0cW-yA4JQ8nCTbpKjwYEbMoI=.0caaf56d-a1c0-4fb8-8b73-66175b2c267d@github.com> References: <6daw9JcPvbNGfGoIgZi0cW-yA4JQ8nCTbpKjwYEbMoI=.0caaf56d-a1c0-4fb8-8b73-66175b2c267d@github.com> Message-ID: <6hgRve3EfrJqyDaSsOAKxTcTxGsoTZ6W6nAvAjI1rNE=.e9c0c68b-4411-487c-98c5-9b28e279a6ac@github.com> On Wed, 28 Jan 2026 20:20:28 GMT, Stefan Karlsson wrote: > The ZForwardingTest gtest first reserves memory via the ZGC APIs to do so and then uses the generic `os::commit_memory(...)` to commit the memory. That is problematic on Windows because the two APIs are not compatible there. I've updated the test to use ZGC's APIs to commit and map memory instead. > > Thanks to @roberttoyonaga for finding this and helping out diagnosing this issue! > > The patch also adds some tiny fixes to the assert code that mislead me while prototyping this. > > I'll run this through tier1 testing. This pull request has now been integrated. Changeset: 92072a93 Author: Stefan Karlsson URL: https://git.openjdk.org/jdk/commit/92072a93bfeb83186df15032d425ed984d24fc52 Stats: 73 lines in 3 files changed: 60 ins; 0 del; 13 mod 8375747: ZGC: ZForwardingTest is unable to commit memory on Windows Reviewed-by: jsikstro, eosterlund ------------- PR: https://git.openjdk.org/jdk/pull/29471 From tschatzl at openjdk.org Thu Jan 29 08:58:36 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 29 Jan 2026 08:58:36 GMT Subject: RFR: 8376350: Convert ReferenceProcessorPhaseTimes to use Atomic [v2] In-Reply-To: References: <2wZjpooawLKkrLsy4Z1MHU2dv8DeF8oxWMLqsCD8KXE=.2a356189-9302-4c17-88ab-b7a7b3e5e1cb@github.com> <81OYYiIaCB895cWxMOcnvAvJqm48lrE_Ip1aLfOZuQA=.6f7564ad-dcc8-45bf-be21-76f4dcfe9f70@github.com> Message-ID: On Wed, 28 Jan 2026 12:25:47 GMT, Stefan Karlsson wrote: >> Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision: >> >> - Apply suggestion from @tschatzl >> - Update src/hotspot/share/gc/shared/referenceProcessorPhaseTimes.cpp >> >> Co-authored-by: Stefan Karlsson > > Marked as reviewed by stefank (Reviewer). Thanks @stefank @walulyai for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/29423#issuecomment-3816338257 From tschatzl at openjdk.org Thu Jan 29 08:58:38 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 29 Jan 2026 08:58:38 GMT Subject: Integrated: 8376350: Convert ReferenceProcessorPhaseTimes to use Atomic In-Reply-To: <2wZjpooawLKkrLsy4Z1MHU2dv8DeF8oxWMLqsCD8KXE=.2a356189-9302-4c17-88ab-b7a7b3e5e1cb@github.com> References: <2wZjpooawLKkrLsy4Z1MHU2dv8DeF8oxWMLqsCD8KXE=.2a356189-9302-4c17-88ab-b7a7b3e5e1cb@github.com> Message-ID: <5cPXxsFs3f9T346N39oocPK9FucnXo3tbO_jozCa32w=.6e875095-1a55-471d-9c4e-97903915f9f5@github.com> On Mon, 26 Jan 2026 15:52:10 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to convert `ReferenceProcessorPhaseTimes` to use `Atomic`. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 681e4ec8 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/681e4ec8d37f4e30462b43e1c789d53525211b0a Stats: 8 lines in 2 files changed: 1 ins; 1 del; 6 mod 8376350: Convert ReferenceProcessorPhaseTimes to use Atomic Reviewed-by: stefank, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/29423 From tschatzl at openjdk.org Thu Jan 29 08:58:37 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 29 Jan 2026 08:58:37 GMT Subject: RFR: 8376335: Convert PreservedMarks classes to use Atomic [v2] In-Reply-To: <4JPk4zpgtxrTE92DVAazbhbOl4fNsBoKAYsMt1W58Ao=.4b23b7ef-4ee4-4601-8592-d6a50d34eaad@github.com> References: <4JPk4zpgtxrTE92DVAazbhbOl4fNsBoKAYsMt1W58Ao=.4b23b7ef-4ee4-4601-8592-d6a50d34eaad@github.com> Message-ID: On Wed, 28 Jan 2026 12:25:02 GMT, Stefan Karlsson wrote: >> Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision: >> >> - * improve docs >> - * stefank review > > Marked as reviewed by stefank (Reviewer). Thanks @stefank @walulyai for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/29422#issuecomment-3816335803 From tschatzl at openjdk.org Thu Jan 29 08:58:38 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 29 Jan 2026 08:58:38 GMT Subject: Integrated: 8376335: Convert PreservedMarks classes to use Atomic In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 15:15:23 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to make the `PreservedMarks` classes use `Atomic`. > > Some refactoring allowed removal of a now unnecessary function, and imo improved the code, avoiding the somewhat awkward passing of the atomic variable. > > Testing: gha, tier1-5 > > Thanks, > Thomas This pull request has now been integrated. Changeset: f9cc1042 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/f9cc104249433eec179c98cb3fb44546254bf588 Stats: 28 lines in 2 files changed: 7 ins; 12 del; 9 mod 8376335: Convert PreservedMarks classes to use Atomic Reviewed-by: stefank, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/29422 From thomas.schatzl at oracle.com Thu Jan 29 09:12:31 2026 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 29 Jan 2026 10:12:31 +0100 Subject: One question about hotspot g1 heap adaptive resizing feature In-Reply-To: References: Message-ID: Hi Erik, On 28.01.26 13:41, Erik Osterlund wrote: > Hi Thomas, > > If I understand the conversation, what is referred to is something like > this in ZGC style AHS: > https://github.com/openjdk/zgc/blob/ > c87666fbda432c9c9d19d6871859b8c195476f6c/src/hotspot/share/gc/z/ > zAdaptiveHeap.cpp#L505 c87666fbda432c9c9d19d6871859b8c195476f6c/src/hotspot/share/gc/z/ > zAdaptiveHeap.cpp#L505> > > and: > https://github.com/openjdk/zgc/blob/ > c87666fbda432c9c9d19d6871859b8c195476f6c/src/hotspot/share/gc/z/ > zAdaptiveHeap.cpp#L515 c87666fbda432c9c9d19d6871859b8c195476f6c/src/hotspot/share/gc/z/ > zAdaptiveHeap.cpp#L515> > > The reasoning here is that if you have a process that utilizes 1% of the > machine CPU resources but 50% of the memory resources, you might not > want to bloat memory with lots of garbage to reduce fraction of that 1% > that is spent of GC. In that situation, having a 100% CPU overhead so > that the JVM uses 2% of the overall machine CPU, while saving a huge > amount of the available RAM, is preferable. In other words, the CPU > overhead target depends on the resource balance of unused machine > resources, as well as a resource balance of the process used resources. > > In terms of use cases, containers without resource constraints or > partial resource constraints, is one application. Multi process > situations would be another one. Thanks for highlighting this aspect. The mentioned use case does not seem to consider multi-process situations, but I filed https://bugs.openjdk.org/browse/JDK-8376662 for G1 to remember. It is also interesting to see that apparently containers can access global state like total machine cpu usage. As far as I understood, the original use case was solely the concern that when the application is doing "nothing", the existing gctimeratio policy would somehow expand the heap because cpu activity would be high. This somewhat seemed to be a contradiction to me. Thinking about it a bit more, it is indeed possible in case the application did not actually allocate anything, but cause extreme gc activity due to reference updates / refinement, so at the next gc G1 would expand unnecessarily. I filed https://bugs.openjdk.org/browse/JDK-8376663 to investigate this too. Another possibility is that Shaojun is concerned because if the application really did "nothing", the heap is not _shrunk_ because there is no gc activity. For that case, currently the user must enable periodic gcs manually in G1. In the future a form of it will by enabled by default (and needs to be disabled manually). Thomas From ghan at openjdk.org Thu Jan 29 09:59:00 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 29 Jan 2026 09:59:00 GMT Subject: RFR: 8376287: Crashes when using -XX:ObjArrayMarkingStride=0 [v2] In-Reply-To: References: Message-ID: > Please review this change, it addresses a trivial issue. Thanks! > > **Description:** > > This is a trivial issue caused by the invalid value of -XX:ObjArrayMarkingStride=0, which results in a division by zero in the PartialArrayTaskStepper::start() method. > https://github.com/openjdk/jdk/blob/2529e2fe8dfe9685033bb0ae558266b8bc3cf95c/src/hotspot/share/gc/shared/partialArrayTaskStepper.inline.hpp#L39-L40 > > **Fix:** > > Restrict the ObjArrayMarkingStride to positive values. > > **Test:** > > GHA Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: remove unused assert ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29479/files - new: https://git.openjdk.org/jdk/pull/29479/files/107cecff..6662176e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29479&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29479&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29479.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29479/head:pull/29479 PR: https://git.openjdk.org/jdk/pull/29479 From shade at openjdk.org Thu Jan 29 11:22:25 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 29 Jan 2026 11:22:25 GMT Subject: RFR: 8376287: Crashes when using -XX:ObjArrayMarkingStride=0 [v2] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 09:59:00 GMT, Guanqiang Han wrote: >> Please review this change, it addresses a trivial issue. Thanks! >> >> **Description:** >> >> This is a trivial issue caused by the invalid value of -XX:ObjArrayMarkingStride=0, which results in a division by zero in the PartialArrayTaskStepper::start() method. >> https://github.com/openjdk/jdk/blob/2529e2fe8dfe9685033bb0ae558266b8bc3cf95c/src/hotspot/share/gc/shared/partialArrayTaskStepper.inline.hpp#L39-L40 >> >> **Fix:** >> >> Restrict the ObjArrayMarkingStride to positive values. >> >> **Test:** >> >> GHA > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > remove unused assert Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29479#pullrequestreview-3722101848 From ghan at openjdk.org Thu Jan 29 11:37:31 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 29 Jan 2026 11:37:31 GMT Subject: RFR: 8376287: Crashes when using -XX:ObjArrayMarkingStride=0 [v2] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 08:28:01 GMT, Thomas Schatzl wrote: >> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: >> >> remove unused assert > > Looks good, but the corresponding sanity assert (ObjArrayMarkingStride > 0) could be removed in Shenandoah now. > > After some investigation we found that not only G1 is affected, but also Serial and Parallel GC to a varying degree, so the summary of the CR changed. Hi @tschatzl , I've removed the unused assert and updated the CR summary. Could you please take a look? Hi @shipilev , thank you for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29479#issuecomment-3817095687 From tschatzl at openjdk.org Thu Jan 29 11:59:52 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 29 Jan 2026 11:59:52 GMT Subject: RFR: 8376287: Crashes when using -XX:ObjArrayMarkingStride=0 [v2] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 09:59:00 GMT, Guanqiang Han wrote: >> Please review this change, it addresses a trivial issue. Thanks! >> >> **Description:** >> >> This is a trivial issue caused by the invalid value of -XX:ObjArrayMarkingStride=0, which results in a division by zero in the PartialArrayTaskStepper::start() method. >> https://github.com/openjdk/jdk/blob/2529e2fe8dfe9685033bb0ae558266b8bc3cf95c/src/hotspot/share/gc/shared/partialArrayTaskStepper.inline.hpp#L39-L40 >> >> **Fix:** >> >> Restrict the ObjArrayMarkingStride to positive values. >> >> **Test:** >> >> GHA > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > remove unused assert See the other note about maximum value. ------------- Changes requested by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29479#pullrequestreview-3722254497 From tschatzl at openjdk.org Thu Jan 29 11:59:54 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 29 Jan 2026 11:59:54 GMT Subject: RFR: 8376287: Crashes when using -XX:ObjArrayMarkingStride=0 [v2] In-Reply-To: References: Message-ID: <5fpE6mUk_XkEdqcQxmJJM6qB8WPCLB1E8m1oDW92PI8=.7abdebcb-4814-4d2c-9e09-431cb6034e21@github.com> On Thu, 29 Jan 2026 08:28:01 GMT, Thomas Schatzl wrote: >> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: >> >> remove unused assert > > Looks good, but the corresponding sanity assert (ObjArrayMarkingStride > 0) could be removed in Shenandoah now. > > After some investigation we found that not only G1 is affected, but also Serial and Parallel GC to a varying degree, so the summary of the CR changed. > Hi @tschatzl , I've removed the unused assert and updated the CR summary. Could you please take a look? Hi @shipilev , thank you for the review. Looking in more detail on the uses of `ObjArrayMarkingStride`, I see that it is cast to `int`, and at least one calculation multiplies it with 2 before casting to int. So it must be <= `MAX_INT / 2`. Apologies for not looking in more detail earlier. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29479#issuecomment-3817194993 From ghan at openjdk.org Thu Jan 29 12:47:58 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 29 Jan 2026 12:47:58 GMT Subject: RFR: 8376287: Crashes when using -XX:ObjArrayMarkingStride=0 [v3] In-Reply-To: References: Message-ID: <5ZoUh1_ZR1SQQndoVhCxlpAXPQUn5BPhxRIzs7E_Cwk=.8d6930b9-8bb9-4439-8b9b-e6e2813f5213@github.com> > Please review this change, it addresses a trivial issue. Thanks! > > **Description:** > > This is a trivial issue caused by the invalid value of -XX:ObjArrayMarkingStride=0, which results in a division by zero in the PartialArrayTaskStepper::start() method. > https://github.com/openjdk/jdk/blob/2529e2fe8dfe9685033bb0ae558266b8bc3cf95c/src/hotspot/share/gc/shared/partialArrayTaskStepper.inline.hpp#L39-L40 > > **Fix:** > > Restrict the ObjArrayMarkingStride to positive values. > > **Test:** > > GHA Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: change max value to INT_MAX/2 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29479/files - new: https://git.openjdk.org/jdk/pull/29479/files/6662176e..e0544982 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29479&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29479&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29479.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29479/head:pull/29479 PR: https://git.openjdk.org/jdk/pull/29479 From iwalulya at openjdk.org Thu Jan 29 14:28:41 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 29 Jan 2026 14:28:41 GMT Subject: RFR: 8374782: Parallel: Investigate removal of specialized objArray iteration code Message-ID: Hi, Please review this change removes specialized local methods used to iterate over array slices in `PSPromotionManager`. Any performance differences between these methods and `objArrayOopDesc::oop_iterate_elements_range` are attributable to differences in inlining behavior. For this reason, `ALWAYSINLINE` is applied. Further investigation is ongoing to improve inlining of calls through `objArrayOopDesc::oop_iterate_elements_range`. Testing: Tier 1-3, perf testing with SPECjvm2008-XML.validation. ------------- Commit messages: - Merge remote-tracking branch 'upstream/master' into JDK-8374782 - ALWAYSINLINE - init Changes: https://git.openjdk.org/jdk/pull/29486/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29486&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374782 Stats: 29 lines in 3 files changed: 2 ins; 17 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/29486.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29486/head:pull/29486 PR: https://git.openjdk.org/jdk/pull/29486 From lkorinth at openjdk.org Thu Jan 29 14:47:12 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 29 Jan 2026 14:47:12 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v9] In-Reply-To: References: Message-ID: > This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. > > It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. > > This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. > > I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. Leo Korinth has updated the pull request incrementally with two additional commits since the last revision: - Reapply "remove commented out code" This reverts commit d0d1860058f0dae7813c3e5115e2784da8331f3b. - Reapply "Stefan J 4" This reverts commit c5a7e2bb44ce111f8c8d1d7f728f1bf8013475e0. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28723/files - new: https://git.openjdk.org/jdk/pull/28723/files/c5a7e2bb..4cf44ec8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28723&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28723&range=07-08 Stats: 3 lines in 2 files changed: 2 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28723.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28723/head:pull/28723 PR: https://git.openjdk.org/jdk/pull/28723