From shade at openjdk.org  Mon Sep  1 09:06:45 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 1 Sep 2025 09:06:45 GMT
Subject: RFR: 8357188: Remove the field
 MemAllocator::Allocation::_overhead_limit_exceeded and the related code [v2]
In-Reply-To: <4suEaL8ElbI5gbPNk1Sq0hO4j5v3SvHUemCfLDbERiY=.1d0d93ff-15f7-4f04-8cb5-a705fc2ddfce@github.com>
References: <0qHdlghXGyq966nZz5mrxkDrTLtN-FNb7zqRSewz92o=.84d3673c-7526-4ad7-a37d-17c3637ce918@github.com>
 <4suEaL8ElbI5gbPNk1Sq0hO4j5v3SvHUemCfLDbERiY=.1d0d93ff-15f7-4f04-8cb5-a705fc2ddfce@github.com>
Message-ID: <rVqLeEbOFSOKzFANTQLxl91x0SHnpav4HKvgiw3Wn4E=.c01af908-090f-4469-a411-ff78ab6d54f6@github.com>

On Sun, 31 Aug 2025 11:31:32 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> After JDK-8338977 [1], the field `MemAllocator::Allocation::_overhead_limit_exceeded` and the parameter `gc_overhead_limit_was_exceeded` of the method `CollectedHeap::mem_allocate` are not used by any GC. This patch removes them.
>> 
>> Test:
>> All the tests of the command `make test TEST="hotspot:hotspot_gc"` passed locally (linux, x86_64, release build).
>> 
>> Best Regards,
>> -- Guoxiong
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8338977
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove outdated comments.

Looks okay. Do we need to track down where was the last use of it?

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27020#pullrequestreview-3172785985

From gli at openjdk.org  Mon Sep  1 10:53:41 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 1 Sep 2025 10:53:41 GMT
Subject: RFR: 8357188: Remove the field
 MemAllocator::Allocation::_overhead_limit_exceeded and the related code [v2]
In-Reply-To: <rVqLeEbOFSOKzFANTQLxl91x0SHnpav4HKvgiw3Wn4E=.c01af908-090f-4469-a411-ff78ab6d54f6@github.com>
References: <0qHdlghXGyq966nZz5mrxkDrTLtN-FNb7zqRSewz92o=.84d3673c-7526-4ad7-a37d-17c3637ce918@github.com>
 <4suEaL8ElbI5gbPNk1Sq0hO4j5v3SvHUemCfLDbERiY=.1d0d93ff-15f7-4f04-8cb5-a705fc2ddfce@github.com>
 <rVqLeEbOFSOKzFANTQLxl91x0SHnpav4HKvgiw3Wn4E=.c01af908-090f-4469-a411-ff78ab6d54f6@github.com>
Message-ID: <HDRggQ5sujDRDMSsXQWq1gRyabAKOrl5RL8H1hfkQ0s=.9a151b2f-35ce-4c14-ad5f-facb045c5ecf@github.com>

On Mon, 1 Sep 2025 09:04:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Do we need to track down where was the last use of it?

Please read the patch of JDK-8338977 [1] [2], I think the change in `parallelScavengeHeap.cpp#L327-L349` was the last use of it.

[1] https://bugs.openjdk.org/browse/JDK-8338977
[2] https://github.com/openjdk/jdk/commit/ad510fb25e47098d136515c355164e5177c5b419

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27020#issuecomment-3241909483

From fbredberg at openjdk.org  Tue Sep  2 11:07:00 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Tue, 2 Sep 2025 11:07:00 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
Message-ID: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>

Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).

This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.

Passes tier1-tier5 with no added problems.

-------------

Commit messages:
 - 8365190: Remove LockingMode related code from share

Changes: https://git.openjdk.org/jdk/pull/27041/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27041&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365190
  Stats: 1268 lines in 50 files changed: 6 ins; 1129 del; 133 mod
  Patch: https://git.openjdk.org/jdk/pull/27041.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27041/head:pull/27041

PR: https://git.openjdk.org/jdk/pull/27041

From ayang at openjdk.org  Tue Sep  2 13:40:41 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 2 Sep 2025 13:40:41 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
In-Reply-To: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
Message-ID: <U94hZ-F_Ttvx0apRTyrd9GMIdjDcrut6q5HM0iCeI2c=.bb3e750b-34da-4a64-b2b3-c2463e52a920@github.com>

On Tue, 2 Sep 2025 08:24:10 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
> 
> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
> 
> Passes tier1-tier5 with no added problems.

Marked as reviewed by ayang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27041#pullrequestreview-3176613129

From rcastanedalo at openjdk.org  Tue Sep  2 13:48:45 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 2 Sep 2025 13:48:45 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
In-Reply-To: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
Message-ID: <uTv7hGrRoKhLCxyY2SILmig-HZw0zE5Gh3wNLZ2R1LE=.0d6eb14f-b6aa-464e-9fac-87b829f32f84@github.com>

On Tue, 2 Sep 2025 08:24:10 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
> 
> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
> 
> Passes tier1-tier5 with no added problems.

src/hotspot/share/opto/phaseX.cpp line 1672:

> 1670:     // Found (linux x64 only?) with:
> 1671:     //   serviceability/sa/ClhsdbThreadContext.java
> 1672:     //   -XX:+UnlockExperimentalVMOptions -XX:LockingMode=1 -XX:+IgnoreUnrecognizedVMOptions -XX:VerifyIterativeGVN=1110

For traceability, I suggest leaving this line untouched and adding a comment in the next line clarifying that `-XX:LockingMode` is not available anymore.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2316150051

From syan at openjdk.org  Tue Sep  2 14:28:56 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 2 Sep 2025 14:28:56 GMT
Subject: RFR: 8366692: Several gc/shenandoah tests timed out
Message-ID: <xmal0MH4ntVgjSL8IDkxsnvEMwINQo9P493HWsweoQ4=.aa160adc-16c7-4d9d-a1a9-13438c7ec052@github.com>

Hi all,

After JDK-8260555 set the default jtreg timeout factor to 1, then several gc/shenandoah tests run timed out with jtreg options -timeoutFactor:1. So I think it's necessary to increase the timeout value set in tests to make test run normally.

The actual run time consumed on my linux-x64 machine with  224 CPU core threads shows in [JDK-8366692](https://bugs.openjdk.org/browse/JDK-8366692).

Accodring the time statistics, the test test/hotspot/jtreg/gc/shenandoah/TestSieveObjects.java only change the second `@run` at the `@test id=generational` and `@test id=aggressive`, other tests do not need to change. And all the `@run` in test test/hotspot/jtreg/gc/shenandoah/jni/TestJNIGlobalRefs.java changed from 120(default value) to 240.

Change has been verified locally on linux-x64, test-fix only, no risk.

-------------

Commit messages:
 - add timeout value for @aggressive
 - 8366692: Several gc/shenandoah tests timed out

Changes: https://git.openjdk.org/jdk/pull/27052/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27052&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366692
  Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/27052.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27052/head:pull/27052

PR: https://git.openjdk.org/jdk/pull/27052

From shade at openjdk.org  Tue Sep  2 15:07:43 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 2 Sep 2025 15:07:43 GMT
Subject: RFR: 8366692: Several gc/shenandoah tests timed out
In-Reply-To: <xmal0MH4ntVgjSL8IDkxsnvEMwINQo9P493HWsweoQ4=.aa160adc-16c7-4d9d-a1a9-13438c7ec052@github.com>
References: <xmal0MH4ntVgjSL8IDkxsnvEMwINQo9P493HWsweoQ4=.aa160adc-16c7-4d9d-a1a9-13438c7ec052@github.com>
Message-ID: <pfbL_9meh_gPlfKRNnNQHARcTgWI8pDAuUvWeLTgBw4=.f41f7a6c-c0dd-49a1-aab6-15df3510e65e@github.com>

On Tue, 2 Sep 2025 13:58:46 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> After JDK-8260555 set the default jtreg timeout factor to 1, then several gc/shenandoah tests run timed out with jtreg options -timeoutFactor:1. So I think it's necessary to increase the timeout value set in tests to make test run normally.
> 
> The actual run time consumed on my linux-x64 machine with  224 CPU core threads shows in [JDK-8366692](https://bugs.openjdk.org/browse/JDK-8366692).
> 
> Accodring the time statistics, the test test/hotspot/jtreg/gc/shenandoah/TestSieveObjects.java only change the second `@run` at the `@test id=generational` and `@test id=aggressive`, other tests do not need to change. And all the `@run` in test test/hotspot/jtreg/gc/shenandoah/jni/TestJNIGlobalRefs.java changed from 120(default value) to 240.
> 
> Change has been verified locally on linux-x64, test-fix only, no risk.

Yeah, it makes sense that tests under verifier are slow. The fix looks fine.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27052#pullrequestreview-3176982444

From wkemper at openjdk.org  Tue Sep  2 18:23:44 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 2 Sep 2025 18:23:44 GMT
Subject: RFR: 8366692: Several gc/shenandoah tests timed out
In-Reply-To: <xmal0MH4ntVgjSL8IDkxsnvEMwINQo9P493HWsweoQ4=.aa160adc-16c7-4d9d-a1a9-13438c7ec052@github.com>
References: <xmal0MH4ntVgjSL8IDkxsnvEMwINQo9P493HWsweoQ4=.aa160adc-16c7-4d9d-a1a9-13438c7ec052@github.com>
Message-ID: <ANyxJvBvoWfiUkp4IhAVD00Bebl7ap9TvfKYpedyxyI=.fb65fc48-5694-4373-9baa-79bcb738105c@github.com>

On Tue, 2 Sep 2025 13:58:46 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> After JDK-8260555 set the default jtreg timeout factor to 1, then several gc/shenandoah tests run timed out with jtreg options -timeoutFactor:1. So I think it's necessary to increase the timeout value set in tests to make test run normally.
> 
> The actual run time consumed on my linux-x64 machine with  224 CPU core threads shows in [JDK-8366692](https://bugs.openjdk.org/browse/JDK-8366692).
> 
> Accodring the time statistics, the test test/hotspot/jtreg/gc/shenandoah/TestSieveObjects.java only change the second `@run` at the `@test id=generational` and `@test id=aggressive`, other tests do not need to change. And all the `@run` in test test/hotspot/jtreg/gc/shenandoah/jni/TestJNIGlobalRefs.java changed from 120(default value) to 240.
> 
> Change has been verified locally on linux-x64, test-fix only, no risk.

Seems there is some unrelated build breakage. Can we merge from `master` again before integrating?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27052#issuecomment-3246356701

From kdnilsen at openjdk.org  Tue Sep  2 18:37:42 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 2 Sep 2025 18:37:42 GMT
Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to
 conc_instruction_and_data_patch
In-Reply-To: <hA8KRrjiWgdQsG7TWURlzOna1OPV0y76a55vfs5X9sU=.2e392c8e-d180-42e7-840a-60085d7426df@github.com>
References: <hA8KRrjiWgdQsG7TWURlzOna1OPV0y76a55vfs5X9sU=.2e392c8e-d180-42e7-840a-60085d7426df@github.com>
Message-ID: <CH6BhAzy_XEsc70YWdXXwnIxFzGa35NDIBK0Cx3Yv5E=.4eb3a051-c38c-4c6b-8c8e-e66320fd1968@github.com>

On Fri, 29 Aug 2025 00:02:42 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> Please, review this patch to make nmethod entry barriers use `conc-instruction-and-data-patch` fence mechanics when ShenandoahGC is being used on AArch64. The patch also removes (including from JVMCI interface) the old constant that was being used only by Shenandoah on AArch64.
> 
> The patch has been tested with functional and performance benchmarks on AArch64. Improvements in DaCapo and Renaissance benchmarks can be as high as 30%. Maximum critical Jops in SPEC improved by ~10%.

Thank you for doing this.  Looks good to me.

-------------

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26999#pullrequestreview-3177693651

From kdnilsen at openjdk.org  Tue Sep  2 18:38:49 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 2 Sep 2025 18:38:49 GMT
Subject: RFR: 8342640: GenShen: Silently ignoring ShenandoahGCHeuristics
 considered poor user-experience [v2]
In-Reply-To: <-G7AGJRPOYIhjHRPhx8fyuinCe-nLXZfbZO3Sz5Y7iM=.0b6d63d6-24e6-4618-9fa0-106dde9fa2f7@github.com>
References: <O8NEkCNP1GVe--X2sM7tUDmboVfTH2L28WoTlnOgeaY=.7234d126-94ff-43f3-9245-765e995eb099@github.com>
 <-G7AGJRPOYIhjHRPhx8fyuinCe-nLXZfbZO3Sz5Y7iM=.0b6d63d6-24e6-4618-9fa0-106dde9fa2f7@github.com>
Message-ID: <-mwUFNkv8imkFbHfvj9GQyXWFiGg1oZ9aIKUPFV3ZXA=.bf85a1f5-2d69-415f-8b00-c9f189c53a5c@github.com>

On Wed, 27 Aug 2025 22:47:58 GMT, Rui Li <duke at openjdk.org> wrote:

>> When generational shenandoah is enabled, it ignores the value of ShenandoahGCHeuristics input silently:
>> 
>> java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:ShenandoahGCHeuristics=junk -version
>> openjdk version "25" 2025-09-16 LTS
>> OpenJDK Runtime Environment Corretto-25.0.0.36.1 (build 25+36-LTS)
>> OpenJDK 64-Bit Server VM Corretto-25.0.0.36.1 (build 25+36-LTS, mixed mode, sharing)
>> 
>> 
>> Adding additional guard rail to gen shen is not an option - it is actually by design that gen shen does not support non adaptive heuristics due to the complexity brought by generational design. 
>> 
>> So print out a warning to users to indicate that their `ShenandoahGCHeuristics` input is ignored.
>> 
>> 
>> x64 (8342640) % java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:ShenandoahGCHeuristics=static -version
>> [0.001s][warning][gc] Ignoring -XX:ShenandoahGCHeuristics input: static, because generational shenandoah only supports adaptive heuristics
>> openjdk version "26" 2026-03-17
>> OpenJDK Runtime Environment Corretto-26.0.2.1.1 (slowdebug build 26+2-FR)
>> OpenJDK 64-Bit Server VM Corretto-26.0.2.1.1 (slowdebug build 26+2-FR, mixed mode)
>> 
>> x64 (8342640) % java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:ShenandoahGCHeuristics=junk -version
>> [0.001s][warning][gc] Ignoring -XX:ShenandoahGCHeuristics input: junk, because generational shenandoah only supports adaptive heuristics
>> openjdk version "26" 2026-03-17
>> OpenJDK Runtime Environment Corretto-26.0.2.1.1 (slowdebug build 26+2-FR)
>> OpenJDK 64-Bit Server VM Corretto-26.0.2.1.1 (slowdebug build 26+2-FR, mixed mode)
>> 
>> x64 (8342640) % java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:ShenandoahGCHeuristics=adaptive -version
>> openjdk version "26" 2026-03-17
>> OpenJDK Runtime Environment Corretto-26.0.2.1.1 (slowdebug build 26+2-FR)
>> OpenJDK 64-Bit Server VM Corretto-26.0.2.1.1 (slowdebug build 26+2-FR, mixed mode)
>> 
>> x64 (8342640) % java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -version  
>> openjdk version "26" 2026-03-17
>> OpenJDK Runtime Environment Corretto-26.0.2.1.1 (slowdebug build 26+2-FR)
>> OpenJDK 64-Bit Server VM Corretto-26.0.2.1.1 (slowdebug build 26+2-FR, mixed mode)
>
> Rui Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update

Thanks for this fix.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26968#pullrequestreview-3177697913

From wkemper at openjdk.org  Tue Sep  2 19:37:42 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 2 Sep 2025 19:37:42 GMT
Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to
 conc_instruction_and_data_patch
In-Reply-To: <hA8KRrjiWgdQsG7TWURlzOna1OPV0y76a55vfs5X9sU=.2e392c8e-d180-42e7-840a-60085d7426df@github.com>
References: <hA8KRrjiWgdQsG7TWURlzOna1OPV0y76a55vfs5X9sU=.2e392c8e-d180-42e7-840a-60085d7426df@github.com>
Message-ID: <LFx-9nu2d9KI5PfPujX92dljjdpRtiKibas0-LncuTU=.36237f22-ca27-4a7e-a22a-6740785747f0@github.com>

On Fri, 29 Aug 2025 00:02:42 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> Please, review this patch to make nmethod entry barriers use `conc-instruction-and-data-patch` fence mechanics when ShenandoahGC is being used on AArch64. The patch also removes (including from JVMCI interface) the old constant that was being used only by Shenandoah on AArch64.
> 
> The patch has been tested with functional and performance benchmarks on AArch64. Improvements in DaCapo and Renaissance benchmarks can be as high as 30%. Maximum critical Jops in SPEC improved by ~10%.

LGTM

-------------

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26999#pullrequestreview-3177866470

From coleenp at openjdk.org  Tue Sep  2 20:35:48 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 2 Sep 2025 20:35:48 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
In-Reply-To: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
Message-ID: <YYyG4Y12GO9UncFyZG8Z4vNUfOUIR9le_CBBp7hC54g=.d29ff0c6-8c37-44cd-b24d-35666d094725@github.com>

On Tue, 2 Sep 2025 08:24:10 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
> 
> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
> 
> Passes tier1-tier5 with no added problems.

A few comments and suggestions for your next RFE.

src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 344:

> 342:   volatile_nonstatic_field(ObjectMonitor,      _entry_list,                                   ObjectWaiter*)                         \
> 343:   volatile_nonstatic_field(ObjectMonitor,      _succ,                                         int64_t)                               \
> 344:   volatile_nonstatic_field(ObjectMonitor,      _stack_locker,                                 BasicLock*)                            \

There are some jvmci tests that check that the java side of jvmci matches, ie:

make test TEST=compiler/jvmci

src/hotspot/share/runtime/basicLock.hpp line 51:

> 49:   void set_bad_metadata_deopt() { set_metadata(badDispHeaderDeopt); }
> 50: 
> 51:   static int displaced_header_offset_in_bytes() { return metadata_offset_in_bytes(); }

Also delete line 51 ?

src/hotspot/share/runtime/javaThread.cpp line 2007:

> 2005: #ifdef SUPPORT_MONITOR_COUNT
> 2006:   // Nothing to do. Just do some sanity check.
> 2007:   assert(_held_monitor_count == 0, "counter should not be used");

In further cleanup, can we now remove _held_monitor_count next?

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 769:

> 767: 
> 768: // LightweightSynchronizer::inflate_locked_or_imse is used to to get an inflated
> 769: // ObjectMonitor* when lightweight locking is used. It is used from contexts

I guess you don't need the phrase "when lightweight locking is used".

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 823:

> 821: ObjectMonitor* LightweightSynchronizer::inflate_into_object_header(oop object, ObjectSynchronizer::InflateCause cause, JavaThread* locking_thread, Thread* current) {
> 822: 
> 823:   // The JavaThread* locking_thread parameter is only used by lightweight locking and

Same here. suggestion:


// The JavaThread* locking parameter requires that the locking_thread == JavaThread::current, or is suspended
// throughout the call by some other mechanism.

src/hotspot/share/runtime/synchronizer.cpp line 542:

> 540:   }
> 541:   ObjectMonitor* monitor;
> 542:   monitor = LightweightSynchronizer::inflate_locked_or_imse(obj(), inflate_cause_notify, CHECK);

Declare and initialize on the same line:

ObjectMonitor* monitor = LightwightSynchronizer::inflate_locked_or_imse(obj...);

src/hotspot/share/runtime/synchronizer.cpp line 557:

> 555: 
> 556:   ObjectMonitor* monitor;
> 557:   monitor = LightweightSynchronizer::inflate_locked_or_imse(obj(), inflate_cause_notify, CHECK);

same here with
ObjectMonitor* monitor = LIght ...

I think we should have another RFE to look at eliminating the middle call.  Call these in LIghtweightSynchronizer::notify, notifyAll and waitInterruptably directly and remove these functions.

src/hotspot/share/runtime/synchronizer.inline.hpp line 48:

> 46:   assert(current == Thread::current(), "must be");
> 47: 
> 48:     LightweightSynchronizer::enter(obj, lock, current);

In the further RFE, we should remove these dispatch functions too.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27041#pullrequestreview-3177963667
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2317054927
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2317063086
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2317069783
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2317072241
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2317077253
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2317084869
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2317088830
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2317095107

From cslucas at openjdk.org  Wed Sep  3 00:23:05 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 3 Sep 2025 00:23:05 GMT
Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to
 conc_instruction_and_data_patch [v2]
In-Reply-To: <hA8KRrjiWgdQsG7TWURlzOna1OPV0y76a55vfs5X9sU=.2e392c8e-d180-42e7-840a-60085d7426df@github.com>
References: <hA8KRrjiWgdQsG7TWURlzOna1OPV0y76a55vfs5X9sU=.2e392c8e-d180-42e7-840a-60085d7426df@github.com>
Message-ID: <TnlE6nDfG3WCxk_8rHCb-tOSFSqcwbsNMP0YtQ5mHxo=.514356af-0802-44af-8488-06876c90b599@github.com>

> Please, review this patch to make nmethod entry barriers use `conc-instruction-and-data-patch` fence mechanics when ShenandoahGC is being used on AArch64. The patch also removes (including from JVMCI interface) the old constant that was being used only by Shenandoah on AArch64.
> 
> The patch has been tested with functional and performance benchmarks on AArch64. Improvements in DaCapo and Renaissance benchmarks can be as high as 30%. Maximum critical Jops in SPEC improved by ~10%.

Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:

  Change shenandoah nmethod entry barrier fence for RISC-V
  
  (cherry picked from commit 495b07fe690ef7e3fe828fd2be27c4259c739c23)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26999/files
  - new: https://git.openjdk.org/jdk/pull/26999/files/62da55fb..3276b586

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26999&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26999&range=00-01

  Stats: 9 lines in 4 files changed: 0 ins; 7 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26999.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26999/head:pull/26999

PR: https://git.openjdk.org/jdk/pull/26999

From cslucas at openjdk.org  Wed Sep  3 00:37:59 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 3 Sep 2025 00:37:59 GMT
Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to
 conc_instruction_and_data_patch [v3]
In-Reply-To: <hA8KRrjiWgdQsG7TWURlzOna1OPV0y76a55vfs5X9sU=.2e392c8e-d180-42e7-840a-60085d7426df@github.com>
References: <hA8KRrjiWgdQsG7TWURlzOna1OPV0y76a55vfs5X9sU=.2e392c8e-d180-42e7-840a-60085d7426df@github.com>
Message-ID: <m8TVuzCamuC5zbdEJFrM4EWQDIKoUCOI8KsNvGeFEFU=.608bd8a2-30b5-46dc-9789-df755ad93d3b@github.com>

> Please, review this patch to make nmethod entry barriers use `conc-instruction-and-data-patch` fence mechanics when ShenandoahGC is being used on AArch64. The patch also removes (including from JVMCI interface) the old constant that was being used only by Shenandoah on AArch64.
> 
> The patch has been tested with functional and performance benchmarks on AArch64. Improvements in DaCapo and Renaissance benchmarks can be as high as 30%. Maximum critical Jops in SPEC improved by ~10%.

Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:

  Make PPC backend to also use concurrent code patching.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26999/files
  - new: https://git.openjdk.org/jdk/pull/26999/files/3276b586..4da31385

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26999&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26999&range=01-02

  Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26999.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26999/head:pull/26999

PR: https://git.openjdk.org/jdk/pull/26999

From fyang at openjdk.org  Wed Sep  3 01:30:44 2025
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 3 Sep 2025 01:30:44 GMT
Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to
 conc_instruction_and_data_patch [v3]
In-Reply-To: <m8TVuzCamuC5zbdEJFrM4EWQDIKoUCOI8KsNvGeFEFU=.608bd8a2-30b5-46dc-9789-df755ad93d3b@github.com>
References: <hA8KRrjiWgdQsG7TWURlzOna1OPV0y76a55vfs5X9sU=.2e392c8e-d180-42e7-840a-60085d7426df@github.com>
 <m8TVuzCamuC5zbdEJFrM4EWQDIKoUCOI8KsNvGeFEFU=.608bd8a2-30b5-46dc-9789-df755ad93d3b@github.com>
Message-ID: <Vctj7iR6hz5kQDIIaEQdHi8JAy8NJq-BRpi5vf5Mez8=.71f12048-427a-4eed-be83-2bd87d8e9ebc@github.com>

On Wed, 3 Sep 2025 00:37:59 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Please, review this patch to make nmethod entry barriers use `conc-instruction-and-data-patch` fence mechanics when ShenandoahGC is being used on AArch64. The patch also removes (including from JVMCI interface) the old constant that was being used only by Shenandoah on AArch64.
>> 
>> The patch has been tested with functional and performance benchmarks on AArch64. Improvements in DaCapo and Renaissance benchmarks can be as high as 30%. Maximum critical Jops in SPEC improved by ~10%.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make PPC backend to also use concurrent code patching.

I just checked the RISC-V part. LGTM. Thanks.

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26999#pullrequestreview-3178669201

From syan at openjdk.org  Wed Sep  3 02:00:24 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 3 Sep 2025 02:00:24 GMT
Subject: RFR: 8366692: Several gc/shenandoah tests timed out [v2]
In-Reply-To: <xmal0MH4ntVgjSL8IDkxsnvEMwINQo9P493HWsweoQ4=.aa160adc-16c7-4d9d-a1a9-13438c7ec052@github.com>
References: <xmal0MH4ntVgjSL8IDkxsnvEMwINQo9P493HWsweoQ4=.aa160adc-16c7-4d9d-a1a9-13438c7ec052@github.com>
Message-ID: <BiUl44HhvTWBJZYv8MayY0_xwkzeYR8Yr9XgqZhi6Kk=.8bfddf94-e580-4ae8-881c-2afed11c7a93@github.com>

> Hi all,
> 
> After JDK-8260555 set the default jtreg timeout factor to 1, then several gc/shenandoah tests run timed out with jtreg options -timeoutFactor:1. So I think it's necessary to increase the timeout value set in tests to make test run normally.
> 
> The actual run time consumed on my linux-x64 machine with  224 CPU core threads shows in [JDK-8366692](https://bugs.openjdk.org/browse/JDK-8366692).
> 
> Accodring the time statistics, the test test/hotspot/jtreg/gc/shenandoah/TestSieveObjects.java only change the second `@run` at the `@test id=generational` and `@test id=aggressive`, other tests do not need to change. And all the `@run` in test test/hotspot/jtreg/gc/shenandoah/jni/TestJNIGlobalRefs.java changed from 120(default value) to 240.
> 
> Change has been verified locally on linux-x64, test-fix only, no risk.

SendaoYan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'openjdk:master' into jbs8366692
 - add timeout value for @aggressive
 - 8366692: Several gc/shenandoah tests timed out

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27052/files
  - new: https://git.openjdk.org/jdk/pull/27052/files/4d8a9601..c5e3ab20

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27052&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27052&range=00-01

  Stats: 831 lines in 41 files changed: 270 ins; 348 del; 213 mod
  Patch: https://git.openjdk.org/jdk/pull/27052.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27052/head:pull/27052

PR: https://git.openjdk.org/jdk/pull/27052

From syan at openjdk.org  Wed Sep  3 02:00:24 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 3 Sep 2025 02:00:24 GMT
Subject: RFR: 8366692: Several gc/shenandoah tests timed out
In-Reply-To: <ANyxJvBvoWfiUkp4IhAVD00Bebl7ap9TvfKYpedyxyI=.fb65fc48-5694-4373-9baa-79bcb738105c@github.com>
References: <xmal0MH4ntVgjSL8IDkxsnvEMwINQo9P493HWsweoQ4=.aa160adc-16c7-4d9d-a1a9-13438c7ec052@github.com>
 <ANyxJvBvoWfiUkp4IhAVD00Bebl7ap9TvfKYpedyxyI=.fb65fc48-5694-4373-9baa-79bcb738105c@github.com>
Message-ID: <673cwRRzBoBr9kRvan06XxfDt7HivhqtS8JbpLILKIU=.94b525a1-be3a-4ade-852a-8e0ccae787bb@github.com>

On Tue, 2 Sep 2025 18:21:14 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Seems there is some unrelated build breakage. Can we merge from `master` again before integrating?

I noticed the build breakage also. I have merge from master just now. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27052#issuecomment-3247419008

From dzhang at openjdk.org  Wed Sep  3 02:15:50 2025
From: dzhang at openjdk.org (Dingli Zhang)
Date: Wed, 3 Sep 2025 02:15:50 GMT
Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to
 conc_instruction_and_data_patch [v3]
In-Reply-To: <m8TVuzCamuC5zbdEJFrM4EWQDIKoUCOI8KsNvGeFEFU=.608bd8a2-30b5-46dc-9789-df755ad93d3b@github.com>
References: <hA8KRrjiWgdQsG7TWURlzOna1OPV0y76a55vfs5X9sU=.2e392c8e-d180-42e7-840a-60085d7426df@github.com>
 <m8TVuzCamuC5zbdEJFrM4EWQDIKoUCOI8KsNvGeFEFU=.608bd8a2-30b5-46dc-9789-df755ad93d3b@github.com>
Message-ID: <n2N9n25iDPApzcgux4YmTr5n7bpubl8exU7_yLkQxuc=.0cf80e1d-be3c-4d11-8ef1-75319ae763e4@github.com>

On Wed, 3 Sep 2025 00:37:59 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Please, review this patch to make nmethod entry barriers use `conc-instruction-and-data-patch` fence mechanics when ShenandoahGC is being used on AArch64. The patch also removes (including from JVMCI interface) the old constant that was being used only by Shenandoah on AArch64.
>> 
>> The patch has been tested with functional and performance benchmarks on AArch64. Improvements in DaCapo and Renaissance benchmarks can be as high as 30%. Maximum critical Jops in SPEC improved by ~10%.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make PPC backend to also use concurrent code patching.

LGTM, thanks!

-------------

Marked as reviewed by dzhang (Author).

PR Review: https://git.openjdk.org/jdk/pull/26999#pullrequestreview-3178728761

From syan at openjdk.org  Wed Sep  3 03:59:46 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 3 Sep 2025 03:59:46 GMT
Subject: RFR: 8366692: Several gc/shenandoah tests timed out [v2]
In-Reply-To: <BiUl44HhvTWBJZYv8MayY0_xwkzeYR8Yr9XgqZhi6Kk=.8bfddf94-e580-4ae8-881c-2afed11c7a93@github.com>
References: <xmal0MH4ntVgjSL8IDkxsnvEMwINQo9P493HWsweoQ4=.aa160adc-16c7-4d9d-a1a9-13438c7ec052@github.com>
 <BiUl44HhvTWBJZYv8MayY0_xwkzeYR8Yr9XgqZhi6Kk=.8bfddf94-e580-4ae8-881c-2afed11c7a93@github.com>
Message-ID: <EF3NiaaWPHNZglJ6qEu9rQqdT1WzXuBtZOMfedioNEg=.3468aabc-a92d-4c49-87d9-a0f9a65432a2@github.com>

On Wed, 3 Sep 2025 02:00:24 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> After JDK-8260555 set the default jtreg timeout factor to 1, then several gc/shenandoah tests run timed out with jtreg options -timeoutFactor:1. So I think it's necessary to increase the timeout value set in tests to make test run normally.
>> 
>> The actual run time consumed on my linux-x64 machine with  224 CPU core threads shows in [JDK-8366692](https://bugs.openjdk.org/browse/JDK-8366692).
>> 
>> Accodring the time statistics, the test test/hotspot/jtreg/gc/shenandoah/TestSieveObjects.java only change the second `@run` at the `@test id=generational` and `@test id=aggressive`, other tests do not need to change. And all the `@run` in test test/hotspot/jtreg/gc/shenandoah/jni/TestJNIGlobalRefs.java changed from 120(default value) to 240.
>> 
>> Change has been verified locally on linux-x64, test-fix only, no risk.
>
> SendaoYan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into jbs8366692
>  - add timeout value for @aggressive
>  - 8366692: Several gc/shenandoah tests timed out

Sorry, I missed the another timed out test gc/shenandoah/TestAllocObjects.java#aggressive.

The time statistics show that the first two '@run' consume time about 145.316 and 260.58. So I think we should change the timed out value to 240 and 480.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27052#issuecomment-3247600638

From cslucas at openjdk.org  Wed Sep  3 04:29:50 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 3 Sep 2025 04:29:50 GMT
Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to
 conc_instruction_and_data_patch [v3]
In-Reply-To: <m8TVuzCamuC5zbdEJFrM4EWQDIKoUCOI8KsNvGeFEFU=.608bd8a2-30b5-46dc-9789-df755ad93d3b@github.com>
References: <hA8KRrjiWgdQsG7TWURlzOna1OPV0y76a55vfs5X9sU=.2e392c8e-d180-42e7-840a-60085d7426df@github.com>
 <m8TVuzCamuC5zbdEJFrM4EWQDIKoUCOI8KsNvGeFEFU=.608bd8a2-30b5-46dc-9789-df755ad93d3b@github.com>
Message-ID: <efHpaPtFS3xEmSkPU_AJ4-PW5Rbok5jPb03sbL2Qn0o=.bfadbfd6-01a7-4edb-ac1a-cdf977adb819@github.com>

On Wed, 3 Sep 2025 00:37:59 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Please, review this patch to make nmethod entry barriers use `conc-instruction-and-data-patch` fence mechanics when ShenandoahGC is being used on AArch64. The patch also removes (including from JVMCI interface) the old constant that was being used only by Shenandoah on AArch64.
>> 
>> The patch has been tested with functional and performance benchmarks on AArch64. Improvements in DaCapo and Renaissance benchmarks can be as high as 30%. Maximum critical Jops in SPEC improved by ~10%.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make PPC backend to also use concurrent code patching.

@TheRealMDoerr - @shipilev mentioned in private that you have access to PPC machines; could you please help testing this patch on PPC?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26999#issuecomment-3247640930

From syan at openjdk.org  Wed Sep  3 04:47:18 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 3 Sep 2025 04:47:18 GMT
Subject: RFR: 8366692: Several gc/shenandoah tests timed out [v3]
In-Reply-To: <xmal0MH4ntVgjSL8IDkxsnvEMwINQo9P493HWsweoQ4=.aa160adc-16c7-4d9d-a1a9-13438c7ec052@github.com>
References: <xmal0MH4ntVgjSL8IDkxsnvEMwINQo9P493HWsweoQ4=.aa160adc-16c7-4d9d-a1a9-13438c7ec052@github.com>
Message-ID: <YO9G-VNuYDEGvMcIdl-SsPqpDavPerNnQYDJnzRnhbY=.37e1e4be-45c1-4dab-89ab-4cae6c6dcc99@github.com>

> Hi all,
> 
> After JDK-8260555 set the default jtreg timeout factor to 1, then several gc/shenandoah tests run timed out with jtreg options -timeoutFactor:1. So I think it's necessary to increase the timeout value set in tests to make test run normally.
> 
> The actual run time consumed on my linux-x64 machine with  224 CPU core threads shows in [JDK-8366692](https://bugs.openjdk.org/browse/JDK-8366692).
> 
> Accodring the time statistics, the test test/hotspot/jtreg/gc/shenandoah/TestSieveObjects.java only change the second `@run` at the `@test id=generational` and `@test id=aggressive`, other tests do not need to change. And all the `@run` in test test/hotspot/jtreg/gc/shenandoah/jni/TestJNIGlobalRefs.java changed from 120(default value) to 240.
> 
> Change has been verified locally on linux-x64, test-fix only, no risk.

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Update gc/shenandoah/TestAllocObjects.java#aggressive

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27052/files
  - new: https://git.openjdk.org/jdk/pull/27052/files/c5e3ab20..8b193acb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27052&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27052&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27052.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27052/head:pull/27052

PR: https://git.openjdk.org/jdk/pull/27052

From shade at openjdk.org  Wed Sep  3 04:47:18 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 3 Sep 2025 04:47:18 GMT
Subject: RFR: 8366692: Several gc/shenandoah tests timed out [v3]
In-Reply-To: <YO9G-VNuYDEGvMcIdl-SsPqpDavPerNnQYDJnzRnhbY=.37e1e4be-45c1-4dab-89ab-4cae6c6dcc99@github.com>
References: <xmal0MH4ntVgjSL8IDkxsnvEMwINQo9P493HWsweoQ4=.aa160adc-16c7-4d9d-a1a9-13438c7ec052@github.com>
 <YO9G-VNuYDEGvMcIdl-SsPqpDavPerNnQYDJnzRnhbY=.37e1e4be-45c1-4dab-89ab-4cae6c6dcc99@github.com>
Message-ID: <tE27Kv0HKUu5EgrsLbdOpjhMpAUQemDuDrxawANo7L0=.cc28422f-a552-4b91-9a00-970343838ac7@github.com>

On Wed, 3 Sep 2025 04:43:57 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> After JDK-8260555 set the default jtreg timeout factor to 1, then several gc/shenandoah tests run timed out with jtreg options -timeoutFactor:1. So I think it's necessary to increase the timeout value set in tests to make test run normally.
>> 
>> The actual run time consumed on my linux-x64 machine with  224 CPU core threads shows in [JDK-8366692](https://bugs.openjdk.org/browse/JDK-8366692).
>> 
>> Accodring the time statistics, the test test/hotspot/jtreg/gc/shenandoah/TestSieveObjects.java only change the second `@run` at the `@test id=generational` and `@test id=aggressive`, other tests do not need to change. And all the `@run` in test test/hotspot/jtreg/gc/shenandoah/jni/TestJNIGlobalRefs.java changed from 120(default value) to 240.
>> 
>> Change has been verified locally on linux-x64, test-fix only, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update gc/shenandoah/TestAllocObjects.java#aggressive

Marked as reviewed by shade (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27052#pullrequestreview-3178926540

From duke at openjdk.org  Wed Sep  3 09:42:17 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Wed, 3 Sep 2025 09:42:17 GMT
Subject: RFR: 8366778: Sort share/asm, share/gc, share/include includes
Message-ID: <AKP9Jcx9hb-p_kNHdelvSTn6bbkXhIEU8Tk9ewf65R8=.adc3821d-3bcf-4e9a-b540-fbbf8e74cc48@github.com>

Sort includes in `share/gc`, `share/asm`, `share/include` using `SortIncludes.java`, and remove some unnecessary ones. These are the last missing modules in `hotspot/share`.

Passes `tier1`.

-------------

Commit messages:
 - sort

Changes: https://git.openjdk.org/jdk/pull/27067/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27067&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366778
  Stats: 40 lines in 15 files changed: 6 ins; 33 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27067.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27067/head:pull/27067

PR: https://git.openjdk.org/jdk/pull/27067

From aboldtch at openjdk.org  Wed Sep  3 09:51:45 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 3 Sep 2025 09:51:45 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
In-Reply-To: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
Message-ID: <0CMB0g0_Ru1hF5l2NA194kD1ouNwMXrB1667Uvl9mFQ=.b6834c47-be53-41bb-b726-2e282517d6bc@github.com>

On Tue, 2 Sep 2025 08:24:10 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
> 
> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
> 
> Passes tier1-tier5 with no added problems.

Nothing obvious seems to be missing from the removal. And the changes look correct.

As @coleenp already mentioned there is even more code now that is effectively unused. Mostly to do with legacy + loom interactions. But I think it is fine to remove that in a follow up RFE.

Similarly there are some nomenclature that should be updated, but I know you have expressed wanting to do that in a follow up RFE as well.

I think it the main refactoring that are left are cleaning up the Synchronizer APIs, unifying some functions etc. 

_As for unifying LightweightSynchronizer with the ObjectSynchronizer, there might be an opportunity to let ObjectSynchronizer define the general API used by the rest of the VM to interact with the locking subsystem. And let LightweightSynchronizer contain all of the implementation. This could including moving the locking specific implementation details of relocking, deopting etc. behind an interface, decoupling them, and avoiding leaking implementation._

src/hotspot/share/runtime/basicLock.hpp line 51:

> 49:   void set_bad_metadata_deopt() { set_metadata(badDispHeaderDeopt); }
> 50: 
> 51:   static int displaced_header_offset_in_bytes() { return metadata_offset_in_bytes(); }

The `badDispHeaderDeopt` and `badDispHeaderOSR` constants should also be renamed.

src/hotspot/share/runtime/synchronizer.cpp line 634:

> 632: }
> 633: 
> 634: static intptr_t install_hash_code(Thread* current, oop obj) {

A future RFE could potentially simplify and unify this with `FastHashCode`

-------------

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27041#pullrequestreview-3179315618
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2318059361
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2318041555

From shade at openjdk.org  Wed Sep  3 10:10:42 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 3 Sep 2025 10:10:42 GMT
Subject: RFR: 8366778: Sort share/asm, share/gc, share/include includes
In-Reply-To: <AKP9Jcx9hb-p_kNHdelvSTn6bbkXhIEU8Tk9ewf65R8=.adc3821d-3bcf-4e9a-b540-fbbf8e74cc48@github.com>
References: <AKP9Jcx9hb-p_kNHdelvSTn6bbkXhIEU8Tk9ewf65R8=.adc3821d-3bcf-4e9a-b540-fbbf8e74cc48@github.com>
Message-ID: <EJhlR_44hNcxxE6RUz4na7E0mkECOidUW_dazh4euYU=.354cc13b-3941-440a-80ef-f1a59d0f8dca@github.com>

On Wed, 3 Sep 2025 09:35:24 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> These are the last missing modules in hotspot/share.

? . Onto `cpu/`, `os/` and `os_cpu/`, I guess?

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27067#pullrequestreview-3179930639

From duke at openjdk.org  Wed Sep  3 10:13:44 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Wed, 3 Sep 2025 10:13:44 GMT
Subject: RFR: 8366778: Sort share/asm, share/gc, share/include includes
In-Reply-To: <EJhlR_44hNcxxE6RUz4na7E0mkECOidUW_dazh4euYU=.354cc13b-3941-440a-80ef-f1a59d0f8dca@github.com>
References: <AKP9Jcx9hb-p_kNHdelvSTn6bbkXhIEU8Tk9ewf65R8=.adc3821d-3bcf-4e9a-b540-fbbf8e74cc48@github.com>
 <EJhlR_44hNcxxE6RUz4na7E0mkECOidUW_dazh4euYU=.354cc13b-3941-440a-80ef-f1a59d0f8dca@github.com>
Message-ID: <Nma3hADdbtql4aYbJJdgRbl101hy_losrXcl83-Mplk=.6e78b267-068a-46d5-a29b-0910071203b9@github.com>

On Wed, 3 Sep 2025 10:08:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > These are the last missing modules in hotspot/share.
> 
> ? . Onto `cpu/`, `os/` and `os_cpu/`, I guess?

??

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27067#issuecomment-3248602850

From ayang at openjdk.org  Wed Sep  3 10:16:44 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 3 Sep 2025 10:16:44 GMT
Subject: RFR: 8366778: Sort share/asm, share/gc, share/include includes
In-Reply-To: <AKP9Jcx9hb-p_kNHdelvSTn6bbkXhIEU8Tk9ewf65R8=.adc3821d-3bcf-4e9a-b540-fbbf8e74cc48@github.com>
References: <AKP9Jcx9hb-p_kNHdelvSTn6bbkXhIEU8Tk9ewf65R8=.adc3821d-3bcf-4e9a-b540-fbbf8e74cc48@github.com>
Message-ID: <xdsS0BVtZURLhWawgfQaqV9azGKISGZyf-fhedDgxc8=.cfb53662-c401-4ac1-b9a5-0a17b8f090ea@github.com>

On Wed, 3 Sep 2025 09:35:24 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> Sort includes in `share/gc`, `share/asm`, `share/include` using `SortIncludes.java`, and remove some unnecessary ones. These are the last missing modules in `hotspot/share`.
> 
> Passes `tier1`.

Marked as reviewed by ayang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27067#pullrequestreview-3179952589

From jsikstro at openjdk.org  Wed Sep  3 11:11:48 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 3 Sep 2025 11:11:48 GMT
Subject: RFR: 8366778: Sort share/asm, share/gc, share/include includes
In-Reply-To: <AKP9Jcx9hb-p_kNHdelvSTn6bbkXhIEU8Tk9ewf65R8=.adc3821d-3bcf-4e9a-b540-fbbf8e74cc48@github.com>
References: <AKP9Jcx9hb-p_kNHdelvSTn6bbkXhIEU8Tk9ewf65R8=.adc3821d-3bcf-4e9a-b540-fbbf8e74cc48@github.com>
Message-ID: <ElFjDvb2mU-v7N1MpttFjW9ROpaYDYytuZ3oQ8ESXrg=.55deefc1-6c6e-4a64-9839-23c57309bf28@github.com>

On Wed, 3 Sep 2025 09:35:24 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> Sort includes in `share/gc`, `share/asm`, `share/include` using `SortIncludes.java`, and remove some unnecessary ones. These are the last missing modules in `hotspot/share`.
> 
> Passes `tier1`.

Marked as reviewed by jsikstro (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27067#pullrequestreview-3180144068

From lmesnik at openjdk.org  Wed Sep  3 15:49:44 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 3 Sep 2025 15:49:44 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
In-Reply-To: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
Message-ID: <xBXI_F-jszTe_2APvvraAs2E5mNFDrPI96aTgTQz9q8=.1bc1774f-39f9-4c65-8f0f-6bc3644f323e@github.com>

On Tue, 2 Sep 2025 08:24:10 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
> 
> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
> 
> Passes tier1-tier5 with no added problems.

svc part looks good.

-------------

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27041#pullrequestreview-3181274100

From duke at openjdk.org  Wed Sep  3 15:54:22 2025
From: duke at openjdk.org (pf0n)
Date: Wed, 3 Sep 2025 15:54:22 GMT
Subject: RFR: 8366122: Shenandoah: Implement efficient support for object count
 after gc events
Message-ID: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>

### Summary

The new implementation of ObjectCountAfterGC for Shenandoah piggybacks off of the existing marking phases and records strongly marked objects in a histogram. If the event is disabled, the original marking closures are used. When enabled new mark-and-count closures are used by the worker threads. Each worker thread updates its local histogram as it marks an object. These local histograms are merged at the conclusion of the marking phase under a mutex. The event is emitted outside a safepoint. Because (most) Shenandoah's marking is done concurrently, so is the object counting work.

### Performance
The performance test were ran using the Extremem benchmark on a default and stress workload. (will edit this section to include data after average time and test for GenShen)

#### Default workload:
ObjectCountAfterGC disabled (master branch):
`[807.216s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      264 us)`
`[807.216s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       91 us)`
`[807.216s][info][gc,stats    ] Concurrent Mark Roots          =    0.041 s (a =     4099 us)`
`[807.216s][info][gc,stats    ] Concurrent Marking             =    1.660 s (a =   166035 us)`
`[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
`[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
`[807.216s][info][gc,stats    ] Pause Final Mark (N)           =    0.004 s (a =      357 us)`

ObjectCountAfterGC disabled (feature branch):
`[807.104s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      302 us)`
`[807.104s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       92 us) `
`[807.104s][info][gc,stats    ] Concurrent Mark Roots          =    0.048 s (a =     4827 us)`
`[807.104s][info][gc,stats    ] Concurrent Marking             =    1.666 s (a =   166638 us) `
`[807.104s][info][gc,stats    ] Pause Final Mark (G)           =    0.006 s (a =      603 us)`
`[807.104s][info][gc,stats    ] Pause Final Mark (N)           =    0.005 s (a =      516 us)`

ObjectCountAfterGC enabled (feature branch)
`[807.299s][info][gc,stats    ] Pause Init Mark (G)            =    0.002 s (a =      227 us)`
`[807.299s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       89 us) `
`[807.299s][info][gc,stats    ] Concurrent Mark Roots          =    0.053 s (a =     5279 us)`
`[807.299s][info][gc,stats    ] Concurrent Marking             =    1.676 s (a =   167595 us)`
`[807.299s][info][gc,stats    ] Pause Final Mark (G)           =    0.005 s (a =      537 us)`
`[807.299s][info][gc,stats    ] Pause Final Mark (N)           =    0.004 s (a =      430 us)`

#### Stress workload:
ObjectCountAfterGC disabled (master branch):
`[1213.361s][info][gc,stats    ] Pause Init Mark (G)            =    0.023 s (a =      232 us)`
`[1213.361s][info][gc,stats    ] Pause Init Mark (N)            =    0.009 s (a =       85 us)`
`[1213.361s][info][gc,stats    ] Concurrent Mark Roots          =    0.252 s (a =     2521 us)`
`[1213.361s][info][gc,stats    ] Concurrent Marking             =   17.635 s (a =   176354 us) `
`[1213.361s][info][gc,stats    ] Pause Final Mark (G)           =    0.065 s (a =      651 us)`
`[1213.361s][info][gc,stats    ] Pause Final Mark (N)           =    0.049 s (a =      493 us)`

ObjectCountAfterGC disabled (feature branch):
`[1213.626s][info][gc,stats    ] Pause Init Mark (G)            =    0.023 s (a =      234 us)`
`[1213.626s][info][gc,stats    ] Pause Init Mark (N)            =    0.009 s (a =       86 us)`
`[1213.626s][info][gc,stats    ] Concurrent Mark Roots          =    0.265 s (a =     2645 us)`
`[1213.626s][info][gc,stats    ] Concurrent Marking             =   17.747 s (a =   177468 us)`
`[1213.626s][info][gc,stats    ] Pause Final Mark (G)           =    0.043 s (a =      431 us)`
`[1213.626s][info][gc,stats    ] Pause Final Mark (N)           =    0.036 s (a =      362 us)`

ObjectCountAfterGC enabled (feature branch):
`[1213.699s][info][gc,stats    ] Pause Init Mark (G)            =    0.020 s (a =      202 us) `
`[1213.699s][info][gc,stats    ] Pause Init Mark (N)            =    0.008 s (a =       83 us)`
`[1213.699s][info][gc,stats    ] Concurrent Mark Roots          =    0.340 s (a =     3404 us)`
`[1213.699s][info][gc,stats    ] Concurrent Marking             =   17.929 s (a =   179289 us)`
`[1213.699s][info][gc,stats    ] Pause Final Mark (G)           =    0.049 s (a =      492 us)`
`[1213.699s][info][gc,stats    ] Pause Final Mark (N)           =    0.040 s (a =      405 us)`

### Testing
Tested changes with GHA, jtreg tier1 JFR, and hotspot_gc. CodePipeline internal perf and stress test succeeded.

-------------

Commit messages:
 - Changed comment, included another guard
 - Removing whitespace
 - Merge master
 - Merge master
 - Merge branch 'master' of https://github.com/openjdk/jdk into test/shen-aggregate-closure
 - Comment on why return value was changed to bool
 - Deleted objectCountEventSender.inline.hpp
 - Merging master
 - Reverting changes back to original state for some files
 - Merge branch '8366122/shen-object-count-after-gc' into test/shen-aggregate-closure
 - ... and 121 more: https://git.openjdk.org/jdk/compare/efb81daf...9552c62b

Changes: https://git.openjdk.org/jdk/pull/26977/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26977&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366122
  Stats: 307 lines in 24 files changed: 252 ins; 28 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/26977.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26977/head:pull/26977

PR: https://git.openjdk.org/jdk/pull/26977

From kdnilsen at openjdk.org  Wed Sep  3 15:54:22 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 3 Sep 2025 15:54:22 GMT
Subject: RFR: 8366122: Shenandoah: Implement efficient support for object
 count after gc events
In-Reply-To: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
Message-ID: <Ag8YUYFFc19FEHoCz3qtzErmImHLsfsPy7DLJ5uwKtI=.6a0d4c07-6cf6-4da7-9893-eea75091167e@github.com>

On Thu, 28 Aug 2025 01:30:39 GMT, pf0n <duke at openjdk.org> wrote:

> ### Summary
> 
> The new implementation of ObjectCountAfterGC for Shenandoah piggybacks off of the existing marking phases and records strongly marked objects in a histogram. If the event is disabled, the original marking closures are used. When enabled new mark-and-count closures are used by the worker threads. Each worker thread updates its local histogram as it marks an object. These local histograms are merged at the conclusion of the marking phase under a mutex. The event is emitted outside a safepoint. Because (most) Shenandoah's marking is done concurrently, so is the object counting work.
> 
> ### Performance
> The performance test were ran using the Extremem benchmark on a default and stress workload. (will edit this section to include data after average time and test for GenShen)
> 
> #### Default workload:
> ObjectCountAfterGC disabled (master branch):
> `[807.216s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      264 us)`
> `[807.216s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       91 us)`
> `[807.216s][info][gc,stats    ] Concurrent Mark Roots          =    0.041 s (a =     4099 us)`
> `[807.216s][info][gc,stats    ] Concurrent Marking             =    1.660 s (a =   166035 us)`
> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
> `[807.216s][info][gc,stats    ] Pause Final Mark (N)           =    0.004 s (a =      357 us)`
> 
> ObjectCountAfterGC disabled (feature branch):
> `[807.104s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      302 us)`
> `[807.104s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       92 us) `
> `[807.104s][info][gc,stats    ] Concurrent Mark Roots          =    0.048 s (a =     4827 us)`
> `[807.104s][info][gc,stats    ] Concurrent Marking             =    1.666 s (a =   166638 us) `
> `[807.104s][info][gc,stats    ] Pause Final Mark (G)           =    0.006 s (a =      603 us)`
> `[807.104s][info][gc,stats    ] Pause Final Mark (N)           =    0.005 s (a =      516 us)`
> 
> ObjectCountAfterGC enabled (feature branch)
> `[807.299s][info][gc,stats    ] Pause Init Mark (G)            =    0.002 s (a =      227 us)`
> `[807.299s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       89 us) `
> `[807.299s][info][gc,stats    ] Concurrent Mark Roots          =    0.053 s (a =     5279 us)`
> `[807.299s][info][gc,st...

I concur with comments by Ramki.

Also, I wonder if you can add to the summary overview a description of how much additional memory is required to enable concurrent object counting.  I believe there is a new thread-local table (how large is this?) for each GC worker thread.  I think service threads do not need this table.  Can you clarify?

The performance numbers quoted in the performance summary above are for Shennadoah satb mode, or for generational mode?  Maybe both should be reported.

src/hotspot/share/gc/shared/gcTrace.inline.hpp line 12:

> 10: 
> 11: // The ObjectCountEventSenderClosure will determine if only the ObjectCount
> 12: // event will be emitted instead of ObjectCountAfterGC. If false, then both

If "what" is false?  This comment is not clear.  Are you speaking of the SeparateEventEmission template parameter?

I think the use of future-tense "will" also makes this comment confusing.  Can you write this in present tense?

-------------

PR Review: https://git.openjdk.org/jdk/pull/26977#pullrequestreview-3166929412
PR Comment: https://git.openjdk.org/jdk/pull/26977#issuecomment-3235270167
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2308805732

From wkemper at openjdk.org  Wed Sep  3 15:54:23 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 3 Sep 2025 15:54:23 GMT
Subject: RFR: 8366122: Shenandoah: Implement efficient support for object
 count after gc events
In-Reply-To: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
Message-ID: <OPZ8vhzy70VNYJu-pVgX-3Te33auMyDb3330R_s3F0I=.1a2a1742-fc26-4735-9847-18947f48c7bf@github.com>

On Thu, 28 Aug 2025 01:30:39 GMT, pf0n <duke at openjdk.org> wrote:

> ### Summary
> 
> The new implementation of ObjectCountAfterGC for Shenandoah piggybacks off of the existing marking phases and records strongly marked objects in a histogram. If the event is disabled, the original marking closures are used. When enabled new mark-and-count closures are used by the worker threads. Each worker thread updates its local histogram as it marks an object. These local histograms are merged at the conclusion of the marking phase under a mutex. The event is emitted outside a safepoint. Because (most) Shenandoah's marking is done concurrently, so is the object counting work.
> 
> ### Performance
> The performance test were ran using the Extremem benchmark on a default and stress workload. (will edit this section to include data after average time and test for GenShen)
> 
> #### Default workload:
> ObjectCountAfterGC disabled (master branch):
> `[807.216s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      264 us)`
> `[807.216s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       91 us)`
> `[807.216s][info][gc,stats    ] Concurrent Mark Roots          =    0.041 s (a =     4099 us)`
> `[807.216s][info][gc,stats    ] Concurrent Marking             =    1.660 s (a =   166035 us)`
> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
> `[807.216s][info][gc,stats    ] Pause Final Mark (N)           =    0.004 s (a =      357 us)`
> 
> ObjectCountAfterGC disabled (feature branch):
> `[807.104s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      302 us)`
> `[807.104s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       92 us) `
> `[807.104s][info][gc,stats    ] Concurrent Mark Roots          =    0.048 s (a =     4827 us)`
> `[807.104s][info][gc,stats    ] Concurrent Marking             =    1.666 s (a =   166638 us) `
> `[807.104s][info][gc,stats    ] Pause Final Mark (G)           =    0.006 s (a =      603 us)`
> `[807.104s][info][gc,stats    ] Pause Final Mark (N)           =    0.005 s (a =      516 us)`
> 
> ObjectCountAfterGC enabled (feature branch)
> `[807.299s][info][gc,stats    ] Pause Init Mark (G)            =    0.002 s (a =      227 us)`
> `[807.299s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       89 us) `
> `[807.299s][info][gc,stats    ] Concurrent Mark Roots          =    0.053 s (a =     5279 us)`
> `[807.299s][info][gc,st...

Left a few superficial suggestions. My big question is what work remains for this event to also work with the generational mode?

src/hotspot/share/gc/shared/gcTrace.hpp line 136:

> 134:   void report_gc_reference_stats(const ReferenceProcessorStats& rp) const;
> 135:   void report_object_count_after_gc(BoolObjectClosure* object_filter, WorkerThreads* workers) NOT_SERVICES_RETURN;
> 136:   // Report object count by not performing a heap inspection. This method will

s/by not/without

src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 179:

> 177:   // Use object counting closure if ObjectCount or ObjectCountAfterGC event is enabled.
> 178:   const bool object_count_enabled = ObjectCountEventSender::should_send_event();
> 179:   if (object_count_enabled && !ShenandoahHeap::heap()->mode()->is_generational()) {

Can the generational mode support this? It can also perform a _global_ collection.

src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 130:

> 128:       // Create the KlassInfoTable for Shenandoah only if JFR is enabled.
> 129: #if INCLUDE_JFR
> 130:       KlassInfoTable cit(false);

Might consider a `CADR` helper class here (Constructor Acquires, Destructor Releases). There are a lot of lines of code between the two `set_cit` calls (and the second one isn't guarded by `INCLUDE_JFR`).

src/hotspot/share/memory/heapInspection.hpp line 33:

> 31: #include "oops/objArrayOop.hpp"
> 32: #include "oops/oop.hpp"
> 33: #include "runtime/mutex.hpp"

Does this need to be in the header?

src/hotspot/share/runtime/mutexLocker.hpp line 90:

> 88: extern Monitor* Notify_lock;                     // a lock used to synchronize the start-up of the vm
> 89: extern Mutex*   ExceptionCache_lock;             // a lock used to synchronize exception cache updates
> 90: extern Mutex*   TableMerge_lock;                 // a lock used to synchronize merging a thread-local table into a global table

Might call this `ObjectCountMerge_lock` and describe its usage as `merging a thread local object count`. There are many `Tables` in the JVM (SymbolTable, InternedStrings, etc.).

test/jdk/jdk/jfr/event/gc/objectcount/TestObjectCountAfterGCEventWithShenandoah.java line 11:

> 9:  *           & vm.opt.ExplicitGCInvokesConcurrent != true
> 10:  * @library /test/lib /test/jdk
> 11:  * @run main/othervm -XX:+UnlockExperimentalVMOptions -XX:-UseFastUnorderedTimeStamps -XX:+UseShenandoahGC -XX:MarkSweepDeadRatio=0 -XX:-UseCompressedOops -XX:-UseCompressedClassPointers -XX:+IgnoreUnrecognizedVMOptions jdk.jfr.event.gc.objectcount.TestObjectCountAfterGCEventWithShenandoah

Are all of these flags necessary to run this test? Can we pare any unnecessary options?

-------------

Changes requested by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26977#pullrequestreview-3178372422
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2317339492
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2317344826
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2317348710
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2317355707
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2317358657
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2317360739

From ysr at openjdk.org  Wed Sep  3 15:54:24 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 3 Sep 2025 15:54:24 GMT
Subject: RFR: 8366122: Shenandoah: Implement efficient support for object
 count after gc events
In-Reply-To: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
Message-ID: <SybYT5LlWxR7Xj8RIG8Q5FA0oVKQXZ29HqR9C482bQQ=.31b680fb-2ae5-4401-9838-032a22c77451@github.com>

On Thu, 28 Aug 2025 01:30:39 GMT, pf0n <duke at openjdk.org> wrote:

> ### Summary
> 
> The new implementation of ObjectCountAfterGC for Shenandoah piggybacks off of the existing marking phases and records strongly marked objects in a histogram. If the event is disabled, the original marking closures are used. When enabled new mark-and-count closures are used by the worker threads. Each worker thread updates its local histogram as it marks an object. These local histograms are merged at the conclusion of the marking phase under a mutex. The event is emitted outside a safepoint. Because (most) Shenandoah's marking is done concurrently, so is the object counting work.
> 
> ### Performance
> The performance test were ran using the Extremem benchmark on a default and stress workload. (will edit this section to include data after average time and test for GenShen)
> 
> #### Default workload:
> ObjectCountAfterGC disabled (master branch):
> `[807.216s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      264 us)`
> `[807.216s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       91 us)`
> `[807.216s][info][gc,stats    ] Concurrent Mark Roots          =    0.041 s (a =     4099 us)`
> `[807.216s][info][gc,stats    ] Concurrent Marking             =    1.660 s (a =   166035 us)`
> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
> `[807.216s][info][gc,stats    ] Pause Final Mark (N)           =    0.004 s (a =      357 us)`
> 
> ObjectCountAfterGC disabled (feature branch):
> `[807.104s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      302 us)`
> `[807.104s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       92 us) `
> `[807.104s][info][gc,stats    ] Concurrent Mark Roots          =    0.048 s (a =     4827 us)`
> `[807.104s][info][gc,stats    ] Concurrent Marking             =    1.666 s (a =   166638 us) `
> `[807.104s][info][gc,stats    ] Pause Final Mark (G)           =    0.006 s (a =      603 us)`
> `[807.104s][info][gc,stats    ] Pause Final Mark (N)           =    0.005 s (a =      516 us)`
> 
> ObjectCountAfterGC enabled (feature branch)
> `[807.299s][info][gc,stats    ] Pause Init Mark (G)            =    0.002 s (a =      227 us)`
> `[807.299s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       89 us) `
> `[807.299s][info][gc,stats    ] Concurrent Mark Roots          =    0.053 s (a =     5279 us)`
> `[807.299s][info][gc,st...

@pf0n : 

1. For the performance numbers, use the final summaries (in the gc log) of quartile and range of time distributions of the pauses and the phases to better reflect the impact on collections throughout the entire run, rather than for specific spot collections.
2. For completeness in the PR description and to help reviewers, please comment upon whether, when the event is enabled, the counting closures are used also for collections other than concurrent ones and where the events are emitted in those cases.

Thanks!

src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 129:

> 127:     if (gc_requested) {
> 128:       // Create the KlassInfoTable for Shenandoah only if JFR is enabled.
> 129:       #if INCLUDE_JFR

Here and elsewhere:
1. for single line pre-proc directives, consider the use of `JFR_ONLY()`.
2. For multi-line pre-proc directives, unindent all the way to the zeroth column, in keeping with hotspot style precedent, even though newer pre-processors accept indented directives.

src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 232:

> 230:   volatile size_t _committed;
> 231:   shenandoah_padding(1);
> 232:   KlassInfoTable* _cit;

Move the comment from line 257 below to before this place.

src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 256:

> 254:   void set_soft_max_capacity(size_t v);
> 255: 
> 256:   // Create Shenandoah's KlassInfoTable.

Not create, but set?

src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 260:

> 258:   inline void set_cit(KlassInfoTable* cit);
> 259: 
> 260:   // Return Shenandoah's KlassInfoTable.

Put these together and use one comment like:


// Setter & accessor for class histogram

src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 653:

> 651: inline void ShenandoahHeap::set_cit(KlassInfoTable* cit) {
> 652:   assert((_cit == nullptr && cit != nullptr) ||
> 653:     (_cit != nullptr && cit == nullptr), "Initialize once & clear once");

The assert message isn't accurate for your current usage. Suggest splitting into two asserts with a suitable message:

assert(_cit == nullptr || cit == nullptr, "Overwriting an existing histogram");
assert(_cit != nullptr || cit != nullptr, "Already cleared");

src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 658:

> 656: 
> 657: inline KlassInfoTable* ShenandoahHeap::get_cit() {
> 658:   assert(_cit != nullptr, "KlassInfoTable for Shenandoah should be initialized");

Change the message to: "KlassInfoTable is null"
(suggestion is to avoid "initialized" here, since the value is repeatedly toggled from a pointer to stack allocated klass info table to null and back).

Essentially the heap is used as a post-office-box to pass a handle to a stack allocated object to worker threads using the object.

src/hotspot/share/gc/shenandoah/shenandoahMark.cpp line 72:

> 70:     mark_loop_work<Closure, GENERATION, CANCELLABLE, STRING_DEDUP>(&cl, ld, w, t, req);
> 71:   } else {
> 72:     #if INCLUDE_JFR

unindent (left-justify to 0th column)

src/hotspot/share/gc/shenandoah/shenandoahMark.hpp line 60:

> 58: public:
> 59:   template<class T, ShenandoahGenerationType GENERATION>
> 60:   static inline bool mark_through_ref(T* p, ShenandoahObjToScanQueue* q, ShenandoahObjToScanQueue* old_q, ShenandoahMarkingContext* const mark_context, bool weak);

document the semantics of the method's return value here and everywhere where a bool return replaces a previously void return.

src/hotspot/share/runtime/mutexLocker.hpp line 90:

> 88: extern Monitor* Notify_lock;                     // a lock used to synchronize the start-up of the vm
> 89: extern Mutex*   ExceptionCache_lock;             // a lock used to synchronize exception cache updates
> 90: extern Mutex*   TableMerge_lock;                 // a lock used to synchronize merging of thread-local KlassInfoTables

nit: `... merging a thread-local into a global table`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26977#issuecomment-3235400211
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2308906242
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2308907269
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2308907857
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2308910727
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2308919955
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2308923148
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2308926296
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2308929362
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2308937729

From duke at openjdk.org  Wed Sep  3 15:54:24 2025
From: duke at openjdk.org (pf0n)
Date: Wed, 3 Sep 2025 15:54:24 GMT
Subject: RFR: 8366122: Shenandoah: Implement efficient support for object
 count after gc events
In-Reply-To: <Ag8YUYFFc19FEHoCz3qtzErmImHLsfsPy7DLJ5uwKtI=.6a0d4c07-6cf6-4da7-9893-eea75091167e@github.com>
References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
 <Ag8YUYFFc19FEHoCz3qtzErmImHLsfsPy7DLJ5uwKtI=.6a0d4c07-6cf6-4da7-9893-eea75091167e@github.com>
Message-ID: <LSyHUVUcJ2sDAvb3MTi5tF06TB5LALX_38NlF42Om9Y=.b934e163-7478-4138-b45d-c0c7aecc7958@github.com>

On Thu, 28 Aug 2025 23:49:20 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> ### Summary
>> 
>> The new implementation of ObjectCountAfterGC for Shenandoah piggybacks off of the existing marking phases and records strongly marked objects in a histogram. If the event is disabled, the original marking closures are used. When enabled new mark-and-count closures are used by the worker threads. Each worker thread updates its local histogram as it marks an object. These local histograms are merged at the conclusion of the marking phase under a mutex. The event is emitted outside a safepoint. Because (most) Shenandoah's marking is done concurrently, so is the object counting work.
>> 
>> ### Performance
>> The performance test were ran using the Extremem benchmark on a default and stress workload. (will edit this section to include data after average time and test for GenShen)
>> 
>> #### Default workload:
>> ObjectCountAfterGC disabled (master branch):
>> `[807.216s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      264 us)`
>> `[807.216s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       91 us)`
>> `[807.216s][info][gc,stats    ] Concurrent Mark Roots          =    0.041 s (a =     4099 us)`
>> `[807.216s][info][gc,stats    ] Concurrent Marking             =    1.660 s (a =   166035 us)`
>> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
>> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
>> `[807.216s][info][gc,stats    ] Pause Final Mark (N)           =    0.004 s (a =      357 us)`
>> 
>> ObjectCountAfterGC disabled (feature branch):
>> `[807.104s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      302 us)`
>> `[807.104s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       92 us) `
>> `[807.104s][info][gc,stats    ] Concurrent Mark Roots          =    0.048 s (a =     4827 us)`
>> `[807.104s][info][gc,stats    ] Concurrent Marking             =    1.666 s (a =   166638 us) `
>> `[807.104s][info][gc,stats    ] Pause Final Mark (G)           =    0.006 s (a =      603 us)`
>> `[807.104s][info][gc,stats    ] Pause Final Mark (N)           =    0.005 s (a =      516 us)`
>> 
>> ObjectCountAfterGC enabled (feature branch)
>> `[807.299s][info][gc,stats    ] Pause Init Mark (G)            =    0.002 s (a =      227 us)`
>> `[807.299s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       89 us) `
>> `[807.299s][info][gc,stats    ] Concurrent Mark Roots       ...
>
> src/hotspot/share/gc/shared/gcTrace.inline.hpp line 12:
> 
>> 10: 
>> 11: // The ObjectCountEventSenderClosure will determine if only the ObjectCount
>> 12: // event will be emitted instead of ObjectCountAfterGC. If false, then both
> 
> If "what" is false?  This comment is not clear.  Are you speaking of the SeparateEventEmission template parameter?
> 
> I think the use of future-tense "will" also makes this comment confusing.  Can you write this in present tense?

I'll remove this template parameter, since it won't be needed for the ObjectCountAfterGC PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2312857523

From duke at openjdk.org  Wed Sep  3 15:54:24 2025
From: duke at openjdk.org (pf0n)
Date: Wed, 3 Sep 2025 15:54:24 GMT
Subject: RFR: 8366122: Shenandoah: Implement efficient support for object
 count after gc events
In-Reply-To: <OPZ8vhzy70VNYJu-pVgX-3Te33auMyDb3330R_s3F0I=.1a2a1742-fc26-4735-9847-18947f48c7bf@github.com>
References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
 <OPZ8vhzy70VNYJu-pVgX-3Te33auMyDb3330R_s3F0I=.1a2a1742-fc26-4735-9847-18947f48c7bf@github.com>
Message-ID: <espHeZfIfmymTBYI7AuHKpolClx2KVpFND7dFQMrqko=.e465c236-8d2c-42ec-8cb8-f1a49f258274@github.com>

On Tue, 2 Sep 2025 22:46:52 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> ### Summary
>> 
>> The new implementation of ObjectCountAfterGC for Shenandoah piggybacks off of the existing marking phases and records strongly marked objects in a histogram. If the event is disabled, the original marking closures are used. When enabled new mark-and-count closures are used by the worker threads. Each worker thread updates its local histogram as it marks an object. These local histograms are merged at the conclusion of the marking phase under a mutex. The event is emitted outside a safepoint. Because (most) Shenandoah's marking is done concurrently, so is the object counting work.
>> 
>> ### Performance
>> The performance test were ran using the Extremem benchmark on a default and stress workload. (will edit this section to include data after average time and test for GenShen)
>> 
>> #### Default workload:
>> ObjectCountAfterGC disabled (master branch):
>> `[807.216s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      264 us)`
>> `[807.216s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       91 us)`
>> `[807.216s][info][gc,stats    ] Concurrent Mark Roots          =    0.041 s (a =     4099 us)`
>> `[807.216s][info][gc,stats    ] Concurrent Marking             =    1.660 s (a =   166035 us)`
>> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
>> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
>> `[807.216s][info][gc,stats    ] Pause Final Mark (N)           =    0.004 s (a =      357 us)`
>> 
>> ObjectCountAfterGC disabled (feature branch):
>> `[807.104s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      302 us)`
>> `[807.104s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       92 us) `
>> `[807.104s][info][gc,stats    ] Concurrent Mark Roots          =    0.048 s (a =     4827 us)`
>> `[807.104s][info][gc,stats    ] Concurrent Marking             =    1.666 s (a =   166638 us) `
>> `[807.104s][info][gc,stats    ] Pause Final Mark (G)           =    0.006 s (a =      603 us)`
>> `[807.104s][info][gc,stats    ] Pause Final Mark (N)           =    0.005 s (a =      516 us)`
>> 
>> ObjectCountAfterGC enabled (feature branch)
>> `[807.299s][info][gc,stats    ] Pause Init Mark (G)            =    0.002 s (a =      227 us)`
>> `[807.299s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       89 us) `
>> `[807.299s][info][gc,stats    ] Concurrent Mark Roots       ...
>
> src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 179:
> 
>> 177:   // Use object counting closure if ObjectCount or ObjectCountAfterGC event is enabled.
>> 178:   const bool object_count_enabled = ObjectCountEventSender::should_send_event();
>> 179:   if (object_count_enabled && !ShenandoahHeap::heap()->mode()->is_generational()) {
> 
> Can the generational mode support this? It can also perform a _global_ collection.

It could be possible to extend the object counting closure for GenShen. I would have to look more deep into where the closure can be used.

> src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 130:
> 
>> 128:       // Create the KlassInfoTable for Shenandoah only if JFR is enabled.
>> 129: #if INCLUDE_JFR
>> 130:       KlassInfoTable cit(false);
> 
> Might consider a `CADR` helper class here (Constructor Acquires, Destructor Releases). There are a lot of lines of code between the two `set_cit` calls (and the second one isn't guarded by `INCLUDE_JFR`).

I'll look into that. Thanks for pointing out the unguarded `set_cit`.

> src/hotspot/share/memory/heapInspection.hpp line 33:
> 
>> 31: #include "oops/objArrayOop.hpp"
>> 32: #include "oops/oop.hpp"
>> 33: #include "runtime/mutex.hpp"
> 
> Does this need to be in the header?

I had an error in GHA during my early implementation, so I included that header. I'll remove and test to see if it is needed or not.

> test/jdk/jdk/jfr/event/gc/objectcount/TestObjectCountAfterGCEventWithShenandoah.java line 11:
> 
>> 9:  *           & vm.opt.ExplicitGCInvokesConcurrent != true
>> 10:  * @library /test/lib /test/jdk
>> 11:  * @run main/othervm -XX:+UnlockExperimentalVMOptions -XX:-UseFastUnorderedTimeStamps -XX:+UseShenandoahGC -XX:MarkSweepDeadRatio=0 -XX:-UseCompressedOops -XX:-UseCompressedClassPointers -XX:+IgnoreUnrecognizedVMOptions jdk.jfr.event.gc.objectcount.TestObjectCountAfterGCEventWithShenandoah
> 
> Are all of these flags necessary to run this test? Can we pare any unnecessary options?

All of the collectors that test for the ObjectCountAfterGC event uses these flags. I thought it would be best to keep it consistent for the Shenandoah test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2317633120
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2317630478
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2317545276
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2317555401

From duke at openjdk.org  Wed Sep  3 15:54:25 2025
From: duke at openjdk.org (pf0n)
Date: Wed, 3 Sep 2025 15:54:25 GMT
Subject: RFR: 8366122: Shenandoah: Implement efficient support for object
 count after gc events
In-Reply-To: <espHeZfIfmymTBYI7AuHKpolClx2KVpFND7dFQMrqko=.e465c236-8d2c-42ec-8cb8-f1a49f258274@github.com>
References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
 <OPZ8vhzy70VNYJu-pVgX-3Te33auMyDb3330R_s3F0I=.1a2a1742-fc26-4735-9847-18947f48c7bf@github.com>
 <espHeZfIfmymTBYI7AuHKpolClx2KVpFND7dFQMrqko=.e465c236-8d2c-42ec-8cb8-f1a49f258274@github.com>
Message-ID: <UOoyzVf5nROGoxZimRWNdikzha7DV4T-BCObVg3KBhc=.30fdb10d-ad36-420e-8b1f-0b9e8c18bfb5@github.com>

On Wed, 3 Sep 2025 02:58:42 GMT, pf0n <duke at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 179:
>> 
>>> 177:   // Use object counting closure if ObjectCount or ObjectCountAfterGC event is enabled.
>>> 178:   const bool object_count_enabled = ObjectCountEventSender::should_send_event();
>>> 179:   if (object_count_enabled && !ShenandoahHeap::heap()->mode()->is_generational()) {
>> 
>> Can the generational mode support this? It can also perform a _global_ collection.
>
> It could be possible to extend the object counting closure for GenShen. I would have to look more deep into where the closure can be used.

GenShen shares the same marking closure as Shenandoah, but it is templatized differently. At surface level, we would just have to replace the marking closure used for the global collection with the object counting closure, but there might be other work to be done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2317645883

From duke at openjdk.org  Wed Sep  3 16:49:03 2025
From: duke at openjdk.org (pf0n)
Date: Wed, 3 Sep 2025 16:49:03 GMT
Subject: RFR: 8366122: Shenandoah: Implement efficient support for object
 count after gc events [v2]
In-Reply-To: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
Message-ID: <LLDq2GcPWoFwS-GU_fCeoKJX5RP0r5aaw2ux6NgfmB4=.6ebf7efc-67a3-4764-befe-f17a7a0d2b29@github.com>

> ### Summary
> 
> The new implementation of ObjectCountAfterGC for Shenandoah piggybacks off of the existing marking phases and records strongly marked objects in a histogram. If the event is disabled, the original marking closures are used. When enabled new mark-and-count closures are used by the worker threads. Each worker thread updates its local histogram as it marks an object. These local histograms are merged at the conclusion of the marking phase under a mutex. The event is emitted outside a safepoint. Because (most) Shenandoah's marking is done concurrently, so is the object counting work.
> 
> ### Performance
> The performance test were ran using the Extremem benchmark on a default and stress workload. (will edit this section to include data after average time and test for GenShen)
> 
> #### Default workload:
> ObjectCountAfterGC disabled (master branch):
> `[807.216s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      264 us)`
> `[807.216s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       91 us)`
> `[807.216s][info][gc,stats    ] Concurrent Mark Roots          =    0.041 s (a =     4099 us)`
> `[807.216s][info][gc,stats    ] Concurrent Marking             =    1.660 s (a =   166035 us)`
> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
> `[807.216s][info][gc,stats    ] Pause Final Mark (N)           =    0.004 s (a =      357 us)`
> 
> ObjectCountAfterGC disabled (feature branch):
> `[807.104s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      302 us)`
> `[807.104s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       92 us) `
> `[807.104s][info][gc,stats    ] Concurrent Mark Roots          =    0.048 s (a =     4827 us)`
> `[807.104s][info][gc,stats    ] Concurrent Marking             =    1.666 s (a =   166638 us) `
> `[807.104s][info][gc,stats    ] Pause Final Mark (G)           =    0.006 s (a =      603 us)`
> `[807.104s][info][gc,stats    ] Pause Final Mark (N)           =    0.005 s (a =      516 us)`
> 
> ObjectCountAfterGC enabled (feature branch)
> `[807.299s][info][gc,stats    ] Pause Init Mark (G)            =    0.002 s (a =      227 us)`
> `[807.299s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       89 us) `
> `[807.299s][info][gc,stats    ] Concurrent Mark Roots          =    0.053 s (a =     5279 us)`
> `[807.299s][info][gc,st...

pf0n has updated the pull request incrementally with two additional commits since the last revision:

 - Using JFR_ONLY
 - Changed comment, included another guard

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26977/files
  - new: https://git.openjdk.org/jdk/pull/26977/files/9552c62b..6a3c6318

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26977&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26977&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26977.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26977/head:pull/26977

PR: https://git.openjdk.org/jdk/pull/26977

From wkemper at openjdk.org  Wed Sep  3 20:15:43 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 3 Sep 2025 20:15:43 GMT
Subject: RFR: 8366692: Several gc/shenandoah tests timed out [v3]
In-Reply-To: <YO9G-VNuYDEGvMcIdl-SsPqpDavPerNnQYDJnzRnhbY=.37e1e4be-45c1-4dab-89ab-4cae6c6dcc99@github.com>
References: <xmal0MH4ntVgjSL8IDkxsnvEMwINQo9P493HWsweoQ4=.aa160adc-16c7-4d9d-a1a9-13438c7ec052@github.com>
 <YO9G-VNuYDEGvMcIdl-SsPqpDavPerNnQYDJnzRnhbY=.37e1e4be-45c1-4dab-89ab-4cae6c6dcc99@github.com>
Message-ID: <uCE45C1stpZ9ewlMgAWC0al165ia9b9J6TLVSSrdA4M=.1b5d3ada-9b51-4388-9871-d6d59e365bfa@github.com>

On Wed, 3 Sep 2025 04:47:18 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> After JDK-8260555 set the default jtreg timeout factor to 1, then several gc/shenandoah tests run timed out with jtreg options -timeoutFactor:1. So I think it's necessary to increase the timeout value set in tests to make test run normally.
>> 
>> The actual run time consumed on my linux-x64 machine with  224 CPU core threads shows in [JDK-8366692](https://bugs.openjdk.org/browse/JDK-8366692).
>> 
>> Accodring the time statistics, the test test/hotspot/jtreg/gc/shenandoah/TestSieveObjects.java only change the second `@run` at the `@test id=generational` and `@test id=aggressive`, other tests do not need to change. And all the `@run` in test test/hotspot/jtreg/gc/shenandoah/jni/TestJNIGlobalRefs.java changed from 120(default value) to 240.
>> 
>> Change has been verified locally on linux-x64, test-fix only, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update gc/shenandoah/TestAllocObjects.java#aggressive

Thank you!

-------------

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27052#pullrequestreview-3182282872

From ysr at openjdk.org  Thu Sep  4 00:15:49 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 4 Sep 2025 00:15:49 GMT
Subject: RFR: 8366122: Shenandoah: Implement efficient support for object
 count after gc events [v2]
In-Reply-To: <espHeZfIfmymTBYI7AuHKpolClx2KVpFND7dFQMrqko=.e465c236-8d2c-42ec-8cb8-f1a49f258274@github.com>
References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
 <OPZ8vhzy70VNYJu-pVgX-3Te33auMyDb3330R_s3F0I=.1a2a1742-fc26-4735-9847-18947f48c7bf@github.com>
 <espHeZfIfmymTBYI7AuHKpolClx2KVpFND7dFQMrqko=.e465c236-8d2c-42ec-8cb8-f1a49f258274@github.com>
Message-ID: <_7YHL1mTJBL7b_EgdhbFJZ2hIFiOD0Tjqy0APNy-h2g=.16b48215-3ac0-4964-9ce2-e8ee475109b3@github.com>

On Wed, 3 Sep 2025 01:31:24 GMT, pf0n <duke at openjdk.org> wrote:

>> src/hotspot/share/memory/heapInspection.hpp line 33:
>> 
>>> 31: #include "oops/objArrayOop.hpp"
>>> 32: #include "oops/oop.hpp"
>>> 33: #include "runtime/mutex.hpp"
>> 
>> Does this need to be in the header?
>
> I had an error in GHA during my early implementation, so I included that header. I'll remove and test to see if it is needed or not.

I believe you need it for this: https://github.com/pf0n/jdk/blob/f43e334bf76f878ec688cbd58a5ab1cb10deb0f9/src/hotspot/share/memory/heapInspection.hpp#L218

It probably happens to work at other places because of preceding includes that happen to satisfy this. Explicitly including it here makes sense for that reason. Not sure why it just started showing up, but likely a new use that didn't otherwise satisfy this include.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2320510893

From duke at openjdk.org  Thu Sep  4 00:27:49 2025
From: duke at openjdk.org (pf0n)
Date: Thu, 4 Sep 2025 00:27:49 GMT
Subject: RFR: 8366122: Shenandoah: Implement efficient support for object
 count after gc events [v2]
In-Reply-To: <_7YHL1mTJBL7b_EgdhbFJZ2hIFiOD0Tjqy0APNy-h2g=.16b48215-3ac0-4964-9ce2-e8ee475109b3@github.com>
References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
 <OPZ8vhzy70VNYJu-pVgX-3Te33auMyDb3330R_s3F0I=.1a2a1742-fc26-4735-9847-18947f48c7bf@github.com>
 <espHeZfIfmymTBYI7AuHKpolClx2KVpFND7dFQMrqko=.e465c236-8d2c-42ec-8cb8-f1a49f258274@github.com>
 <_7YHL1mTJBL7b_EgdhbFJZ2hIFiOD0Tjqy0APNy-h2g=.16b48215-3ac0-4964-9ce2-e8ee475109b3@github.com>
Message-ID: <zpYqUbIOOXyW5NYLgU28BOypxufdRr1crkOYLfJ7kUk=.0dad4d5e-29bc-4114-9652-0d655e45e9a5@github.com>

On Thu, 4 Sep 2025 00:12:48 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> I had an error in GHA during my early implementation, so I included that header. I'll remove and test to see if it is needed or not.
>
> I believe you need it for this: https://github.com/pf0n/jdk/blob/f43e334bf76f878ec688cbd58a5ab1cb10deb0f9/src/hotspot/share/memory/heapInspection.hpp#L218
> 
> It probably happens to work at other places because of preceding includes that happen to satisfy this. Explicitly including it here makes sense for that reason. Not sure why it just started showing up, but likely a new use that didn't otherwise satisfy this include.

I forgot to circle back on this, but there are files that I created that includes `heapInspection.hpp`. I get an incomplete type for the Mutex class if I don't include `mutex.hpp`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2320521485

From syan at openjdk.org  Thu Sep  4 01:30:50 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 4 Sep 2025 01:30:50 GMT
Subject: RFR: 8366692: Several gc/shenandoah tests timed out
In-Reply-To: <ANyxJvBvoWfiUkp4IhAVD00Bebl7ap9TvfKYpedyxyI=.fb65fc48-5694-4373-9baa-79bcb738105c@github.com>
References: <xmal0MH4ntVgjSL8IDkxsnvEMwINQo9P493HWsweoQ4=.aa160adc-16c7-4d9d-a1a9-13438c7ec052@github.com>
 <ANyxJvBvoWfiUkp4IhAVD00Bebl7ap9TvfKYpedyxyI=.fb65fc48-5694-4373-9baa-79bcb738105c@github.com>
Message-ID: <snsODwr4ewo1sj1W0ZUMifeuiRXn-aVsc8L7VmhHf4Y=.86fa6b89-7394-4d1f-9022-e2449a7ba093@github.com>

On Tue, 2 Sep 2025 18:21:14 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Hi all,
>> 
>> After JDK-8260555 set the default jtreg timeout factor to 1, then several gc/shenandoah tests run timed out with jtreg options -timeoutFactor:1. So I think it's necessary to increase the timeout value set in tests to make test run normally.
>> 
>> The actual run time consumed on my linux-x64 machine with  224 CPU core threads shows in [JDK-8366692](https://bugs.openjdk.org/browse/JDK-8366692).
>> 
>> Accodring the time statistics, the test test/hotspot/jtreg/gc/shenandoah/TestSieveObjects.java only change the second `@run` at the `@test id=generational` and `@test id=aggressive`, other tests do not need to change. And all the `@run` in test test/hotspot/jtreg/gc/shenandoah/jni/TestJNIGlobalRefs.java changed from 120(default value) to 240.
>> 
>> Change has been verified locally on linux-x64, test-fix only, no risk.
>
> Seems there is some unrelated build breakage. Can we merge from `master` again before integrating?

Thanks for the reviews @earthling-amzn @shipilev

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27052#issuecomment-3251359877

From syan at openjdk.org  Thu Sep  4 01:30:51 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 4 Sep 2025 01:30:51 GMT
Subject: Integrated: 8366692: Several gc/shenandoah tests timed out
In-Reply-To: <xmal0MH4ntVgjSL8IDkxsnvEMwINQo9P493HWsweoQ4=.aa160adc-16c7-4d9d-a1a9-13438c7ec052@github.com>
References: <xmal0MH4ntVgjSL8IDkxsnvEMwINQo9P493HWsweoQ4=.aa160adc-16c7-4d9d-a1a9-13438c7ec052@github.com>
Message-ID: <kUVpGjVxQducUglz_m_hQBrEwLa0-nmx2pfPDY8B7-o=.ee8337f6-8913-4cbb-844a-606b7526a84d@github.com>

On Tue, 2 Sep 2025 13:58:46 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> After JDK-8260555 set the default jtreg timeout factor to 1, then several gc/shenandoah tests run timed out with jtreg options -timeoutFactor:1. So I think it's necessary to increase the timeout value set in tests to make test run normally.
> 
> The actual run time consumed on my linux-x64 machine with  224 CPU core threads shows in [JDK-8366692](https://bugs.openjdk.org/browse/JDK-8366692).
> 
> Accodring the time statistics, the test test/hotspot/jtreg/gc/shenandoah/TestSieveObjects.java only change the second `@run` at the `@test id=generational` and `@test id=aggressive`, other tests do not need to change. And all the `@run` in test test/hotspot/jtreg/gc/shenandoah/jni/TestJNIGlobalRefs.java changed from 120(default value) to 240.
> 
> Change has been verified locally on linux-x64, test-fix only, no risk.

This pull request has now been integrated.

Changeset: 02dd2119
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/02dd21196ed27289a6fad92c4881af484ce9c258
Stats:     8 lines in 3 files changed: 0 ins; 0 del; 8 mod

8366692: Several gc/shenandoah tests timed out

Reviewed-by: shade, wkemper

-------------

PR: https://git.openjdk.org/jdk/pull/27052

From ysr at openjdk.org  Thu Sep  4 01:58:47 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 4 Sep 2025 01:58:47 GMT
Subject: RFR: 8366122: Shenandoah: Implement efficient support for object
 count after gc events [v2]
In-Reply-To: <zpYqUbIOOXyW5NYLgU28BOypxufdRr1crkOYLfJ7kUk=.0dad4d5e-29bc-4114-9652-0d655e45e9a5@github.com>
References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
 <OPZ8vhzy70VNYJu-pVgX-3Te33auMyDb3330R_s3F0I=.1a2a1742-fc26-4735-9847-18947f48c7bf@github.com>
 <espHeZfIfmymTBYI7AuHKpolClx2KVpFND7dFQMrqko=.e465c236-8d2c-42ec-8cb8-f1a49f258274@github.com>
 <_7YHL1mTJBL7b_EgdhbFJZ2hIFiOD0Tjqy0APNy-h2g=.16b48215-3ac0-4964-9ce2-e8ee475109b3@github.com>
 <zpYqUbIOOXyW5NYLgU28BOypxufdRr1crkOYLfJ7kUk=.0dad4d5e-29bc-4114-9652-0d655e45e9a5@github.com>
Message-ID: <kvyA4Km6GcTbvLGMO8WwIvlFZvHv_wkpxzAhJ3jwBQs=.617fc48a-077d-4065-b151-c6d21e7f2c22@github.com>

On Thu, 4 Sep 2025 00:24:37 GMT, pf0n <duke at openjdk.org> wrote:

>> I believe you need it for this: https://github.com/pf0n/jdk/blob/f43e334bf76f878ec688cbd58a5ab1cb10deb0f9/src/hotspot/share/memory/heapInspection.hpp#L218
>> 
>> It probably happens to work at other places because of preceding includes that happen to satisfy this. Explicitly including it here makes sense for that reason. Not sure why it just started showing up, but likely a new use that didn't otherwise satisfy this include.
>
> I forgot to circle back on this, but there are files that I created that includes `heapInspection.hpp`. I get an incomplete type for the Mutex class if I don't include `mutex.hpp`.

Makes sense.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2320618033

From ysr at openjdk.org  Thu Sep  4 02:07:52 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 4 Sep 2025 02:07:52 GMT
Subject: RFR: 8366122: Shenandoah: Implement efficient support for object
 count after gc events [v2]
In-Reply-To: <espHeZfIfmymTBYI7AuHKpolClx2KVpFND7dFQMrqko=.e465c236-8d2c-42ec-8cb8-f1a49f258274@github.com>
References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
 <OPZ8vhzy70VNYJu-pVgX-3Te33auMyDb3330R_s3F0I=.1a2a1742-fc26-4735-9847-18947f48c7bf@github.com>
 <espHeZfIfmymTBYI7AuHKpolClx2KVpFND7dFQMrqko=.e465c236-8d2c-42ec-8cb8-f1a49f258274@github.com>
Message-ID: <SudZ1va_xJeFpa7ujHhojOq-zVTLgFdfVF0YG2M4pIo=.4b7655df-de9a-4726-9c06-42a3801374ff@github.com>

On Wed, 3 Sep 2025 01:41:15 GMT, pf0n <duke at openjdk.org> wrote:

>> test/jdk/jdk/jfr/event/gc/objectcount/TestObjectCountAfterGCEventWithShenandoah.java line 11:
>> 
>>> 9:  *           & vm.opt.ExplicitGCInvokesConcurrent != true
>>> 10:  * @library /test/lib /test/jdk
>>> 11:  * @run main/othervm -XX:+UnlockExperimentalVMOptions -XX:-UseFastUnorderedTimeStamps -XX:+UseShenandoahGC -XX:MarkSweepDeadRatio=0 -XX:-UseCompressedOops -XX:-UseCompressedClassPointers -XX:+IgnoreUnrecognizedVMOptions jdk.jfr.event.gc.objectcount.TestObjectCountAfterGCEventWithShenandoah
>> 
>> Are all of these flags necessary to run this test? Can we pare any unnecessary options?
>
> All of the collectors that test for the ObjectCountAfterGC event uses these flags. I thought it would be best to keep it consistent for the Shenandoah test.

Best practice is to remove flags that are no-ops, otherwise we accrue junk here.

I'd urge removal of such cruft, in particular: MarkSweepDeadRatio, UseCompressedOops & UseCompressedClassPointers (which you may have added for debugging ease), and IgnoreUnrecognizedVMOptions (which should, I think, not be there in any tests unless there is an explicitly stated reason to include it). I am not sure we even need UseFastUnorderedTimeStamps either since the test does not, to my knowledge, examine the order of timestamped events in the JFR recording. If further constraint checking is added to the tests that requires this, it should be added back at that time.

For the other collectors, we can consider a separate ticket to clean any unnecessary flags up (I suspect only MarkSweepDeadRatio may be needed for the cases where one is looking for a collection to necessarily move objects-- which I don't think these tests test for -- so even that flag appears unnecessary at least for these tests.)

I vote for unburdening the flag load for the new Shenandoah test at least, as suggested by William.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2320627227

From dholmes at openjdk.org  Thu Sep  4 02:35:49 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Sep 2025 02:35:49 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
In-Reply-To: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
Message-ID: <uYFYP2iLn3Ol4ZKMCpmlh_3-drv9GOazRdMEQM_1W1c=.37a052a3-63ee-472b-916d-dcc8415160fb@github.com>

On Tue, 2 Sep 2025 08:24:10 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
> 
> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
> 
> Passes tier1-tier5 with no added problems.

Looks good. Great cleanup! A couple of nits/suggestions.

Thanks

src/hotspot/share/c1/c1_LIRGenerator.cpp line 638:

> 636:   LIR_Opr hdr = lock;
> 637:   lock = new_hdr;
> 638:   CodeStub* slow_path = new MonitorExitStub(lock, true, monitor_no);

It seems all creators for `MonitorExitStub` now pass `true` so that parameter can be removed.

src/hotspot/share/runtime/basicLock.hpp line 40:

> 38:   // Used as a cache of the ObjectMonitor* used when locking. Must either
> 39:   // be nullptr or the ObjectMonitor* used when locking.
> 40:   volatile uintptr_t _metadata;

So this could now be a properly typed and named field. Future RFE.

src/hotspot/share/runtime/basicLock.hpp line 53:

> 51:   static int displaced_header_offset_in_bytes() { return metadata_offset_in_bytes(); }
> 52: 
> 53:   // For lightweight locking

If the following are for lightweight locking then what are the two previous for?

-------------

PR Review: https://git.openjdk.org/jdk/pull/27041#pullrequestreview-3179255959
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2317998409
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2320634417
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2320643671

From dholmes at openjdk.org  Thu Sep  4 02:35:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Sep 2025 02:35:51 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
In-Reply-To: <YYyG4Y12GO9UncFyZG8Z4vNUfOUIR9le_CBBp7hC54g=.d29ff0c6-8c37-44cd-b24d-35666d094725@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <YYyG4Y12GO9UncFyZG8Z4vNUfOUIR9le_CBBp7hC54g=.d29ff0c6-8c37-44cd-b24d-35666d094725@github.com>
Message-ID: <PTY0GwU-8Ah615YhW9AYNPnGR6SjCnEyDW78GrxDtMk=.2a19b8bd-6606-46f5-af68-663c386807ca@github.com>

On Tue, 2 Sep 2025 20:15:51 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
>> 
>> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
>> 
>> Passes tier1-tier5 with no added problems.
>
> src/hotspot/share/runtime/basicLock.hpp line 51:
> 
>> 49:   void set_bad_metadata_deopt() { set_metadata(badDispHeaderDeopt); }
>> 50: 
>> 51:   static int displaced_header_offset_in_bytes() { return metadata_offset_in_bytes(); }
> 
> Also delete line 51 ?

Still appears used in LIRAssembler. But the assert in which it is used doesn't really make sense as it just checks the offset == 0.

> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 769:
> 
>> 767: 
>> 768: // LightweightSynchronizer::inflate_locked_or_imse is used to to get an inflated
>> 769: // ObjectMonitor* when lightweight locking is used. It is used from contexts
> 
> I guess you don't need the phrase "when lightweight locking is used".

Even calling it "lightweight locking" is no longer needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2320640694
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2320651595

From gli at openjdk.org  Thu Sep  4 05:12:32 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Thu, 4 Sep 2025 05:12:32 GMT
Subject: RFR: 8357188: Remove the field
 MemAllocator::Allocation::_overhead_limit_exceeded and the related code [v3]
In-Reply-To: <0qHdlghXGyq966nZz5mrxkDrTLtN-FNb7zqRSewz92o=.84d3673c-7526-4ad7-a37d-17c3637ce918@github.com>
References: <0qHdlghXGyq966nZz5mrxkDrTLtN-FNb7zqRSewz92o=.84d3673c-7526-4ad7-a37d-17c3637ce918@github.com>
Message-ID: <ZUYQejSVisCygJBSHg-Bq17nYxGzF8ojAsg-5NCUH9g=.994a2297-86e9-4834-abd0-3cd801cb02e1@github.com>

> Hi all,
> 
> After JDK-8338977 [1], the field `MemAllocator::Allocation::_overhead_limit_exceeded` and the parameter `gc_overhead_limit_was_exceeded` of the method `CollectedHeap::mem_allocate` are not used by any GC. This patch removes them.
> 
> Test:
> All the tests of the command `make test TEST="hotspot:hotspot_gc"` passed locally (linux, x86_64, release build).
> 
> Best Regards,
> -- Guoxiong
> 
> [1] https://bugs.openjdk.org/browse/JDK-8338977

Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge branch 'master' into REMOVE_UNUSED_FIELD
 - Remove outdated comments.
 - JDK-8357188

-------------

Changes: https://git.openjdk.org/jdk/pull/27020/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27020&range=02
  Stats: 43 lines in 14 files changed: 0 ins; 22 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/27020.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27020/head:pull/27020

PR: https://git.openjdk.org/jdk/pull/27020

From duke at openjdk.org  Thu Sep  4 06:40:45 2025
From: duke at openjdk.org (duke)
Date: Thu, 4 Sep 2025 06:40:45 GMT
Subject: RFR: 8366778: Sort share/asm, share/gc, share/include includes
In-Reply-To: <AKP9Jcx9hb-p_kNHdelvSTn6bbkXhIEU8Tk9ewf65R8=.adc3821d-3bcf-4e9a-b540-fbbf8e74cc48@github.com>
References: <AKP9Jcx9hb-p_kNHdelvSTn6bbkXhIEU8Tk9ewf65R8=.adc3821d-3bcf-4e9a-b540-fbbf8e74cc48@github.com>
Message-ID: <BHmNGZy5Em9RXH306251D5NcqTqIvMPEKFVBX6K2c7k=.647363b7-2124-41bd-8019-0ee49999e175@github.com>

On Wed, 3 Sep 2025 09:35:24 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> Sort includes in `share/gc`, `share/asm`, `share/include` using `SortIncludes.java`, and remove some unnecessary ones. These are the last missing modules in `hotspot/share`.
> 
> Passes `tier1`.

@fandreuz 
Your change (at version d4eaae2d60da111630642b0b75927c6ad7d55d4f) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27067#issuecomment-3252143814

From duke at openjdk.org  Thu Sep  4 07:16:47 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 4 Sep 2025 07:16:47 GMT
Subject: Integrated: 8366778: Sort share/asm, share/gc, share/include includes
In-Reply-To: <AKP9Jcx9hb-p_kNHdelvSTn6bbkXhIEU8Tk9ewf65R8=.adc3821d-3bcf-4e9a-b540-fbbf8e74cc48@github.com>
References: <AKP9Jcx9hb-p_kNHdelvSTn6bbkXhIEU8Tk9ewf65R8=.adc3821d-3bcf-4e9a-b540-fbbf8e74cc48@github.com>
Message-ID: <kL636qTleCc5CXlvs6lT_ykqB5xzgCjeF06idGqKito=.373d7ae8-ef39-4aed-a555-b15b3c3a702a@github.com>

On Wed, 3 Sep 2025 09:35:24 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> Sort includes in `share/gc`, `share/asm`, `share/include` using `SortIncludes.java`, and remove some unnecessary ones. These are the last missing modules in `hotspot/share`.
> 
> Passes `tier1`.

This pull request has now been integrated.

Changeset: 1495dd94
Author:    Francesco Andreuzzi <andreuzzi.francesco at gmail.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1495dd94e97fc023dede71f957ce3b166d20d5ac
Stats:     40 lines in 15 files changed: 6 ins; 33 del; 1 mod

8366778: Sort share/asm, share/gc, share/include includes

Reviewed-by: shade, ayang, jsikstro

-------------

PR: https://git.openjdk.org/jdk/pull/27067

From fbredberg at openjdk.org  Thu Sep  4 09:32:44 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 4 Sep 2025 09:32:44 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
In-Reply-To: <YYyG4Y12GO9UncFyZG8Z4vNUfOUIR9le_CBBp7hC54g=.d29ff0c6-8c37-44cd-b24d-35666d094725@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <YYyG4Y12GO9UncFyZG8Z4vNUfOUIR9le_CBBp7hC54g=.d29ff0c6-8c37-44cd-b24d-35666d094725@github.com>
Message-ID: <WMI9YeW1LQDQUrD4wsR54qWnveFCSqdXctjVN55isGg=.cc90e31e-3cb9-4d5c-b80f-6286b80db4b8@github.com>

On Tue, 2 Sep 2025 20:11:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
>> 
>> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
>> 
>> Passes tier1-tier5 with no added problems.
>
> src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 344:
> 
>> 342:   volatile_nonstatic_field(ObjectMonitor,      _entry_list,                                   ObjectWaiter*)                         \
>> 343:   volatile_nonstatic_field(ObjectMonitor,      _succ,                                         int64_t)                               \
>> 344:   volatile_nonstatic_field(ObjectMonitor,      _stack_locker,                                 BasicLock*)                            \
> 
> There are some jvmci tests that check that the java side of jvmci matches, ie:
> 
> make test TEST=compiler/jvmci

Tried that and got:
`TEST SUCCESS`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321428734

From fbredberg at openjdk.org  Thu Sep  4 09:48:45 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 4 Sep 2025 09:48:45 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
In-Reply-To: <PTY0GwU-8Ah615YhW9AYNPnGR6SjCnEyDW78GrxDtMk=.2a19b8bd-6606-46f5-af68-663c386807ca@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <YYyG4Y12GO9UncFyZG8Z4vNUfOUIR9le_CBBp7hC54g=.d29ff0c6-8c37-44cd-b24d-35666d094725@github.com>
 <PTY0GwU-8Ah615YhW9AYNPnGR6SjCnEyDW78GrxDtMk=.2a19b8bd-6606-46f5-af68-663c386807ca@github.com>
Message-ID: <SIs0ZM-BB6p9kbd0vhXQLGK2nU04ADkz3QcckKFOexU=.322fd9a7-42cc-4a5a-80e0-d63d2b328c11@github.com>

On Thu, 4 Sep 2025 02:16:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/basicLock.hpp line 51:
>> 
>>> 49:   void set_bad_metadata_deopt() { set_metadata(badDispHeaderDeopt); }
>>> 50: 
>>> 51:   static int displaced_header_offset_in_bytes() { return metadata_offset_in_bytes(); }
>> 
>> Also delete line 51 ?
>
> Still appears used in LIRAssembler. But the assert in which it is used doesn't really make sense as it just checks the offset == 0.

This is unfortunately still used by some of the platform files. Since I want to keep this PR clean of platform changes, I have added this to the [next cleanup](https://bugs.openjdk.org/browse/JDK-8365191).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321466475

From fbredberg at openjdk.org  Thu Sep  4 10:00:47 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 4 Sep 2025 10:00:47 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
In-Reply-To: <YYyG4Y12GO9UncFyZG8Z4vNUfOUIR9le_CBBp7hC54g=.d29ff0c6-8c37-44cd-b24d-35666d094725@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <YYyG4Y12GO9UncFyZG8Z4vNUfOUIR9le_CBBp7hC54g=.d29ff0c6-8c37-44cd-b24d-35666d094725@github.com>
Message-ID: <CZRSry64icYZhI6xHfZ5_1713lUTvAGk7-NchbVftxI=.e6eb1a58-1fef-45f3-aad7-1d7de95b412c@github.com>

On Tue, 2 Sep 2025 20:19:06 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
>> 
>> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
>> 
>> Passes tier1-tier5 with no added problems.
>
> src/hotspot/share/runtime/javaThread.cpp line 2007:
> 
>> 2005: #ifdef SUPPORT_MONITOR_COUNT
>> 2006:   // Nothing to do. Just do some sanity check.
>> 2007:   assert(_held_monitor_count == 0, "counter should not be used");
> 
> In further cleanup, can we now remove _held_monitor_count next?

I think so, but I'm not sure. Anyhow I've added this to o the [next cleanup](https://bugs.openjdk.org/browse/JDK-8365191).

> src/hotspot/share/runtime/synchronizer.inline.hpp line 48:
> 
>> 46:   assert(current == Thread::current(), "must be");
>> 47: 
>> 48:     LightweightSynchronizer::enter(obj, lock, current);
> 
> In the further RFE, we should remove these dispatch functions too.

Added this to o the [next cleanup](https://bugs.openjdk.org/browse/JDK-8365191).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321483375
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321488805

From fbredberg at openjdk.org  Thu Sep  4 10:00:45 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 4 Sep 2025 10:00:45 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
In-Reply-To: <0CMB0g0_Ru1hF5l2NA194kD1ouNwMXrB1667Uvl9mFQ=.b6834c47-be53-41bb-b726-2e282517d6bc@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <0CMB0g0_Ru1hF5l2NA194kD1ouNwMXrB1667Uvl9mFQ=.b6834c47-be53-41bb-b726-2e282517d6bc@github.com>
Message-ID: <Q9XERDwEJhJZOlDuj1ufQSUyXhdMw0-5HSTeRZ2cEeg=.b4087d4f-8554-4066-a2c0-102bd1ce9617@github.com>

On Wed, 3 Sep 2025 07:37:34 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
>> 
>> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
>> 
>> Passes tier1-tier5 with no added problems.
>
> src/hotspot/share/runtime/basicLock.hpp line 51:
> 
>> 49:   void set_bad_metadata_deopt() { set_metadata(badDispHeaderDeopt); }
>> 50: 
>> 51:   static int displaced_header_offset_in_bytes() { return metadata_offset_in_bytes(); }
> 
> The `badDispHeaderDeopt` and `badDispHeaderOSR` constants should also be renamed.

Added this to o the [next cleanup](https://bugs.openjdk.org/browse/JDK-8365191).

> src/hotspot/share/runtime/synchronizer.cpp line 634:
> 
>> 632: }
>> 633: 
>> 634: static intptr_t install_hash_code(Thread* current, oop obj) {
> 
> A future RFE could potentially simplify and unify this with `FastHashCode`

Added this to o the [next cleanup](https://bugs.openjdk.org/browse/JDK-8365191).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321495256
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321493463

From fbredberg at openjdk.org  Thu Sep  4 10:13:43 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 4 Sep 2025 10:13:43 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
In-Reply-To: <uYFYP2iLn3Ol4ZKMCpmlh_3-drv9GOazRdMEQM_1W1c=.37a052a3-63ee-472b-916d-dcc8415160fb@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <uYFYP2iLn3Ol4ZKMCpmlh_3-drv9GOazRdMEQM_1W1c=.37a052a3-63ee-472b-916d-dcc8415160fb@github.com>
Message-ID: <_Ola7zEQaOGFemDMFTFkjmAouaLRxSJwarKbWnEKbDk=.4469db17-0021-450b-968e-b28267c626d4@github.com>

On Wed, 3 Sep 2025 07:16:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
>> 
>> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
>> 
>> Passes tier1-tier5 with no added problems.
>
> src/hotspot/share/c1/c1_LIRGenerator.cpp line 638:
> 
>> 636:   LIR_Opr hdr = lock;
>> 637:   lock = new_hdr;
>> 638:   CodeStub* slow_path = new MonitorExitStub(lock, true, monitor_no);
> 
> It seems all creators for `MonitorExitStub` now pass `true` so that parameter can be removed.

Good find! But this affects platform files, and since I want to keep this PR clean of platform changes, I have added this to the [next cleanup](https://bugs.openjdk.org/browse/JDK-8365191).

> src/hotspot/share/runtime/basicLock.hpp line 40:
> 
>> 38:   // Used as a cache of the ObjectMonitor* used when locking. Must either
>> 39:   // be nullptr or the ObjectMonitor* used when locking.
>> 40:   volatile uintptr_t _metadata;
> 
> So this could now be a properly typed and named field. Future RFE.

I have added this to the [next cleanup](https://bugs.openjdk.org/browse/JDK-8365191).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321521296
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321526089

From fbredberg at openjdk.org  Thu Sep  4 10:20:44 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 4 Sep 2025 10:20:44 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
In-Reply-To: <uYFYP2iLn3Ol4ZKMCpmlh_3-drv9GOazRdMEQM_1W1c=.37a052a3-63ee-472b-916d-dcc8415160fb@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <uYFYP2iLn3Ol4ZKMCpmlh_3-drv9GOazRdMEQM_1W1c=.37a052a3-63ee-472b-916d-dcc8415160fb@github.com>
Message-ID: <-yO5kJRg9ghIK9ZHi8auSW22u__Ixsva-A4mvgadZic=.4f31754d-c0a9-4646-a3b7-40aade9678a4@github.com>

On Thu, 4 Sep 2025 02:18:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
>> 
>> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
>> 
>> Passes tier1-tier5 with no added problems.
>
> src/hotspot/share/runtime/basicLock.hpp line 53:
> 
>> 51:   static int displaced_header_offset_in_bytes() { return metadata_offset_in_bytes(); }
>> 52: 
>> 53:   // For lightweight locking
> 
> If the following are for lightweight locking then what are the two previous for?

For something old and soon forgotten. :)
After I had integrated some platforms I realized that this was no longer needed, but since I want to keep this PR clean of platform changes, I have added this to the [next cleanup](https://bugs.openjdk.org/browse/JDK-8365191).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321540639

From gli at openjdk.org  Thu Sep  4 11:02:43 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Thu, 4 Sep 2025 11:02:43 GMT
Subject: RFR: 8357188: Remove the field
 MemAllocator::Allocation::_overhead_limit_exceeded and the related code [v3]
In-Reply-To: <ZUYQejSVisCygJBSHg-Bq17nYxGzF8ojAsg-5NCUH9g=.994a2297-86e9-4834-abd0-3cd801cb02e1@github.com>
References: <0qHdlghXGyq966nZz5mrxkDrTLtN-FNb7zqRSewz92o=.84d3673c-7526-4ad7-a37d-17c3637ce918@github.com>
 <ZUYQejSVisCygJBSHg-Bq17nYxGzF8ojAsg-5NCUH9g=.994a2297-86e9-4834-abd0-3cd801cb02e1@github.com>
Message-ID: <uEuu6ViZTOx3oXfovHZSLOhle-vQtET_Yw1QTBKIdUc=.edfe8f9b-6be2-4725-afcf-fab57e3ec4cf@github.com>

On Thu, 4 Sep 2025 05:12:32 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> After JDK-8338977 [1], the field `MemAllocator::Allocation::_overhead_limit_exceeded` and the parameter `gc_overhead_limit_was_exceeded` of the method `CollectedHeap::mem_allocate` are not used by any GC. This patch removes them.
>> 
>> Test:
>> All the tests of the command `make test TEST="hotspot:hotspot_gc"` passed locally (linux, x86_64, release build).
>> 
>> Best Regards,
>> -- Guoxiong
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8338977
>
> Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into REMOVE_UNUSED_FIELD
>  - Remove outdated comments.
>  - JDK-8357188

I merged the `master` branch in order to solve the code conflict. Could you help review this patch again?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27020#issuecomment-3253128894

From ayang at openjdk.org  Thu Sep  4 11:10:45 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 4 Sep 2025 11:10:45 GMT
Subject: RFR: 8357188: Remove the field
 MemAllocator::Allocation::_overhead_limit_exceeded and the related code [v3]
In-Reply-To: <ZUYQejSVisCygJBSHg-Bq17nYxGzF8ojAsg-5NCUH9g=.994a2297-86e9-4834-abd0-3cd801cb02e1@github.com>
References: <0qHdlghXGyq966nZz5mrxkDrTLtN-FNb7zqRSewz92o=.84d3673c-7526-4ad7-a37d-17c3637ce918@github.com>
 <ZUYQejSVisCygJBSHg-Bq17nYxGzF8ojAsg-5NCUH9g=.994a2297-86e9-4834-abd0-3cd801cb02e1@github.com>
Message-ID: <zY1w6Mw6FNenzPfMVJZXYFt4-_kTtFVukvFYN2qrFkA=.a4a48b4e-d531-4800-bfe4-1c5345102613@github.com>

On Thu, 4 Sep 2025 05:12:32 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> After JDK-8338977 [1], the field `MemAllocator::Allocation::_overhead_limit_exceeded` and the parameter `gc_overhead_limit_was_exceeded` of the method `CollectedHeap::mem_allocate` are not used by any GC. This patch removes them.
>> 
>> Test:
>> All the tests of the command `make test TEST="hotspot:hotspot_gc"` passed locally (linux, x86_64, release build).
>> 
>> Best Regards,
>> -- Guoxiong
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8338977
>
> Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into REMOVE_UNUSED_FIELD
>  - Remove outdated comments.
>  - JDK-8357188

Marked as reviewed by ayang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27020#pullrequestreview-3184638351

From coleenp at openjdk.org  Thu Sep  4 11:21:52 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 4 Sep 2025 11:21:52 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
In-Reply-To: <-yO5kJRg9ghIK9ZHi8auSW22u__Ixsva-A4mvgadZic=.4f31754d-c0a9-4646-a3b7-40aade9678a4@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <uYFYP2iLn3Ol4ZKMCpmlh_3-drv9GOazRdMEQM_1W1c=.37a052a3-63ee-472b-916d-dcc8415160fb@github.com>
 <-yO5kJRg9ghIK9ZHi8auSW22u__Ixsva-A4mvgadZic=.4f31754d-c0a9-4646-a3b7-40aade9678a4@github.com>
Message-ID: <AZKEm7040REVX7fA2IIYKLA5y_SVtnySVjBt9Uy49m0=.77917dd2-de3d-4066-ba68-40c6fe89ae38@github.com>

On Thu, 4 Sep 2025 10:18:27 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> src/hotspot/share/runtime/basicLock.hpp line 53:
>> 
>>> 51:   static int displaced_header_offset_in_bytes() { return metadata_offset_in_bytes(); }
>>> 52: 
>>> 53:   // For lightweight locking
>> 
>> If the following are for lightweight locking then what are the two previous for?
>
> For something old and soon forgotten. :)
> After I had integrated some platforms I realized that this was no longer needed, but since I want to keep this PR clean of platform changes, I have added this to the [next cleanup](https://bugs.openjdk.org/browse/JDK-8365191).

This makes sense to change the displaced header names in BasicLock with the changes to various disp_hdr and other register names in the next cleanup.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321704905

From coleenp at openjdk.org  Thu Sep  4 11:21:55 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 4 Sep 2025 11:21:55 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
In-Reply-To: <PTY0GwU-8Ah615YhW9AYNPnGR6SjCnEyDW78GrxDtMk=.2a19b8bd-6606-46f5-af68-663c386807ca@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <YYyG4Y12GO9UncFyZG8Z4vNUfOUIR9le_CBBp7hC54g=.d29ff0c6-8c37-44cd-b24d-35666d094725@github.com>
 <PTY0GwU-8Ah615YhW9AYNPnGR6SjCnEyDW78GrxDtMk=.2a19b8bd-6606-46f5-af68-663c386807ca@github.com>
Message-ID: <hMBSttV4Haz0_DDzYERrYojOSEF2r95ljXFreYlrplA=.e9f32226-b3be-499a-9665-5059f89dd0a4@github.com>

On Thu, 4 Sep 2025 02:26:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 769:
>> 
>>> 767: 
>>> 768: // LightweightSynchronizer::inflate_locked_or_imse is used to to get an inflated
>>> 769: // ObjectMonitor* when lightweight locking is used. It is used from contexts
>> 
>> I guess you don't need the phrase "when lightweight locking is used".
>
> Even calling it "lightweight locking" is no longer needed.

I think the name "lightweight locking" is used for the file name and class name, so the name is okay.  It does help if you're trying to understand the history of the locking algorithm.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321711418

From coleenp at openjdk.org  Thu Sep  4 11:25:53 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 4 Sep 2025 11:25:53 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
In-Reply-To: <CZRSry64icYZhI6xHfZ5_1713lUTvAGk7-NchbVftxI=.e6eb1a58-1fef-45f3-aad7-1d7de95b412c@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <YYyG4Y12GO9UncFyZG8Z4vNUfOUIR9le_CBBp7hC54g=.d29ff0c6-8c37-44cd-b24d-35666d094725@github.com>
 <CZRSry64icYZhI6xHfZ5_1713lUTvAGk7-NchbVftxI=.e6eb1a58-1fef-45f3-aad7-1d7de95b412c@github.com>
Message-ID: <cYXatz3k_5COQxEHYOY-YXa6GxOSe9YZ6SKQtxNp-oE=.80a9ea35-4724-4f90-97c1-a7d23cead631@github.com>

On Thu, 4 Sep 2025 09:55:23 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> src/hotspot/share/runtime/synchronizer.inline.hpp line 48:
>> 
>>> 46:   assert(current == Thread::current(), "must be");
>>> 47: 
>>> 48:     LightweightSynchronizer::enter(obj, lock, current);
>> 
>> In the further RFE, we should remove these dispatch functions too.
>
> Added this to o the [next cleanup](https://bugs.openjdk.org/browse/JDK-8365191).

So to be clear, we should probably have 2+ RFEs that follow this.  One to remove the cpu specific names like displaced header, one to remove the loom interactions and held_monitor_count, and another to remove the dispatches to LightweightSynchronizer and make ObjectSynchronizer's role in object locking clear.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321723438

From fbredberg at openjdk.org  Thu Sep  4 11:36:02 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 4 Sep 2025 11:36:02 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share [v2]
In-Reply-To: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
Message-ID: <hxcBQMZwFekaGf3CW-V2c1AOMG0v2lb69uCNy2pDVP4=.030551cc-729a-41d0-854f-9e22996f27e7@github.com>

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
> 
> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
> 
> Passes tier1-tier5 with no added problems.

Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:

  Update after review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27041/files
  - new: https://git.openjdk.org/jdk/pull/27041/files/71038b71..3c1b56c5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27041&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27041&range=00-01

  Stats: 17 lines in 4 files changed: 1 ins; 4 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/27041.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27041/head:pull/27041

PR: https://git.openjdk.org/jdk/pull/27041

From fbredberg at openjdk.org  Thu Sep  4 12:10:01 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 4 Sep 2025 12:10:01 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share [v3]
In-Reply-To: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
Message-ID: <44Gctjipr64z9PfAvwdEgRo4pq8sFtmpZOE4JehO4rc=.c6532986-972f-466c-b7c6-75e063613fa9@github.com>

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
> 
> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
> 
> Passes tier1-tier5 with no added problems.

Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:

  New version for Coleen

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27041/files
  - new: https://git.openjdk.org/jdk/pull/27041/files/3c1b56c5..f2fc9a5f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27041&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27041&range=01-02

  Stats: 9 lines in 1 file changed: 0 ins; 2 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/27041.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27041/head:pull/27041

PR: https://git.openjdk.org/jdk/pull/27041

From coleenp at openjdk.org  Thu Sep  4 12:10:01 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 4 Sep 2025 12:10:01 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share [v3]
In-Reply-To: <44Gctjipr64z9PfAvwdEgRo4pq8sFtmpZOE4JehO4rc=.c6532986-972f-466c-b7c6-75e063613fa9@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <44Gctjipr64z9PfAvwdEgRo4pq8sFtmpZOE4JehO4rc=.c6532986-972f-466c-b7c6-75e063613fa9@github.com>
Message-ID: <c1Lts9xSz6lsCaqC60pPBdZJx7AD1BkN744G6qaLwzE=.567436f0-fdfa-45fc-b609-ba197b6ef6d9@github.com>

On Thu, 4 Sep 2025 12:07:43 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
>> 
>> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
>> 
>> Passes tier1-tier5 with no added problems.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   New version for Coleen

Looks great!!

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27041#pullrequestreview-3184882023

From fbredberg at openjdk.org  Thu Sep  4 13:03:50 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 4 Sep 2025 13:03:50 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share [v3]
In-Reply-To: <uTv7hGrRoKhLCxyY2SILmig-HZw0zE5Gh3wNLZ2R1LE=.0d6eb14f-b6aa-464e-9fac-87b829f32f84@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <uTv7hGrRoKhLCxyY2SILmig-HZw0zE5Gh3wNLZ2R1LE=.0d6eb14f-b6aa-464e-9fac-87b829f32f84@github.com>
Message-ID: <A3xR2rgOAyv-WUK_CJLcEYYf2l6kumF_IFmu2SKkRlg=.04caf3b9-4afc-4075-bda9-bf3285ac826e@github.com>

On Tue, 2 Sep 2025 13:46:11 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   New version for Coleen
>
> src/hotspot/share/opto/phaseX.cpp line 1672:
> 
>> 1670:     // Found (linux x64 only?) with:
>> 1671:     //   serviceability/sa/ClhsdbThreadContext.java
>> 1672:     //   -XX:+UnlockExperimentalVMOptions -XX:LockingMode=1 -XX:+IgnoreUnrecognizedVMOptions -XX:VerifyIterativeGVN=1110
> 
> For traceability, I suggest leaving this line untouched and adding a comment in the next line clarifying that `-XX:LockingMode` is not available anymore.

Fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2322046338

From fbredberg at openjdk.org  Thu Sep  4 13:03:51 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 4 Sep 2025 13:03:51 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share [v3]
In-Reply-To: <hMBSttV4Haz0_DDzYERrYojOSEF2r95ljXFreYlrplA=.e9f32226-b3be-499a-9665-5059f89dd0a4@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <YYyG4Y12GO9UncFyZG8Z4vNUfOUIR9le_CBBp7hC54g=.d29ff0c6-8c37-44cd-b24d-35666d094725@github.com>
 <PTY0GwU-8Ah615YhW9AYNPnGR6SjCnEyDW78GrxDtMk=.2a19b8bd-6606-46f5-af68-663c386807ca@github.com>
 <hMBSttV4Haz0_DDzYERrYojOSEF2r95ljXFreYlrplA=.e9f32226-b3be-499a-9665-5059f89dd0a4@github.com>
Message-ID: <KK4Gp9gky9Z6uCNBSkwvUv3e5XIM4Znkm6sejXtbpi0=.2a12cb35-4498-4258-ab96-5333b2736cb3@github.com>

On Thu, 4 Sep 2025 11:19:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Even calling it "lightweight locking" is no longer needed.
>
> I think the name "lightweight locking" is used for the file name and class name, so the name is okay.  It does help if you're trying to understand the history of the locking algorithm.

Fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2322050243

From fbredberg at openjdk.org  Thu Sep  4 13:03:53 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 4 Sep 2025 13:03:53 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share [v3]
In-Reply-To: <YYyG4Y12GO9UncFyZG8Z4vNUfOUIR9le_CBBp7hC54g=.d29ff0c6-8c37-44cd-b24d-35666d094725@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <YYyG4Y12GO9UncFyZG8Z4vNUfOUIR9le_CBBp7hC54g=.d29ff0c6-8c37-44cd-b24d-35666d094725@github.com>
Message-ID: <kJEg8xjAET9XdViA9Ax1temyDx-1bA13Mgwg5oS4v_U=.fce93271-67d1-40b9-9a64-8bc2d21654de@github.com>

On Tue, 2 Sep 2025 20:22:45 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   New version for Coleen
>
> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 823:
> 
>> 821: ObjectMonitor* LightweightSynchronizer::inflate_into_object_header(oop object, ObjectSynchronizer::InflateCause cause, JavaThread* locking_thread, Thread* current) {
>> 822: 
>> 823:   // The JavaThread* locking_thread parameter is only used by lightweight locking and
> 
> Same here. suggestion:
> 
> 
> // The JavaThread* locking parameter requires that the locking_thread == JavaThread::current, or is suspended
> // throughout the call by some other mechanism.

Fixed

> src/hotspot/share/runtime/synchronizer.cpp line 542:
> 
>> 540:   }
>> 541:   ObjectMonitor* monitor;
>> 542:   monitor = LightweightSynchronizer::inflate_locked_or_imse(obj(), inflate_cause_notify, CHECK);
> 
> Declare and initialize on the same line:
> 
> ObjectMonitor* monitor = LightwightSynchronizer::inflate_locked_or_imse(obj...);

Fixed

> src/hotspot/share/runtime/synchronizer.cpp line 557:
> 
>> 555: 
>> 556:   ObjectMonitor* monitor;
>> 557:   monitor = LightweightSynchronizer::inflate_locked_or_imse(obj(), inflate_cause_notify, CHECK);
> 
> same here with
> ObjectMonitor* monitor = LIght ...
> 
> I think we should have another RFE to look at eliminating the middle call.  Call these in LIghtweightSynchronizer::notify, notifyAll and waitInterruptably directly and remove these functions.

Added this to o the [next cleanup](https://bugs.openjdk.org/browse/JDK-8365191).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2322051302
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2322052236
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2322057900

From rcastanedalo at openjdk.org  Thu Sep  4 13:34:52 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 4 Sep 2025 13:34:52 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share [v3]
In-Reply-To: <44Gctjipr64z9PfAvwdEgRo4pq8sFtmpZOE4JehO4rc=.c6532986-972f-466c-b7c6-75e063613fa9@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <44Gctjipr64z9PfAvwdEgRo4pq8sFtmpZOE4JehO4rc=.c6532986-972f-466c-b7c6-75e063613fa9@github.com>
Message-ID: <k17wvmQmd2nzxOcn9eHhUDOK9ezTo673f6XTsRi5xrw=.68621d5a-054e-4009-a00c-2ad5fe786a57@github.com>

On Thu, 4 Sep 2025 12:10:01 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
>> 
>> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
>> 
>> Passes tier1-tier5 with no added problems.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   New version for Coleen

Compiler changes look good, thanks!

-------------

Marked as reviewed by rcastanedalo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27041#pullrequestreview-3185331487

From wkemper at openjdk.org  Thu Sep  4 14:30:31 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 4 Sep 2025 14:30:31 GMT
Subject: RFR: Merge openjdk/jdk21u:master
Message-ID: <LI_50zoUU8sj8dI4uHvI6GygS8D5vIZD8Xs8plo7nWs=.4470fc2e-8c3d-4d7f-aaa6-18e932f4a591@github.com>

Merges tag jdk-21.0.9+6

-------------

Commit messages:
 - 8360518: Docker tests do not work when asan is configured
 - 8362855: Test java/net/ipv6tests/TcpTest.java should report SkippedException when there no ia4addr  or ia6addr
 - 8350807: Certificates using MD5 algorithm that are disabled by default are incorrectly allowed in TLSv1.3 when re-enabled
 - 8342074: Fix runtime/Thread/TestAlwaysPreTouchStacks.java to be flagless or accept VM flags
 - 8351487: [ubsan] jvmti.h runtime error: load of value which is not a valid value
 - 8352765: G1CollectedHeap::expand_and_allocate() may fail to allocate even after heap expansion succeeds
 - 8338939: Simplify processing of hidden class names
 - 8343607: C2: Shenandoah crashes during barrier expansion in Continuation::enter
 - 8355429: Open source ProgressMonitor test
 - 8354285: Open source Swing tests Batch 3
 - ... and 2 more: https://git.openjdk.org/shenandoah-jdk21u/compare/36910541...48f48ec7

The webrev contains the conflicts with master:
 - merge conflicts: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=217&range=00.conflicts

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/217/files
  Stats: 1007 lines in 51 files changed: 712 ins; 204 del; 91 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/217.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/217/head:pull/217

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/217

From cslucas at openjdk.org  Thu Sep  4 17:50:46 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 4 Sep 2025 17:50:46 GMT
Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to
 conc_instruction_and_data_patch [v3]
In-Reply-To: <m8TVuzCamuC5zbdEJFrM4EWQDIKoUCOI8KsNvGeFEFU=.608bd8a2-30b5-46dc-9789-df755ad93d3b@github.com>
References: <hA8KRrjiWgdQsG7TWURlzOna1OPV0y76a55vfs5X9sU=.2e392c8e-d180-42e7-840a-60085d7426df@github.com>
 <m8TVuzCamuC5zbdEJFrM4EWQDIKoUCOI8KsNvGeFEFU=.608bd8a2-30b5-46dc-9789-df755ad93d3b@github.com>
Message-ID: <Gc9xPom3ZggUmVYdtQaORP0cFhBGtA07ZifTc2qgjMs=.64875ef9-dd4f-4634-aead-7d67b880f272@github.com>

On Wed, 3 Sep 2025 00:37:59 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Please, review this patch to make nmethod entry barriers use `conc-instruction-and-data-patch` fence mechanics when ShenandoahGC is being used on AArch64. The patch also removes (including from JVMCI interface) the old constant that was being used only by Shenandoah on AArch64.
>> 
>> The patch has been tested with functional and performance benchmarks on AArch64. Improvements in DaCapo and Renaissance benchmarks can be as high as 30%. Maximum critical Jops in SPEC improved by ~10%.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make PPC backend to also use concurrent code patching.

@TheRealMDoerr - gentle nudge.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26999#issuecomment-3254845065

From wkemper at openjdk.org  Thu Sep  4 17:55:32 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 4 Sep 2025 17:55:32 GMT
Subject: RFR: Merge openjdk/jdk21u:master [v2]
In-Reply-To: <LI_50zoUU8sj8dI4uHvI6GygS8D5vIZD8Xs8plo7nWs=.4470fc2e-8c3d-4d7f-aaa6-18e932f4a591@github.com>
References: <LI_50zoUU8sj8dI4uHvI6GygS8D5vIZD8Xs8plo7nWs=.4470fc2e-8c3d-4d7f-aaa6-18e932f4a591@github.com>
Message-ID: <Xa1wPs6IK4JVPCqsuFHDj3YI4nV2amVSslOB-HuonOA=.25e7cbb2-f34a-40a1-b9f4-7c25a538d772@github.com>

> Merges tag jdk-21.0.9+6

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 branch 'master' into merge-jdk-21.0.9+6
 - 8360518: Docker tests do not work when asan is configured
   
   Reviewed-by: rschmelter
   Backport-of: 01b15bc1f961f43ae11db0c15f45763c4ec4180b
 - 8362855: Test java/net/ipv6tests/TcpTest.java should report SkippedException when there no ia4addr  or ia6addr
   
   Backport-of: 0f49f65af3ac85b93ccf140dcfad823fb03b5ce1
 - 8350807: Certificates using MD5 algorithm that are disabled by default are incorrectly allowed in TLSv1.3 when re-enabled
   
   Reviewed-by: mbaesken
   Backport-of: abb23828f9dc5f4cdb75d5b924dd6f45925102cd
 - 8342074: Fix runtime/Thread/TestAlwaysPreTouchStacks.java to be flagless or accept VM flags
   
   Reviewed-by: rschmelter
   Backport-of: 9291abc6337f8cf480806f4b2996ec905b021704
 - 8351487: [ubsan] jvmti.h runtime error: load of value which is not a valid value
   
   Backport-of: bf3cfbeff414356aaf2b0933568ff648beace2c5
 - 8352765: G1CollectedHeap::expand_and_allocate() may fail to allocate even after heap expansion succeeds
   
   Backport-of: 804a8fa4e96a32be2b38c2d0906dc5861a292007
 - 8338939: Simplify processing of hidden class names
   
   Backport-of: 0f667103db7842fe9d3399f56baee0a5def4529e
 - 8343607: C2: Shenandoah crashes during barrier expansion in Continuation::enter
   
   Reviewed-by: shade
   Backport-of: 45c914c3ad8fbc406af9ba9dec97f11c28c91299
 - 8355429: Open source ProgressMonitor test
   
   Backport-of: 3b7f43f95e061274020deaa1eecdb8182a6b64e1
 - ... and 3 more: https://git.openjdk.org/shenandoah-jdk21u/compare/d0d9b7e3...a0e383ad

-------------

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/217/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=217&range=01
  Stats: 1008 lines in 51 files changed: 712 ins; 205 del; 91 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/217.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/217/head:pull/217

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/217

From gli at openjdk.org  Fri Sep  5 13:37:21 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Fri, 5 Sep 2025 13:37:21 GMT
Subject: RFR: 8357188: Remove the field
 MemAllocator::Allocation::_overhead_limit_exceeded and the related code [v3]
In-Reply-To: <ZUYQejSVisCygJBSHg-Bq17nYxGzF8ojAsg-5NCUH9g=.994a2297-86e9-4834-abd0-3cd801cb02e1@github.com>
References: <0qHdlghXGyq966nZz5mrxkDrTLtN-FNb7zqRSewz92o=.84d3673c-7526-4ad7-a37d-17c3637ce918@github.com>
 <ZUYQejSVisCygJBSHg-Bq17nYxGzF8ojAsg-5NCUH9g=.994a2297-86e9-4834-abd0-3cd801cb02e1@github.com>
Message-ID: <IQynXSFKxAT775NPC4Q4WHgQMj4pmkxd8OIkjVIY1Ew=.449ab052-dd96-45d4-a472-8c312118a87c@github.com>

On Thu, 4 Sep 2025 05:12:32 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> After JDK-8338977 [1], the field `MemAllocator::Allocation::_overhead_limit_exceeded` and the parameter `gc_overhead_limit_was_exceeded` of the method `CollectedHeap::mem_allocate` are not used by any GC. This patch removes them.
>> 
>> Test:
>> All the tests of the command `make test TEST="hotspot:hotspot_gc"` passed locally (linux, x86_64, release build).
>> 
>> Best Regards,
>> -- Guoxiong
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8338977
>
> Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into REMOVE_UNUSED_FIELD
>  - Remove outdated comments.
>  - JDK-8357188

Thanks for your reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27020#issuecomment-3258374018

From gli at openjdk.org  Fri Sep  5 13:37:22 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Fri, 5 Sep 2025 13:37:22 GMT
Subject: Integrated: 8357188: Remove the field
 MemAllocator::Allocation::_overhead_limit_exceeded and the related code
In-Reply-To: <0qHdlghXGyq966nZz5mrxkDrTLtN-FNb7zqRSewz92o=.84d3673c-7526-4ad7-a37d-17c3637ce918@github.com>
References: <0qHdlghXGyq966nZz5mrxkDrTLtN-FNb7zqRSewz92o=.84d3673c-7526-4ad7-a37d-17c3637ce918@github.com>
Message-ID: <Pd9JygbaA5jGM8ulQwRXAuJRhvPXH4pU_Du3yF0SqFw=.99aaaca0-36e2-4805-baaf-0e00154c9925@github.com>

On Sat, 30 Aug 2025 10:49:45 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> After JDK-8338977 [1], the field `MemAllocator::Allocation::_overhead_limit_exceeded` and the parameter `gc_overhead_limit_was_exceeded` of the method `CollectedHeap::mem_allocate` are not used by any GC. This patch removes them.
> 
> Test:
> All the tests of the command `make test TEST="hotspot:hotspot_gc"` passed locally (linux, x86_64, release build).
> 
> Best Regards,
> -- Guoxiong
> 
> [1] https://bugs.openjdk.org/browse/JDK-8338977

This pull request has now been integrated.

Changeset: 33794d16
Author:    Guoxiong Li <gli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/33794d161467635eb32591fee189e5409cd2d114
Stats:     43 lines in 14 files changed: 0 ins; 22 del; 21 mod

8357188: Remove the field MemAllocator::Allocation::_overhead_limit_exceeded and the related code

Reviewed-by: ayang, shade

-------------

PR: https://git.openjdk.org/jdk/pull/27020

From cslucas at openjdk.org  Fri Sep  5 17:27:12 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Fri, 5 Sep 2025 17:27:12 GMT
Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to
 conc_instruction_and_data_patch [v3]
In-Reply-To: <m8TVuzCamuC5zbdEJFrM4EWQDIKoUCOI8KsNvGeFEFU=.608bd8a2-30b5-46dc-9789-df755ad93d3b@github.com>
References: <hA8KRrjiWgdQsG7TWURlzOna1OPV0y76a55vfs5X9sU=.2e392c8e-d180-42e7-840a-60085d7426df@github.com>
 <m8TVuzCamuC5zbdEJFrM4EWQDIKoUCOI8KsNvGeFEFU=.608bd8a2-30b5-46dc-9789-df755ad93d3b@github.com>
Message-ID: <2mUEu3_9zBcWAkwSos4lG5VxpzWLuqmVk6iiJlkaLYg=.949860c5-1d21-4634-89f0-df25b2714445@github.com>

On Wed, 3 Sep 2025 00:37:59 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Please, review this patch to make nmethod entry barriers use `conc-instruction-and-data-patch` fence mechanics when ShenandoahGC is being used on AArch64. The patch also removes (including from JVMCI interface) the old constant that was being used only by Shenandoah on AArch64.
>> 
>> The patch has been tested with functional and performance benchmarks on AArch64. Improvements in DaCapo and Renaissance benchmarks can be as high as 30%. Maximum critical Jops in SPEC improved by ~10%.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make PPC backend to also use concurrent code patching.

@dbriemann - do you have access to a PPC machine that you can use to test this patch? TIA.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26999#issuecomment-3259209337

From duke at openjdk.org  Fri Sep  5 19:02:02 2025
From: duke at openjdk.org (pf0n)
Date: Fri, 5 Sep 2025 19:02:02 GMT
Subject: RFR: 8366122: Shenandoah: Implement efficient support for object
 count after gc events [v3]
In-Reply-To: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
Message-ID: <b1klCGCEqGxrorcHKOssWKVqhivTE-NnZqN5-UZqJ0k=.c0bf62fd-f6a2-4117-a383-7e17f0fb4db3@github.com>

> ### Summary
> 
> The new implementation of ObjectCountAfterGC for Shenandoah piggybacks off of the existing marking phases and records strongly marked objects in a histogram. If the event is disabled, the original marking closures are used. When enabled new mark-and-count closures are used by the worker threads. Each worker thread updates its local histogram as it marks an object. These local histograms are merged at the conclusion of the marking phase under a mutex. The event is emitted outside a safepoint. Because (most) Shenandoah's marking is done concurrently, so is the object counting work.
> 
> ### Performance
> The performance test were ran using the Extremem benchmark on a default and stress workload. (will edit this section to include data after average time and test for GenShen)
> 
> #### Default workload:
> ObjectCountAfterGC disabled (master branch):
> `[807.216s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      264 us)`
> `[807.216s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       91 us)`
> `[807.216s][info][gc,stats    ] Concurrent Mark Roots          =    0.041 s (a =     4099 us)`
> `[807.216s][info][gc,stats    ] Concurrent Marking             =    1.660 s (a =   166035 us)`
> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
> `[807.216s][info][gc,stats    ] Pause Final Mark (N)           =    0.004 s (a =      357 us)`
> 
> ObjectCountAfterGC disabled (feature branch):
> `[807.104s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      302 us)`
> `[807.104s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       92 us) `
> `[807.104s][info][gc,stats    ] Concurrent Mark Roots          =    0.048 s (a =     4827 us)`
> `[807.104s][info][gc,stats    ] Concurrent Marking             =    1.666 s (a =   166638 us) `
> `[807.104s][info][gc,stats    ] Pause Final Mark (G)           =    0.006 s (a =      603 us)`
> `[807.104s][info][gc,stats    ] Pause Final Mark (N)           =    0.005 s (a =      516 us)`
> 
> ObjectCountAfterGC enabled (feature branch)
> `[807.299s][info][gc,stats    ] Pause Init Mark (G)            =    0.002 s (a =      227 us)`
> `[807.299s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       89 us) `
> `[807.299s][info][gc,stats    ] Concurrent Mark Roots          =    0.053 s (a =     5279 us)`
> `[807.299s][info][gc,st...

pf0n has updated the pull request incrementally with three additional commits since the last revision:

 - Whitespace
 - Filtering alive objects
 - Filtering alive objects

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26977/files
  - new: https://git.openjdk.org/jdk/pull/26977/files/6a3c6318..4295fed1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26977&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26977&range=01-02

  Stats: 27 lines in 5 files changed: 22 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/26977.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26977/head:pull/26977

PR: https://git.openjdk.org/jdk/pull/26977

From duke at openjdk.org  Fri Sep  5 19:07:29 2025
From: duke at openjdk.org (pf0n)
Date: Fri, 5 Sep 2025 19:07:29 GMT
Subject: RFR: 8366122: Shenandoah: Implement efficient support for object
 count after gc events [v4]
In-Reply-To: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
Message-ID: <3oswYxtSVJyfVg1xsIkus9BfXpNFMEE0cS3tYxH1Mak=.237f1e90-9b60-4b4f-af13-16bb4826b9cc@github.com>

> ### Summary
> 
> The new implementation of ObjectCountAfterGC for Shenandoah piggybacks off of the existing marking phases and records strongly marked objects in a histogram. If the event is disabled, the original marking closures are used. When enabled new mark-and-count closures are used by the worker threads. Each worker thread updates its local histogram as it marks an object. These local histograms are merged at the conclusion of the marking phase under a mutex. The event is emitted outside a safepoint. Because (most) Shenandoah's marking is done concurrently, so is the object counting work.
> 
> ### Performance
> The performance test were ran using the Extremem benchmark on a default and stress workload. (will edit this section to include data after average time and test for GenShen)
> 
> #### Default workload:
> ObjectCountAfterGC disabled (master branch):
> `[807.216s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      264 us)`
> `[807.216s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       91 us)`
> `[807.216s][info][gc,stats    ] Concurrent Mark Roots          =    0.041 s (a =     4099 us)`
> `[807.216s][info][gc,stats    ] Concurrent Marking             =    1.660 s (a =   166035 us)`
> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
> `[807.216s][info][gc,stats    ] Pause Final Mark (N)           =    0.004 s (a =      357 us)`
> 
> ObjectCountAfterGC disabled (feature branch):
> `[807.104s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      302 us)`
> `[807.104s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       92 us) `
> `[807.104s][info][gc,stats    ] Concurrent Mark Roots          =    0.048 s (a =     4827 us)`
> `[807.104s][info][gc,stats    ] Concurrent Marking             =    1.666 s (a =   166638 us) `
> `[807.104s][info][gc,stats    ] Pause Final Mark (G)           =    0.006 s (a =      603 us)`
> `[807.104s][info][gc,stats    ] Pause Final Mark (N)           =    0.005 s (a =      516 us)`
> 
> ObjectCountAfterGC enabled (feature branch)
> `[807.299s][info][gc,stats    ] Pause Init Mark (G)            =    0.002 s (a =      227 us)`
> `[807.299s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       89 us) `
> `[807.299s][info][gc,stats    ] Concurrent Mark Roots          =    0.053 s (a =     5279 us)`
> `[807.299s][info][gc,st...

pf0n has updated the pull request incrementally with one additional commit since the last revision:

  Whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26977/files
  - new: https://git.openjdk.org/jdk/pull/26977/files/4295fed1..c7abbbf0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26977&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26977&range=02-03

  Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26977.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26977/head:pull/26977

PR: https://git.openjdk.org/jdk/pull/26977

From dholmes at openjdk.org  Mon Sep  8 05:38:15 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 8 Sep 2025 05:38:15 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share [v3]
In-Reply-To: <44Gctjipr64z9PfAvwdEgRo4pq8sFtmpZOE4JehO4rc=.c6532986-972f-466c-b7c6-75e063613fa9@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <44Gctjipr64z9PfAvwdEgRo4pq8sFtmpZOE4JehO4rc=.c6532986-972f-466c-b7c6-75e063613fa9@github.com>
Message-ID: <itpRRA1PnHEhDa3RJ7ihqo4V6QpnyBfMj-o9O2vZUEo=.005d8a89-eb43-4ad0-bbb1-c42a986decf6@github.com>

On Thu, 4 Sep 2025 12:10:01 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
>> 
>> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
>> 
>> Passes tier1-tier5 with no added problems.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   New version for Coleen

Marked as reviewed by dholmes (Reviewer).

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 768:

> 766: }
> 767: 
> 768: // LightweightSynchronizer::inflate_locked_or_imse is used to to get an

Suggestion:

// LightweightSynchronizer::inflate_locked_or_imse is used to get an

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 822:

> 820:   // The JavaThread* locking parameter requires that the
> 821:   // locking_thread == JavaThread::current, or is suspended throughout
> 822:   // the call by some other mechanism.

Suggestion:

  // The JavaThread* locking parameter requires that the locking_thread == JavaThread::current, 
  // or is suspended throughout the call by some other mechanism.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27041#pullrequestreview-3195015687
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2329176488
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2329179011

From xpeng at openjdk.org  Mon Sep  8 05:43:52 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Mon, 8 Sep 2025 05:43:52 GMT
Subject: RFR: 8354555: Add generic JFR events for TaskTerminator [v10]
In-Reply-To: <_7FP2wNe8p3N8SxKdmCN1x4zKO8TT5JWRcWEt51i35c=.4fbac292-3cb7-48b9-922e-1114f74e0549@github.com>
References: <_7FP2wNe8p3N8SxKdmCN1x4zKO8TT5JWRcWEt51i35c=.4fbac292-3cb7-48b9-922e-1114f74e0549@github.com>
Message-ID: <VR5t_MDcFP62KWr3r1POtMvqo9WEegerfVUwYawe0wM=.1d9cf66c-69ef-433a-a38a-20a619aad858@github.com>

> The purpose of the PR is to add generic JFR events for TaskTerminator to track the attempts and timings that GC threads have tried to terminate GC tasks.
> 
> Today only G1 emits JFR event with name `Termination` from [G1ParEvacuateFollowersClosure](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/g1/g1YoungCollector.cpp#L555-L563), all other garbage collectors don't emit any JFR event for the termination attempt at all. 
> 
> By adding this, it gives performance engineers the visibility to the termination attempts and  termination time when GC threads trying to finish GC tasks, we could build tool to analyze the jfr events to determine if there is potential data structure issue in application code, e.g. very large LinkedList or LinkedBlockingQueue.
> 
> For the test, I have manually tested different GCs with Flight Recording enabled and verified the events:
> G1:
> 
> jdk.GCPhaseParallel {
>   startTime = 23:09:34.124 (2025-05-22)
>   duration = 0.0108 ms
>   gcId = 0
>   gcWorkerId = 8
>   name = "Termination"
>   eventThread = "GC Thread#4" (osThreadId = 20483)
> }
> 
> jdk.GCPhaseParallel {
>   startTime = 23:09:34.124 (2025-05-22)
>   duration = 0.0467 ms
>   gcId = 0
>   gcWorkerId = 2
>   name = "Termination"
>   eventThread = "GC Thread#2" (osThreadId = 21251)
> }
> 
> jdk.GCPhaseParallel {
>   startTime = 23:09:34.124 (2025-05-22)
>   duration = 0.0474 ms
>   gcId = 0
>   gcWorkerId = 1
>   name = "Termination"
>   eventThread = "GC Thread#8" (osThreadId = 36359)
> }
> jdk.GCPhaseParallel {
>   startTime = 23:09:41.925 (2025-05-22)
>   duration = 0.000834 ms
>   gcId = 14
>   gcWorkerId = 7
>   name = "Termination: Parallel Marking"
>   eventThread = "GC Thread#1" (osThreadId = 21507)
> }
> 
> jdk.GCPhaseParallel {
>   startTime = 23:09:41.925 (2025-05-22)
>   duration = 0.000166 ms
>   gcId = 14
>   gcWorkerId = 7
>   name = "Termination: Parallel Marking"
>   eventThread = "GC Thread#1" (osThreadId = 21507)
> }
> 
> 
> Shenandoah: 
> 
> jdk.GCPhaseParallel {
>   startTime = 23:39:58.890 (2025-05-22)
>   duration = 0.0202 ms
>   gcId = 0
>   gcWorkerId = 0
>   name = "Termination: Concurrent Mark"
>   eventThread = "Shenandoah GC Threads#3" (osThreadId = 13827)
> }
> 
> jdk.GCPhaseParallel {
>   startTime = 23:39:58.890 (2025-05-22)
>   duration = 0.0205 ms
>   gcId = 0
>   gcWorkerId = 1
>   name = "Termination: Concurrent Mark"
>   eventThread = "Shenandoah GC Threads#1" (osThreadId = 14339)
> }
> 
> jdk.GCPhaseParallel {
>   startTime = 23:39:58.890 (2025-05-22)
>   duration = 0.0127 ms
>   gcId = 0
>   gcWorkerId = 5
>   name = "Termination: Final Mark"
>   eventThread = "Shenandoah G...

Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:

 - Merge branch 'openjdk:master' into JDK-8354555
 - Merge branch 'openjdk:master' into JDK-8354555
 - Merge branch 'openjdk:master' into JDK-8354555
 - Merge branch 'openjdk:master' into JDK-8354555
 - Merge branch 'openjdk:master' into JDK-8354555
 - Merge branch 'openjdk:master' into JDK-8354555
 - Fix jft test failure
 - Merge branch 'master' into JDK-8354555
 - Patch to fix the PR concerns
 - Emit exact same events for G1 as G1 is emitting today from G1EvacuateRegionsBaseTask and G1STWRefProcProxyTask
 - ... and 24 more: https://git.openjdk.org/jdk/compare/b0ca9bf6...52d61612

-------------

Changes: https://git.openjdk.org/jdk/pull/24676/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24676&range=09
  Stats: 90 lines in 10 files changed: 68 ins; 7 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/24676.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24676/head:pull/24676

PR: https://git.openjdk.org/jdk/pull/24676

From kbarrett at openjdk.org  Mon Sep  8 06:32:08 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 8 Sep 2025 06:32:08 GMT
Subject: RFR: 8367014: Rename class Atomic to AtomicAccess
Message-ID: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>

Please review this change that renames the all-static class `Atomic` to
`AtomicAccess`. The reason for this name change is to allow the introduction
of the new type `Atomic<T>` ([JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013)).

The PR has several commits, according to the specific category of change being
made. It may be easier to review the PR by studying these individual commits.

Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose
to not rename the various "atomic_<cpu>.*" and "atomic_<os>_<cpu>.*" files.

There are a number of comments containing the word "Atomic" that I didn't
change. They are generically about atomic operations, and will just as well
serve as referring to the future `Atomic<T>`.

Testing: mach5 tier1, GHA sanity tests.
This is one of those changes where successful builds indicate the change is good.

-------------

Commit messages:
 - update copyrights
 - misc cleanups
 - fix indentation from rename
 - rename Atomic => AtomicAccess in gtests
 - rename Atomic => AtomicAccess
 - change includes of atomic.hpp in gtests
 - change includes of atomic.hpp
 - rename atomic.hpp => atomicAccess.hpp

Changes: https://git.openjdk.org/jdk/pull/27135/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27135&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367014
  Stats: 4894 lines in 427 files changed: 1237 ins; 1235 del; 2422 mod
  Patch: https://git.openjdk.org/jdk/pull/27135.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27135/head:pull/27135

PR: https://git.openjdk.org/jdk/pull/27135

From fbredberg at openjdk.org  Mon Sep  8 07:08:31 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Mon, 8 Sep 2025 07:08:31 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share [v4]
In-Reply-To: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
Message-ID: <nn63Ff47Ae1WC7NwO8B5tWK8CWdpHz4xFkrpJZjtidk=.11850b3f-4f1c-49df-a17d-0f949bd6ed2e@github.com>

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
> 
> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
> 
> Passes tier1-tier5 with no added problems.

Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:

  New version for David

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27041/files
  - new: https://git.openjdk.org/jdk/pull/27041/files/f2fc9a5f..905ef3fb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27041&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27041&range=02-03

  Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27041.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27041/head:pull/27041

PR: https://git.openjdk.org/jdk/pull/27041

From aboldtch at openjdk.org  Mon Sep  8 07:08:31 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 8 Sep 2025 07:08:31 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share [v4]
In-Reply-To: <nn63Ff47Ae1WC7NwO8B5tWK8CWdpHz4xFkrpJZjtidk=.11850b3f-4f1c-49df-a17d-0f949bd6ed2e@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <nn63Ff47Ae1WC7NwO8B5tWK8CWdpHz4xFkrpJZjtidk=.11850b3f-4f1c-49df-a17d-0f949bd6ed2e@github.com>
Message-ID: <ErZI_8BcW3wmQDxrkOZ3LVUVq3K4Z1K2Y7RaYyuZHWg=.a1b7df24-7ce7-4d81-b8e1-cb0c41c6f0e5@github.com>

On Mon, 8 Sep 2025 07:05:47 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
>> 
>> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
>> 
>> Passes tier1-tier5 with no added problems.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   New version for David

Marked as reviewed by aboldtch (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27041#pullrequestreview-3195220478

From fbredberg at openjdk.org  Mon Sep  8 07:08:32 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Mon, 8 Sep 2025 07:08:32 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share [v3]
In-Reply-To: <itpRRA1PnHEhDa3RJ7ihqo4V6QpnyBfMj-o9O2vZUEo=.005d8a89-eb43-4ad0-bbb1-c42a986decf6@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <44Gctjipr64z9PfAvwdEgRo4pq8sFtmpZOE4JehO4rc=.c6532986-972f-466c-b7c6-75e063613fa9@github.com>
 <itpRRA1PnHEhDa3RJ7ihqo4V6QpnyBfMj-o9O2vZUEo=.005d8a89-eb43-4ad0-bbb1-c42a986decf6@github.com>
Message-ID: <rNB90g4uggb8Ldjb7gcVfP9CQUJ1N4xb9UKqPPVWewY=.e42357d0-28d3-4279-8060-0d234967bd09@github.com>

On Mon, 8 Sep 2025 05:33:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   New version for Coleen
>
> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 768:
> 
>> 766: }
>> 767: 
>> 768: // LightweightSynchronizer::inflate_locked_or_imse is used to to get an
> 
> Suggestion:
> 
> // LightweightSynchronizer::inflate_locked_or_imse is used to get an

Fixed

> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 822:
> 
>> 820:   // The JavaThread* locking parameter requires that the
>> 821:   // locking_thread == JavaThread::current, or is suspended throughout
>> 822:   // the call by some other mechanism.
> 
> Suggestion:
> 
>   // The JavaThread* locking parameter requires that the locking_thread == JavaThread::current, 
>   // or is suspended throughout the call by some other mechanism.

Fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2329325202
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2329325682

From dholmes at openjdk.org  Mon Sep  8 07:24:14 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 8 Sep 2025 07:24:14 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share [v4]
In-Reply-To: <nn63Ff47Ae1WC7NwO8B5tWK8CWdpHz4xFkrpJZjtidk=.11850b3f-4f1c-49df-a17d-0f949bd6ed2e@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <nn63Ff47Ae1WC7NwO8B5tWK8CWdpHz4xFkrpJZjtidk=.11850b3f-4f1c-49df-a17d-0f949bd6ed2e@github.com>
Message-ID: <nya8oCGxNul7GsrvBrbaDgsQtSbzARALdlQ3aKnCsTo=.8e61be4a-43b6-4d6d-b4ce-5b1bd60586b9@github.com>

On Mon, 8 Sep 2025 07:08:31 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
>> 
>> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
>> 
>> Passes tier1-tier5 with no added problems.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   New version for David

Marked as reviewed by dholmes (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27041#pullrequestreview-3195269911

From dholmes at openjdk.org  Mon Sep  8 08:20:10 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 8 Sep 2025 08:20:10 GMT
Subject: RFR: 8367014: Rename class Atomic to AtomicAccess
In-Reply-To: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
References: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
Message-ID: <qssX-7viebmd4gjIHOMjpQpGFuds34Z-4x0U4z8u6ps=.76432e6e-37a8-493a-abd5-9acd0058d8cb@github.com>

On Mon, 8 Sep 2025 06:26:03 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that renames the all-static class `Atomic` to
> `AtomicAccess`. The reason for this name change is to allow the introduction
> of the new type `Atomic<T>` ([JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013)).
> 
> The PR has several commits, according to the specific category of change being
> made. It may be easier to review the PR by studying these individual commits.
> 
> Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose
> to not rename the various "atomic_<cpu>.*" and "atomic_<os>_<cpu>.*" files.
> 
> There are a number of comments containing the word "Atomic" that I didn't
> change. They are generically about atomic operations, and will just as well
> serve as referring to the future `Atomic<T>`.
> 
> Testing: mach5 tier1, GHA sanity tests.
> This is one of those changes where successful builds indicate the change is good.

LGTM! Thanks for taking this on!

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27135#pullrequestreview-3195448260

From mdoerr at openjdk.org  Mon Sep  8 09:34:18 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 8 Sep 2025 09:34:18 GMT
Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to
 conc_instruction_and_data_patch [v3]
In-Reply-To: <m8TVuzCamuC5zbdEJFrM4EWQDIKoUCOI8KsNvGeFEFU=.608bd8a2-30b5-46dc-9789-df755ad93d3b@github.com>
References: <hA8KRrjiWgdQsG7TWURlzOna1OPV0y76a55vfs5X9sU=.2e392c8e-d180-42e7-840a-60085d7426df@github.com>
 <m8TVuzCamuC5zbdEJFrM4EWQDIKoUCOI8KsNvGeFEFU=.608bd8a2-30b5-46dc-9789-df755ad93d3b@github.com>
Message-ID: <Xe6ehHoHwbeIELQYabtpb9paR7i0Jmk19R4bkzq9tQw=.de0df764-44fb-4be9-b841-c30379c46d62@github.com>

On Wed, 3 Sep 2025 00:37:59 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Please, review this patch to make nmethod entry barriers use `conc-instruction-and-data-patch` fence mechanics when ShenandoahGC is being used on AArch64. The patch also removes (including from JVMCI interface) the old constant that was being used only by Shenandoah on AArch64.
>> 
>> The patch has been tested with functional and performance benchmarks on AArch64. Improvements in DaCapo and Renaissance benchmarks can be as high as 30%. Maximum critical Jops in SPEC improved by ~10%.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make PPC backend to also use concurrent code patching.

This change is a NOP for PPC64 since we're generating the same code for both patching types. GHA cross build has passed, so there's nothing to worry regarding PPC64.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26999#issuecomment-3265416475

From aph at openjdk.org  Mon Sep  8 09:35:16 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 8 Sep 2025 09:35:16 GMT
Subject: RFR: 8367014: Rename class Atomic to AtomicAccess
In-Reply-To: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
References: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
Message-ID: <12OJX5AFklPfeUixNRHyTHo38EV4dFzLX8Dp-yvMVrI=.bcd6c93a-d462-4ed9-9d34-e8197c7fb04a@github.com>

On Mon, 8 Sep 2025 06:26:03 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that renames the all-static class `Atomic` to
> `AtomicAccess`. The reason for this name change is to allow the introduction
> of the new type `Atomic<T>` ([JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013)).
> 
> The PR has several commits, according to the specific category of change being
> made. It may be easier to review the PR by studying these individual commits.
> 
> Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose
> to not rename the various "atomic_<cpu>.*" and "atomic_<os>_<cpu>.*" files.
> 
> There are a number of comments containing the word "Atomic" that I didn't
> change. They are generically about atomic operations, and will just as well
> serve as referring to the future `Atomic<T>`.
> 
> Testing: mach5 tier1, GHA sanity tests.
> This is one of those changes where successful builds indicate the change is good.

`AtomicAccess` is a bit wordy, and this change is going to mess up diffs for backports terribly, but I can't think of a better way to do it. Thanks.

-------------

Marked as reviewed by aph (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27135#pullrequestreview-3195732355

From kbarrett at openjdk.org  Mon Sep  8 09:47:14 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 8 Sep 2025 09:47:14 GMT
Subject: RFR: 8367014: Rename class Atomic to AtomicAccess
In-Reply-To: <12OJX5AFklPfeUixNRHyTHo38EV4dFzLX8Dp-yvMVrI=.bcd6c93a-d462-4ed9-9d34-e8197c7fb04a@github.com>
References: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
 <12OJX5AFklPfeUixNRHyTHo38EV4dFzLX8Dp-yvMVrI=.bcd6c93a-d462-4ed9-9d34-e8197c7fb04a@github.com>
Message-ID: <qmpM9lKGFOdN8PFrFkDB_v8GX1--yTbckJca3wbIFMw=.7048968e-f160-4503-845b-b8a901894a97@github.com>

On Mon, 8 Sep 2025 09:32:43 GMT, Andrew Haley <aph at openjdk.org> wrote:

> `AtomicAccess` is a bit wordy, and this change is going to mess up diffs for backports terribly, but I can't think of a better way to do it. Thanks.

There was a bunch of internal to Oracle bike shedding over the names already. But I'm open to more if someone
thinks they have a better idea. Note that once we're all done with switching to `Atomic<T>` where appropriate,
I don't expect very many direct uses of `AtomicAccess` to remain (though there will be _some_).

Diffs for backports are going to get messed up anyway, since most uses of `AtomicAccess` will eventually be
switched over to `Atomic<T>` style usage.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27135#issuecomment-3265464120

From aph at openjdk.org  Mon Sep  8 10:18:14 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 8 Sep 2025 10:18:14 GMT
Subject: RFR: 8367014: Rename class Atomic to AtomicAccess
In-Reply-To: <qmpM9lKGFOdN8PFrFkDB_v8GX1--yTbckJca3wbIFMw=.7048968e-f160-4503-845b-b8a901894a97@github.com>
References: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
 <12OJX5AFklPfeUixNRHyTHo38EV4dFzLX8Dp-yvMVrI=.bcd6c93a-d462-4ed9-9d34-e8197c7fb04a@github.com>
 <qmpM9lKGFOdN8PFrFkDB_v8GX1--yTbckJca3wbIFMw=.7048968e-f160-4503-845b-b8a901894a97@github.com>
Message-ID: <pBpfy7FUmxGT68RoU28K5VMnHcs9ifJx6GaZkYixsWo=.7b81b442-1b65-405a-b26e-313144c0ecf9@github.com>

On Mon, 8 Sep 2025 09:44:26 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> > `AtomicAccess` is a bit wordy, and this change is going to mess up diffs for backports terribly, but I can't think of a better way to do it. Thanks.
> 
> There was a bunch of internal to Oracle bike shedding over the names already. 

Sure, I imagine there was! It's a shame when decision making happens behind closed doors in a FOSS project, but public list bikeshedding would have been too much for this change.

> Diffs for backports are going to get messed up anyway, since most uses of `AtomicAccess` will eventually be switched over to `Atomic<T>` style usage.

That's fair.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27135#issuecomment-3265596419

From fbredberg at openjdk.org  Mon Sep  8 10:30:29 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Mon, 8 Sep 2025 10:30:29 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share [v4]
In-Reply-To: <nn63Ff47Ae1WC7NwO8B5tWK8CWdpHz4xFkrpJZjtidk=.11850b3f-4f1c-49df-a17d-0f949bd6ed2e@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <nn63Ff47Ae1WC7NwO8B5tWK8CWdpHz4xFkrpJZjtidk=.11850b3f-4f1c-49df-a17d-0f949bd6ed2e@github.com>
Message-ID: <3pd2IyLkKN1NErQilmGDrxPygkH03OTIelZwKZhDkBs=.7a5176ff-395b-4f82-a0eb-ff50ec1401a2@github.com>

On Mon, 8 Sep 2025 07:08:31 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
>> 
>> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
>> 
>> Passes tier1-tier7 with no added problems.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   New version for David

Thank you all for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27041#issuecomment-3265647098

From fbredberg at openjdk.org  Mon Sep  8 10:30:30 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Mon, 8 Sep 2025 10:30:30 GMT
Subject: Integrated: 8365190: Remove LockingMode related code from share
In-Reply-To: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
Message-ID: <8z9GgG5Q8z1MaKgjotL4d7FtJLtrPv_7J0XcQd9gSpo=.f15375ac-ed3b-47da-aada-9ffb10f4eb56@github.com>

On Tue, 2 Sep 2025 08:24:10 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
> 
> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
> 
> Passes tier1-tier7 with no added problems.

This pull request has now been integrated.

Changeset: a2726968
Author:    Fredrik Bredberg <fbredberg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a272696813f2e5e896ac9de9985246aaeb9d476c
Stats:     1277 lines in 50 files changed: 8 ins; 1137 del; 132 mod

8365190: Remove LockingMode related code from share

Reviewed-by: aboldtch, dholmes, ayang, coleenp, lmesnik, rcastanedalo

-------------

PR: https://git.openjdk.org/jdk/pull/27041

From wkemper at openjdk.org  Mon Sep  8 17:46:48 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 8 Sep 2025 17:46:48 GMT
Subject: Integrated: Merge openjdk/jdk21u:master
In-Reply-To: <LI_50zoUU8sj8dI4uHvI6GygS8D5vIZD8Xs8plo7nWs=.4470fc2e-8c3d-4d7f-aaa6-18e932f4a591@github.com>
References: <LI_50zoUU8sj8dI4uHvI6GygS8D5vIZD8Xs8plo7nWs=.4470fc2e-8c3d-4d7f-aaa6-18e932f4a591@github.com>
Message-ID: <WU8TVheemQCS32ki3-v2oapS7O88kOY1wB9CRDInWUE=.962da050-94fd-413c-b11e-69bc2da6a89b@github.com>

On Thu, 4 Sep 2025 14:25:50 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.9+6

This pull request has now been integrated.

Changeset: de04b203
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/de04b203d3472c06598a365ef7e7038937bf9f8b
Stats:     1008 lines in 51 files changed: 712 ins; 205 del; 91 mod

Merge

-------------

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/217

From cslucas at openjdk.org  Mon Sep  8 21:47:21 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Mon, 8 Sep 2025 21:47:21 GMT
Subject: Integrated: 8364936: Shenandoah: Switch nmethod entry barriers to
 conc_instruction_and_data_patch
In-Reply-To: <hA8KRrjiWgdQsG7TWURlzOna1OPV0y76a55vfs5X9sU=.2e392c8e-d180-42e7-840a-60085d7426df@github.com>
References: <hA8KRrjiWgdQsG7TWURlzOna1OPV0y76a55vfs5X9sU=.2e392c8e-d180-42e7-840a-60085d7426df@github.com>
Message-ID: <fF2BC7pFts0lWXYH_NyFSWYS9s9_qI-zd8buuGgj7vo=.7f7b61a7-00b8-4dfb-92f7-72b32904bdf8@github.com>

On Fri, 29 Aug 2025 00:02:42 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> Please, review this patch to make nmethod entry barriers use `conc-instruction-and-data-patch` fence mechanics when ShenandoahGC is being used on AArch64. The patch also removes (including from JVMCI interface) the old constant that was being used only by Shenandoah on AArch64.
> 
> The patch has been tested with functional and performance benchmarks on AArch64. Improvements in DaCapo and Renaissance benchmarks can be as high as 30%. Maximum critical Jops in SPEC improved by ~10%.

This pull request has now been integrated.

Changeset: 81a1e8e1
Author:    Cesar Soares Lucas <cslucas at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/81a1e8e1363446de499a59fc706221efde12dd86
Stats:     28 lines in 12 files changed: 0 ins; 19 del; 9 mod

8364936: Shenandoah: Switch nmethod entry barriers to conc_instruction_and_data_patch

Reviewed-by: fyang, dzhang, kdnilsen, wkemper

-------------

PR: https://git.openjdk.org/jdk/pull/26999

From stefank at openjdk.org  Tue Sep  9 11:52:03 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 9 Sep 2025 11:52:03 GMT
Subject: RFR: 8367014: Rename class Atomic to AtomicAccess
In-Reply-To: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
References: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
Message-ID: <iDpU5TCdK05ZWAVCbaI7KAFEn6htGCLJE-4O5Whaf0s=.640b886d-5f1f-45af-b947-7506dd0d97e9@github.com>

On Mon, 8 Sep 2025 06:26:03 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that renames the all-static class `Atomic` to
> `AtomicAccess`. The reason for this name change is to allow the introduction
> of the new type `Atomic<T>` ([JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013)).
> 
> The PR has several commits, according to the specific category of change being
> made. It may be easier to review the PR by studying these individual commits.
> 
> Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose
> to not rename the various "atomic_<cpu>.*" and "atomic_<os>_<cpu>.*" files.
> 
> There are a number of comments containing the word "Atomic" that I didn't
> change. They are generically about atomic operations, and will just as well
> serve as referring to the future `Atomic<T>`.
> 
> Testing: mach5 tier1, GHA sanity tests.
> This is one of those changes where successful builds indicate the change is good.

I've checked through the patch and it looks good. I found one file that lacked alignment adjustments.

> Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose
> to not rename the various "atomic_." and "atomic__." files.

Could you motivate why you chose to not do that?

src/hotspot/os_cpu/bsd_x86/atomic_bsd_x86.hpp line 43:

> 41: template<>
> 42: template<typename D, typename I>
> 43: inline D AtomicAccess::PlatformAdd<4>::fetch_then_add(D volatile* dest, I add_value,

This file has multiple alignment issues.

-------------

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27135#pullrequestreview-3200998425
PR Review Comment: https://git.openjdk.org/jdk/pull/27135#discussion_r2333148324

From kdnilsen at openjdk.org  Tue Sep  9 20:05:02 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 9 Sep 2025 20:05:02 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet
Message-ID: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>

This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.

This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.

The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.

-------------

Commit messages:
 - Fix ShenandoahAllocationRate::sample() and remove debug scaffolding
 - Remove debug instrumentation
 - Cleanup make_all_regions_unavailable()
 - Remove RENAISSANCE debugging instrumentation
 - Replace MEMORY_USAGE debugging with assertions
 - Zero [empty_]region_counts in make_all_regions_unavailable plus lots of debug instrumentation
 - fix white space
 - more fixes to pip accounting
 - Fix accounting for pip regions
 - Initialize _mutator_bytes_allocated_since_gc-start
 - ... and 102 more: https://git.openjdk.org/jdk/compare/05da2137...87e26b37

Changes: https://git.openjdk.org/jdk/pull/26867/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365880
  Stats: 3113 lines in 35 files changed: 1977 ins; 542 del; 594 mod
  Patch: https://git.openjdk.org/jdk/pull/26867.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26867/head:pull/26867

PR: https://git.openjdk.org/jdk/pull/26867

From kdnilsen at openjdk.org  Tue Sep  9 21:02:15 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 9 Sep 2025 21:02:15 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <FCpDu7mIedyahqaXcv2tCoqcZwFoI0Hb2XnoiVBzT_E=.938071d2-95d9-4d58-9fa6-6e02b89fefc3@github.com>

On Wed, 20 Aug 2025 19:17:48 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
> 
> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
> 
> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.

This code now passes all internal CI tests.

The attached shows  some performance results on a SpecJBB workload for Generational Shenandoah and Traditional Shenandoah.  We see general improvements.  This presumably results from not having to maintain two synchronization mechanisms for two separate sets of "books".

<img width="369" height="139" alt="Screenshot 2025-09-09 at 1 53 53?PM" src="https://github.com/user-attachments/assets/c656c775-c710-48fd-975e-07e45156aa48" />

<img width="369" height="139" alt="Screenshot 2025-09-09 at 1 55 06?PM" src="https://github.com/user-attachments/assets/b2097fb6-82cf-4b7b-a37a-6b44acb44d7e" />

We also see general improvement running an Extremem workload.

<img width="1736" height="682" alt="Screenshot 2025-09-09 at 1 56 02?PM" src="https://github.com/user-attachments/assets/65e68ec7-5ead-4f38-b49a-2d625ab81ec4" />

Analysis of these results has revealed a shortcoming in the Generational version of Final Update Refs safepoint, which accounts for the higher p99.999 and p100 latencies of GenShen compared to Shen.  In a separate PR, we will be moving the Flush SATB buffer action out of the safepoint, performing this work in a handshake instead.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26867#issuecomment-3272248200

From kdnilsen at openjdk.org  Tue Sep  9 21:10:01 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 9 Sep 2025 21:10:01 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v2]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <T79cZPmpaFg2GdwJ8DmvyvrQMFl2nf2pQ4NOGG4vtNU=.a9b5115d-f509-43f7-b6cf-d9d52e2cc5bf@github.com>

> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
> 
> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
> 
> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  Add include file for missing declaration

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/87e26b37..a77eb75d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26867.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26867/head:pull/26867

PR: https://git.openjdk.org/jdk/pull/26867

From kdnilsen at openjdk.org  Tue Sep  9 22:07:11 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 9 Sep 2025 22:07:11 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v3]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <dEUIaXmSftNpVQ-tqfFsAXetwlMbvEBWqbMp9vdTTPY=.da1e4904-f814-434d-b2e9-25aa1ded47d5@github.com>

> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
> 
> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
> 
> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  another tweak to make GHA gtest happy

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/a77eb75d..cd9522af

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=01-02

  Stats: 9 lines in 1 file changed: 0 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/26867.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26867/head:pull/26867

PR: https://git.openjdk.org/jdk/pull/26867

From wkemper at openjdk.org  Tue Sep  9 22:09:02 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 9 Sep 2025 22:09:02 GMT
Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may
 raise threshold prematurely [v5]
In-Reply-To: <a0xbCmn50ELDPEhLMbdtdnTGeC6Io9Uammhf6XF4cZM=.6003fa95-8b51-4a56-b8cd-b7d53b4ba7fd@github.com>
References: <a0xbCmn50ELDPEhLMbdtdnTGeC6Io9Uammhf6XF4cZM=.6003fa95-8b51-4a56-b8cd-b7d53b4ba7fd@github.com>
Message-ID: <E7REoG0yKecrPhN65iUcJXLlTmicD9hOD0w0Jy1eED8=.dcda48f1-d269-4f9f-9271-25487bfe2ceb@github.com>

> The adaptive tenuring algorithm has been modified to begin its evaluation of mortality rates from the current tenuring threshold. To compliment this change, objects must also now be strictly above the tenuring threshold to be promoted (instead of greater-than-or-equal).

William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision:

 - Fix include order
 - Add missing newline
 - Fix typo
 - Merge tag 'jdk-26+14' into adaptive-tenuring-threshold
   
   Added tag jdk-26+14 for changeset ab9f70dd
 - Do not require objects to be strictly older than the tenuring threshold
 - Log updated tenuring age at info, log age table at debug
 - Be consistent when comparing tenuring threshold with ages
 - Fix windows build
 - Fix release build
 - Revert unintended change
 - ... and 10 more: https://git.openjdk.org/jdk/compare/557d3a94...0ffa89c5

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26906/files
  - new: https://git.openjdk.org/jdk/pull/26906/files/658f76f7..0ffa89c5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26906&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26906&range=03-04

  Stats: 24118 lines in 1089 files changed: 16766 ins; 3687 del; 3665 mod
  Patch: https://git.openjdk.org/jdk/pull/26906.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26906/head:pull/26906

PR: https://git.openjdk.org/jdk/pull/26906

From wkemper at openjdk.org  Tue Sep  9 22:09:04 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 9 Sep 2025 22:09:04 GMT
Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may
 raise threshold prematurely [v3]
In-Reply-To: <F62Ov4-foXX5k-inl4XO2hx_TGQj1nrf9BmAvjJpqBw=.f460cb67-621d-493d-bbb1-2cf9b978742d@github.com>
References: <a0xbCmn50ELDPEhLMbdtdnTGeC6Io9Uammhf6XF4cZM=.6003fa95-8b51-4a56-b8cd-b7d53b4ba7fd@github.com>
 <GxnQowl_uv6hL5gO26Qo88aVZWfnLgLPRghlIJilR3I=.29442648-30ae-461c-a1ba-40a4358085ec@github.com>
 <F62Ov4-foXX5k-inl4XO2hx_TGQj1nrf9BmAvjJpqBw=.f460cb67-621d-493d-bbb1-2cf9b978742d@github.com>
Message-ID: <k82pC4utQFVfnH7FApwVB9zdZiJv9SAej7GpPKfo_E8=.5fb16bb1-cd7f-4bfe-ac6b-5eba6af2c836@github.com>

On Thu, 28 Aug 2025 01:06:19 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix windows build
>
> Also, are there any comparative performance numbers to share yet?

@ysramakrishna - no appreciable changes in our performance benchmarks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26906#issuecomment-3272425061

From kdnilsen at openjdk.org  Tue Sep  9 22:34:33 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 9 Sep 2025 22:34:33 GMT
Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may
 raise threshold prematurely [v5]
In-Reply-To: <E7REoG0yKecrPhN65iUcJXLlTmicD9hOD0w0Jy1eED8=.dcda48f1-d269-4f9f-9271-25487bfe2ceb@github.com>
References: <a0xbCmn50ELDPEhLMbdtdnTGeC6Io9Uammhf6XF4cZM=.6003fa95-8b51-4a56-b8cd-b7d53b4ba7fd@github.com>
 <E7REoG0yKecrPhN65iUcJXLlTmicD9hOD0w0Jy1eED8=.dcda48f1-d269-4f9f-9271-25487bfe2ceb@github.com>
Message-ID: <6-E3njfrTUmO1C2fV6L9OFG2av0Ct5bpf8gvjcwAPyo=.a3847570-8ccf-4871-9abc-6c264718d70e@github.com>

On Tue, 9 Sep 2025 22:09:02 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> The adaptive tenuring algorithm has been modified to begin its evaluation of mortality rates from the current tenuring threshold. To compliment this change, objects must also now be strictly above the tenuring threshold to be promoted (instead of greater-than-or-equal).
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision:
> 
>  - Fix include order
>  - Add missing newline
>  - Fix typo
>  - Merge tag 'jdk-26+14' into adaptive-tenuring-threshold
>    
>    Added tag jdk-26+14 for changeset ab9f70dd
>  - Do not require objects to be strictly older than the tenuring threshold
>  - Log updated tenuring age at info, log age table at debug
>  - Be consistent when comparing tenuring threshold with ages
>  - Fix windows build
>  - Fix release build
>  - Revert unintended change
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/2b231502...0ffa89c5

Thanks for chasing down the performance regression.  Looks good.

src/hotspot/share/gc/shenandoah/shenandoahAgeCensus.hpp line 186:

> 184: 
> 185:   // Return true if this age is at or above the tenuring threshold.
> 186:   bool is_tenurable(uint age) const {

might want to mark this as inline.  (if in-lined, this might be the right way to check whether individual objects should be promoted.  But I don't want to delay integration of this PR, so maybe that could be done in a different PR if we think it worthwhile.)

-------------

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26906#pullrequestreview-3203541920
PR Review Comment: https://git.openjdk.org/jdk/pull/26906#discussion_r2334950649

From kdnilsen at openjdk.org  Tue Sep  9 22:34:34 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 9 Sep 2025 22:34:34 GMT
Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may
 raise threshold prematurely [v5]
In-Reply-To: <6-E3njfrTUmO1C2fV6L9OFG2av0Ct5bpf8gvjcwAPyo=.a3847570-8ccf-4871-9abc-6c264718d70e@github.com>
References: <a0xbCmn50ELDPEhLMbdtdnTGeC6Io9Uammhf6XF4cZM=.6003fa95-8b51-4a56-b8cd-b7d53b4ba7fd@github.com>
 <E7REoG0yKecrPhN65iUcJXLlTmicD9hOD0w0Jy1eED8=.dcda48f1-d269-4f9f-9271-25487bfe2ceb@github.com>
 <6-E3njfrTUmO1C2fV6L9OFG2av0Ct5bpf8gvjcwAPyo=.a3847570-8ccf-4871-9abc-6c264718d70e@github.com>
Message-ID: <ClXnGLYPio3W6uzsS9WfGdZo5sJ7rCGLrrbYHSZR1QI=.f5d1806a-6576-43cc-8749-33ea720f2871@github.com>

On Tue, 9 Sep 2025 22:24:41 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision:
>> 
>>  - Fix include order
>>  - Add missing newline
>>  - Fix typo
>>  - Merge tag 'jdk-26+14' into adaptive-tenuring-threshold
>>    
>>    Added tag jdk-26+14 for changeset ab9f70dd
>>  - Do not require objects to be strictly older than the tenuring threshold
>>  - Log updated tenuring age at info, log age table at debug
>>  - Be consistent when comparing tenuring threshold with ages
>>  - Fix windows build
>>  - Fix release build
>>  - Revert unintended change
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/2b231502...0ffa89c5
>
> src/hotspot/share/gc/shenandoah/shenandoahAgeCensus.hpp line 186:
> 
>> 184: 
>> 185:   // Return true if this age is at or above the tenuring threshold.
>> 186:   bool is_tenurable(uint age) const {
> 
> might want to mark this as inline.  (if in-lined, this might be the right way to check whether individual objects should be promoted.  But I don't want to delay integration of this PR, so maybe that could be done in a different PR if we think it worthwhile.)

Ok.  I see that ShenandoahGenerationalHeap::is_tenurable() is in-lined.  That's probably the one that matters the most.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26906#discussion_r2334963712

From wkemper at openjdk.org  Tue Sep  9 23:48:14 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 9 Sep 2025 23:48:14 GMT
Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may
 raise threshold prematurely [v5]
In-Reply-To: <ClXnGLYPio3W6uzsS9WfGdZo5sJ7rCGLrrbYHSZR1QI=.f5d1806a-6576-43cc-8749-33ea720f2871@github.com>
References: <a0xbCmn50ELDPEhLMbdtdnTGeC6Io9Uammhf6XF4cZM=.6003fa95-8b51-4a56-b8cd-b7d53b4ba7fd@github.com>
 <E7REoG0yKecrPhN65iUcJXLlTmicD9hOD0w0Jy1eED8=.dcda48f1-d269-4f9f-9271-25487bfe2ceb@github.com>
 <6-E3njfrTUmO1C2fV6L9OFG2av0Ct5bpf8gvjcwAPyo=.a3847570-8ccf-4871-9abc-6c264718d70e@github.com>
 <ClXnGLYPio3W6uzsS9WfGdZo5sJ7rCGLrrbYHSZR1QI=.f5d1806a-6576-43cc-8749-33ea720f2871@github.com>
Message-ID: <k-2BIBkBd5-ziXnzsFq5MP6AwG_P4HMsG7gbQjwRXLI=.48ef5e19-8931-4495-93f8-8a48545d60ab@github.com>

On Tue, 9 Sep 2025 22:31:19 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahAgeCensus.hpp line 186:
>> 
>>> 184: 
>>> 185:   // Return true if this age is at or above the tenuring threshold.
>>> 186:   bool is_tenurable(uint age) const {
>> 
>> might want to mark this as inline.  (if in-lined, this might be the right way to check whether individual objects should be promoted.  But I don't want to delay integration of this PR, so maybe that could be done in a different PR if we think it worthwhile.)
>
> Ok.  I see that ShenandoahGenerationalHeap::is_tenurable() is in-lined.  That's probably the one that matters the most.

Anything defined in the header is implicitly inlined.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26906#discussion_r2335110857

From kbarrett at openjdk.org  Wed Sep 10 07:34:09 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 10 Sep 2025 07:34:09 GMT
Subject: RFR: 8367014: Rename class Atomic to AtomicAccess [v2]
In-Reply-To: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
References: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
Message-ID: <8HMzxvTwZd1uSZCs528eM4pHsJVeKmFGtplElc8vXpk=.643b3706-7af2-40aa-835c-c3f8a785dd0e@github.com>

> Please review this change that renames the all-static class `Atomic` to
> `AtomicAccess`. The reason for this name change is to allow the introduction
> of the new type `Atomic<T>` ([JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013)).
> 
> The PR has several commits, according to the specific category of change being
> made. It may be easier to review the PR by studying these individual commits.
> 
> Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose
> to not rename the various "atomic_<cpu>.*" and "atomic_<os>_<cpu>.*" files.
> 
> There are a number of comments containing the word "Atomic" that I didn't
> change. They are generically about atomic operations, and will just as well
> serve as referring to the future `Atomic<T>`.
> 
> Testing: mach5 tier1, GHA sanity tests.
> This is one of those changes where successful builds indicate the change is good.

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - rename recently added Atomic:: => AtomicAccess::
 - Merge branch 'master' into atomic-access
 - fix prefiously missed arg misalignments
 - rename test_atomic.cpp
 - update copyrights
 - misc cleanups
 - fix indentation from rename
 - rename Atomic => AtomicAccess in gtests
 - rename Atomic => AtomicAccess
 - change includes of atomic.hpp in gtests
 - ... and 2 more: https://git.openjdk.org/jdk/compare/af9b9050...11007c45

-------------

Changes: https://git.openjdk.org/jdk/pull/27135/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27135&range=01
  Stats: 5577 lines in 430 files changed: 1587 ins; 1585 del; 2405 mod
  Patch: https://git.openjdk.org/jdk/pull/27135.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27135/head:pull/27135

PR: https://git.openjdk.org/jdk/pull/27135

From kbarrett at openjdk.org  Wed Sep 10 07:34:11 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 10 Sep 2025 07:34:11 GMT
Subject: RFR: 8367014: Rename class Atomic to AtomicAccess [v2]
In-Reply-To: <iDpU5TCdK05ZWAVCbaI7KAFEn6htGCLJE-4O5Whaf0s=.640b886d-5f1f-45af-b947-7506dd0d97e9@github.com>
References: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
 <iDpU5TCdK05ZWAVCbaI7KAFEn6htGCLJE-4O5Whaf0s=.640b886d-5f1f-45af-b947-7506dd0d97e9@github.com>
Message-ID: <Mgcv8v1mlWQx038Q1ZXbttfdtwZlc7fEnAfvW8zSIOg=.5391ed7d-974c-400c-a0b6-c69d6b8eb4b4@github.com>

On Tue, 9 Sep 2025 11:49:26 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> > Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose
> > to not rename the various "atomic_." and "atomic__." files.
> 
> Could you motivate why you chose to not do that?

I thought about it, and waffled back and forth. But I was trying to do as much
as possible of this change mechanically. Renaming a file involves multiple
steps that weren't all easily scriptable. (And I'd already messed up a part of
the renaming of atomic.hpp during patch development.) Also, this change is
going to be hard for backports as it is, and I think renamings might make that
worse. Renamings can also be annoying for archeology. But if you think it's
important...

> src/hotspot/os_cpu/bsd_x86/atomic_bsd_x86.hpp line 43:
> 
>> 41: template<>
>> 42: template<typename D, typename I>
>> 43: inline D AtomicAccess::PlatformAdd<4>::fetch_then_add(D volatile* dest, I add_value,
> 
> This file has multiple alignment issues.

Oops, completely missed that file.  Will fix.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27135#issuecomment-3273667707
PR Review Comment: https://git.openjdk.org/jdk/pull/27135#discussion_r2335809380

From kbarrett at openjdk.org  Wed Sep 10 07:34:12 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 10 Sep 2025 07:34:12 GMT
Subject: RFR: 8367014: Rename class Atomic to AtomicAccess
In-Reply-To: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
References: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
Message-ID: <rR6GvHDl1M50PWJjcUUruJaWvMEAeTcPK9ubMpkRd28=.ded50ad8-7757-4624-95be-f3d468adb54d@github.com>

On Mon, 8 Sep 2025 06:26:03 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that renames the all-static class `Atomic` to
> `AtomicAccess`. The reason for this name change is to allow the introduction
> of the new type `Atomic<T>` ([JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013)).
> 
> The PR has several commits, according to the specific category of change being
> made. It may be easier to review the PR by studying these individual commits.
> 
> Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose
> to not rename the various "atomic_<cpu>.*" and "atomic_<os>_<cpu>.*" files.
> 
> There are a number of comments containing the word "Atomic" that I didn't
> change. They are generically about atomic operations, and will just as well
> serve as referring to the future `Atomic<T>`.
> 
> Testing: mach5 tier1, GHA sanity tests.
> This is one of those changes where successful builds indicate the change is good.

Updated for recent commits adding some new uses of `Atomic::` and merge conflicts. Running GHA sanity tests.
mach5 tier1 already passed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27135#issuecomment-3273675624

From aph at openjdk.org  Wed Sep 10 07:43:37 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 10 Sep 2025 07:43:37 GMT
Subject: RFR: 8367014: Rename class Atomic to AtomicAccess [v2]
In-Reply-To: <Mgcv8v1mlWQx038Q1ZXbttfdtwZlc7fEnAfvW8zSIOg=.5391ed7d-974c-400c-a0b6-c69d6b8eb4b4@github.com>
References: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
 <iDpU5TCdK05ZWAVCbaI7KAFEn6htGCLJE-4O5Whaf0s=.640b886d-5f1f-45af-b947-7506dd0d97e9@github.com>
 <Mgcv8v1mlWQx038Q1ZXbttfdtwZlc7fEnAfvW8zSIOg=.5391ed7d-974c-400c-a0b6-c69d6b8eb4b4@github.com>
Message-ID: <OYC0XgAFLzN_Kvj9pJZfkQNkg3daoisgjU_lna1CTM0=.a4a18c4d-d501-4461-9976-ff2551a88209@github.com>

On Wed, 10 Sep 2025 07:23:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Also, this change is
> going to be hard for backports as it is, and I think renamings might make that
> worse. Renamings can also be annoying for archeology.

Speaking as an archaeologist and the lead of multiple backport projects, I agree with you, Kim.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27135#issuecomment-3273724381

From stefank at openjdk.org  Wed Sep 10 08:56:25 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 10 Sep 2025 08:56:25 GMT
Subject: RFR: 8367014: Rename class Atomic to AtomicAccess [v2]
In-Reply-To: <Mgcv8v1mlWQx038Q1ZXbttfdtwZlc7fEnAfvW8zSIOg=.5391ed7d-974c-400c-a0b6-c69d6b8eb4b4@github.com>
References: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
 <iDpU5TCdK05ZWAVCbaI7KAFEn6htGCLJE-4O5Whaf0s=.640b886d-5f1f-45af-b947-7506dd0d97e9@github.com>
 <Mgcv8v1mlWQx038Q1ZXbttfdtwZlc7fEnAfvW8zSIOg=.5391ed7d-974c-400c-a0b6-c69d6b8eb4b4@github.com>
Message-ID: <HRnDxKuZ3LesQsDPfU1YHhv6PijVH6i3lGA7j5a2NdA=.fe6f81b2-0934-40ac-86a6-d3ab6dfd1e81@github.com>

On Wed, 10 Sep 2025 07:23:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> > > Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose
> > > to not rename the various "atomic_." and "atomic__." files.
> > 
> > 
> > Could you motivate why you chose to not do that?
> 
> I thought about it, and waffled back and forth. But I was trying to do as much as possible of this change mechanically. Renaming a file involves multiple steps that weren't all easily scriptable. (And I'd already messed up a part of the renaming of atomic.hpp during patch development.) Also, this change is going to be hard for backports as it is, and I think renamings might make that worse. Renamings can also be annoying for archeology. But if you think it's important...

Sure, renames are annoying. I do think that it is bad to leave inconsistent names in a long-lived, evolving code base.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27135#issuecomment-3273979685

From duke at openjdk.org  Wed Sep 10 09:22:35 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Wed, 10 Sep 2025 09:22:35 GMT
Subject: RFR: 8367320: Sort cpu/x86 includes
Message-ID: <qcY0LlIm4IjPerZIS-HXD7szCbJ9WvkADuu56oSKj4U=.9de36603-eefd-4de0-bcf6-8f7e311f4863@github.com>

Sort includes in `cpu/x86` using `SortIncludes.java`. I'm also removing a couple unnecessary ones.

Passes `tier1` and `tier2`.

-------------

Commit messages:
 - revert
 - sort

Changes: https://git.openjdk.org/jdk/pull/27189/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27189&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367320
  Stats: 107 lines in 40 files changed: 45 ins; 61 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27189.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27189/head:pull/27189

PR: https://git.openjdk.org/jdk/pull/27189

From ayang at openjdk.org  Wed Sep 10 09:36:37 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 10 Sep 2025 09:36:37 GMT
Subject: RFR: 8367320: Sort cpu/x86 includes
In-Reply-To: <qcY0LlIm4IjPerZIS-HXD7szCbJ9WvkADuu56oSKj4U=.9de36603-eefd-4de0-bcf6-8f7e311f4863@github.com>
References: <qcY0LlIm4IjPerZIS-HXD7szCbJ9WvkADuu56oSKj4U=.9de36603-eefd-4de0-bcf6-8f7e311f4863@github.com>
Message-ID: <NPOWGZuSFOfgg9Zl-UxLZJf-UYMR-iH5RGgHWizEbqI=.43f387be-e2b1-4c8b-a4ec-204610c0c4e7@github.com>

On Wed, 10 Sep 2025 09:17:07 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> Sort includes in `cpu/x86` using `SortIncludes.java`. I'm also removing a couple unnecessary ones.
> 
> Passes `tier1` and `tier2`.

src/hotspot/cpu/x86/continuationEntry_x86.inline.hpp line 29:

> 27: 
> 28: #include "oops/method.inline.hpp"
> 29: #include "runtime/continuationEntry.hpp"

I believe this is the "corresponding .hpp" in "All .inline.hpp files should include their corresponding .hpp file as the first include line..." from the style-guide, so should be kept at the top.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27189#discussion_r2336167042

From duke at openjdk.org  Wed Sep 10 10:10:49 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Wed, 10 Sep 2025 10:10:49 GMT
Subject: RFR: 8367320: Sort cpu/x86 includes
In-Reply-To: <NPOWGZuSFOfgg9Zl-UxLZJf-UYMR-iH5RGgHWizEbqI=.43f387be-e2b1-4c8b-a4ec-204610c0c4e7@github.com>
References: <qcY0LlIm4IjPerZIS-HXD7szCbJ9WvkADuu56oSKj4U=.9de36603-eefd-4de0-bcf6-8f7e311f4863@github.com>
 <NPOWGZuSFOfgg9Zl-UxLZJf-UYMR-iH5RGgHWizEbqI=.43f387be-e2b1-4c8b-a4ec-204610c0c4e7@github.com>
Message-ID: <m4QmYeOpn0Ofg0paXUl3SURG72Vgcoo3zG9t31i2QLw=.e1fa198f-8f15-41ce-979f-9fdfd2abf1d3@github.com>

On Wed, 10 Sep 2025 09:33:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Sort includes in `cpu/x86` using `SortIncludes.java`. I'm also removing a couple unnecessary ones.
>> 
>> Passes `tier1` and `tier2`.
>
> src/hotspot/cpu/x86/continuationEntry_x86.inline.hpp line 29:
> 
>> 27: 
>> 28: #include "oops/method.inline.hpp"
>> 29: #include "runtime/continuationEntry.hpp"
> 
> I believe this is the "corresponding .hpp" in "All .inline.hpp files should include their corresponding .hpp file as the first include line..." from the style-guide, so should be kept at the top.

I see. There's already a `continuationEntry_x86.hpp` in `cpu/x86`, maybe the `#include "runtime/continuationEntry.hpp"` should go there instead, and `continuationEntry_x86.inline.hpp` should include `continuationEntry_x86.hpp`? 

This would solve the problem without requiring changes in `SortIncludes.java`, which is not very flexible in terms of the relation between the names of the `.hpp` file and the corresponding `.inline.hpp` :

String nonInlineHpp = pathString.replace(".inline.hpp", ".hpp");

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27189#discussion_r2336257257

From duke at openjdk.org  Wed Sep 10 14:50:21 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Wed, 10 Sep 2025 14:50:21 GMT
Subject: RFR: 8367320: Sort cpu/x86 includes [v2]
In-Reply-To: <qcY0LlIm4IjPerZIS-HXD7szCbJ9WvkADuu56oSKj4U=.9de36603-eefd-4de0-bcf6-8f7e311f4863@github.com>
References: <qcY0LlIm4IjPerZIS-HXD7szCbJ9WvkADuu56oSKj4U=.9de36603-eefd-4de0-bcf6-8f7e311f4863@github.com>
Message-ID: <uJxrEpfWrvgPfNCgOnTFCGUMNPWnpRFD37ShnSio-nk=.ba8506fc-b091-4540-8647-2d888f037c0a@github.com>

> Sort includes in `cpu/x86` using `SortIncludes.java`. I'm also removing a couple unnecessary ones.
> 
> Passes `tier1` and `tier2`.

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  inline stuff

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27189/files
  - new: https://git.openjdk.org/jdk/pull/27189/files/30263b81..d7204d8f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27189&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27189&range=00-01

  Stats: 5 lines in 2 files changed: 4 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27189.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27189/head:pull/27189

PR: https://git.openjdk.org/jdk/pull/27189

From duke at openjdk.org  Wed Sep 10 14:50:23 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Wed, 10 Sep 2025 14:50:23 GMT
Subject: RFR: 8367320: Sort cpu/x86 includes [v2]
In-Reply-To: <m4QmYeOpn0Ofg0paXUl3SURG72Vgcoo3zG9t31i2QLw=.e1fa198f-8f15-41ce-979f-9fdfd2abf1d3@github.com>
References: <qcY0LlIm4IjPerZIS-HXD7szCbJ9WvkADuu56oSKj4U=.9de36603-eefd-4de0-bcf6-8f7e311f4863@github.com>
 <NPOWGZuSFOfgg9Zl-UxLZJf-UYMR-iH5RGgHWizEbqI=.43f387be-e2b1-4c8b-a4ec-204610c0c4e7@github.com>
 <m4QmYeOpn0Ofg0paXUl3SURG72Vgcoo3zG9t31i2QLw=.e1fa198f-8f15-41ce-979f-9fdfd2abf1d3@github.com>
Message-ID: <OEpLsYqopqFIwfloxT5MHsJeImNHQMIh9UrokdyEomo=.cdba39e1-8a76-4af1-824b-bf65d158f695@github.com>

On Wed, 10 Sep 2025 10:08:31 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> src/hotspot/cpu/x86/continuationEntry_x86.inline.hpp line 29:
>> 
>>> 27: 
>>> 28: #include "oops/method.inline.hpp"
>>> 29: #include "runtime/continuationEntry.hpp"
>> 
>> I believe this is the "corresponding .hpp" in "All .inline.hpp files should include their corresponding .hpp file as the first include line..." from the style-guide, so should be kept at the top.
>
> I see. There's already a `continuationEntry_x86.hpp` in `cpu/x86`, maybe the `#include "runtime/continuationEntry.hpp"` should go there instead, and `continuationEntry_x86.inline.hpp` should include `continuationEntry_x86.hpp`? 
> 
> This would solve the problem without requiring changes in `SortIncludes.java`, which is not very flexible in terms of the relation between the names of the `.hpp` file and the corresponding `.inline.hpp` :
> 
> String nonInlineHpp = pathString.replace(".inline.hpp", ".hpp");

d7204d8f32399c9b437fbf83d9f66f068cc0a171

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27189#discussion_r2337020701

From ayang at openjdk.org  Wed Sep 10 15:50:38 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 10 Sep 2025 15:50:38 GMT
Subject: RFR: 8367320: Sort cpu/x86 includes [v2]
In-Reply-To: <uJxrEpfWrvgPfNCgOnTFCGUMNPWnpRFD37ShnSio-nk=.ba8506fc-b091-4540-8647-2d888f037c0a@github.com>
References: <qcY0LlIm4IjPerZIS-HXD7szCbJ9WvkADuu56oSKj4U=.9de36603-eefd-4de0-bcf6-8f7e311f4863@github.com>
 <uJxrEpfWrvgPfNCgOnTFCGUMNPWnpRFD37ShnSio-nk=.ba8506fc-b091-4540-8647-2d888f037c0a@github.com>
Message-ID: <SEbNcGLpW0yfTiFrVP5TCq7_44jOAE-eIBKMLuyVZng=.6303168d-2591-4e72-a1ac-99a608784e8d@github.com>

On Wed, 10 Sep 2025 14:50:21 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> Sort includes in `cpu/x86` using `SortIncludes.java`. I'm also removing a couple unnecessary ones.
>> 
>> Passes `tier1` and `tier2`.
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   inline stuff

src/hotspot/cpu/x86/continuationHelper_x86.inline.hpp line 29:

> 27: 
> 28: #include "runtime/continuationEntry.inline.hpp"
> 29: #include "runtime/continuationHelper.hpp"

I think this is another case where the intention was that `continuationHelper.hpp` is the corresponding hpp and should be placed at the top.

I wonder if the script should/can be revised a bit to recognize this pattern.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27189#discussion_r2337196317

From duke at openjdk.org  Wed Sep 10 16:12:24 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Wed, 10 Sep 2025 16:12:24 GMT
Subject: RFR: 8367320: Sort cpu/x86 includes [v2]
In-Reply-To: <SEbNcGLpW0yfTiFrVP5TCq7_44jOAE-eIBKMLuyVZng=.6303168d-2591-4e72-a1ac-99a608784e8d@github.com>
References: <qcY0LlIm4IjPerZIS-HXD7szCbJ9WvkADuu56oSKj4U=.9de36603-eefd-4de0-bcf6-8f7e311f4863@github.com>
 <uJxrEpfWrvgPfNCgOnTFCGUMNPWnpRFD37ShnSio-nk=.ba8506fc-b091-4540-8647-2d888f037c0a@github.com>
 <SEbNcGLpW0yfTiFrVP5TCq7_44jOAE-eIBKMLuyVZng=.6303168d-2591-4e72-a1ac-99a608784e8d@github.com>
Message-ID: <cc3NNxUCaYZGZntgK1VfPijHJaJqFLRaddVbGXQdrwk=.6d24ac68-c79c-48c6-b521-fba161e306ac@github.com>

On Wed, 10 Sep 2025 15:47:59 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   inline stuff
>
> src/hotspot/cpu/x86/continuationHelper_x86.inline.hpp line 29:
> 
>> 27: 
>> 28: #include "runtime/continuationEntry.inline.hpp"
>> 29: #include "runtime/continuationHelper.hpp"
> 
> I think this is another case where the intention was that `continuationHelper.hpp` is the corresponding hpp and should be placed at the top.
> 
> I wonder if the script should/can be revised a bit to recognize this pattern.

I think the style guide should be changed too if we want to make this change:

All .inline.hpp files should include their corresponding .hpp file as
the first include line with a blank line separating it from the rest of the
include lines.


There should be some more details about what constitutes the "corresponding .hpp file". In the case of your [comment above](https://github.com/openjdk/jdk/pull/27189#discussion_r2336167042) in this PR, the `.inline.hpp` file had a clear "corresponding `.hpp` file", namely `continuationEntry_x86.hpp`. 

Should the style guide state something like "the corresponding `.hpp` file for a `inline.hpp` whose name contains some compilation flag-dependent qualifier, is either the `.hpp` file with the qualifier (if present) or the `.hpp` file without the qualifier as a fallback" ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27189#discussion_r2337246309

From wkemper at openjdk.org  Wed Sep 10 18:06:40 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 10 Sep 2025 18:06:40 GMT
Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may
 raise threshold prematurely [v5]
In-Reply-To: <E7REoG0yKecrPhN65iUcJXLlTmicD9hOD0w0Jy1eED8=.dcda48f1-d269-4f9f-9271-25487bfe2ceb@github.com>
References: <a0xbCmn50ELDPEhLMbdtdnTGeC6Io9Uammhf6XF4cZM=.6003fa95-8b51-4a56-b8cd-b7d53b4ba7fd@github.com>
 <E7REoG0yKecrPhN65iUcJXLlTmicD9hOD0w0Jy1eED8=.dcda48f1-d269-4f9f-9271-25487bfe2ceb@github.com>
Message-ID: <XLSvkEGmTrWDzBTbz9ncolMzuDyQko2iw32wN7XAmxU=.c682a8d8-ad77-464f-8b42-67f21fdc97b6@github.com>

On Tue, 9 Sep 2025 22:09:02 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> The adaptive tenuring algorithm has been modified to begin its evaluation of mortality rates from the current tenuring threshold. To compliment this change, objects must also now be strictly above the tenuring threshold to be promoted (instead of greater-than-or-equal).
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision:
> 
>  - Fix include order
>  - Add missing newline
>  - Fix typo
>  - Merge tag 'jdk-26+14' into adaptive-tenuring-threshold
>    
>    Added tag jdk-26+14 for changeset ab9f70dd
>  - Do not require objects to be strictly older than the tenuring threshold
>  - Log updated tenuring age at info, log age table at debug
>  - Be consistent when comparing tenuring threshold with ages
>  - Fix windows build
>  - Fix release build
>  - Revert unintended change
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/a4290181...0ffa89c5

Test failures do not look related to these changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26906#issuecomment-3275987994

From kdnilsen at openjdk.org  Wed Sep 10 20:45:00 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 10 Sep 2025 20:45:00 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v3]
In-Reply-To: <dEUIaXmSftNpVQ-tqfFsAXetwlMbvEBWqbMp9vdTTPY=.da1e4904-f814-434d-b2e9-25aa1ded47d5@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
 <dEUIaXmSftNpVQ-tqfFsAXetwlMbvEBWqbMp9vdTTPY=.da1e4904-f814-434d-b2e9-25aa1ded47d5@github.com>
Message-ID: <0DIlqJVwgCnx2FvbXZuDySjJ3hz241ag41o3BCHkSuY=.ac51c769-c5c0-4750-99b4-0ff43f864d33@github.com>

On Tue, 9 Sep 2025 22:07:11 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
>> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
>> 
>> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
>> 
>> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   another tweak to make GHA gtest happy

src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 372:

> 370:       _last_sample_time = now;
> 371:       _last_sample_value = allocated;
> 372:     }

This was a bug.  If we don't update the average, we should not restart the time until next sample and we should not overwrite the value of _last_sample_value.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2337848793

From phh at openjdk.org  Wed Sep 10 22:05:58 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 10 Sep 2025 22:05:58 GMT
Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may
 raise threshold prematurely [v5]
In-Reply-To: <E7REoG0yKecrPhN65iUcJXLlTmicD9hOD0w0Jy1eED8=.dcda48f1-d269-4f9f-9271-25487bfe2ceb@github.com>
References: <a0xbCmn50ELDPEhLMbdtdnTGeC6Io9Uammhf6XF4cZM=.6003fa95-8b51-4a56-b8cd-b7d53b4ba7fd@github.com>
 <E7REoG0yKecrPhN65iUcJXLlTmicD9hOD0w0Jy1eED8=.dcda48f1-d269-4f9f-9271-25487bfe2ceb@github.com>
Message-ID: <fLW-gqgv8YOGnY7u1-eNWoHyUWzUJmdPKMQ4BFyq7oc=.b982daa0-3402-43ce-805a-28d4ad3f6d0b@github.com>

On Tue, 9 Sep 2025 22:09:02 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> The adaptive tenuring algorithm has been modified to begin its evaluation of mortality rates from the current tenuring threshold. To compliment this change, objects must also now be strictly above the tenuring threshold to be promoted (instead of greater-than-or-equal).
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision:
> 
>  - Fix include order
>  - Add missing newline
>  - Fix typo
>  - Merge tag 'jdk-26+14' into adaptive-tenuring-threshold
>    
>    Added tag jdk-26+14 for changeset ab9f70dd
>  - Do not require objects to be strictly older than the tenuring threshold
>  - Log updated tenuring age at info, log age table at debug
>  - Be consistent when comparing tenuring threshold with ages
>  - Fix windows build
>  - Fix release build
>  - Revert unintended change
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/a2c26721...0ffa89c5

Looks good from a sw engineering pov (the vast majority of the changes are that). I can't definitively say that the functionality change is the right thing, but seems reasonable. I'll go by Ramki's judgement.

-------------

Marked as reviewed by phh (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26906#pullrequestreview-3207975609

From wkemper at openjdk.org  Wed Sep 10 22:14:59 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 10 Sep 2025 22:14:59 GMT
Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may
 raise threshold prematurely [v5]
In-Reply-To: <fLW-gqgv8YOGnY7u1-eNWoHyUWzUJmdPKMQ4BFyq7oc=.b982daa0-3402-43ce-805a-28d4ad3f6d0b@github.com>
References: <a0xbCmn50ELDPEhLMbdtdnTGeC6Io9Uammhf6XF4cZM=.6003fa95-8b51-4a56-b8cd-b7d53b4ba7fd@github.com>
 <E7REoG0yKecrPhN65iUcJXLlTmicD9hOD0w0Jy1eED8=.dcda48f1-d269-4f9f-9271-25487bfe2ceb@github.com>
 <fLW-gqgv8YOGnY7u1-eNWoHyUWzUJmdPKMQ4BFyq7oc=.b982daa0-3402-43ce-805a-28d4ad3f6d0b@github.com>
Message-ID: <2LxUvCMZ3k_Z0pzeJTs4kMF3FUjwexh8oj208skeP60=.ca96561e-6200-42b3-b1be-da295a88dd89@github.com>

On Wed, 10 Sep 2025 22:03:08 GMT, Paul Hohensee <phh at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision:
>> 
>>  - Fix include order
>>  - Add missing newline
>>  - Fix typo
>>  - Merge tag 'jdk-26+14' into adaptive-tenuring-threshold
>>    
>>    Added tag jdk-26+14 for changeset ab9f70dd
>>  - Do not require objects to be strictly older than the tenuring threshold
>>  - Log updated tenuring age at info, log age table at debug
>>  - Be consistent when comparing tenuring threshold with ages
>>  - Fix windows build
>>  - Fix release build
>>  - Revert unintended change
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/f4bf1efb...0ffa89c5
>
> Looks good from a sw engineering pov (the vast majority of the changes are that). I can't definitively say that the functionality change is the right thing, but seems reasonable. I'll go by Ramki's judgement.

Thanks @phohensee . The change is sort of subtle and won't be noticed on every workload.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26906#issuecomment-3276702155

From wkemper at openjdk.org  Wed Sep 10 22:15:00 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 10 Sep 2025 22:15:00 GMT
Subject: Integrated: 8365956: GenShen: Adaptive tenuring threshold algorithm
 may raise threshold prematurely
In-Reply-To: <a0xbCmn50ELDPEhLMbdtdnTGeC6Io9Uammhf6XF4cZM=.6003fa95-8b51-4a56-b8cd-b7d53b4ba7fd@github.com>
References: <a0xbCmn50ELDPEhLMbdtdnTGeC6Io9Uammhf6XF4cZM=.6003fa95-8b51-4a56-b8cd-b7d53b4ba7fd@github.com>
Message-ID: <l8NUVEIns2hiDxOsX-zRu8Yj9R39HtAZcKtmRydYr7k=.093b644f-d564-40a4-adc3-14c32937d754@github.com>

On Fri, 22 Aug 2025 18:24:12 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The adaptive tenuring algorithm has been modified to begin its evaluation of mortality rates from the current tenuring threshold. To compliment this change, objects must also now be strictly above the tenuring threshold to be promoted (instead of greater-than-or-equal).

This pull request has now been integrated.

Changeset: 7fcce270
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7fcce27096605a27ca3b74349d1012bb0bd5963d
Stats:     347 lines in 15 files changed: 253 ins; 29 del; 65 mod

8365956: GenShen: Adaptive tenuring threshold algorithm may raise threshold prematurely

Reviewed-by: kdnilsen, phh

-------------

PR: https://git.openjdk.org/jdk/pull/26906

From kbarrett at openjdk.org  Thu Sep 11 04:23:16 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 11 Sep 2025 04:23:16 GMT
Subject: RFR: 8367014: Rename class Atomic to AtomicAccess [v2]
In-Reply-To: <8HMzxvTwZd1uSZCs528eM4pHsJVeKmFGtplElc8vXpk=.643b3706-7af2-40aa-835c-c3f8a785dd0e@github.com>
References: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
 <8HMzxvTwZd1uSZCs528eM4pHsJVeKmFGtplElc8vXpk=.643b3706-7af2-40aa-835c-c3f8a785dd0e@github.com>
Message-ID: <NwTxewPoW7AdReAVMKC2swb1-QNuERIw_jEmnxbV_Rc=.a231e1f5-1f4b-43ac-8cd9-f0d09bcddaa0@github.com>

On Wed, 10 Sep 2025 07:34:09 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change that renames the all-static class `Atomic` to
>> `AtomicAccess`. The reason for this name change is to allow the introduction
>> of the new type `Atomic<T>` ([JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013)).
>> 
>> The PR has several commits, according to the specific category of change being
>> made. It may be easier to review the PR by studying these individual commits.
>> 
>> Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose
>> to not rename the various "atomic_<cpu>.*" and "atomic_<os>_<cpu>.*" files.
>> 
>> There are a number of comments containing the word "Atomic" that I didn't
>> change. They are generically about atomic operations, and will just as well
>> serve as referring to the future `Atomic<T>`.
>> 
>> Testing: mach5 tier1, GHA sanity tests.
>> This is one of those changes where successful builds indicate the change is good.
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - rename recently added Atomic:: => AtomicAccess::
>  - Merge branch 'master' into atomic-access
>  - fix prefiously missed arg misalignments
>  - rename test_atomic.cpp
>  - update copyrights
>  - misc cleanups
>  - fix indentation from rename
>  - rename Atomic => AtomicAccess in gtests
>  - rename Atomic => AtomicAccess
>  - change includes of atomic.hpp in gtests
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/af9b9050...11007c45

Needs re-review because of updates to deal with merge conflicts and to update newly merged code that needed
the renamings applied. @stefank @theRealAph @dholmes-ora

Hm, now says there is a new merge conflict. Guess you folks should hold off on re-review.

src/hotspot/cpu/aarch64/gc/shared/barrierSetNMethod_aarch64.cpp line 118:

> 116:   }
> 117: 
> 118:   void set_value(int value, int bit_mask) {

This and similar changes for arm and riscv came from a merged changeset.
I took that new version and updated it for `Atomic::` => `AtomicAccess::` renaming.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 394:

> 392:       last_recompute_check = os::javaTimeNanos();
> 393:     }
> 394:     DEBUG_ONLY(if (AtomicAccess::load_acquire(&_out_of_stack_walking_enabled)) {)

Another case of taking a merge update and then adjusting for `Atomic::` => `AtomicAccess::`.

src/hotspot/share/runtime/basicLock.inline.hpp line 32:

> 30: #include "runtime/objectMonitor.inline.hpp"
> 31: 
> 32: inline markWord BasicLock::displaced_header() const {

These functions were removed by a merge update.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27135#issuecomment-3277397927
PR Comment: https://git.openjdk.org/jdk/pull/27135#issuecomment-3277401578
PR Review Comment: https://git.openjdk.org/jdk/pull/27135#discussion_r2338471419
PR Review Comment: https://git.openjdk.org/jdk/pull/27135#discussion_r2338472405
PR Review Comment: https://git.openjdk.org/jdk/pull/27135#discussion_r2338473094

From kbarrett at openjdk.org  Thu Sep 11 05:30:11 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 11 Sep 2025 05:30:11 GMT
Subject: RFR: 8367014: Rename class Atomic to AtomicAccess [v3]
In-Reply-To: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
References: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
Message-ID: <2uwnMiCfWvw9BT15Us6UZqTE_JD4-OGNIsjjzZotu9Y=.7efc037c-5d91-4b7b-88be-c48adb659ff6@github.com>

> Please review this change that renames the all-static class `Atomic` to
> `AtomicAccess`. The reason for this name change is to allow the introduction
> of the new type `Atomic<T>` ([JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013)).
> 
> The PR has several commits, according to the specific category of change being
> made. It may be easier to review the PR by studying these individual commits.
> 
> Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose
> to not rename the various "atomic_<cpu>.*" and "atomic_<os>_<cpu>.*" files.
> 
> There are a number of comments containing the word "Atomic" that I didn't
> change. They are generically about atomic operations, and will just as well
> serve as referring to the future `Atomic<T>`.
> 
> Testing: mach5 tier1, GHA sanity tests.
> This is one of those changes where successful builds indicate the change is good.

Kim Barrett 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 branch 'master' into atomic-access
 - rename recently added Atomic:: => AtomicAccess::
 - Merge branch 'master' into atomic-access
 - fix prefiously missed arg misalignments
 - rename test_atomic.cpp
 - update copyrights
 - misc cleanups
 - fix indentation from rename
 - rename Atomic => AtomicAccess in gtests
 - rename Atomic => AtomicAccess
 - ... and 3 more: https://git.openjdk.org/jdk/compare/134c3ef4...00ecd55c

-------------

Changes: https://git.openjdk.org/jdk/pull/27135/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27135&range=02
  Stats: 5577 lines in 430 files changed: 1587 ins; 1585 del; 2405 mod
  Patch: https://git.openjdk.org/jdk/pull/27135.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27135/head:pull/27135

PR: https://git.openjdk.org/jdk/pull/27135

From dholmes at openjdk.org  Thu Sep 11 06:00:20 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 11 Sep 2025 06:00:20 GMT
Subject: RFR: 8367014: Rename class Atomic to AtomicAccess [v3]
In-Reply-To: <2uwnMiCfWvw9BT15Us6UZqTE_JD4-OGNIsjjzZotu9Y=.7efc037c-5d91-4b7b-88be-c48adb659ff6@github.com>
References: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
 <2uwnMiCfWvw9BT15Us6UZqTE_JD4-OGNIsjjzZotu9Y=.7efc037c-5d91-4b7b-88be-c48adb659ff6@github.com>
Message-ID: <x0HHZmRFF6qGeazll281IN3i7NAnMwoKN2xMvvtN0fM=.f9be5d61-7f4d-4ef4-854e-fef56501a7d2@github.com>

On Thu, 11 Sep 2025 05:30:11 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change that renames the all-static class `Atomic` to
>> `AtomicAccess`. The reason for this name change is to allow the introduction
>> of the new type `Atomic<T>` ([JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013)).
>> 
>> The PR has several commits, according to the specific category of change being
>> made. It may be easier to review the PR by studying these individual commits.
>> 
>> Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose
>> to not rename the various "atomic_<cpu>.*" and "atomic_<os>_<cpu>.*" files.
>> 
>> There are a number of comments containing the word "Atomic" that I didn't
>> change. They are generically about atomic operations, and will just as well
>> serve as referring to the future `Atomic<T>`.
>> 
>> Testing: mach5 tier1, GHA sanity tests.
>> This is one of those changes where successful builds indicate the change is good.
>
> Kim Barrett 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 branch 'master' into atomic-access
>  - rename recently added Atomic:: => AtomicAccess::
>  - Merge branch 'master' into atomic-access
>  - fix prefiously missed arg misalignments
>  - rename test_atomic.cpp
>  - update copyrights
>  - misc cleanups
>  - fix indentation from rename
>  - rename Atomic => AtomicAccess in gtests
>  - rename Atomic => AtomicAccess
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/134c3ef4...00ecd55c

Still good. Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27135#pullrequestreview-3208979512

From wkemper at openjdk.org  Thu Sep 11 14:27:59 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 11 Sep 2025 14:27:59 GMT
Subject: RFR: Merge openjdk/jdk21u:master
Message-ID: <-FA6t6N9nh4P4MjGPusOCMayxIgagEgCjzeWyZBo4qA=.d7f469ff-d7a1-42bc-93b2-f5bd2b419b33@github.com>

Merges tag jdk-21.0.9+7

-------------

Commit messages:
 - 8365375: Method SU3.setAcceleratorSelectionForeground assigns to acceleratorForeground
 - 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/219/files
  Stats: 630 lines in 8 files changed: 524 ins; 81 del; 25 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/219.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/219/head:pull/219

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/219

From wkemper at openjdk.org  Thu Sep 11 20:35:41 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 11 Sep 2025 20:35:41 GMT
Subject: RFR: 8367378: GenShen: Missing timing stats when old mark buffers are
 flushed during final update refs
Message-ID: <kCL-Vc4S1ttnzVXYOHgD4M40t9T0_H23lMa_H6sADWE=.693526b6-bd88-43ea-acf9-f3baef8bafa7@github.com>

This change adds timing to the 'flush old SATB buffers' subphase of final update refs. Ultimately, we hope to move this phase to a handshake (or not have it all). In the interim, we should at least know how long it takes. The updated phase timings message in the logs has the form:

[2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats       ] Pause Final Update Refs (N)         377 us, workers (us): ---, ---, ---, ---, ---, ---, ---, ---, 
[2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats       ]   Update Region States               98 us
[2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats       ]   Transfer Old From SATB             74 us
[2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats       ]   Trash Collection Set               48 us
[2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats       ]   Rebuild Free Set                  132 us
[2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats       ]   Propagate GC State                  6 us

The `Transfer Old From SATB` is new.

-------------

Commit messages:
 - Add timing for satb purge during update final refs

Changes: https://git.openjdk.org/jdk/pull/27234/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27234&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367378
  Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27234.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27234/head:pull/27234

PR: https://git.openjdk.org/jdk/pull/27234

From kdnilsen at openjdk.org  Thu Sep 11 21:12:38 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 11 Sep 2025 21:12:38 GMT
Subject: RFR: 8367378: GenShen: Missing timing stats when old mark buffers
 are flushed during final update refs
In-Reply-To: <kCL-Vc4S1ttnzVXYOHgD4M40t9T0_H23lMa_H6sADWE=.693526b6-bd88-43ea-acf9-f3baef8bafa7@github.com>
References: <kCL-Vc4S1ttnzVXYOHgD4M40t9T0_H23lMa_H6sADWE=.693526b6-bd88-43ea-acf9-f3baef8bafa7@github.com>
Message-ID: <9Wt0z9OmTgnJ3YQAXWERZHplZxf_KHTa929NtzXdmuQ=.5d635ab0-c379-4b88-8d16-24736a071184@github.com>

On Thu, 11 Sep 2025 20:28:08 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This change adds timing to the 'flush old SATB buffers' subphase of final update refs. Ultimately, we hope to move this phase to a handshake (or not have it all). In the interim, we should at least know how long it takes. The updated phase timings message in the logs has the form:
> 
> [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats       ] Pause Final Update Refs (N)         377 us, workers (us): ---, ---, ---, ---, ---, ---, ---, ---, 
> [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats       ]   Update Region States               98 us
> [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats       ]   Transfer Old From SATB             74 us
> [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats       ]   Trash Collection Set               48 us
> [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats       ]   Rebuild Free Set                  132 us
> [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats       ]   Propagate GC State                  6 us
> 
> The `Transfer Old From SATB` is new.

Thanks much

-------------

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27234#pullrequestreview-3213649690

From wkemper at openjdk.org  Thu Sep 11 21:46:44 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 11 Sep 2025 21:46:44 GMT
Subject: RFR: 8367450: Shenandoah: Log the composition of the collection set
Message-ID: <F_eMy4j26l3Nk4DM8ObN1mGLjaFvzHs0IlBfMV0zeqc=.0063c575-fc07-4a6b-801d-ea6f7b97dff7@github.com>

Reuse the same log message from GenShen which details the composition of the live data to be evacuated. In the non-generational modes, all regions are considered young and nothing will be promoted (or old).

-------------

Commit messages:
 - Log the composition of live data within the collection set

Changes: https://git.openjdk.org/jdk/pull/27235/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27235&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367450
  Stats: 118 lines in 5 files changed: 36 ins; 55 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/27235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27235/head:pull/27235

PR: https://git.openjdk.org/jdk/pull/27235

From wkemper at openjdk.org  Thu Sep 11 22:09:09 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 11 Sep 2025 22:09:09 GMT
Subject: RFR: Merge openjdk/jdk21u:master [v2]
In-Reply-To: <-FA6t6N9nh4P4MjGPusOCMayxIgagEgCjzeWyZBo4qA=.d7f469ff-d7a1-42bc-93b2-f5bd2b419b33@github.com>
References: <-FA6t6N9nh4P4MjGPusOCMayxIgagEgCjzeWyZBo4qA=.d7f469ff-d7a1-42bc-93b2-f5bd2b419b33@github.com>
Message-ID: <Tl8zPuzte6JtsCATPjSTeV4nEGHKYo8kYPoLUOvJOWQ=.1b414b4d-23cf-49fd-8ceb-65dfbfdffcc6@github.com>

> Merges tag jdk-21.0.9+7

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.

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/219/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/219/files/98dbb499..98dbb499

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=219&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=219&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/219.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/219/head:pull/219

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/219

From wkemper at openjdk.org  Thu Sep 11 22:09:11 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 11 Sep 2025 22:09:11 GMT
Subject: Integrated: Merge openjdk/jdk21u:master
In-Reply-To: <-FA6t6N9nh4P4MjGPusOCMayxIgagEgCjzeWyZBo4qA=.d7f469ff-d7a1-42bc-93b2-f5bd2b419b33@github.com>
References: <-FA6t6N9nh4P4MjGPusOCMayxIgagEgCjzeWyZBo4qA=.d7f469ff-d7a1-42bc-93b2-f5bd2b419b33@github.com>
Message-ID: <rJraod-xEaMlJvKikEThAmsr3C197ntbSJz6BL4Gr0Y=.2fdbff4c-0542-49b5-a00c-3a7433e3d23a@github.com>

On Thu, 11 Sep 2025 14:21:34 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.9+7

This pull request has now been integrated.

Changeset: ae47a615
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/ae47a61583bdc71dc75a5c9a8e845699ae9502cd
Stats:     630 lines in 8 files changed: 524 ins; 81 del; 25 mod

Merge

-------------

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/219

From wkemper at openjdk.org  Thu Sep 11 22:22:52 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 11 Sep 2025 22:22:52 GMT
Subject: RFR: 8367451: GenShen: Remove the option to compute age census during
 evacuation
Message-ID: <I3LQDu4h-DPdKLbgMJgZgDHxggevg6NL5bUFMuunCbY=.d1c0c2ab-c65b-4f89-a2da-73a60261bd3c@github.com>

This experimental option has always defaulted to false. We are working on changes that will make it impractical to maintain this option. We also do not regularly test this configuration.

-------------

Commit messages:
 - Remove the option to compute age census at evacuation

Changes: https://git.openjdk.org/jdk/pull/27236/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27236&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367451
  Stats: 18 lines in 7 files changed: 0 ins; 5 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/27236.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27236/head:pull/27236

PR: https://git.openjdk.org/jdk/pull/27236

From kdnilsen at openjdk.org  Thu Sep 11 23:22:18 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 11 Sep 2025 23:22:18 GMT
Subject: RFR: 8367451: GenShen: Remove the option to compute age census
 during evacuation
In-Reply-To: <I3LQDu4h-DPdKLbgMJgZgDHxggevg6NL5bUFMuunCbY=.d1c0c2ab-c65b-4f89-a2da-73a60261bd3c@github.com>
References: <I3LQDu4h-DPdKLbgMJgZgDHxggevg6NL5bUFMuunCbY=.d1c0c2ab-c65b-4f89-a2da-73a60261bd3c@github.com>
Message-ID: <wOQyF8aFPBR2UzeIhkKnH0JH9iSioN-nPPFO5mhvLlU=.4c198040-c638-4d5b-ab3d-1bdf6ea41f9d@github.com>

On Thu, 11 Sep 2025 22:16:15 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This experimental option has always defaulted to false. We are working on changes that will make it impractical to maintain this option. We also do not regularly test this configuration.

Thanks.

-------------

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27236#pullrequestreview-3213980261

From kdnilsen at openjdk.org  Thu Sep 11 23:28:13 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 11 Sep 2025 23:28:13 GMT
Subject: RFR: 8367450: Shenandoah: Log the composition of the collection
 set
In-Reply-To: <F_eMy4j26l3Nk4DM8ObN1mGLjaFvzHs0IlBfMV0zeqc=.0063c575-fc07-4a6b-801d-ea6f7b97dff7@github.com>
References: <F_eMy4j26l3Nk4DM8ObN1mGLjaFvzHs0IlBfMV0zeqc=.0063c575-fc07-4a6b-801d-ea6f7b97dff7@github.com>
Message-ID: <IU302VGbtkKDZCRTs7_rhXgkS34g3U9U6zS5id0lMZ8=.e8325e2e-ce68-4a2b-a311-5b25fb1a5f92@github.com>

On Thu, 11 Sep 2025 21:40:50 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Reuse the same log message from GenShen which details the composition of the live data to be evacuated. In the non-generational modes, all regions are considered young and nothing will be promoted (or old).

Thanks.  Very nice improvement.

-------------

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27235#pullrequestreview-3213992068

From kbarrett at openjdk.org  Fri Sep 12 06:35:19 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 12 Sep 2025 06:35:19 GMT
Subject: RFR: 8367014: Rename class Atomic to AtomicAccess [v3]
In-Reply-To: <OYC0XgAFLzN_Kvj9pJZfkQNkg3daoisgjU_lna1CTM0=.a4a18c4d-d501-4461-9976-ff2551a88209@github.com>
References: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
 <iDpU5TCdK05ZWAVCbaI7KAFEn6htGCLJE-4O5Whaf0s=.640b886d-5f1f-45af-b947-7506dd0d97e9@github.com>
 <Mgcv8v1mlWQx038Q1ZXbttfdtwZlc7fEnAfvW8zSIOg=.5391ed7d-974c-400c-a0b6-c69d6b8eb4b4@github.com>
 <OYC0XgAFLzN_Kvj9pJZfkQNkg3daoisgjU_lna1CTM0=.a4a18c4d-d501-4461-9976-ff2551a88209@github.com>
Message-ID: <7AkpbeYv_skWN-uWtPAf4LpJ4stSozu2k0I75xUrAkI=.9aa5463f-4548-4a91-80e1-929f918c0676@github.com>

On Wed, 10 Sep 2025 07:40:38 GMT, Andrew Haley <aph at openjdk.org> wrote:

>>> > Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose
>>> > to not rename the various "atomic_." and "atomic__." files.
>>> 
>>> Could you motivate why you chose to not do that?
>> 
>> I thought about it, and waffled back and forth. But I was trying to do as much
>> as possible of this change mechanically. Renaming a file involves multiple
>> steps that weren't all easily scriptable. (And I'd already messed up a part of
>> the renaming of atomic.hpp during patch development.) Also, this change is
>> going to be hard for backports as it is, and I think renamings might make that
>> worse. Renamings can also be annoying for archeology. But if you think it's
>> important...
>
>> Also, this change is
>> going to be hard for backports as it is, and I think renamings might make that
>> worse. Renamings can also be annoying for archeology.
> 
> Speaking as an archaeologist and the lead of multiple backport projects, I agree with you, Kim.

Thanks for reviews @theRealAph , @stefank , and @dholmes-ora

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27135#issuecomment-3283901596

From kbarrett at openjdk.org  Fri Sep 12 06:39:35 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 12 Sep 2025 06:39:35 GMT
Subject: Integrated: 8367014: Rename class Atomic to AtomicAccess
In-Reply-To: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
References: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
Message-ID: <CyoQAAkoPz9RK2zIgnukLtEB6dsDnUqNoKBhjdGPz1E=.55952cab-5558-4ad7-a292-43c8d1e044c0@github.com>

On Mon, 8 Sep 2025 06:26:03 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that renames the all-static class `Atomic` to
> `AtomicAccess`. The reason for this name change is to allow the introduction
> of the new type `Atomic<T>` ([JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013)).
> 
> The PR has several commits, according to the specific category of change being
> made. It may be easier to review the PR by studying these individual commits.
> 
> Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose
> to not rename the various "atomic_<cpu>.*" and "atomic_<os>_<cpu>.*" files.
> 
> There are a number of comments containing the word "Atomic" that I didn't
> change. They are generically about atomic operations, and will just as well
> serve as referring to the future `Atomic<T>`.
> 
> Testing: mach5 tier1, GHA sanity tests.
> This is one of those changes where successful builds indicate the change is good.

This pull request has now been integrated.

Changeset: 9e843f56
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9e843f56ec0e4126e8256dff44f47c56e5282d20
Stats:     5577 lines in 430 files changed: 1587 ins; 1585 del; 2405 mod

8367014: Rename class Atomic to AtomicAccess

Reviewed-by: dholmes, aph, stefank

-------------

PR: https://git.openjdk.org/jdk/pull/27135

From xpeng at openjdk.org  Fri Sep 12 06:42:17 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 12 Sep 2025 06:42:17 GMT
Subject: RFR: 8367378: GenShen: Missing timing stats when old mark buffers
 are flushed during final update refs
In-Reply-To: <kCL-Vc4S1ttnzVXYOHgD4M40t9T0_H23lMa_H6sADWE=.693526b6-bd88-43ea-acf9-f3baef8bafa7@github.com>
References: <kCL-Vc4S1ttnzVXYOHgD4M40t9T0_H23lMa_H6sADWE=.693526b6-bd88-43ea-acf9-f3baef8bafa7@github.com>
Message-ID: <EQ4eqatJH7mern-dhD0P-3Yv3Z-KwORAVJPtUvIgtPs=.f72030df-93d9-4b71-9f82-a5cd3b3d543e@github.com>

On Thu, 11 Sep 2025 20:28:08 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This change adds timing to the 'flush old SATB buffers' subphase of final update refs. Ultimately, we hope to move this phase to a handshake (or not have it all). In the interim, we should at least know how long it takes. The updated phase timings message in the logs has the form:
> 
> [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats       ] Pause Final Update Refs (N)         377 us, workers (us): ---, ---, ---, ---, ---, ---, ---, ---, 
> [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats       ]   Update Region States               98 us
> [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats       ]   Transfer Old From SATB             74 us
> [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats       ]   Trash Collection Set               48 us
> [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats       ]   Rebuild Free Set                  132 us
> [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats       ]   Propagate GC State                  6 us
> 
> The `Transfer Old From SATB` is new.

Marked as reviewed by xpeng (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27234#pullrequestreview-3214888307

From xpeng at openjdk.org  Fri Sep 12 06:52:23 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 12 Sep 2025 06:52:23 GMT
Subject: RFR: 8367451: GenShen: Remove the option to compute age census
 during evacuation
In-Reply-To: <I3LQDu4h-DPdKLbgMJgZgDHxggevg6NL5bUFMuunCbY=.d1c0c2ab-c65b-4f89-a2da-73a60261bd3c@github.com>
References: <I3LQDu4h-DPdKLbgMJgZgDHxggevg6NL5bUFMuunCbY=.d1c0c2ab-c65b-4f89-a2da-73a60261bd3c@github.com>
Message-ID: <y_dWZeCaZSSPWdF5wvgRKJGWBl5tLeEATMSrXUk_zb8=.23fc26a0-172a-472d-9fa4-423aba0fa23c@github.com>

On Thu, 11 Sep 2025 22:16:15 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This experimental option has always defaulted to false. We are working on changes that will make it impractical to maintain this option. We also do not regularly test this configuration.

Looks good, Thanks!

-------------

Marked as reviewed by xpeng (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27236#pullrequestreview-3214924153

From ayang at openjdk.org  Fri Sep 12 10:19:40 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 12 Sep 2025 10:19:40 GMT
Subject: RFR: 8367320: Sort cpu/x86 includes [v2]
In-Reply-To: <cc3NNxUCaYZGZntgK1VfPijHJaJqFLRaddVbGXQdrwk=.6d24ac68-c79c-48c6-b521-fba161e306ac@github.com>
References: <qcY0LlIm4IjPerZIS-HXD7szCbJ9WvkADuu56oSKj4U=.9de36603-eefd-4de0-bcf6-8f7e311f4863@github.com>
 <uJxrEpfWrvgPfNCgOnTFCGUMNPWnpRFD37ShnSio-nk=.ba8506fc-b091-4540-8647-2d888f037c0a@github.com>
 <SEbNcGLpW0yfTiFrVP5TCq7_44jOAE-eIBKMLuyVZng=.6303168d-2591-4e72-a1ac-99a608784e8d@github.com>
 <cc3NNxUCaYZGZntgK1VfPijHJaJqFLRaddVbGXQdrwk=.6d24ac68-c79c-48c6-b521-fba161e306ac@github.com>
Message-ID: <PfLzz6AW41vw7IQwUI5xVVsS7oV_bqjQMT6a3QAglVk=.9c270ec5-ab35-48c5-85e4-9dd983c9a0b5@github.com>

On Wed, 10 Sep 2025 16:09:18 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> There should be some more details about what constitutes the "corresponding .hpp file"

That's probably a good idea to further clarify what the "corresponding .hpp" file is, when arch (_x86) is included in the inline-file name. I also wonder what others think.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27189#discussion_r2343753537

From fandreuzzi at openjdk.org  Fri Sep 12 10:43:01 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 12 Sep 2025 10:43:01 GMT
Subject: RFR: 8367476: Shenandoah: Remove use of
 CollectedHeap::_soft_ref_policy
Message-ID: <tzAvTC0wDUpwFEy_076ofgsqpFAcVf5bjiM7SQLwO-w=.7a288588-bb12-435c-8a07-378069e8a851@github.com>

Similarly to what was done in #26496 and #26648, the usages of `CollectedHeap::_soft_ref_policy` in Shenandoah can be replaced with an earlier call to ShenandoahReferenceProcessor::set_soft_reference_policy.

This is the last usages of `CollectedHeap::_soft_ref_policy`, so it can be removed.

Passes tier(1,2,3)_gc_shenandoah.

-------------

Commit messages:
 - can be const
 - stuff
 - stuff

Changes: https://git.openjdk.org/jdk/pull/27239/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27239&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367476
  Stats: 97 lines in 17 files changed: 16 ins; 74 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/27239.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27239/head:pull/27239

PR: https://git.openjdk.org/jdk/pull/27239

From ayang at openjdk.org  Fri Sep 12 11:05:12 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 12 Sep 2025 11:05:12 GMT
Subject: RFR: 8367476: Shenandoah: Remove use of
 CollectedHeap::_soft_ref_policy
In-Reply-To: <tzAvTC0wDUpwFEy_076ofgsqpFAcVf5bjiM7SQLwO-w=.7a288588-bb12-435c-8a07-378069e8a851@github.com>
References: <tzAvTC0wDUpwFEy_076ofgsqpFAcVf5bjiM7SQLwO-w=.7a288588-bb12-435c-8a07-378069e8a851@github.com>
Message-ID: <Gw5JaWTh0fniqU_G70GTNVzvtIgjDtkrRB80yFJSj-0=.2f9477f4-9626-431d-aae3-8b6dd058c36c@github.com>

On Fri, 12 Sep 2025 00:19:05 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Similarly to what was done in #26496 and #26648, the usages of `CollectedHeap::_soft_ref_policy` in Shenandoah can be replaced with an earlier call to `ShenandoahReferenceProcessor::set_soft_reference_policy`.
> 
> This is the last usage of `CollectedHeap::_soft_ref_policy`, so it can be removed.
> 
> Passes tier(1,2,3)_gc_shenandoah.

src/hotspot/share/gc/shared/collectedHeap.hpp line 239:

> 237:     return cause == GCCause::_metadata_GC_clear_soft_refs ||
> 238:            cause == GCCause::_wb_full_gc;
> 239:   }

I feel that it makes more sense to have this in `GCCause`.

src/hotspot/share/gc/shared/collectedHeap.hpp line 241:

> 239:   }
> 240: 
> 241:   inline bool should_clear_all_soft_refs() const {

I suggest inlining this method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27239#discussion_r2343856579
PR Review Comment: https://git.openjdk.org/jdk/pull/27239#discussion_r2343858970

From fandreuzzi at openjdk.org  Fri Sep 12 11:14:22 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 12 Sep 2025 11:14:22 GMT
Subject: RFR: 8367320: Sort cpu/x86 includes [v2]
In-Reply-To: <PfLzz6AW41vw7IQwUI5xVVsS7oV_bqjQMT6a3QAglVk=.9c270ec5-ab35-48c5-85e4-9dd983c9a0b5@github.com>
References: <qcY0LlIm4IjPerZIS-HXD7szCbJ9WvkADuu56oSKj4U=.9de36603-eefd-4de0-bcf6-8f7e311f4863@github.com>
 <uJxrEpfWrvgPfNCgOnTFCGUMNPWnpRFD37ShnSio-nk=.ba8506fc-b091-4540-8647-2d888f037c0a@github.com>
 <SEbNcGLpW0yfTiFrVP5TCq7_44jOAE-eIBKMLuyVZng=.6303168d-2591-4e72-a1ac-99a608784e8d@github.com>
 <cc3NNxUCaYZGZntgK1VfPijHJaJqFLRaddVbGXQdrwk=.6d24ac68-c79c-48c6-b521-fba161e306ac@github.com>
 <PfLzz6AW41vw7IQwUI5xVVsS7oV_bqjQMT6a3QAglVk=.9c270ec5-ab35-48c5-85e4-9dd983c9a0b5@github.com>
Message-ID: <qn4oadwPRuZd-b8jDslu4RM2tcUbdN8eR10xQSCx66M=.e5d7f943-521a-4b9d-ba7f-7cc417f24bda@github.com>

On Fri, 12 Sep 2025 10:16:33 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> I think the style guide should be changed too if we want to make this change:
>> 
>> All .inline.hpp files should include their corresponding .hpp file as
>> the first include line with a blank line separating it from the rest of the
>> include lines.
>> 
>> 
>> There should be some more details about what constitutes the "corresponding .hpp file". In the case of your [comment above](https://github.com/openjdk/jdk/pull/27189#discussion_r2336167042) in this PR, the `.inline.hpp` file had a clear "corresponding `.hpp` file", namely `continuationEntry_x86.hpp`. 
>> 
>> Should the style guide state something like "the corresponding `.hpp` file for a `inline.hpp` whose name contains some compilation flag-dependent qualifier, is either the `.hpp` file with the qualifier (if present) or the `.hpp` file without the qualifier as a fallback" ?
>
>> There should be some more details about what constitutes the "corresponding .hpp file"
> 
> That's probably a good idea to further clarify what the "corresponding .hpp" file is, when arch (_x86) is included in the inline-file name. I also wonder what others think.

I'm going to open a PR with a small change in `style-guide.md` to start the discussion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27189#discussion_r2343878101

From stefank at openjdk.org  Fri Sep 12 13:15:28 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 12 Sep 2025 13:15:28 GMT
Subject: RFR: 8367320: Sort cpu/x86 includes [v2]
In-Reply-To: <qn4oadwPRuZd-b8jDslu4RM2tcUbdN8eR10xQSCx66M=.e5d7f943-521a-4b9d-ba7f-7cc417f24bda@github.com>
References: <qcY0LlIm4IjPerZIS-HXD7szCbJ9WvkADuu56oSKj4U=.9de36603-eefd-4de0-bcf6-8f7e311f4863@github.com>
 <uJxrEpfWrvgPfNCgOnTFCGUMNPWnpRFD37ShnSio-nk=.ba8506fc-b091-4540-8647-2d888f037c0a@github.com>
 <SEbNcGLpW0yfTiFrVP5TCq7_44jOAE-eIBKMLuyVZng=.6303168d-2591-4e72-a1ac-99a608784e8d@github.com>
 <cc3NNxUCaYZGZntgK1VfPijHJaJqFLRaddVbGXQdrwk=.6d24ac68-c79c-48c6-b521-fba161e306ac@github.com>
 <PfLzz6AW41vw7IQwUI5xVVsS7oV_bqjQMT6a3QAglVk=.9c270ec5-ab35-48c5-85e4-9dd983c9a0b5@github.com>
 <qn4oadwPRuZd-b8jDslu4RM2tcUbdN8eR10xQSCx66M=.e5d7f943-521a-4b9d-ba7f-7cc417f24bda@github.com>
Message-ID: <JLtJZTSVo2RMFjOqLK4umUdDychDTLExEKTF7VgvbCM=.8cde6896-846e-4d19-9785-cb1a09b444a7@github.com>

On Fri, 12 Sep 2025 11:11:10 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>>> There should be some more details about what constitutes the "corresponding .hpp file"
>> 
>> That's probably a good idea to further clarify what the "corresponding .hpp" file is, when arch (_x86) is included in the inline-file name. I also wonder what others think.
>
> I'm going to open a PR with a small change in `style-guide.md` to start the discussion.

Just note that we currently don't have a consistent way that we structure the inclusions of our the platform dependent files. When making the patch that followed the  "corresponding .hpp" rule I had to handle the includes on case-by-case basis. Just be warned that you might create a rule that we can't adhere to without rewriting some of the includes patterns.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27189#discussion_r2344224871

From fandreuzzi at openjdk.org  Fri Sep 12 13:31:14 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 12 Sep 2025 13:31:14 GMT
Subject: RFR: 8367320: Sort cpu/x86 includes [v2]
In-Reply-To: <JLtJZTSVo2RMFjOqLK4umUdDychDTLExEKTF7VgvbCM=.8cde6896-846e-4d19-9785-cb1a09b444a7@github.com>
References: <qcY0LlIm4IjPerZIS-HXD7szCbJ9WvkADuu56oSKj4U=.9de36603-eefd-4de0-bcf6-8f7e311f4863@github.com>
 <uJxrEpfWrvgPfNCgOnTFCGUMNPWnpRFD37ShnSio-nk=.ba8506fc-b091-4540-8647-2d888f037c0a@github.com>
 <SEbNcGLpW0yfTiFrVP5TCq7_44jOAE-eIBKMLuyVZng=.6303168d-2591-4e72-a1ac-99a608784e8d@github.com>
 <cc3NNxUCaYZGZntgK1VfPijHJaJqFLRaddVbGXQdrwk=.6d24ac68-c79c-48c6-b521-fba161e306ac@github.com>
 <PfLzz6AW41vw7IQwUI5xVVsS7oV_bqjQMT6a3QAglVk=.9c270ec5-ab35-48c5-85e4-9dd983c9a0b5@github.com>
 <qn4oadwPRuZd-b8jDslu4RM2tcUbdN8eR10xQSCx66M=.e5d7f943-521a-4b9d-ba7f-7cc417f24bda@github.com>
 <JLtJZTSVo2RMFjOqLK4umUdDychDTLExEKTF7VgvbCM=.8cde6896-846e-4d19-9785-cb1a09b444a7@github.com>
Message-ID: <Zu6vbcuY4pyxPsWVH9slAWbfjLc5aIfdQNou7LVWe1U=.0987ca43-67ab-4155-aebb-a6cc9c570f5b@github.com>

On Fri, 12 Sep 2025 13:12:43 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I'm going to open a PR with a small change in `style-guide.md` to start the discussion.
>
> Just note that we currently don't have a consistent way that we structure the inclusions of our the platform dependent files. When making the patch that followed the  "corresponding .hpp" rule I had to handle the includes on case-by-case basis. Just be warned that you might create a rule that we can't adhere to without rewriting some of the includes patterns.

Hi @stefank, I've just opened #27259.

> Just be warned that you might create a rule that we can't adhere to without rewriting some of the includes patterns.

What do you mean? Do you have an example?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27189#discussion_r2344267959

From fandreuzzi at openjdk.org  Fri Sep 12 14:23:35 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 12 Sep 2025 14:23:35 GMT
Subject: RFR: 8367476: Shenandoah: Remove use of
 CollectedHeap::_soft_ref_policy [v2]
In-Reply-To: <tzAvTC0wDUpwFEy_076ofgsqpFAcVf5bjiM7SQLwO-w=.7a288588-bb12-435c-8a07-378069e8a851@github.com>
References: <tzAvTC0wDUpwFEy_076ofgsqpFAcVf5bjiM7SQLwO-w=.7a288588-bb12-435c-8a07-378069e8a851@github.com>
Message-ID: <e1U8g7gn18EwcgKc8uYG8D4S3nSb6B2VCb7RdCTrHgU=.27d17b97-ab1c-4230-b8cf-20ec4441a108@github.com>

> Similarly to what was done in #26496 and #26648, the usages of `CollectedHeap::_soft_ref_policy` in Shenandoah can be replaced with an earlier call to `ShenandoahReferenceProcessor::set_soft_reference_policy`.
> 
> This is the last usage of `CollectedHeap::_soft_ref_policy`, so it can be removed.
> 
> Passes tier(1,2,3)_gc_shenandoah.

Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:

 - eagerly initialize to always-clear
 - move to gccause

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27239/files
  - new: https://git.openjdk.org/jdk/pull/27239/files/01e41d7b..a55b8bd2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27239&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27239&range=00-01

  Stats: 30 lines in 8 files changed: 11 ins; 12 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/27239.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27239/head:pull/27239

PR: https://git.openjdk.org/jdk/pull/27239

From fandreuzzi at openjdk.org  Fri Sep 12 14:23:37 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 12 Sep 2025 14:23:37 GMT
Subject: RFR: 8367476: Shenandoah: Remove use of
 CollectedHeap::_soft_ref_policy [v2]
In-Reply-To: <Gw5JaWTh0fniqU_G70GTNVzvtIgjDtkrRB80yFJSj-0=.2f9477f4-9626-431d-aae3-8b6dd058c36c@github.com>
References: <tzAvTC0wDUpwFEy_076ofgsqpFAcVf5bjiM7SQLwO-w=.7a288588-bb12-435c-8a07-378069e8a851@github.com>
 <Gw5JaWTh0fniqU_G70GTNVzvtIgjDtkrRB80yFJSj-0=.2f9477f4-9626-431d-aae3-8b6dd058c36c@github.com>
Message-ID: <VQzB78dRTsLc_So4vimnt5WWF6g7egtIazptCU5f2Nc=.f656b23c-92c9-47ed-87fe-b32ac5f5cb7d@github.com>

On Fri, 12 Sep 2025 11:00:01 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - eagerly initialize to always-clear
>>  - move to gccause
>
> src/hotspot/share/gc/shared/collectedHeap.hpp line 239:
> 
>> 237:     return cause == GCCause::_metadata_GC_clear_soft_refs ||
>> 238:            cause == GCCause::_wb_full_gc;
>> 239:   }
> 
> I feel that it makes more sense to have this in `GCCause`.

035963eb771c9c614cc98affdbbb18ec86a53e78

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27239#discussion_r2344402767

From stefank at openjdk.org  Fri Sep 12 15:02:24 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 12 Sep 2025 15:02:24 GMT
Subject: RFR: 8367320: Sort cpu/x86 includes [v2]
In-Reply-To: <Zu6vbcuY4pyxPsWVH9slAWbfjLc5aIfdQNou7LVWe1U=.0987ca43-67ab-4155-aebb-a6cc9c570f5b@github.com>
References: <qcY0LlIm4IjPerZIS-HXD7szCbJ9WvkADuu56oSKj4U=.9de36603-eefd-4de0-bcf6-8f7e311f4863@github.com>
 <uJxrEpfWrvgPfNCgOnTFCGUMNPWnpRFD37ShnSio-nk=.ba8506fc-b091-4540-8647-2d888f037c0a@github.com>
 <SEbNcGLpW0yfTiFrVP5TCq7_44jOAE-eIBKMLuyVZng=.6303168d-2591-4e72-a1ac-99a608784e8d@github.com>
 <cc3NNxUCaYZGZntgK1VfPijHJaJqFLRaddVbGXQdrwk=.6d24ac68-c79c-48c6-b521-fba161e306ac@github.com>
 <PfLzz6AW41vw7IQwUI5xVVsS7oV_bqjQMT6a3QAglVk=.9c270ec5-ab35-48c5-85e4-9dd983c9a0b5@github.com>
 <qn4oadwPRuZd-b8jDslu4RM2tcUbdN8eR10xQSCx66M=.e5d7f943-521a-4b9d-ba7f-7cc417f24bda@github.com>
 <JLtJZTSVo2RMFjOqLK4umUdDychDTLExEKTF7VgvbCM=.8cde6896-846e-4d19-9785-cb1a09b444a7@github.com>
 <Zu6vbcuY4pyxPsWVH9slAWbfjLc5aIfdQNou7LVWe1U=.0987ca43-67ab-4155-aebb-a6cc9c570f5b@github.com>
Message-ID: <eZUFEcB_v4sAhJvc5iBhSea6pful4_0FyQ9EjeHbXq4=.fcbbbaaf-a91f-4edd-b5a1-c44665a6c3c9@github.com>

On Fri, 12 Sep 2025 13:27:52 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> Just note that we currently don't have a consistent way that we structure the inclusions of our the platform dependent files. When making the patch that followed the  "corresponding .hpp" rule I had to handle the includes on case-by-case basis. Just be warned that you might create a rule that we can't adhere to without rewriting some of the includes patterns.
>
> Hi @stefank, I've just opened #27259.
> 
>> Just be warned that you might create a rule that we can't adhere to without rewriting some of the includes patterns.
> 
> What do you mean? Do you have an example?

For example, take a look at the various frame* files:

frame.inline.hpp include frame.hpp - this is according to our rules
frame.hpp does one of our weird tricks to include the frame_<cpu>.hpp straight into the middle of the frame class (via the CPU_HEADER macro).
frame_<cpu>.inline.hpp can therefore not include the corresponding frame_<cpu>.hpp because if it did it would include the cpu-dependent parts of the frame class and that will not work.

Another think one has to consider is if the includes are written so that the platform files can be included stand-alone or not:

Sometimes we have this include order:
file.inline.hpp includes file.hpp and file_<cpu>.inline.hpp
file_<cpu>.inline.hpp doesn't include file.hpp because the only way to use file_<cpu>.inline.hpp is to include file.inline.hpp. file_<cpu>.inline.hpp can't be included stand-alone.

Sometimes we the opposite include order:
file_<cpu>.inline.hpp includes file.inline.hpp, which includes file.hpp, and file_<cpu>.inline.hpp can be included stand-alone.

If you are going to write a style guide for the platform includes you need to go through our includes and see if your proposal matches what we have. If not, you need to figure out if there's some refactoring that can be done to change files to match the proposal.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27189#discussion_r2344516463

From ayang at openjdk.org  Fri Sep 12 15:21:22 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 12 Sep 2025 15:21:22 GMT
Subject: RFR: 8367476: Shenandoah: Remove use of
 CollectedHeap::_soft_ref_policy [v2]
In-Reply-To: <e1U8g7gn18EwcgKc8uYG8D4S3nSb6B2VCb7RdCTrHgU=.27d17b97-ab1c-4230-b8cf-20ec4441a108@github.com>
References: <tzAvTC0wDUpwFEy_076ofgsqpFAcVf5bjiM7SQLwO-w=.7a288588-bb12-435c-8a07-378069e8a851@github.com>
 <e1U8g7gn18EwcgKc8uYG8D4S3nSb6B2VCb7RdCTrHgU=.27d17b97-ab1c-4230-b8cf-20ec4441a108@github.com>
Message-ID: <y7SlIhZC5KY_p5D8j4k6orgasSpk1nf5zByk54C7q_0=.1e8885c5-5e5a-43f9-9d81-f7b8454cef38@github.com>

On Fri, 12 Sep 2025 14:23:35 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> Similarly to what was done in #26496 and #26648, the usages of `CollectedHeap::_soft_ref_policy` in Shenandoah can be replaced with an earlier call to `ShenandoahReferenceProcessor::set_soft_reference_policy`.
>> 
>> This is the last usage of `CollectedHeap::_soft_ref_policy`, so it can be removed.
>> 
>> Passes tier1-2, and tier3_gc_shenandoah.
>
> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - eagerly initialize to always-clear
>  - move to gccause

I have reviewed all non-Shenandoah code.

-------------

Marked as reviewed by ayang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27239#pullrequestreview-3217218522

From phh at openjdk.org  Fri Sep 12 16:04:15 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 12 Sep 2025 16:04:15 GMT
Subject: RFR: 8367378: GenShen: Missing timing stats when old mark buffers
 are flushed during final update refs
In-Reply-To: <kCL-Vc4S1ttnzVXYOHgD4M40t9T0_H23lMa_H6sADWE=.693526b6-bd88-43ea-acf9-f3baef8bafa7@github.com>
References: <kCL-Vc4S1ttnzVXYOHgD4M40t9T0_H23lMa_H6sADWE=.693526b6-bd88-43ea-acf9-f3baef8bafa7@github.com>
Message-ID: <Ep-8VyF18It6Q0tWr7elUF730z2Zr-ZG2yT0dXmv3HY=.3ced72fe-e08d-4a68-b889-234a65121625@github.com>

On Thu, 11 Sep 2025 20:28:08 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This change adds timing to the 'flush old SATB buffers' subphase of final update refs. Ultimately, we hope to move this phase to a handshake (or not have it all). In the interim, we should at least know how long it takes. The updated phase timings message in the logs has the form:
> 
> [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats       ] Pause Final Update Refs (N)         377 us, workers (us): ---, ---, ---, ---, ---, ---, ---, ---, 
> [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats       ]   Update Region States               98 us
> [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats       ]   Transfer Old From SATB             74 us
> [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats       ]   Trash Collection Set               48 us
> [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats       ]   Rebuild Free Set                  132 us
> [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats       ]   Propagate GC State                  6 us
> 
> The `Transfer Old From SATB` is new.

Marked as reviewed by phh (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27234#pullrequestreview-3217509401

From phh at openjdk.org  Fri Sep 12 16:06:26 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 12 Sep 2025 16:06:26 GMT
Subject: RFR: 8367451: GenShen: Remove the option to compute age census
 during evacuation
In-Reply-To: <I3LQDu4h-DPdKLbgMJgZgDHxggevg6NL5bUFMuunCbY=.d1c0c2ab-c65b-4f89-a2da-73a60261bd3c@github.com>
References: <I3LQDu4h-DPdKLbgMJgZgDHxggevg6NL5bUFMuunCbY=.d1c0c2ab-c65b-4f89-a2da-73a60261bd3c@github.com>
Message-ID: <IrY0bWk-2GTbp6fnUyS3MEKY1Hux2Kpri9ISpd2p_Bc=.cf5502f9-33e6-416c-89d9-90a7f581cb80@github.com>

On Thu, 11 Sep 2025 22:16:15 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This experimental option has always defaulted to false. We are working on changes that will make it impractical to maintain this option. We also do not regularly test this configuration.

Marked as reviewed by phh (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27236#pullrequestreview-3217527778

From fandreuzzi at openjdk.org  Fri Sep 12 16:14:22 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 12 Sep 2025 16:14:22 GMT
Subject: RFR: 8367320: Sort cpu/x86 includes [v2]
In-Reply-To: <eZUFEcB_v4sAhJvc5iBhSea6pful4_0FyQ9EjeHbXq4=.fcbbbaaf-a91f-4edd-b5a1-c44665a6c3c9@github.com>
References: <qcY0LlIm4IjPerZIS-HXD7szCbJ9WvkADuu56oSKj4U=.9de36603-eefd-4de0-bcf6-8f7e311f4863@github.com>
 <uJxrEpfWrvgPfNCgOnTFCGUMNPWnpRFD37ShnSio-nk=.ba8506fc-b091-4540-8647-2d888f037c0a@github.com>
 <SEbNcGLpW0yfTiFrVP5TCq7_44jOAE-eIBKMLuyVZng=.6303168d-2591-4e72-a1ac-99a608784e8d@github.com>
 <cc3NNxUCaYZGZntgK1VfPijHJaJqFLRaddVbGXQdrwk=.6d24ac68-c79c-48c6-b521-fba161e306ac@github.com>
 <PfLzz6AW41vw7IQwUI5xVVsS7oV_bqjQMT6a3QAglVk=.9c270ec5-ab35-48c5-85e4-9dd983c9a0b5@github.com>
 <qn4oadwPRuZd-b8jDslu4RM2tcUbdN8eR10xQSCx66M=.e5d7f943-521a-4b9d-ba7f-7cc417f24bda@github.com>
 <JLtJZTSVo2RMFjOqLK4umUdDychDTLExEKTF7VgvbCM=.8cde6896-846e-4d19-9785-cb1a09b444a7@github.com>
 <Zu6vbcuY4pyxPsWVH9slAWbfjLc5aIfdQNou7LVWe1U=.0987ca43-67ab-4155-aebb-a6cc9c570f5b@github.com>
 <eZUFEcB_v4sAhJvc5iBhSea6pful4_0FyQ9EjeHbXq4=.fcbbbaaf-a91f-4edd-b5a1-c44665a6c3c9@github.com>
Message-ID: <_4mRtYH_RWgbVHs49HojPPTYfzSidVOKkCypb-nSBbc=.b1854ffb-1b14-470d-9350-6f02d5673dd7@github.com>

On Fri, 12 Sep 2025 14:59:45 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Hi @stefank, I've just opened #27259.
>> 
>>> Just be warned that you might create a rule that we can't adhere to without rewriting some of the includes patterns.
>> 
>> What do you mean? Do you have an example?
>
> For example, take a look at the various frame* files:
> 
> frame.inline.hpp include frame.hpp - this is according to our rules
> frame.hpp does one of our weird tricks to include the frame_<cpu>.hpp straight into the middle of the frame class (via the CPU_HEADER macro).
> frame_<cpu>.inline.hpp can therefore not include the corresponding frame_<cpu>.hpp because if it did it would include the cpu-dependent parts of the frame class and that will not work.
> 
> Another think one has to consider is if the includes are written so that the platform files can be included stand-alone or not:
> 
> Sometimes we have this include order:
> file.inline.hpp includes file.hpp and file_<cpu>.inline.hpp
> file_<cpu>.inline.hpp doesn't include file.hpp because the only way to use file_<cpu>.inline.hpp is to include file.inline.hpp. file_<cpu>.inline.hpp can't be included stand-alone.
> 
> Sometimes we the opposite include order:
> file_<cpu>.inline.hpp includes file.inline.hpp, which includes file.hpp, and file_<cpu>.inline.hpp can be included stand-alone.
> 
> If you are going to write a style guide for the platform includes you need to go through our includes and see if your proposal matches what we have. If not, you need to figure out if there's some refactoring that can be done to change files to match the proposal.

Thanks for the detailed summary, indeed it looks like my initial proposal is not enough to address all cases. I'll think about it and go through the cases as you suggested.

For the time being, I moved #27259 to draft.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27189#discussion_r2344728131

From wkemper at openjdk.org  Fri Sep 12 16:53:31 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 12 Sep 2025 16:53:31 GMT
Subject: Integrated: 8367451: GenShen: Remove the option to compute age census
 during evacuation
In-Reply-To: <I3LQDu4h-DPdKLbgMJgZgDHxggevg6NL5bUFMuunCbY=.d1c0c2ab-c65b-4f89-a2da-73a60261bd3c@github.com>
References: <I3LQDu4h-DPdKLbgMJgZgDHxggevg6NL5bUFMuunCbY=.d1c0c2ab-c65b-4f89-a2da-73a60261bd3c@github.com>
Message-ID: <S94qIevpPiLpXiuCx3Ib076f-aMa2LH7O25KD5tyv5w=.a123024b-6286-499a-bdaa-346cd8d891db@github.com>

On Thu, 11 Sep 2025 22:16:15 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This experimental option has always defaulted to false. We are working on changes that will make it impractical to maintain this option. We also do not regularly test this configuration.

This pull request has now been integrated.

Changeset: 850f904a
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/850f904a84186b514a9b79fd4625b4651e73149b
Stats:     18 lines in 7 files changed: 0 ins; 5 del; 13 mod

8367451: GenShen: Remove the option to compute age census during evacuation

Reviewed-by: kdnilsen, xpeng, phh

-------------

PR: https://git.openjdk.org/jdk/pull/27236

From wkemper at openjdk.org  Fri Sep 12 16:53:26 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 12 Sep 2025 16:53:26 GMT
Subject: Integrated: 8367378: GenShen: Missing timing stats when old mark
 buffers are flushed during final update refs
In-Reply-To: <kCL-Vc4S1ttnzVXYOHgD4M40t9T0_H23lMa_H6sADWE=.693526b6-bd88-43ea-acf9-f3baef8bafa7@github.com>
References: <kCL-Vc4S1ttnzVXYOHgD4M40t9T0_H23lMa_H6sADWE=.693526b6-bd88-43ea-acf9-f3baef8bafa7@github.com>
Message-ID: <mSTZPo5Trws91eQSsmTs8xWyA9bdM7VrTHaO0zb4mc8=.3e3c257d-74bc-4cfb-b0d1-b7cafc53731a@github.com>

On Thu, 11 Sep 2025 20:28:08 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This change adds timing to the 'flush old SATB buffers' subphase of final update refs. Ultimately, we hope to move this phase to a handshake (or not have it all). In the interim, we should at least know how long it takes. The updated phase timings message in the logs has the form:
> 
> [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats       ] Pause Final Update Refs (N)         377 us, workers (us): ---, ---, ---, ---, ---, ---, ---, ---, 
> [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats       ]   Update Region States               98 us
> [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats       ]   Transfer Old From SATB             74 us
> [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats       ]   Trash Collection Set               48 us
> [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats       ]   Rebuild Free Set                  132 us
> [2025-09-11T18:43:11.463+0000][291.626s][3541][info ][gc,stats       ]   Propagate GC State                  6 us
> 
> The `Transfer Old From SATB` is new.

This pull request has now been integrated.

Changeset: 11df2891
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/11df28916af4c2bfd69b2829c74e046ad953ee6c
Stats:     2 lines in 2 files changed: 2 ins; 0 del; 0 mod

8367378: GenShen: Missing timing stats when old mark buffers are flushed during final update refs

Reviewed-by: kdnilsen, xpeng, phh

-------------

PR: https://git.openjdk.org/jdk/pull/27234

From kdnilsen at openjdk.org  Fri Sep 12 17:20:16 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 12 Sep 2025 17:20:16 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v3]
In-Reply-To: <dEUIaXmSftNpVQ-tqfFsAXetwlMbvEBWqbMp9vdTTPY=.da1e4904-f814-434d-b2e9-25aa1ded47d5@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
 <dEUIaXmSftNpVQ-tqfFsAXetwlMbvEBWqbMp9vdTTPY=.da1e4904-f814-434d-b2e9-25aa1ded47d5@github.com>
Message-ID: <RZZZ1pjhaPeJ24NcfE8ThIa3no1l6kLIpxzrv4Uzg2I=.8d2bd458-ce72-43b0-8f09-b919a2fa55b8@github.com>

On Tue, 9 Sep 2025 22:07:11 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
>> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
>> 
>> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
>> 
>> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   another tweak to make GHA gtest happy

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 3271:

> 3269:   }
> 3270: }
> 3271: 

Maybe we no longer need regular bypass because CDS no longer needs regular bypass.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2344973965

From kdnilsen at openjdk.org  Fri Sep 12 18:20:15 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 12 Sep 2025 18:20:15 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v3]
In-Reply-To: <0DIlqJVwgCnx2FvbXZuDySjJ3hz241ag41o3BCHkSuY=.ac51c769-c5c0-4750-99b4-0ff43f864d33@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
 <dEUIaXmSftNpVQ-tqfFsAXetwlMbvEBWqbMp9vdTTPY=.da1e4904-f814-434d-b2e9-25aa1ded47d5@github.com>
 <0DIlqJVwgCnx2FvbXZuDySjJ3hz241ag41o3BCHkSuY=.ac51c769-c5c0-4750-99b4-0ff43f864d33@github.com>
Message-ID: <h7wGTy_BxiWCprqyz9qtZTsKHq4zu1o6eO16oSHnAFo=.31658967-978b-492c-9309-d24af732b67c@github.com>

On Wed, 10 Sep 2025 20:42:42 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   another tweak to make GHA gtest happy
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 372:
> 
>> 370:       _last_sample_time = now;
>> 371:       _last_sample_value = allocated;
>> 372:     }
> 
> This was a bug.  If we don't update the average, we should not restart the time until next sample and we should not overwrite the value of _last_sample_value.

Let's split this out into a different PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2345013011

From kdnilsen at openjdk.org  Fri Sep 12 18:20:18 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 12 Sep 2025 18:20:18 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v3]
In-Reply-To: <dEUIaXmSftNpVQ-tqfFsAXetwlMbvEBWqbMp9vdTTPY=.da1e4904-f814-434d-b2e9-25aa1ded47d5@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
 <dEUIaXmSftNpVQ-tqfFsAXetwlMbvEBWqbMp9vdTTPY=.da1e4904-f814-434d-b2e9-25aa1ded47d5@github.com>
Message-ID: <Db1uIscnLCsYsdoEHp8ya19Z5narnOm5B_1I1bQPjE4=.f90cd251-31f4-47b7-83e9-a5bcc7f60c1a@github.com>

On Tue, 9 Sep 2025 22:07:11 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
>> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
>> 
>> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
>> 
>> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   another tweak to make GHA gtest happy

src/hotspot/share/gc/shenandoah/shenandoahGenerationalEvacuationTask.cpp line 235:

> 233:     // is_collector_free range.
> 234:     region->restore_top_before_promote();
> 235:     size_t region_to_be_used_in_old = region->used();

is region_to_be_used_in_old dead here?

test/hotspot/jtreg/gc/shenandoah/mxbeans/TestChurnNotifications.java line 162:

> 160:         long count = TARGET_MB * 1024 * 1024 / (16 + 4 * size);
> 161: 
> 162:         long anticipated_humongous_waste_per_array = 124_272;

Define ANTICIPATED_HUMONGOUS_WASTE_PER_ARRAY as a static constant.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2345034798
PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2345081989

From ayang at openjdk.org  Fri Sep 12 18:46:21 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 12 Sep 2025 18:46:21 GMT
Subject: RFR: 8367320: Sort cpu/x86 includes [v2]
In-Reply-To: <_4mRtYH_RWgbVHs49HojPPTYfzSidVOKkCypb-nSBbc=.b1854ffb-1b14-470d-9350-6f02d5673dd7@github.com>
References: <qcY0LlIm4IjPerZIS-HXD7szCbJ9WvkADuu56oSKj4U=.9de36603-eefd-4de0-bcf6-8f7e311f4863@github.com>
 <uJxrEpfWrvgPfNCgOnTFCGUMNPWnpRFD37ShnSio-nk=.ba8506fc-b091-4540-8647-2d888f037c0a@github.com>
 <SEbNcGLpW0yfTiFrVP5TCq7_44jOAE-eIBKMLuyVZng=.6303168d-2591-4e72-a1ac-99a608784e8d@github.com>
 <cc3NNxUCaYZGZntgK1VfPijHJaJqFLRaddVbGXQdrwk=.6d24ac68-c79c-48c6-b521-fba161e306ac@github.com>
 <PfLzz6AW41vw7IQwUI5xVVsS7oV_bqjQMT6a3QAglVk=.9c270ec5-ab35-48c5-85e4-9dd983c9a0b5@github.com>
 <qn4oadwPRuZd-b8jDslu4RM2tcUbdN8eR10xQSCx66M=.e5d7f943-521a-4b9d-ba7f-7cc417f24bda@github.com>
 <JLtJZTSVo2RMFjOqLK4umUdDychDTLExEKTF7VgvbCM=.8cde6896-846e-4d19-9785-cb1a09b444a7@github.com>
 <Zu6vbcuY4pyxPsWVH9slAWbfjLc5aIfdQNou7LVWe1U=.0987ca43-67ab-4155-aebb-a6cc9c570f5b@github.com>
 <eZUFEcB_v4sAhJvc5iBhSea6pful4_0FyQ9EjeHbXq4=.fcbbbaaf-a91f-4edd-b5a1-c44665a6c3c9@github.com>
 <_4mRtYH_RWgbVHs49HojPPTYfzSidVOKkCypb-nSBbc=.b1854ffb-1b14-470d-9350-6f02d5673dd7@github.com>
Message-ID: <HAFfhfrfnAkgEYHFhqHf6Qr4w2R5hxqvt4HLj0hSG6Q=.3976df26-0aad-47fd-bd6f-77861fa5d2ab@github.com>

On Fri, 12 Sep 2025 16:11:21 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> For example, take a look at the various frame* files:
>> 
>> frame.inline.hpp include frame.hpp - this is according to our rules
>> frame.hpp does one of our weird tricks to include the frame_<cpu>.hpp straight into the middle of the frame class (via the CPU_HEADER macro).
>> frame_<cpu>.inline.hpp can therefore not include the corresponding frame_<cpu>.hpp because if it did it would include the cpu-dependent parts of the frame class and that will not work.
>> 
>> Another think one has to consider is if the includes are written so that the platform files can be included stand-alone or not:
>> 
>> Sometimes we have this include order:
>> file.inline.hpp includes file.hpp and file_<cpu>.inline.hpp
>> file_<cpu>.inline.hpp doesn't include file.hpp because the only way to use file_<cpu>.inline.hpp is to include file.inline.hpp. file_<cpu>.inline.hpp can't be included stand-alone.
>> 
>> Sometimes we the opposite include order:
>> file_<cpu>.inline.hpp includes file.inline.hpp, which includes file.hpp, and file_<cpu>.inline.hpp can be included stand-alone.
>> 
>> If you are going to write a style guide for the platform includes you need to go through our includes and see if your proposal matches what we have. If not, you need to figure out if there's some refactoring that can be done to change files to match the proposal.
>
> Thanks for the detailed summary, indeed it looks like my initial proposal is not enough to address all cases. I'll think about it and go through the cases as you suggested.
> 
> For the time being, I moved #27259 to draft.

> Another think one has to consider is if the includes are written so that the platform files can be included stand-alone or not

If a header file (hpp or inline.hpp) can not be included stand alone, I would even argue it's not really a proper header file.

Even though `#include` is indeed just copy-and-paste, the use of `#include CPU_HEADER(frame)` still feels like an overuse of C/C++ header includes. I think those "improper" header files can "stand out" if they are named differently from ordinary one, maybe sth like `frame_X.partial.hpp`. My 2c.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27189#discussion_r2345139816

From wkemper at openjdk.org  Fri Sep 12 20:51:35 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 12 Sep 2025 20:51:35 GMT
Subject: RFR: 8367378: GenShen: Missing timing stats when old mark buffers are
 flushed during final update refs
Message-ID: <4VPUjd7cpG9QVAt6ISfPpuvNccMdVLHQay9ANSPCcHM=.d30d33d2-4978-4458-99ab-ed3396623cb5@github.com>

Clean backport. Adds trivial instrumentation.

-------------

Commit messages:
 - Backport 11df28916af4c2bfd69b2829c74e046ad953ee6c

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/220/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=220&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367378
  Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/220.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/220/head:pull/220

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/220

From wkemper at openjdk.org  Fri Sep 12 22:17:28 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 12 Sep 2025 22:17:28 GMT
Subject: Integrated: 8367378: GenShen: Missing timing stats when old mark
 buffers are flushed during final update refs
In-Reply-To: <4VPUjd7cpG9QVAt6ISfPpuvNccMdVLHQay9ANSPCcHM=.d30d33d2-4978-4458-99ab-ed3396623cb5@github.com>
References: <4VPUjd7cpG9QVAt6ISfPpuvNccMdVLHQay9ANSPCcHM=.d30d33d2-4978-4458-99ab-ed3396623cb5@github.com>
Message-ID: <ps8bhsoceCVRF4iUjSRNVyR29_Nc-itbfUpM2ug1Cm4=.47a2e2c9-2090-4c87-aa66-8eccc5751fbb@github.com>

On Fri, 12 Sep 2025 20:45:39 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Adds trivial instrumentation.

This pull request has now been integrated.

Changeset: d367a7b3
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/d367a7b3ae8915da6b5ce547de99250a6538e80d
Stats:     2 lines in 2 files changed: 2 ins; 0 del; 0 mod

8367378: GenShen: Missing timing stats when old mark buffers are flushed during final update refs

Backport-of: 11df28916af4c2bfd69b2829c74e046ad953ee6c

-------------

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/220

From wkemper at openjdk.org  Fri Sep 12 22:19:18 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 12 Sep 2025 22:19:18 GMT
Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a
 runtime diagnostic option
Message-ID: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com>

Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option.

-------------

Commit messages:
 - Make detailed evacuation tracking a diagnostic option in product builds

Changes: https://git.openjdk.org/jdk/pull/27238/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27238&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367473
  Stats: 36 lines in 4 files changed: 19 ins; 4 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/27238.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27238/head:pull/27238

PR: https://git.openjdk.org/jdk/pull/27238

From wkemper at openjdk.org  Fri Sep 12 22:19:18 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 12 Sep 2025 22:19:18 GMT
Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a
 runtime diagnostic option
In-Reply-To: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com>
References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com>
Message-ID: <dZTv61cCrDzRK6T2m4pFppVTuv4uWCOIAhAoL33D1jQ=.6c3643a6-684e-4bca-b6fb-633378e02216@github.com>

On Thu, 11 Sep 2025 22:43:23 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option.

Converted to draft while we wait for performance evaluations to complete.

This chart shows the distribution (as a box plot) of all concurrent evacuation times across all benchmarks and platforms for the past 24 hours (approximately 15K data points in total). Each facet of the chart shows 3 configurations:
* top: The diagnostic option in this PR is enabled
* middle: The diagnostic option is disabled
* bottom: The baseline - this behavior does not exist in the product build.

The first facet shows the effect of this option on _global_ GCs in Genshen. The second facet shows the effect of this option on _global_ GCs in Shenandoah. The last option shows the effect on _young_ evacuation in GenShen. The performance impact of testing if the option is enabled seems minimal for Genshen. The impact when the option is enabled is small, but notable. I cannot explain the outlier (p100) for Genshen's young collections on master. 

<img width="1830" height="650" alt="image" src="https://github.com/user-attachments/assets/04b46996-9bf8-4dea-a208-85960a9fd942" />

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27238#issuecomment-3282858675
PR Comment: https://git.openjdk.org/jdk/pull/27238#issuecomment-3286899661

From kdnilsen at openjdk.org  Fri Sep 12 22:19:19 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 12 Sep 2025 22:19:19 GMT
Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a
 runtime diagnostic option
In-Reply-To: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com>
References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com>
Message-ID: <Jzmu1RfgjgB7PWV18bcGhS5Lb65QrcCv5ceN0JsXz6M=.fc52f5ee-4cfe-44c5-b617-9509a8dc20bd@github.com>

On Thu, 11 Sep 2025 22:43:23 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option.

src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 326:

> 324:     return ShenandoahBarrierSet::resolve_forwarded(p);
> 325:   }
> 326: 

Am wondering if we can template the implementation of try_evacuate_object and the LRB also, so that the fast path is unaffected by the existence of this extra run-time check.  I'm curious to see if there is a measurable impact on performance from this change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27238#discussion_r2342574645

From wkemper at openjdk.org  Fri Sep 12 23:32:55 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 12 Sep 2025 23:32:55 GMT
Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may raise
 threshold prematurely
Message-ID: <StL32ysKb0Tl01zLAA7kZiZZol3KoIKc8mM41rMlSMw=.9fc5f3b6-966d-48cd-b3f0-d38bdda5f6dd@github.com>

Not clean. Conflicts were because of format specifiers for the most part.

-------------

Commit messages:
 - 8365956: GenShen: Adaptive tenuring threshold algorithm may raise threshold prematurely

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/221/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=221&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365956
  Stats: 348 lines in 15 files changed: 255 ins; 30 del; 63 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/221.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/221/head:pull/221

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/221

From kdnilsen at openjdk.org  Sun Sep 14 01:32:27 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sun, 14 Sep 2025 01:32:27 GMT
Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a
 runtime diagnostic option
In-Reply-To: <dZTv61cCrDzRK6T2m4pFppVTuv4uWCOIAhAoL33D1jQ=.6c3643a6-684e-4bca-b6fb-633378e02216@github.com>
References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com>
 <dZTv61cCrDzRK6T2m4pFppVTuv4uWCOIAhAoL33D1jQ=.6c3643a6-684e-4bca-b6fb-633378e02216@github.com>
Message-ID: <ZTs_rUh2oRR3hUJRoQh2lk-930aEGXLX2GGdV00gPbM=.5e7577d0-f76d-4528-a29a-ac9859db7dcf@github.com>

On Fri, 12 Sep 2025 21:29:39 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This chart shows the distribution (as a box plot) of all concurrent evacuation times across all benchmarks and platforms for the past 24 hours (approximately 15K data points in total). Each facet of the chart shows 3 configurations:
> 
> * top: The diagnostic option in this PR is enabled
> * middle: The diagnostic option is disabled
> * bottom: The baseline - this behavior does not exist in the product build.

I'm confused.  It looks like it takes more time when this option is disabled.  And it looks like this branch runs in less time than baseline, when this option is enabled.  Can you explain what I'm missing?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27238#issuecomment-3289060922

From kdnilsen at openjdk.org  Sun Sep 14 01:32:28 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sun, 14 Sep 2025 01:32:28 GMT
Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a
 runtime diagnostic option
In-Reply-To: <Jzmu1RfgjgB7PWV18bcGhS5Lb65QrcCv5ceN0JsXz6M=.fc52f5ee-4cfe-44c5-b617-9509a8dc20bd@github.com>
References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com>
 <Jzmu1RfgjgB7PWV18bcGhS5Lb65QrcCv5ceN0JsXz6M=.fc52f5ee-4cfe-44c5-b617-9509a8dc20bd@github.com>
Message-ID: <BL4erOWcJ9xUKnAFEh6ezAT7baC_7qKA_iOsp56KQ1g=.02e6966f-d554-4165-ad8b-c58b577e493f@github.com>

On Thu, 11 Sep 2025 23:31:11 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option.
>
> src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 326:
> 
>> 324:     return ShenandoahBarrierSet::resolve_forwarded(p);
>> 325:   }
>> 326: 
> 
> Am wondering if we can template the implementation of try_evacuate_object and the LRB also, so that the fast path is unaffected by the existence of this extra run-time check.  I'm curious to see if there is a measurable impact on performance from this change.

If we decide we want "better performance", it seems we could have two versions of the GC worker thread evacuation closures.  One calls the templated version try_evacuate_object() that has this instrumentation in it.  The other calls the templated version of try_evacuate_object() that does not have this instrumentation in it.  For LRB, I assume we could have an if-then-else to decide which version to call.  LRB evacuations are quite rare, I believe, so that doesn't bother me so much.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27238#discussion_r2347058185

From stefank at openjdk.org  Mon Sep 15 05:58:17 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 15 Sep 2025 05:58:17 GMT
Subject: RFR: 8367320: Sort cpu/x86 includes [v2]
In-Reply-To: <HAFfhfrfnAkgEYHFhqHf6Qr4w2R5hxqvt4HLj0hSG6Q=.3976df26-0aad-47fd-bd6f-77861fa5d2ab@github.com>
References: <qcY0LlIm4IjPerZIS-HXD7szCbJ9WvkADuu56oSKj4U=.9de36603-eefd-4de0-bcf6-8f7e311f4863@github.com>
 <uJxrEpfWrvgPfNCgOnTFCGUMNPWnpRFD37ShnSio-nk=.ba8506fc-b091-4540-8647-2d888f037c0a@github.com>
 <SEbNcGLpW0yfTiFrVP5TCq7_44jOAE-eIBKMLuyVZng=.6303168d-2591-4e72-a1ac-99a608784e8d@github.com>
 <cc3NNxUCaYZGZntgK1VfPijHJaJqFLRaddVbGXQdrwk=.6d24ac68-c79c-48c6-b521-fba161e306ac@github.com>
 <PfLzz6AW41vw7IQwUI5xVVsS7oV_bqjQMT6a3QAglVk=.9c270ec5-ab35-48c5-85e4-9dd983c9a0b5@github.com>
 <qn4oadwPRuZd-b8jDslu4RM2tcUbdN8eR10xQSCx66M=.e5d7f943-521a-4b9d-ba7f-7cc417f24bda@github.com>
 <JLtJZTSVo2RMFjOqLK4umUdDychDTLExEKTF7VgvbCM=.8cde6896-846e-4d19-9785-cb1a09b444a7@github.com>
 <Zu6vbcuY4pyxPsWVH9slAWbfjLc5aIfdQNou7LVWe1U=.0987ca43-67ab-4155-aebb-a6cc9c570f5b@github.com>
 <eZUFEcB_v4sAhJvc5iBhSea6pful4_0FyQ9EjeHbXq4=.fcbbbaaf-a91f-4edd-b5a1-c44665a6c3c9@github.com>
 <_4mRtYH_RWgbVHs49HojPPTYfzSidVOKkCypb-nSBbc=.b1854ffb-1b14-470d-9350-6f02d5673dd7@github.com>
 <HAFfhfrfnAkgEYHFhqHf6Qr4w2R5hxqvt4H
 Lj0hSG6Q=.3976df26-0aad-47fd-bd6f-77861fa5d2ab@github.com>
Message-ID: <g8LqNSsJLizIic-IL_wdIjC5bSf88hFEgigGJg05GAQ=.7da5e62d-22ae-4779-88d8-ee3e5beb49cb@github.com>

On Fri, 12 Sep 2025 18:43:52 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thanks for the detailed summary, indeed it looks like my initial proposal is not enough to address all cases. I'll think about it and go through the cases as you suggested.
>> 
>> For the time being, I moved #27259 to draft.
>
>> Another think one has to consider is if the includes are written so that the platform files can be included stand-alone or not
> 
> If a header file (hpp or inline.hpp) can not be included stand alone, I would even argue it's not really a proper header file.
> 
> Even though `#include` is indeed just copy-and-paste, the use of `#include CPU_HEADER(frame)` still feels like an overuse of C/C++ header includes. I think those "improper" header files can "stand out" if they are named differently from ordinary one, maybe sth like `frame_X.partial.hpp`. My 2c.

FWIW, while writing the above and looking through the files I had a similar reaction to what Albert writes here. We would still need to differentiate between .hpp and .inline.hpp files. Maybe:

file.partial.hpp
file.partial.inline.hpp


Another interesting pattern we have can be found in the gc_globals.hpp and g1_globals.hpp files:

If you want the flags from g1_globals.hpp you must include gc_globals.hpp. g1_globals.hpp can be included stand-alone, but it won't do you much good because the declarations of the flags are generated by including gc_globals.hpp. Should g1_globals.hpp then be named g1_globals.partial.hpp?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27189#discussion_r2347943256

From wkemper at openjdk.org  Mon Sep 15 16:27:47 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 15 Sep 2025 16:27:47 GMT
Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a
 runtime diagnostic option
In-Reply-To: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com>
References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com>
Message-ID: <pgGPXdydvBtRC_MtlpNiIZEKFsXaJUgFl7szOn6Bj6A=.6f3dfce3-ce7b-40d4-802a-7750f78d40e1@github.com>

On Thu, 11 Sep 2025 22:43:23 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option.

I think we can ignore the outliers (the long "whisker" in the box plot represents p100 (max) time). The `master` branch likely has more benchmark runs than the feature branches so it may in turn be more likely to experience a long evacuation phase. The colored portion of the box plot represents P25 to P75 and aligns more with my expectations for the performance. I don't have an explanation for why enabling the diagnostic feature seems to reduce the severity of the outliers.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27238#issuecomment-3292981876

From kdnilsen at openjdk.org  Mon Sep 15 19:55:09 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 15 Sep 2025 19:55:09 GMT
Subject: RFR: 8367708: GenShen: Reduce total evacuation burden
Message-ID: <XgAjKd4zPFG5jDJ7OoyvefR9AiDN_Rj8nCMQlClXKQE=.23d80412-fddf-4e52-b25f-3be1e6d82c8e@github.com>

This PR provides several improvements that cumulatively reduce the amount of evacuation performed by GenShen compared to traditional Shenandoah. Specifically:

1. Do not promote humongous arrays of primitive data.  Leaving these regions in the young generation allows them to be reclaimed more quickly when they become garbage.  There is no disadvantage to leaving these regions in the young generation as their contents does not need to be scanned by the garbage collector.
2. Change the default value of ShenandoahOldGarbageThreshold from 15% to 25%.  This results in smaller sets of candidate regions for mixed evacuation, less aggressive compaction of old generation.  This also increases the likelihood that a region will be promoted in place instead of promoted by evacuation.
3. Only promote regions in place if the used within a region exceeds ShenandoahGenerationalMinPIPUsage (default 30) percent of the heap region size.  This is enforced in combination with the preexisting requirement that the garbage within the region be less than ShenandoahOldGarbageThreshold (new default 25) percent of the heap region size.  This causes regions with very low utilization to be promoted by evacuation rather than promoted in place.  While the immediate effect of this change is to perform more copying when the region is promoted, the secondary effect is that this region does not need to be evacuated at a later time, after it has accumulate more live data, as part of an effort to defragment old-gen memory.
4. Only defragment old-gen memory if the command-line has requested non-zero reserves for humongous objects (ShenandoahGenerationalHumongousReserves).  Previously, we would invest in defragmenting old-gen memory every time we finished old-generation marking, even if ShenandoahGenerationalHumongousReserves equals zero.

-------------

Commit messages:
 - Merge remote-tracking branch 'jdk/master' into combined-evac-improvements
 - Merge remote-tracking branch 'origin/master' into combined-evac-improvements
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - manualy resolve evac tracker diffs
 - Merge remote-tracking branch 'jdk/master' into combined-evac-improvements
 - Merge remote-tracking branch 'jdk/master' into combined-evac-improvements-gh
 - Only defragment old if non-zero humongous reserve
 - Less aggressive compaction of old
 - ... and 40 more: https://git.openjdk.org/jdk/compare/5271448b...6fc458aa

Changes: https://git.openjdk.org/jdk/pull/27278/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27278&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367708
  Stats: 50 lines in 6 files changed: 29 ins; 5 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/27278.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27278/head:pull/27278

PR: https://git.openjdk.org/jdk/pull/27278

From kdnilsen at openjdk.org  Mon Sep 15 19:55:09 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 15 Sep 2025 19:55:09 GMT
Subject: RFR: 8367708: GenShen: Reduce total evacuation burden
In-Reply-To: <XgAjKd4zPFG5jDJ7OoyvefR9AiDN_Rj8nCMQlClXKQE=.23d80412-fddf-4e52-b25f-3be1e6d82c8e@github.com>
References: <XgAjKd4zPFG5jDJ7OoyvefR9AiDN_Rj8nCMQlClXKQE=.23d80412-fddf-4e52-b25f-3be1e6d82c8e@github.com>
Message-ID: <UzramcQ25OF-aYGofwM4tP1_0EaFHYb-UTaV0iV95iM=.93aea75c-fcc8-43f3-a9be-19132d252454@github.com>

On Mon, 15 Sep 2025 04:44:24 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This PR provides several improvements that cumulatively reduce the amount of evacuation performed by GenShen compared to traditional Shenandoah. Specifically:
> 
> 1. Do not promote humongous arrays of primitive data.  Leaving these regions in the young generation allows them to be reclaimed more quickly when they become garbage.  There is no disadvantage to leaving these regions in the young generation as their contents does not need to be scanned by the garbage collector.
> 2. Change the default value of ShenandoahOldGarbageThreshold from 15% to 25%.  This results in smaller sets of candidate regions for mixed evacuation, less aggressive compaction of old generation.  This also increases the likelihood that a region will be promoted in place instead of promoted by evacuation.
> 3. Only promote regions in place if the used within a region exceeds ShenandoahGenerationalMinPIPUsage (default 30) percent of the heap region size.  This is enforced in combination with the preexisting requirement that the garbage within the region be less than ShenandoahOldGarbageThreshold (new default 25) percent of the heap region size.  This causes regions with very low utilization to be promoted by evacuation rather than promoted in place.  While the immediate effect of this change is to perform more copying when the region is promoted, the secondary effect is that this region does not need to be evacuated at a later time, after it has accumulate more live data, as part of an effort to defragment old-gen memory.
> 4. Only defragment old-gen memory if the command-line has requested non-zero reserves for humongous objects (ShenandoahGenerationalHumongousReserves).  Previously, we would invest in defragmenting old-gen memory every time we finished old-generation marking, even if ShenandoahGenerationalHumongousReserves equals zero.

The impact on overall SpecJBB scores has been minimal.

Compare top charts (proposed PR) with bottom charts (baseline). These charts show the maximum number of bytes evacuated by workers and mutators into the old generation (blue, purple) across all benchmarks (~20 executions of 6 benchmark suites) and platforms (x86, aarch64).  Green represents young bytes evacuated by workers; red is young bytes evacuated by mutators.  Young evacuations increase slightly with this reduction in old evacuations.

<img width="2531" height="1354" alt="image" src="https://github.com/user-attachments/assets/1ec1b300-abd2-49a8-9a63-312e821d60d8" />

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27278#issuecomment-3293659081

From wkemper at openjdk.org  Mon Sep 15 21:06:17 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 15 Sep 2025 21:06:17 GMT
Subject: RFR: 8367708: GenShen: Reduce total evacuation burden
In-Reply-To: <XgAjKd4zPFG5jDJ7OoyvefR9AiDN_Rj8nCMQlClXKQE=.23d80412-fddf-4e52-b25f-3be1e6d82c8e@github.com>
References: <XgAjKd4zPFG5jDJ7OoyvefR9AiDN_Rj8nCMQlClXKQE=.23d80412-fddf-4e52-b25f-3be1e6d82c8e@github.com>
Message-ID: <Xyx6J_ybXtLQKiNqKm7wLphPeDLrxYkUfp_YqnsPH9M=.d2a92368-101b-4c0e-b2e3-83bf469d2ac4@github.com>

On Mon, 15 Sep 2025 04:44:24 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This PR provides several improvements that cumulatively reduce the amount of evacuation performed by GenShen compared to traditional Shenandoah. Specifically:
> 
> 1. Do not promote humongous arrays of primitive data.  Leaving these regions in the young generation allows them to be reclaimed more quickly when they become garbage.  There is no disadvantage to leaving these regions in the young generation as their contents does not need to be scanned by the garbage collector.
> 2. Change the default value of ShenandoahOldGarbageThreshold from 15% to 25%.  This results in smaller sets of candidate regions for mixed evacuation, less aggressive compaction of old generation.  This also increases the likelihood that a region will be promoted in place instead of promoted by evacuation.
> 3. Only promote regions in place if the used within a region exceeds ShenandoahGenerationalMinPIPUsage (default 30) percent of the heap region size.  This is enforced in combination with the preexisting requirement that the garbage within the region be less than ShenandoahOldGarbageThreshold (new default 25) percent of the heap region size.  This causes regions with very low utilization to be promoted by evacuation rather than promoted in place.  While the immediate effect of this change is to perform more copying when the region is promoted, the secondary effect is that this region does not need to be evacuated at a later time, after it has accumulated more live data, as part of an effort to defragment old-gen memory.
> 4. Only defragment old-gen memory if the command-line has requested non-zero reserves for humongous objects (ShenandoahGenerationalHumongousReserves).  Previously, we would invest in defragmenting old-gen memory every time we finished old-generation marking, even if ShenandoahGenerationalHumongousReserves equals zero.

I think there is an accidental change in here that reverts https://github.com/openjdk/jdk/pull/26256.

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1443:

> 1441: 
> 1442:   oop humongous_obj = cast_to_oop(start->bottom());
> 1443:   size_t size = humongous_obj->size();

Is this intentional? This looks like it would reintroduce https://github.com/openjdk/jdk/pull/26256 (crash trying to access size of humongous object after its class has been unloaded).

src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 841:

> 839:   static inline void atomic_clear_oop(narrowOop* addr, narrowOop compare);
> 840: 
> 841:   size_t trash_humongous_region_at(ShenandoahHeapRegion *r);

Original method was `const`, removal seems unintentional.

-------------

Changes requested by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27278#pullrequestreview-3226316735
PR Review Comment: https://git.openjdk.org/jdk/pull/27278#discussion_r2350120750
PR Review Comment: https://git.openjdk.org/jdk/pull/27278#discussion_r2350122230

From kdnilsen at openjdk.org  Mon Sep 15 21:32:25 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 15 Sep 2025 21:32:25 GMT
Subject: RFR: 8367708: GenShen: Reduce total evacuation burden
In-Reply-To: <Xyx6J_ybXtLQKiNqKm7wLphPeDLrxYkUfp_YqnsPH9M=.d2a92368-101b-4c0e-b2e3-83bf469d2ac4@github.com>
References: <XgAjKd4zPFG5jDJ7OoyvefR9AiDN_Rj8nCMQlClXKQE=.23d80412-fddf-4e52-b25f-3be1e6d82c8e@github.com>
 <Xyx6J_ybXtLQKiNqKm7wLphPeDLrxYkUfp_YqnsPH9M=.d2a92368-101b-4c0e-b2e3-83bf469d2ac4@github.com>
Message-ID: <HYKx5tXVHfm5IPRrRlcDnk8drLST0PtBBQejDKaRu3Y=.53e0af51-3237-4760-9b4a-81747af9ec03@github.com>

On Mon, 15 Sep 2025 20:59:32 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This PR provides several improvements that cumulatively reduce the amount of evacuation performed by GenShen compared to traditional Shenandoah. Specifically:
>> 
>> 1. Do not promote humongous arrays of primitive data.  Leaving these regions in the young generation allows them to be reclaimed more quickly when they become garbage.  There is no disadvantage to leaving these regions in the young generation as their contents does not need to be scanned by the garbage collector.
>> 2. Change the default value of ShenandoahOldGarbageThreshold from 15% to 25%.  This results in smaller sets of candidate regions for mixed evacuation, less aggressive compaction of old generation.  This also increases the likelihood that a region will be promoted in place instead of promoted by evacuation.
>> 3. Only promote regions in place if the used within a region exceeds ShenandoahGenerationalMinPIPUsage (default 30) percent of the heap region size.  This is enforced in combination with the preexisting requirement that the garbage within the region be less than ShenandoahOldGarbageThreshold (new default 25) percent of the heap region size.  This causes regions with very low utilization to be promoted by evacuation rather than promoted in place.  While the immediate effect of this change is to perform more copying when the region is promoted, the secondary effect is that this region does not need to be evacuated at a later time, after it has accumulated more live data, as part of an effort to defragment old-gen memory.
>> 4. Only defragment old-gen memory if the command-line has requested non-zero reserves for humongous objects (ShenandoahGenerationalHumongousReserves).  Previously, we would invest in defragmenting old-gen memory every time we finished old-generation marking, even if ShenandoahGenerationalHumongousReserves equals zero.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1443:
> 
>> 1441: 
>> 1442:   oop humongous_obj = cast_to_oop(start->bottom());
>> 1443:   size_t size = humongous_obj->size();
> 
> Is this intentional? This looks like it would reintroduce https://github.com/openjdk/jdk/pull/26256 (crash trying to access size of humongous object after its class has been unloaded).

good catch.  I'll change how this is implemented.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27278#discussion_r2350171314

From phh at openjdk.org  Mon Sep 15 23:02:13 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Mon, 15 Sep 2025 23:02:13 GMT
Subject: RFR: 8367450: Shenandoah: Log the composition of the collection
 set
In-Reply-To: <F_eMy4j26l3Nk4DM8ObN1mGLjaFvzHs0IlBfMV0zeqc=.0063c575-fc07-4a6b-801d-ea6f7b97dff7@github.com>
References: <F_eMy4j26l3Nk4DM8ObN1mGLjaFvzHs0IlBfMV0zeqc=.0063c575-fc07-4a6b-801d-ea6f7b97dff7@github.com>
Message-ID: <dbaZBECqlAkvH4Y1eiLfSCyPueEerL1R15roJyKWamg=.9bc38a4e-2c14-4ccf-90bb-5ce60b90d70d@github.com>

On Thu, 11 Sep 2025 21:40:50 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Reuse the same log message from GenShen which details the composition of the live data to be evacuated. In the non-generational modes, all regions are considered young and nothing will be promoted (or old).

Shouldn't evacInfo be initialized via constructor?

-------------

PR Review: https://git.openjdk.org/jdk/pull/27235#pullrequestreview-3226556674

From phh at openjdk.org  Mon Sep 15 23:10:13 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Mon, 15 Sep 2025 23:10:13 GMT
Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a
 runtime diagnostic option
In-Reply-To: <BL4erOWcJ9xUKnAFEh6ezAT7baC_7qKA_iOsp56KQ1g=.02e6966f-d554-4165-ad8b-c58b577e493f@github.com>
References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com>
 <Jzmu1RfgjgB7PWV18bcGhS5Lb65QrcCv5ceN0JsXz6M=.fc52f5ee-4cfe-44c5-b617-9509a8dc20bd@github.com>
 <BL4erOWcJ9xUKnAFEh6ezAT7baC_7qKA_iOsp56KQ1g=.02e6966f-d554-4165-ad8b-c58b577e493f@github.com>
Message-ID: <z8RZzywvbZ4PgJWhs6eP5NqLt0ZC1Jie-uPxubkMF7w=.17300d8a-5640-4bff-bcbf-175ad84fac47@github.com>

On Sun, 14 Sep 2025 01:28:33 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 326:
>> 
>>> 324:     return ShenandoahBarrierSet::resolve_forwarded(p);
>>> 325:   }
>>> 326: 
>> 
>> Am wondering if we can template the implementation of try_evacuate_object and the LRB also, so that the fast path is unaffected by the existence of this extra run-time check.  I'm curious to see if there is a measurable impact on performance from this change.
>
> If we decide we want "better performance", it seems we could have two versions of the GC worker thread evacuation closures.  One calls the templated version try_evacuate_object() that has this instrumentation in it.  The other calls the templated version of try_evacuate_object() that does not have this instrumentation in it.  For LRB, I assume we could have an if-then-else to decide which version to call.  LRB evacuations are quite rare, I believe, so that doesn't bother me so much.

On typical hardware, if the test is in the fast path, the load of ShenandoahEvacTracking will hit in L1, the latency will be absorbed by speculation, and the cmp/branch is a single clock. So maybe 2 clocks at most. Downside is that if ShenandoahEvacTracking is the only thing being accessed in its cache line, you waste an L1 line.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27238#discussion_r2350295732

From kdnilsen at openjdk.org  Mon Sep 15 23:16:01 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 15 Sep 2025 23:16:01 GMT
Subject: RFR: 8367708: GenShen: Reduce total evacuation burden [v2]
In-Reply-To: <XgAjKd4zPFG5jDJ7OoyvefR9AiDN_Rj8nCMQlClXKQE=.23d80412-fddf-4e52-b25f-3be1e6d82c8e@github.com>
References: <XgAjKd4zPFG5jDJ7OoyvefR9AiDN_Rj8nCMQlClXKQE=.23d80412-fddf-4e52-b25f-3be1e6d82c8e@github.com>
Message-ID: <SflkpWm-5l_zIeZkqHl0RB3QSq9PNxcWSUn6yi3QvM0=.486198ca-46aa-47da-abd5-7ae9789ba210@github.com>

> This PR provides several improvements that cumulatively reduce the amount of evacuation performed by GenShen compared to traditional Shenandoah. Specifically:
> 
> 1. Do not promote humongous arrays of primitive data.  Leaving these regions in the young generation allows them to be reclaimed more quickly when they become garbage.  There is no disadvantage to leaving these regions in the young generation as their contents does not need to be scanned by the garbage collector.
> 2. Change the default value of ShenandoahOldGarbageThreshold from 15% to 25%.  This results in smaller sets of candidate regions for mixed evacuation, less aggressive compaction of old generation.  This also increases the likelihood that a region will be promoted in place instead of promoted by evacuation.
> 3. Only promote regions in place if the used within a region exceeds ShenandoahGenerationalMinPIPUsage (default 30) percent of the heap region size.  This is enforced in combination with the preexisting requirement that the garbage within the region be less than ShenandoahOldGarbageThreshold (new default 25) percent of the heap region size.  This causes regions with very low utilization to be promoted by evacuation rather than promoted in place.  While the immediate effect of this change is to perform more copying when the region is promoted, the secondary effect is that this region does not need to be evacuated at a later time, after it has accumulated more live data, as part of an effort to defragment old-gen memory.
> 4. Only defragment old-gen memory if the command-line has requested non-zero reserves for humongous objects (ShenandoahGenerationalHumongousReserves).  Previously, we would invest in defragmenting old-gen memory every time we finished old-generation marking, even if ShenandoahGenerationalHumongousReserves equals zero.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  Respond to reviewer feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27278/files
  - new: https://git.openjdk.org/jdk/pull/27278/files/6fc458aa..69a76009

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27278&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27278&range=00-01

  Stats: 20 lines in 2 files changed: 9 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/27278.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27278/head:pull/27278

PR: https://git.openjdk.org/jdk/pull/27278

From wkemper at openjdk.org  Tue Sep 16 00:02:14 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 16 Sep 2025 00:02:14 GMT
Subject: RFR: 8367708: GenShen: Reduce total evacuation burden [v2]
In-Reply-To: <SflkpWm-5l_zIeZkqHl0RB3QSq9PNxcWSUn6yi3QvM0=.486198ca-46aa-47da-abd5-7ae9789ba210@github.com>
References: <XgAjKd4zPFG5jDJ7OoyvefR9AiDN_Rj8nCMQlClXKQE=.23d80412-fddf-4e52-b25f-3be1e6d82c8e@github.com>
 <SflkpWm-5l_zIeZkqHl0RB3QSq9PNxcWSUn6yi3QvM0=.486198ca-46aa-47da-abd5-7ae9789ba210@github.com>
Message-ID: <hhOVSR-SZ3FbsSHNDpaYYP281hvYFpgL5epw8dxebyQ=.c7d516fc-ae6d-4184-b80e-61d58db5202e@github.com>

On Mon, 15 Sep 2025 23:16:01 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This PR provides several improvements that cumulatively reduce the amount of evacuation performed by GenShen compared to traditional Shenandoah. Specifically:
>> 
>> 1. Do not promote humongous arrays of primitive data.  Leaving these regions in the young generation allows them to be reclaimed more quickly when they become garbage.  There is no disadvantage to leaving these regions in the young generation as their contents does not need to be scanned by the garbage collector.
>> 2. Change the default value of ShenandoahOldGarbageThreshold from 15% to 25%.  This results in smaller sets of candidate regions for mixed evacuation, less aggressive compaction of old generation.  This also increases the likelihood that a region will be promoted in place instead of promoted by evacuation.
>> 3. Only promote regions in place if the used within a region exceeds ShenandoahGenerationalMinPIPUsage (default 30) percent of the heap region size.  This is enforced in combination with the preexisting requirement that the garbage within the region be less than ShenandoahOldGarbageThreshold (new default 25) percent of the heap region size.  This causes regions with very low utilization to be promoted by evacuation rather than promoted in place.  While the immediate effect of this change is to perform more copying when the region is promoted, the secondary effect is that this region does not need to be evacuated at a later time, after it has accumulated more live data, as part of an effort to defragment old-gen memory.
>> 4. Only defragment old-gen memory if the command-line has requested non-zero reserves for humongous objects (ShenandoahGenerationalHumongousReserves).  Previously, we would invest in defragmenting old-gen memory every time we finished old-generation marking, even if ShenandoahGenerationalHumongousReserves equals zero.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to reviewer feedback

Changes requested by wkemper (Reviewer).

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1442:

> 1440:   assert(start->is_humongous_start(), "reclaim regions starting with the first one");
> 1441: 
> 1442:   // Cannot access humongous_obj->size() in case class has been unloaded

Why do we want to make two passes over the humongous object? I don't see why the original code needs to change or how this change is related to this PR?

-------------

PR Review: https://git.openjdk.org/jdk/pull/27278#pullrequestreview-3226643002
PR Review Comment: https://git.openjdk.org/jdk/pull/27278#discussion_r2350352216

From wkemper at openjdk.org  Tue Sep 16 00:30:37 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 16 Sep 2025 00:30:37 GMT
Subject: RFR: 8367450: Shenandoah: Log the composition of the collection
 set [v2]
In-Reply-To: <F_eMy4j26l3Nk4DM8ObN1mGLjaFvzHs0IlBfMV0zeqc=.0063c575-fc07-4a6b-801d-ea6f7b97dff7@github.com>
References: <F_eMy4j26l3Nk4DM8ObN1mGLjaFvzHs0IlBfMV0zeqc=.0063c575-fc07-4a6b-801d-ea6f7b97dff7@github.com>
Message-ID: <lotfS3nWbNUGopdQ3Jj_fivEW2RBVTb4cZrcd9cvrkI=.8873c73c-458d-4a02-9fa4-fd65c780a655@github.com>

> Reuse the same log message from GenShen which details the composition of the live data to be evacuated. In the non-generational modes, all regions are considered young and nothing will be promoted (or old).

William Kemper has updated the pull request incrementally with one additional commit since the last revision:

  Simplify JFR evac info reporting

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27235/files
  - new: https://git.openjdk.org/jdk/pull/27235/files/b3e10d4c..14d36331

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27235&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27235&range=00-01

  Stats: 162 lines in 4 files changed: 1 ins; 131 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/27235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27235/head:pull/27235

PR: https://git.openjdk.org/jdk/pull/27235

From duke at openjdk.org  Tue Sep 16 04:04:19 2025
From: duke at openjdk.org (Rui Li)
Date: Tue, 16 Sep 2025 04:04:19 GMT
Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a
 runtime diagnostic option
In-Reply-To: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com>
References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com>
Message-ID: <QvKbV2L9Y1FQsAwOrxHwTIWdhUPvr7Px5Owy8gtP1sI=.d24e95ca-8fd5-4075-93aa-97973cd01924@github.com>

On Thu, 11 Sep 2025 22:43:23 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option.

This print might also need to be sandwiched by the `ShenandoahEvacTracking` flag check? https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.cpp#L332-L333

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27238#issuecomment-3294824583

From phh at openjdk.org  Tue Sep 16 15:53:37 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Tue, 16 Sep 2025 15:53:37 GMT
Subject: RFR: 8367450: Shenandoah: Log the composition of the collection
 set [v2]
In-Reply-To: <lotfS3nWbNUGopdQ3Jj_fivEW2RBVTb4cZrcd9cvrkI=.8873c73c-458d-4a02-9fa4-fd65c780a655@github.com>
References: <F_eMy4j26l3Nk4DM8ObN1mGLjaFvzHs0IlBfMV0zeqc=.0063c575-fc07-4a6b-801d-ea6f7b97dff7@github.com>
 <lotfS3nWbNUGopdQ3Jj_fivEW2RBVTb4cZrcd9cvrkI=.8873c73c-458d-4a02-9fa4-fd65c780a655@github.com>
Message-ID: <kMM_UYJKTxTdG2199MHZ4ugDrje_MBgu12FbR6IHzHU=.d1ea6ba9-2ffb-47f7-bd89-1d2ddc480a5c@github.com>

On Tue, 16 Sep 2025 00:30:37 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Reuse the same log message from GenShen which details the composition of the live data to be evacuated. In the non-generational modes, all regions are considered young and nothing will be promoted (or old).
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify JFR evac info reporting

Use a copy constructor in shenandoahTrace.cpp, ShenandoahTracer::report_evacuation_info? If you just copy fields, you might miss a few if the definition of ShenandoahEvacuationInformation changes.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27235#pullrequestreview-3230650440

From phh at openjdk.org  Tue Sep 16 16:16:58 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Tue, 16 Sep 2025 16:16:58 GMT
Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a
 runtime diagnostic option
In-Reply-To: <z8RZzywvbZ4PgJWhs6eP5NqLt0ZC1Jie-uPxubkMF7w=.17300d8a-5640-4bff-bcbf-175ad84fac47@github.com>
References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com>
 <Jzmu1RfgjgB7PWV18bcGhS5Lb65QrcCv5ceN0JsXz6M=.fc52f5ee-4cfe-44c5-b617-9509a8dc20bd@github.com>
 <BL4erOWcJ9xUKnAFEh6ezAT7baC_7qKA_iOsp56KQ1g=.02e6966f-d554-4165-ad8b-c58b577e493f@github.com>
 <z8RZzywvbZ4PgJWhs6eP5NqLt0ZC1Jie-uPxubkMF7w=.17300d8a-5640-4bff-bcbf-175ad84fac47@github.com>
Message-ID: <8igXcI511iS8lbECWTA213zFWiLfBwW9I6x12ng2wrA=.c89b70e0-35b3-46b8-a091-013a5d0ffb90@github.com>

On Mon, 15 Sep 2025 23:06:36 GMT, Paul Hohensee <phh at openjdk.org> wrote:

>> If we decide we want "better performance", it seems we could have two versions of the GC worker thread evacuation closures.  One calls the templated version try_evacuate_object() that has this instrumentation in it.  The other calls the templated version of try_evacuate_object() that does not have this instrumentation in it.  For LRB, I assume we could have an if-then-else to decide which version to call.  LRB evacuations are quite rare, I believe, so that doesn't bother me so much.
>
> On typical hardware, if the test is in the fast path, the load of ShenandoahEvacTracking will hit in L1, the latency will be absorbed by speculation, and the cmp/branch is a single clock. So maybe 2 clocks at most. Downside is that if ShenandoahEvacTracking is the only thing being accessed in its cache line, you waste an L1 line.

If there are two evac closure versions, then the choice must be made at a higher level than at the closure invocation point, otherwise it's the same cost.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27238#discussion_r2353011393

From wkemper at openjdk.org  Tue Sep 16 17:40:17 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 16 Sep 2025 17:40:17 GMT
Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may
 raise threshold prematurely [v2]
In-Reply-To: <StL32ysKb0Tl01zLAA7kZiZZol3KoIKc8mM41rMlSMw=.9fc5f3b6-966d-48cd-b3f0-d38bdda5f6dd@github.com>
References: <StL32ysKb0Tl01zLAA7kZiZZol3KoIKc8mM41rMlSMw=.9fc5f3b6-966d-48cd-b3f0-d38bdda5f6dd@github.com>
Message-ID: <Yx5JP6k8BdZ5qig9rmN0YdqcT_Vhb5GetqrMefvXoeA=.07c40709-4331-484e-90ee-e1f1439cd1af@github.com>

> Not clean. Conflicts were because of format specifiers for the most part.

William Kemper has updated the pull request incrementally with one additional commit since the last revision:

  Need to include precompiled header for windows on this branch

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/221/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/221/files/9a77396d..51148379

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=221&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=221&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/221.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/221/head:pull/221

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/221

From kdnilsen at openjdk.org  Tue Sep 16 17:56:09 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 16 Sep 2025 17:56:09 GMT
Subject: RFR: 8367708: GenShen: Reduce total evacuation burden [v2]
In-Reply-To: <HYKx5tXVHfm5IPRrRlcDnk8drLST0PtBBQejDKaRu3Y=.53e0af51-3237-4760-9b4a-81747af9ec03@github.com>
References: <XgAjKd4zPFG5jDJ7OoyvefR9AiDN_Rj8nCMQlClXKQE=.23d80412-fddf-4e52-b25f-3be1e6d82c8e@github.com>
 <Xyx6J_ybXtLQKiNqKm7wLphPeDLrxYkUfp_YqnsPH9M=.d2a92368-101b-4c0e-b2e3-83bf469d2ac4@github.com>
 <HYKx5tXVHfm5IPRrRlcDnk8drLST0PtBBQejDKaRu3Y=.53e0af51-3237-4760-9b4a-81747af9ec03@github.com>
Message-ID: <gjLI40GooIo_oHYSR-7aRFixAki0aan4-0uB8AXy53E=.abedd0f0-a219-4f23-9393-08dc86b73bcd@github.com>

On Mon, 15 Sep 2025 21:29:17 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1443:
>> 
>>> 1441: 
>>> 1442:   oop humongous_obj = cast_to_oop(start->bottom());
>>> 1443:   size_t size = humongous_obj->size();
>> 
>> Is this intentional? This looks like it would reintroduce https://github.com/openjdk/jdk/pull/26256 (crash trying to access size of humongous object after its class has been unloaded).
>
> good catch.  I'll change how this is implemented.

I've fixed this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27278#discussion_r2353245688

From wkemper at openjdk.org  Tue Sep 16 17:58:35 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 16 Sep 2025 17:58:35 GMT
Subject: RFR: 8367450: Shenandoah: Log the composition of the collection
 set [v3]
In-Reply-To: <F_eMy4j26l3Nk4DM8ObN1mGLjaFvzHs0IlBfMV0zeqc=.0063c575-fc07-4a6b-801d-ea6f7b97dff7@github.com>
References: <F_eMy4j26l3Nk4DM8ObN1mGLjaFvzHs0IlBfMV0zeqc=.0063c575-fc07-4a6b-801d-ea6f7b97dff7@github.com>
Message-ID: <6qlIiMobj48-AoxpC5sHdilE3QCo1KGJsF20-6Jgm7I=.2a977253-2393-452d-bd19-5c6eeacd1fa8@github.com>

> Reuse the same log message from GenShen which details the composition of the live data to be evacuated. In the non-generational modes, all regions are considered young and nothing will be promoted (or old).

William Kemper has updated the pull request incrementally with one additional commit since the last revision:

  Restore accidentally deleted constructor

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27235/files
  - new: https://git.openjdk.org/jdk/pull/27235/files/14d36331..7bde84b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27235&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27235&range=01-02

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27235/head:pull/27235

PR: https://git.openjdk.org/jdk/pull/27235

From kdnilsen at openjdk.org  Tue Sep 16 17:59:04 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 16 Sep 2025 17:59:04 GMT
Subject: RFR: 8367708: GenShen: Reduce total evacuation burden [v2]
In-Reply-To: <hhOVSR-SZ3FbsSHNDpaYYP281hvYFpgL5epw8dxebyQ=.c7d516fc-ae6d-4184-b80e-61d58db5202e@github.com>
References: <XgAjKd4zPFG5jDJ7OoyvefR9AiDN_Rj8nCMQlClXKQE=.23d80412-fddf-4e52-b25f-3be1e6d82c8e@github.com>
 <SflkpWm-5l_zIeZkqHl0RB3QSq9PNxcWSUn6yi3QvM0=.486198ca-46aa-47da-abd5-7ae9789ba210@github.com>
 <hhOVSR-SZ3FbsSHNDpaYYP281hvYFpgL5epw8dxebyQ=.c7d516fc-ae6d-4184-b80e-61d58db5202e@github.com>
Message-ID: <K7riBaR6JC-50Pm7QyURjHS-SGwhcTJEEgSZkpRHxKY=.ea1b94e4-f25d-4e29-8391-60c8bd7ec7f4@github.com>

On Mon, 15 Sep 2025 23:58:27 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to reviewer feedback
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1442:
> 
>> 1440:   assert(start->is_humongous_start(), "reclaim regions starting with the first one");
>> 1441: 
>> 1442:   // Cannot access humongous_obj->size() in case class has been unloaded
> 
> Why do we want to make two passes over the humongous object? I don't see why the original code needs to change or how this change is related to this PR?

There's a comment in the "new code" that we have to reclaim from the tail.  Otherwise assertion fails when printing region to trace log. 

I agree it is unclear how this relates to current PR.  I'll revert and see if something breaks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27278#discussion_r2353251364

From wkemper at openjdk.org  Tue Sep 16 18:16:27 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 16 Sep 2025 18:16:27 GMT
Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a
 runtime diagnostic option [v2]
In-Reply-To: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com>
References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com>
Message-ID: <Z8VoedeeZgcZyVfl9ffxJDnpgvDACpWMMqhWY9ZKW1M=.4425eac7-ad70-4518-bf87-73b39eb60e01@github.com>

> Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option.

William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge remote-tracking branch 'jdk/master' into make-evac-tracking-runtime-option
 - Only print evacuation info when evac tracking is enabled (generational mode fix)
 - Make detailed evacuation tracking a diagnostic option in product builds

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27238/files
  - new: https://git.openjdk.org/jdk/pull/27238/files/013480d2..bbee4ee3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27238&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27238&range=00-01

  Stats: 12926 lines in 600 files changed: 6899 ins; 2751 del; 3276 mod
  Patch: https://git.openjdk.org/jdk/pull/27238.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27238/head:pull/27238

PR: https://git.openjdk.org/jdk/pull/27238

From wkemper at openjdk.org  Tue Sep 16 19:03:02 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 16 Sep 2025 19:03:02 GMT
Subject: RFR: 8367476: Shenandoah: Remove use of
 CollectedHeap::_soft_ref_policy [v2]
In-Reply-To: <e1U8g7gn18EwcgKc8uYG8D4S3nSb6B2VCb7RdCTrHgU=.27d17b97-ab1c-4230-b8cf-20ec4441a108@github.com>
References: <tzAvTC0wDUpwFEy_076ofgsqpFAcVf5bjiM7SQLwO-w=.7a288588-bb12-435c-8a07-378069e8a851@github.com>
 <e1U8g7gn18EwcgKc8uYG8D4S3nSb6B2VCb7RdCTrHgU=.27d17b97-ab1c-4230-b8cf-20ec4441a108@github.com>
Message-ID: <y46rh9LHVv7ukNBptF-hreflauYXJ2gGGVpqLQ2IIYI=.77e801ba-7e3d-41e2-8ff7-28b1ff60ee7e@github.com>

On Fri, 12 Sep 2025 14:23:35 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> Similarly to what was done in #26496 and #26648, the usages of `CollectedHeap::_soft_ref_policy` in Shenandoah can be replaced with an earlier call to `ShenandoahReferenceProcessor::set_soft_reference_policy`.
>> 
>> This is the last usage of `CollectedHeap::_soft_ref_policy`, so it can be removed.
>> 
>> Passes tier1-2, and tier3_gc_shenandoah.
>
> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - eagerly initialize to always-clear
>  - move to gccause

Shenandoah parts look good to me.

-------------

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27239#pullrequestreview-3231296755

From fandreuzzi at openjdk.org  Tue Sep 16 19:17:58 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 16 Sep 2025 19:17:58 GMT
Subject: RFR: 8367476: Shenandoah: Remove use of
 CollectedHeap::_soft_ref_policy [v2]
In-Reply-To: <y7SlIhZC5KY_p5D8j4k6orgasSpk1nf5zByk54C7q_0=.1e8885c5-5e5a-43f9-9d81-f7b8454cef38@github.com>
References: <tzAvTC0wDUpwFEy_076ofgsqpFAcVf5bjiM7SQLwO-w=.7a288588-bb12-435c-8a07-378069e8a851@github.com>
 <e1U8g7gn18EwcgKc8uYG8D4S3nSb6B2VCb7RdCTrHgU=.27d17b97-ab1c-4230-b8cf-20ec4441a108@github.com>
 <y7SlIhZC5KY_p5D8j4k6orgasSpk1nf5zByk54C7q_0=.1e8885c5-5e5a-43f9-9d81-f7b8454cef38@github.com>
Message-ID: <ijQd1ig6b8p4ytFSYqe_JNYj9BFM7XbB2QHgQz3Mh_4=.d3e7d0bc-68ba-4fb6-ad1b-ca9028093371@github.com>

On Fri, 12 Sep 2025 15:18:20 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - eagerly initialize to always-clear
>>  - move to gccause
>
> I have reviewed all non-Shenandoah code.

Thanks for your review @albertnetymk and @earthling-amzn.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27239#issuecomment-3300021618

From duke at openjdk.org  Tue Sep 16 19:17:59 2025
From: duke at openjdk.org (duke)
Date: Tue, 16 Sep 2025 19:17:59 GMT
Subject: RFR: 8367476: Shenandoah: Remove use of
 CollectedHeap::_soft_ref_policy [v2]
In-Reply-To: <e1U8g7gn18EwcgKc8uYG8D4S3nSb6B2VCb7RdCTrHgU=.27d17b97-ab1c-4230-b8cf-20ec4441a108@github.com>
References: <tzAvTC0wDUpwFEy_076ofgsqpFAcVf5bjiM7SQLwO-w=.7a288588-bb12-435c-8a07-378069e8a851@github.com>
 <e1U8g7gn18EwcgKc8uYG8D4S3nSb6B2VCb7RdCTrHgU=.27d17b97-ab1c-4230-b8cf-20ec4441a108@github.com>
Message-ID: <UdqtoCSHoWEnoEBihqVNd6cLVgq79Ttb5bPeSXe1uM4=.f6681170-562e-42a2-beb4-fc6a7b19348b@github.com>

On Fri, 12 Sep 2025 14:23:35 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> Similarly to what was done in #26496 and #26648, the usages of `CollectedHeap::_soft_ref_policy` in Shenandoah can be replaced with an earlier call to `ShenandoahReferenceProcessor::set_soft_reference_policy`.
>> 
>> This is the last usage of `CollectedHeap::_soft_ref_policy`, so it can be removed.
>> 
>> Passes tier1-2, and tier3_gc_shenandoah.
>
> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - eagerly initialize to always-clear
>  - move to gccause

@fandreuz 
Your change (at version a55b8bd21ffa892b7f045bfe0961773855790661) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27239#issuecomment-3300024331

From wkemper at openjdk.org  Tue Sep 16 19:21:51 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 16 Sep 2025 19:21:51 GMT
Subject: RFR: 8367708: GenShen: Reduce total evacuation burden [v2]
In-Reply-To: <K7riBaR6JC-50Pm7QyURjHS-SGwhcTJEEgSZkpRHxKY=.ea1b94e4-f25d-4e29-8391-60c8bd7ec7f4@github.com>
References: <XgAjKd4zPFG5jDJ7OoyvefR9AiDN_Rj8nCMQlClXKQE=.23d80412-fddf-4e52-b25f-3be1e6d82c8e@github.com>
 <SflkpWm-5l_zIeZkqHl0RB3QSq9PNxcWSUn6yi3QvM0=.486198ca-46aa-47da-abd5-7ae9789ba210@github.com>
 <hhOVSR-SZ3FbsSHNDpaYYP281hvYFpgL5epw8dxebyQ=.c7d516fc-ae6d-4184-b80e-61d58db5202e@github.com>
 <K7riBaR6JC-50Pm7QyURjHS-SGwhcTJEEgSZkpRHxKY=.ea1b94e4-f25d-4e29-8391-60c8bd7ec7f4@github.com>
Message-ID: <nz8by3q5zQXIpN-4EtwWfgh7TKTV3gudxh8P2LeSkw8=.6d2f23e0-2ab9-4a00-b0fc-496e8c4bbd91@github.com>

On Tue, 16 Sep 2025 17:56:23 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1442:
>> 
>>> 1440:   assert(start->is_humongous_start(), "reclaim regions starting with the first one");
>>> 1441: 
>>> 1442:   // Cannot access humongous_obj->size() in case class has been unloaded
>> 
>> Why do we want to make two passes over the humongous object? I don't see why the original code needs to change or how this change is related to this PR?
>
> There's a comment in the "new code" that we have to reclaim from the tail.  Otherwise assertion fails when printing region to trace log. 
> 
> I agree it is unclear how this relates to current PR.  I'll revert and see if something breaks.

Thanks. We talked about this comment in the original PR: https://github.com/openjdk/jdk/pull/26256. It's a stale comment. I ran a pipeline with `gc*=trace` (and also inspected all usages).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27278#discussion_r2353429010

From kdnilsen at openjdk.org  Tue Sep 16 19:41:47 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 16 Sep 2025 19:41:47 GMT
Subject: RFR: 8367708: GenShen: Reduce total evacuation burden [v3]
In-Reply-To: <XgAjKd4zPFG5jDJ7OoyvefR9AiDN_Rj8nCMQlClXKQE=.23d80412-fddf-4e52-b25f-3be1e6d82c8e@github.com>
References: <XgAjKd4zPFG5jDJ7OoyvefR9AiDN_Rj8nCMQlClXKQE=.23d80412-fddf-4e52-b25f-3be1e6d82c8e@github.com>
Message-ID: <jXSlXas-EPze6BoNgx0zFpGY9fwc-S_GtaOSvBXvmpY=.478a79e8-8b27-4c11-95c3-e249ed6f0a2e@github.com>

> This PR provides several improvements that cumulatively reduce the amount of evacuation performed by GenShen compared to traditional Shenandoah. Specifically:
> 
> 1. Do not promote humongous arrays of primitive data.  Leaving these regions in the young generation allows them to be reclaimed more quickly when they become garbage.  There is no disadvantage to leaving these regions in the young generation as their contents does not need to be scanned by the garbage collector.
> 2. Change the default value of ShenandoahOldGarbageThreshold from 15% to 25%.  This results in smaller sets of candidate regions for mixed evacuation, less aggressive compaction of old generation.  This also increases the likelihood that a region will be promoted in place instead of promoted by evacuation.
> 3. Only promote regions in place if the used within a region exceeds ShenandoahGenerationalMinPIPUsage (default 30) percent of the heap region size.  This is enforced in combination with the preexisting requirement that the garbage within the region be less than ShenandoahOldGarbageThreshold (new default 25) percent of the heap region size.  This causes regions with very low utilization to be promoted by evacuation rather than promoted in place.  While the immediate effect of this change is to perform more copying when the region is promoted, the secondary effect is that this region does not need to be evacuated at a later time, after it has accumulated more live data, as part of an effort to defragment old-gen memory.
> 4. Only defragment old-gen memory if the command-line has requested non-zero reserves for humongous objects (ShenandoahGenerationalHumongousReserves).  Previously, we would invest in defragmenting old-gen memory every time we finished old-generation marking, even if ShenandoahGenerationalHumongousReserves equals zero.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  revert changes to trash_humongous_region_at()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27278/files
  - new: https://git.openjdk.org/jdk/pull/27278/files/69a76009..1ff51494

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27278&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27278&range=01-02

  Stats: 26 lines in 1 file changed: 5 ins; 14 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/27278.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27278/head:pull/27278

PR: https://git.openjdk.org/jdk/pull/27278

From kdnilsen at openjdk.org  Tue Sep 16 19:43:49 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 16 Sep 2025 19:43:49 GMT
Subject: RFR: 8367708: GenShen: Reduce total evacuation burden [v2]
In-Reply-To: <nz8by3q5zQXIpN-4EtwWfgh7TKTV3gudxh8P2LeSkw8=.6d2f23e0-2ab9-4a00-b0fc-496e8c4bbd91@github.com>
References: <XgAjKd4zPFG5jDJ7OoyvefR9AiDN_Rj8nCMQlClXKQE=.23d80412-fddf-4e52-b25f-3be1e6d82c8e@github.com>
 <SflkpWm-5l_zIeZkqHl0RB3QSq9PNxcWSUn6yi3QvM0=.486198ca-46aa-47da-abd5-7ae9789ba210@github.com>
 <hhOVSR-SZ3FbsSHNDpaYYP281hvYFpgL5epw8dxebyQ=.c7d516fc-ae6d-4184-b80e-61d58db5202e@github.com>
 <K7riBaR6JC-50Pm7QyURjHS-SGwhcTJEEgSZkpRHxKY=.ea1b94e4-f25d-4e29-8391-60c8bd7ec7f4@github.com>
 <nz8by3q5zQXIpN-4EtwWfgh7TKTV3gudxh8P2LeSkw8=.6d2f23e0-2ab9-4a00-b0fc-496e8c4bbd91@github.com>
Message-ID: <eMFH1yUmnSxYtfs7AMB4D6Bzep0lWZUik7C-_0UstTQ=.95536411-8cf6-432a-a091-8db43d103404@github.com>

On Tue, 16 Sep 2025 19:19:19 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> There's a comment in the "new code" that we have to reclaim from the tail.  Otherwise assertion fails when printing region to trace log. 
>> 
>> I agree it is unclear how this relates to current PR.  I'll revert and see if something breaks.
>
> Thanks. We talked about this comment in the original PR: https://github.com/openjdk/jdk/pull/26256. It's a stale comment. I ran a pipeline with `gc*=trace` (and also inspected all usages).

Running this change through test pipelines.  Perhaps the original problem that I had encountered was fixed in a different way upstream, and my change was no longer necessary or relevant after merging from upstream.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27278#discussion_r2353485278

From kdnilsen at openjdk.org  Tue Sep 16 20:10:42 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 16 Sep 2025 20:10:42 GMT
Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need
 accurate live_data [v8]
In-Reply-To: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
References: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
Message-ID: <Gbp9tNN6wxbIgA1UUBU46U0uHhw1nSUbZXVYZDg58Lw=.385b4829-0898-4c75-9ea6-65f576fc9475@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 41 commits:

 - Merge remote-tracking branch 'jdk/master' into fix-live-data-for-mixed-evac-candidates
 - Fix uninitialized variable
 - Remove deprecation conditional compiles
 - Adjust candidate live memory for each mixed evac
 - Refactor for better abstraction
 - Fix set_live() after full gc
 - Fix garbage_before_padded_for_promote()
 - Experiment 2: refinements to reduce regressions
 - Experiment with reviewer suggestion
   
   Redefine the way ShenandoahHeapRegion::get_live_data_<type> works to
   simplify changes.
 - Track live and garbage for mixed-evac regions
 - ... and 31 more: https://git.openjdk.org/jdk/compare/b75e35cb...d486a218

-------------

Changes: https://git.openjdk.org/jdk/pull/24319/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24319&range=07
  Stats: 111 lines in 11 files changed: 76 ins; 24 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/24319.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24319/head:pull/24319

PR: https://git.openjdk.org/jdk/pull/24319

From phh at openjdk.org  Tue Sep 16 20:17:59 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Tue, 16 Sep 2025 20:17:59 GMT
Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may
 raise threshold prematurely [v2]
In-Reply-To: <Yx5JP6k8BdZ5qig9rmN0YdqcT_Vhb5GetqrMefvXoeA=.07c40709-4331-484e-90ee-e1f1439cd1af@github.com>
References: <StL32ysKb0Tl01zLAA7kZiZZol3KoIKc8mM41rMlSMw=.9fc5f3b6-966d-48cd-b3f0-d38bdda5f6dd@github.com>
 <Yx5JP6k8BdZ5qig9rmN0YdqcT_Vhb5GetqrMefvXoeA=.07c40709-4331-484e-90ee-e1f1439cd1af@github.com>
Message-ID: <4XKpu0pCYty3MKwXXADbD_COqKAfwo35iJxR-rRrnQo=.6be68b5e-4fe5-4bb9-a67f-c23c90ad63e1@github.com>

On Tue, 16 Sep 2025 17:40:17 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Not clean. Conflicts were because of format specifiers for the most part.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Need to include precompiled header for windows on this branch

Marked as reviewed by phh (no project role).

-------------

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/221#pullrequestreview-3231554261

From wkemper at openjdk.org  Tue Sep 16 20:56:09 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 16 Sep 2025 20:56:09 GMT
Subject: RFR: 8367450: Shenandoah: Log the composition of the collection
 set [v4]
In-Reply-To: <F_eMy4j26l3Nk4DM8ObN1mGLjaFvzHs0IlBfMV0zeqc=.0063c575-fc07-4a6b-801d-ea6f7b97dff7@github.com>
References: <F_eMy4j26l3Nk4DM8ObN1mGLjaFvzHs0IlBfMV0zeqc=.0063c575-fc07-4a6b-801d-ea6f7b97dff7@github.com>
Message-ID: <N_mMV4j8ONtp9yiRYa3DQFgDJIPfnOalN2XLDA9PJzI=.091b5b81-e842-43bf-9ead-c7cd6e571cb2@github.com>

> Reuse the same log message from GenShen which details the composition of the live data to be evacuated. In the non-generational modes, all regions are considered young and nothing will be promoted (or old).

William Kemper has updated the pull request incrementally with one additional commit since the last revision:

  Fix zero build

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27235/files
  - new: https://git.openjdk.org/jdk/pull/27235/files/7bde84b8..3b6f970e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27235&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27235&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27235/head:pull/27235

PR: https://git.openjdk.org/jdk/pull/27235

From kdnilsen at openjdk.org  Tue Sep 16 21:29:34 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 16 Sep 2025 21:29:34 GMT
Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need
 accurate live_data [v9]
In-Reply-To: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
References: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
Message-ID: <8GvpkoZ5-Pso8XG-AKeR0QnlBQr0op9E-lvQMS12lTI=.6c88343d-4c74-4f29-a528-f499f559a2bd@github.com>

> The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected.  In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region.  This is typically ok for young regions, where the amount of live data determines whether a region should be added to the collection set during the final-mark safepoint.
> 
> However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated.  In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended.
> 
> This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  Fix compilation errors after merge

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24319/files
  - new: https://git.openjdk.org/jdk/pull/24319/files/d486a218..cc6f1153

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24319&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24319&range=07-08

  Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24319.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24319/head:pull/24319

PR: https://git.openjdk.org/jdk/pull/24319

From kdnilsen at openjdk.org  Tue Sep 16 23:43:54 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 16 Sep 2025 23:43:54 GMT
Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may
 raise threshold prematurely [v2]
In-Reply-To: <Yx5JP6k8BdZ5qig9rmN0YdqcT_Vhb5GetqrMefvXoeA=.07c40709-4331-484e-90ee-e1f1439cd1af@github.com>
References: <StL32ysKb0Tl01zLAA7kZiZZol3KoIKc8mM41rMlSMw=.9fc5f3b6-966d-48cd-b3f0-d38bdda5f6dd@github.com>
 <Yx5JP6k8BdZ5qig9rmN0YdqcT_Vhb5GetqrMefvXoeA=.07c40709-4331-484e-90ee-e1f1439cd1af@github.com>
Message-ID: <dVNubiakURwOHYnhiarIOwCSTvVbftIQ43A-pldeizg=.ceff0dc2-8b5c-418e-a57d-14fffce0881e@github.com>

On Tue, 16 Sep 2025 17:40:17 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Not clean. Conflicts were because of format specifiers for the most part.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Need to include precompiled header for windows on this branch

Thanks

-------------

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/221#pullrequestreview-3232008586

From wkemper at openjdk.org  Wed Sep 17 00:01:52 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 17 Sep 2025 00:01:52 GMT
Subject: Integrated: 8365956: GenShen: Adaptive tenuring threshold algorithm
 may raise threshold prematurely
In-Reply-To: <StL32ysKb0Tl01zLAA7kZiZZol3KoIKc8mM41rMlSMw=.9fc5f3b6-966d-48cd-b3f0-d38bdda5f6dd@github.com>
References: <StL32ysKb0Tl01zLAA7kZiZZol3KoIKc8mM41rMlSMw=.9fc5f3b6-966d-48cd-b3f0-d38bdda5f6dd@github.com>
Message-ID: <QkIeBY8IN2Fy4SnQDDPJNUGIpnlc-I5W_UPCxSVRZmk=.f74277b0-bcd1-4d92-a422-9713e222e666@github.com>

On Fri, 12 Sep 2025 23:26:23 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Not clean. Conflicts were because of format specifiers for the most part.

This pull request has now been integrated.

Changeset: d6e3334e
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/d6e3334ebe98c901ea54ea7b6dd96782086d7e1b
Stats:     349 lines in 15 files changed: 256 ins; 30 del; 63 mod

8365956: GenShen: Adaptive tenuring threshold algorithm may raise threshold prematurely

Reviewed-by: phh, kdnilsen
Backport-of: 7fcce27096605a27ca3b74349d1012bb0bd5963d

-------------

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/221

From wkemper at openjdk.org  Wed Sep 17 00:20:58 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 17 Sep 2025 00:20:58 GMT
Subject: RFR: 8367450: Shenandoah: Log the composition of the collection
 set [v5]
In-Reply-To: <F_eMy4j26l3Nk4DM8ObN1mGLjaFvzHs0IlBfMV0zeqc=.0063c575-fc07-4a6b-801d-ea6f7b97dff7@github.com>
References: <F_eMy4j26l3Nk4DM8ObN1mGLjaFvzHs0IlBfMV0zeqc=.0063c575-fc07-4a6b-801d-ea6f7b97dff7@github.com>
Message-ID: <2KA4IRFQOPFBpt9D570g9HORzBXycZhs7cDPLYjnGmE=.6f331678-cb61-4e05-8c7d-06fcea7fa64e@github.com>

> Reuse the same log message from GenShen which details the composition of the live data to be evacuated. In the non-generational modes, all regions are considered young and nothing will be promoted (or old).

William Kemper has updated the pull request incrementally with one additional commit since the last revision:

  Remove redundant collection set logging

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27235/files
  - new: https://git.openjdk.org/jdk/pull/27235/files/3b6f970e..aeb6b39e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27235&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27235&range=03-04

  Stats: 19 lines in 4 files changed: 1 ins; 18 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27235/head:pull/27235

PR: https://git.openjdk.org/jdk/pull/27235

From fandreuzzi at openjdk.org  Wed Sep 17 08:30:12 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 17 Sep 2025 08:30:12 GMT
Subject: Integrated: 8367476: Shenandoah: Remove use of
 CollectedHeap::_soft_ref_policy
In-Reply-To: <tzAvTC0wDUpwFEy_076ofgsqpFAcVf5bjiM7SQLwO-w=.7a288588-bb12-435c-8a07-378069e8a851@github.com>
References: <tzAvTC0wDUpwFEy_076ofgsqpFAcVf5bjiM7SQLwO-w=.7a288588-bb12-435c-8a07-378069e8a851@github.com>
Message-ID: <Z0gfY83laQZ7POfntAbZGkXS1THegZag7gcfLUn4ZDA=.b02ef83a-397f-48be-b6e0-3a64dee36812@github.com>

On Fri, 12 Sep 2025 00:19:05 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Similarly to what was done in #26496 and #26648, the usages of `CollectedHeap::_soft_ref_policy` in Shenandoah can be replaced with an earlier call to `ShenandoahReferenceProcessor::set_soft_reference_policy`.
> 
> This is the last usage of `CollectedHeap::_soft_ref_policy`, so it can be removed.
> 
> Passes tier1-2, and tier3_gc_shenandoah.

This pull request has now been integrated.

Changeset: 976207df
Author:    Francesco Andreuzzi <fandreuzzi at openjdk.org>
Committer: Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/976207df1fcebf76a5f732b26424d6a4896b359e
Stats:     101 lines in 20 files changed: 16 ins; 75 del; 10 mod

8367476: Shenandoah: Remove use of CollectedHeap::_soft_ref_policy

Reviewed-by: ayang, wkemper

-------------

PR: https://git.openjdk.org/jdk/pull/27239

From wkemper at openjdk.org  Wed Sep 17 19:10:44 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 17 Sep 2025 19:10:44 GMT
Subject: RFR: 8367708: GenShen: Reduce total evacuation burden [v3]
In-Reply-To: <jXSlXas-EPze6BoNgx0zFpGY9fwc-S_GtaOSvBXvmpY=.478a79e8-8b27-4c11-95c3-e249ed6f0a2e@github.com>
References: <XgAjKd4zPFG5jDJ7OoyvefR9AiDN_Rj8nCMQlClXKQE=.23d80412-fddf-4e52-b25f-3be1e6d82c8e@github.com>
 <jXSlXas-EPze6BoNgx0zFpGY9fwc-S_GtaOSvBXvmpY=.478a79e8-8b27-4c11-95c3-e249ed6f0a2e@github.com>
Message-ID: <ZHPtVN-sV11cehWQV0_XBcNdKmXzWbuCUP3bhrCMPH0=.e88ea712-0c10-4a1e-9fa4-b9690464d252@github.com>

On Tue, 16 Sep 2025 19:41:47 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This PR provides several improvements that cumulatively reduce the amount of evacuation performed by GenShen compared to traditional Shenandoah. Specifically:
>> 
>> 1. Do not promote humongous arrays of primitive data.  Leaving these regions in the young generation allows them to be reclaimed more quickly when they become garbage.  There is no disadvantage to leaving these regions in the young generation as their contents does not need to be scanned by the garbage collector.
>> 2. Change the default value of ShenandoahOldGarbageThreshold from 15% to 25%.  This results in smaller sets of candidate regions for mixed evacuation, less aggressive compaction of old generation.  This also increases the likelihood that a region will be promoted in place instead of promoted by evacuation.
>> 3. Only promote regions in place if the used within a region exceeds ShenandoahGenerationalMinPIPUsage (default 30) percent of the heap region size.  This is enforced in combination with the preexisting requirement that the garbage within the region be less than ShenandoahOldGarbageThreshold (new default 25) percent of the heap region size.  This causes regions with very low utilization to be promoted by evacuation rather than promoted in place.  While the immediate effect of this change is to perform more copying when the region is promoted, the secondary effect is that this region does not need to be evacuated at a later time, after it has accumulated more live data, as part of an effort to defragment old-gen memory.
>> 4. Only defragment old-gen memory if the command-line has requested non-zero reserves for humongous objects (ShenandoahGenerationalHumongousReserves).  Previously, we would invest in defragmenting old-gen memory every time we finished old-generation marking, even if ShenandoahGenerationalHumongousReserves equals zero.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes to trash_humongous_region_at()

LGTM!

-------------

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27278#pullrequestreview-3235879253

From phh at openjdk.org  Wed Sep 17 23:57:36 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 17 Sep 2025 23:57:36 GMT
Subject: RFR: 8367450: Shenandoah: Log the composition of the collection
 set [v5]
In-Reply-To: <2KA4IRFQOPFBpt9D570g9HORzBXycZhs7cDPLYjnGmE=.6f331678-cb61-4e05-8c7d-06fcea7fa64e@github.com>
References: <F_eMy4j26l3Nk4DM8ObN1mGLjaFvzHs0IlBfMV0zeqc=.0063c575-fc07-4a6b-801d-ea6f7b97dff7@github.com>
 <2KA4IRFQOPFBpt9D570g9HORzBXycZhs7cDPLYjnGmE=.6f331678-cb61-4e05-8c7d-06fcea7fa64e@github.com>
Message-ID: <6CrX79gi4l5yFXhCPJVvftrgC7-ykYnY3siTgHcqyPY=.f5dcd425-7bfe-4dc8-b7af-c733987e67e2@github.com>

On Wed, 17 Sep 2025 00:20:58 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Reuse the same log message from GenShen which details the composition of the live data to be evacuated. In the non-generational modes, all regions are considered young and nothing will be promoted (or old).
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant collection set logging

Marked as reviewed by phh (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27235#pullrequestreview-3236614392

From phh at openjdk.org  Wed Sep 17 23:58:40 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 17 Sep 2025 23:58:40 GMT
Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a
 runtime diagnostic option [v2]
In-Reply-To: <Z8VoedeeZgcZyVfl9ffxJDnpgvDACpWMMqhWY9ZKW1M=.4425eac7-ad70-4518-bf87-73b39eb60e01@github.com>
References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com>
 <Z8VoedeeZgcZyVfl9ffxJDnpgvDACpWMMqhWY9ZKW1M=.4425eac7-ad70-4518-bf87-73b39eb60e01@github.com>
Message-ID: <RQhZ4e0ioqC-GSTFttCBvQN6WlKHCB5XNuwu6D9wuYg=.1fe32ed7-3502-49e9-8ce1-ac40c58f0d2f@github.com>

On Tue, 16 Sep 2025 18:16:27 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option.
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'jdk/master' into make-evac-tracking-runtime-option
>  - Only print evacuation info when evac tracking is enabled (generational mode fix)
>  - Make detailed evacuation tracking a diagnostic option in product builds

Marked as reviewed by phh (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27238#pullrequestreview-3236618160

From ysr at openjdk.org  Thu Sep 18 00:52:35 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 18 Sep 2025 00:52:35 GMT
Subject: RFR: 8367450: Shenandoah: Log the composition of the collection
 set [v5]
In-Reply-To: <2KA4IRFQOPFBpt9D570g9HORzBXycZhs7cDPLYjnGmE=.6f331678-cb61-4e05-8c7d-06fcea7fa64e@github.com>
References: <F_eMy4j26l3Nk4DM8ObN1mGLjaFvzHs0IlBfMV0zeqc=.0063c575-fc07-4a6b-801d-ea6f7b97dff7@github.com>
 <2KA4IRFQOPFBpt9D570g9HORzBXycZhs7cDPLYjnGmE=.6f331678-cb61-4e05-8c7d-06fcea7fa64e@github.com>
Message-ID: <duoVaOPquV0ilEE_rmcccStK9PqNU_VNe5fBxc8sZZE=.fe7d9333-e249-4c36-8c00-47d1a5a70d36@github.com>

On Wed, 17 Sep 2025 00:20:58 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Reuse the same log message from GenShen which details the composition of the live data to be evacuated. In the non-generational modes, all regions are considered young and nothing will be promoted (or old).
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant collection set logging

Changes look good, other than suggested documentation of a few APIs (see specific comment in review).

src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp line 1:

> 1: /*

Either for the accessors (preferred because they are the public APIs for the class) or for the private data members in which those values are tracked, it would be nice to have a one-line sentence describing what the value is and when the value is valid.

I realize this might seem obvious when working in this code, but the documentation is helpful for those not deeply familiar with these fields or trying to use these many months later.

-------------

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27235#pullrequestreview-3236816177
PR Review Comment: https://git.openjdk.org/jdk/pull/27235#discussion_r2357188582

From ysr at openjdk.org  Thu Sep 18 01:59:44 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 18 Sep 2025 01:59:44 GMT
Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a
 runtime diagnostic option [v2]
In-Reply-To: <Z8VoedeeZgcZyVfl9ffxJDnpgvDACpWMMqhWY9ZKW1M=.4425eac7-ad70-4518-bf87-73b39eb60e01@github.com>
References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com>
 <Z8VoedeeZgcZyVfl9ffxJDnpgvDACpWMMqhWY9ZKW1M=.4425eac7-ad70-4518-bf87-73b39eb60e01@github.com>
Message-ID: <-S5kGwanp5G--dEw5uQBPRFlnSO9l6yyyXGOdQKAwd8=.f891358d-5e2d-4677-bf00-e97a146e1b05@github.com>

On Tue, 16 Sep 2025 18:16:27 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option.
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'jdk/master' into make-evac-tracking-runtime-option
>  - Only print evacuation info when evac tracking is enabled (generational mode fix)
>  - Make detailed evacuation tracking a diagnostic option in product builds

Changes look good to me. I am guessing you checked that the original issue is gone; would be a good idea to check that the output looks like it's expected and may be include a sample output with the flag enabled.

src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 399:

> 397:   product(bool, ShenandoahEvacTracking, false, DIAGNOSTIC,                  \
> 398:           "Collect additional metrics about evacuations. Enabling this "    \
> 399:           "track how many objects and how many bytes were evacuated, and "  \

Nit: track -> tracks?
Or may be simply say: "Track additional, more detailed metrics related to evacuations by mutators and GC workers." and elide the first sentence" "Collect additional ..."?

-------------

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27238#pullrequestreview-3236841054
PR Review Comment: https://git.openjdk.org/jdk/pull/27238#discussion_r2357208495

From ysr at openjdk.org  Thu Sep 18 01:59:45 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 18 Sep 2025 01:59:45 GMT
Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a
 runtime diagnostic option
In-Reply-To: <dZTv61cCrDzRK6T2m4pFppVTuv4uWCOIAhAoL33D1jQ=.6c3643a6-684e-4bca-b6fb-633378e02216@github.com>
References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com>
 <dZTv61cCrDzRK6T2m4pFppVTuv4uWCOIAhAoL33D1jQ=.6c3643a6-684e-4bca-b6fb-633378e02216@github.com>
Message-ID: <yRTXeiQZ6WkEAPzsiFT2TlnxwqD81n1PU5YJ6lICLTc=.55c7cb2b-6f0a-4cb9-af73-10691cc5b15f@github.com>

On Fri, 12 Sep 2025 21:29:39 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This chart shows the distribution (as a box plot) of all concurrent evacuation times across all benchmarks and platforms for the past 24 hours (approximately 15K data points in total). Each facet of the chart shows 3 configurations:
> 
> * top: The diagnostic option in this PR is enabled
> * middle: The diagnostic option is disabled
> * bottom: The baseline - this behavior does not exist in the product build.
> 
> The first facet shows the effect of this option on _global_ GCs in Genshen. The second facet shows the effect of this option on _global_ GCs in Shenandoah. The last option shows the effect on _young_ evacuation in GenShen. 

If I am reading the data right, it seems to me that the impact is most noticeable (percentage-wise) in Shenandoah. (The effect on GenShen seems minimal.) Is it understood why there should be a bigger impact on Shenandoah, or is the data telling us something else about why it looks the way it does?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27238#issuecomment-3305110048

From wkemper at openjdk.org  Thu Sep 18 16:08:34 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 18 Sep 2025 16:08:34 GMT
Subject: RFR: 8367450: Shenandoah: Log the composition of the collection
 set [v6]
In-Reply-To: <F_eMy4j26l3Nk4DM8ObN1mGLjaFvzHs0IlBfMV0zeqc=.0063c575-fc07-4a6b-801d-ea6f7b97dff7@github.com>
References: <F_eMy4j26l3Nk4DM8ObN1mGLjaFvzHs0IlBfMV0zeqc=.0063c575-fc07-4a6b-801d-ea6f7b97dff7@github.com>
Message-ID: <oRCsTIZ4pbxWHeLGAUWqm46vrGcjGnU6AhjMEMkUgTs=.c0da55fd-7f39-4605-ac8d-ca12e0c15806@github.com>

> Reuse the same log message from GenShen which details the composition of the live data to be evacuated. In the non-generational modes, all regions are considered young and nothing will be promoted (or old).

William Kemper has updated the pull request incrementally with one additional commit since the last revision:

  Improve documentation for methods touched in this change

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27235/files
  - new: https://git.openjdk.org/jdk/pull/27235/files/aeb6b39e..e0854ecb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27235&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27235&range=04-05

  Stats: 11 lines in 2 files changed: 9 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27235/head:pull/27235

PR: https://git.openjdk.org/jdk/pull/27235

From kdnilsen at openjdk.org  Thu Sep 18 16:10:18 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 18 Sep 2025 16:10:18 GMT
Subject: Integrated: 8367708: GenShen: Reduce total evacuation burden
In-Reply-To: <XgAjKd4zPFG5jDJ7OoyvefR9AiDN_Rj8nCMQlClXKQE=.23d80412-fddf-4e52-b25f-3be1e6d82c8e@github.com>
References: <XgAjKd4zPFG5jDJ7OoyvefR9AiDN_Rj8nCMQlClXKQE=.23d80412-fddf-4e52-b25f-3be1e6d82c8e@github.com>
Message-ID: <191jY5pbuFDtyevG-1yhD8ZUQhBxuHMoHiv74IRFwxg=.de5794ab-6c66-454c-a651-d3f83fd1dc1e@github.com>

On Mon, 15 Sep 2025 04:44:24 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This PR provides several improvements that cumulatively reduce the amount of evacuation performed by GenShen compared to traditional Shenandoah. Specifically:
> 
> 1. Do not promote humongous arrays of primitive data.  Leaving these regions in the young generation allows them to be reclaimed more quickly when they become garbage.  There is no disadvantage to leaving these regions in the young generation as their contents does not need to be scanned by the garbage collector.
> 2. Change the default value of ShenandoahOldGarbageThreshold from 15% to 25%.  This results in smaller sets of candidate regions for mixed evacuation, less aggressive compaction of old generation.  This also increases the likelihood that a region will be promoted in place instead of promoted by evacuation.
> 3. Only promote regions in place if the used within a region exceeds ShenandoahGenerationalMinPIPUsage (default 30) percent of the heap region size.  This is enforced in combination with the preexisting requirement that the garbage within the region be less than ShenandoahOldGarbageThreshold (new default 25) percent of the heap region size.  This causes regions with very low utilization to be promoted by evacuation rather than promoted in place.  While the immediate effect of this change is to perform more copying when the region is promoted, the secondary effect is that this region does not need to be evacuated at a later time, after it has accumulated more live data, as part of an effort to defragment old-gen memory.
> 4. Only defragment old-gen memory if the command-line has requested non-zero reserves for humongous objects (ShenandoahGenerationalHumongousReserves).  Previously, we would invest in defragmenting old-gen memory every time we finished old-generation marking, even if ShenandoahGenerationalHumongousReserves equals zero.

This pull request has now been integrated.

Changeset: c597384a
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c597384ad64c7107fba4e970aa435a141276b2fd
Stats:     30 lines in 4 files changed: 22 ins; 2 del; 6 mod

8367708: GenShen: Reduce total evacuation burden

Reviewed-by: wkemper

-------------

PR: https://git.openjdk.org/jdk/pull/27278

From wkemper at openjdk.org  Thu Sep 18 16:13:25 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 18 Sep 2025 16:13:25 GMT
Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a
 runtime diagnostic option [v3]
In-Reply-To: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com>
References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com>
Message-ID: <IHNxxTpE1XJXAvftobRDU0dp5vRG0VrStacyoKs4fqA=.2323e3f9-93b0-4937-a5f5-d63b4667cb7e@github.com>

> Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option.

William Kemper has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo in option description

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27238/files
  - new: https://git.openjdk.org/jdk/pull/27238/files/bbee4ee3..a890cd30

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27238&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27238&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27238.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27238/head:pull/27238

PR: https://git.openjdk.org/jdk/pull/27238

From phh at openjdk.org  Thu Sep 18 17:01:50 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Thu, 18 Sep 2025 17:01:50 GMT
Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a
 runtime diagnostic option [v3]
In-Reply-To: <IHNxxTpE1XJXAvftobRDU0dp5vRG0VrStacyoKs4fqA=.2323e3f9-93b0-4937-a5f5-d63b4667cb7e@github.com>
References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com>
 <IHNxxTpE1XJXAvftobRDU0dp5vRG0VrStacyoKs4fqA=.2323e3f9-93b0-4937-a5f5-d63b4667cb7e@github.com>
Message-ID: <HoYyCOe09T3azWdrqszY7zrR5LTzG32GLY9SzgyiSBQ=.af913aaf-c9ed-4608-be3e-91a0818dfa80@github.com>

On Thu, 18 Sep 2025 16:13:25 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in option description

Marked as reviewed by phh (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27238#pullrequestreview-3240997697

From wkemper at openjdk.org  Thu Sep 18 17:20:01 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 18 Sep 2025 17:20:01 GMT
Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a
 runtime diagnostic option [v4]
In-Reply-To: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com>
References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com>
Message-ID: <d8R-NDgV5bUqCoMF5a4fhR3_U93PRfqYj2s-N3gDMm4=.8ba990f8-efa3-406c-9f9e-87c4feb38daf@github.com>

> Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option.

William Kemper has updated the pull request incrementally with one additional commit since the last revision:

  Only print region age tables in generational mode

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27238/files
  - new: https://git.openjdk.org/jdk/pull/27238/files/a890cd30..0e1446de

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27238&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27238&range=02-03

  Stats: 13 lines in 1 file changed: 4 ins; 3 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/27238.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27238/head:pull/27238

PR: https://git.openjdk.org/jdk/pull/27238

From wkemper at openjdk.org  Thu Sep 18 17:31:19 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 18 Sep 2025 17:31:19 GMT
Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a
 runtime diagnostic option [v5]
In-Reply-To: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com>
References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com>
Message-ID: <FP1fZnZtr4y9iQr53Q6Kd2b44shx0FtUNKiLAAo02DY=.3e97e61d-d004-491b-898e-c58dd7bcacf7@github.com>

> Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option.

William Kemper has updated the pull request incrementally with one additional commit since the last revision:

  Only print promotion/old evacuation metrics in generational mode

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27238/files
  - new: https://git.openjdk.org/jdk/pull/27238/files/0e1446de..0ab56c91

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27238&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27238&range=03-04

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27238.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27238/head:pull/27238

PR: https://git.openjdk.org/jdk/pull/27238

From wkemper at openjdk.org  Thu Sep 18 17:36:31 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 18 Sep 2025 17:36:31 GMT
Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a
 runtime diagnostic option [v5]
In-Reply-To: <FP1fZnZtr4y9iQr53Q6Kd2b44shx0FtUNKiLAAo02DY=.3e97e61d-d004-491b-898e-c58dd7bcacf7@github.com>
References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com>
 <FP1fZnZtr4y9iQr53Q6Kd2b44shx0FtUNKiLAAo02DY=.3e97e61d-d004-491b-898e-c58dd7bcacf7@github.com>
Message-ID: <pOgRgHOcBkUuXYs3BvhKiemozJVRtNwgosi5Jn8YEsY=.943856ae-c8c2-4f92-9cd0-643dad9b339e@github.com>

On Thu, 18 Sep 2025 17:31:19 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Only print promotion/old evacuation metrics in generational mode

When the diagnostic option is disabled there is no additional output in the logs. When the option is enabled, we'll see a break down of which type of evacuations were performed by which threads:

[2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats       ] Workers: 
[2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats       ] Young: Evacuated 8469K across 122601 objects, abandoned 1840B across 23 objects.
[2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats       ] Promotion: Evacuated 0B across 0 objects, abandoned 0B across 0 objects.
[2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats       ] Old: Evacuated 0B across 0 objects, abandoned 0B across 0 objects.
[2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats       ] 
[2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats       ] Mutators: 
[2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats       ] Young: Evacuated 845K across 10247 objects, abandoned 803K across 7852 objects.
[2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats       ] Promotion: Evacuated 0B across 0 objects, abandoned 0B across 0 objects.
[2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats       ] Old: Evacuated 0B across 0 objects, abandoned 0B across 0 objects.


When the option is enabled in single-gen mode, we will see only evacuation data for young regions (there are no promotions or old evacuations in this mode):


[2025-09-18T17:30:04.246+0000][3.663s][20861][info][gc,stats       ] Workers: 
[2025-09-18T17:30:04.246+0000][3.663s][20861][info][gc,stats       ] Young: Evacuated 5555K across 122874 objects, abandoned 0B across 0 objects.
[2025-09-18T17:30:04.246+0000][3.663s][20861][info][gc,stats       ] 
[2025-09-18T17:30:04.246+0000][3.663s][20861][info][gc,stats       ] Mutators: 
[2025-09-18T17:30:04.246+0000][3.663s][20861][info][gc,stats       ] Young: Evacuated 408K across 320 objects, abandoned 0B across 0 objects.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27238#issuecomment-3308722358

From wkemper at openjdk.org  Thu Sep 18 17:36:35 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 18 Sep 2025 17:36:35 GMT
Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a
 runtime diagnostic option [v2]
In-Reply-To: <-S5kGwanp5G--dEw5uQBPRFlnSO9l6yyyXGOdQKAwd8=.f891358d-5e2d-4677-bf00-e97a146e1b05@github.com>
References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com>
 <Z8VoedeeZgcZyVfl9ffxJDnpgvDACpWMMqhWY9ZKW1M=.4425eac7-ad70-4518-bf87-73b39eb60e01@github.com>
 <-S5kGwanp5G--dEw5uQBPRFlnSO9l6yyyXGOdQKAwd8=.f891358d-5e2d-4677-bf00-e97a146e1b05@github.com>
Message-ID: <R6lsezGKzdRTBVUFXmAujTyhsl4FAONLIpFgL08GyTo=.a9f1dcfe-4ab1-4dba-8700-62601c9887b4@github.com>

On Thu, 18 Sep 2025 00:57:39 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'jdk/master' into make-evac-tracking-runtime-option
>>  - Only print evacuation info when evac tracking is enabled (generational mode fix)
>>  - Make detailed evacuation tracking a diagnostic option in product builds
>
> src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 399:
> 
>> 397:   product(bool, ShenandoahEvacTracking, false, DIAGNOSTIC,                  \
>> 398:           "Collect additional metrics about evacuations. Enabling this "    \
>> 399:           "track how many objects and how many bytes were evacuated, and "  \
> 
> Nit: track -> tracks?
> Or may be simply say: "Track additional, more detailed metrics related to evacuations by mutators and GC workers." and elide the first sentence" "Collect additional ..."?

I just fixed the typo. The following sentence explains in some detail what will be tracked and how it will be reported.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27238#discussion_r2360453664

From ysr at openjdk.org  Thu Sep 18 18:28:57 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 18 Sep 2025 18:28:57 GMT
Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a
 runtime diagnostic option [v5]
In-Reply-To: <FP1fZnZtr4y9iQr53Q6Kd2b44shx0FtUNKiLAAo02DY=.3e97e61d-d004-491b-898e-c58dd7bcacf7@github.com>
References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com>
 <FP1fZnZtr4y9iQr53Q6Kd2b44shx0FtUNKiLAAo02DY=.3e97e61d-d004-491b-898e-c58dd7bcacf7@github.com>
Message-ID: <hJ3RZ7QtIVgZ1b6H78cTUizp2MD6_gPruX1_wJIILIg=.96443e4e-a401-420f-96bf-9866e4f525ef@github.com>

On Thu, 18 Sep 2025 17:31:19 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Only print promotion/old evacuation metrics in generational mode

Marked as reviewed by ysr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27238#pullrequestreview-3241395957

From ysr at openjdk.org  Thu Sep 18 18:28:58 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 18 Sep 2025 18:28:58 GMT
Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a
 runtime diagnostic option [v5]
In-Reply-To: <pOgRgHOcBkUuXYs3BvhKiemozJVRtNwgosi5Jn8YEsY=.943856ae-c8c2-4f92-9cd0-643dad9b339e@github.com>
References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com>
 <FP1fZnZtr4y9iQr53Q6Kd2b44shx0FtUNKiLAAo02DY=.3e97e61d-d004-491b-898e-c58dd7bcacf7@github.com>
 <pOgRgHOcBkUuXYs3BvhKiemozJVRtNwgosi5Jn8YEsY=.943856ae-c8c2-4f92-9cd0-643dad9b339e@github.com>
Message-ID: <eCOdhTjBTPjSlvNaXVY31B4PwwUqVccTtUDikQc2pd4=.71b96649-0572-4f9c-a68b-55051d2c75f2@github.com>

On Thu, 18 Sep 2025 17:33:10 GMT, William Kemper <wkemper at openjdk.org> wrote:

> When the diagnostic option is disabled there is no additional output in the logs. When the option is enabled, we'll see a break down of which type of evacuations were performed by which threads:
> 
> ```
> [2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats       ] Workers: 
> [2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats       ] Young: Evacuated 8469K across 122601 objects, abandoned 1840B across 23 objects.
> [2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats       ] Promotion: Evacuated 0B across 0 objects, abandoned 0B across 0 objects.
> [2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats       ] Old: Evacuated 0B across 0 objects, abandoned 0B across 0 objects.
> [2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats       ] 
> [2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats       ] Mutators: 
> [2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats       ] Young: Evacuated 845K across 10247 objects, abandoned 803K across 7852 objects.
> [2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats       ] Promotion: Evacuated 0B across 0 objects, abandoned 0B across 0 objects.
> [2025-09-18T17:02:08.963+0000][31.169s][24648][info ][gc,stats       ] Old: Evacuated 0B across 0 objects, abandoned 0B across 0 objects.
> ```
> 
> When the option is enabled in single-gen mode, we will see only evacuation data for young regions (there are no promotions or old evacuations in this mode):
> 
> ```
> [2025-09-18T17:30:04.246+0000][3.663s][20861][info][gc,stats       ] Workers: 
> [2025-09-18T17:30:04.246+0000][3.663s][20861][info][gc,stats       ] Young: Evacuated 5555K across 122874 objects, abandoned 0B across 0 objects.
> [2025-09-18T17:30:04.246+0000][3.663s][20861][info][gc,stats       ] 
> [2025-09-18T17:30:04.246+0000][3.663s][20861][info][gc,stats       ] Mutators: 
> [2025-09-18T17:30:04.246+0000][3.663s][20861][info][gc,stats       ] Young: Evacuated 408K across 320 objects, abandoned 0B across 0 objects.
> ```

I don't suppose it's advisable to suppress data that's vacuous (pun not intended :), i.e. where no promotions occur in generational mode?

Reviewed and approved. ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27238#issuecomment-3308984129

From ysr at openjdk.org  Thu Sep 18 18:28:59 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 18 Sep 2025 18:28:59 GMT
Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a
 runtime diagnostic option [v5]
In-Reply-To: <eCOdhTjBTPjSlvNaXVY31B4PwwUqVccTtUDikQc2pd4=.71b96649-0572-4f9c-a68b-55051d2c75f2@github.com>
References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com>
 <FP1fZnZtr4y9iQr53Q6Kd2b44shx0FtUNKiLAAo02DY=.3e97e61d-d004-491b-898e-c58dd7bcacf7@github.com>
 <pOgRgHOcBkUuXYs3BvhKiemozJVRtNwgosi5Jn8YEsY=.943856ae-c8c2-4f92-9cd0-643dad9b339e@github.com>
 <eCOdhTjBTPjSlvNaXVY31B4PwwUqVccTtUDikQc2pd4=.71b96649-0572-4f9c-a68b-55051d2c75f2@github.com>
Message-ID: <gf0nnMpwy7iOTUTL8Y3Eggi5cwAdzJKy-y_lZ4zReKQ=.c9bb7e32-9e63-45b5-9628-329488a514e1@github.com>

On Thu, 18 Sep 2025 18:22:53 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> I don't suppose it's advisable to suppress data that's vacuous (pun not intended :), i.e. where no promotions occur in generational mode?

I don't think we should suppress that data. Having it explicitly spelled out at each cycle regardless is less confusing and better for human (and machine) consumption.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27238#issuecomment-3308998116

From ysr at openjdk.org  Thu Sep 18 18:40:23 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 18 Sep 2025 18:40:23 GMT
Subject: RFR: 8367450: Shenandoah: Log the composition of the collection
 set [v6]
In-Reply-To: <oRCsTIZ4pbxWHeLGAUWqm46vrGcjGnU6AhjMEMkUgTs=.c0da55fd-7f39-4605-ac8d-ca12e0c15806@github.com>
References: <F_eMy4j26l3Nk4DM8ObN1mGLjaFvzHs0IlBfMV0zeqc=.0063c575-fc07-4a6b-801d-ea6f7b97dff7@github.com>
 <oRCsTIZ4pbxWHeLGAUWqm46vrGcjGnU6AhjMEMkUgTs=.c0da55fd-7f39-4605-ac8d-ca12e0c15806@github.com>
Message-ID: <Z-EDsrw_KRaFJmmS5bMWgCpI521pdtm2cEb69-_raQQ=.e397ecd1-3d3f-447c-bd4f-15b34d77ce1b@github.com>

On Thu, 18 Sep 2025 16:08:34 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Reuse the same log message from GenShen which details the composition of the live data to be evacuated. In the non-generational modes, all regions are considered young and nothing will be promoted (or old).
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve documentation for methods touched in this change

Thank you! ?

-------------

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27235#pullrequestreview-3241461808

From wkemper at openjdk.org  Thu Sep 18 19:06:21 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 18 Sep 2025 19:06:21 GMT
Subject: Integrated: 8367450: Shenandoah: Log the composition of the collection
 set
In-Reply-To: <F_eMy4j26l3Nk4DM8ObN1mGLjaFvzHs0IlBfMV0zeqc=.0063c575-fc07-4a6b-801d-ea6f7b97dff7@github.com>
References: <F_eMy4j26l3Nk4DM8ObN1mGLjaFvzHs0IlBfMV0zeqc=.0063c575-fc07-4a6b-801d-ea6f7b97dff7@github.com>
Message-ID: <-3IsI6mT8huONO3dw_xhyDJ4ak5FjctdN3rbtrIxraI=.16f3ec1d-e496-41e4-b519-55c73697ca5e@github.com>

On Thu, 11 Sep 2025 21:40:50 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Reuse the same log message from GenShen which details the composition of the live data to be evacuated. In the non-generational modes, all regions are considered young and nothing will be promoted (or old).

This pull request has now been integrated.

Changeset: 4be4826d
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4be4826ddb51c155eec3fe2923d891357f8d753b
Stats:     294 lines in 11 files changed: 50 ins; 205 del; 39 mod

8367450: Shenandoah: Log the composition of the collection set

Reviewed-by: ysr, kdnilsen, phh

-------------

PR: https://git.openjdk.org/jdk/pull/27235

From wkemper at openjdk.org  Thu Sep 18 19:24:31 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 18 Sep 2025 19:24:31 GMT
Subject: RFR: 8367473: Shenandoah: Make the detailed evacuation metrics a
 runtime diagnostic option [v5]
In-Reply-To: <FP1fZnZtr4y9iQr53Q6Kd2b44shx0FtUNKiLAAo02DY=.3e97e61d-d004-491b-898e-c58dd7bcacf7@github.com>
References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com>
 <FP1fZnZtr4y9iQr53Q6Kd2b44shx0FtUNKiLAAo02DY=.3e97e61d-d004-491b-898e-c58dd7bcacf7@github.com>
Message-ID: <D5wawcw-cAanJMU8Rczn2Y32gj0esxrVGA9k0wX-dm4=.3ea9694d-831d-4f00-b6b8-e0ee1430bc95@github.com>

On Thu, 18 Sep 2025 17:31:19 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Only print promotion/old evacuation metrics in generational mode

It's only suppressed in the non-generational mode, in which case there will _always_ be zero promotions/old evacuations. In the _generational_ mode, it will show the zeros to reinforce the notion that no promotions or old evacuations happened on _this_ cycle.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27238#issuecomment-3309136169

From wkemper at openjdk.org  Thu Sep 18 19:24:33 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 18 Sep 2025 19:24:33 GMT
Subject: Integrated: 8367473: Shenandoah: Make the detailed evacuation metrics
 a runtime diagnostic option
In-Reply-To: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com>
References: <94L4UDbruG66AHl2WPiZi-rKqUbuP9V7FyoHlLw9Ph8=.ab28d904-2d19-4ea5-b163-e560e1dbee4e@github.com>
Message-ID: <lc8Z7j06oxwpbLMa4BzWRKHjbHODFZjLofrgz8fska8=.d0ffec06-fbdf-44a2-9c46-ee9457f74b2e@github.com>

On Thu, 11 Sep 2025 22:43:23 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Non-product builds currently have a feature to produce detailed metrics about evacuations (number of objects, number of bytes, split out by age (young, old, promotion) and thread (mutator or worker). This change makes this feature accessible in release builds as a diagnostic option.

This pull request has now been integrated.

Changeset: e4cb86df
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e4cb86df2b05cef6dd7e29e8803ebbbf5b4fe5a2
Stats:     61 lines in 5 files changed: 27 ins; 7 del; 27 mod

8367473: Shenandoah: Make the detailed evacuation metrics a runtime diagnostic option
8367722: [GenShen] ShenandoahEvacuationStats is always empty

Reviewed-by: ysr, phh

-------------

PR: https://git.openjdk.org/jdk/pull/27238

From wkemper at openjdk.org  Thu Sep 18 19:58:56 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 18 Sep 2025 19:58:56 GMT
Subject: RFR: 8365792: GenShen: assertion "Generations aren't reconciled"
Message-ID: <Hhs_lBKpOo-djnxz0p1d49kQlJfnP6NI0G7si8kkLWs=.f5357d2e-166b-4841-beb1-b700bfa56a0f@github.com>

The coalesce-and-fill phase of an old gc cycle may be resumed at any time _without_ running a Shenandoah vm operation. The assertion itself is only meant to run during an operation which changes the active/gc generation. However, the assertion is made in places that may also run concurrently. The original assertion would be enforced if _any_ vm operation were running. For example, the assertions failures in the ticket show Shenandoah concurrently making old regions parsable (this assert should not be enforced) when a heap inspection operation takes a safepoint and (erroneously) causes this assertion to be enforced.

-------------

Commit messages:
 - Only shenandoah vm operations participate in active/gc generation scheme

Changes: https://git.openjdk.org/jdk/pull/27373/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27373&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365792
  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27373.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27373/head:pull/27373

PR: https://git.openjdk.org/jdk/pull/27373

From xpeng at openjdk.org  Thu Sep 18 20:09:00 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 18 Sep 2025 20:09:00 GMT
Subject: RFR: 8365792: GenShen: assertion "Generations aren't reconciled"
In-Reply-To: <Hhs_lBKpOo-djnxz0p1d49kQlJfnP6NI0G7si8kkLWs=.f5357d2e-166b-4841-beb1-b700bfa56a0f@github.com>
References: <Hhs_lBKpOo-djnxz0p1d49kQlJfnP6NI0G7si8kkLWs=.f5357d2e-166b-4841-beb1-b700bfa56a0f@github.com>
Message-ID: <_zxpTPbXNPMjwFXU4FSDwqkLHVQA8qClGEPch0fmXUM=.aa8c731d-fd2e-45a5-a5a8-8abe9b804f8e@github.com>

On Thu, 18 Sep 2025 19:06:50 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The coalesce-and-fill phase of an old gc cycle may be resumed at any time _without_ running a Shenandoah vm operation. The assertion itself is only meant to run during an operation which changes the active/gc generation. However, the assertion is made in places that may also run concurrently. The original assertion would be enforced if _any_ vm operation were running. For example, the assertions failures in the ticket show Shenandoah concurrently making old regions parsable (this assert should not be enforced) when a heap inspection operation takes a safepoint and (erroneously) causes this assertion to be enforced.

Thanks, it makes sense.

-------------

Marked as reviewed by xpeng (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27373#pullrequestreview-3241881071

From ysr at openjdk.org  Thu Sep 18 20:50:30 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 18 Sep 2025 20:50:30 GMT
Subject: RFR: 8365792: GenShen: assertion "Generations aren't reconciled"
In-Reply-To: <Hhs_lBKpOo-djnxz0p1d49kQlJfnP6NI0G7si8kkLWs=.f5357d2e-166b-4841-beb1-b700bfa56a0f@github.com>
References: <Hhs_lBKpOo-djnxz0p1d49kQlJfnP6NI0G7si8kkLWs=.f5357d2e-166b-4841-beb1-b700bfa56a0f@github.com>
Message-ID: <NxkUnEM1OpdbLXyS7KrSCS_6xNAyM5tn02N3PPkinXo=.2f84ebf5-35f2-42a9-932a-e458f16087e4@github.com>

On Thu, 18 Sep 2025 19:06:50 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The coalesce-and-fill phase of an old gc cycle may be resumed at any time _without_ running a Shenandoah vm operation. The assertion itself is only meant to run during an operation which changes the active/gc generation. However, the assertion is made in places that may also run concurrently. The original assertion would be enforced if _any_ vm operation were running. For example, the assertions failures in the ticket show Shenandoah concurrently making old regions parsable (this assert should not be enforced) when a heap inspection operation takes a safepoint and (erroneously) causes this assertion to be enforced.

Very cool; thanks for chasing this down and fixing it.

?

-------------

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27373#pullrequestreview-3242071548

From wkemper at openjdk.org  Thu Sep 18 21:21:27 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 18 Sep 2025 21:21:27 GMT
Subject: Integrated: 8365792: GenShen: assertion "Generations aren't
 reconciled"
In-Reply-To: <Hhs_lBKpOo-djnxz0p1d49kQlJfnP6NI0G7si8kkLWs=.f5357d2e-166b-4841-beb1-b700bfa56a0f@github.com>
References: <Hhs_lBKpOo-djnxz0p1d49kQlJfnP6NI0G7si8kkLWs=.f5357d2e-166b-4841-beb1-b700bfa56a0f@github.com>
Message-ID: <7PnRe1T2rbyTIAebAWjnrICi3fdHmOwIc3zQgLbs7HQ=.19daed6b-820b-4ab4-9810-470186d5db54@github.com>

On Thu, 18 Sep 2025 19:06:50 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The coalesce-and-fill phase of an old gc cycle may be resumed at any time _without_ running a Shenandoah vm operation. The assertion itself is only meant to run during an operation which changes the active/gc generation. However, the assertion is made in places that may also run concurrently. The original assertion would be enforced if _any_ vm operation were running. For example, the assertions failures in the ticket show Shenandoah concurrently making old regions parsable (this assert should not be enforced) when a heap inspection operation takes a safepoint and (erroneously) causes this assertion to be enforced.

This pull request has now been integrated.

Changeset: 6e4e966d
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6e4e966d9b71ec04618e19784b5a661f34595ef6
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8365792: GenShen: assertion "Generations aren't reconciled"

Reviewed-by: xpeng, ysr

-------------

PR: https://git.openjdk.org/jdk/pull/27373

From ysr at openjdk.org  Thu Sep 18 22:01:23 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 18 Sep 2025 22:01:23 GMT
Subject: RFR: 8367708: GenShen: Reduce total evacuation burden [v3]
In-Reply-To: <jXSlXas-EPze6BoNgx0zFpGY9fwc-S_GtaOSvBXvmpY=.478a79e8-8b27-4c11-95c3-e249ed6f0a2e@github.com>
References: <XgAjKd4zPFG5jDJ7OoyvefR9AiDN_Rj8nCMQlClXKQE=.23d80412-fddf-4e52-b25f-3be1e6d82c8e@github.com>
 <jXSlXas-EPze6BoNgx0zFpGY9fwc-S_GtaOSvBXvmpY=.478a79e8-8b27-4c11-95c3-e249ed6f0a2e@github.com>
Message-ID: <UuwvVDwTH9N8e1TCVG5Ko5wUIxxcR-y07a_xwuUQzz0=.07b679fe-7e26-43e8-8b03-f5289d01abbe@github.com>

On Tue, 16 Sep 2025 19:41:47 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This PR provides several improvements that cumulatively reduce the amount of evacuation performed by GenShen compared to traditional Shenandoah. Specifically:
>> 
>> 1. Do not promote humongous arrays of primitive data.  Leaving these regions in the young generation allows them to be reclaimed more quickly when they become garbage.  There is no disadvantage to leaving these regions in the young generation as their contents does not need to be scanned by the garbage collector.
>> 2. Change the default value of ShenandoahOldGarbageThreshold from 15% to 25%.  This results in smaller sets of candidate regions for mixed evacuation, less aggressive compaction of old generation.  This also increases the likelihood that a region will be promoted in place instead of promoted by evacuation.
>> 3. Only promote regions in place if the used within a region exceeds ShenandoahGenerationalMinPIPUsage (default 30) percent of the heap region size.  This is enforced in combination with the preexisting requirement that the garbage within the region be less than ShenandoahOldGarbageThreshold (new default 25) percent of the heap region size.  This causes regions with very low utilization to be promoted by evacuation rather than promoted in place.  While the immediate effect of this change is to perform more copying when the region is promoted, the secondary effect is that this region does not need to be evacuated at a later time, after it has accumulated more live data, as part of an effort to defragment old-gen memory.
>> 4. Only defragment old-gen memory if the command-line has requested non-zero reserves for humongous objects (ShenandoahGenerationalHumongousReserves).  Previously, we would invest in defragmenting old-gen memory every time we finished old-generation marking, even if ShenandoahGenerationalHumongousReserves equals zero.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes to trash_humongous_region_at()

src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 37:

> 35:                             constraint)                                     \
> 36:                                                                             \
> 37:   product(uintx, ShenandoahGenerationalMinPIPUsage, 30, EXPERIMENTAL,       \

Looking at this quite late, but thought I'd leave these comments here nonetheless.

While I agree that copying takes up cycle time and cpu, there is a potential space cost to promoting in place regions with substantial garbage. Why was 30% used (i.e. 70% garbage) considered reasonable? I'd have expected something like 50 or a tad higher used (i.e. less than 50% garbage) to be eligible for PIP.

Did higher values not work well for specific benchmarks that were used to pick this threshold?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27278#discussion_r2361276332

From ayang at openjdk.org  Fri Sep 19 07:57:49 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 19 Sep 2025 07:57:49 GMT
Subject: RFR: 8368072: Remove redundant arguments of MarkingNMethodClosure
Message-ID: <n2b-h3U2oduzaiO9_GjZ5nII1zFzLf4Wtkm8YVKcudY=.564253f7-b87e-46b1-bec9-1680eea0ed87@github.com>

"Inline" statically known value to callee to simplify `MarkingNMethodClosure`.

Test: tier1

-------------

Commit messages:
 - nmethod-closure-remove-arg

Changes: https://git.openjdk.org/jdk/pull/27382/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27382&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368072
  Stats: 21 lines in 6 files changed: 0 ins; 11 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/27382.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27382/head:pull/27382

PR: https://git.openjdk.org/jdk/pull/27382

From ayang at openjdk.org  Fri Sep 19 08:18:37 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 19 Sep 2025 08:18:37 GMT
Subject: RFR: 8368072: Remove redundant arguments of MarkingNMethodClosure
 [v2]
In-Reply-To: <n2b-h3U2oduzaiO9_GjZ5nII1zFzLf4Wtkm8YVKcudY=.564253f7-b87e-46b1-bec9-1680eea0ed87@github.com>
References: <n2b-h3U2oduzaiO9_GjZ5nII1zFzLf4Wtkm8YVKcudY=.564253f7-b87e-46b1-bec9-1680eea0ed87@github.com>
Message-ID: <o0NmxxH5hWQ1r0uUmaLWsb2v7VorEWIvD3mTFFBmkR4=.8d2b6a11-a78c-48e1-94be-6e59c04d9a5b@github.com>

> "Inline" statically known value to callee to simplify `MarkingNMethodClosure`.
> 
> Test: tier1

Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision:

 - review
 - review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27382/files
  - new: https://git.openjdk.org/jdk/pull/27382/files/598a28d4..7e0efed5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27382&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27382&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27382.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27382/head:pull/27382

PR: https://git.openjdk.org/jdk/pull/27382

From jsikstro at openjdk.org  Fri Sep 19 08:18:40 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 19 Sep 2025 08:18:40 GMT
Subject: RFR: 8368072: Remove redundant arguments of MarkingNMethodClosure
 [v2]
In-Reply-To: <o0NmxxH5hWQ1r0uUmaLWsb2v7VorEWIvD3mTFFBmkR4=.8d2b6a11-a78c-48e1-94be-6e59c04d9a5b@github.com>
References: <n2b-h3U2oduzaiO9_GjZ5nII1zFzLf4Wtkm8YVKcudY=.564253f7-b87e-46b1-bec9-1680eea0ed87@github.com>
 <o0NmxxH5hWQ1r0uUmaLWsb2v7VorEWIvD3mTFFBmkR4=.8d2b6a11-a78c-48e1-94be-6e59c04d9a5b@github.com>
Message-ID: <SJESSdOiDp6IYwJKFYtdwfHSMkbNQZ6mq6c6pr6TqaQ=.a045aad3-27c5-4fde-8793-66e97e7b409a@github.com>

On Fri, 19 Sep 2025 08:15:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> "Inline" statically known value to callee to simplify `MarkingNMethodClosure`.
>> 
>> Test: tier1
>
> Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - review
>  - review

src/hotspot/share/memory/iterator.hpp line 259:

> 257: 
> 258: class MarkingNMethodClosure : public NMethodToOopClosure {
> 259:   bool _keepalive_nmethods;

This isn't needed anymore, right?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27382#discussion_r2362121475

From fandreuzzi at openjdk.org  Fri Sep 19 08:18:42 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 19 Sep 2025 08:18:42 GMT
Subject: RFR: 8368072: Remove redundant arguments of MarkingNMethodClosure
 [v2]
In-Reply-To: <o0NmxxH5hWQ1r0uUmaLWsb2v7VorEWIvD3mTFFBmkR4=.8d2b6a11-a78c-48e1-94be-6e59c04d9a5b@github.com>
References: <n2b-h3U2oduzaiO9_GjZ5nII1zFzLf4Wtkm8YVKcudY=.564253f7-b87e-46b1-bec9-1680eea0ed87@github.com>
 <o0NmxxH5hWQ1r0uUmaLWsb2v7VorEWIvD3mTFFBmkR4=.8d2b6a11-a78c-48e1-94be-6e59c04d9a5b@github.com>
Message-ID: <ajHrv9QJDSX3bmA6p-cocFe0Z2cxrtKVcOPJiLzUt9w=.43bd80fc-9870-44ed-a8f5-22e3a72946cc@github.com>

On Fri, 19 Sep 2025 08:15:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> "Inline" statically known value to callee to simplify `MarkingNMethodClosure`.
>> 
>> Test: tier1
>
> Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - review
>  - review

src/hotspot/share/memory/iterator.hpp line 261:

> 259:  public:
> 260:   MarkingNMethodClosure(OopClosure* cl) :
> 261:       NMethodToOopClosure(cl, false /* fix_relocations */) {}

Would it be appropriate to use `!NMethodToOopClosure::FixRelocations` here instead?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27382#discussion_r2362127076

From ayang at openjdk.org  Fri Sep 19 08:34:37 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 19 Sep 2025 08:34:37 GMT
Subject: RFR: 8368072: Remove redundant arguments of MarkingNMethodClosure
 [v3]
In-Reply-To: <n2b-h3U2oduzaiO9_GjZ5nII1zFzLf4Wtkm8YVKcudY=.564253f7-b87e-46b1-bec9-1680eea0ed87@github.com>
References: <n2b-h3U2oduzaiO9_GjZ5nII1zFzLf4Wtkm8YVKcudY=.564253f7-b87e-46b1-bec9-1680eea0ed87@github.com>
Message-ID: <nbX8kjusV2a2FJPsuvOcCgCCAuoKcsaOiL-t8kXc1NY=.34971d6e-2ca9-4730-889c-77eddca8babc@github.com>

> "Inline" statically known value to callee to simplify `MarkingNMethodClosure`.
> 
> Test: tier1

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27382/files
  - new: https://git.openjdk.org/jdk/pull/27382/files/7e0efed5..637eb9a4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27382&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27382&range=01-02

  Stats: 5 lines in 1 file changed: 2 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27382.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27382/head:pull/27382

PR: https://git.openjdk.org/jdk/pull/27382

From stefank at openjdk.org  Fri Sep 19 08:34:37 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 19 Sep 2025 08:34:37 GMT
Subject: RFR: 8368072: Remove redundant arguments of MarkingNMethodClosure
 [v3]
In-Reply-To: <nbX8kjusV2a2FJPsuvOcCgCCAuoKcsaOiL-t8kXc1NY=.34971d6e-2ca9-4730-889c-77eddca8babc@github.com>
References: <n2b-h3U2oduzaiO9_GjZ5nII1zFzLf4Wtkm8YVKcudY=.564253f7-b87e-46b1-bec9-1680eea0ed87@github.com>
 <nbX8kjusV2a2FJPsuvOcCgCCAuoKcsaOiL-t8kXc1NY=.34971d6e-2ca9-4730-889c-77eddca8babc@github.com>
Message-ID: <yoXByW2TM88MIoORKvIv6063vn-mUEnitJ_3pHl6ORg=.fc04e984-7812-4955-92c8-b03e4a37b2de@github.com>

On Fri, 19 Sep 2025 08:32:02 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> "Inline" statically known value to callee to simplify `MarkingNMethodClosure`.
>> 
>> Test: tier1
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Marked as reviewed by stefank (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27382#pullrequestreview-3243772929

From stefank at openjdk.org  Fri Sep 19 08:34:40 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 19 Sep 2025 08:34:40 GMT
Subject: RFR: 8368072: Remove redundant arguments of MarkingNMethodClosure
 [v2]
In-Reply-To: <o0NmxxH5hWQ1r0uUmaLWsb2v7VorEWIvD3mTFFBmkR4=.8d2b6a11-a78c-48e1-94be-6e59c04d9a5b@github.com>
References: <n2b-h3U2oduzaiO9_GjZ5nII1zFzLf4Wtkm8YVKcudY=.564253f7-b87e-46b1-bec9-1680eea0ed87@github.com>
 <o0NmxxH5hWQ1r0uUmaLWsb2v7VorEWIvD3mTFFBmkR4=.8d2b6a11-a78c-48e1-94be-6e59c04d9a5b@github.com>
Message-ID: <T1ZRhXeeHfm3k9bCqY3-zXKaqj8nq22vUUAVkdx40ng=.edfc9305-6fa6-42be-aced-faed4fb48aa2@github.com>

On Fri, 19 Sep 2025 08:18:37 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> "Inline" statically known value to callee to simplify `MarkingNMethodClosure`.
>> 
>> Test: tier1
>
> Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - review
>  - review

src/hotspot/share/memory/iterator.hpp line 261:

> 259:  public:
> 260:   MarkingNMethodClosure(OopClosure* cl) :
> 261:       NMethodToOopClosure(cl, !NMethodToOopClosure::FixRelocations) {}

I think you should decouple MarkingNMethodClosure and NMethodToOopClosure. The later is only used to hold the same instance variables and one of them is unused after this change.


class MarkingNMethodClosure : public NMethodClosure {
  OopClosure* _cl;

public:
  MarkingNMethodClosure(OopClosure* cl) : _cl(cl) {}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27382#discussion_r2362151898

From fandreuzzi at openjdk.org  Fri Sep 19 08:40:35 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 19 Sep 2025 08:40:35 GMT
Subject: RFR: 8368072: Remove redundant arguments of MarkingNMethodClosure
 [v3]
In-Reply-To: <nbX8kjusV2a2FJPsuvOcCgCCAuoKcsaOiL-t8kXc1NY=.34971d6e-2ca9-4730-889c-77eddca8babc@github.com>
References: <n2b-h3U2oduzaiO9_GjZ5nII1zFzLf4Wtkm8YVKcudY=.564253f7-b87e-46b1-bec9-1680eea0ed87@github.com>
 <nbX8kjusV2a2FJPsuvOcCgCCAuoKcsaOiL-t8kXc1NY=.34971d6e-2ca9-4730-889c-77eddca8babc@github.com>
Message-ID: <s9GM66HKmlIDrr7DkCXK4EXSEgJ1C0GPRdipjrnyOTA=.402c60a5-ad8a-4e14-91a3-b66c0cabfa2f@github.com>

On Fri, 19 Sep 2025 08:34:37 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> "Inline" statically known value to callee to simplify `MarkingNMethodClosure`.
>> 
>> Test: tier1
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Marked as reviewed by fandreuzzi (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27382#pullrequestreview-3243807190

From kdnilsen at openjdk.org  Sat Sep 20 00:11:24 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sat, 20 Sep 2025 00:11:24 GMT
Subject: RFR: 8368015: Shenandoah: fix error in computation of average
 allocation rate
Message-ID: <gvhZ5s4LMcR4NQDCICvZZKtQgtNzL5wbl7hhG-j6cf8=.207310b9-3c82-4b69-9446-25f91061d7cc@github.com>

We use bytes_allocated_since_gc_start() to compute allocation rates.  This leaves a blind spot, as our current implementation ignores allocations and the time period between the moment we begin GC and the first time we update the allocation rate following the start of GC.  When this happens, we typically find that the sampled number of allocations is smaller than the allocations that had accumulated by the time we triggered the start of the current GC cycle.

This PR adds tracking for that accounting gap.

-------------

Commit messages:
 - fix whitespace
 - Account for gap allocations between gc cycles

Changes: https://git.openjdk.org/jdk/pull/27398/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27398&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368015
  Stats: 32 lines in 4 files changed: 25 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/27398.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27398/head:pull/27398

PR: https://git.openjdk.org/jdk/pull/27398

From wkemper at openjdk.org  Sat Sep 20 00:11:24 2025
From: wkemper at openjdk.org (William Kemper)
Date: Sat, 20 Sep 2025 00:11:24 GMT
Subject: RFR: 8368015: Shenandoah: fix error in computation of average
 allocation rate
In-Reply-To: <gvhZ5s4LMcR4NQDCICvZZKtQgtNzL5wbl7hhG-j6cf8=.207310b9-3c82-4b69-9446-25f91061d7cc@github.com>
References: <gvhZ5s4LMcR4NQDCICvZZKtQgtNzL5wbl7hhG-j6cf8=.207310b9-3c82-4b69-9446-25f91061d7cc@github.com>
Message-ID: <V4XHnrm9BI7E2dHATH24GatWNmfqYO_KXSEBrpMHbqI=.1d261b6b-4b27-433c-ac19-64ab9278dbb8@github.com>

On Fri, 19 Sep 2025 20:36:51 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> We use bytes_allocated_since_gc_start() to compute allocation rates.  This leaves a blind spot, as our current implementation ignores allocations and the time period between the moment we begin GC and the first time we update the allocation rate following the start of GC.  When this happens, we typically find that the sampled number of allocations is smaller than the allocations that had accumulated by the time we triggered the start of the current GC cycle.
> 
> This PR adds tracking for that accounting gap.

Is the real issue that we reset `bytes_allocated_since_gc_start` without sampling the value _before_ it is reset (thereby losing allocations that happen during the gc)? Would it be simpler to also take the sample just before it is reset (perhaps use an atomic exchange with zero, so we lose nothing)? Then we wouldn't need to juggle an extra member variable to remember the value. There is no reason we aren't allowed to update the allocation rate outside of `should_start_gc`.

Side note - should we really call this `bytes_allocated_since_gc_end`? I think that is what the variable actually represents because it is reset at the end of the cycle.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27398#pullrequestreview-3247194979

From kdnilsen at openjdk.org  Sat Sep 20 00:11:25 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sat, 20 Sep 2025 00:11:25 GMT
Subject: RFR: 8368015: Shenandoah: fix error in computation of average
 allocation rate
In-Reply-To: <V4XHnrm9BI7E2dHATH24GatWNmfqYO_KXSEBrpMHbqI=.1d261b6b-4b27-433c-ac19-64ab9278dbb8@github.com>
References: <gvhZ5s4LMcR4NQDCICvZZKtQgtNzL5wbl7hhG-j6cf8=.207310b9-3c82-4b69-9446-25f91061d7cc@github.com>
 <V4XHnrm9BI7E2dHATH24GatWNmfqYO_KXSEBrpMHbqI=.1d261b6b-4b27-433c-ac19-64ab9278dbb8@github.com>
Message-ID: <fEqI4ob0uLb_rJdasaTLeQQS4tjm3YK3g1pHN5fYZkk=.56ca861a-3628-4b41-9912-4d6a7c509761@github.com>

On Fri, 19 Sep 2025 21:29:32 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Is the real issue that we reset `bytes_allocated_since_gc_start` without sampling the value _before_ it is reset
> (thereby losing allocations that happen during the gc)?

I guess that's a big part of the problem.  But the other problem is that there is not a natural alignment between when we reset the bytes allocated and when we reset the values of _last_sample_time and _last_sample_value.

> Would it be simpler to also take the sample just before it is reset (perhaps use an atomic exchange with zero,
> so we lose nothing)?  Then we wouldn't need to juggle an extra member variable to remember the value. There
> is no reason we aren't allowed to update the allocation rate outside of `should_start_gc`.

There is some inherent synchronization in place that avoids the need for an atomic variable.  As implemented, we only
add samples from should_start_gc(), which is invoked by a single thread "at most" once per ms only when GC is idle and we add one additional sample with GenShen from within final_mark safepoint when we are calculating the necessary reserves.

So the proposed implementation already "loses" nothing, I think.

If you want to "save a variable", we could just initialize _last_sample_value to the bytes allocated following the last sample prior to start of GC instead of initializing this value to zero.  But then we would also have to initialize bytes_allocated_since_gc_start to this same value instead of initializing that to zero.  And this would make bytes_allocated_since_gc_start() a bit imprecise in that we would really be returning bytes allocated since last sample taken before gc start.  I guess I could live with that, but I'm inclined to keep the more accurate semantics and add the state variable to keep track of the delta...

> 
> Side note - should we really call this `bytes_allocated_since_gc_end`? I think that is what the variable actually
> represents because it is reset at the end of the cycle.

I believe we do reset at the start of GC.  The reset_bytes_allocated_since_gc_start() gets called from ShenandoahControlThread::run_service() whenever gc_requested, and at the top of ShenandoahGenerationalControlThread::run_gc_cycle().

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27398#issuecomment-3313963649

From wkemper at openjdk.org  Sat Sep 20 00:11:25 2025
From: wkemper at openjdk.org (William Kemper)
Date: Sat, 20 Sep 2025 00:11:25 GMT
Subject: RFR: 8368015: Shenandoah: fix error in computation of average
 allocation rate
In-Reply-To: <fEqI4ob0uLb_rJdasaTLeQQS4tjm3YK3g1pHN5fYZkk=.56ca861a-3628-4b41-9912-4d6a7c509761@github.com>
References: <gvhZ5s4LMcR4NQDCICvZZKtQgtNzL5wbl7hhG-j6cf8=.207310b9-3c82-4b69-9446-25f91061d7cc@github.com>
 <V4XHnrm9BI7E2dHATH24GatWNmfqYO_KXSEBrpMHbqI=.1d261b6b-4b27-433c-ac19-64ab9278dbb8@github.com>
 <fEqI4ob0uLb_rJdasaTLeQQS4tjm3YK3g1pHN5fYZkk=.56ca861a-3628-4b41-9912-4d6a7c509761@github.com>
Message-ID: <5SRTHzH_RSDCUkcrFB_zdKkqeBTAIYxscvSEnxT-_u8=.d43724fc-0113-4079-bbcc-d012e990eaf0@github.com>

On Fri, 19 Sep 2025 21:56:25 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> There is some inherent synchronization in place that avoids the need for an atomic variable.

I meant losing updates to `bytes_allocated_since_gc_start` made by mutators as they allocate. This read/reset could _technically_ lose updates from allocating threads (I'm not really worried about that):
```C++
    size_t bytes_allocated = young_generation()->bytes_allocated_since_gc_start();
    // Suppose control thread is off cpu here while mutators increase bytes allocated
    young_generation()->reset_bytes_allocated_since_gc_start();


I had something like this in mind:
```C++
  // atomic exchange existing value with zero
  size_t bytes_allocated = young_generation()->reset_bytes_allocated_since_gc_start();
  // incorporate the value into the samples for the average
  young_generation()->sample_allocations(bytes_allocated);


> I believe we do reset at the start of GC. 

You're right, I misread that code. I think I'm more confused now than I was before. I thought you were trying to fix the lost updates to `bytes_allocated_since_gc_start` between the last time the heuristic reads it and resets it. Shouldn't the average allocation rate work out the same if we read small changes frequently (the usual case when the GC is idle) or if we read a large change infrequently (such as our first read after it is reset)?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27398#issuecomment-3314002066

From kdnilsen at openjdk.org  Sat Sep 20 00:11:27 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sat, 20 Sep 2025 00:11:27 GMT
Subject: RFR: 8368015: Shenandoah: fix error in computation of average
 allocation rate
In-Reply-To: <gvhZ5s4LMcR4NQDCICvZZKtQgtNzL5wbl7hhG-j6cf8=.207310b9-3c82-4b69-9446-25f91061d7cc@github.com>
References: <gvhZ5s4LMcR4NQDCICvZZKtQgtNzL5wbl7hhG-j6cf8=.207310b9-3c82-4b69-9446-25f91061d7cc@github.com>
Message-ID: <1CVo2PV4oafnz4Es3iGyZiC8G9SBvp1B3oxrU-Pwd6c=.6d52c939-4b95-4945-803d-f1d6b566205d@github.com>

On Fri, 19 Sep 2025 20:36:51 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> We use bytes_allocated_since_gc_start() to compute allocation rates.  This leaves a blind spot, as our current implementation ignores allocations and the time period between the moment we begin GC and the first time we update the allocation rate following the start of GC.  When this happens, we typically find that the sampled number of allocations is smaller than the allocations that had accumulated by the time we triggered the start of the current GC cycle.
> 
> This PR adds tracking for that accounting gap.

As currently implemented, bytes_allocated_since_gc_start() is reliable (as in mainline, or as in the PR that unifies all accounting within the ShenandoahFreeSet).

The problem is that the average allocation rate is not reliable.  The reason average allocation rate is not reliable is because:
1. In the most common case, all of the allocations that happen between the moment we last sampled before the start of GC and we next sample at the end of final mark are ignored.  This might represent several seconds of time.  In the case that allocation rates are increasing, we will be excluding the most recent several seconds of allocation behavior from our next allocation average.
2. In the less common case, our "average" allocation rate will be grossly under-reported.  Consider a case where allocation rate is gradually increasing.  We've been sampling every 100 ms, and our average rate at the time we trigger GC is based on recent allocation rates of: ..., 1GB/s, 1.1GB/s, 1.3GB/s, 1.4GB/s and then we trigger.  Suppose allocation rates continue to increase at this same rate, but we don't sample again until the end of marking, which takes 3 seconds.  During these 3 seconds, we have missed 30 updates.  If we had continued to sample, we would have seen that the most recent 100 ms allocated at a rate of 4.5 GB/s.  The proposed new implementation would add a sample that says we just allocated at an average rate of ~3GB/s for ~3.05 seconds.  In the current  implementation, we might find that the last_sample_value is 8GB (assume this sample happened 50 ms before GC was triggered).  The new value of allocated will be 9 GB (3 GB/s for 3 seconds).  So we'll add into our 
 average the value 1 GB allocated in 3.05 seconds, or approximately 333 MB/s (with a heavy weight because this represents 3 seconds of execution time).  This causes triggering heuristic to be overly optimistic, because they are left believing that allocations are at a lower rate than reality.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 374:

> 372:     _rate.add(rate);
> 373:     _rate_avg.add(_rate.avg());
> 374:     _last_sample_time = now;

Note: in original implementation, the first sample() collected following the start of GC typically finds that allocated < _last_sample_value, so we ignore all data associated with that time gap.  With Shenandoah, the next sample happens the first time we ask should_start_gc() following the completion of the current GC.  With GenShen, the next sample happens after marking, when we calculate the allocation runway in order to size our reserves.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27398#issuecomment-3314220009
PR Review Comment: https://git.openjdk.org/jdk/pull/27398#discussion_r2364492203

From kdnilsen at openjdk.org  Sat Sep 20 00:11:28 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sat, 20 Sep 2025 00:11:28 GMT
Subject: RFR: 8368015: Shenandoah: fix error in computation of average
 allocation rate
In-Reply-To: <1CVo2PV4oafnz4Es3iGyZiC8G9SBvp1B3oxrU-Pwd6c=.6d52c939-4b95-4945-803d-f1d6b566205d@github.com>
References: <gvhZ5s4LMcR4NQDCICvZZKtQgtNzL5wbl7hhG-j6cf8=.207310b9-3c82-4b69-9446-25f91061d7cc@github.com>
 <1CVo2PV4oafnz4Es3iGyZiC8G9SBvp1B3oxrU-Pwd6c=.6d52c939-4b95-4945-803d-f1d6b566205d@github.com>
Message-ID: <qT6VO7yqIzuH7qLGQslofggPpnHt4JNkEdivME0VLgU=.2c073a5a-160e-4426-abf0-f78d8aad2ce6@github.com>

On Fri, 19 Sep 2025 20:43:59 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> We use bytes_allocated_since_gc_start() to compute allocation rates.  This leaves a blind spot, as our current implementation ignores allocations and the time period between the moment we begin GC and the first time we update the allocation rate following the start of GC.  When this happens, we typically find that the sampled number of allocations is smaller than the allocations that had accumulated by the time we triggered the start of the current GC cycle.
>> 
>> This PR adds tracking for that accounting gap.
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 374:
> 
>> 372:     _rate.add(rate);
>> 373:     _rate_avg.add(_rate.avg());
>> 374:     _last_sample_time = now;
> 
> Note: in original implementation, the first sample() collected following the start of GC typically finds that allocated < _last_sample_value, so we ignore all data associated with that time gap.  With Shenandoah, the next sample happens the first time we ask should_start_gc() following the completion of the current GC.  With GenShen, the next sample happens after marking, when we calculate the allocation runway in order to size our reserves.

It is possible that the first sample() collected() following the start of GC finds allocated > _last_sample value.  If this happens, the above computes a bogus result.  It thinks we've only allocated (new_sample_value - _last_sample_value) bytes in total time (now - _last_sample_time).  In truth, we've allocated new_sample_value plus currently_unknown_allocations following _last_sample_time but before the start of GC.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27398#discussion_r2364497570

From kdnilsen at openjdk.org  Sat Sep 20 00:20:13 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sat, 20 Sep 2025 00:20:13 GMT
Subject: RFR: 8368015: Shenandoah: fix error in computation of average
 allocation rate
In-Reply-To: <gvhZ5s4LMcR4NQDCICvZZKtQgtNzL5wbl7hhG-j6cf8=.207310b9-3c82-4b69-9446-25f91061d7cc@github.com>
References: <gvhZ5s4LMcR4NQDCICvZZKtQgtNzL5wbl7hhG-j6cf8=.207310b9-3c82-4b69-9446-25f91061d7cc@github.com>
Message-ID: <KkP-OBiEUggvpX3NpdfDM-g18nen9JidRoYCZuS3RMg=.71699612-a0ae-4228-8f29-4a9e3b70d4fb@github.com>

On Fri, 19 Sep 2025 20:36:51 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> We use bytes_allocated_since_gc_start() to compute allocation rates.  This leaves a blind spot, as our current implementation ignores allocations and the time period between the moment we begin GC and the first time we update the allocation rate following the start of GC.  When this happens, we typically find that the sampled number of allocations is smaller than the allocations that had accumulated by the time we triggered the start of the current GC cycle.
> 
> This PR adds tracking for that accounting gap.

> 
> I had something like this in mind:
> 
> ```c++
>   // atomic exchange existing value with zero
>   size_t bytes_allocated = young_generation()->reset_bytes_allocated_since_gc_start();
>   // incorporate the value into the samples for the average
>   young_generation()->sample_allocations(bytes_allocated);
> ```
> 

This is a good idea.  We'll end up with two samples whereas my proposed solution had a single combined sample.  But we avoid the extra variable.  Also, two samples gives us better awareness of acceleration...

I'll make this change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27398#issuecomment-3314273445

From ayang at openjdk.org  Mon Sep 22 07:18:58 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 22 Sep 2025 07:18:58 GMT
Subject: RFR: 8368072: Remove redundant arguments of MarkingNMethodClosure
 [v3]
In-Reply-To: <nbX8kjusV2a2FJPsuvOcCgCCAuoKcsaOiL-t8kXc1NY=.34971d6e-2ca9-4730-889c-77eddca8babc@github.com>
References: <n2b-h3U2oduzaiO9_GjZ5nII1zFzLf4Wtkm8YVKcudY=.564253f7-b87e-46b1-bec9-1680eea0ed87@github.com>
 <nbX8kjusV2a2FJPsuvOcCgCCAuoKcsaOiL-t8kXc1NY=.34971d6e-2ca9-4730-889c-77eddca8babc@github.com>
Message-ID: <P4Ra9Xh-ZkGyyl0DiD9dg_mIEtOf9o_76TTwcZiu3tE=.1bb891fa-cdc5-470e-8c8e-0a75634233d1@github.com>

On Fri, 19 Sep 2025 08:34:37 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> "Inline" statically known value to callee to simplify `MarkingNMethodClosure`.
>> 
>> Test: tier1
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Thanks for review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27382#issuecomment-3317298325

From ayang at openjdk.org  Mon Sep 22 07:23:55 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 22 Sep 2025 07:23:55 GMT
Subject: Integrated: 8368072: Remove redundant arguments of
 MarkingNMethodClosure
In-Reply-To: <n2b-h3U2oduzaiO9_GjZ5nII1zFzLf4Wtkm8YVKcudY=.564253f7-b87e-46b1-bec9-1680eea0ed87@github.com>
References: <n2b-h3U2oduzaiO9_GjZ5nII1zFzLf4Wtkm8YVKcudY=.564253f7-b87e-46b1-bec9-1680eea0ed87@github.com>
Message-ID: <x0gRIeGAMsBomwDc7TnS7THM3Ts7pOTEc6wCcA8zG8g=.8d103b3b-e8ca-457a-9fc3-b25b2bfd0a72@github.com>

On Fri, 19 Sep 2025 07:47:45 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> "Inline" statically known value to callee to simplify `MarkingNMethodClosure`.
> 
> Test: tier1

This pull request has now been integrated.

Changeset: f10fbe1f
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f10fbe1fb40645633b91fad2af3d7c2cbb005b39
Stats:     23 lines in 6 files changed: 0 ins; 12 del; 11 mod

8368072: Remove redundant arguments of MarkingNMethodClosure

Reviewed-by: stefank, fandreuzzi

-------------

PR: https://git.openjdk.org/jdk/pull/27382

From xpeng at openjdk.org  Mon Sep 22 08:46:32 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Mon, 22 Sep 2025 08:46:32 GMT
Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS
 for memory allocation
Message-ID: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@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 mutator memory allocation to improve heap lock contention, at vey high level, here is how it works:
* ShenandoahFreeSet holds a N (default to 13) number of ShenandoahHeapRegion* which are used by mutator threads for regular object allocations, they are called shared regions/directly allocatable regions, which are stored in PaddedEnd data structure(padded array).
* Each mutator thread will be assigned one of the directly allocatable regions, the thread will try to allocate in the directly allocatable region with CAS atomic operation, if fails will try 2 more consecutive  directly allocatable regions in the array storing directly allocatable region.
* If mutator thread fails after trying 3 directly allocatable regions, it will:
   * Take heap lock
   * Try to retire the directly allocatable regions which are ready to retire.
   *  Iterator mutator partition and allocate directly allocatable regions and store to the padded array if any need to be retired.
   *  Satisfy mutator allocation request if possible.


I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, I have done many tests, here are some of them:

1. Dacapo lusearch test on EC2 host with 96 CPU cores:
Openjdk TIP:

[ec2-user at ip-172-31-42-91 jdk]$ ./master-jdk/bin/java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms4G -Xmx4G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions  -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational  -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar  -n 10 lusearch  | grep "metered full smoothing"
===== DaCapo tail latency, metered full smoothing: 50% 131684 usec, 90% 200192 usec, 99% 211369 usec, 99.9% 212517 usec, 99.99% 213043 usec, max 235289 usec, measured over 524288 events =====
===== DaCapo tail latency, metered full smoothing: 50% 1568 usec, 90% 36101 usec, 99% 42172 usec, 99.9% 42928 usec, 99.99% 43100 usec, max 43305 usec, measured over 524288 events =====
===== DaCapo tail latency, metered full smoothing: 50% 52644 usec, 90% 124393 usec, 99% 137711 usec, 99.9% 139355 usec, 99.99% 139749 usec, max 146722 usec, measured over 524288 events =====
===== DaCapo tail latency, metered full smoothing: 50% 28623 usec, 90% 67126 usec, 99% 73916 usec, 99.9% 75175 usec, 99.99% 75462 usec, max 79066 usec, measured over 524288 events =====
===== DaCapo tail latency, metered full smoothing: 50% 41 usec, 90% 9428 usec, 99% 21770 usec, 99.9% 23106 usec, 99.99% 23443 usec, max 24179 usec, measured over 524288 events =====
===== DaCapo tail latency, metered full smoothing: 50% 44215 usec, 90% 89790 usec, 99% 96317 usec, 99.9% 97160 usec, 99.99% 97447 usec, max 101699 usec, measured over 524288 events =====
===== DaCapo tail latency, metered full smoothing: 50% 5760 usec, 90% 55041 usec, 99% 66487 usec, 99.9% 67538 usec, 99.99% 67993 usec, max 75581 usec, measured over 524288 events =====
===== DaCapo tail latency, metered full smoothing: 50% 44 usec, 90% 10890 usec, 99% 23198 usec, 99.9% 24500 usec, 99.99% 24880 usec, max 25787 usec, measured over 524288 events =====
===== DaCapo tail latency, metered full smoothing: 50% 173 usec, 90% 28241 usec, 99% 44742 usec, 99.9% 46328 usec, 99.99% 46815 usec, max 51731 usec, measured over 524288 events =====
===== DaCapo tail latency, metered full smoothing: 50% 3386 usec, 90% 52216 usec, 99% 65358 usec, 99.9% 67119 usec, 99.99% 67612 usec, max 75257 usec, measured over 524288 events =====


With CAS allocator:

[ec2-user at ip-172-31-42-91 jdk]$ ./cas-alloc-jdk/bin/java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms4G -Xmx4G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions  -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational  -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar  -n 10 lusearch  | grep "metered full smoothing"
===== DaCapo tail latency, metered full smoothing: 50% 116096 usec, 90% 181392 usec, 99% 194708 usec, 99.9% 197017 usec, 99.99% 198255 usec, max 209449 usec, measured over 524288 events =====
===== DaCapo tail latency, metered full smoothing: 50% 26 usec, 90% 205 usec, 99% 2192 usec, 99.9% 5521 usec, 99.99% 9909 usec, max 20341 usec, measured over 524288 events =====
===== DaCapo tail latency, metered full smoothing: 50% 30 usec, 90% 206 usec, 99% 819 usec, 99.9% 6330 usec, 99.99% 18174 usec, max 26832 usec, measured over 524288 events =====
===== DaCapo tail latency, metered full smoothing: 50% 26 usec, 90% 188 usec, 99% 770 usec, 99.9% 9462 usec, 99.99% 14628 usec, max 20693 usec, measured over 524288 events =====
===== DaCapo tail latency, metered full smoothing: 50% 26 usec, 90% 191 usec, 99% 793 usec, 99.9% 9579 usec, 99.99% 15123 usec, max 18807 usec, measured over 524288 events =====
===== DaCapo tail latency, metered full smoothing: 50% 30 usec, 90% 211 usec, 99% 654 usec, 99.9% 5401 usec, 99.99% 14597 usec, max 30266 usec, measured over 524288 events =====
===== DaCapo tail latency, metered full smoothing: 50% 27 usec, 90% 196 usec, 99% 794 usec, 99.9% 4499 usec, 99.99% 21784 usec, max 32097 usec, measured over 524288 events =====
===== DaCapo tail latency, metered full smoothing: 50% 32 usec, 90% 236 usec, 99% 546 usec, 99.9% 4874 usec, 99.99% 17115 usec, max 24615 usec, measured over 524288 events =====
===== DaCapo tail latency, metered full smoothing: 50% 30 usec, 90% 202 usec, 99% 698 usec, 99.9% 7301 usec, 99.99% 12966 usec, max 14096 usec, measured over 524288 events =====
===== DaCapo tail latency, metered full smoothing: 50% 26 usec, 90% 193 usec, 99% 740 usec, 99.9% 5625 usec, 99.99% 16836 usec, max 22915 usec, measured over 524288 events =====



Same tests, if I run it on smaller instance with less CPU cores, the improvement is much less. 

2. specJBB2015 on EC2 with 2 cores, 4G heap:

OpenJDK tip

jbb2015.result.category = SPECjbb2015-Composite
jbb2015.result.group.count = 1
jbb2015.result.metric.max-jOPS = 2801
jbb2015.result.metric.critical-jOPS = 1463
jbb2015.result.SLA-10000-jOPS = 967
jbb2015.result.SLA-25000-jOPS = 1260
jbb2015.result.SLA-50000-jOPS = 1532
jbb2015.result.SLA-75000-jOPS = 1861
jbb2015.result.SLA-100000-jOPS = 1927



With CAS allocator:

jbb2015.result.category = SPECjbb2015-Composite
jbb2015.result.group.count = 1
jbb2015.result.metric.max-jOPS = 2965
jbb2015.result.metric.critical-jOPS = 1487
jbb2015.result.SLA-10000-jOPS = 906
jbb2015.result.SLA-25000-jOPS = 1197
jbb2015.result.SLA-50000-jOPS = 1692
jbb2015.result.SLA-75000-jOPS = 1867
jbb2015.result.SLA-100000-jOPS = 2125



2. specJBB2015 on EC2 with 16 cores, 31G heap:
OpenJDK tip:

jbb2015.result.category = SPECjbb2015-Composite
jbb2015.result.group.count = 1
jbb2015.result.metric.max-jOPS = 26740
jbb2015.result.metric.critical-jOPS = 22588
jbb2015.result.SLA-10000-jOPS = 15998
jbb2015.result.SLA-25000-jOPS = 23140
jbb2015.result.SLA-50000-jOPS = 24454
jbb2015.result.SLA-75000-jOPS = 25094
jbb2015.result.SLA-100000-jOPS = 25882


With CAS allocator:

jbb2015.result.category = SPECjbb2015-Composite
jbb2015.result.group.count = 1
jbb2015.result.metric.max-jOPS = 28454
jbb2015.result.metric.critical-jOPS = 23763
jbb2015.result.SLA-10000-jOPS = 16284
jbb2015.result.SLA-25000-jOPS = 24511
jbb2015.result.SLA-50000-jOPS = 25882
jbb2015.result.SLA-75000-jOPS = 26911
jbb2015.result.SLA-100000-jOPS = 27254



### Other tests:
- [x] All Shenandoah jtreg tests

-------------

Commit messages:
 - Merge branch 'master' into cas-alloc-1
 - Move ShenandoahHeapRegionIterationClosure to shenandoahFreeSet.hpp
 - Merge branch 'openjdk:master' into cas-alloc-1
 - Fix errors caused by renaming ofAtomic to AtomicAccess
 - Merge branch 'openjdk:master' into cas-alloc-1
 - Remove unused flag
 - Merge branch 'openjdk:master' into cas-alloc-1
 - Merge branch 'cas-alloc-1' into cas-alloc
 - Merge branch 'cas-alloc-1' of https://github.com/pengxiaolong/jdk into cas-alloc-1
 - Merge branch 'master' into cas-alloc-1
 - ... and 120 more: https://git.openjdk.org/jdk/compare/44454633...087b54fb

Changes: https://git.openjdk.org/jdk/pull/26171/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361099
  Stats: 735 lines in 16 files changed: 674 ins; 7 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/26171.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171

PR: https://git.openjdk.org/jdk/pull/26171

From kdnilsen at openjdk.org  Mon Sep 22 08:46:40 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 22 Sep 2025 08:46:40 GMT
Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using
 CAS for memory allocation
In-Reply-To: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
References: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
Message-ID: <JgNk3o87C6Lz5xtmuAclB83IDkW5fQYHZAxQh-Kv-yY=.590627c9-ebd9-4081-b4f3-f9b0d3339cab@github.com>

On Mon, 7 Jul 2025 19:56:30 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of mutator memory allocation to improve heap lock contention, at vey high level, here is how it works:
> * ShenandoahFreeSet holds a N (default to 13) number of ShenandoahHeapRegion* which are used by mutator threads for regular object allocations, they are called shared regions/directly allocatable regions, which are stored in PaddedEnd data structure(padded array).
> * Each mutator thread will be assigned one of the directly allocatable regions, the thread will try to allocate in the directly allocatable region with CAS atomic operation, if fails will try 2 more consecutive  directly allocatable regions in the array storing directly allocatable region.
> * If mutator thread fails after trying 3 directly allocatable regions, it will:
>    * Take heap lock
>    * Try to retire the directly allocatable regions which are ready to retire.
>    *  Iterator mutator partition and allocate directly allocatable regions and store to the padded array if any need to be retired.
>    *  Satisfy mutator allocation request if possible.
> 
> 
> I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, I have done many tests, here are some of them:
> 
> 1. Dacapo lusearch test on EC2 host with 96 CPU cores:
> Openjdk TIP:
> 
> [ec2-user at ip-172-31-42-91 jdk]$ ./master-jdk/bin/java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms4G -Xmx4G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions  -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational  -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar  -n 10 lusearch  | grep "metered full smoothing"
> ===== DaCapo tail latency, metered full smoothing: 50% 131684 usec, 90% 200192 usec, 99% 211369 usec, 99.9% 212517 usec, 99.99% 213043 usec, max 235289 usec, measured over 524288 events =====
> ===== DaCapo tail latency, metered full smoothing: 50% 1568 usec, 90% 36101 usec, 99% 42172 usec, 99.9% 42928 usec, 99.99% 43100 usec, max 43305 usec, measured over 524288 events =====
> ===== DaCapo tail latency, metered full smoothing: 50% 52644 usec, 90% 124393 usec, 99% 137711 usec, 99.9% 139355 usec, 99.99% 139749 usec, max 146722 usec, measured over 524288 events ====...

Thanks for doing this work.  It is huge progress.  I've left a number of comments.  I didn't have time to study/comment on all of the code, as I am out-of-office for rest of this week.  I'll look more when I return.

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 246:

> 244:   _leftmosts_empty[int(ShenandoahFreeSetPartitionId::Mutator)] = mutator_leftmost_empty;
> 245:   _rightmosts_empty[int(ShenandoahFreeSetPartitionId::Mutator)] = mutator_rightmost_empty;
> 246: 

We have the heap lock here, so should not need to use atomic store operations.  Atomic operations have a performance penalty that I think we want to avoid.

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 247:

> 245:   _rightmosts_empty[int(ShenandoahFreeSetPartitionId::Mutator)] = mutator_rightmost_empty;
> 246: 
> 247:   Atomic::store(_region_counts + int(ShenandoahFreeSetPartitionId::Mutator), mutator_region_count);

If we do need to use Atomic operations, would prefer &_region_counts[int(ShenandoahFreeSetPartitionId::Mutator)] notation for the array elements.

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 282:

> 280: 
> 281: void ShenandoahRegionPartitions::increase_used(ShenandoahFreeSetPartitionId which_partition, size_t bytes) {
> 282:   shenandoah_assert_heaplocked();

Are you now calling this directly from the CAS allocators?  So you want to not have to assert heap locked and that is why we make the used accounting atomic?

My preference would be to avoid this need by counting the entire region as used at the time the region becomes directly allocatable.

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 615:

> 613:         size_t capacity = _free_set->alloc_capacity(i);
> 614:         bool is_empty = (capacity == _region_size_bytes);
> 615:         // TODO remove assert, not possible to pass when allow mutator to allocate w/o lock.

Probably the preferred approach here is to "pre-retire" regions when they are made directly allocatable.  When the region is pre-retired, it is taken out of the partition, so assert_bounds no longer applies to this region.

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 2151:

> 2149: 
> 2150: template<bool IS_TLAB>
> 2151: HeapWord* ShenandoahFreeSet::par_allocate_single_for_mutator(ShenandoahAllocRequest &req, bool &in_new_region) {

Not clear to me what prefix par_ represents.  Parallel allocate (without lock?)

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 2168:

> 2166:     for (uint i = 0u; i < max_probes; i++) {
> 2167:       ShenandoahHeapRegion** shared_region_address = _directly_allocatable_regions + idx;
> 2168:       ShenandoahHeapRegion* r = Atomic::load_acquire(shared_region_address);

This code has a lot more synchronization overhead than what is required for CAS allocations.  load_acquire() forces a memory fence.  All writes performed by other threads before the store_release() must be visible to this thread upon return from load_acquire.  I would like to see some documentation that describes the coherency model that we assume/require here.  Can we write this up as a comment in the header file?

Personal preference: I think there are many situations where we get better performance if we allow ourselves to see slightly old data, and we can argue that the slightly old data is "harmless".  For example, if some other thread replaces the directly_allocatable_region[N] while we're attempting to allocate from directly_allocatable_region[N], we might attempt to allocate from the original region and fail.  That's harmless.  We'll just retry at the next probe point.  If multiple probes fail to allocate, we'll take the synchronization lock and everything will be resolved there.  The accumulation of atomic volatile access has a big impact on performance.  I've measured this in previous experiments.  You can do the same.

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 2191:

> 2189:     }
> 2190:     // If any of the 3 consecutive directly allocatable regions is ready for retire and replacement,
> 2191:     // grab heap lock try to retire all ready-to-retire shared regions.

Would be preferable to allow this thread to retire all ready-to-retire regions in the directly allocatable set (not just the three that I know about) while it holds the heap lock.  We do not necessarily need to keep a separate per-thread representation of ready-to-retire shared regions.  This is a very rare event. Just iterate through the 13 (or whatever) regions in the directly allocatable set and ask for each whether end-top is less than min plab size.

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 81:

> 79:   // are denoted in bytes.  Note that some regions that had been assigned to a particular partition at rebuild time
> 80:   // may have been retired following the rebuild.  The tallies for these regions are still reflected in _capacity[p]
> 81:   // and _used[p], even though the region may have been removed from the free set.

Prefer not to make these volatile, as that imposes a compiler overhead.

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 226:

> 224:   inline size_t available_in(ShenandoahFreeSetPartitionId which_partition) const {
> 225:     assert (which_partition < NumPartitions, "selected free set must be valid");
> 226:     return capacity_of(which_partition) - used_by(which_partition);

We can't do this outside of a lock.  The value fetched for capacity may be incoherent with the value fetched for used (because each is modified independently).  That is why the previous version of the code used the available[] array and computed its value while holding the lock.

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 232:

> 230:   // returned without acquiring the lock.  In debug builds, the global heap lock is acquired in order to
> 231:   // enforce a consistency assert.
> 232:   inline size_t available_in_not_locked(ShenandoahFreeSetPartitionId which_partition) const {

These changes are beyond the scope of planned topic.  I think we need to consider them more carefully.  Would prefer not to mix the two.  (and I personally believe the original implementation has better performance, but feel free to prove me wrong.)

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 274:

> 272: };
> 273: 
> 274: #define DIRECTLY_ALLOCATABLE_REGION_UNKNOWN_AFFINITY ((Thread*)-1)

Out of time to dive deep into this right now.  Wonder if it makes sense to randomly generate a hash for each thread and store this into a thread-local field.  Might provide "randomness" and locality.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26171#pullrequestreview-2998610364
PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2193123384
PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2193127191
PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2193133676
PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2193188287
PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2195596428
PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2195616392
PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2195638643
PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2193242080
PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2193250484
PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2195588615
PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2195661494

From wkemper at openjdk.org  Mon Sep 22 08:46:41 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 22 Sep 2025 08:46:41 GMT
Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using
 CAS for memory allocation
In-Reply-To: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
References: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
Message-ID: <XScQtjAH_vKXAUXlKvzvbjOtphx7n5W48UirnVGEYyo=.ca734751-4ab9-42d5-8837-c7f29395e480@github.com>

On Mon, 7 Jul 2025 19:56:30 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of mutator memory allocation to improve heap lock contention, at vey high level, here is how it works:
> * ShenandoahFreeSet holds a N (default to 13) number of ShenandoahHeapRegion* which are used by mutator threads for regular object allocations, they are called shared regions/directly allocatable regions, which are stored in PaddedEnd data structure(padded array).
> * Each mutator thread will be assigned one of the directly allocatable regions, the thread will try to allocate in the directly allocatable region with CAS atomic operation, if fails will try 2 more consecutive  directly allocatable regions in the array storing directly allocatable region.
> * If mutator thread fails after trying 3 directly allocatable regions, it will:
>    * Take heap lock
>    * Try to retire the directly allocatable regions which are ready to retire.
>    *  Iterator mutator partition and allocate directly allocatable regions and store to the padded array if any need to be retired.
>    *  Satisfy mutator allocation request if possible.
> 
> 
> I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, I have done many tests, here are some of them:
> 
> 1. Dacapo lusearch test on EC2 host with 96 CPU cores:
> Openjdk TIP:
> 
> [ec2-user at ip-172-31-42-91 jdk]$ ./master-jdk/bin/java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms4G -Xmx4G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions  -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational  -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar  -n 10 lusearch  | grep "metered full smoothing"
> ===== DaCapo tail latency, metered full smoothing: 50% 131684 usec, 90% 200192 usec, 99% 211369 usec, 99.9% 212517 usec, 99.99% 213043 usec, max 235289 usec, measured over 524288 events =====
> ===== DaCapo tail latency, metered full smoothing: 50% 1568 usec, 90% 36101 usec, 99% 42172 usec, 99.9% 42928 usec, 99.99% 43100 usec, max 43305 usec, measured over 524288 events =====
> ===== DaCapo tail latency, metered full smoothing: 50% 52644 usec, 90% 124393 usec, 99% 137711 usec, 99.9% 139355 usec, 99.99% 139749 usec, max 146722 usec, measured over 524288 events ====...

It would be helpful to have a more detailed overview in the change log description to help reviewers get oriented with the changes.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26171#pullrequestreview-3007644661

From xpeng at openjdk.org  Mon Sep 22 08:46:41 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Mon, 22 Sep 2025 08:46:41 GMT
Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using
 CAS for memory allocation
In-Reply-To: <XScQtjAH_vKXAUXlKvzvbjOtphx7n5W48UirnVGEYyo=.ca734751-4ab9-42d5-8837-c7f29395e480@github.com>
References: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
 <XScQtjAH_vKXAUXlKvzvbjOtphx7n5W48UirnVGEYyo=.ca734751-4ab9-42d5-8837-c7f29395e480@github.com>
Message-ID: <vTSZLaIhUbET2qc01hVSBeRlyVAz5H7FjWXInmtRThc=.7cf0f597-86c6-4447-bd07-8e5f1389a52d@github.com>

On Thu, 10 Jul 2025 22:45:01 GMT, William Kemper <wkemper at openjdk.org> wrote:

> It would be helpful to have a more detailed overview in the change log description to help reviewers get oriented with the changes.

Thanks, I'll add detailed overview next week, I didn't add too much since I knew I was going to change the code significantly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26171#issuecomment-3064470661

From xpeng at openjdk.org  Mon Sep 22 08:46:43 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Mon, 22 Sep 2025 08:46:43 GMT
Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using
 CAS for memory allocation
In-Reply-To: <JgNk3o87C6Lz5xtmuAclB83IDkW5fQYHZAxQh-Kv-yY=.590627c9-ebd9-4081-b4f3-f9b0d3339cab@github.com>
References: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
 <JgNk3o87C6Lz5xtmuAclB83IDkW5fQYHZAxQh-Kv-yY=.590627c9-ebd9-4081-b4f3-f9b0d3339cab@github.com>
Message-ID: <IRgMbTQIV2pGn3OdOYj152mrizMTEYzKnLXcPmgeALs=.7a088a6d-1fef-4c1c-8a6c-753116b461e8@github.com>

On Tue, 8 Jul 2025 17:55:33 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of mutator memory allocation to improve heap lock contention, at vey high level, here is how it works:
>> * ShenandoahFreeSet holds a N (default to 13) number of ShenandoahHeapRegion* which are used by mutator threads for regular object allocations, they are called shared regions/directly allocatable regions, which are stored in PaddedEnd data structure(padded array).
>> * Each mutator thread will be assigned one of the directly allocatable regions, the thread will try to allocate in the directly allocatable region with CAS atomic operation, if fails will try 2 more consecutive  directly allocatable regions in the array storing directly allocatable region.
>> * If mutator thread fails after trying 3 directly allocatable regions, it will:
>>    * Take heap lock
>>    * Try to retire the directly allocatable regions which are ready to retire.
>>    *  Iterator mutator partition and allocate directly allocatable regions and store to the padded array if any need to be retired.
>>    *  Satisfy mutator allocation request if possible.
>> 
>> 
>> I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, I have done many tests, here are some of them:
>> 
>> 1. Dacapo lusearch test on EC2 host with 96 CPU cores:
>> Openjdk TIP:
>> 
>> [ec2-user at ip-172-31-42-91 jdk]$ ./master-jdk/bin/java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms4G -Xmx4G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions  -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational  -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar  -n 10 lusearch  | grep "metered full smoothing"
>> ===== DaCapo tail latency, metered full smoothing: 50% 131684 usec, 90% 200192 usec, 99% 211369 usec, 99.9% 212517 usec, 99.99% 213043 usec, max 235289 usec, measured over 524288 events =====
>> ===== DaCapo tail latency, metered full smoothing: 50% 1568 usec, 90% 36101 usec, 99% 42172 usec, 99.9% 42928 usec, 99.99% 43100 usec, max 43305 usec, measured over 524288 events =====
>> ===== DaCapo tail latency, metered full smoothing: 50% 52644 usec, 90% 124393 usec, 99% 137711 usec, 99.9% 139355 usec, 99.99% 139749 usec, max 146722 ...
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 246:
> 
>> 244:   _leftmosts_empty[int(ShenandoahFreeSetPartitionId::Mutator)] = mutator_leftmost_empty;
>> 245:   _rightmosts_empty[int(ShenandoahFreeSetPartitionId::Mutator)] = mutator_rightmost_empty;
>> 246: 
> 
> We have the heap lock here, so should not need to use atomic store operations.  Atomic operations have a performance penalty that I think we want to avoid.

Yes, we do have heap lock. But mutator may also update the used/available after allocation w/o heap lock, so the update for mutator partition need to be done with atomic operation, but not all of them. 

I'll revisit this part and remove the atomic operations which are not needed.

> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 247:
> 
>> 245:   _rightmosts_empty[int(ShenandoahFreeSetPartitionId::Mutator)] = mutator_rightmost_empty;
>> 246: 
>> 247:   Atomic::store(_region_counts + int(ShenandoahFreeSetPartitionId::Mutator), mutator_region_count);
> 
> If we do need to use Atomic operations, would prefer &_region_counts[int(ShenandoahFreeSetPartitionId::Mutator)] notation for the array elements.

It make sense, I'll update it,  `[]` operation for array always has boundary check.

> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 282:
> 
>> 280: 
>> 281: void ShenandoahRegionPartitions::increase_used(ShenandoahFreeSetPartitionId which_partition, size_t bytes) {
>> 282:   shenandoah_assert_heaplocked();
> 
> Are you now calling this directly from the CAS allocators?  So you want to not have to assert heap locked and that is why we make the used accounting atomic?
> 
> My preference would be to avoid this need by counting the entire region as used at the time the region becomes directly allocatable.

Yes, we increase used after CAS allocation, so it can be called w/o lock.

I'll revisit it along with the the comments you have above, if we count the entire region as used when we reserve a region for direct allocation, this change can be removed.

> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 2151:
> 
>> 2149: 
>> 2150: template<bool IS_TLAB>
>> 2151: HeapWord* ShenandoahFreeSet::par_allocate_single_for_mutator(ShenandoahAllocRequest &req, bool &in_new_region) {
> 
> Not clear to me what prefix par_ represents.  Parallel allocate (without lock?)

Yes.
The name is a bit confusing, what about `try_allocate_single_for_mutator`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2198891380
PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2198896336
PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2198902300
PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2198905623

From xpeng at openjdk.org  Mon Sep 22 08:46:43 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Mon, 22 Sep 2025 08:46:43 GMT
Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using
 CAS for memory allocation
In-Reply-To: <IRgMbTQIV2pGn3OdOYj152mrizMTEYzKnLXcPmgeALs=.7a088a6d-1fef-4c1c-8a6c-753116b461e8@github.com>
References: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
 <JgNk3o87C6Lz5xtmuAclB83IDkW5fQYHZAxQh-Kv-yY=.590627c9-ebd9-4081-b4f3-f9b0d3339cab@github.com>
 <IRgMbTQIV2pGn3OdOYj152mrizMTEYzKnLXcPmgeALs=.7a088a6d-1fef-4c1c-8a6c-753116b461e8@github.com>
Message-ID: <B-JnC37YJrwIZVBJcqKUNC8oEoFTYJxfbOjOkni--HY=.34fdc8ee-5e3f-457d-a198-519722585fdf@github.com>

On Thu, 10 Jul 2025 22:34:27 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 282:
>> 
>>> 280: 
>>> 281: void ShenandoahRegionPartitions::increase_used(ShenandoahFreeSetPartitionId which_partition, size_t bytes) {
>>> 282:   shenandoah_assert_heaplocked();
>> 
>> Are you now calling this directly from the CAS allocators?  So you want to not have to assert heap locked and that is why we make the used accounting atomic?
>> 
>> My preference would be to avoid this need by counting the entire region as used at the time the region becomes directly allocatable.
>
> Yes, we increase used after CAS allocation, so it can be called w/o lock.
> 
> I'll revisit it along with the the comments you have above, if we count the entire region as used when we reserve a region for direct allocation, this change can be removed.

I have changed it to the approach as you suggested, now it count the entire region as used at the time the region becomes directly allocatable.

>> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 2151:
>> 
>>> 2149: 
>>> 2150: template<bool IS_TLAB>
>>> 2151: HeapWord* ShenandoahFreeSet::par_allocate_single_for_mutator(ShenandoahAllocRequest &req, bool &in_new_region) {
>> 
>> Not clear to me what prefix par_ represents.  Parallel allocate (without lock?)
>
> Yes.
> The name is a bit confusing, what about `try_allocate_single_for_mutator`?

Technically not completely without lock, it may take lock when there is need to retire and refill new directly allocatable regions.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2202219473
PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2198908091

From kdnilsen at openjdk.org  Mon Sep 22 19:13:41 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 22 Sep 2025 19:13:41 GMT
Subject: RFR: 8368015: Shenandoah: fix error in computation of average
 allocation rate [v2]
In-Reply-To: <gvhZ5s4LMcR4NQDCICvZZKtQgtNzL5wbl7hhG-j6cf8=.207310b9-3c82-4b69-9446-25f91061d7cc@github.com>
References: <gvhZ5s4LMcR4NQDCICvZZKtQgtNzL5wbl7hhG-j6cf8=.207310b9-3c82-4b69-9446-25f91061d7cc@github.com>
Message-ID: <yRB_ZOWhuRXEdibuOrz13mgjZoFwRlsNxk_LAWG-m5g=.24e7b2df-b599-4f36-b63b-a48208011bca@github.com>

> We use bytes_allocated_since_gc_start() to compute allocation rates.  This leaves a blind spot, as our current implementation ignores allocations and the time period between the moment we begin GC and the first time we update the allocation rate following the start of GC.  When this happens, we typically find that the sampled number of allocations is smaller than the allocations that had accumulated by the time we triggered the start of the current GC cycle.
> 
> This PR adds tracking for that accounting gap.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  remove state variable previous GC allocated

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27398/files
  - new: https://git.openjdk.org/jdk/pull/27398/files/2ea7e50a..2e422421

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27398&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27398&range=00-01

  Stats: 69 lines in 7 files changed: 40 ins; 15 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/27398.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27398/head:pull/27398

PR: https://git.openjdk.org/jdk/pull/27398

From kdnilsen at openjdk.org  Mon Sep 22 20:42:06 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 22 Sep 2025 20:42:06 GMT
Subject: RFR: 8368015: Shenandoah: fix error in computation of average
 allocation rate [v2]
In-Reply-To: <yRB_ZOWhuRXEdibuOrz13mgjZoFwRlsNxk_LAWG-m5g=.24e7b2df-b599-4f36-b63b-a48208011bca@github.com>
References: <gvhZ5s4LMcR4NQDCICvZZKtQgtNzL5wbl7hhG-j6cf8=.207310b9-3c82-4b69-9446-25f91061d7cc@github.com>
 <yRB_ZOWhuRXEdibuOrz13mgjZoFwRlsNxk_LAWG-m5g=.24e7b2df-b599-4f36-b63b-a48208011bca@github.com>
Message-ID: <1zWphYBRePzvVFEF3lnsQM0-8vif-l7mp-G_i5eYKEE=.37087053-f4e9-4200-b472-b91767d164ae@github.com>

On Mon, 22 Sep 2025 19:13:41 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> We use bytes_allocated_since_gc_start() to compute allocation rates.  This leaves a blind spot, as our current implementation ignores allocations and the time period between the moment we begin GC and the first time we update the allocation rate following the start of GC.  When this happens, we typically find that the sampled number of allocations is smaller than the allocations that had accumulated by the time we triggered the start of the current GC cycle.
>> 
>> This PR adds tracking for that accounting gap.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove state variable previous GC allocated

I've refactored the code to get rid of the unnecessary state variable: _previous_gc_allocated.  I accomplished by forcing a sample to be taken at the moment we begin GC.  I found that the initial implementation of this change caused unruly behavior because sometimes the allocation data collected between the moment previous sample was taken and the the start of the subsequent GC is too short, and the calculated allocation rate is consequentially too noisy.

The "fix" for this problem is to not force the allocation rate sample if this time is less than 2 ms in duration.  When we ignore the "forced sample request", we treat the "ignored" allocations as if they had been performed after the start of this GC cycle.  Here is the performance of this PR compared to baseline from 8/28 on an Extremem workload with 31 GB heap size.

<img width="2021" height="449" alt="image" src="https://github.com/user-attachments/assets/ca1d5d05-20c3-4e48-89be-51d836dbdf34" />

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27398#issuecomment-3321410934

From wkemper at openjdk.org  Mon Sep 22 23:13:01 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 22 Sep 2025 23:13:01 GMT
Subject: RFR: 8368015: Shenandoah: fix error in computation of average
 allocation rate [v2]
In-Reply-To: <yRB_ZOWhuRXEdibuOrz13mgjZoFwRlsNxk_LAWG-m5g=.24e7b2df-b599-4f36-b63b-a48208011bca@github.com>
References: <gvhZ5s4LMcR4NQDCICvZZKtQgtNzL5wbl7hhG-j6cf8=.207310b9-3c82-4b69-9446-25f91061d7cc@github.com>
 <yRB_ZOWhuRXEdibuOrz13mgjZoFwRlsNxk_LAWG-m5g=.24e7b2df-b599-4f36-b63b-a48208011bca@github.com>
Message-ID: <D__vnhYc-3eaale_ze97YsNy4CusX5rjT_7Tu8K1kmc=.8d780025-a9a6-41f7-b20f-00ecdaeebb01@github.com>

On Mon, 22 Sep 2025 19:13:41 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> We use bytes_allocated_since_gc_start() to compute allocation rates.  This leaves a blind spot, as our current implementation ignores allocations and the time period between the moment we begin GC and the first time we update the allocation rate following the start of GC.  When this happens, we typically find that the sampled number of allocations is smaller than the allocations that had accumulated by the time we triggered the start of the current GC cycle.
>> 
>> This PR adds tracking for that accounting gap.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove state variable previous GC allocated

Should we move [this line](https://github.com/openjdk/jdk/pull/27398/files#diff-5cbba824b4e4b914425672f0d1bea49b44aa48940fd07f517b7312055927c575R249) where we take the allocation sample above the early exit when `_start_gc_is_pending`? Not directly related to this PR, but seems to be in the spirit of making the allocation rate sampling more accurate.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 364:

> 362: 
> 363: double ShenandoahAllocationRate::force_sample(size_t allocated, size_t &unaccounted_bytes_allocated) {
> 364:   const double MinSampleTime = 0.002;    // Do not sample if time since last update is less than 2 ms

Would it make sense to "carry over" the `unaccounted_bytes_allocated` if, at the time of reset, the last sample was taken less than `ShenandoahAllocationRate::_interval_sec` (instead of `MinSampleTime`)? I believe this would result in more samples being carried over.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 382:

> 380: }
> 381: 
> 382: double ShenandoahAllocationRate::sample(size_t allocated, bool force_update) {

`force_update` looks unused here.

-------------

Changes requested by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27398#pullrequestreview-3255437150
PR Review Comment: https://git.openjdk.org/jdk/pull/27398#discussion_r2370548105
PR Review Comment: https://git.openjdk.org/jdk/pull/27398#discussion_r2370489243

From kdnilsen at openjdk.org  Tue Sep 23 14:51:28 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 23 Sep 2025 14:51:28 GMT
Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need
 accurate live_data [v9]
In-Reply-To: <8GvpkoZ5-Pso8XG-AKeR0QnlBQr0op9E-lvQMS12lTI=.6c88343d-4c74-4f29-a528-f499f559a2bd@github.com>
References: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
 <8GvpkoZ5-Pso8XG-AKeR0QnlBQr0op9E-lvQMS12lTI=.6c88343d-4c74-4f29-a528-f499f559a2bd@github.com>
Message-ID: <UwPJbn6Ub3nthby4SBwpj14azOkHrL2hS_OZaXCSMgM=.de22c315-fb7c-4c6d-bf37-fc993d70ddc8@github.com>

On Tue, 16 Sep 2025 21:29:34 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected.  In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region.  This is typically ok for young regions, where the amount of live data determines whether a region should be added to the collection set during the final-mark safepoint.
>> 
>> However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated.  In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended.
>> 
>> This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation errors after merge

CI data collected over several days of runs shows slight improvement or neutral impact on metrics:

Sept. 16, 2025:

   Control: openjdk-master-aarch64
Experiment: fix-live-data-for-mixed-evac-candidates-gh-aarch64


Genshen
-------------------------------------------------------------------------------------------------------
-19.76% kafka/dacapo_simple_latency_min p=0.00321
  Control:    478.000us (+/- 66.09us)         70
  Test:       399.125us (+/- 96.26us)         10

-12.10% avrora/shenandoahinitmark_stopped p=0.00001
  Control:      0.052ms (+/-  0.01ms)        296
  Test:         0.047ms (+/-  0.01ms)         44

-11.57% specjbb2015_weak_ref_patch/prepare_young p=0.00012
  Control:      1.602ms (+/-107.15us)         45
  Test:         1.436ms (+/- 97.24us)          6

-11.15% specjbb2015_weak_ref_patch/update_roots_young p=0.00021
  Control:      1.559ms (+/-106.96us)         45
  Test:         1.403ms (+/- 95.82us)          6


Shenandoah
-------------------------------------------------------------------------------------------------------
-15.40% serial/cleanclassloaderdatametaspaces_stopped p=0.00236
  Control:      0.110ms (+/-  0.01ms)         70
  Test:         0.096ms (+/-  0.01ms)         10

Sept. 18, 2025:

   Control: openjdk-master-aarch64
Experiment: fix-live-data-for-mixed-evac-candidates-gh-aarch64


Genshen
-------------------------------------------------------------------------------------------------------
-54.93% reactors/shenandoah_old_gen_used p=0.00069
  Control: 7168817.375   (+/-2595408.39  )         80
  Test:    4627212.500   (+/-1664542.48  )         20

-16.67% dotty/shenandoah_old_gen_used p=0.00325
  Control: 16102164.875   (+/-2840080.53  )         80
  Test:    13801402.000   (+/-2233823.94  )         20

-12.42% specjbb2015_weak_ref_patch/fu_thread_roots_young p=0.00088
  Control:      1.649ms (+/-177.28us)         50
  Test:         1.467ms (+/-157.40us)         13

-11.12% kafka/dacapo_simple_latency_min p=0.00435
  Control:    483.453us (+/- 58.27us)         80
  Test:       435.062us (+/- 82.07us)         20


Shenandoah
-------------------------------------------------------------------------------------------------------
-13.50% serial/cleanclassloaderdatametaspaces_stopped p=0.00023
  Control:      0.111ms (+/-  0.01ms)         80
  Test:         0.098ms (+/-  0.01ms)         20


Sept. 19, 2025:

   Control: openjdk-master-x86_64
Experiment: fix-live-data-for-mixed-evac-candidates-gh-x86


Genshen
-------------------------------------------------------------------------------------------------------
+22.88% spring/dacapo_metered_latency_max p=0.00553
  Control:     57.031ms (+/- 17.50ms)        100
  Test:        70.081ms (+/- 14.02ms)         20

-60.91% reactors/shenandoah_old_gen_used p=0.00002
  Control: 7445668.600   (+/-2417060.62  )        100
  Test:    4627212.500   (+/-1664542.48  )         20

-16.80% dotty/shenandoah_old_gen_used p=0.00223
  Control: 16119749.300   (+/-2805728.19  )        100
  Test:    13801402.000   (+/-2233823.94  )         20

-11.45% specjbb2015_weak_ref_patch/fu_thread_roots_young p=0.00026
  Control:      1.635ms (+/-159.88us)         75
  Test:         1.467ms (+/-157.40us)         13


Shenandoah
-------------------------------------------------------------------------------------------------------
-13.07% serial/cleanclassloaderdatametaspaces_stopped p=0.00029
  Control:      0.110ms (+/-  0.01ms)        100
  Test:         0.098ms (+/-  0.01ms)         20

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24319#issuecomment-3324353923

From kdnilsen at openjdk.org  Tue Sep 23 15:03:22 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 23 Sep 2025 15:03:22 GMT
Subject: RFR: 8368015: Shenandoah: fix error in computation of average
 allocation rate [v2]
In-Reply-To: <D__vnhYc-3eaale_ze97YsNy4CusX5rjT_7Tu8K1kmc=.8d780025-a9a6-41f7-b20f-00ecdaeebb01@github.com>
References: <gvhZ5s4LMcR4NQDCICvZZKtQgtNzL5wbl7hhG-j6cf8=.207310b9-3c82-4b69-9446-25f91061d7cc@github.com>
 <yRB_ZOWhuRXEdibuOrz13mgjZoFwRlsNxk_LAWG-m5g=.24e7b2df-b599-4f36-b63b-a48208011bca@github.com>
 <D__vnhYc-3eaale_ze97YsNy4CusX5rjT_7Tu8K1kmc=.8d780025-a9a6-41f7-b20f-00ecdaeebb01@github.com>
Message-ID: <mFbRbUp5bNDmDKKJavc47ikT7FffaBZYXBxE3rAYURM=.ae723df4-a4d4-4206-abf3-e0eed9f91332@github.com>

On Mon, 22 Sep 2025 23:10:07 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Should we move [this line](https://github.com/openjdk/jdk/pull/27398/files#diff-5cbba824b4e4b914425672f0d1bea49b44aa48940fd07f517b7312055927c575R249) 
> where we take the allocation sample above the early exit when `_start_gc_is_pending`? 
> Not directly related to this PR, but seems to be in the spirit of making the allocation rate sampling more accurate.

That's a good suggestion.  I'll move it.

> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 382:
> 
>> 380: }
>> 381: 
>> 382: double ShenandoahAllocationRate::sample(size_t allocated, bool force_update) {
> 
> `force_update` looks unused here.

Thanks for that catch.  I failed to clean up my mess after an earlier experiment that didn't work...  Fixed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27398#issuecomment-3324386185
PR Review Comment: https://git.openjdk.org/jdk/pull/27398#discussion_r2372626061

From kdnilsen at openjdk.org  Tue Sep 23 15:03:25 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 23 Sep 2025 15:03:25 GMT
Subject: RFR: 8368015: Shenandoah: fix error in computation of average
 allocation rate [v2]
In-Reply-To: <yRB_ZOWhuRXEdibuOrz13mgjZoFwRlsNxk_LAWG-m5g=.24e7b2df-b599-4f36-b63b-a48208011bca@github.com>
References: <gvhZ5s4LMcR4NQDCICvZZKtQgtNzL5wbl7hhG-j6cf8=.207310b9-3c82-4b69-9446-25f91061d7cc@github.com>
 <yRB_ZOWhuRXEdibuOrz13mgjZoFwRlsNxk_LAWG-m5g=.24e7b2df-b599-4f36-b63b-a48208011bca@github.com>
Message-ID: <Hruw8nh-TGP7mKPnWNIj4QTlVNQ4x-eok0T27EBx5f4=.786c57c2-9c15-4964-bdf6-773a7c54ffb5@github.com>

On Mon, 22 Sep 2025 19:13:41 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> We use bytes_allocated_since_gc_start() to compute allocation rates.  This leaves a blind spot, as our current implementation ignores allocations and the time period between the moment we begin GC and the first time we update the allocation rate following the start of GC.  When this happens, we typically find that the sampled number of allocations is smaller than the allocations that had accumulated by the time we triggered the start of the current GC cycle.
>> 
>> This PR adds tracking for that accounting gap.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove state variable previous GC allocated

I've also run current baseline tests for comparison with this branch.  Here are the results:

<img width="2014" height="436" alt="image" src="https://github.com/user-attachments/assets/1c710552-b942-4409-b6e6-f99bc63130a3" />

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27398#issuecomment-3324392518

From kdnilsen at openjdk.org  Tue Sep 23 15:20:16 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 23 Sep 2025 15:20:16 GMT
Subject: RFR: 8368015: Shenandoah: fix error in computation of average
 allocation rate [v3]
In-Reply-To: <gvhZ5s4LMcR4NQDCICvZZKtQgtNzL5wbl7hhG-j6cf8=.207310b9-3c82-4b69-9446-25f91061d7cc@github.com>
References: <gvhZ5s4LMcR4NQDCICvZZKtQgtNzL5wbl7hhG-j6cf8=.207310b9-3c82-4b69-9446-25f91061d7cc@github.com>
Message-ID: <zocUuhJ-PsA_JgNXsponLVKOP14zOIMMeNRnE2ZkWRw=.057560eb-ef68-4c7e-ab60-bed647ef1b6c@github.com>

> We use bytes_allocated_since_gc_start() to compute allocation rates.  This leaves a blind spot, as our current implementation ignores allocations and the time period between the moment we begin GC and the first time we update the allocation rate following the start of GC.  When this happens, we typically find that the sampled number of allocations is smaller than the allocations that had accumulated by the time we triggered the start of the current GC cycle.
> 
> This PR adds tracking for that accounting gap.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  reviewer feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27398/files
  - new: https://git.openjdk.org/jdk/pull/27398/files/2e422421..bd7448ad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27398&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27398&range=01-02

  Stats: 7 lines in 2 files changed: 3 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27398.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27398/head:pull/27398

PR: https://git.openjdk.org/jdk/pull/27398

From kdnilsen at openjdk.org  Tue Sep 23 15:41:13 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 23 Sep 2025 15:41:13 GMT
Subject: RFR: 8368015: Shenandoah: fix error in computation of average
 allocation rate [v2]
In-Reply-To: <D__vnhYc-3eaale_ze97YsNy4CusX5rjT_7Tu8K1kmc=.8d780025-a9a6-41f7-b20f-00ecdaeebb01@github.com>
References: <gvhZ5s4LMcR4NQDCICvZZKtQgtNzL5wbl7hhG-j6cf8=.207310b9-3c82-4b69-9446-25f91061d7cc@github.com>
 <yRB_ZOWhuRXEdibuOrz13mgjZoFwRlsNxk_LAWG-m5g=.24e7b2df-b599-4f36-b63b-a48208011bca@github.com>
 <D__vnhYc-3eaale_ze97YsNy4CusX5rjT_7Tu8K1kmc=.8d780025-a9a6-41f7-b20f-00ecdaeebb01@github.com>
Message-ID: <LVzpyZ3B0TsKlNE1hXCH2-tQdwRuv9xv_xayKqYv-wM=.768ea66b-9c9a-434a-be9a-c107c2452180@github.com>

On Mon, 22 Sep 2025 23:07:16 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove state variable previous GC allocated
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 364:
> 
>> 362: 
>> 363: double ShenandoahAllocationRate::force_sample(size_t allocated, size_t &unaccounted_bytes_allocated) {
>> 364:   const double MinSampleTime = 0.002;    // Do not sample if time since last update is less than 2 ms
> 
> Would it make sense to "carry over" the `unaccounted_bytes_allocated` if, at the time of reset, the last sample was taken less than `ShenandoahAllocationRate::_interval_sec` (instead of `MinSampleTime`)? I believe this would result in more samples being carried over.

I've done experiments with a variety of	different values for MinSampleTime (e.g. 50 ms, 25ms, 2 ms).  I	find that any value
greater	than 1 ms works	pretty well in the sense that the measured rate	is pretty consistent with the average rate as computed
by the preexisting mechanisms.

The biggest problem I observed was when	we tried to measure rate over an interval of a few microseconds, and these intervals
sometimes had zero allocations.

We could make the change you suggest, but that would actually result in	fewer samples rather than more.	 It would also make
the value of bytes_allocated_since_gc_start() less precise in that this quantity	would carry up to 100 ms of allocations	that
actually occurred before the start of the current GC.

Here's an ASCII art attempt to illustrate how it works	in the current implementation.

Here is	a timeline with	a tick mark to illustrate the desired sample time, every	100 ms:


      	 .1s  	   .2s	     .3s       .4s.     .5s  	   .6s	     .7s       .8s.    .9s  	   1s	      1.1s      1.2s
|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---
      	       ^      	      	      	      	    	      	      	      	      	      	       ^
Existing       |                                                                                       |
Samples:  A    B                                                                                       C      	 D         E
               |                                                                                       |
Proposed       |                                                                                       |
Samples:  A    |                                                                                       B      	 C    	   D
               |                                                                                       |
               |                                                                                       |
      	       Trigger GC at 0.14s    	      	      	      	      	      	      	      	       Finish GC at 1.03s

In either approach, we sample at 0.1s and this sample contributes to the average allocation rate that causes us	to trigger at
time 0.14s.  In	the current implementation, at time 0.14s, we take a new sample	representing the most current allocation rate
as computed over the span between 0.1s and 0.14s.  As implemented, if this time	delta (0.14s minus 0.10s =0.04s) is less than
2 ms, we'll skip sample	B.  I think you	are proposing that we skip sample B whenever this delta	is less	than 100 ms
 (_interval_sec).

We do not sample during	GC.  As	soon as	GC finishes, we	begin asking the question, should I start another GC.  This resumes the
sampling activity, aligning the	periodic samples on the	time at	which we finished previous GC cycle.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27398#discussion_r2372740860

From wkemper at openjdk.org  Tue Sep 23 20:07:37 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 23 Sep 2025 20:07:37 GMT
Subject: RFR: 8368152: Shenandoah: Incorrect behavior at end of degenerated
 cycle
Message-ID: <k9XN2LBBWOARhNt9yqK5sLX5u7HO4fMqL-rz4w3oQYo=.77b0c7a4-9b5b-49e1-832b-e1e628f0a4ea@github.com>

There are several issues addressed in this PR:
* Shenandoah always ran a full GC after any degenerated cycle
* The number of consecutive degenerated GCs with bad progress was reset for every degenerated cycle
* Good progress was reported in generational mode even when no progress is made

-------------

Commit messages:
 - Improve documentation, add unit test
 - Fix logic for handling degenerated cycles that do not make good progress

Changes: https://git.openjdk.org/jdk/pull/27456/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27456&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368152
  Stats: 123 lines in 5 files changed: 101 ins; 9 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/27456.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27456/head:pull/27456

PR: https://git.openjdk.org/jdk/pull/27456

From wkemper at openjdk.org  Tue Sep 23 21:13:27 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 23 Sep 2025 21:13:27 GMT
Subject: RFR: 8368152: Shenandoah: Incorrect behavior at end of degenerated
 cycle [v2]
In-Reply-To: <k9XN2LBBWOARhNt9yqK5sLX5u7HO4fMqL-rz4w3oQYo=.77b0c7a4-9b5b-49e1-832b-e1e628f0a4ea@github.com>
References: <k9XN2LBBWOARhNt9yqK5sLX5u7HO4fMqL-rz4w3oQYo=.77b0c7a4-9b5b-49e1-832b-e1e628f0a4ea@github.com>
Message-ID: <mq3qex_9eSm22ReOJdOLkik2r2ad2USr4eSoVkCPShY=.2f0a937f-cf5c-4adc-821d-245e005c249e@github.com>

> There are several issues addressed in this PR:
> * Shenandoah always ran a full GC after any degenerated cycle
> * The number of consecutive degenerated GCs with bad progress was reset for every degenerated cycle
> * Good progress was reported in generational mode even when no progress is made

William Kemper has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo in comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27456/files
  - new: https://git.openjdk.org/jdk/pull/27456/files/f5aa7b13..c962f198

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27456&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27456&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27456.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27456/head:pull/27456

PR: https://git.openjdk.org/jdk/pull/27456

From wkemper at openjdk.org  Tue Sep 23 21:13:30 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 23 Sep 2025 21:13:30 GMT
Subject: RFR: 8368152: Shenandoah: Incorrect behavior at end of degenerated
 cycle
In-Reply-To: <k9XN2LBBWOARhNt9yqK5sLX5u7HO4fMqL-rz4w3oQYo=.77b0c7a4-9b5b-49e1-832b-e1e628f0a4ea@github.com>
References: <k9XN2LBBWOARhNt9yqK5sLX5u7HO4fMqL-rz4w3oQYo=.77b0c7a4-9b5b-49e1-832b-e1e628f0a4ea@github.com>
Message-ID: <G9CNPA8sP6lJ9AiFaZZe-uvlRZU3yF2Lc3_Azc5rjb4=.7d1ed422-d25d-414d-9031-56a221d1a6b5@github.com>

On Tue, 23 Sep 2025 19:59:05 GMT, William Kemper <wkemper at openjdk.org> wrote:

> There are several issues addressed in this PR:
> * Shenandoah always ran a full GC after any degenerated cycle
> * The number of consecutive degenerated GCs with bad progress was reset for every degenerated cycle
> * Good progress was reported in generational mode even when no progress is made

There is a comment in `shDegeneratedGC` explaining this scenario. I'll move it to `shCollectorPolicy`. I didn't quite understand why single-gen mode would not benefit equally from this reasoning, but I tried to preserve the original intended behavior.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27456#issuecomment-3325562835

From kdnilsen at openjdk.org  Tue Sep 23 21:13:28 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 23 Sep 2025 21:13:28 GMT
Subject: RFR: 8368152: Shenandoah: Incorrect behavior at end of degenerated
 cycle [v2]
In-Reply-To: <mq3qex_9eSm22ReOJdOLkik2r2ad2USr4eSoVkCPShY=.2f0a937f-cf5c-4adc-821d-245e005c249e@github.com>
References: <k9XN2LBBWOARhNt9yqK5sLX5u7HO4fMqL-rz4w3oQYo=.77b0c7a4-9b5b-49e1-832b-e1e628f0a4ea@github.com>
 <mq3qex_9eSm22ReOJdOLkik2r2ad2USr4eSoVkCPShY=.2f0a937f-cf5c-4adc-821d-245e005c249e@github.com>
Message-ID: <EFkrbaCj5FqorYjIewrBzVt-SZJaSbJEfSuhakqPWOo=.51e54c9b-c633-47e4-bcb0-deeba61f5bd6@github.com>

On Tue, 23 Sep 2025 21:10:11 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> There are several issues addressed in this PR:
>> * Shenandoah always ran a full GC after any degenerated cycle
>> * The number of consecutive degenerated GCs with bad progress was reset for every degenerated cycle
>> * Good progress was reported in generational mode even when no progress is made
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in comment

A common scenario that I have seen in various GC logs is the following:
1. Concurrent GC experiences allocation failure and degenerates
2. Degenerated GC fails to make progress because lots of garbage was allocated after the start of concurrent marking (ie. all garbage is floating)
3. We escalate to Full GC, resulting in a very long STW delay (The Full GC delay plus the delay for degen that preceded Full GC)
4. It is often the case that better throughput and better latency is realized if we run a concurrent GC which may once again degenerate, rather than escalating from the first degen to Full GC. All of the floating garbage that was locked up during the previous GC should be reclaimed by the second concurrent (possibly degenerated) GC, so the second cycle should have "good progress" even if the first did not.
5. I believe the solution you've implemented here will first try a second concurrent/degenerated cycle before escalating to Full GC.  Will you confirm that?

Should we have some comments in this code to explain why CONSECUTIVE_BAD_DEGEN_PROGRESS_THRESHOLD is 2 and not 1?

-------------

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27456#pullrequestreview-3259587644

From wkemper at openjdk.org  Tue Sep 23 21:24:20 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 23 Sep 2025 21:24:20 GMT
Subject: RFR: 8368152: Shenandoah: Incorrect behavior at end of degenerated
 cycle [v3]
In-Reply-To: <k9XN2LBBWOARhNt9yqK5sLX5u7HO4fMqL-rz4w3oQYo=.77b0c7a4-9b5b-49e1-832b-e1e628f0a4ea@github.com>
References: <k9XN2LBBWOARhNt9yqK5sLX5u7HO4fMqL-rz4w3oQYo=.77b0c7a4-9b5b-49e1-832b-e1e628f0a4ea@github.com>
Message-ID: <gqZC71GibHHzmN5aPBEqYI-TKxEARk6CK6gmrTKbBjA=.acfbdc1c-2476-4369-ba0f-b047554ec4c4@github.com>

> There are several issues addressed in this PR:
> * Shenandoah always ran a full GC after any degenerated cycle
> * The number of consecutive degenerated GCs with bad progress was reset for every degenerated cycle
> * Good progress was reported in generational mode even when no progress is made

William Kemper has updated the pull request incrementally with one additional commit since the last revision:

  Improve comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27456/files
  - new: https://git.openjdk.org/jdk/pull/27456/files/c962f198..2324450a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27456&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27456&range=01-02

  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27456.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27456/head:pull/27456

PR: https://git.openjdk.org/jdk/pull/27456

From ysr at openjdk.org  Tue Sep 23 22:05:28 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 23 Sep 2025 22:05:28 GMT
Subject: RFR: 8368152: Shenandoah: Incorrect behavior at end of degenerated
 cycle [v3]
In-Reply-To: <gqZC71GibHHzmN5aPBEqYI-TKxEARk6CK6gmrTKbBjA=.acfbdc1c-2476-4369-ba0f-b047554ec4c4@github.com>
References: <k9XN2LBBWOARhNt9yqK5sLX5u7HO4fMqL-rz4w3oQYo=.77b0c7a4-9b5b-49e1-832b-e1e628f0a4ea@github.com>
 <gqZC71GibHHzmN5aPBEqYI-TKxEARk6CK6gmrTKbBjA=.acfbdc1c-2476-4369-ba0f-b047554ec4c4@github.com>
Message-ID: <ocmjgciBCj1Sz7BaKCIrRoERAalALV9WEiMy0gPUlrk=.c6840210-d455-4073-b19a-e2815918253f@github.com>

On Tue, 23 Sep 2025 21:24:20 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> There are several issues addressed in this PR:
>> * Shenandoah always ran a full GC after any degenerated cycle
>> * The number of consecutive degenerated GCs with bad progress was reset for every degenerated cycle
>> * Good progress was reported in generational mode even when no progress is made
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comment

Looks good; left some documentation nits, but approved even if the documentation suggestions aren't taken.

?

src/hotspot/share/gc/shenandoah/shenandoahCollectorPolicy.hpp line 68:

> 66:   // in generational mode, run a full GC. Non-generational modes will upgrade
> 67:   // immediately when a degenerated cycle does not make progress. Many degenerated
> 68:   // cycles are caused by floating garbage. It is more efficient to attempt

If it's used only for generational case, I'd like the comment to be less coy about it. I'd place `GENERATIONAL` or some such in the name of the constant, e.g. `GENERATIONAL_TO_FULL_NON_PROGRESSING_DEGENS`,  and its "accessor" (or user) down in `should_upgrade_degenerated_gc()` to, e.g., `generational_should_upgrade_degen_to_full()`.

The comment could say:


// When a degenerated cycle doesn't make progress:
// a. for the non-generational case, we'll immediately upgrade to full at the first non-progressing degen
// b. for the generational case, we'll upgrade to full after these many non-progressing consecutive degens


My question is why we choose this number for genshen. May be a sentence in the ticket or in the comments on the intuition here?

src/hotspot/share/gc/shenandoah/shenandoahCollectorPolicy.hpp line 117:

> 115:   // Genshen will only upgrade to a full gc after the configured number of futile degenerated cycles.
> 116:   bool should_upgrade_degenerated_gc() const {
> 117:     return _consecutive_degenerated_gcs_without_progress >= CONSECUTIVE_BAD_DEGEN_PROGRESS_THRESHOLD;

assert that heap is generational? See previous comment above at line 68.

src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp line 323:

> 321:   // Shenandoah to avoid introducing "surprising new behavior."  It also makes less sense with non-generational
> 322:   // Shenandoah to replace a full GC with a degenerated GC, because both have similar pause times in non-generational
> 323:   // mode.

May be, based on the first paragraph above, you want to say more simply (replacing the entire second paragraph):

On the other hand, in non-generational mode,
to both preserve legacy behavior, and because the
difference between a degenerated gc and full gc is smaller,
we immediately escalate to
a full gc following the first degenerated cycle that doesn't make progress.


I'd also move this comment out from here and to the constant that was defined for the number of consecutive degens before escalating to full in generational mode.

-------------

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27456#pullrequestreview-3259658651
PR Review Comment: https://git.openjdk.org/jdk/pull/27456#discussion_r2373504315
PR Review Comment: https://git.openjdk.org/jdk/pull/27456#discussion_r2373507843
PR Review Comment: https://git.openjdk.org/jdk/pull/27456#discussion_r2373546896

From ysr at openjdk.org  Tue Sep 23 22:05:29 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 23 Sep 2025 22:05:29 GMT
Subject: RFR: 8368152: Shenandoah: Incorrect behavior at end of degenerated
 cycle [v3]
In-Reply-To: <ocmjgciBCj1Sz7BaKCIrRoERAalALV9WEiMy0gPUlrk=.c6840210-d455-4073-b19a-e2815918253f@github.com>
References: <k9XN2LBBWOARhNt9yqK5sLX5u7HO4fMqL-rz4w3oQYo=.77b0c7a4-9b5b-49e1-832b-e1e628f0a4ea@github.com>
 <gqZC71GibHHzmN5aPBEqYI-TKxEARk6CK6gmrTKbBjA=.acfbdc1c-2476-4369-ba0f-b047554ec4c4@github.com>
 <ocmjgciBCj1Sz7BaKCIrRoERAalALV9WEiMy0gPUlrk=.c6840210-d455-4073-b19a-e2815918253f@github.com>
Message-ID: <4d3hrqqqX8Dxl474hJ6fA2aCQclSHCMPao2tHdcXVx0=.06c86e17-aa98-4c55-88a9-74573b26dad6@github.com>

On Tue, 23 Sep 2025 21:31:40 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve comment
>
> src/hotspot/share/gc/shenandoah/shenandoahCollectorPolicy.hpp line 68:
> 
>> 66:   // in generational mode, run a full GC. Non-generational modes will upgrade
>> 67:   // immediately when a degenerated cycle does not make progress. Many degenerated
>> 68:   // cycles are caused by floating garbage. It is more efficient to attempt
> 
> If it's used only for generational case, I'd like the comment to be less coy about it. I'd place `GENERATIONAL` or some such in the name of the constant, e.g. `GENERATIONAL_TO_FULL_NON_PROGRESSING_DEGENS`,  and its "accessor" (or user) down in `should_upgrade_degenerated_gc()` to, e.g., `generational_should_upgrade_degen_to_full()`.
> 
> The comment could say:
> 
> 
> // When a degenerated cycle doesn't make progress:
> // a. for the non-generational case, we'll immediately upgrade to full at the first non-progressing degen
> // b. for the generational case, we'll upgrade to full after these many non-progressing consecutive degens
> 
> 
> My question is why we choose this number for genshen. May be a sentence in the ticket or in the comments on the intuition here?

Noticed the long comment at lines 313-323 in `ShenandoahDegenGC::collect()` that describes why. May be move that comment (made suitably more succinct) to this place also to tie it all together in one place.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27456#discussion_r2373551052

From kdnilsen at openjdk.org  Tue Sep 23 22:17:33 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 23 Sep 2025 22:17:33 GMT
Subject: RFR: 8368015: Shenandoah: fix error in computation of average
 allocation rate [v4]
In-Reply-To: <gvhZ5s4LMcR4NQDCICvZZKtQgtNzL5wbl7hhG-j6cf8=.207310b9-3c82-4b69-9446-25f91061d7cc@github.com>
References: <gvhZ5s4LMcR4NQDCICvZZKtQgtNzL5wbl7hhG-j6cf8=.207310b9-3c82-4b69-9446-25f91061d7cc@github.com>
Message-ID: <2mbrDmNAYPTgsWGuMuGYJHPpb-fYm54iILreEPjA5fI=.4018f21c-269f-41b4-9668-dc80c98abd46@github.com>

> We use bytes_allocated_since_gc_start() to compute allocation rates.  This leaves a blind spot, as our current implementation ignores allocations and the time period between the moment we begin GC and the first time we update the allocation rate following the start of GC.  When this happens, we typically find that the sampled number of allocations is smaller than the allocations that had accumulated by the time we triggered the start of the current GC cycle.
> 
> This PR adds tracking for that accounting gap.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  Add override declarations to satisfy certain compilers

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27398/files
  - new: https://git.openjdk.org/jdk/pull/27398/files/bd7448ad..81db0b67

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27398&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27398&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27398.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27398/head:pull/27398

PR: https://git.openjdk.org/jdk/pull/27398

From wkemper at openjdk.org  Tue Sep 23 22:24:14 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 23 Sep 2025 22:24:14 GMT
Subject: RFR: 8368152: Shenandoah: Incorrect behavior at end of degenerated
 cycle [v4]
In-Reply-To: <k9XN2LBBWOARhNt9yqK5sLX5u7HO4fMqL-rz4w3oQYo=.77b0c7a4-9b5b-49e1-832b-e1e628f0a4ea@github.com>
References: <k9XN2LBBWOARhNt9yqK5sLX5u7HO4fMqL-rz4w3oQYo=.77b0c7a4-9b5b-49e1-832b-e1e628f0a4ea@github.com>
Message-ID: <jmGIzTbRuZClOfX4cg8X1M9W-o82togENpOYPv2thQI=.27e60c36-29a3-4bee-8841-ee74a0155ed0@github.com>

> There are several issues addressed in this PR:
> * Shenandoah always ran a full GC after any degenerated cycle
> * The number of consecutive degenerated GCs with bad progress was reset for every degenerated cycle
> * Good progress was reported in generational mode even when no progress is made

William Kemper has updated the pull request incrementally with one additional commit since the last revision:

  Improve comments and names

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27456/files
  - new: https://git.openjdk.org/jdk/pull/27456/files/2324450a..4c36c6f3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27456&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27456&range=02-03

  Stats: 32 lines in 3 files changed: 5 ins; 10 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/27456.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27456/head:pull/27456

PR: https://git.openjdk.org/jdk/pull/27456

From ysr at openjdk.org  Tue Sep 23 22:24:17 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 23 Sep 2025 22:24:17 GMT
Subject: RFR: 8368152: Shenandoah: Incorrect behavior at end of degenerated
 cycle [v3]
In-Reply-To: <gqZC71GibHHzmN5aPBEqYI-TKxEARk6CK6gmrTKbBjA=.acfbdc1c-2476-4369-ba0f-b047554ec4c4@github.com>
References: <k9XN2LBBWOARhNt9yqK5sLX5u7HO4fMqL-rz4w3oQYo=.77b0c7a4-9b5b-49e1-832b-e1e628f0a4ea@github.com>
 <gqZC71GibHHzmN5aPBEqYI-TKxEARk6CK6gmrTKbBjA=.acfbdc1c-2476-4369-ba0f-b047554ec4c4@github.com>
Message-ID: <Fd9h4DczaSkn2t2COfUcFrAtx9i9Ejv8GkdUc4N0i4k=.03d119aa-abfe-4ff5-9139-dd98cd1dbbcc@github.com>

On Tue, 23 Sep 2025 21:24:20 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> There are several issues addressed in this PR:
>> * Shenandoah always ran a full GC after any degenerated cycle
>> * The number of consecutive degenerated GCs with bad progress was reset for every degenerated cycle
>> * Good progress was reported in generational mode even when no progress is made
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comment

Also, independently, I think the notion of progress should be clarified based on current implementation in `ShenandoahMetricsSnapshot::is_good_progress()` (which declaration should itself have a brief comment):


   Compare before and after snapshots to determine if GC
   made sufficient progress. The notion of progress is based on space free after,
   change in space freed, or changes in internal and/or external fragmentation.


I found it slightly confusing that even though a `Generation` argument is passed into the method, it's really not used directly as far as I could tell in the notion of progress. The metrics all appear to be heap-wide, rather than generation-wide. There is a comment about the collection set being proportional to the generation in question which of course makes sense, but I'd much rather we didn't pass in an argument that isn't used there, but rather address it directly in the documentation.

May be I am missing something?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27456#issuecomment-3325724362

From wkemper at openjdk.org  Tue Sep 23 22:24:20 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 23 Sep 2025 22:24:20 GMT
Subject: RFR: 8368152: Shenandoah: Incorrect behavior at end of degenerated
 cycle [v3]
In-Reply-To: <ocmjgciBCj1Sz7BaKCIrRoERAalALV9WEiMy0gPUlrk=.c6840210-d455-4073-b19a-e2815918253f@github.com>
References: <k9XN2LBBWOARhNt9yqK5sLX5u7HO4fMqL-rz4w3oQYo=.77b0c7a4-9b5b-49e1-832b-e1e628f0a4ea@github.com>
 <gqZC71GibHHzmN5aPBEqYI-TKxEARk6CK6gmrTKbBjA=.acfbdc1c-2476-4369-ba0f-b047554ec4c4@github.com>
 <ocmjgciBCj1Sz7BaKCIrRoERAalALV9WEiMy0gPUlrk=.c6840210-d455-4073-b19a-e2815918253f@github.com>
Message-ID: <ebI1gaxemoC_D82as61Un8y2uzy6x-Tx5HCwItsUyk8=.3a331287-fc45-4e4a-bee1-13b0b6d76b60@github.com>

On Tue, 23 Sep 2025 21:33:53 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve comment
>
> src/hotspot/share/gc/shenandoah/shenandoahCollectorPolicy.hpp line 117:
> 
>> 115:   // Genshen will only upgrade to a full gc after the configured number of futile degenerated cycles.
>> 116:   bool should_upgrade_degenerated_gc() const {
>> 117:     return _consecutive_degenerated_gcs_without_progress >= CONSECUTIVE_BAD_DEGEN_PROGRESS_THRESHOLD;
> 
> assert that heap is generational? See previous comment above at line 68.

I renamed the method, but I don't want to put an assert on the mode here because it would make the unit test much harder to run.

> src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp line 323:
> 
>> 321:   // Shenandoah to avoid introducing "surprising new behavior."  It also makes less sense with non-generational
>> 322:   // Shenandoah to replace a full GC with a degenerated GC, because both have similar pause times in non-generational
>> 323:   // mode.
> 
> May be, based on the first paragraph above, you want to say more simply (replacing the entire second paragraph):
> 
> On the other hand, in non-generational mode,
> to both preserve legacy behavior, and because the
> difference between a degenerated gc and full gc is smaller,
> we immediately escalate to
> a full gc following the first degenerated cycle that doesn't make progress.
> 
> 
> I'd also move this comment out from here and to the constant that was defined for the number of consecutive degens before escalating to full in generational mode.

I moved the whole explanation into `shCollectorPolicy`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27456#discussion_r2373573529
PR Review Comment: https://git.openjdk.org/jdk/pull/27456#discussion_r2373574294

From wkemper at openjdk.org  Tue Sep 23 22:26:31 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 23 Sep 2025 22:26:31 GMT
Subject: RFR: 8368152: Shenandoah: Incorrect behavior at end of degenerated
 cycle [v4]
In-Reply-To: <jmGIzTbRuZClOfX4cg8X1M9W-o82togENpOYPv2thQI=.27e60c36-29a3-4bee-8841-ee74a0155ed0@github.com>
References: <k9XN2LBBWOARhNt9yqK5sLX5u7HO4fMqL-rz4w3oQYo=.77b0c7a4-9b5b-49e1-832b-e1e628f0a4ea@github.com>
 <jmGIzTbRuZClOfX4cg8X1M9W-o82togENpOYPv2thQI=.27e60c36-29a3-4bee-8841-ee74a0155ed0@github.com>
Message-ID: <8a6wleS4lVtHAIM16-jcZmE0IzTraEslvX02RW0APaU=.8d96b9d8-4d62-418c-bd5f-d7350bb58de9@github.com>

On Tue, 23 Sep 2025 22:24:14 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> There are several issues addressed in this PR:
>> * Shenandoah always ran a full GC after any degenerated cycle
>> * The number of consecutive degenerated GCs with bad progress was reset for every degenerated cycle
>> * Good progress was reported in generational mode even when no progress is made
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comments and names

You're right that the `generation` argument to `is_good_progress` is unused. I think it makes sense to instead pass this to the `shMetrics` constructor and have it evaluate `used` from the generation. I will experiment with this, but I think it's outside the scope of this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27456#issuecomment-3325736835

From kdnilsen at openjdk.org  Tue Sep 23 22:31:19 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 23 Sep 2025 22:31:19 GMT
Subject: RFR: 8368152: Shenandoah: Incorrect behavior at end of degenerated
 cycle [v4]
In-Reply-To: <jmGIzTbRuZClOfX4cg8X1M9W-o82togENpOYPv2thQI=.27e60c36-29a3-4bee-8841-ee74a0155ed0@github.com>
References: <k9XN2LBBWOARhNt9yqK5sLX5u7HO4fMqL-rz4w3oQYo=.77b0c7a4-9b5b-49e1-832b-e1e628f0a4ea@github.com>
 <jmGIzTbRuZClOfX4cg8X1M9W-o82togENpOYPv2thQI=.27e60c36-29a3-4bee-8841-ee74a0155ed0@github.com>
Message-ID: <vpbpIxVs-JsTK9tjVkIOsCU0yS0aFcdlg0Rj8guHsHk=.500a4b3f-c0a0-49c2-9e8b-1ba10454dfaa@github.com>

On Tue, 23 Sep 2025 22:24:14 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> There are several issues addressed in this PR:
>> * Shenandoah always ran a full GC after any degenerated cycle
>> * The number of consecutive degenerated GCs with bad progress was reset for every degenerated cycle
>> * Good progress was reported in generational mode even when no progress is made
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comments and names

Marked as reviewed by kdnilsen (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27456#pullrequestreview-3259769073

From ysr at openjdk.org  Tue Sep 23 22:33:55 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 23 Sep 2025 22:33:55 GMT
Subject: RFR: 8368152: Shenandoah: Incorrect behavior at end of degenerated
 cycle [v4]
In-Reply-To: <jmGIzTbRuZClOfX4cg8X1M9W-o82togENpOYPv2thQI=.27e60c36-29a3-4bee-8841-ee74a0155ed0@github.com>
References: <k9XN2LBBWOARhNt9yqK5sLX5u7HO4fMqL-rz4w3oQYo=.77b0c7a4-9b5b-49e1-832b-e1e628f0a4ea@github.com>
 <jmGIzTbRuZClOfX4cg8X1M9W-o82togENpOYPv2thQI=.27e60c36-29a3-4bee-8841-ee74a0155ed0@github.com>
Message-ID: <xeoXEXyQnM0tOWl_66iDTAch8jMqFUK-zWTwlwWlOUc=.70f8edfc-c8aa-497a-bc8b-ca0e955f8a65@github.com>

On Tue, 23 Sep 2025 22:24:14 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> There are several issues addressed in this PR:
>> * Shenandoah always ran a full GC after any degenerated cycle
>> * The number of consecutive degenerated GCs with bad progress was reset for every degenerated cycle
>> * Good progress was reported in generational mode even when no progress is made
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comments and names

Marked as reviewed by ysr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27456#pullrequestreview-3259777394

From kdnilsen at openjdk.org  Tue Sep 23 22:56:01 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 23 Sep 2025 22:56:01 GMT
Subject: RFR: 8368015: Shenandoah: fix error in computation of average
 allocation rate [v5]
In-Reply-To: <gvhZ5s4LMcR4NQDCICvZZKtQgtNzL5wbl7hhG-j6cf8=.207310b9-3c82-4b69-9446-25f91061d7cc@github.com>
References: <gvhZ5s4LMcR4NQDCICvZZKtQgtNzL5wbl7hhG-j6cf8=.207310b9-3c82-4b69-9446-25f91061d7cc@github.com>
Message-ID: <LsoPAk6cCRPe0uOlvagDfXPe2InAjzk327JtT9w5pvg=.59e4d64f-5fac-49ea-bc8c-eb3283a593d9@github.com>

> We use bytes_allocated_since_gc_start() to compute allocation rates.  This leaves a blind spot, as our current implementation ignores allocations and the time period between the moment we begin GC and the first time we update the allocation rate following the start of GC.  When this happens, we typically find that the sampled number of allocations is smaller than the allocations that had accumulated by the time we triggered the start of the current GC cycle.
> 
> This PR adds tracking for that accounting gap.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  More override declarations to satisfy certain compilers

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27398/files
  - new: https://git.openjdk.org/jdk/pull/27398/files/81db0b67..91f35d25

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27398&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27398&range=03-04

  Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/27398.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27398/head:pull/27398

PR: https://git.openjdk.org/jdk/pull/27398

From wkemper at openjdk.org  Wed Sep 24 00:49:53 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 24 Sep 2025 00:49:53 GMT
Subject: Integrated: 8368152: Shenandoah: Incorrect behavior at end of
 degenerated cycle
In-Reply-To: <k9XN2LBBWOARhNt9yqK5sLX5u7HO4fMqL-rz4w3oQYo=.77b0c7a4-9b5b-49e1-832b-e1e628f0a4ea@github.com>
References: <k9XN2LBBWOARhNt9yqK5sLX5u7HO4fMqL-rz4w3oQYo=.77b0c7a4-9b5b-49e1-832b-e1e628f0a4ea@github.com>
Message-ID: <366AluM9fb6C2xeX-ht46CF8XF3ZzACBKvz8sNRBi_Q=.4e6cf433-ba1d-46e2-8f80-6fe3006a8ef1@github.com>

On Tue, 23 Sep 2025 19:59:05 GMT, William Kemper <wkemper at openjdk.org> wrote:

> There are several issues addressed in this PR:
> * Shenandoah always ran a full GC after any degenerated cycle
> * The number of consecutive degenerated GCs with bad progress was reset for every degenerated cycle
> * Good progress was reported in generational mode even when no progress is made

This pull request has now been integrated.

Changeset: f36c33c8
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f36c33c86df0400d2155bfadd9a6b5ea56743133
Stats:     141 lines in 5 files changed: 109 ins; 19 del; 13 mod

8368152: Shenandoah: Incorrect behavior at end of degenerated cycle

Reviewed-by: kdnilsen, ysr

-------------

PR: https://git.openjdk.org/jdk/pull/27456

From kdnilsen at openjdk.org  Wed Sep 24 21:40:17 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 24 Sep 2025 21:40:17 GMT
Subject: RFR: 8368307: Shenandoah: get_next_bit_impl should special case weak
 and strong mark bits
Message-ID: <xayU5wW0nJ39tai5VKrG2TwRQd9L_ifdH_h6VntcrGQ=.83639e19-7638-4130-9108-76a4273502ba@github.com>

Check for weak bit or strong bit when giving special handling to the next bit found in first position of word.

-------------

Commit messages:
 - check for weak bit or strong bit in first bit position

Changes: https://git.openjdk.org/jdk/pull/27476/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27476&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368307
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27476.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27476/head:pull/27476

PR: https://git.openjdk.org/jdk/pull/27476

From wkemper at openjdk.org  Wed Sep 24 21:56:47 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 24 Sep 2025 21:56:47 GMT
Subject: RFR: 8368015: Shenandoah: fix error in computation of average
 allocation rate [v2]
In-Reply-To: <LVzpyZ3B0TsKlNE1hXCH2-tQdwRuv9xv_xayKqYv-wM=.768ea66b-9c9a-434a-be9a-c107c2452180@github.com>
References: <gvhZ5s4LMcR4NQDCICvZZKtQgtNzL5wbl7hhG-j6cf8=.207310b9-3c82-4b69-9446-25f91061d7cc@github.com>
 <yRB_ZOWhuRXEdibuOrz13mgjZoFwRlsNxk_LAWG-m5g=.24e7b2df-b599-4f36-b63b-a48208011bca@github.com>
 <D__vnhYc-3eaale_ze97YsNy4CusX5rjT_7Tu8K1kmc=.8d780025-a9a6-41f7-b20f-00ecdaeebb01@github.com>
 <LVzpyZ3B0TsKlNE1hXCH2-tQdwRuv9xv_xayKqYv-wM=.768ea66b-9c9a-434a-be9a-c107c2452180@github.com>
Message-ID: <YRBLaNr_hqNgCx-jYr1Qx4WQ2bNlJb87Qx_nCvPe0so=.7ef75e47-56ba-4f38-8a8a-26b26ac1e445@github.com>

On Tue, 23 Sep 2025 15:36:42 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 364:
>> 
>>> 362: 
>>> 363: double ShenandoahAllocationRate::force_sample(size_t allocated, size_t &unaccounted_bytes_allocated) {
>>> 364:   const double MinSampleTime = 0.002;    // Do not sample if time since last update is less than 2 ms
>> 
>> Would it make sense to "carry over" the `unaccounted_bytes_allocated` if, at the time of reset, the last sample was taken less than `ShenandoahAllocationRate::_interval_sec` (instead of `MinSampleTime`)? I believe this would result in more samples being carried over.
>
> I've done experiments with a variety of	different values for MinSampleTime (e.g. 50 ms, 25ms, 2 ms).  I	find that any value
> greater	than 1 ms works	pretty well in the sense that the measured rate	is pretty consistent with the average rate as computed
> by the preexisting mechanisms.
> 
> The biggest problem I observed was when	we tried to measure rate over an interval of a few microseconds, and these intervals
> sometimes had zero allocations.
> 
> We could make the change you suggest, but that would actually result in	fewer samples rather than more.	 It would also make
> the value of bytes_allocated_since_gc_start() less precise in that this quantity	would carry up to 100 ms of allocations	that
> actually occurred before the start of the current GC.
> 
> Here's an ASCII art attempt to illustrate how it works	in the current implementation.
> 
> Here is	a timeline with	a tick mark to illustrate the desired sample time, every	100 ms:
> 
> 
>       	 .1s  	   .2s	     .3s       .4s.     .5s  	   .6s	     .7s       .8s.    .9s  	   1s	      1.1s      1.2s
> |---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---
>       	       ^      	      	      	      	    	      	      	      	      	      	       ^
> Existing       |                                                                                       |
> Samples:  A    B                                                                                       C      	 D         E
>                |                                                                                       |
> Proposed       |                                                                                       |
> Samples:  A    |                                                                                       B      	 C    	   D
>                |                                                                                       |
>                |                                                                                       |
>       	       Trigger GC at 0.14s    	      	      	      	      	      	      	      	       Finish GC at 1.03s
> 
> In either approach, we sample at 0.1s and this sample contributes to the average allocation rate that causes us	to trigger at
> time 0.14s.  In	the current implementation, at time 0.14s, we take a new sample	representing the most current allocation rate
> as computed over the span between 0.1s and 0.14s.  As implemented, if this time	delta (0.14s minus 0.10s =0...

With the change in the PR, I was thinking of "skipped" samples as being "carried over" to the next cycle (per `unaccounted_bytes_allocated = allocated - _last_sample_value;`).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27398#discussion_r2377167640

From wkemper at openjdk.org  Wed Sep 24 22:14:13 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 24 Sep 2025 22:14:13 GMT
Subject: RFR: 8368015: Shenandoah: fix error in computation of average
 allocation rate [v5]
In-Reply-To: <LsoPAk6cCRPe0uOlvagDfXPe2InAjzk327JtT9w5pvg=.59e4d64f-5fac-49ea-bc8c-eb3283a593d9@github.com>
References: <gvhZ5s4LMcR4NQDCICvZZKtQgtNzL5wbl7hhG-j6cf8=.207310b9-3c82-4b69-9446-25f91061d7cc@github.com>
 <LsoPAk6cCRPe0uOlvagDfXPe2InAjzk327JtT9w5pvg=.59e4d64f-5fac-49ea-bc8c-eb3283a593d9@github.com>
Message-ID: <y8BMqfFhUg1Pbv7LKbG69cfNxSQzM4wTwEt3gxW-CrY=.e7b0219c-e236-4c33-be9f-130ff500f0db@github.com>

On Tue, 23 Sep 2025 22:56:01 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> We use bytes_allocated_since_gc_start() to compute allocation rates.  This leaves a blind spot, as our current implementation ignores allocations and the time period between the moment we begin GC and the first time we update the allocation rate following the start of GC.  When this happens, we typically find that the sampled number of allocations is smaller than the allocations that had accumulated by the time we triggered the start of the current GC cycle.
>> 
>> This PR adds tracking for that accounting gap.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More override declarations to satisfy certain compilers

Thank you for the changes.

-------------

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27398#pullrequestreview-3264893414

From fandreuzzi at openjdk.org  Wed Sep 24 22:46:30 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 24 Sep 2025 22:46:30 GMT
Subject: RFR: 8368599: ShenandoahConcurrentMark could use
 ThreadsClaimTokenScope
Message-ID: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com>

Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `ShenandoahConcurrentMark::finish_mark_work` to be more precise with what is actually needed and why. Similar to #27385.

Test: tier1, and tier[1,2,3]_gc_shenandoah

-------------

Commit messages:
 - replace

Changes: https://git.openjdk.org/jdk/pull/27477/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27477&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368599
  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27477.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27477/head:pull/27477

PR: https://git.openjdk.org/jdk/pull/27477

From kdnilsen at openjdk.org  Wed Sep 24 22:51:49 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 24 Sep 2025 22:51:49 GMT
Subject: Integrated: 8368015: Shenandoah: fix error in computation of average
 allocation rate
In-Reply-To: <gvhZ5s4LMcR4NQDCICvZZKtQgtNzL5wbl7hhG-j6cf8=.207310b9-3c82-4b69-9446-25f91061d7cc@github.com>
References: <gvhZ5s4LMcR4NQDCICvZZKtQgtNzL5wbl7hhG-j6cf8=.207310b9-3c82-4b69-9446-25f91061d7cc@github.com>
Message-ID: <PjJq1nA-GytR5EigrijBjff-2mNCqryiiMPchOAowgY=.797aad89-91d7-4fd8-aa46-91e51c6a30df@github.com>

On Fri, 19 Sep 2025 20:36:51 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> We use bytes_allocated_since_gc_start() to compute allocation rates.  This leaves a blind spot, as our current implementation ignores allocations and the time period between the moment we begin GC and the first time we update the allocation rate following the start of GC.  When this happens, we typically find that the sampled number of allocations is smaller than the allocations that had accumulated by the time we triggered the start of the current GC cycle.
> 
> This PR adds tracking for that accounting gap.

This pull request has now been integrated.

Changeset: a2870d6b
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a2870d6b4985a68beb3fe3bf6622e6245e9a82ec
Stats:     80 lines in 7 files changed: 56 ins; 6 del; 18 mod

8368015: Shenandoah: fix error in computation of average allocation rate

Reviewed-by: wkemper

-------------

PR: https://git.openjdk.org/jdk/pull/27398

From wkemper at openjdk.org  Wed Sep 24 23:01:11 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 24 Sep 2025 23:01:11 GMT
Subject: RFR: 8368499: GenShen: Do not collect age census during evac when
 adaptive tenuring is disabled
Message-ID: <FB1APSykTknNA9zfwLOUE36zduLMqImj7ojbkVlPxt8=.3dc64309-ea54-4224-98bb-f175f5f3791c@github.com>

This is a simplification to `ShenandoahEvacTracker` (which is a diagnostic feature). The ability to compute the age census during evacuation was still in the code, even though the (experimental) option to enable it was removed. Removing the rest of the code allows us to take an additional flag-check off the evacuation path and to consolidate duplicated gc stat processing code between `shControlThread` and `shGenerationalControlThread`.

-------------

Commit messages:
 - Decouple age table printing from evac tracking, consolidate duplicated code
 - Do not compute age census during evac when adaptive tenuring is disabled

Changes: https://git.openjdk.org/jdk/pull/27479/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27479&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368499
  Stats: 250 lines in 11 files changed: 55 ins; 137 del; 58 mod
  Patch: https://git.openjdk.org/jdk/pull/27479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27479/head:pull/27479

PR: https://git.openjdk.org/jdk/pull/27479

From ysr at openjdk.org  Wed Sep 24 23:03:23 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 24 Sep 2025 23:03:23 GMT
Subject: RFR: 8368015: Shenandoah: fix error in computation of average
 allocation rate [v5]
In-Reply-To: <LsoPAk6cCRPe0uOlvagDfXPe2InAjzk327JtT9w5pvg=.59e4d64f-5fac-49ea-bc8c-eb3283a593d9@github.com>
References: <gvhZ5s4LMcR4NQDCICvZZKtQgtNzL5wbl7hhG-j6cf8=.207310b9-3c82-4b69-9446-25f91061d7cc@github.com>
 <LsoPAk6cCRPe0uOlvagDfXPe2InAjzk327JtT9w5pvg=.59e4d64f-5fac-49ea-bc8c-eb3283a593d9@github.com>
Message-ID: <Xc5uXUlRh-wGRMcXMRIC4VgPiJ11auY3mMh3RtIGolw=.92228cb5-eb1d-4ffb-96fa-b3fc513a196e@github.com>

On Tue, 23 Sep 2025 22:56:01 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> We use bytes_allocated_since_gc_start() to compute allocation rates.  This leaves a blind spot, as our current implementation ignores allocations and the time period between the moment we begin GC and the first time we update the allocation rate following the start of GC.  When this happens, we typically find that the sampled number of allocations is smaller than the allocations that had accumulated by the time we triggered the start of the current GC cycle.
>> 
>> This PR adds tracking for that accounting gap.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More override declarations to satisfy certain compilers

The changes look mostly correct (there's the small issue of ascribing time and allocation precisely to the right interval which might be unavoidable), but I feel this code can be refactored to make it slightly less clunky.

However, probably best to leave that for a follow up.

I left a few suggestions for documentation.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp line 40:

> 38:   void allocation_counter_reset();
> 39: 
> 40:   double force_sample(size_t allocated, size_t &unaccounted_bytes_allocated);

Document these two APIs: force_sample() and sample().

A small block documentation comment on ShenandoahAllocationRate() is also a good idea.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.hpp line 244:

> 242:   double elapsed_cycle_time() const;
> 243: 
> 244:   virtual size_t force_alloc_rate_sample(size_t bytes_allocated) {

I realize none of these public API's have any documentation of intent, but might be a good idea to start doing that with this new API you are adding here.

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2329:

> 2327:   // unaccounted_bytes is the bytes not accounted for by our forced sample.  If the sample interval is too short,
> 2328:   // the "forced sample" will not happen, and any recently allocated bytes are "unaccounted for".  We pretend these
> 2329:   // bytes are allocated after the start of subsequent gc.

I think these comments should be made slightly more abstract and moved to the spec of `reset` and of the `force` methods. These almost feel like a bit of the specifics of the sampling and the "residue" computation leaking through into objects that it shouldn't leak into. So a bit of thought on how to organize this best by pushing everything to one place would work better from the standpoint of code maintainability and robustness.

As I understand the issue is that we use two separate APIs with no locking to read the allocated bytes and to reset these bytes, all while these are being concurrently incremented. So you want to have the reset method detect the residue allocation between the two points, and ascribe it to the rate computation to be used in the next sample. I feel there may be a simpler way to do this by pushing all of these mechanics & details down into the sampling method which has direct access to the counter that it can manipulate for computing rates and upon request for resetting.

-------------

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27398#pullrequestreview-3264863343
PR Review Comment: https://git.openjdk.org/jdk/pull/27398#discussion_r2377176198
PR Review Comment: https://git.openjdk.org/jdk/pull/27398#discussion_r2377172069
PR Review Comment: https://git.openjdk.org/jdk/pull/27398#discussion_r2377256204

From kdnilsen at openjdk.org  Wed Sep 24 23:08:07 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 24 Sep 2025 23:08:07 GMT
Subject: RFR: 8368499: GenShen: Do not collect age census during evac when
 adaptive tenuring is disabled
In-Reply-To: <FB1APSykTknNA9zfwLOUE36zduLMqImj7ojbkVlPxt8=.3dc64309-ea54-4224-98bb-f175f5f3791c@github.com>
References: <FB1APSykTknNA9zfwLOUE36zduLMqImj7ojbkVlPxt8=.3dc64309-ea54-4224-98bb-f175f5f3791c@github.com>
Message-ID: <2tVaJ3hKQ2TQCCLkr0BPsg_4Vkaln2tJsFkqoVl_bGI=.b0792d10-377c-4ac8-970b-1a6f6eba4588@github.com>

On Wed, 24 Sep 2025 22:53:28 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This is a simplification to `ShenandoahEvacTracker` (which is a diagnostic feature). The ability to compute the age census during evacuation was still in the code, even though the (experimental) option to enable it was removed. Removing the rest of the code allows us to take an additional flag-check off the evacuation path and to consolidate duplicated gc stat processing code between `shControlThread` and `shGenerationalControlThread`.

Thanks for these improvements.

-------------

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27479#pullrequestreview-3264977489

From wkemper at openjdk.org  Wed Sep 24 23:10:22 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 24 Sep 2025 23:10:22 GMT
Subject: RFR: 8368015: Shenandoah: fix error in computation of average
 allocation rate [v5]
In-Reply-To: <Xc5uXUlRh-wGRMcXMRIC4VgPiJ11auY3mMh3RtIGolw=.92228cb5-eb1d-4ffb-96fa-b3fc513a196e@github.com>
References: <gvhZ5s4LMcR4NQDCICvZZKtQgtNzL5wbl7hhG-j6cf8=.207310b9-3c82-4b69-9446-25f91061d7cc@github.com>
 <LsoPAk6cCRPe0uOlvagDfXPe2InAjzk327JtT9w5pvg=.59e4d64f-5fac-49ea-bc8c-eb3283a593d9@github.com>
 <Xc5uXUlRh-wGRMcXMRIC4VgPiJ11auY3mMh3RtIGolw=.92228cb5-eb1d-4ffb-96fa-b3fc513a196e@github.com>
Message-ID: <nA5G_zmpXE-TL_x7nld4of0LR4bMhpxLYyNDG-ZxdaE=.8b92e5b5-dcbc-414a-b2fc-35ef8eee0896@github.com>

On Wed, 24 Sep 2025 22:58:28 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More override declarations to satisfy certain compilers
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2329:
> 
>> 2327:   // unaccounted_bytes is the bytes not accounted for by our forced sample.  If the sample interval is too short,
>> 2328:   // the "forced sample" will not happen, and any recently allocated bytes are "unaccounted for".  We pretend these
>> 2329:   // bytes are allocated after the start of subsequent gc.
> 
> I think these comments should be made slightly more abstract and moved to the spec of `reset` and of the `force` methods. These almost feel like a bit of the specifics of the sampling and the "residue" computation leaking through into objects that it shouldn't leak into. So a bit of thought on how to organize this best by pushing everything to one place would work better from the standpoint of code maintainability and robustness.
> 
> As I understand the issue is that we use two separate APIs with no locking to read the allocated bytes and to reset these bytes, all while these are being concurrently incremented. So you want to have the reset method detect the residue allocation between the two points, and ascribe it to the rate computation to be used in the next sample. I feel there may be a simpler way to do this by pushing all of these mechanics & details down into the sampling method which has direct access to the counter that it can manipulate for computing rates and upon request for resetting.

I agree. What we're really try to track is the mutator's allocation rate. There's no particular reason it needs to be implemented in terms of bytes allocated _since gc start_. Of course, we must reset (or at least, reduce) the value periodically to avoid rollover, but again, we don't need to do that only when we start a gc. As @kdnilsen noted, having the control thread take the samples also means we don't collect samples during the GC cycle. We should consider having mutators (or some other thread) collect the samples and manage the allocation counter.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27398#discussion_r2377265215

From kdnilsen at openjdk.org  Wed Sep 24 23:10:22 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 24 Sep 2025 23:10:22 GMT
Subject: RFR: 8368015: Shenandoah: fix error in computation of average
 allocation rate [v5]
In-Reply-To: <nA5G_zmpXE-TL_x7nld4of0LR4bMhpxLYyNDG-ZxdaE=.8b92e5b5-dcbc-414a-b2fc-35ef8eee0896@github.com>
References: <gvhZ5s4LMcR4NQDCICvZZKtQgtNzL5wbl7hhG-j6cf8=.207310b9-3c82-4b69-9446-25f91061d7cc@github.com>
 <LsoPAk6cCRPe0uOlvagDfXPe2InAjzk327JtT9w5pvg=.59e4d64f-5fac-49ea-bc8c-eb3283a593d9@github.com>
 <Xc5uXUlRh-wGRMcXMRIC4VgPiJ11auY3mMh3RtIGolw=.92228cb5-eb1d-4ffb-96fa-b3fc513a196e@github.com>
 <nA5G_zmpXE-TL_x7nld4of0LR4bMhpxLYyNDG-ZxdaE=.8b92e5b5-dcbc-414a-b2fc-35ef8eee0896@github.com>
Message-ID: <3QX83tSpGiYad43aMwfXO8Bf3LVEtjTaRsOII8H9FAc=.204eedd4-c5d1-49c3-95d8-15586f247ae3@github.com>

On Wed, 24 Sep 2025 23:07:40 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2329:
>> 
>>> 2327:   // unaccounted_bytes is the bytes not accounted for by our forced sample.  If the sample interval is too short,
>>> 2328:   // the "forced sample" will not happen, and any recently allocated bytes are "unaccounted for".  We pretend these
>>> 2329:   // bytes are allocated after the start of subsequent gc.
>> 
>> I think these comments should be made slightly more abstract and moved to the spec of `reset` and of the `force` methods. These almost feel like a bit of the specifics of the sampling and the "residue" computation leaking through into objects that it shouldn't leak into. So a bit of thought on how to organize this best by pushing everything to one place would work better from the standpoint of code maintainability and robustness.
>> 
>> As I understand the issue is that we use two separate APIs with no locking to read the allocated bytes and to reset these bytes, all while these are being concurrently incremented. So you want to have the reset method detect the residue allocation between the two points, and ascribe it to the rate computation to be used in the next sample. I feel there may be a simpler way to do this by pushing all of these mechanics & details down into the sampling method which has direct access to the counter that it can manipulate for computing rates and upon request for resetting.
>
> I agree. What we're really try to track is the mutator's allocation rate. There's no particular reason it needs to be implemented in terms of bytes allocated _since gc start_. Of course, we must reset (or at least, reduce) the value periodically to avoid rollover, but again, we don't need to do that only when we start a gc. As @kdnilsen noted, having the control thread take the samples also means we don't collect samples during the GC cycle. We should consider having mutators (or some other thread) collect the samples and manage the allocation counter.

Thanks for review.  I'll update docs in a separate PR (since I integrated already).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27398#discussion_r2377265803

From ysr at openjdk.org  Wed Sep 24 23:39:08 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 24 Sep 2025 23:39:08 GMT
Subject: RFR: 8368499: GenShen: Do not collect age census during evac when
 adaptive tenuring is disabled
In-Reply-To: <FB1APSykTknNA9zfwLOUE36zduLMqImj7ojbkVlPxt8=.3dc64309-ea54-4224-98bb-f175f5f3791c@github.com>
References: <FB1APSykTknNA9zfwLOUE36zduLMqImj7ojbkVlPxt8=.3dc64309-ea54-4224-98bb-f175f5f3791c@github.com>
Message-ID: <VqUmRYPrEqCWWJ0usKHGaG40M_9pwtK2TLFG7WfdC9Y=.7259dc99-8385-427b-aa43-1bcc102c7ef2@github.com>

On Wed, 24 Sep 2025 22:53:28 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This is a simplification to `ShenandoahEvacTracker` (which is a diagnostic feature). The ability to compute the age census during evacuation was still in the code, even though the (experimental) option to enable it was removed. Removing the rest of the code allows us to take an additional flag-check off the evacuation path and to consolidate duplicated gc stat processing code between `shControlThread` and `shGenerationalControlThread`.

LGTM; thanks for the clean up!

-------------

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27479#pullrequestreview-3265015095

From wkemper at openjdk.org  Wed Sep 24 23:49:26 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 24 Sep 2025 23:49:26 GMT
Subject: RFR: 8368152: Shenandoah: Incorrect behavior at end of degenerated
 cycle
Message-ID: <dpoE92y30Rvy13TYDvp71BoCgtjNjIgUK_qQNdmLt7U=.e08dab1a-32b6-42f0-a290-c6138a79ba62@github.com>

Not clean, but trivial conflict resolution.

-------------

Commit messages:
 - Add missing precompile header for 21 branch
 - 8368152: Shenandoah: Incorrect behavior at end of degenerated cycle

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/222/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=222&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368152
  Stats: 145 lines in 5 files changed: 112 ins; 19 del; 14 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/222.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/222/head:pull/222

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/222

From wkemper at openjdk.org  Wed Sep 24 23:58:53 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 24 Sep 2025 23:58:53 GMT
Subject: RFR: 8368599: ShenandoahConcurrentMark could use
 ThreadsClaimTokenScope
In-Reply-To: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com>
References: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com>
Message-ID: <4MAbJyfv4_vkF9E9f2GO9dXfaxEB5HjY22DLDowNiu4=.880d1627-d0b8-4686-bce1-bc07b8a1d694@github.com>

On Wed, 24 Sep 2025 22:37:44 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `ShenandoahConcurrentMark::finish_mark_work` to be more precise with what is actually needed and why. Similar to #27385.
> 
> Test: tier1, and tier[1,2,3]_gc_shenandoah

LGTM! Thank you.

-------------

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27477#pullrequestreview-3265051449

From ayang at openjdk.org  Thu Sep 25 10:42:01 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 25 Sep 2025 10:42:01 GMT
Subject: RFR: 8368599: ShenandoahConcurrentMark could use
 ThreadsClaimTokenScope
In-Reply-To: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com>
References: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com>
Message-ID: <4xXAiT5xKFTZOb_8v4f9vRVVk2UVS-4Cq1E66fwNqbA=.9a8b2f43-bd19-4797-841c-5c4a54481a6a@github.com>

On Wed, 24 Sep 2025 22:37:44 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `ShenandoahConcurrentMark::finish_mark_work` to be more precise with what is actually needed and why. Similar to #27385.
> 
> Test: tier1, and tier[1,2,3]_gc_shenandoah

I wonder if it can be inlined to `ShenandoahFinalMarkingTask` as a field, but up to you.

-------------

Marked as reviewed by ayang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27477#pullrequestreview-3267008172

From fandreuzzi at openjdk.org  Thu Sep 25 11:00:19 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 25 Sep 2025 11:00:19 GMT
Subject: RFR: 8368599: ShenandoahConcurrentMark could use
 ThreadsClaimTokenScope [v2]
In-Reply-To: <4xXAiT5xKFTZOb_8v4f9vRVVk2UVS-4Cq1E66fwNqbA=.9a8b2f43-bd19-4797-841c-5c4a54481a6a@github.com>
References: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com>
 <4xXAiT5xKFTZOb_8v4f9vRVVk2UVS-4Cq1E66fwNqbA=.9a8b2f43-bd19-4797-841c-5c4a54481a6a@github.com>
Message-ID: <ATMevlyzPeIi2UF8DjnInA8vndYDm-1JutY5ChWaXFA=.0d976cb3-06f4-45a1-8172-5ca683e985ab@github.com>

On Thu, 25 Sep 2025 10:39:12 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> I wonder if it can be inlined to `ShenandoahFinalMarkingTask` as a field, but up to you.

Good point, it looks better this way: b1686c28687a97ef3bc0764740c33a6dd89c0c2e

I re-run tier[1,2,3]_gc_shenandoah.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27477#issuecomment-3333396462

From fandreuzzi at openjdk.org  Thu Sep 25 11:00:18 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 25 Sep 2025 11:00:18 GMT
Subject: RFR: 8368599: ShenandoahConcurrentMark could use
 ThreadsClaimTokenScope [v2]
In-Reply-To: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com>
References: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com>
Message-ID: <qwKK3x51U4uQgi5Oco5sr6FIsFPOMBOjWV2YP4R6g78=.26efd2a1-749d-4a79-bf11-42842b20dc30@github.com>

> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `ShenandoahConcurrentMark::finish_mark_work` to be more precise with what is actually needed and why. Similar to #27385.
> 
> Test: tier1, and tier[1,2,3]_gc_shenandoah

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  as field

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27477/files
  - new: https://git.openjdk.org/jdk/pull/27477/files/44377b16..b1686c28

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27477&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27477&range=00-01

  Stats: 4 lines in 1 file changed: 2 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27477.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27477/head:pull/27477

PR: https://git.openjdk.org/jdk/pull/27477

From duke at openjdk.org  Thu Sep 25 12:44:33 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Thu, 25 Sep 2025 12:44:33 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v15]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <LbtKjOFGsHTibAzEPUiW9ZqBktChIHNCRguabF9NWAA=.d17d091e-79d8-40eb-b320-cd36aac1503c@github.com>

> This PR will consolidate fixes of the following bugs:
> 
> https://bugs.openjdk.org/browse/JDK-8361188
> https://bugs.openjdk.org/browse/JDK-8361189
> https://bugs.openjdk.org/browse/JDK-8361190
> https://bugs.openjdk.org/browse/JDK-8361191
> https://bugs.openjdk.org/browse/JDK-8361192
> https://bugs.openjdk.org/browse/JDK-8361193
> https://bugs.openjdk.org/browse/JDK-8361195
> 
> This PR depends on https://github.com/openjdk/jdk/pull/25971
> 
> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190

Khalid Boulanouare has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 74 commits:

 - Merge branch 'openjdk:master' into jdk-8360498
 - Removes not needed changes
 - Revert "Removes not needed changes"
   
   This reverts commit e76780d50cc390e35443dccb193cfbc9a1cec1cb.
 - Removes not needed changes
 - Removes extra white lines
 - Merge branch 'pr/25971' into jdk-8360498
 - Merge branch 'openjdk:master' into jdk-8158801
 - Merge branch 'pr/25971' into jdk-8360498
 - Merge branch 'openjdk:master' into jdk-8158801
 - Centers missed frames in the middle of screen
 - ... and 64 more: https://git.openjdk.org/jdk/compare/26b5708c...e5753d14

-------------

Changes: https://git.openjdk.org/jdk/pull/26625/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=14
  Stats: 185 lines in 14 files changed: 96 ins; 44 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/26625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26625/head:pull/26625

PR: https://git.openjdk.org/jdk/pull/26625

From duke at openjdk.org  Thu Sep 25 13:03:51 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Thu, 25 Sep 2025 13:03:51 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v16]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <5YzcczRe9VgQqc7POMiumcCnf6esXSQO6PpUbIuuxhA=.efcb29a6-3705-475d-901c-515838317bfe@github.com>

> This PR will consolidate fixes of the following bugs:
> 
> https://bugs.openjdk.org/browse/JDK-8361188
> https://bugs.openjdk.org/browse/JDK-8361189
> https://bugs.openjdk.org/browse/JDK-8361190
> https://bugs.openjdk.org/browse/JDK-8361191
> https://bugs.openjdk.org/browse/JDK-8361192
> https://bugs.openjdk.org/browse/JDK-8361193
> https://bugs.openjdk.org/browse/JDK-8361195
> 
> This PR depends on https://github.com/openjdk/jdk/pull/25971
> 
> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190

Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:

  Resolves confict for when there is a merge with jdk-8158801

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/e5753d14..8794db9a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=14-15

  Stats: 55 lines in 1 file changed: 36 ins; 3 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/26625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26625/head:pull/26625

PR: https://git.openjdk.org/jdk/pull/26625

From kdnilsen at openjdk.org  Thu Sep 25 13:28:10 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 25 Sep 2025 13:28:10 GMT
Subject: RFR: 8368152: Shenandoah: Incorrect behavior at end of degenerated
 cycle
In-Reply-To: <dpoE92y30Rvy13TYDvp71BoCgtjNjIgUK_qQNdmLt7U=.e08dab1a-32b6-42f0-a290-c6138a79ba62@github.com>
References: <dpoE92y30Rvy13TYDvp71BoCgtjNjIgUK_qQNdmLt7U=.e08dab1a-32b6-42f0-a290-c6138a79ba62@github.com>
Message-ID: <jX56_ApB-N6oqvU58vdqbY2yy9uQtBzkQxn3W8iXCgs=.d050d33d-1147-421c-995b-d8e66721cb1d@github.com>

On Wed, 24 Sep 2025 23:42:46 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Not clean, but trivial conflict resolution.

Thanks for your urgency on this.

-------------

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/222#pullrequestreview-3267653724

From alanb at openjdk.org  Thu Sep 25 13:30:34 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 Sep 2025 13:30:34 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v16]
In-Reply-To: <5YzcczRe9VgQqc7POMiumcCnf6esXSQO6PpUbIuuxhA=.efcb29a6-3705-475d-901c-515838317bfe@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <5YzcczRe9VgQqc7POMiumcCnf6esXSQO6PpUbIuuxhA=.efcb29a6-3705-475d-901c-515838317bfe@github.com>
Message-ID: <qCdRyzzEZkz-BhwZbGHWty81mOSB7ae9pu9B7FmSKSs=.f77f53d2-5df1-4829-83d7-a4aefaae732b@github.com>

On Thu, 25 Sep 2025 13:03:51 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> This PR will consolidate fixes of the following bugs:
>> 
>> https://bugs.openjdk.org/browse/JDK-8361188
>> https://bugs.openjdk.org/browse/JDK-8361189
>> https://bugs.openjdk.org/browse/JDK-8361190
>> https://bugs.openjdk.org/browse/JDK-8361191
>> https://bugs.openjdk.org/browse/JDK-8361192
>> https://bugs.openjdk.org/browse/JDK-8361193
>> https://bugs.openjdk.org/browse/JDK-8361195
>> 
>> This PR depends on https://github.com/openjdk/jdk/pull/25971
>> 
>> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
>> 
>> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
>> 
>> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
>> 
>> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
>> 
>> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190
>
> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Resolves confict for when there is a merge with jdk-8158801

What is this about? The PR suggests 500+ commits and 300+  files changed but I think it's just a change to some AWT tests. Can you sync up the branch so that it only contains the changes to the AWT tests that you want to change, and remove all the labels except "client" as it will otherwise broadcast to all the mailing lists.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26625#issuecomment-3334044893

From ayang at openjdk.org  Thu Sep 25 13:31:32 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 25 Sep 2025 13:31:32 GMT
Subject: RFR: 8368599: ShenandoahConcurrentMark could use
 ThreadsClaimTokenScope [v2]
In-Reply-To: <qwKK3x51U4uQgi5Oco5sr6FIsFPOMBOjWV2YP4R6g78=.26efd2a1-749d-4a79-bf11-42842b20dc30@github.com>
References: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com>
 <qwKK3x51U4uQgi5Oco5sr6FIsFPOMBOjWV2YP4R6g78=.26efd2a1-749d-4a79-bf11-42842b20dc30@github.com>
Message-ID: <ju0y0PBp1gob3GVg5Qu769bM-fWIg5A4F0dB0Xj1q8s=.96290a4d-5959-4904-8f3d-4d2f0463fa86@github.com>

On Thu, 25 Sep 2025 11:00:18 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `ShenandoahConcurrentMark::finish_mark_work` to be more precise with what is actually needed and why. Similar to #27385.
>> 
>> Test: tier1, and tier[1,2,3]_gc_shenandoah
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   as field

Marked as reviewed by ayang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27477#pullrequestreview-3267672065

From duke at openjdk.org  Thu Sep 25 14:00:08 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Thu, 25 Sep 2025 14:00:08 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v17]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <IFBetIfNildsjk1H900soCAiLg2EM8nsjrkfKOPWBV4=.4ccfcb8f-ec0e-4c6b-a713-c604c6a9f114@github.com>

> This PR will consolidate fixes of the following bugs:
> 
> https://bugs.openjdk.org/browse/JDK-8361188
> https://bugs.openjdk.org/browse/JDK-8361189
> https://bugs.openjdk.org/browse/JDK-8361190
> https://bugs.openjdk.org/browse/JDK-8361191
> https://bugs.openjdk.org/browse/JDK-8361192
> https://bugs.openjdk.org/browse/JDK-8361193
> https://bugs.openjdk.org/browse/JDK-8361195
> 
> This PR depends on https://github.com/openjdk/jdk/pull/25971
> 
> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190

Khalid Boulanouare has updated the pull request incrementally with three additional commits since the last revision:

 - Merge branch 'openjdk:master' into jdk-8360498
 - 8359378: aarch64: crash when using -XX:+UseFPUForSpilling
   
   Reviewed-by: aph, rcastanedalo
 - 8367103: RISC-V: store cpu features in a bitmap
   
   Reviewed-by: fyang, luhenry

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/8794db9a..69c087a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=15-16

  Stats: 214 lines in 3 files changed: 142 ins; 4 del; 68 mod
  Patch: https://git.openjdk.org/jdk/pull/26625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26625/head:pull/26625

PR: https://git.openjdk.org/jdk/pull/26625

From duke at openjdk.org  Thu Sep 25 14:00:10 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Thu, 25 Sep 2025 14:00:10 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v16]
In-Reply-To: <qCdRyzzEZkz-BhwZbGHWty81mOSB7ae9pu9B7FmSKSs=.f77f53d2-5df1-4829-83d7-a4aefaae732b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <5YzcczRe9VgQqc7POMiumcCnf6esXSQO6PpUbIuuxhA=.efcb29a6-3705-475d-901c-515838317bfe@github.com>
 <qCdRyzzEZkz-BhwZbGHWty81mOSB7ae9pu9B7FmSKSs=.f77f53d2-5df1-4829-83d7-a4aefaae732b@github.com>
Message-ID: <URXFmVJhmSe8PBZ4Vdbqw_lKQyw9TfofauV5j6QYwzA=.50d49205-a08a-4147-a97e-66f090371efc@github.com>

On Thu, 25 Sep 2025 13:26:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Resolves confict for when there is a merge with jdk-8158801
>
> What is this about? The PR suggests 500+ commits and 300+  files changed but I think it's just a change to some AWT tests. Can you sync up the branch so that it only contains the changes to the AWT tests that you want to change, and remove all the labels except "client" as it will otherwise broadcast to all the mailing lists.

@AlanBateman This PR is created based on PR https://github.com/openjdk/jdk/tree/pr/25971. My branch https://github.com/kboulanou/jdk/tree/jdk-8360498 is only 2 commits behind master. I am waiting for approval for PR https://github.com/openjdk/jdk/tree/pr/25971 for this PR to follow. Please let me know if there is anything I need to do. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26625#issuecomment-3334251324

From shade at openjdk.org  Thu Sep 25 14:19:21 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 25 Sep 2025 14:19:21 GMT
Subject: RFR: 8368599: ShenandoahConcurrentMark could use
 ThreadsClaimTokenScope [v2]
In-Reply-To: <qwKK3x51U4uQgi5Oco5sr6FIsFPOMBOjWV2YP4R6g78=.26efd2a1-749d-4a79-bf11-42842b20dc30@github.com>
References: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com>
 <qwKK3x51U4uQgi5Oco5sr6FIsFPOMBOjWV2YP4R6g78=.26efd2a1-749d-4a79-bf11-42842b20dc30@github.com>
Message-ID: <YL9taXQ9GYzI3D6Z0QnDfdtu07uWkj5AwCUneey_nh8=.21e68c71-a500-46d7-84d7-b3a2529eedd2@github.com>

On Thu, 25 Sep 2025 11:00:18 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `ShenandoahConcurrentMark::finish_mark_work` to be more precise with what is actually needed and why. Similar to #27385.
>> 
>> Test: tier1, and tier[1,2,3]_gc_shenandoah
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   as field

Hold on a second.


class StrongRootsScope : public MarkScope {


...and:


MarkScope::MarkScope() {
  nmethod::oops_do_marking_prologue();
}

MarkScope::~MarkScope() {
  nmethod::oops_do_marking_epilogue();
}


So, what calls `nmethod::oops_do_marking_prologue`/`epilogue`, and do we know it is (not) needed?

-------------

Changes requested by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27477#pullrequestreview-3267993745

From wkemper at openjdk.org  Thu Sep 25 14:31:30 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 25 Sep 2025 14:31:30 GMT
Subject: RFR: Merge openjdk/jdk21u:master
Message-ID: <_LDGC8qT7knMCVt85MhhGa6PgaJqLT3tIXftAON4TqM=.989ef173-13b5-44f5-8a92-bb03ab6b0fcd@github.com>

Merges tag jdk-21.0.9+8

-------------

Commit messages:
 - 8367388: Tests start to fail on JDK-21 after JDK-8351907

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/223/files
  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/223.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/223/head:pull/223

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/223

From ayang at openjdk.org  Thu Sep 25 14:39:50 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 25 Sep 2025 14:39:50 GMT
Subject: RFR: 8368599: ShenandoahConcurrentMark could use
 ThreadsClaimTokenScope [v2]
In-Reply-To: <YL9taXQ9GYzI3D6Z0QnDfdtu07uWkj5AwCUneey_nh8=.21e68c71-a500-46d7-84d7-b3a2529eedd2@github.com>
References: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com>
 <qwKK3x51U4uQgi5Oco5sr6FIsFPOMBOjWV2YP4R6g78=.26efd2a1-749d-4a79-bf11-42842b20dc30@github.com>
 <YL9taXQ9GYzI3D6Z0QnDfdtu07uWkj5AwCUneey_nh8=.21e68c71-a500-46d7-84d7-b3a2529eedd2@github.com>
Message-ID: <YZ-0R5aLzMboLy_tYfTAJaw9mqGA7jDUEp0_6QWlkYk=.5c19f9f2-df5d-4833-85da-467561cb7e1b@github.com>

On Thu, 25 Sep 2025 14:16:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> So, what calls nmethod::oops_do_marking_prologue/epilogue, and do we know it is (not) needed?

`nmethod::oops_do_marking_prologue/epilogue` is meant to undo the effect of `oops_do_try_claim` in `MarkingNMethodClosure`. Since Shenandoah conc marking doesn't use `MarkingNMethodClosure`, it's not needed. (STW full-gc marking, `ShenandoahSTWMark`, uses `MarkingNMethodClosure` though.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27477#issuecomment-3334488740

From wkemper at openjdk.org  Thu Sep 25 15:39:37 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 25 Sep 2025 15:39:37 GMT
Subject: Integrated: 8368152: Shenandoah: Incorrect behavior at end of
 degenerated cycle
In-Reply-To: <dpoE92y30Rvy13TYDvp71BoCgtjNjIgUK_qQNdmLt7U=.e08dab1a-32b6-42f0-a290-c6138a79ba62@github.com>
References: <dpoE92y30Rvy13TYDvp71BoCgtjNjIgUK_qQNdmLt7U=.e08dab1a-32b6-42f0-a290-c6138a79ba62@github.com>
Message-ID: <Zjjba1JljUdQnz_xBCImlAzg78Toe5gFHOU3yzmM_As=.486f6025-907b-4488-9beb-628e5e1eb5cf@github.com>

On Wed, 24 Sep 2025 23:42:46 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Not clean, but trivial conflict resolution.

This pull request has now been integrated.

Changeset: 7fccea8f
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/7fccea8f8b714fd4795091ed0350bd1ab800514f
Stats:     145 lines in 5 files changed: 112 ins; 19 del; 14 mod

8368152: Shenandoah: Incorrect behavior at end of degenerated cycle

Reviewed-by: kdnilsen
Backport-of: f36c33c86df0400d2155bfadd9a6b5ea56743133

-------------

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/222

From wkemper at openjdk.org  Thu Sep 25 15:40:35 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 25 Sep 2025 15:40:35 GMT
Subject: Integrated: 8368499: GenShen: Do not collect age census during evac
 when adaptive tenuring is disabled
In-Reply-To: <FB1APSykTknNA9zfwLOUE36zduLMqImj7ojbkVlPxt8=.3dc64309-ea54-4224-98bb-f175f5f3791c@github.com>
References: <FB1APSykTknNA9zfwLOUE36zduLMqImj7ojbkVlPxt8=.3dc64309-ea54-4224-98bb-f175f5f3791c@github.com>
Message-ID: <3qPceQaSOSQcS9k59ZW-nee-6yjND5eWelCz8RzEdXk=.ade4846d-9ae7-4349-8843-e9c6f932c901@github.com>

On Wed, 24 Sep 2025 22:53:28 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This is a simplification to `ShenandoahEvacTracker` (which is a diagnostic feature). The ability to compute the age census during evacuation was still in the code, even though the (experimental) option to enable it was removed. Removing the rest of the code allows us to take an additional flag-check off the evacuation path and to consolidate duplicated gc stat processing code between `shControlThread` and `shGenerationalControlThread`.

This pull request has now been integrated.

Changeset: 8ca1feaf
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8ca1feaf7e29c1370853b9b95c2ee7a62c6b84b7
Stats:     250 lines in 11 files changed: 55 ins; 137 del; 58 mod

8368499: GenShen: Do not collect age census during evac when adaptive tenuring is disabled

Reviewed-by: kdnilsen, ysr

-------------

PR: https://git.openjdk.org/jdk/pull/27479

From cslucas at openjdk.org  Thu Sep 25 17:29:50 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 25 Sep 2025 17:29:50 GMT
Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to
 conc_instruction_and_data_patch
Message-ID: <dQr8jbAuv5k614QmFd4Ze1p56ZJ8uyHLCJQqHn0Q7n4=.986f1c70-82b2-4194-85fd-99ef84914933@github.com>

Hi all,

This pull request contains a backport of commit [81a1e8e1](https://github.com/openjdk/jdk/commit/81a1e8e1363446de499a59fc706221efde12dd86) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Cesar Soares Lucas on 8 Sep 2025 and was reviewed by Fei Yang, Dingli Zhang, Kelvin Nilsen and William Kemper.

I had to manually resolve a merge conflict in `TestHotSpotVMConfig.java` because the original patch modified a region of the file that is not present in this repository version of the same file.

Thanks!

-------------

Commit messages:
 - Revert some changes due to non-ZGC using the old patching type.
 - Backport 81a1e8e1363446de499a59fc706221efde12dd86

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/218/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=218&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364936
  Stats: 21 lines in 9 files changed: 0 ins; 15 del; 6 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/218.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/218/head:pull/218

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/218

From wkemper at openjdk.org  Thu Sep 25 17:29:51 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 25 Sep 2025 17:29:51 GMT
Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to
 conc_instruction_and_data_patch
In-Reply-To: <dQr8jbAuv5k614QmFd4Ze1p56ZJ8uyHLCJQqHn0Q7n4=.986f1c70-82b2-4194-85fd-99ef84914933@github.com>
References: <dQr8jbAuv5k614QmFd4Ze1p56ZJ8uyHLCJQqHn0Q7n4=.986f1c70-82b2-4194-85fd-99ef84914933@github.com>
Message-ID: <weNaou0tJiXXt_y-eV8E3js0dHCgUzc32mr55wkA_eg=.49adfebc-2dcb-4e3d-b8d8-d9546c70c1df@github.com>

On Wed, 10 Sep 2025 19:07:08 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [81a1e8e1](https://github.com/openjdk/jdk/commit/81a1e8e1363446de499a59fc706221efde12dd86) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Cesar Soares Lucas on 8 Sep 2025 and was reviewed by Fei Yang, Dingli Zhang, Kelvin Nilsen and William Kemper.
> 
> I had to manually resolve a merge conflict in `TestHotSpotVMConfig.java` because the original patch modified a region of the file that is not present in this repository version of the same file.
> 
> Thanks!

Marked as reviewed by wkemper (Committer).

-------------

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/218#pullrequestreview-3264724126

From cslucas at openjdk.org  Thu Sep 25 17:38:50 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 25 Sep 2025 17:38:50 GMT
Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to
 conc_instruction_and_data_patch [v2]
In-Reply-To: <dQr8jbAuv5k614QmFd4Ze1p56ZJ8uyHLCJQqHn0Q7n4=.986f1c70-82b2-4194-85fd-99ef84914933@github.com>
References: <dQr8jbAuv5k614QmFd4Ze1p56ZJ8uyHLCJQqHn0Q7n4=.986f1c70-82b2-4194-85fd-99ef84914933@github.com>
Message-ID: <d6oC52SUQkZBQYPSjfEz4mMbMDlzFihIm30OMMk1TLM=.0b984082-55fb-44cb-9072-4cd00010958f@github.com>

> Hi all,
> 
> This pull request contains a backport of commit [81a1e8e1](https://github.com/openjdk/jdk/commit/81a1e8e1363446de499a59fc706221efde12dd86) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Cesar Soares Lucas on 8 Sep 2025 and was reviewed by Fei Yang, Dingli Zhang, Kelvin Nilsen and William Kemper.
> 
> I had to manually resolve a merge conflict in `TestHotSpotVMConfig.java` because the original patch modified a region of the file that is not present in this repository version of the same file.
> 
> Thanks!

Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:

  This also needs to be reverted.

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/218/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/218/files/49c12b6b..af29f617

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=218&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=218&range=00-01

  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/218.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/218/head:pull/218

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/218

From cslucas at openjdk.org  Thu Sep 25 17:48:36 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 25 Sep 2025 17:48:36 GMT
Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to
 conc_instruction_and_data_patch [v3]
In-Reply-To: <dQr8jbAuv5k614QmFd4Ze1p56ZJ8uyHLCJQqHn0Q7n4=.986f1c70-82b2-4194-85fd-99ef84914933@github.com>
References: <dQr8jbAuv5k614QmFd4Ze1p56ZJ8uyHLCJQqHn0Q7n4=.986f1c70-82b2-4194-85fd-99ef84914933@github.com>
Message-ID: <AgN_uCL3wm8ogHkF1zxqLRmEg-WJqeSbG-v3nhnaoIA=.ff7a94eb-7c7c-4158-ad57-ab0f5381d132@github.com>

> Hi all,
> 
> This pull request contains a backport of commit [81a1e8e1](https://github.com/openjdk/jdk/commit/81a1e8e1363446de499a59fc706221efde12dd86) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Cesar Soares Lucas on 8 Sep 2025 and was reviewed by Fei Yang, Dingli Zhang, Kelvin Nilsen and William Kemper.
> 
> I had to manually resolve a merge conflict in `TestHotSpotVMConfig.java` because the original patch modified a region of the file that is not present in this repository version of the same file.
> 
> Thanks!

Cesar Soares Lucas has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Revert some changes due to non-ZGC using the old patching type.

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/218/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/218/files/af29f617..0020610c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=218&range=02
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=218&range=01-02

  Stats: 11 lines in 5 files changed: 9 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/218.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/218/head:pull/218

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/218

From xpeng at openjdk.org  Thu Sep 25 19:07:22 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 25 Sep 2025 19:07:22 GMT
Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using
 CAS for memory allocation [v2]
In-Reply-To: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
References: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
Message-ID: <m07b6SPgoUSj_zn4wSBsm3DHfdy0QRYDSBgFefrpCGE=.742dda90-1f9d-40d5-b9b4-dfd34b651ecf@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 mutator memory allocation to improve heap lock contention, at vey high level, here is how it works:
> * ShenandoahFreeSet holds a N (default to 13) number of ShenandoahHeapRegion* which are used by mutator threads for regular object allocations, they are called shared regions/directly allocatable regions, which are stored in PaddedEnd data structure(padded array).
> * Each mutator thread will be assigned one of the directly allocatable regions, the thread will try to allocate in the directly allocatable region with CAS atomic operation, if fails will try 2 more consecutive  directly allocatable regions in the array storing directly allocatable region.
> * If mutator thread fails after trying 3 directly allocatable regions, it will:
>    * Take heap lock
>    * Try to retire the directly allocatable regions which are ready to retire.
>    *  Iterator mutator partition and allocate directly allocatable regions and store to the padded array if any need to be retired.
>    *  Satisfy mutator allocation request if possible.
> 
> 
> I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, I have done many tests, here are some of them:
> 
> 1. Dacapo lusearch test on EC2 host with 96 CPU cores:
> Openjdk TIP:
> 
> [ec2-user at ip-172-31-42-91 jdk]$ ./master-jdk/bin/java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms4G -Xmx4G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions  -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational  -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar  -n 10 lusearch  | grep "metered full smoothing"
> ===== DaCapo tail latency, metered full smoothing: 50% 131684 usec, 90% 200192 usec, 99% 211369 usec, 99.9% 212517 usec, 99.99% 213043 usec, max 235289 usec, measured over 524288 events =====
> ===== DaCapo tail latency, metered full smoothing: 50% 1568 usec, 90% 36101 usec, 99% 42172 usec, 99.9% 42928 usec, 99.99% 43100 usec, max 43305 usec, measured over 524288 events =====
> ===== DaCapo tail latency, metered full smoothing: 50% 52644 usec, 90% 124393 usec, 99% 137711 usec, 99.9% 139355 usec, 99.99% 139749 usec, max 146722 usec, measured over 524288 events ====...

Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 131 commits:

 - Merge branch 'openjdk:master' into cas-alloc-1
 - Merge branch 'master' into cas-alloc-1
 - Move ShenandoahHeapRegionIterationClosure to shenandoahFreeSet.hpp
 - Merge branch 'openjdk:master' into cas-alloc-1
 - Fix errors caused by renaming ofAtomic to AtomicAccess
 - Merge branch 'openjdk:master' into cas-alloc-1
 - Remove unused flag
 - Merge branch 'openjdk:master' into cas-alloc-1
 - Merge branch 'cas-alloc-1' into cas-alloc
 - Merge branch 'cas-alloc-1' of https://github.com/pengxiaolong/jdk into cas-alloc-1
 - ... and 121 more: https://git.openjdk.org/jdk/compare/3c9fd768...666f2ef1

-------------

Changes: https://git.openjdk.org/jdk/pull/26171/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=01
  Stats: 735 lines in 16 files changed: 674 ins; 7 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/26171.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171

PR: https://git.openjdk.org/jdk/pull/26171

From wkemper at openjdk.org  Thu Sep 25 20:45:52 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 25 Sep 2025 20:45:52 GMT
Subject: RFR: 8264851: Shenandoah: Rework control loop mechanics to use timed
 waits
Message-ID: <ROt--V437nRJ09DJ3R4V1WSk02YAzeaf4LZZUTTR1V4=.65a89969-77d8-44f8-98d5-15ed704d3095@github.com>

We use a similar mechanism in `shGenerationalControlThread` already. Using a timed wait allows the control thread to be woken up before the wait expires.

-------------

Commit messages:
 - Add documentation and make new method private
 - Use timed wait/notify for more timely control thread reactions

Changes: https://git.openjdk.org/jdk/pull/27502/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27502&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8264851
  Stats: 28 lines in 2 files changed: 18 ins; 6 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/27502.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27502/head:pull/27502

PR: https://git.openjdk.org/jdk/pull/27502

From kdnilsen at openjdk.org  Thu Sep 25 23:39:57 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 25 Sep 2025 23:39:57 GMT
Subject: RFR: 8368681: Shenandoah: Add documentation comments for
 ShenandoahAllocationRate
Message-ID: <X-CvPPN19w1A5KVuv0iSc30y3au9r9wHhuISQr7SeIY=.2fb56236-2070-4585-9cf8-b89b7aec7dc4@github.com>

Add documentation to ShenandoahAllocationRate

-------------

Commit messages:
 - Add documentation

Changes: https://git.openjdk.org/jdk/pull/27505/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27505&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368681
  Stats: 44 lines in 2 files changed: 44 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27505.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27505/head:pull/27505

PR: https://git.openjdk.org/jdk/pull/27505

From wkemper at openjdk.org  Thu Sep 25 23:52:22 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 25 Sep 2025 23:52:22 GMT
Subject: RFR: 8368681: Shenandoah: Add documentation comments for
 ShenandoahAllocationRate
In-Reply-To: <X-CvPPN19w1A5KVuv0iSc30y3au9r9wHhuISQr7SeIY=.2fb56236-2070-4585-9cf8-b89b7aec7dc4@github.com>
References: <X-CvPPN19w1A5KVuv0iSc30y3au9r9wHhuISQr7SeIY=.2fb56236-2070-4585-9cf8-b89b7aec7dc4@github.com>
Message-ID: <DVRNqsAD6wijI3vBK8Gpb1oZzjlwecFlizYUpSq84tI=.d66f5b08-98eb-4946-a5b1-1d80d0860b0b@github.com>

On Thu, 25 Sep 2025 23:33:56 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Add documentation to ShenandoahAllocationRate

Just a few typos

src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp line 52:

> 50:   // The sampled allocation rate is computed from (allocated - _last_sample_value) / (current_time - _last_sample_time).
> 51:   // Return the newly computed rate if the sample is taken, zero if it is not an appropriate time to add a sample.
> 52:   // In the case that a new sample is not take, overwrite unaccounted_bytes_allocated with bytes allocated since

s/take/taken

src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp line 53:

> 51:   // Return the newly computed rate if the sample is taken, zero if it is not an appropriate time to add a sample.
> 52:   // In the case that a new sample is not take, overwrite unaccounted_bytes_allocated with bytes allocated since
> 53:   // the previous sample was taken (allocated - __last_sample_value).  Otherwise, overwrite unaccounted_byets_allocated

s/byets/bytes

src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp line 73:

> 71:  private:
> 72: 
> 73:   // Return the instantaneous rate calculated from from (allocated - _last_sample_value) / (time - _last_sample_time).

s/from from/from

-------------

Changes requested by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27505#pullrequestreview-3269736178
PR Review Comment: https://git.openjdk.org/jdk/pull/27505#discussion_r2380542331
PR Review Comment: https://git.openjdk.org/jdk/pull/27505#discussion_r2380542829
PR Review Comment: https://git.openjdk.org/jdk/pull/27505#discussion_r2380544508

From wkemper at openjdk.org  Thu Sep 25 23:59:22 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 25 Sep 2025 23:59:22 GMT
Subject: RFR: 8368307: Shenandoah: get_next_bit_impl should special case
 weak and strong mark bits
In-Reply-To: <xayU5wW0nJ39tai5VKrG2TwRQd9L_ifdH_h6VntcrGQ=.83639e19-7638-4130-9108-76a4273502ba@github.com>
References: <xayU5wW0nJ39tai5VKrG2TwRQd9L_ifdH_h6VntcrGQ=.83639e19-7638-4130-9108-76a4273502ba@github.com>
Message-ID: <EAEkZ_aknIhnnGoflAKDVeZeXQnGpeLLzbBFZ--Yvfw=.8a386fe0-4cf8-4780-869c-13267eeab16b@github.com>

On Wed, 24 Sep 2025 21:31:24 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Check for weak bit or strong bit when giving special handling to the next bit found in first position of word.

Changes requested by wkemper (Reviewer).

src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.inline.hpp line 138:

> 136:     idx_t index = to_words_align_down(l_index);
> 137:     bm_word_t cword = (map(index) ^ flip) >> bit_in_word(l_index);
> 138:     if ((cword & 0x03) != 0) {

Can we update the comment below to indicate that we are checking the first two bits because of strong and weak marking? 

Is there a risk here that dependents of this method will now start treating objects that are only weakly reachable as alive? Or does this fix a bug that caused us to miss such objects?

-------------

PR Review: https://git.openjdk.org/jdk/pull/27476#pullrequestreview-3269751140
PR Review Comment: https://git.openjdk.org/jdk/pull/27476#discussion_r2380554607

From xpeng at openjdk.org  Fri Sep 26 00:24:45 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 26 Sep 2025 00:24:45 GMT
Subject: RFR: 8368681: Shenandoah: Add documentation comments for
 ShenandoahAllocationRate
In-Reply-To: <X-CvPPN19w1A5KVuv0iSc30y3au9r9wHhuISQr7SeIY=.2fb56236-2070-4585-9cf8-b89b7aec7dc4@github.com>
References: <X-CvPPN19w1A5KVuv0iSc30y3au9r9wHhuISQr7SeIY=.2fb56236-2070-4585-9cf8-b89b7aec7dc4@github.com>
Message-ID: <fEQ08iqHAsj5FtJ6NmDhmHVOegKeZgIamUXYfNkqFng=.96e989bb-8193-4414-a5e9-03be0cd620a1@github.com>

On Thu, 25 Sep 2025 23:33:56 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Add documentation to ShenandoahAllocationRate

src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp line 74:

> 72: 
> 73:   // Return the instantaneous rate calculated from from (allocated - _last_sample_value) / (time - _last_sample_time).
> 74:   // Return Sentinel vlue 0.0 if (time - _last_sample_time) == 0 or if (allocated <= _last_sample_value).

s/vlue/value

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27505#discussion_r2380581112

From fandreuzzi at openjdk.org  Fri Sep 26 08:17:19 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 26 Sep 2025 08:17:19 GMT
Subject: RFR: 8368599: ShenandoahConcurrentMark could use
 ThreadsClaimTokenScope [v2]
In-Reply-To: <YZ-0R5aLzMboLy_tYfTAJaw9mqGA7jDUEp0_6QWlkYk=.5c19f9f2-df5d-4833-85da-467561cb7e1b@github.com>
References: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com>
 <qwKK3x51U4uQgi5Oco5sr6FIsFPOMBOjWV2YP4R6g78=.26efd2a1-749d-4a79-bf11-42842b20dc30@github.com>
 <YL9taXQ9GYzI3D6Z0QnDfdtu07uWkj5AwCUneey_nh8=.21e68c71-a500-46d7-84d7-b3a2529eedd2@github.com>
 <YZ-0R5aLzMboLy_tYfTAJaw9mqGA7jDUEp0_6QWlkYk=.5c19f9f2-df5d-4833-85da-467561cb7e1b@github.com>
Message-ID: <ydKuhCLLW6eLAHPeKM3oV5BPcWf3TgbvHVs2vtelQ7E=.078b4235-c87e-4048-928d-d4e64d0c936c@github.com>

On Thu, 25 Sep 2025 14:37:06 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hold on a second.
>> 
>> 
>> class StrongRootsScope : public MarkScope {
>> 
>> 
>> ...and:
>> 
>> 
>> MarkScope::MarkScope() {
>>   nmethod::oops_do_marking_prologue();
>> }
>> 
>> MarkScope::~MarkScope() {
>>   nmethod::oops_do_marking_epilogue();
>> }
>> 
>> 
>> So, what calls `nmethod::oops_do_marking_prologue`/`epilogue`, and do we know it is (not) needed?
>
>> So, what calls nmethod::oops_do_marking_prologue/epilogue, and do we know it is (not) needed?
> 
> `nmethod::oops_do_marking_prologue/epilogue` is meant to undo the effect of `oops_do_try_claim` in `MarkingNMethodClosure`. Since Shenandoah conc marking doesn't use `MarkingNMethodClosure`, it's not needed. (STW full-gc marking, `ShenandoahSTWMark`, uses `MarkingNMethodClosure` though.)

Thanks for the review @albertnetymk and @earthling-amzn.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27477#issuecomment-3337288304

From duke at openjdk.org  Fri Sep 26 08:17:23 2025
From: duke at openjdk.org (duke)
Date: Fri, 26 Sep 2025 08:17:23 GMT
Subject: RFR: 8368599: ShenandoahConcurrentMark could use
 ThreadsClaimTokenScope [v2]
In-Reply-To: <qwKK3x51U4uQgi5Oco5sr6FIsFPOMBOjWV2YP4R6g78=.26efd2a1-749d-4a79-bf11-42842b20dc30@github.com>
References: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com>
 <qwKK3x51U4uQgi5Oco5sr6FIsFPOMBOjWV2YP4R6g78=.26efd2a1-749d-4a79-bf11-42842b20dc30@github.com>
Message-ID: <pHpR64FDsdyya9WBV35OyrBoUNDuyb8ASsHeN5nDXbc=.c9b95481-000c-47cc-9498-15e0afacd829@github.com>

On Thu, 25 Sep 2025 11:00:18 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `ShenandoahConcurrentMark::finish_mark_work` to be more precise with what is actually needed and why. Similar to #27385.
>> 
>> Test: tier1, and tier[1,2,3]_gc_shenandoah
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   as field

@fandreuz 
Your change (at version b1686c28687a97ef3bc0764740c33a6dd89c0c2e) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27477#issuecomment-3337296420

From kdnilsen at openjdk.org  Fri Sep 26 08:39:29 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 26 Sep 2025 08:39:29 GMT
Subject: RFR: 8368307: Shenandoah: get_next_bit_impl should special case
 weak and strong mark bits [v2]
In-Reply-To: <xayU5wW0nJ39tai5VKrG2TwRQd9L_ifdH_h6VntcrGQ=.83639e19-7638-4130-9108-76a4273502ba@github.com>
References: <xayU5wW0nJ39tai5VKrG2TwRQd9L_ifdH_h6VntcrGQ=.83639e19-7638-4130-9108-76a4273502ba@github.com>
Message-ID: <cefFSyf2p8hYULQyNQJtCwi6uEM7oP1H5DJp4vsCAEw=.a08a7cc8-98fb-4b1d-ac2b-bf656b5a1b33@github.com>

> Check for weak bit or strong bit when giving special handling to the next bit found in first position of word.

Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Fix up comment
 - Merge remote-tracking branch 'jdk/master' into next-bit-may-be-weak
 - check for weak bit or strong bit in first bit position

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27476/files
  - new: https://git.openjdk.org/jdk/pull/27476/files/d144bdc1..a3700aa0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27476&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27476&range=00-01

  Stats: 13168 lines in 308 files changed: 7595 ins; 3835 del; 1738 mod
  Patch: https://git.openjdk.org/jdk/pull/27476.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27476/head:pull/27476

PR: https://git.openjdk.org/jdk/pull/27476

From kdnilsen at openjdk.org  Fri Sep 26 08:39:32 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 26 Sep 2025 08:39:32 GMT
Subject: RFR: 8368307: Shenandoah: get_next_bit_impl should special case
 weak and strong mark bits [v2]
In-Reply-To: <EAEkZ_aknIhnnGoflAKDVeZeXQnGpeLLzbBFZ--Yvfw=.8a386fe0-4cf8-4780-869c-13267eeab16b@github.com>
References: <xayU5wW0nJ39tai5VKrG2TwRQd9L_ifdH_h6VntcrGQ=.83639e19-7638-4130-9108-76a4273502ba@github.com>
 <EAEkZ_aknIhnnGoflAKDVeZeXQnGpeLLzbBFZ--Yvfw=.8a386fe0-4cf8-4780-869c-13267eeab16b@github.com>
Message-ID: <RS9JDd3AnOv8BcvBa4eWlEHeQjhlsGdiKr42Nfc40E8=.a018039c-723e-4410-a53a-913786809b0f@github.com>

On Thu, 25 Sep 2025 23:56:53 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Fix up comment
>>  - Merge remote-tracking branch 'jdk/master' into next-bit-may-be-weak
>>  - check for weak bit or strong bit in first bit position
>
> src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.inline.hpp line 138:
> 
>> 136:     idx_t index = to_words_align_down(l_index);
>> 137:     bm_word_t cword = (map(index) ^ flip) >> bit_in_word(l_index);
>> 138:     if ((cword & 0x03) != 0) {
> 
> Can we update the comment below to indicate that we are checking the first two bits because of strong and weak marking? 
> 
> Is there a risk here that dependents of this method will now start treating objects that are only weakly reachable as alive? Or does this fix a bug that caused us to miss such objects?

This does not fix a correctness issue.  This represents a "special" case optimization.

Basically, if either the first weak-mark or first strong-mark bits are set, we want to take this fast path to the return statement.  The code is not wrong if we fail to take this fast path.  It is simply less efficient.

I noticed that the intent of this function is to return the index of the next set bit, regardless of whether it is a weak-mark bit or a strong-mark bit, when I was writing a unit test for this function as part of https://github.com/openjdk/jdk/pull/27353.

In that PR, we introduce a new function complementary function, get_last_bit_impl(), and we use the 0x03 search pattern in that code.  So this fix mirrors the behavior of the new function.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27476#discussion_r2381373652

From kdnilsen at openjdk.org  Fri Sep 26 08:39:32 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 26 Sep 2025 08:39:32 GMT
Subject: RFR: 8368307: Shenandoah: get_next_bit_impl should special case
 weak and strong mark bits [v2]
In-Reply-To: <RS9JDd3AnOv8BcvBa4eWlEHeQjhlsGdiKr42Nfc40E8=.a018039c-723e-4410-a53a-913786809b0f@github.com>
References: <xayU5wW0nJ39tai5VKrG2TwRQd9L_ifdH_h6VntcrGQ=.83639e19-7638-4130-9108-76a4273502ba@github.com>
 <EAEkZ_aknIhnnGoflAKDVeZeXQnGpeLLzbBFZ--Yvfw=.8a386fe0-4cf8-4780-869c-13267eeab16b@github.com>
 <RS9JDd3AnOv8BcvBa4eWlEHeQjhlsGdiKr42Nfc40E8=.a018039c-723e-4410-a53a-913786809b0f@github.com>
Message-ID: <3rNS4PO9DmD_IJpPBIaj5UrRzoY7mzTMl59wU_c7q5I=.b4d766ee-fad3-4de1-abfa-2ea858d6546b@github.com>

On Fri, 26 Sep 2025 08:32:10 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.inline.hpp line 138:
>> 
>>> 136:     idx_t index = to_words_align_down(l_index);
>>> 137:     bm_word_t cword = (map(index) ^ flip) >> bit_in_word(l_index);
>>> 138:     if ((cword & 0x03) != 0) {
>> 
>> Can we update the comment below to indicate that we are checking the first two bits because of strong and weak marking? 
>> 
>> Is there a risk here that dependents of this method will now start treating objects that are only weakly reachable as alive? Or does this fix a bug that caused us to miss such objects?
>
> This does not fix a correctness issue.  This represents a "special" case optimization.
> 
> Basically, if either the first weak-mark or first strong-mark bits are set, we want to take this fast path to the return statement.  The code is not wrong if we fail to take this fast path.  It is simply less efficient.
> 
> I noticed that the intent of this function is to return the index of the next set bit, regardless of whether it is a weak-mark bit or a strong-mark bit, when I was writing a unit test for this function as part of https://github.com/openjdk/jdk/pull/27353.
> 
> In that PR, we introduce a new function complementary function, get_last_bit_impl(), and we use the 0x03 search pattern in that code.  So this fix mirrors the behavior of the new function.

I'll fix this comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27476#discussion_r2381379088

From kdnilsen at openjdk.org  Fri Sep 26 10:23:14 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 26 Sep 2025 10:23:14 GMT
Subject: RFR: 8358735: GenShen: bug in #undef'd code in block_start()
Message-ID: <JTwkqXthnFpzrfVsFosxLf2uDWRBXWguvioNPr-XqWA=.41881654-4539-4920-9d65-e93b210913f6@github.com>

When scanning a range of dirty cards within the GenShen remembered set, we need to find the object that spans the beginning of the left-most dirty card.  The existing code is not reliable following class unloading.

The new code uses the marking context when it is available to determine the location of live objects that reside below TAMS within each region.  Above TAMS, all objects are presumed live and parsable.

-------------

Commit messages:
 - cleanup code for review
 - Fix order of include files
 - fix white space
 - disable for debug build, alphabetic order for includes
 - add explicit typecast to avoid compiler warning message
 - Remove troublesome assert that assumes lock is held
 - Merge remote-tracking branch 'jdk/master' into finish-block-start
 - Add handling for first_object_start() past end of range
 - Revert extraneous changes
 - Add special handling above TAMS
 - ... and 15 more: https://git.openjdk.org/jdk/compare/01d7554b...76979421

Changes: https://git.openjdk.org/jdk/pull/27353/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27353&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358735
  Stats: 849 lines in 11 files changed: 812 ins; 5 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/27353.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27353/head:pull/27353

PR: https://git.openjdk.org/jdk/pull/27353

From kdnilsen at openjdk.org  Fri Sep 26 10:23:14 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 26 Sep 2025 10:23:14 GMT
Subject: RFR: 8358735: GenShen: bug in #undef'd code in block_start()
In-Reply-To: <JTwkqXthnFpzrfVsFosxLf2uDWRBXWguvioNPr-XqWA=.41881654-4539-4920-9d65-e93b210913f6@github.com>
References: <JTwkqXthnFpzrfVsFosxLf2uDWRBXWguvioNPr-XqWA=.41881654-4539-4920-9d65-e93b210913f6@github.com>
Message-ID: <tC7z7lXSAabDOW9J_2blAPWyle-nGQNR2oIkYJDeF24=.e2ca0fd4-5f86-46e3-b6b9-401189dac393@github.com>

On Wed, 17 Sep 2025 20:12:49 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> When scanning a range of dirty cards within the GenShen remembered set, we need to find the object that spans the beginning of the left-most dirty card.  The existing code is not reliable following class unloading.
> 
> The new code uses the marking context when it is available to determine the location of live objects that reside below TAMS within each region.  Above TAMS, all objects are presumed live and parsable.

/author: ysramakrishna

Have confirmed with several hundred runs that this fixes the error typically observed within 100 runs on master.

Reproducer:

~/github/jdk.finish-block-start/build/linux-x86_64-server-fastdebug/jdk/bin/java \
  -XX:+PrintFlagsFinal -XX:-UseCompressedOops \
  -XX:-UseCompressedClassPointers -XX:+AlwaysPreTouch  -Xms10g -Xmx10g \
  -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational \
  -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions \
  -XX:-ShenandoahUncommit -XX:+ShenandoahVerify -XX:+ShenandoahAllocFailureALot -XX:+UseStringDeduplication \
  -Xlog:async -Xlog:"gc*=info,safepoint*=info,handshake*=info"  \
  -jar  ~/lib/dacapo-23.11-chopin.jar --scratch-directory ./tmp/dacapo-scratch/tomcat \
  --no-validation --iterations 5 --log-directory ./tmp/dacapo-log/tomcat tomcat \
  > trial.$COUNT.out 2>trial.$COUNT.err

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27353#issuecomment-3304431762
PR Comment: https://git.openjdk.org/jdk/pull/27353#issuecomment-3337947338

From wkemper at openjdk.org  Fri Sep 26 15:13:55 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 26 Sep 2025 15:13:55 GMT
Subject: RFR: 8368307: Shenandoah: get_next_bit_impl should special case
 weak and strong mark bits [v2]
In-Reply-To: <cefFSyf2p8hYULQyNQJtCwi6uEM7oP1H5DJp4vsCAEw=.a08a7cc8-98fb-4b1d-ac2b-bf656b5a1b33@github.com>
References: <xayU5wW0nJ39tai5VKrG2TwRQd9L_ifdH_h6VntcrGQ=.83639e19-7638-4130-9108-76a4273502ba@github.com>
 <cefFSyf2p8hYULQyNQJtCwi6uEM7oP1H5DJp4vsCAEw=.a08a7cc8-98fb-4b1d-ac2b-bf656b5a1b33@github.com>
Message-ID: <MV5WhEVRnS6djxjBfXIG0pOxp2snYNMXfPv9C20hQNQ=.776f0323-bbbc-4c8a-be60-2bb96100771d@github.com>

On Fri, 26 Sep 2025 08:39:29 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Check for weak bit or strong bit when giving special handling to the next bit found in first position of word.
>
> Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Fix up comment
>  - Merge remote-tracking branch 'jdk/master' into next-bit-may-be-weak
>  - check for weak bit or strong bit in first bit position

Marked as reviewed by wkemper (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27476#pullrequestreview-3272694762

From wkemper at openjdk.org  Fri Sep 26 15:13:57 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 26 Sep 2025 15:13:57 GMT
Subject: RFR: 8368307: Shenandoah: get_next_bit_impl should special case
 weak and strong mark bits [v2]
In-Reply-To: <3rNS4PO9DmD_IJpPBIaj5UrRzoY7mzTMl59wU_c7q5I=.b4d766ee-fad3-4de1-abfa-2ea858d6546b@github.com>
References: <xayU5wW0nJ39tai5VKrG2TwRQd9L_ifdH_h6VntcrGQ=.83639e19-7638-4130-9108-76a4273502ba@github.com>
 <EAEkZ_aknIhnnGoflAKDVeZeXQnGpeLLzbBFZ--Yvfw=.8a386fe0-4cf8-4780-869c-13267eeab16b@github.com>
 <RS9JDd3AnOv8BcvBa4eWlEHeQjhlsGdiKr42Nfc40E8=.a018039c-723e-4410-a53a-913786809b0f@github.com>
 <3rNS4PO9DmD_IJpPBIaj5UrRzoY7mzTMl59wU_c7q5I=.b4d766ee-fad3-4de1-abfa-2ea858d6546b@github.com>
Message-ID: <xW6dbwuyMP8stD4dhKfaD1o1QnfIewzC7Av1UGjHYFY=.990f320a-2563-4c58-be5b-eb886f5dc15d@github.com>

On Fri, 26 Sep 2025 08:33:24 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This does not fix a correctness issue.  This represents a "special" case optimization.
>> 
>> Basically, if either the first weak-mark or first strong-mark bits are set, we want to take this fast path to the return statement.  The code is not wrong if we fail to take this fast path.  It is simply less efficient.
>> 
>> I noticed that the intent of this function is to return the index of the next set bit, regardless of whether it is a weak-mark bit or a strong-mark bit, when I was writing a unit test for this function as part of https://github.com/openjdk/jdk/pull/27353.
>> 
>> In that PR, we introduce a new function complementary function, get_last_bit_impl(), and we use the 0x03 search pattern in that code.  So this fix mirrors the behavior of the new function.
>
> I'll fix this comment.

Got i t, thank you!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27476#discussion_r2382711211

From wkemper at openjdk.org  Fri Sep 26 17:17:53 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 26 Sep 2025 17:17:53 GMT
Subject: RFR: Merge openjdk/jdk21u:master [v2]
In-Reply-To: <_LDGC8qT7knMCVt85MhhGa6PgaJqLT3tIXftAON4TqM=.989ef173-13b5-44f5-8a92-bb03ab6b0fcd@github.com>
References: <_LDGC8qT7knMCVt85MhhGa6PgaJqLT3tIXftAON4TqM=.989ef173-13b5-44f5-8a92-bb03ab6b0fcd@github.com>
Message-ID: <dalnscUNsjxf38pNcEnk5qY38JGQ_RYhfmW4KpHO1Iw=.b6a2be6a-f408-43c8-882d-c94cb57fd603@github.com>

> Merges tag jdk-21.0.9+8

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.

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/223/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/223/files/dea855e1..dea855e1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=223&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=223&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/223.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/223/head:pull/223

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/223

From wkemper at openjdk.org  Fri Sep 26 17:17:53 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 26 Sep 2025 17:17:53 GMT
Subject: Integrated: Merge openjdk/jdk21u:master
In-Reply-To: <_LDGC8qT7knMCVt85MhhGa6PgaJqLT3tIXftAON4TqM=.989ef173-13b5-44f5-8a92-bb03ab6b0fcd@github.com>
References: <_LDGC8qT7knMCVt85MhhGa6PgaJqLT3tIXftAON4TqM=.989ef173-13b5-44f5-8a92-bb03ab6b0fcd@github.com>
Message-ID: <AnoPBknjeU99AQtqlmwsxiF1oLRtv58yAOILwh5cAwY=.6ec27a38-7bb5-451b-ab61-7842be8808be@github.com>

On Thu, 25 Sep 2025 14:23:01 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.9+8

This pull request has now been integrated.

Changeset: 360af664
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/360af66493d1e8bdacdb5a104daa3c6e3ec32880
Stats:     7 lines in 1 file changed: 6 ins; 0 del; 1 mod

Merge

-------------

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/223

From duke at openjdk.org  Fri Sep 26 19:59:09 2025
From: duke at openjdk.org (duke)
Date: Fri, 26 Sep 2025 19:59:09 GMT
Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to
 conc_instruction_and_data_patch [v3]
In-Reply-To: <AgN_uCL3wm8ogHkF1zxqLRmEg-WJqeSbG-v3nhnaoIA=.ff7a94eb-7c7c-4158-ad57-ab0f5381d132@github.com>
References: <dQr8jbAuv5k614QmFd4Ze1p56ZJ8uyHLCJQqHn0Q7n4=.986f1c70-82b2-4194-85fd-99ef84914933@github.com>
 <AgN_uCL3wm8ogHkF1zxqLRmEg-WJqeSbG-v3nhnaoIA=.ff7a94eb-7c7c-4158-ad57-ab0f5381d132@github.com>
Message-ID: <EwChFQrxiomo4QWTglqhiFL5KywnHxAb-hrGsZ_7THM=.6ca0c9d9-00e5-485f-be78-676f03c37cfc@github.com>

On Thu, 25 Sep 2025 17:48:36 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [81a1e8e1](https://github.com/openjdk/jdk/commit/81a1e8e1363446de499a59fc706221efde12dd86) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by Cesar Soares Lucas on 8 Sep 2025 and was reviewed by Fei Yang, Dingli Zhang, Kelvin Nilsen and William Kemper.
>> 
>> I had to manually resolve a merge conflict in `TestHotSpotVMConfig.java` because the original patch modified a region of the file that is not present in this repository version of the same file.
>> 
>> Thanks!
>
> Cesar Soares Lucas has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Revert some changes due to non-ZGC using the old patching type.

@JohnTortugo 
Your change (at version 0020610c8bd430ab8b1e4fe13a3d1e4875e702c7) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/shenandoah-jdk21u/pull/218#issuecomment-3340289073

From kdnilsen at openjdk.org  Sat Sep 27 04:10:22 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sat, 27 Sep 2025 04:10:22 GMT
Subject: Integrated: 8368307: Shenandoah: get_next_bit_impl should special case
 weak and strong mark bits
In-Reply-To: <xayU5wW0nJ39tai5VKrG2TwRQd9L_ifdH_h6VntcrGQ=.83639e19-7638-4130-9108-76a4273502ba@github.com>
References: <xayU5wW0nJ39tai5VKrG2TwRQd9L_ifdH_h6VntcrGQ=.83639e19-7638-4130-9108-76a4273502ba@github.com>
Message-ID: <gXZLYnBYfWlEB6KTLJ71kzslFmt3VcNfEpkic9V-EF0=.7aac157b-65cf-443c-a000-b65932342a8d@github.com>

On Wed, 24 Sep 2025 21:31:24 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Check for weak bit or strong bit when giving special handling to the next bit found in first position of word.

This pull request has now been integrated.

Changeset: af8fb20a
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/af8fb20ac0325a231ee14bd72e9764e02ca07681
Stats:     8 lines in 1 file changed: 0 ins; 2 del; 6 mod

8368307: Shenandoah: get_next_bit_impl should special case weak and strong mark bits

Reviewed-by: wkemper

-------------

PR: https://git.openjdk.org/jdk/pull/27476

From kdnilsen at openjdk.org  Sat Sep 27 23:13:34 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sat, 27 Sep 2025 23:13:34 GMT
Subject: RFR: 8368681: Shenandoah: Add documentation comments for
 ShenandoahAllocationRate [v2]
In-Reply-To: <X-CvPPN19w1A5KVuv0iSc30y3au9r9wHhuISQr7SeIY=.2fb56236-2070-4585-9cf8-b89b7aec7dc4@github.com>
References: <X-CvPPN19w1A5KVuv0iSc30y3au9r9wHhuISQr7SeIY=.2fb56236-2070-4585-9cf8-b89b7aec7dc4@github.com>
Message-ID: <GkWjWcWY8Ovl9DIitUg2ivSxP2a9cZchgGEq1WVmsuE=.aa4fa2e3-81e8-403a-a1e8-f71c2b609119@github.com>

> Add documentation to ShenandoahAllocationRate

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  Fix several typos

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27505/files
  - new: https://git.openjdk.org/jdk/pull/27505/files/2dce29d2..35bce7e3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27505&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27505&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/27505.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27505/head:pull/27505

PR: https://git.openjdk.org/jdk/pull/27505

From kdnilsen at openjdk.org  Sat Sep 27 23:13:35 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sat, 27 Sep 2025 23:13:35 GMT
Subject: RFR: 8368681: Shenandoah: Add documentation comments for
 ShenandoahAllocationRate [v2]
In-Reply-To: <DVRNqsAD6wijI3vBK8Gpb1oZzjlwecFlizYUpSq84tI=.d66f5b08-98eb-4946-a5b1-1d80d0860b0b@github.com>
References: <X-CvPPN19w1A5KVuv0iSc30y3au9r9wHhuISQr7SeIY=.2fb56236-2070-4585-9cf8-b89b7aec7dc4@github.com>
 <DVRNqsAD6wijI3vBK8Gpb1oZzjlwecFlizYUpSq84tI=.d66f5b08-98eb-4946-a5b1-1d80d0860b0b@github.com>
Message-ID: <29b4Jj0ouaoWbHsGS_Sqfiji0TZwdb0XXoRmNSEoIWI=.fb31b179-3101-4627-9ee9-a9df25ba3861@github.com>

On Thu, 25 Sep 2025 23:46:11 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix several typos
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp line 53:
> 
>> 51:   // Return the newly computed rate if the sample is taken, zero if it is not an appropriate time to add a sample.
>> 52:   // In the case that a new sample is not take, overwrite unaccounted_bytes_allocated with bytes allocated since
>> 53:   // the previous sample was taken (allocated - __last_sample_value).  Otherwise, overwrite unaccounted_byets_allocated
> 
> s/byets/bytes

Thanks.  Fixed.

> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp line 73:
> 
>> 71:  private:
>> 72: 
>> 73:   // Return the instantaneous rate calculated from from (allocated - _last_sample_value) / (time - _last_sample_time).
> 
> s/from from/from

Thanks.  Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27505#discussion_r2384381257
PR Review Comment: https://git.openjdk.org/jdk/pull/27505#discussion_r2384381400

From kdnilsen at openjdk.org  Sat Sep 27 23:13:37 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sat, 27 Sep 2025 23:13:37 GMT
Subject: RFR: 8368681: Shenandoah: Add documentation comments for
 ShenandoahAllocationRate [v2]
In-Reply-To: <fEQ08iqHAsj5FtJ6NmDhmHVOegKeZgIamUXYfNkqFng=.96e989bb-8193-4414-a5e9-03be0cd620a1@github.com>
References: <X-CvPPN19w1A5KVuv0iSc30y3au9r9wHhuISQr7SeIY=.2fb56236-2070-4585-9cf8-b89b7aec7dc4@github.com>
 <fEQ08iqHAsj5FtJ6NmDhmHVOegKeZgIamUXYfNkqFng=.96e989bb-8193-4414-a5e9-03be0cd620a1@github.com>
Message-ID: <poFjf_ccNSkdTTkgj40ajIZYsFJ5ZGdsuXZlkftFEiY=.808587b3-5505-41f2-8672-84689d2d15a3@github.com>

On Fri, 26 Sep 2025 00:22:14 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix several typos
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp line 74:
> 
>> 72: 
>> 73:   // Return the instantaneous rate calculated from from (allocated - _last_sample_value) / (time - _last_sample_time).
>> 74:   // Return Sentinel vlue 0.0 if (time - _last_sample_time) == 0 or if (allocated <= _last_sample_value).
> 
> s/vlue/value

Thanks. Fixed.

(Sorry Xiaolong and William for so many typos in this PR.  Thanks for your careful reviews.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27505#discussion_r2384381630

From kdnilsen at openjdk.org  Sun Sep 28 16:32:14 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sun, 28 Sep 2025 16:32:14 GMT
Subject: RFR: 8264851: Shenandoah: Rework control loop mechanics to use
 timed waits
In-Reply-To: <ROt--V437nRJ09DJ3R4V1WSk02YAzeaf4LZZUTTR1V4=.65a89969-77d8-44f8-98d5-15ed704d3095@github.com>
References: <ROt--V437nRJ09DJ3R4V1WSk02YAzeaf4LZZUTTR1V4=.65a89969-77d8-44f8-98d5-15ed704d3095@github.com>
Message-ID: <coHhbtloI58U5aY1JYF8A6kC1trGMXquVVNVgPy2PXs=.990ebff9-d0b1-498d-9a3a-961a2e15f877@github.com>

On Thu, 25 Sep 2025 20:35:59 GMT, William Kemper <wkemper at openjdk.org> wrote:

> We use a similar mechanism in `shGenerationalControlThread` already. Using a timed wait allows the control thread to be woken up before the wait expires.

Marked as reviewed by kdnilsen (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27502#pullrequestreview-3277156578

From kdnilsen at openjdk.org  Sun Sep 28 21:44:14 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sun, 28 Sep 2025 21:44:14 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v4]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <bp18eaB-RHSGdwJTKH38sm2byqjsYJtXhby6FmPNzSM=.e082adce-1e4d-43b4-8730-36e31388f60b@github.com>

> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
> 
> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
> 
> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  revert changes to shenandoahAdaptiveHeuristics.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/cd9522af..46717a74

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=02-03

  Stats: 5 lines in 1 file changed: 3 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26867.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26867/head:pull/26867

PR: https://git.openjdk.org/jdk/pull/26867

From kdnilsen at openjdk.org  Sun Sep 28 23:45:18 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sun, 28 Sep 2025 23:45:18 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v3]
In-Reply-To: <h7wGTy_BxiWCprqyz9qtZTsKHq4zu1o6eO16oSHnAFo=.31658967-978b-492c-9309-d24af732b67c@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
 <dEUIaXmSftNpVQ-tqfFsAXetwlMbvEBWqbMp9vdTTPY=.da1e4904-f814-434d-b2e9-25aa1ded47d5@github.com>
 <0DIlqJVwgCnx2FvbXZuDySjJ3hz241ag41o3BCHkSuY=.ac51c769-c5c0-4750-99b4-0ff43f864d33@github.com>
 <h7wGTy_BxiWCprqyz9qtZTsKHq4zu1o6eO16oSHnAFo=.31658967-978b-492c-9309-d24af732b67c@github.com>
Message-ID: <-h1hI8i3oFf5q81lymjg6wVR3r0RMA3ZCF-z6-m7dTU=.52f09166-ea4d-445e-9393-12923464cdf2@github.com>

On Fri, 12 Sep 2025 17:37:01 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 372:
>> 
>>> 370:       _last_sample_time = now;
>>> 371:       _last_sample_value = allocated;
>>> 372:     }
>> 
>> This was a bug.  If we don't update the average, we should not restart the time until next sample and we should not overwrite the value of _last_sample_value.
>
> Let's split this out into a different PR.

I reverted these changes, addressed this issue in separate PR https://github.com/openjdk/jdk/pull/27398, and merged from mainline.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2386423882

From kdnilsen at openjdk.org  Sun Sep 28 23:52:07 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sun, 28 Sep 2025 23:52:07 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v5]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <1GU4oXKtR0svO4h0rBVbeUdApNLbcuTNbRwg2M2qMSs=.dcc9cc11-a298-4d3e-920f-30caf7ed4f92@github.com>

> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
> 
> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
> 
> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.

Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 116 commits:

 - Merge remote-tracking branch 'jdk/master' into freeset-has-authoritative-tallies
 - revert changes to shenandoahAdaptiveHeuristics.cpp
 - another tweak to make GHA gtest happy
 - Add include file for missing declaration
 - Fix ShenandoahAllocationRate::sample() and remove debug scaffolding
 - Remove debug instrumentation
 - Cleanup make_all_regions_unavailable()
 - Remove RENAISSANCE debugging instrumentation
 - Replace MEMORY_USAGE debugging with assertions
 - Zero [empty_]region_counts in make_all_regions_unavailable plus lots of debug instrumentation
 - ... and 106 more: https://git.openjdk.org/jdk/compare/320230db...7fad8482

-------------

Changes: https://git.openjdk.org/jdk/pull/26867/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=04
  Stats: 3110 lines in 34 files changed: 1978 ins; 539 del; 593 mod
  Patch: https://git.openjdk.org/jdk/pull/26867.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26867/head:pull/26867

PR: https://git.openjdk.org/jdk/pull/26867

From kdnilsen at openjdk.org  Mon Sep 29 00:05:16 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 29 Sep 2025 00:05:16 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v3]
In-Reply-To: <RZZZ1pjhaPeJ24NcfE8ThIa3no1l6kLIpxzrv4Uzg2I=.8d2bd458-ce72-43b0-8f09-b919a2fa55b8@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
 <dEUIaXmSftNpVQ-tqfFsAXetwlMbvEBWqbMp9vdTTPY=.da1e4904-f814-434d-b2e9-25aa1ded47d5@github.com>
 <RZZZ1pjhaPeJ24NcfE8ThIa3no1l6kLIpxzrv4Uzg2I=.8d2bd458-ce72-43b0-8f09-b919a2fa55b8@github.com>
Message-ID: <kMkm7UEELjM-yh_znMOSpwh6RwR4FQeCym5wTG7UWFE=.a297bb8c-0966-4e1b-8693-b1b91f44dbcd@github.com>

On Fri, 12 Sep 2025 17:17:17 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   another tweak to make GHA gtest happy
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 3271:
> 
>> 3269:   }
>> 3270: }
>> 3271: 
> 
> Maybe we no longer need regular bypass because CDS no longer needs regular bypass.

ShenandoahFreeSet::decrease_humongous_waste_for_regular_bypass() is called from ShenandoahHeapRegion::decrement_humongous_waste().

ShenandoahHeapRegion::decrement_humongous_waste() is called from ShenandoahHeapRegion::make_trash().

It looks to me like we still need this functionality.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2386436422

From kdnilsen at openjdk.org  Mon Sep 29 00:13:41 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 29 Sep 2025 00:13:41 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v6]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <pEBnj4cTLGOpva1YfKDnfMNVGLEFuohcswfdfUCXoL0=.bcc211fa-a7e0-4b29-b26c-1774448fa100@github.com>

> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
> 
> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
> 
> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  Change spelling of symbolic constant in test program

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/7fad8482..ad45b667

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=04-05

  Stats: 6 lines in 1 file changed: 2 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26867.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26867/head:pull/26867

PR: https://git.openjdk.org/jdk/pull/26867

From kdnilsen at openjdk.org  Mon Sep 29 00:13:42 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 29 Sep 2025 00:13:42 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v3]
In-Reply-To: <Db1uIscnLCsYsdoEHp8ya19Z5narnOm5B_1I1bQPjE4=.f90cd251-31f4-47b7-83e9-a5bcc7f60c1a@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
 <dEUIaXmSftNpVQ-tqfFsAXetwlMbvEBWqbMp9vdTTPY=.da1e4904-f814-434d-b2e9-25aa1ded47d5@github.com>
 <Db1uIscnLCsYsdoEHp8ya19Z5narnOm5B_1I1bQPjE4=.f90cd251-31f4-47b7-83e9-a5bcc7f60c1a@github.com>
Message-ID: <OqfxIhtqQzZZ6a0UguYApErMPKNiY2AfKXYwFX6SFtU=.a1fd9915-778f-4166-a5ae-42b31126014e@github.com>

On Fri, 12 Sep 2025 18:13:54 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   another tweak to make GHA gtest happy
>
> test/hotspot/jtreg/gc/shenandoah/mxbeans/TestChurnNotifications.java line 162:
> 
>> 160:         long count = TARGET_MB * 1024 * 1024 / (16 + 4 * size);
>> 161: 
>> 162:         long anticipated_humongous_waste_per_array = 124_272;
> 
> Define ANTICIPATED_HUMONGOUS_WASTE_PER_ARRAY as a static constant.

I've made this change

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2386439133

From kdnilsen at openjdk.org  Mon Sep 29 03:40:16 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 29 Sep 2025 03:40:16 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v7]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <pl7JnaXA-Dclv2FTjizSAOMrl3IEwk1rJeM_AzDNVZM=.dfb554f3-0a5b-4a92-a485-dfe166ed6ab6@github.com>

> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
> 
> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
> 
> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.

Kelvin Nilsen has updated the pull request incrementally with two additional commits since the last revision:

 - Fix typo introduced during merge
 - Use OO implementation of ShenandoahGeneration::used()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/ad45b667..144ace0b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=05-06

  Stats: 43 lines in 5 files changed: 21 ins; 15 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/26867.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26867/head:pull/26867

PR: https://git.openjdk.org/jdk/pull/26867

From myankelevich at openjdk.org  Mon Sep 29 10:28:19 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 29 Sep 2025 10:28:19 GMT
Subject: RFR: 8365072: Refactor tests to use PEM API (Phase 2) [v3]
In-Reply-To: <_Qf2f6cwWoaNPHpm8TfYeWQTiiqhn-z291PeGY7uP6U=.8e77e560-d233-4232-86e8-4e0da5180947@github.com>
References: <_Qf2f6cwWoaNPHpm8TfYeWQTiiqhn-z291PeGY7uP6U=.8e77e560-d233-4232-86e8-4e0da5180947@github.com>
Message-ID: <iWr9NfPTK1SgsC0M8bFlnv0tRvIeCPI4P_X9J_ddrHo=.685f585d-dcad-4c49-b3e8-5884faeeb05f@github.com>

> Tests changed in this PR: 
> 1. test/jdk/java/security/cert/CertPathBuilder/selfIssued/StatusLoopDependency.java
> 2. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevel.java
> 3. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevelRevoked.java
> 6. test/jdk/sun/security/ssl/ClientHandshaker/RSAExport.java
> 7. test/jdk/javax/net/ssl/ServerName/SSLSocketSNISensitive.java
> 9. test/jdk/sun/security/ssl/X509TrustManagerImpl/BasicConstraints.java
> 10. test/jdk/sun/security/ssl/X509TrustManagerImpl/ComodoHacker.java
> 11. test/jdk/javax/net/ssl/interop/ClientHelloInterOp.java
> 12. test/jdk/sun/security/rsa/InvalidBitString.java
> 14. test/jdk/java/security/cert/CertPathBuilder/NoExtensions.java
> 17. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java
> 19. test/jdk/sun/security/x509/X509CRLImpl/Verify.java
> 
> PEMRecord tests will be done under a subtask [JDK-8367326](https://bugs.openjdk.org/browse/JDK-8367326)

Mikhail Yankelevich has updated the pull request incrementally with 364 additional commits since the last revision:

 - removed pemrecord usage
 - 8365190: Remove LockingMode related code from share
   
   Reviewed-by: aboldtch, dholmes, ayang, coleenp, lmesnik, rcastanedalo
 - 8367025: zIndexDistributor.hpp uses angle-bracket inclusion of globalDefinitions.hpp
   
   Reviewed-by: aboldtch, tschatzl, jwaters
 - 8360219: [AIX] assert(locals_base >= l2) failed: bad placement
   
   Reviewed-by: dlong, mdoerr
 - 8366864: Sort os/linux includes
   
   Reviewed-by: ayang, dholmes
 - 8366874: Test gc/arguments/TestParallelGCErgo.java fails with UseTransparentHugePages
   
   Reviewed-by: ayang, shade, stefank, tschatzl
 - 8351260: java.lang.AssertionError: Unexpected type tree: (ERROR) = (ERROR)
   
   Reviewed-by: vromero
 - 8365776: Convert JShell tests to use JUnit instead of TestNG
   
   Reviewed-by: vromero
 - 8354871: Replace stack map frame type magics with constants
   
   Reviewed-by: liach
 - 8361533: Apply java.io.Serial annotations in java.logging
   
   Reviewed-by: rriggs
 - ... and 354 more: https://git.openjdk.org/jdk/compare/d44cb277...e0be5eaa

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27194/files
  - new: https://git.openjdk.org/jdk/pull/27194/files/d44cb277..e0be5eaa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27194&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27194&range=01-02

  Stats: 53711 lines in 1891 files changed: 31453 ins; 14034 del; 8224 mod
  Patch: https://git.openjdk.org/jdk/pull/27194.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27194/head:pull/27194

PR: https://git.openjdk.org/jdk/pull/27194

From wkemper at openjdk.org  Mon Sep 29 16:43:38 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 29 Sep 2025 16:43:38 GMT
Subject: RFR: 8358735: GenShen: bug in #undef'd code in block_start()
In-Reply-To: <JTwkqXthnFpzrfVsFosxLf2uDWRBXWguvioNPr-XqWA=.41881654-4539-4920-9d65-e93b210913f6@github.com>
References: <JTwkqXthnFpzrfVsFosxLf2uDWRBXWguvioNPr-XqWA=.41881654-4539-4920-9d65-e93b210913f6@github.com>
Message-ID: <X8u7mX4HnBM1mz5YRRebpoZq0CsLzrnNyl6yzZv6eNM=.693ee00e-8f7e-4b9a-a63e-cdaf65c0bb1c@github.com>

On Wed, 17 Sep 2025 20:12:49 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> When scanning a range of dirty cards within the GenShen remembered set, we need to find the object that spans the beginning of the left-most dirty card.  The existing code is not reliable following class unloading.
> 
> The new code uses the marking context when it is available to determine the location of live objects that reside below TAMS within each region.  Above TAMS, all objects are presumed live and parsable.

src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.hpp line 132:

> 130: 
> 131:   // Search for last one in the range [l_index, r_index).  Return r_index if not found.
> 132:   inline idx_t get_prev_one_offset (idx_t l_index, idx_t r_index) const;

Nit: Some idiosyncratic formatting here (space before opening parenthesis).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27353#discussion_r2388596886

From wkemper at openjdk.org  Mon Sep 29 16:49:37 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 29 Sep 2025 16:49:37 GMT
Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need
 accurate live_data [v9]
In-Reply-To: <8GvpkoZ5-Pso8XG-AKeR0QnlBQr0op9E-lvQMS12lTI=.6c88343d-4c74-4f29-a528-f499f559a2bd@github.com>
References: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
 <8GvpkoZ5-Pso8XG-AKeR0QnlBQr0op9E-lvQMS12lTI=.6c88343d-4c74-4f29-a528-f499f559a2bd@github.com>
Message-ID: <nDkv97Tf4j0ailCsZzEU5CE5OCaPOdimeHXVWnva5aQ=.97ad3a84-42dd-46eb-aa31-ce89863c01f3@github.com>

On Tue, 16 Sep 2025 21:29:34 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected.  In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region.  This is typically ok for young regions, where the amount of live data determines whether a region should be added to the collection set during the final-mark safepoint.
>> 
>> However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated.  In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended.
>> 
>> This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation errors after merge

Suggest a small refactoring to reduce code duplication.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 91:

> 89:   }
> 90: 
> 91:   // Between consecutive mixed-evacuation cycles, the live data within each candidate region may change due to

I think we could reduce some duplication and call `recalibrate_old_collection_candidates_live_memory` here if the function didn't have the side effect of updating `_live_bytes_in_unprocessed_candidates`. Perhaps the function could return `total_live_data` and be `const`?

-------------

Changes requested by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24319#pullrequestreview-3231974347
PR Review Comment: https://git.openjdk.org/jdk/pull/24319#discussion_r2353850889

From cslucas at openjdk.org  Mon Sep 29 17:38:39 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Mon, 29 Sep 2025 17:38:39 GMT
Subject: Integrated: 8364936: Shenandoah: Switch nmethod entry barriers to
 conc_instruction_and_data_patch
In-Reply-To: <dQr8jbAuv5k614QmFd4Ze1p56ZJ8uyHLCJQqHn0Q7n4=.986f1c70-82b2-4194-85fd-99ef84914933@github.com>
References: <dQr8jbAuv5k614QmFd4Ze1p56ZJ8uyHLCJQqHn0Q7n4=.986f1c70-82b2-4194-85fd-99ef84914933@github.com>
Message-ID: <1Zy8zeENa6ebkQtFzVa6msnN1z7-CPFNLnD-7xLEqls=.b124edd9-f65c-4045-ba2a-83cc1aa5eb4e@github.com>

On Wed, 10 Sep 2025 19:07:08 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [81a1e8e1](https://github.com/openjdk/jdk/commit/81a1e8e1363446de499a59fc706221efde12dd86) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Cesar Soares Lucas on 8 Sep 2025 and was reviewed by Fei Yang, Dingli Zhang, Kelvin Nilsen and William Kemper.
> 
> I had to manually resolve a merge conflict in `TestHotSpotVMConfig.java` because the original patch modified a region of the file that is not present in this repository version of the same file.
> 
> Thanks!

This pull request has now been integrated.

Changeset: d9eaa690
Author:    Cesar Soares Lucas <cslucas at openjdk.org>
Committer: William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/d9eaa6902751fdf37c3a20714f32e6d392112fc0
Stats:     3 lines in 3 files changed: 0 ins; 0 del; 3 mod

8364936: Shenandoah: Switch nmethod entry barriers to conc_instruction_and_data_patch

Reviewed-by: wkemper
Backport-of: 81a1e8e1363446de499a59fc706221efde12dd86

-------------

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/218

From xpeng at openjdk.org  Mon Sep 29 20:28:15 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Mon, 29 Sep 2025 20:28:15 GMT
Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using
 CAS for memory allocation [v3]
In-Reply-To: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
References: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
Message-ID: <RU-wPoVGvNBNy-PBOQYJFpeWAB0ptqc7fXo6VQwKW8I=.8f20002b-0cb3-4418-bc0c-fb5d4a4ddecd@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 mutator memory allocation to improve heap lock contention, at vey high level, here is how it works:
> * ShenandoahFreeSet holds a N (default to 13) number of ShenandoahHeapRegion* which are used by mutator threads for regular object allocations, they are called shared regions/directly allocatable regions, which are stored in PaddedEnd data structure(padded array).
> * Each mutator thread will be assigned one of the directly allocatable regions, the thread will try to allocate in the directly allocatable region with CAS atomic operation, if fails will try 2 more consecutive  directly allocatable regions in the array storing directly allocatable region.
> * If mutator thread fails after trying 3 directly allocatable regions, it will:
>    * Take heap lock
>    * Try to retire the directly allocatable regions which are ready to retire.
>    *  Iterator mutator partition and allocate directly allocatable regions and store to the padded array if any need to be retired.
>    *  Satisfy mutator allocation request if possible.
> 
> 
> I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, I have done many tests, here are some of them:
> 
> 1. Dacapo lusearch test on EC2 host with 96 CPU cores:
> Openjdk TIP:
> 
> [ec2-user at ip-172-31-42-91 jdk]$ ./master-jdk/bin/java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms4G -Xmx4G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions  -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational  -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar  -n 10 lusearch  | grep "metered full smoothing"
> ===== DaCapo tail latency, metered full smoothing: 50% 131684 usec, 90% 200192 usec, 99% 211369 usec, 99.9% 212517 usec, 99.99% 213043 usec, max 235289 usec, measured over 524288 events =====
> ===== DaCapo tail latency, metered full smoothing: 50% 1568 usec, 90% 36101 usec, 99% 42172 usec, 99.9% 42928 usec, 99.99% 43100 usec, max 43305 usec, measured over 524288 events =====
> ===== DaCapo tail latency, metered full smoothing: 50% 52644 usec, 90% 124393 usec, 99% 137711 usec, 99.9% 139355 usec, 99.99% 139749 usec, max 146722 usec, measured over 524288 events ====...

Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 133 commits:

 - format
 - Merge branch 'openjdk:master' into cas-alloc-1
 - Merge branch 'openjdk:master' into cas-alloc-1
 - Merge branch 'master' into cas-alloc-1
 - Move ShenandoahHeapRegionIterationClosure to shenandoahFreeSet.hpp
 - Merge branch 'openjdk:master' into cas-alloc-1
 - Fix errors caused by renaming ofAtomic to AtomicAccess
 - Merge branch 'openjdk:master' into cas-alloc-1
 - Remove unused flag
 - Merge branch 'openjdk:master' into cas-alloc-1
 - ... and 123 more: https://git.openjdk.org/jdk/compare/2f29b3f2...6bd38d61

-------------

Changes: https://git.openjdk.org/jdk/pull/26171/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=02
  Stats: 735 lines in 16 files changed: 674 ins; 7 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/26171.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171

PR: https://git.openjdk.org/jdk/pull/26171

From kdnilsen at openjdk.org  Mon Sep 29 21:19:19 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 29 Sep 2025 21:19:19 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v8]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <RR-UjeJeyxtCNAQwZ0ZrY_WB7_U5TLyVqAeBmeNwz_M=.4b7246bb-3b9d-4d40-81b0-9bec566347ee@github.com>

> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
> 
> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
> 
> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  more cosmetic improvements for used

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/144ace0b..01229f45

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=06-07

  Stats: 50 lines in 8 files changed: 25 ins; 21 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/26867.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26867/head:pull/26867

PR: https://git.openjdk.org/jdk/pull/26867

From wkemper at openjdk.org  Mon Sep 29 21:31:27 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 29 Sep 2025 21:31:27 GMT
Subject: RFR: 8368501: Shenandoah: GC progress evaluation does not use
 generation
Message-ID: <Qn6FDlj32BhpX--A-sebLeUUJpc0zk_jlA39Tm9hbSA=.43c28844-62cf-44a2-a3cc-6b2b85744592@github.com>

Remove unused `generation` parameter from stop-the-world GC progress evaluation. Also, have `shMetrics` use the freeset for `usage`  details. This is a follow up to a comment from an unrelated PR: https://github.com/openjdk/jdk/pull/27456#issuecomment-3325724362.

-------------

Commit messages:
 - Have stw progress evaluation just use the free set
 - Use collected generation to assess "used" progress

Changes: https://git.openjdk.org/jdk/pull/27561/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27561&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368501
  Stats: 79 lines in 4 files changed: 6 ins; 37 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/27561.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27561/head:pull/27561

PR: https://git.openjdk.org/jdk/pull/27561

From kdnilsen at openjdk.org  Mon Sep 29 23:09:45 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 29 Sep 2025 23:09:45 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v9]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <PBnJTz564k2w4y_CJrXnOC61weh-6Aj6Tmudn1qIEW0=.3c2ecf51-b0b3-4bfa-91f6-6b4e4f538046@github.com>

> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
> 
> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
> 
> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  cosmetic miprovements for bytes_allocated_since_gc_start() and get_affiliated_region_count()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/01229f45..8a0cee03

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=07-08

  Stats: 94 lines in 8 files changed: 63 ins; 30 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26867.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26867/head:pull/26867

PR: https://git.openjdk.org/jdk/pull/26867

From ayang at openjdk.org  Tue Sep 30 08:23:00 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 30 Sep 2025 08:23:00 GMT
Subject: RFR: 8368599: ShenandoahConcurrentMark could use
 ThreadsClaimTokenScope [v2]
In-Reply-To: <YL9taXQ9GYzI3D6Z0QnDfdtu07uWkj5AwCUneey_nh8=.21e68c71-a500-46d7-84d7-b3a2529eedd2@github.com>
References: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com>
 <qwKK3x51U4uQgi5Oco5sr6FIsFPOMBOjWV2YP4R6g78=.26efd2a1-749d-4a79-bf11-42842b20dc30@github.com>
 <YL9taXQ9GYzI3D6Z0QnDfdtu07uWkj5AwCUneey_nh8=.21e68c71-a500-46d7-84d7-b3a2529eedd2@github.com>
Message-ID: <YG-9MU3-xzaEQ_JHaPZAS5OI7IV_USQdYdnNWn4dFSQ=.11cbdb39-9540-4514-89b2-9aa10a4820df@github.com>

On Thu, 25 Sep 2025 14:16:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   as field
>
> Hold on a second.
> 
> 
> class StrongRootsScope : public MarkScope {
> 
> 
> ...and:
> 
> 
> MarkScope::MarkScope() {
>   nmethod::oops_do_marking_prologue();
> }
> 
> MarkScope::~MarkScope() {
>   nmethod::oops_do_marking_epilogue();
> }
> 
> 
> So, what calls `nmethod::oops_do_marking_prologue`/`epilogue`, and do we know it is (not) needed?

@shipilev Is the above explanation enough? If so, hopefully, this PR can be merged to unblock further cleanups around `StrongRootsScope`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27477#issuecomment-3350610528

From tschatzl at openjdk.org  Tue Sep 30 13:45:28 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 30 Sep 2025 13:45:28 GMT
Subject: RFR: 8236073: G1: Use SoftMaxHeapSize to guide GC heuristics
Message-ID: <8jjBh52pZlAjsLJ4ce1oacnDVdu8qCe2pJYApXsU5HM=.462adbdd-e3b7-4d4a-a130-aecadba36b00@github.com>

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

-------------

Commit messages:
 - * add test showing that the GC responds to changes of the SoftMaxHeapSize variable
 - * some comment update for target_occupancy()
 - * fix gtests
 - * observe MinHeapSize for `G1CollectedHeap::soft_max_capacity()`
 - * updates
 - initial version

Changes: https://git.openjdk.org/jdk/pull/27524/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27524&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8236073
  Stats: 123 lines in 10 files changed: 82 ins; 4 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/27524.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27524/head:pull/27524

PR: https://git.openjdk.org/jdk/pull/27524

From shade at openjdk.org  Tue Sep 30 16:18:35 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 30 Sep 2025 16:18:35 GMT
Subject: RFR: 8368599: ShenandoahConcurrentMark could use
 ThreadsClaimTokenScope [v2]
In-Reply-To: <qwKK3x51U4uQgi5Oco5sr6FIsFPOMBOjWV2YP4R6g78=.26efd2a1-749d-4a79-bf11-42842b20dc30@github.com>
References: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com>
 <qwKK3x51U4uQgi5Oco5sr6FIsFPOMBOjWV2YP4R6g78=.26efd2a1-749d-4a79-bf11-42842b20dc30@github.com>
Message-ID: <CHj6a0A5RmK5vSukveREAC14Zvfpo5Z-zn-bKCbhco8=.bd93bdc5-71a7-404f-851e-f9479fc6bf11@github.com>

On Thu, 25 Sep 2025 11:00:18 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `ShenandoahConcurrentMark::finish_mark_work` to be more precise with what is actually needed and why. Similar to #27385.
>> 
>> Test: tier1, and tier[1,2,3]_gc_shenandoah
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   as field

OK, fine. I see `ShenandoahSTWMark` still uses `StrongRootsScope`, which answers my question.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27477#pullrequestreview-3285772695

From fandreuzzi at openjdk.org  Tue Sep 30 16:18:36 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 30 Sep 2025 16:18:36 GMT
Subject: Integrated: 8368599: ShenandoahConcurrentMark could use
 ThreadsClaimTokenScope
In-Reply-To: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com>
References: <4NwqHXusqpML2llqRYE8zK872ntksLBtmTSWvWZb5HI=.3ce82ba9-2ed4-43ce-b40b-a4b3ac17ac61@github.com>
Message-ID: <cpu0c8AKvTMil_z6Ib1yE0O59-xUvHUoA4dTEQSQ3YM=.752c78ec-739f-4241-807c-62f31c718b18@github.com>

On Wed, 24 Sep 2025 22:37:44 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `ShenandoahConcurrentMark::finish_mark_work` to be more precise with what is actually needed and why. Similar to #27385.
> 
> Test: tier1, and tier[1,2,3]_gc_shenandoah

This pull request has now been integrated.

Changeset: fe9dbcc4
Author:    Francesco Andreuzzi <fandreuzzi at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fe9dbcc496671a256c61ac52df5580569dbafb0a
Stats:     5 lines in 1 file changed: 2 ins; 2 del; 1 mod

8368599: ShenandoahConcurrentMark could use ThreadsClaimTokenScope

Reviewed-by: ayang, shade, wkemper

-------------

PR: https://git.openjdk.org/jdk/pull/27477

From kdnilsen at openjdk.org  Tue Sep 30 16:38:08 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 30 Sep 2025 16:38:08 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v10]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <u5WkQ9tPcLfroQAKH8K-XDv3HLuBjKWGZclMJ4t9ZUI=.efc26e36-2dab-4ecd-ba8b-9961246b3752@github.com>

> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
> 
> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
> 
> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  OO improvements to get_humongous_waste()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/8a0cee03..cbe83407

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=08-09

  Stats: 48 lines in 8 files changed: 31 ins; 16 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26867.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26867/head:pull/26867

PR: https://git.openjdk.org/jdk/pull/26867

From fandreuzzi at openjdk.org  Tue Sep 30 16:42:35 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 30 Sep 2025 16:42:35 GMT
Subject: RFR: 8368966: Remove spurious VMStructs friends
Message-ID: <8OJWg3O52vyoX_mFGHHpTsBmWvHeBVJC3Pq8IYKY2rk=.205ce94a-a9c8-4d85-8321-9268b1a29b68@github.com>

In this PR I propose a small clean up to remove several spurious friends of `VMStructs`. I could not find any reference to them in `vmStructs*`, or private symbols are not mentioned so the friendship can be removed.

Passes tier1 and tier2 (fastdebug).

-------------

Commit messages:
 - Merge branch 'master' into cleanup-vmstructs
 - nn

Changes: https://git.openjdk.org/jdk/pull/27583/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27583&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368966
  Stats: 80 lines in 47 files changed: 1 ins; 78 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27583.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27583/head:pull/27583

PR: https://git.openjdk.org/jdk/pull/27583

From kdnilsen at openjdk.org  Tue Sep 30 16:58:47 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 30 Sep 2025 16:58:47 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v11]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <EOVgTCiuu_kSxiR4iLH12OGedXj1HLRuE-BOR1YWl9Y=.bbfdf927-56d5-4135-8f37-5e28050425a9@github.com>

> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
> 
> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
> 
> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  OO refinements to used_regions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/cbe83407..c6a51a95

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=09-10

  Stats: 34 lines in 6 files changed: 13 ins; 14 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/26867.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26867/head:pull/26867

PR: https://git.openjdk.org/jdk/pull/26867

From kdnilsen at openjdk.org  Tue Sep 30 21:55:46 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 30 Sep 2025 21:55:46 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v12]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <zykF_uZbCnQ24lXQ7WDVnnbofQqtZbm3THblcpqnUnc=.c22227ea-3a1b-4507-b4f1-b48368c80fa3@github.com>

> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
> 
> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
> 
> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.

Kelvin Nilsen has updated the pull request incrementally with five additional commits since the last revision:

 - small refactoring
 - OO refinements to used_regions_size()
 - fix broken assert from previous commit
 - OO refinements to free_unaffiliated_regions()
 - OO refinements to max_capacity()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/c6a51a95..43e1358f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=10-11

  Stats: 147 lines in 9 files changed: 76 ins; 56 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/26867.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26867/head:pull/26867

PR: https://git.openjdk.org/jdk/pull/26867