From ysuenaga at openjdk.org  Thu Jan  1 09:24:59 2026
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 1 Jan 2026 09:24:59 GMT
Subject: RFR: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is
 incorrectly implemented
In-Reply-To: <SiBemHHhiHk3uDElvjRK16U2SNea7P1wsptA_4z7kxA=.0746951f-41b4-46b4-8397-40603dea6298@github.com>
References: <SiBemHHhiHk3uDElvjRK16U2SNea7P1wsptA_4z7kxA=.0746951f-41b4-46b4-8397-40603dea6298@github.com>
Message-ID: <pML72kcmtTlVgQnTx971zygcjz3sDsob_NHzbef56Fg=.280d004b-f095-4e2f-99e3-9ecb73248baf@github.com>

On Sat, 29 Nov 2025 06:06:16 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> The jtreg test TestEmergencyDumpAtOOM.java runs into the following error on ppc64 platforms.
> 
> JFR emergency dump would be kicked at `VMError::report_and_die()`, then Java thread for JFR would not work due to secondary signal handler for error reporting.
> 
> Passed all of jdk_jfr tests on Linux AMD64.

I'm still waiting for second reviewer.
@mgronlun Can you take a look?

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

PR Comment: https://git.openjdk.org/jdk/pull/28563#issuecomment-3703460604

From aph at openjdk.org  Thu Jan  1 10:05:03 2026
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 1 Jan 2026 10:05:03 GMT
Subject: RFR: 8372942: AArch64: Set JVM flags for Neoverse V3AE core
In-Reply-To: <E0Fdz0OrKiYwvHaBVOUns9YCtHKwl8lBZrIC6UYZj-o=.1652733f-4423-415c-a621-22118aa464cc@github.com>
References: <E0Fdz0OrKiYwvHaBVOUns9YCtHKwl8lBZrIC6UYZj-o=.1652733f-4423-415c-a621-22118aa464cc@github.com>
Message-ID: <IQq_H8QAIKTEwo-0uii0rYV4IYI-YTpiKqjTVwfr--A=.31af74b9-7f69-46bf-b755-04f58e82ec65@github.com>

On Tue, 2 Dec 2025 14:56:49 GMT, Ruben <duke at openjdk.org> wrote:

> For Neoverse N1, N2, N3, V1, V2 and V3, the following JVM flags are set:
> - UseSIMDForMemoryOps=true
> - OnSpinWaitInst=isb
> - OnSpinWaitInstCount=1
> - AlwaysMergeDMB=false
> 
> Additionally, for Neoverse V1, V2 and V3 only, these flags are set:
> - UseCryptoPmullForCRC32=true
> - CodeEntryAlignment=32
> 
> Enable the same flags for Neoverse V3AE.

Thanks, this is fine.
I wonder if we should be thinking about replacing some of this open-coded logic with something more expressive and concise. This bunch of model_is() expressions could be a switch, for example.

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

Marked as reviewed by aph (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28607#pullrequestreview-3621750746

From aph at openjdk.org  Thu Jan  1 13:15:59 2026
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 1 Jan 2026 13:15:59 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v21]
In-Reply-To: <yPoVq-X-9UlWSVpOhumN8VxrSI_lBSR5efh5Z6iPc0w=.2f1ba28a-7b42-4b03-8e25-21b31b7ee965@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
 <QedZccpniOaFQ_SbJqZd-IsyrdlBDa1CB1oa6vL1018=.a8378937-2234-499c-a1f6-20b8214afacd@github.com>
 <15wAKoik-66gfbUzGQEROBTv_cTV_I_6jq96S2ErOyA=.22e19b52-220c-4c35-9aaa-9f08719e16fa@github.com>
 <yPoVq-X-9UlWSVpOhumN8VxrSI_lBSR5efh5Z6iPc0w=.2f1ba28a-7b42-4b03-8e25-21b31b7ee965@github.com>
Message-ID: <wSxY8IqN9mDrzQ5HuBr4twXO1U5s44BwvVGWIoKX5LI=.21dc2e0e-211a-41d3-9111-75929bad608b@github.com>

On Wed, 31 Dec 2025 16:06:53 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

> > Is there any reason not to do this by default on all AArch64?
> 
> It will be turned on if AArch64 has `ctr_el0.IDC` and `ctr_el0.DIC` set. See https://github.com/openjdk/jdk/pull/28328/changes#diff-a87e260510f34ca7d9b0feb089ad982be8268c5c8aa5a71221f6738b051ea488R663

Sure, I can see that, but is there any reason not to do this by default on all AArch64?

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

PR Comment: https://git.openjdk.org/jdk/pull/28328#issuecomment-3703679652

From kbarrett at openjdk.org  Thu Jan  1 13:30:14 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 1 Jan 2026 13:30:14 GMT
Subject: RFR: 8374444: Fix simple -Wzero-as-null-pointer-constant warnings
Message-ID: <TUNKybNBZMCTpg-cqZHhsvsD4dUuRs9VeB2H3dKWX-Y=.f8a844c2-d831-4d72-b80d-3ee32c626f86@github.com>

Please review this trivial change to fix several recent changes that trigger
`-Wzero-as-null-pointer-constant `warnings when that warning is enabled.

Testing: mach5 tier1

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

Commit messages:
 - fix simple -Wzero-as-null-pointer-constant warnings

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

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

From lmesnik at openjdk.org  Thu Jan  1 20:15:54 2026
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 1 Jan 2026 20:15:54 GMT
Subject: RFR: 8343809: Add requires tag to mark tests that are incompatible
 with exploded image [v2]
In-Reply-To: <V5dtzsq1IEKP5CaYB9oZNq89cA1dXin4S5X5ZWbZ4GU=.25109012-74e7-43b5-ad65-b3080eba7511@github.com>
References: <GtxujYXXFK6Y32kkijCc7XyGcMStlbQs7C9OM2QxmfM=.cbfe5c94-c9ab-4852-bad2-66deb4932723@github.com>
 <V5dtzsq1IEKP5CaYB9oZNq89cA1dXin4S5X5ZWbZ4GU=.25109012-74e7-43b5-ad65-b3080eba7511@github.com>
Message-ID: <1-X6XEzhKOyBhAdV8K-43abGJWYx4IOhZvp3b1tlwto=.cfbc37ec-45e8-4b47-bff0-a8fc93ad61b3@github.com>

On Tue, 16 Dec 2025 16:51:56 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The 
>> jdk.explodedImage
>> might be used to filter tests incompatible with 
>> make exploded-run-test TEST=...
>> 
>> The exploded-run-test  mode is used only for quick manual testing and not in CI or ATR testing. However, it is make sense to reduce false positive failures so developers don't waste time during local testing.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplified file check

ping

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

PR Comment: https://git.openjdk.org/jdk/pull/28814#issuecomment-3704068280

From eastigeevich at openjdk.org  Thu Jan  1 20:38:08 2026
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Thu, 1 Jan 2026 20:38:08 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v21]
In-Reply-To: <wSxY8IqN9mDrzQ5HuBr4twXO1U5s44BwvVGWIoKX5LI=.21dc2e0e-211a-41d3-9111-75929bad608b@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
 <QedZccpniOaFQ_SbJqZd-IsyrdlBDa1CB1oa6vL1018=.a8378937-2234-499c-a1f6-20b8214afacd@github.com>
 <15wAKoik-66gfbUzGQEROBTv_cTV_I_6jq96S2ErOyA=.22e19b52-220c-4c35-9aaa-9f08719e16fa@github.com>
 <yPoVq-X-9UlWSVpOhumN8VxrSI_lBSR5efh5Z6iPc0w=.2f1ba28a-7b42-4b03-8e25-21b31b7ee965@github.com>
 <wSxY8IqN9mDrzQ5HuBr4twXO1U5s44BwvVGWIoKX5LI=.21dc2e0e-211a-41d3-9111-75929bad608b@github.com>
Message-ID: <suIW5qm-iGcSsrmNPTjwP8XwHdUMcEQZsrGQyt97a0g=.23ea0dbc-f2f7-43ce-9377-45ebf645dcab@github.com>

On Thu, 1 Jan 2026 13:13:07 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Sure, I can see that, but is there any reason not to do this by default on all AArch64?

Do you mean to do this for all AArch64 OSes, not only for Linux AArch64?

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

PR Comment: https://git.openjdk.org/jdk/pull/28328#issuecomment-3704085326

From aboldtch at openjdk.org  Fri Jan  2 04:27:04 2026
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 2 Jan 2026 04:27:04 GMT
Subject: RFR: 8372241: Add GTestCheckers [v4]
In-Reply-To: <JD1Zp8q0PaUuSEmeB04BpwJqYj8Hv3691RikemjROgc=.7d9d1ed6-4890-4ea3-9e63-b4fc9a2d6d42@github.com>
References: <JD1Zp8q0PaUuSEmeB04BpwJqYj8Hv3691RikemjROgc=.7d9d1ed6-4890-4ea3-9e63-b4fc9a2d6d42@github.com>
Message-ID: <67KWeG0lvyWzdOVSB9N37SvGSiWFZVS5cpCMeoFrepI=.8d6d292d-0581-4775-b17f-772832d55a6f@github.com>

> Each GTest test case is intended to be able to run on its own (this is the design intent of the frame work).
> 
> Hotspot also adds some extra flavours of GTests, those that run with no created VM (`TEST`/`TEST_F`), those that run with a shared created VM (`TEST_VM`/`TEST_VM_F`) and those that run in a private created VM (`TEST_OTHER_VM`/`TEST_VM_ASSERT`/`TEST_VM_ASSERT_MSG`/`TEST_VM_FATAL_ERROR_MSG`/`TEST_VM_CRASH_SIGNAL`).
> 
> The way this is implemented is by having the first shared VM test that runs create a VM. But this leads to having all proceeding test also have access to a shared VM, even if they are test that are supposed to be able to run without a created VM.
> 
> Combining this with the fact that almost all our automated GTest testing always just run all tests in the same order makes it hard to discover if we have dependencies between tests.
> 
> I propose we add three types of GTest invocation tests used to find these incorrect dependencies.
> 
> 1. A test which runs only our no created VM test, to find if we have any VM dependency.
> 2. A test which runs only one test at a time, to see if there are any tests which depend on other test having been run.
> 3. A test which shuffles the order of our tests to see if there are any dependencies on the order of tests.
> 
> Added 1. and 3. to tier1 as they are just as cheap or cheaper than the normal `GTestWrapper.java`. 2. is only added to our complement test groups, so `tier4` and `hotspot_misc`.  Also added a new test group `:hotspot_validate_gtest` which can be used to more easily run all three of these tests.
> 
> 3. will have some randomness, so there might be that things start popping up. It is quite easy to add exclude tests from via the filter. But the shuffle dependencies are probably the scariest if we find them, as they might be just a test running bug as the one that is excluded here. But it can also find broken assumptions, or bring things we have missed to light.
> 
> These tests and the chain of followup fixes are not of high priority. It has not been able to find anything but bad test assumptions and incorrectly configured tests. So I have no problem letting this PR stay open until after the fork, so these tests can bake in the JDK 27 branch rather than the JDK 26 branch.

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

 - Add filter for JDK-8374450
 - Merge tag 'jdk-27+3' into JDK-8372241
   
   Added tag jdk-27+3 for changeset 4f283f18
 - Merge tag 'jdk-26+26' into JDK-8372241
   
   Added tag jdk-26+26 for changeset 847fbab7
 - Add comments with the associated bug ids for TEST_FILTERS
 - Add GTestCheckers

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28409/files
  - new: https://git.openjdk.org/jdk/pull/28409/files/d2b18730..6b541162

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

  Stats: 71583 lines in 1437 files changed: 45438 ins; 18779 del; 7366 mod
  Patch: https://git.openjdk.org/jdk/pull/28409.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28409/head:pull/28409

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

From aboldtch at openjdk.org  Fri Jan  2 04:27:48 2026
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 2 Jan 2026 04:27:48 GMT
Subject: RFR: 8371346: ZGC: Flexible heap base selection [v4]
In-Reply-To: <g2sXoLZ6-rQ8TeHjA_C2Gi_gmrAW_uA-mQpe867xG-M=.5f135781-364a-4929-b6cb-79f2488b415c@github.com>
References: <g2sXoLZ6-rQ8TeHjA_C2Gi_gmrAW_uA-mQpe867xG-M=.5f135781-364a-4929-b6cb-79f2488b415c@github.com>
Message-ID: <PNX9ylHzKliKykbKDpeCIWTr8rS9wQF4iCSMwaQdJaM=.ea28cb15-aa07-4d43-abbe-1cc4dbf729c7@github.com>

> ZGC reserves a virtual address range for its heap with one high order bit set which is referred to as the heap base. Internally we then often represent heap addresses as offset from this heap base.
> 
> Currently we select one specific heap base at the start based on MaxHeapSize and the current system properties.
> 
> With instrumented builds, or custom launchers it may be that we are unable to reserve a usable address range using that heap base. Currently we just give up if this happens and exits the VM.
> 
> This is problematic when using instrumented builds such as ASAN where there are certain address ranges it uses which often clash with the default ZGC heap base.
> 
> I propose that we are more flexible when selecting the heap base, and we start as we do today at our preferred location, but are able to retry other compatible heap bases within some broader limits.
> 
> The implementation will now start at the recommended or required heap base which ever is larger and try to first reserve the desired reservation size (normally 16 * MaxHeapSize). If no heap base can accommodate this desired size, it will attempt to find at least the required size and use that.
> 
> On linux x86_64 we will now also probe for the heap base rather than hard coding the max heap base as we did previously. This is beneficial when there are address space restrictions (such as with ASAN), and when there are none, we only do a couple of extra system calls at most. 
> 
> There are some changes to the gc+init logging. The ZAddressOffsetMax is adjusted to always be a correct upper bound. And the exit path when reservation fails is clean up, so that we exit early when we know that the external virtual memory limits will prohibit the heap reservation. 
> 
> Performance testing show no significant differences.
> 
> Testing:
> * GHA
> * Running ZGC tier1-8 on Oracle supported platforms

Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Merge tag 'jdk-27+3' into zgc_flexible_heap_base
   
   Added tag jdk-27+3 for changeset 4f283f18
 - Merge tag 'jdk-26+26' into zgc_flexible_heap_base
   
   Added tag jdk-26+26 for changeset 847fbab7
 - Small fixes
 - Merge remote-tracking branch 'upstream_jdk/master' into stefank_review_pr_28161
 - Fixes and cleanups
 - pr/28161_review
 - Merge remote-tracking branch 'upstream/master' into pr/28161
 - Initial Test Implementation
 - Initial implementation flexible heap base
 - Constrain ZAddressOffsetMax correctly when multi-partition fails
 - ... and 3 more: https://git.openjdk.org/jdk/compare/4f283f18...a3a69a11

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

Changes: https://git.openjdk.org/jdk/pull/28161/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28161&range=03
  Stats: 2727 lines in 50 files changed: 1886 ins; 631 del; 210 mod
  Patch: https://git.openjdk.org/jdk/pull/28161.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28161/head:pull/28161

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

From kbarrett at openjdk.org  Fri Jan  2 05:12:47 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 2 Jan 2026 05:12:47 GMT
Subject: RFR: 8374444: Fix simple -Wzero-as-null-pointer-constant warnings
 [v2]
In-Reply-To: <TUNKybNBZMCTpg-cqZHhsvsD4dUuRs9VeB2H3dKWX-Y=.f8a844c2-d831-4d72-b80d-3ee32c626f86@github.com>
References: <TUNKybNBZMCTpg-cqZHhsvsD4dUuRs9VeB2H3dKWX-Y=.f8a844c2-d831-4d72-b80d-3ee32c626f86@github.com>
Message-ID: <YyvB4M2wqF68kPNzV19xYV7qoMWkzDDCMVnbJPN9LOI=.ae971468-b9ba-43d5-a1ef-ea0682c88121@github.com>

> Please review this trivial change to fix several recent changes that trigger
> `-Wzero-as-null-pointer-constant `warnings when that warning is enabled.
> 
> Testing: mach5 tier1

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

  update copyrights

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29014/files
  - new: https://git.openjdk.org/jdk/pull/29014/files/5e9e059f..fe41f6ef

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

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

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

From alanb at openjdk.org  Fri Jan  2 07:02:36 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 2 Jan 2026 07:02:36 GMT
Subject: RFR: 8343809: Add requires tag to mark tests that are incompatible
 with exploded image [v2]
In-Reply-To: <V5dtzsq1IEKP5CaYB9oZNq89cA1dXin4S5X5ZWbZ4GU=.25109012-74e7-43b5-ad65-b3080eba7511@github.com>
References: <GtxujYXXFK6Y32kkijCc7XyGcMStlbQs7C9OM2QxmfM=.cbfe5c94-c9ab-4852-bad2-66deb4932723@github.com>
 <V5dtzsq1IEKP5CaYB9oZNq89cA1dXin4S5X5ZWbZ4GU=.25109012-74e7-43b5-ad65-b3080eba7511@github.com>
Message-ID: <nvKidc_TTH1dXYv0WlYUVPHHIy5qcPfFXMXa7XA2kPs=.38eb5f82-e67c-4be1-b8fc-41deecf277f7@github.com>

On Tue, 16 Dec 2025 16:51:56 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The 
>> jdk.explodedImage
>> might be used to filter tests incompatible with 
>> make exploded-run-test TEST=...
>> 
>> The exploded-run-test  mode is used only for quick manual testing and not in CI or ATR testing. However, it is make sense to reduce false positive failures so developers don't waste time during local testing.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplified file check

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28814#pullrequestreview-3622345063

From aboldtch at openjdk.org  Fri Jan  2 07:33:53 2026
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 2 Jan 2026 07:33:53 GMT
Subject: RFR: 8374444: Fix simple -Wzero-as-null-pointer-constant warnings
 [v2]
In-Reply-To: <YyvB4M2wqF68kPNzV19xYV7qoMWkzDDCMVnbJPN9LOI=.ae971468-b9ba-43d5-a1ef-ea0682c88121@github.com>
References: <TUNKybNBZMCTpg-cqZHhsvsD4dUuRs9VeB2H3dKWX-Y=.f8a844c2-d831-4d72-b80d-3ee32c626f86@github.com>
 <YyvB4M2wqF68kPNzV19xYV7qoMWkzDDCMVnbJPN9LOI=.ae971468-b9ba-43d5-a1ef-ea0682c88121@github.com>
Message-ID: <CeX-Y66nNk6bv-ZFORb-ghNgAVr5zf2-ed3e-Nfi-9w=.b56641d6-848c-4f7e-81b8-3af0a39cc40b@github.com>

On Fri, 2 Jan 2026 05:12:47 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this trivial change to fix several recent changes that trigger
>> `-Wzero-as-null-pointer-constant `warnings when that warning is enabled.
>> 
>> Testing: mach5 tier1
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyrights

lgtm.

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

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29014#pullrequestreview-3622374465

From mbaesken at openjdk.org  Fri Jan  2 08:48:02 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 2 Jan 2026 08:48:02 GMT
Subject: RFR: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is
 incorrectly implemented
In-Reply-To: <SiBemHHhiHk3uDElvjRK16U2SNea7P1wsptA_4z7kxA=.0746951f-41b4-46b4-8397-40603dea6298@github.com>
References: <SiBemHHhiHk3uDElvjRK16U2SNea7P1wsptA_4z7kxA=.0746951f-41b4-46b4-8397-40603dea6298@github.com>
Message-ID: <-Vb3RjzTqS7Lo9tMqVYqEbRQ1nYLg20mfcehWEe6Vm4=.e4dba3af-59af-42c9-b0bc-0d6e57122121@github.com>

On Sat, 29 Nov 2025 06:06:16 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> The jtreg test TestEmergencyDumpAtOOM.java runs into the following error on ppc64 platforms.
> 
> JFR emergency dump would be kicked at `VMError::report_and_die()`, then Java thread for JFR would not work due to secondary signal handler for error reporting.
> 
> Passed all of jdk_jfr tests on Linux AMD64.

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28563#pullrequestreview-3622449994

From aboldtch at openjdk.org  Fri Jan  2 09:21:31 2026
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 2 Jan 2026 09:21:31 GMT
Subject: RFR: 8372241: Add GTestCheckers [v5]
In-Reply-To: <JD1Zp8q0PaUuSEmeB04BpwJqYj8Hv3691RikemjROgc=.7d9d1ed6-4890-4ea3-9e63-b4fc9a2d6d42@github.com>
References: <JD1Zp8q0PaUuSEmeB04BpwJqYj8Hv3691RikemjROgc=.7d9d1ed6-4890-4ea3-9e63-b4fc9a2d6d42@github.com>
Message-ID: <P2JIe--Ix5xF8iFUPcaTo126KGpW1q3Sd5orlY0-9gU=.49751168-a790-4330-867e-38d71ea48347@github.com>

> Each GTest test case is intended to be able to run on its own (this is the design intent of the frame work).
> 
> Hotspot also adds some extra flavours of GTests, those that run with no created VM (`TEST`/`TEST_F`), those that run with a shared created VM (`TEST_VM`/`TEST_VM_F`) and those that run in a private created VM (`TEST_OTHER_VM`/`TEST_VM_ASSERT`/`TEST_VM_ASSERT_MSG`/`TEST_VM_FATAL_ERROR_MSG`/`TEST_VM_CRASH_SIGNAL`).
> 
> The way this is implemented is by having the first shared VM test that runs create a VM. But this leads to having all proceeding test also have access to a shared VM, even if they are test that are supposed to be able to run without a created VM.
> 
> Combining this with the fact that almost all our automated GTest testing always just run all tests in the same order makes it hard to discover if we have dependencies between tests.
> 
> I propose we add three types of GTest invocation tests used to find these incorrect dependencies.
> 
> 1. A test which runs only our no created VM test, to find if we have any VM dependency.
> 2. A test which runs only one test at a time, to see if there are any tests which depend on other test having been run.
> 3. A test which shuffles the order of our tests to see if there are any dependencies on the order of tests.
> 
> Added 1. and 3. to tier1 as they are just as cheap or cheaper than the normal `GTestWrapper.java`. 2. is only added to our complement test groups, so `tier4` and `hotspot_misc`.  Also added a new test group `:hotspot_validate_gtest` which can be used to more easily run all three of these tests.
> 
> 3. will have some randomness, so there might be that things start popping up. It is quite easy to add exclude tests from via the filter. But the shuffle dependencies are probably the scariest if we find them, as they might be just a test running bug as the one that is excluded here. But it can also find broken assumptions, or bring things we have missed to light.
> 
> These tests and the chain of followup fixes are not of high priority. It has not been able to find anything but bad test assumptions and incorrectly configured tests. So I have no problem letting this PR stay open until after the fork, so these tests can bake in the JDK 27 branch rather than the JDK 26 branch.

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

 - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8372241
 - Add filter for JDK-8374450
 - Merge tag 'jdk-27+3' into JDK-8372241
   
   Added tag jdk-27+3 for changeset 4f283f18
 - Merge tag 'jdk-26+26' into JDK-8372241
   
   Added tag jdk-26+26 for changeset 847fbab7
 - Add comments with the associated bug ids for TEST_FILTERS
 - Add GTestCheckers

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28409/files
  - new: https://git.openjdk.org/jdk/pull/28409/files/6b541162..279c4430

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

  Stats: 6448 lines in 2020 files changed: 2175 ins; 767 del; 3506 mod
  Patch: https://git.openjdk.org/jdk/pull/28409.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28409/head:pull/28409

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

From kbarrett at openjdk.org  Fri Jan  2 10:08:26 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 2 Jan 2026 10:08:26 GMT
Subject: RFR: 8374350: Convert hotspot gtests to use Atomic<T> [v2]
In-Reply-To: <BxRBFQ-RXjXDRiF75q_IepNnhurF97pwc2r_YquJx1U=.485cb8de-9395-41e3-a97e-457da24385dd@github.com>
References: <BxRBFQ-RXjXDRiF75q_IepNnhurF97pwc2r_YquJx1U=.485cb8de-9395-41e3-a97e-457da24385dd@github.com>
Message-ID: <SYmHDwrLJYMBJgHLgrpZ5BFy_MpDOPNopMwzjD5_KrY=.11a6992a-1d6c-42d1-86af-b0b0ca444999@github.com>

> Please review this change to convert HotSpot gtests to use Atomic<T> rather
> than directly using AtomicAccess.
> 
> test_atomicAccess.cpp is, of course, not subject to this conversion.
> 
> test_globalCounter.cpp is also not included in this conversion.  The other
> conversions were straight forward.  This test is less so, and I decided I
> needed to spend more time studying it, so have left it for followup work.
> 
> The conversion of each test is a separate commit, in case that makes it easier
> to review.
> 
> Testing: mach5 tier1

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

  update copyrights

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29001/files
  - new: https://git.openjdk.org/jdk/pull/29001/files/a98a1b6b..8f35f5c8

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

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

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

From kbarrett at openjdk.org  Fri Jan  2 10:11:58 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 2 Jan 2026 10:11:58 GMT
Subject: RFR: 8374328: Convert simple AtomicAccess uses in gc/shared to use
 Atomic<T> [v2]
In-Reply-To: <RJp0KKg8demYMWOXkrVs1g_jitLhTsvce6ZFO98ihNw=.2c8e0a03-d56a-450e-91c8-019931a717b8@github.com>
References: <RJp0KKg8demYMWOXkrVs1g_jitLhTsvce6ZFO98ihNw=.2c8e0a03-d56a-450e-91c8-019931a717b8@github.com>
Message-ID: <eKtPNvQBTPlQk_hCJrcWWv98vVwtuQ-7s1F5CDAbcUU=.7f8592f1-8a3e-4c96-bb26-9aab7eddf9a2@github.com>

> Please review these fairly simple changes to code in gc/shared to use
> `Atomic<T>` instead of directly using `AtomicAccess`.
> 
> This change doesn't eliminate all remaining direct uses of `AtomicAccess` in
> that directory; there are still a few uses that seem less simple, and maybe
> some that should stay with direct `AtomicAccess`.
> 
> The changes are grouped into a series of commits, as a potential aid to reviewers.
> 
> Testing: mach5 tier1-5

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

  update copyrights

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28987/files
  - new: https://git.openjdk.org/jdk/pull/28987/files/0abdb185..ad121490

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

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

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

From kbarrett at openjdk.org  Fri Jan  2 10:13:38 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 2 Jan 2026 10:13:38 GMT
Subject: RFR: 8374190: Convert ConcurrentHashTable atomic lists to use
 Atomic<T> [v2]
In-Reply-To: <AF4ZUl0ny2Mzk2XrJiWpUPvv63oubznivKfrGgbyz20=.a1c8a867-1f21-4ff9-b76b-91c456a126b8@github.com>
References: <AF4ZUl0ny2Mzk2XrJiWpUPvv63oubznivKfrGgbyz20=.a1c8a867-1f21-4ff9-b76b-91c456a126b8@github.com>
Message-ID: <VWZzIImhHtxN-8n3cSq-N6GfufVdymIzHqGYpr0HhFM=.623f2eaa-4307-4fa2-9676-6d6fe407c19d@github.com>

> Please review this change to ConcurrentHashTable to use `Atomic<Node*>` for
> the Node lists.  Note that this does not complete the replacement of direct
> uses of AtomicAccess by that class; there's still one more group remaining.
> 
> Testing: mach5 tier1-3

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

  update copyrights

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28951/files
  - new: https://git.openjdk.org/jdk/pull/28951/files/0278f373..a12d25ff

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

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

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

From kbarrett at openjdk.org  Fri Jan  2 10:21:44 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 2 Jan 2026 10:21:44 GMT
Subject: RFR: 8372754: Add wrapper for <cstdlib> [v4]
In-Reply-To: <7QNN5i5DkBH7c9YXWh5U40JwTKmiBPJSAcLm-f1HE_8=.9b18027e-8274-46d1-ba2d-e70514c40fc3@github.com>
References: <7QNN5i5DkBH7c9YXWh5U40JwTKmiBPJSAcLm-f1HE_8=.9b18027e-8274-46d1-ba2d-e70514c40fc3@github.com>
Message-ID: <blpDC9uwyrMnXpRAO7mZ3dXLSA0lXJ-_iVjoMfhGyd0=.1b8a1e99-4edd-488b-af34-697b7e42bc4d@github.com>

> Please review this change that adds a HotSpot wrapper for <cstdlib>.  It also
> includes the forbidden function declarations for functions declared there,
> moving them from forbiddenFunctions.hpp and friends.
> 
> The AIX-specific workaround for its macro-based renaming of malloc/calloc is
> also moved to this wrapper, so there is a single location for it. Also cleaned
> it up a bit, based on further investigation of the problem.
> 
> Also changed uses of `<cstdlib>` and `<stdlib.h>` to include the wrapper instead.
> There are still a couple of includes of `<stdlib.h>` in the hotspot directory,
> because they can't use the hotspot wrapper: os/windows/include/jvm_md.h and
> share/adlc/adlc.hpp.  I looked at removing the one in windows jvm_md.h, but
> there are a lot of dependencies on that implicit include in non-HotSpot code.
> 
> While updating to use the wrapper, I also did a small amount of include
> cleanup here and there.  The changes around immediate_aarch64.hpp are perhaps
> a little less trivial than I should have made here.
> 
> Testing: mach5 tier1
> 
> This should probably be retested by aix port maintainer folks, although I
> don't think I made any relevant changes since you last tested it.
> 
> This change also resolves:

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

  update copyrights

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28562/files
  - new: https://git.openjdk.org/jdk/pull/28562/files/7855de87..ced402c0

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

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

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

From kbarrett at openjdk.org  Fri Jan  2 10:22:12 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 2 Jan 2026 10:22:12 GMT
Subject: RFR: 8374444: Fix simple -Wzero-as-null-pointer-constant warnings
 [v2]
In-Reply-To: <CeX-Y66nNk6bv-ZFORb-ghNgAVr5zf2-ed3e-Nfi-9w=.b56641d6-848c-4f7e-81b8-3af0a39cc40b@github.com>
References: <TUNKybNBZMCTpg-cqZHhsvsD4dUuRs9VeB2H3dKWX-Y=.f8a844c2-d831-4d72-b80d-3ee32c626f86@github.com>
 <YyvB4M2wqF68kPNzV19xYV7qoMWkzDDCMVnbJPN9LOI=.ae971468-b9ba-43d5-a1ef-ea0682c88121@github.com>
 <CeX-Y66nNk6bv-ZFORb-ghNgAVr5zf2-ed3e-Nfi-9w=.b56641d6-848c-4f7e-81b8-3af0a39cc40b@github.com>
Message-ID: <fv4AXfcBBZvhM1BZFD0BsLWuqc9No2GoVrbMIwviWNE=.4e13053a-85d9-494d-95c3-5f715ebe30a3@github.com>

On Fri, 2 Jan 2026 07:31:39 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update copyrights
>
> lgtm. Trivial.

Thanks for review @xmas92

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

PR Comment: https://git.openjdk.org/jdk/pull/29014#issuecomment-3704988320

From kbarrett at openjdk.org  Fri Jan  2 10:22:14 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 2 Jan 2026 10:22:14 GMT
Subject: Integrated: 8374444: Fix simple -Wzero-as-null-pointer-constant
 warnings
In-Reply-To: <TUNKybNBZMCTpg-cqZHhsvsD4dUuRs9VeB2H3dKWX-Y=.f8a844c2-d831-4d72-b80d-3ee32c626f86@github.com>
References: <TUNKybNBZMCTpg-cqZHhsvsD4dUuRs9VeB2H3dKWX-Y=.f8a844c2-d831-4d72-b80d-3ee32c626f86@github.com>
Message-ID: <lljIIisNZyJZNwB0qc2QK4b6OUgV34FyekJqV6Loia0=.a4e4f386-16a5-4076-8615-1b17a73918d0@github.com>

On Thu, 1 Jan 2026 13:23:02 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial change to fix several recent changes that trigger
> `-Wzero-as-null-pointer-constant `warnings when that warning is enabled.
> 
> Testing: mach5 tier1

This pull request has now been integrated.

Changeset: efb79dc6
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/efb79dc6b4907ecf4e1bab3c393ee5cd5fe911a8
Stats:     16 lines in 5 files changed: 0 ins; 0 del; 16 mod

8374444: Fix simple -Wzero-as-null-pointer-constant warnings

Reviewed-by: aboldtch

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

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

From aboldtch at openjdk.org  Fri Jan  2 10:31:56 2026
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 2 Jan 2026 10:31:56 GMT
Subject: RFR: 8374350: Convert hotspot gtests to use Atomic<T> [v2]
In-Reply-To: <SYmHDwrLJYMBJgHLgrpZ5BFy_MpDOPNopMwzjD5_KrY=.11a6992a-1d6c-42d1-86af-b0b0ca444999@github.com>
References: <BxRBFQ-RXjXDRiF75q_IepNnhurF97pwc2r_YquJx1U=.485cb8de-9395-41e3-a97e-457da24385dd@github.com>
 <SYmHDwrLJYMBJgHLgrpZ5BFy_MpDOPNopMwzjD5_KrY=.11a6992a-1d6c-42d1-86af-b0b0ca444999@github.com>
Message-ID: <xp1GeD9sxlxv6tGdGdsvlvALexd61xOtyJ9eyiuylio=.6f5ebd2a-fe81-4785-ae70-6f79e82fa4d3@github.com>

On Fri, 2 Jan 2026 10:08:26 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to convert HotSpot gtests to use Atomic<T> rather
>> than directly using AtomicAccess.
>> 
>> test_atomicAccess.cpp is, of course, not subject to this conversion.
>> 
>> test_globalCounter.cpp is also not included in this conversion.  The other
>> conversions were straight forward.  This test is less so, and I decided I
>> needed to spend more time studying it, so have left it for followup work.
>> 
>> The conversion of each test is a separate commit, in case that makes it easier
>> to review.
>> 
>> Testing: mach5 tier1
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyrights

lgtm.

Just wondering if we should use `GrowableArray` instead of NEW/FREE macros and the placement new operator. Or would you rather have such a change as a separate RFE?

test/hotspot/gtest/gc/g1/test_g1BatchedGangTask.cpp line 60:

> 58:   }
> 59: 
> 60:   Atomic<bool>* _do_work_called_by;

Can we use `GrowableArrayCHeap<Atomic<bool>, MemTag::mtInternal>` instead, and skip the manual destruction (and element construction)?

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

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29001#pullrequestreview-3622854328
PR Review Comment: https://git.openjdk.org/jdk/pull/29001#discussion_r2657457204

From aboldtch at openjdk.org  Fri Jan  2 10:37:00 2026
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 2 Jan 2026 10:37:00 GMT
Subject: RFR: 8374350: Convert hotspot gtests to use Atomic<T> [v2]
In-Reply-To: <xp1GeD9sxlxv6tGdGdsvlvALexd61xOtyJ9eyiuylio=.6f5ebd2a-fe81-4785-ae70-6f79e82fa4d3@github.com>
References: <BxRBFQ-RXjXDRiF75q_IepNnhurF97pwc2r_YquJx1U=.485cb8de-9395-41e3-a97e-457da24385dd@github.com>
 <SYmHDwrLJYMBJgHLgrpZ5BFy_MpDOPNopMwzjD5_KrY=.11a6992a-1d6c-42d1-86af-b0b0ca444999@github.com>
 <xp1GeD9sxlxv6tGdGdsvlvALexd61xOtyJ9eyiuylio=.6f5ebd2a-fe81-4785-ae70-6f79e82fa4d3@github.com>
Message-ID: <0NPTXVswTQTbg52zjeuB26o5JHlFO8L_b_Ryy31nfNw=.1629bb1c-f153-4812-aaef-8fb4ddd767f9@github.com>

On Fri, 2 Jan 2026 10:19:59 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update copyrights
>
> test/hotspot/gtest/gc/g1/test_g1BatchedGangTask.cpp line 60:
> 
>> 58:   }
>> 59: 
>> 60:   Atomic<bool>* _do_work_called_by;
> 
> Can we use `GrowableArrayCHeap<Atomic<bool>, MemTag::mtInternal>` instead, and skip the manual destruction (and element construction)?

Right Atomic are non copyable ofc. Ignore this. :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29001#discussion_r2657483493

From fandreuzzi at openjdk.org  Fri Jan  2 11:56:23 2026
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 2 Jan 2026 11:56:23 GMT
Subject: RFR: 8374465: Spurious dot in documentation for JVMTI ClassLoad
Message-ID: <fh8w1UmlT38JcwUqc7Tgu2faJmGlVik4MogunSVHMVA=.f68cc7f1-b8bb-4e9b-9e09-e9a4eac032b8@github.com>

I spotted an unwanted additional dot in the documentation for JVMTI ClassLoad. I propose to remove it.

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

Commit messages:
 - remove dot

Changes: https://git.openjdk.org/jdk/pull/29017/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29017&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374465
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/29017.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29017/head:pull/29017

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

From aph at openjdk.org  Fri Jan  2 12:11:55 2026
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 2 Jan 2026 12:11:55 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v21]
In-Reply-To: <suIW5qm-iGcSsrmNPTjwP8XwHdUMcEQZsrGQyt97a0g=.23ea0dbc-f2f7-43ce-9377-45ebf645dcab@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
 <QedZccpniOaFQ_SbJqZd-IsyrdlBDa1CB1oa6vL1018=.a8378937-2234-499c-a1f6-20b8214afacd@github.com>
 <15wAKoik-66gfbUzGQEROBTv_cTV_I_6jq96S2ErOyA=.22e19b52-220c-4c35-9aaa-9f08719e16fa@github.com>
 <yPoVq-X-9UlWSVpOhumN8VxrSI_lBSR5efh5Z6iPc0w=.2f1ba28a-7b42-4b03-8e25-21b31b7ee965@github.com>
 <wSxY8IqN9mDrzQ5HuBr4twXO1U5s44BwvVGWIoKX5LI=.21dc2e0e-211a-41d3-9111-75929bad608b@github.com>
 <suIW5qm-iGcSsrmNPTjwP8XwHdUMcEQZsrGQyt97a0g=.23ea0dbc-f2f7-43ce-9377-45ebf645dcab@github.com>
Message-ID: <2b8w_8NwTITCCqqyirLgPcfxyQd35yS-MmPlO8rEwS0=.74b73b12-1b0a-4d73-b18f-1f6ac0e5f18d@github.com>

On Thu, 1 Jan 2026 20:35:25 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

> > Sure, I can see that, but is there any reason not to do this by default on all AArch64?
> 
> Do you mean to do this for all AArch64 OSes, not only for Linux AArch64?

In a perfect world we'd do this for all AArch64. But Linux-only would be good too. But is there any reason not to do this on all Linux systems?

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

PR Comment: https://git.openjdk.org/jdk/pull/28328#issuecomment-3705195536

From kbarrett at openjdk.org  Fri Jan  2 12:27:52 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 2 Jan 2026 12:27:52 GMT
Subject: RFR: 8374465: Spurious dot in documentation for JVMTI ClassLoad
In-Reply-To: <fh8w1UmlT38JcwUqc7Tgu2faJmGlVik4MogunSVHMVA=.f68cc7f1-b8bb-4e9b-9e09-e9a4eac032b8@github.com>
References: <fh8w1UmlT38JcwUqc7Tgu2faJmGlVik4MogunSVHMVA=.f68cc7f1-b8bb-4e9b-9e09-e9a4eac032b8@github.com>
Message-ID: <O_hjldZKrRs7RxKNCXKFeiMFKzrv-k76hAEvy7gqNUY=.e2eb50a7-296d-494d-a885-f2c2d81fcea8@github.com>

On Fri, 2 Jan 2026 11:48:16 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> I spotted an unwanted additional dot in the documentation for JVMTI ClassLoad. I propose to remove it.

Looks good, and trivial.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29017#pullrequestreview-3623040745

From fandreuzzi at openjdk.org  Fri Jan  2 12:40:00 2026
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 2 Jan 2026 12:40:00 GMT
Subject: RFR: 8374465: Spurious dot in documentation for JVMTI ClassLoad
In-Reply-To: <fh8w1UmlT38JcwUqc7Tgu2faJmGlVik4MogunSVHMVA=.f68cc7f1-b8bb-4e9b-9e09-e9a4eac032b8@github.com>
References: <fh8w1UmlT38JcwUqc7Tgu2faJmGlVik4MogunSVHMVA=.f68cc7f1-b8bb-4e9b-9e09-e9a4eac032b8@github.com>
Message-ID: <BAMcOdA9YtfhsDCtVdb_aqMPKIIchvIBv87vlB4hMvQ=.6125fe52-cbc5-4ab3-aade-b99799645e12@github.com>

On Fri, 2 Jan 2026 11:48:16 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> I spotted an unwanted additional dot in the documentation for JVMTI ClassLoad. I propose to remove it.

Failure looks unrelated: https://github.com/fandreuz/jdk/actions/runs/20657192979/job/59312268923#step:9:6386

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

PR Comment: https://git.openjdk.org/jdk/pull/29017#issuecomment-3705242964

From kbarrett at openjdk.org  Fri Jan  2 13:54:02 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 2 Jan 2026 13:54:02 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v21]
In-Reply-To: <QedZccpniOaFQ_SbJqZd-IsyrdlBDa1CB1oa6vL1018=.a8378937-2234-499c-a1f6-20b8214afacd@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
 <QedZccpniOaFQ_SbJqZd-IsyrdlBDa1CB1oa6vL1018=.a8378937-2234-499c-a1f6-20b8214afacd@github.com>
Message-ID: <1HoFAoxwMTDW1GJteYe1Bl3X9erLJtcdjdY7kEqOMgE=.f34e8855-352e-4654-9297-6af29b5f17de@github.com>

On Mon, 29 Dec 2025 21:51:20 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> Arm Neoverse N1 erratum 1542419: "The core might fetch a stale instruction from memory which violates the ordering of instruction fetches". It is fixed in Neoverse N1 r4p1.
>>  
>> Neoverse-N1 implementations mitigate erratum 1542419 with a workaround:
>> - Disable coherent icache.
>> - Trap IC IVAU instructions.
>> - Execute:
>>    - `tlbi vae3is, xzr`
>>    - `dsb sy`
>>  
>>  `tlbi vae3is, xzr` invalidates translations for all address spaces (global for address).  It waits for all memory accesses using in-scope old translation information to complete before it is considered complete.
>>  
>> As this workaround has significant overhead, Arm Neoverse N1 (MP050) Software Developer Errata Notice version 29.0 suggests:
>> 
>> "Since one TLB inner-shareable invalidation is enough to avoid this erratum, the number of injected TLB invalidations should be minimized in the trap handler to mitigate the performance impact due to this workaround."
>> 
>> This PR introduces a mechanism to defer instruction cache (ICache) invalidation for AArch64 to address the Arm Neoverse N1 erratum 1542419, which causes significant performance overhead if ICache invalidation is performed too frequently. The implementation includes detection of affected Neoverse N1 CPUs and automatic enabling of the workaround for relevant Neoverse N1 revisions.
>> 
>> Changes include:
>> 
>> * Added a new diagnostic JVM flag `NeoverseN1Errata1542419` to enable or disable the workaround for the erratum. The flag is automatically enabled for Neoverse N1 CPUs prior to r4p1, as detected during VM initialization.
>> * Introduced the `ICacheInvalidationContext` class to manage deferred ICache invalidation, with platform-specific logic for AArch64. This context is used to batch ICache invalidations, reducing performance impact. As the address for icache invalidation is not relevant, we use the nmethod's code start address.
>> * Provided a default (no-op) implementation for `ICacheInvalidationContext` on platforms where the workaround is not needed, ensuring portability and minimal impact on other architectures.
>> * Modified barrier patching and relocation logic (`ZBarrierSetAssembler`, `ZNMethod`, `RelocIterator`, and related code) to accept a `defer_icache_invalidation` parameter, allowing ICache invalidation to be deferred and later performed in bulk.
>> 
>> Testing results: linux fastdebug build
>> - Neoverse-N1 (Graviton 2)
>>    - [x] tier1: passed
>>    - [x] tier2: passed
>>    - [x] tier3: passed
>>    - [x] tier4: 3 failu...
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix linux-cross-compile riscv64 build

src/hotspot/share/runtime/icache.hpp line 139:

> 137: class DefaultICacheInvalidationContext : StackObj {
> 138:  private:
> 139:   NONCOPYABLE(DefaultICacheInvalidationContext);

Not a review, just a drive-by comment. @xmas92 suggested moving the `NONCOPYABLE` to the
private part of the class, as a style issue. It used to be that `NONCOPYABLE` was best used in the
private part of a class, because of how it was implemented.  But with the change to using deleted
definitions, it's actually better to have it in the public part. That way you get an "attempt to use a
deleted function" error rather than possibly getting an "attempt to use an inaccessible function"
error.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28328#discussion_r2657751265

From fandreuzzi at openjdk.org  Fri Jan  2 14:54:03 2026
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 2 Jan 2026 14:54:03 GMT
Subject: RFR: 8374465: Spurious dot in documentation for JVMTI ClassLoad
In-Reply-To: <O_hjldZKrRs7RxKNCXKFeiMFKzrv-k76hAEvy7gqNUY=.e2eb50a7-296d-494d-a885-f2c2d81fcea8@github.com>
References: <fh8w1UmlT38JcwUqc7Tgu2faJmGlVik4MogunSVHMVA=.f68cc7f1-b8bb-4e9b-9e09-e9a4eac032b8@github.com>
 <O_hjldZKrRs7RxKNCXKFeiMFKzrv-k76hAEvy7gqNUY=.e2eb50a7-296d-494d-a885-f2c2d81fcea8@github.com>
Message-ID: <F8uiQNsC1WCZs4yLcNRgkFOyeK1N14DsCxSOBodJljE=.00ec8f1d-c355-4900-8ae5-89a76159f0a3@github.com>

On Fri, 2 Jan 2026 12:23:48 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> I spotted an unwanted additional dot in the documentation for JVMTI ClassLoad. I propose to remove it.
>
> Looks good, and trivial.

Thanks for the review @kimbarrett.

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

PR Comment: https://git.openjdk.org/jdk/pull/29017#issuecomment-3705518190

From fandreuzzi at openjdk.org  Fri Jan  2 14:54:05 2026
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 2 Jan 2026 14:54:05 GMT
Subject: Integrated: 8374465: Spurious dot in documentation for JVMTI ClassLoad
In-Reply-To: <fh8w1UmlT38JcwUqc7Tgu2faJmGlVik4MogunSVHMVA=.f68cc7f1-b8bb-4e9b-9e09-e9a4eac032b8@github.com>
References: <fh8w1UmlT38JcwUqc7Tgu2faJmGlVik4MogunSVHMVA=.f68cc7f1-b8bb-4e9b-9e09-e9a4eac032b8@github.com>
Message-ID: <d7FYDYNSYPS6okNJhaH7YUEcB3D-l2bAQVYSQ7gnUYY=.09138388-8a4d-47b6-adca-a11013e72126@github.com>

On Fri, 2 Jan 2026 11:48:16 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> I spotted an unwanted additional dot in the documentation for JVMTI ClassLoad. I propose to remove it.

This pull request has now been integrated.

Changeset: 2daf12ed
Author:    Francesco Andreuzzi <fandreuzzi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2daf12edd24e641d4d7706d582994c2b3fe95e87
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8374465: Spurious dot in documentation for JVMTI ClassLoad

Reviewed-by: kbarrett

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

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

From eastigeevich at openjdk.org  Fri Jan  2 15:43:15 2026
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Fri, 2 Jan 2026 15:43:15 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v21]
In-Reply-To: <2b8w_8NwTITCCqqyirLgPcfxyQd35yS-MmPlO8rEwS0=.74b73b12-1b0a-4d73-b18f-1f6ac0e5f18d@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
 <QedZccpniOaFQ_SbJqZd-IsyrdlBDa1CB1oa6vL1018=.a8378937-2234-499c-a1f6-20b8214afacd@github.com>
 <15wAKoik-66gfbUzGQEROBTv_cTV_I_6jq96S2ErOyA=.22e19b52-220c-4c35-9aaa-9f08719e16fa@github.com>
 <yPoVq-X-9UlWSVpOhumN8VxrSI_lBSR5efh5Z6iPc0w=.2f1ba28a-7b42-4b03-8e25-21b31b7ee965@github.com>
 <wSxY8IqN9mDrzQ5HuBr4twXO1U5s44BwvVGWIoKX5LI=.21dc2e0e-211a-41d3-9111-75929bad608b@github.com>
 <suIW5qm-iGcSsrmNPTjwP8XwHdUMcEQZsrGQyt97a0g=.23ea0dbc-f2f7-43ce-9377-45ebf645dcab@github.com>
 <2b8w_8NwTITCCqqyirLgPcfxyQd35yS-MmPlO8rEwS0=.74b73b12-1b0a-4d73-b18f-1f6ac0e5f18d@github.com>
Message-ID: <uRdaUHBa5upBjQehzzvVabGhJWLxQlv1RZqap3JKUiI=.ec8805c2-d90c-4a7a-b2c2-ccff9e372f2f@github.com>

On Fri, 2 Jan 2026 12:07:57 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > > Sure, I can see that, but is there any reason not to do this by default on all AArch64?
> > 
> > 
> > Do you mean to do this for all AArch64 OSes, not only for Linux AArch64?
> 
> In a perfect world we'd do this for all AArch64. But Linux-only would be good too. But is there any reason not to do this on all Linux systems?

IMO, a reason is that not all AArch64 might have both `ctr_el0.IDC` and `ctr_el0.DIC` set. If either of `ctr_el0.IDC`/`ctr_el0.DIC` or both are not set, we will need to use `DC`/`IC` with real addresses to clean and to invalidate caches. We will need to choose between invalidating modified instructions or the whole nmethod's code. Invalidating modified instructions will need tracking of modified instructions. Invalidating the whole nmethod does not need tracking but it can be expensive vs invalidating particular instructions.

IMO cases of Java running on AArch64 CPU where both `ctr_el0.IDC` and `ctr_el0.DIC` are not set, might be rare.

Jacob Bramley from Arm has nice blog posts about Caches and Self-Modifying Code:
- [Caches and Self-Modifying Code: Implementing `__clear_cache`](https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-implementing-clear-cache)
- [Caches and Self-Modifying Code: Working with Threads](https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-working-with-threads)

In this PR we optimize two parts invalidating caches:
1. GCs patching code. This is invalidation of modified instructions.
2. Generation and installation of code. This is invalidation of the whole code.

The second case can be optimized for all AArch64.

Is there anything I am missing? And we can do optimized cache invalidation on all AArch64?

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

PR Comment: https://git.openjdk.org/jdk/pull/28328#issuecomment-3705607781

From aph at openjdk.org  Fri Jan  2 18:06:58 2026
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 2 Jan 2026 18:06:58 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v21]
In-Reply-To: <uRdaUHBa5upBjQehzzvVabGhJWLxQlv1RZqap3JKUiI=.ec8805c2-d90c-4a7a-b2c2-ccff9e372f2f@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
 <QedZccpniOaFQ_SbJqZd-IsyrdlBDa1CB1oa6vL1018=.a8378937-2234-499c-a1f6-20b8214afacd@github.com>
 <15wAKoik-66gfbUzGQEROBTv_cTV_I_6jq96S2ErOyA=.22e19b52-220c-4c35-9aaa-9f08719e16fa@github.com>
 <yPoVq-X-9UlWSVpOhumN8VxrSI_lBSR5efh5Z6iPc0w=.2f1ba28a-7b42-4b03-8e25-21b31b7ee965@github.com>
 <wSxY8IqN9mDrzQ5HuBr4twXO1U5s44BwvVGWIoKX5LI=.21dc2e0e-211a-41d3-9111-75929bad608b@github.com>
 <suIW5qm-iGcSsrmNPTjwP8XwHdUMcEQZsrGQyt97a0g=.23ea0dbc-f2f7-43ce-9377-45ebf645dcab@github.com>
 <2b8w_8NwTITCCqqyirLgPcfxyQd35yS-MmPlO8rEwS0=.74b73b12-1b0a-4d73-b18f-1f6ac0e5f18d@github.com>
 <uRdaUHBa5upBjQehzzvVabGhJWLxQlv1RZqap3JKUiI=.ec8805c2-d90c-4a7a-b2c2-ccff9e372f2f@github.com>
Message-ID: <bZH11dR4PKPMERnMJAHvz2hCNr6B_eP8M3eyJ9pdvwk=.2d7d331a-a411-48b9-9c56-ea4915a6c5d1@github.com>

On Fri, 2 Jan 2026 15:39:50 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

> > > > Sure, I can see that, but is there any reason not to do this by default on all AArch64?
> > > 
> > > 
> > > Do you mean to do this for all AArch64 OSes, not only for Linux AArch64?
> > 
> > 
> > In a perfect world we'd do this for all AArch64. But Linux-only would be good too. But is there any reason not to do this on all Linux systems?
> 
> IMO, a reason is that not all AArch64 might have both `ctr_el0.IDC` and `ctr_el0.DIC` set. If either of `ctr_el0.IDC`/`ctr_el0.DIC` or both are not set, we will need to use `DC`/`IC` with real addresses to clean and to invalidate caches. We will need to choose between invalidating modified instructions or the whole nmethod's code. Invalidating modified instructions will need tracking of modified instructions. Invalidating the whole nmethod does not need tracking but it can be expensive vs invalidating particular instructions.

Ah, I see. So it looks like we'll have to maintain two entirely different bodies of code to do the cache management. That will be a recurring pain, and is disappointing.

> 
> IMO cases of Java running on AArch64 CPU where both `ctr_el0.IDC` and `ctr_el0.DIC` are not set, might be rare.
> 
> Jacob Bramley from Arm has nice blog posts about Caches and Self-Modifying Code:
> 
>     * [Caches and Self-Modifying Code: Implementing `__clear_cache`](https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-implementing-clear-cache)

That's useful. It's worth taking advantage of cache-coherent implementations (when they're not broken!) by not emitting unnecessary instructions.

>     * [Caches and Self-Modifying Code: Working with Threads](https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-working-with-threads)

Thanks. That's a good read, but no surprises. I'm fairly sure we've been doing most of that for as long as the port has existed.

> In this PR we optimize two parts invalidating caches:
> 
>     1. GCs patching code. This is invalidation of modified instructions.
> 
>     2. Generation and installation of code. This is invalidation of the whole code.
> 
> 
> The second case can be optimized for all AArch64.
> 
> Is there anything I am missing? And we can do optimized cache invalidation on all AArch64?

Probably not,  but I've been working on a patch to minimize the invalidation we do today.

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

PR Comment: https://git.openjdk.org/jdk/pull/28328#issuecomment-3705936075

From eastigeevich at openjdk.org  Fri Jan  2 22:07:00 2026
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Fri, 2 Jan 2026 22:07:00 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v21]
In-Reply-To: <bZH11dR4PKPMERnMJAHvz2hCNr6B_eP8M3eyJ9pdvwk=.2d7d331a-a411-48b9-9c56-ea4915a6c5d1@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
 <QedZccpniOaFQ_SbJqZd-IsyrdlBDa1CB1oa6vL1018=.a8378937-2234-499c-a1f6-20b8214afacd@github.com>
 <15wAKoik-66gfbUzGQEROBTv_cTV_I_6jq96S2ErOyA=.22e19b52-220c-4c35-9aaa-9f08719e16fa@github.com>
 <yPoVq-X-9UlWSVpOhumN8VxrSI_lBSR5efh5Z6iPc0w=.2f1ba28a-7b42-4b03-8e25-21b31b7ee965@github.com>
 <wSxY8IqN9mDrzQ5HuBr4twXO1U5s44BwvVGWIoKX5LI=.21dc2e0e-211a-41d3-9111-75929bad608b@github.com>
 <suIW5qm-iGcSsrmNPTjwP8XwHdUMcEQZsrGQyt97a0g=.23ea0dbc-f2f7-43ce-9377-45ebf645dcab@github.com>
 <2b8w_8NwTITCCqqyirLgPcfxyQd35yS-MmPlO8rEwS0=.74b73b12-1b0a-4d73-b18f-1f6ac0e5f18d@github.com>
 <uRdaUHBa5upBjQehzzvVabGhJWLxQlv1RZqap3JKUiI=.ec8805c2-d90c-4a7a-b2c2-ccff9e372f2f@github.com>
 <bZH11dR4PKPMERnMJAHvz2hCNr6B_eP8M3eyJ9pdvwk=.2d7d331a-a411-48b9-9c56-ea4915a6c5d1@github.com>
Message-ID: <Q2-63X_5ML0DhzCqJyl7BjFaQ16dS4gnDbYIKGk0od8=.ad75e4ee-be1c-43e9-bf52-4614f5dd4cd9@github.com>

On Fri, 2 Jan 2026 18:02:49 GMT, Andrew Haley <aph at openjdk.org> wrote:

>>> > > Sure, I can see that, but is there any reason not to do this by default on all AArch64?
>>> > 
>>> > 
>>> > Do you mean to do this for all AArch64 OSes, not only for Linux AArch64?
>>> 
>>> In a perfect world we'd do this for all AArch64. But Linux-only would be good too. But is there any reason not to do this on all Linux systems?
>> 
>> IMO, a reason is that not all AArch64 might have both `ctr_el0.IDC` and `ctr_el0.DIC` set. If either of `ctr_el0.IDC`/`ctr_el0.DIC` or both are not set, we will need to use `DC`/`IC` with real addresses to clean and to invalidate caches. We will need to choose between invalidating modified instructions or the whole nmethod's code. Invalidating modified instructions will need tracking of modified instructions. Invalidating the whole nmethod does not need tracking but it can be expensive vs invalidating particular instructions.
>> 
>> IMO cases of Java running on AArch64 CPU where both `ctr_el0.IDC` and `ctr_el0.DIC` are not set, might be rare.
>> 
>> Jacob Bramley from Arm has nice blog posts about Caches and Self-Modifying Code:
>> - [Caches and Self-Modifying Code: Implementing `__clear_cache`](https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-implementing-clear-cache)
>> - [Caches and Self-Modifying Code: Working with Threads](https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-working-with-threads)
>> 
>> In this PR we optimize two parts invalidating caches:
>> 1. GCs patching code. This is invalidation of modified instructions.
>> 2. Generation and installation of code. This is invalidation of the whole code.
>> 
>> The second case can be optimized for all AArch64.
>> 
>> Is there anything I am missing? And we can do optimized cache invalidation on all AArch64?
>
>> > > > Sure, I can see that, but is there any reason not to do this by default on all AArch64?
>> > > 
>> > > 
>> > > Do you mean to do this for all AArch64 OSes, not only for Linux AArch64?
>> > 
>> > 
>> > In a perfect world we'd do this for all AArch64. But Linux-only would be good too. But is there any reason not to do this on all Linux systems?
>> 
>> IMO, a reason is that not all AArch64 might have both `ctr_el0.IDC` and `ctr_el0.DIC` set. If either of `ctr_el0.IDC`/`ctr_el0.DIC` or both are not set, we will need to use `DC`/`IC` with real addresses to clean and to invalidate caches. We will need to choose between invalidating modified instructions or the whole nmethod's code. Invalidating modified instructions will need tracking of modified instructions. Invalidating the whole nmethod does not need tracking but it can be expensive vs invalidating particular instructions.
> 
> Ah, I see. So it looks like we'll have to maintain two entirely different bodies of code to do the cache management. That will be a recurring pain, and is disappointing.
> 
>> 
>> IMO cases of Java running on AArch64 CPU where both `ctr_el0.IDC` and `ctr_el0.DIC` are not set, might be rare.
>> 
>> Jacob Bramley from Arm has nice blog posts about Caches and Self-Modifying Code:
>> 
>>     * [Caches and Self-Modifying Code: Implementing `__clear_cache`](https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-implementing-clear-cache)
> 
> That's useful. It's worth taking advantage of cache-coherent implementations (when they're not broken!) by not emitting unnecessary instructions.
> 
>>     * [Caches and Self-Modifying Code: Working with Threads](https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-working-with-threads)
> 
> Thanks. That's a good read, but no surprises. I'm fairly sure we've been doing most of that for as long as the port has existed.
> 
>> In this PR we optimize two parts invalidating caches:
>> 
>>     1. GCs patching code. This is invalidation of modified instructions.
>> 
>>     2. Generation and installation of code. This is invalidation of the whole code.
>> 
>> 
>> The second case can be optimized for all AArch64.
>> 
>> Is there anything I am missing? And we can do optimized cache invalidation on all AArch64?
> 
> Probably not,  but I've been working on a patch to minimize the invalidation we do today.

@theRealAph

> ...
> Probably not, but I've been working on a patch to minimize the invalidation we do today. 

Does this mean we don't need this PR or need to rework it? Could you please provide more details?

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

PR Comment: https://git.openjdk.org/jdk/pull/28328#issuecomment-3706299227

From lmesnik at openjdk.org  Sat Jan  3 02:56:08 2026
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 3 Jan 2026 02:56:08 GMT
Subject: Integrated: 8343809: Add requires tag to mark tests that are
 incompatible with exploded image
In-Reply-To: <GtxujYXXFK6Y32kkijCc7XyGcMStlbQs7C9OM2QxmfM=.cbfe5c94-c9ab-4852-bad2-66deb4932723@github.com>
References: <GtxujYXXFK6Y32kkijCc7XyGcMStlbQs7C9OM2QxmfM=.cbfe5c94-c9ab-4852-bad2-66deb4932723@github.com>
Message-ID: <I22rr_bOrT4mg7B6pPG7jABi5ToBerThewueMhNb7Jg=.a1af79d5-8bca-4351-b54b-eb2b7b953ede@github.com>

On Sat, 13 Dec 2025 20:01:13 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The 
> jdk.explodedImage
> might be used to filter tests incompatible with 
> make exploded-run-test TEST=...
> 
> The exploded-run-test  mode is used only for quick manual testing and not in CI or ATR testing. However, it is make sense to reduce false positive failures so developers don't waste time during local testing.

This pull request has now been integrated.

Changeset: 53824cf2
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/53824cf2a97adbc25d32bec0acaff24d105081f9
Stats:     22 lines in 5 files changed: 20 ins; 0 del; 2 mod

8343809: Add requires tag to mark tests that are incompatible with exploded image

Reviewed-by: alanb, dholmes

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

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

From kbarrett at openjdk.org  Sat Jan  3 07:03:01 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 3 Jan 2026 07:03:01 GMT
Subject: RFR: 8374350: Convert hotspot gtests to use Atomic<T> [v2]
In-Reply-To: <SYmHDwrLJYMBJgHLgrpZ5BFy_MpDOPNopMwzjD5_KrY=.11a6992a-1d6c-42d1-86af-b0b0ca444999@github.com>
References: <BxRBFQ-RXjXDRiF75q_IepNnhurF97pwc2r_YquJx1U=.485cb8de-9395-41e3-a97e-457da24385dd@github.com>
 <SYmHDwrLJYMBJgHLgrpZ5BFy_MpDOPNopMwzjD5_KrY=.11a6992a-1d6c-42d1-86af-b0b0ca444999@github.com>
Message-ID: <2BsNqPX7px4ySEnRdMif4KFSqS8cE8oIyi_BmO8Qkts=.afb1a1fd-385d-4a53-a1b8-355fe4eec80c@github.com>

On Fri, 2 Jan 2026 10:08:26 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to convert HotSpot gtests to use Atomic<T> rather
>> than directly using AtomicAccess.
>> 
>> test_atomicAccess.cpp is, of course, not subject to this conversion.
>> 
>> test_globalCounter.cpp is also not included in this conversion.  The other
>> conversions were straight forward.  This test is less so, and I decided I
>> needed to spend more time studying it, so have left it for followup work.
>> 
>> The conversion of each test is a separate commit, in case that makes it easier
>> to review.
>> 
>> Testing: mach5 tier1
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyrights

GHA linux-x64-debug build failed because out of disk space.

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

PR Comment: https://git.openjdk.org/jdk/pull/29001#issuecomment-3706843863

From aph at openjdk.org  Sat Jan  3 09:59:05 2026
From: aph at openjdk.org (Andrew Haley)
Date: Sat, 3 Jan 2026 09:59:05 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v21]
In-Reply-To: <Q2-63X_5ML0DhzCqJyl7BjFaQ16dS4gnDbYIKGk0od8=.ad75e4ee-be1c-43e9-bf52-4614f5dd4cd9@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
 <QedZccpniOaFQ_SbJqZd-IsyrdlBDa1CB1oa6vL1018=.a8378937-2234-499c-a1f6-20b8214afacd@github.com>
 <15wAKoik-66gfbUzGQEROBTv_cTV_I_6jq96S2ErOyA=.22e19b52-220c-4c35-9aaa-9f08719e16fa@github.com>
 <yPoVq-X-9UlWSVpOhumN8VxrSI_lBSR5efh5Z6iPc0w=.2f1ba28a-7b42-4b03-8e25-21b31b7ee965@github.com>
 <wSxY8IqN9mDrzQ5HuBr4twXO1U5s44BwvVGWIoKX5LI=.21dc2e0e-211a-41d3-9111-75929bad608b@github.com>
 <suIW5qm-iGcSsrmNPTjwP8XwHdUMcEQZsrGQyt97a0g=.23ea0dbc-f2f7-43ce-9377-45ebf645dcab@github.com>
 <2b8w_8NwTITCCqqyirLgPcfxyQd35yS-MmPlO8rEwS0=.74b73b12-1b0a-4d73-b18f-1f6ac0e5f18d@github.com>
 <uRdaUHBa5upBjQehzzvVabGhJWLxQlv1RZqap3JKUiI=.ec8805c2-d90c-4a7a-b2c2-ccff9e372f2f@github.com>
 <bZH11dR4PKPMERnMJAHvz2hCNr6B_eP8M3eyJ9pdvwk=.2d7d331a-a411-48b9-9c56-ea4915a6c5d1@github.com>
 <Q2-63X_5ML0DhzCqJyl7BjFaQ16dS4gnDbYIKGk0od8=.ad75e4ee-be1c-43e9-bf52-4614f5dd4cd9@github.com>
Message-ID: <8hQOV9QhPL_j5g7WpcwzJc_8QPeAzLSIFk3ASRlCXa8=.3e1ac93f-2f6a-4dce-bead-31241240cb6e@github.com>

On Fri, 2 Jan 2026 22:04:00 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

> > Probably not, but I've been working on a patch to minimize the invalidation we do today.
> 
> Does this mean we don't need this PR or need to rework it? Could you please provide more details?

It makes no difference to this patch. I'm still experimenting.

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

PR Comment: https://git.openjdk.org/jdk/pull/28328#issuecomment-3706937169

From lmesnik at openjdk.org  Sat Jan  3 19:52:27 2026
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 3 Jan 2026 19:52:27 GMT
Subject: RFR: 8374483: Eliminate :serviceability_ttf_virtual group and mark svc
 non-virtual tests with requires
Message-ID: <vcJ-FiE-QJuQ7V3p2QU5hbFh48GyYEIf15yOANmSvi4=.737c9a42-5886-4839-a5e6-66e1fe1cf8f0@github.com>

Remove group :serviceability_ttf_virtual and mark only failing tests with requires.

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

Commit messages:
 - updated tests

Changes: https://git.openjdk.org/jdk/pull/29024/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29024&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374483
  Stats: 52 lines in 19 files changed: 26 ins; 7 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/29024.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29024/head:pull/29024

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

From syan at openjdk.org  Sun Jan  4 02:41:05 2026
From: syan at openjdk.org (SendaoYan)
Date: Sun, 4 Jan 2026 02:41:05 GMT
Subject: RFR: 8374483: Eliminate :serviceability_ttf_virtual group and mark
 svc non-virtual tests with requires
In-Reply-To: <vcJ-FiE-QJuQ7V3p2QU5hbFh48GyYEIf15yOANmSvi4=.737c9a42-5886-4839-a5e6-66e1fe1cf8f0@github.com>
References: <vcJ-FiE-QJuQ7V3p2QU5hbFh48GyYEIf15yOANmSvi4=.737c9a42-5886-4839-a5e6-66e1fe1cf8f0@github.com>
Message-ID: <-sYToet_Qr8ddZAeRXW_5HoEJqfwCYNcWm0myfHVO-w=.a4955764-1b19-450c-b1cd-ca71d74376d0@github.com>

On Sat, 3 Jan 2026 19:44:50 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Remove group :serviceability_ttf_virtual and mark only failing tests with requires.

Marked as reviewed by syan (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/29024#pullrequestreview-3624638135

From VicWang at zhaoxin.com  Sun Jan  4 03:06:22 2026
From: VicWang at zhaoxin.com (Vic Wang(BJ-RD))
Date: Sun, 4 Jan 2026 03:06:22 +0000
Subject: RFR: 8367478: Improve UseAVX setting and add cpu descriptions for
 zhaoxin processors
Message-ID: <8f5b4548d6554be88fec81a6d09fad7b@zhaoxin.com>


>-----Original Message-----
>From: hotspot-dev <hotspot-dev-retn at openjdk.org> On Behalf Of Vic Wang
>Sent: Thursday, December 4, 2025 7:44 AM
>To: hotspot-dev at openjdk.org
>Subject: RFR: 8367478: Improve UseAVX setting and add cpu descriptions for zhaoxin processors
>
>
>Here is the patch that improving the UseAVX setting and add cpu descriptions for zhaoxin processors.
>Can you help to review this patch?
>Thank you!
>
>-------------
>
>Commit messages:
> - Improve UseAVX setting and add cpu descriptions for zhaoxin processors.
>
>Changes: https://git.openjdk.org/jdk/pull/27241/files
>  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27241&range=00
>  Issue: https://bugs.openjdk.org/browse/JDK-8367478
>  Stats: 37 lines in 1 file changed: 34 ins; 0 del; 3 mod
>  Patch: https://git.openjdk.org/jdk/pull/27241.diff
>  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27241/head:pull/27241
>
>PR: https://git.openjdk.org/jdk/pull/27241

Hi All,

Can you help review this PR?
Please let me know if any additional information or changes are needed.

Thanks!
Vic Wang


?????
?????????????????????????????????????????????????????
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.

From jiefu at openjdk.org  Sun Jan  4 03:38:56 2026
From: jiefu at openjdk.org (Jie Fu)
Date: Sun, 4 Jan 2026 03:38:56 GMT
Subject: RFR: 8367478: Improve UseAVX setting and add cpu descriptions for
 zhaoxin processors
In-Reply-To: <LBWpAyFqe8AT4WYw6cSWlvouAtJQ2FnsWudpyucG4ic=.4be84eb3-fba2-4954-b024-9803136f80b2@github.com>
References: <LBWpAyFqe8AT4WYw6cSWlvouAtJQ2FnsWudpyucG4ic=.4be84eb3-fba2-4954-b024-9803136f80b2@github.com>
Message-ID: <PhKpcw_O-whj6RMf4EcM1IRZ-imZvLR1Rzc3QGyBoZo=.a537e8af-59e6-433b-8d12-429143f41fbe@github.com>

On Fri, 12 Sep 2025 01:49:23 GMT, Vic Wang <duke at openjdk.org> wrote:

> Here is the patch that improving the UseAVX setting and add cpu descriptions for zhaoxin processors.
> Can you help to review this patch?
> Thank you!

src/hotspot/cpu/x86/vm_version_x86.cpp line 2603:

> 2601: const char* VM_Version::cpu_family_description(void) {
> 2602:   int cpu_family_id = extended_cpu_family();
> 2603:   int cpu_model_id = extended_cpu_model();

If `cpu_model_id` is only used by zx, how about moving it after line 2617?

Also, please merge with the latest code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27241#discussion_r2659298009

From duke at openjdk.org  Sun Jan  4 06:57:29 2026
From: duke at openjdk.org (Vic Wang)
Date: Sun, 4 Jan 2026 06:57:29 GMT
Subject: RFR: 8367478: Improve UseAVX setting and add cpu descriptions for
 zhaoxin processors [v2]
In-Reply-To: <LBWpAyFqe8AT4WYw6cSWlvouAtJQ2FnsWudpyucG4ic=.4be84eb3-fba2-4954-b024-9803136f80b2@github.com>
References: <LBWpAyFqe8AT4WYw6cSWlvouAtJQ2FnsWudpyucG4ic=.4be84eb3-fba2-4954-b024-9803136f80b2@github.com>
Message-ID: <y422XoyyzWDNigwlPU0nvv30TwFye9vZ3b3Kzdr72Yo=.e1180718-0dd0-456a-8209-753b5a60e259@github.com>

> Here is the patch that improving the UseAVX setting and add cpu descriptions for zhaoxin processors.
> Can you help to review this patch?
> Thank you!

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

 - Merge branch 'openjdk:master' into master-20250911
 - Improve UseAVX setting and add cpu descriptions for zhaoxin processors.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27241/files
  - new: https://git.openjdk.org/jdk/pull/27241/files/06498b42..c75c0eff

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

  Stats: 599769 lines in 7696 files changed: 414246 ins; 115374 del; 70149 mod
  Patch: https://git.openjdk.org/jdk/pull/27241.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27241/head:pull/27241

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

From duke at openjdk.org  Sun Jan  4 10:07:31 2026
From: duke at openjdk.org (Vic Wang)
Date: Sun, 4 Jan 2026 10:07:31 GMT
Subject: RFR: 8367478: Improve UseAVX setting and add cpu descriptions for
 zhaoxin processors [v3]
In-Reply-To: <LBWpAyFqe8AT4WYw6cSWlvouAtJQ2FnsWudpyucG4ic=.4be84eb3-fba2-4954-b024-9803136f80b2@github.com>
References: <LBWpAyFqe8AT4WYw6cSWlvouAtJQ2FnsWudpyucG4ic=.4be84eb3-fba2-4954-b024-9803136f80b2@github.com>
Message-ID: <MDgUlsHJ4C2McXJhDU3fYO-7zmHjwPdpItdwJaw33Os=.b0baa6d3-71da-4aa5-9526-48619f501eac@github.com>

> Here is the patch that improving the UseAVX setting and add cpu descriptions for zhaoxin processors.
> Can you help to review this patch?
> Thank you!

Vic Wang 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 two new commits since the last revision:

 - Move cpu_model_id to the zx-specific if branch.
 - Improve UseAVX setting and add cpu descriptions for zhaoxin processors.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27241/files
  - new: https://git.openjdk.org/jdk/pull/27241/files/c75c0eff..535af7ba

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

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

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

From duke at openjdk.org  Mon Jan  5 01:00:07 2026
From: duke at openjdk.org (Vic Wang)
Date: Mon, 5 Jan 2026 01:00:07 GMT
Subject: RFR: 8367478: Improve UseAVX setting and add cpu descriptions for
 zhaoxin processors [v3]
In-Reply-To: <PhKpcw_O-whj6RMf4EcM1IRZ-imZvLR1Rzc3QGyBoZo=.a537e8af-59e6-433b-8d12-429143f41fbe@github.com>
References: <LBWpAyFqe8AT4WYw6cSWlvouAtJQ2FnsWudpyucG4ic=.4be84eb3-fba2-4954-b024-9803136f80b2@github.com>
 <PhKpcw_O-whj6RMf4EcM1IRZ-imZvLR1Rzc3QGyBoZo=.a537e8af-59e6-433b-8d12-429143f41fbe@github.com>
Message-ID: <CUktlZy90vJP32WC1yKe0gT8zWdvJR73LtNM-579D7o=.6db0910b-6815-4269-8e39-b141a050e08b@github.com>

On Sun, 4 Jan 2026 03:36:33 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Vic Wang 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 two new commits since the last revision:
>> 
>>  - Move cpu_model_id to the zx-specific if branch.
>>  - Improve UseAVX setting and add cpu descriptions for zhaoxin processors.
>
> src/hotspot/cpu/x86/vm_version_x86.cpp line 2603:
> 
>> 2601: const char* VM_Version::cpu_family_description(void) {
>> 2602:   int cpu_family_id = extended_cpu_family();
>> 2603:   int cpu_model_id = extended_cpu_model();
> 
> If `cpu_model_id` is only used by zx, how about moving it after line 2617?
> 
> Also, please merge with the latest code.

Thanks for the suggestion! 
I?ve moved cpu_model_id to the zx-specific if branch after line 2617. And I?ve also merged with the latest code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27241#discussion_r2660059688

From jiefu at openjdk.org  Mon Jan  5 02:21:56 2026
From: jiefu at openjdk.org (Jie Fu)
Date: Mon, 5 Jan 2026 02:21:56 GMT
Subject: RFR: 8367478: Improve UseAVX setting and add cpu descriptions for
 zhaoxin processors [v3]
In-Reply-To: <MDgUlsHJ4C2McXJhDU3fYO-7zmHjwPdpItdwJaw33Os=.b0baa6d3-71da-4aa5-9526-48619f501eac@github.com>
References: <LBWpAyFqe8AT4WYw6cSWlvouAtJQ2FnsWudpyucG4ic=.4be84eb3-fba2-4954-b024-9803136f80b2@github.com>
 <MDgUlsHJ4C2McXJhDU3fYO-7zmHjwPdpItdwJaw33Os=.b0baa6d3-71da-4aa5-9526-48619f501eac@github.com>
Message-ID: <9R90qVMedt6prUnfCZPBD6Q84zdGHSWyEfBvc8wqlZk=.945c2b8a-bf48-47c7-b15a-e5050ad545c7@github.com>

On Sun, 4 Jan 2026 10:07:31 GMT, Vic Wang <duke at openjdk.org> wrote:

>> Here is the patch that improving the UseAVX setting and add cpu descriptions for zhaoxin processors.
>> Can you help to review this patch?
>> Thank you!
>
> Vic Wang 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 two new commits since the last revision:
> 
>  - Move cpu_model_id to the zx-specific if branch.
>  - Improve UseAVX setting and add cpu descriptions for zhaoxin processors.

Thanks for the update.
The changes are all zx-only related, which looks fine to me.

Can you show us some performance number before and after this change?

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

PR Comment: https://git.openjdk.org/jdk/pull/27241#issuecomment-3708718966

From shade at openjdk.org  Mon Jan  5 06:38:07 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 5 Jan 2026 06:38:07 GMT
Subject: RFR: 8357258: x86: Improve receiver type profiling reliability
 [v10]
In-Reply-To: <X9RJoDWqk67MlK7P4ACCbzROxLkfEqvU0zDid3zymnc=.7c0086a3-f514-4b0d-8bc0-592bf4a05bba@github.com>
References: <X9RJoDWqk67MlK7P4ACCbzROxLkfEqvU0zDid3zymnc=.7c0086a3-f514-4b0d-8bc0-592bf4a05bba@github.com>
Message-ID: <ThUdNW8z1RPz_Q6nWF73g7O93F2HIMo_5MqcdXIcazQ=.f9d6c4be-f0a4-4e57-bea9-7f033ffe4281@github.com>

> See the bug for discussion what issues current machinery has. 
> 
> This PR executes the plan outlined in the bug:
>  1. Common the receiver type profiling code in interpreter and C1
>  2. Rewrite receiver type profiling code to only do atomic receiver slot installations
>  3. Trim `C1OptimizeVirtualCallProfiling` to only claim slots when receiver is installed 
> 
> This PR does _not_ do atomic counter updates themselves, as it may have much wider performance implications, including regressions. This PR should be at least performance neutral.
> 
> Additional testing:
>   - [x] Linux x86_64 server fastdebug, `compiler/`
>   - [x] Linux x86_64 server fastdebug, `all`

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - Merge branch 'master' into JDK-8357258-x86-c1-optimize-virt-calls
 - Merge branch 'master' into JDK-8357258-x86-c1-optimize-virt-calls
 - Merge branch 'master' into JDK-8357258-x86-c1-optimize-virt-calls
 - More comments
 - Tighten up the comments
 - Simplify third case: no need to loop, just restart the search
 - Actually have a second "fast" case: receiver is not found in the table, and the table is full
 - Pushing/popping for rare CAS path is counter-productive
 - Merge branch 'master' into JDK-8357258-x86-c1-optimize-virt-calls
 - Tighten up some more
 - ... and 13 more: https://git.openjdk.org/jdk/compare/6eaabed5...e4a4719f

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

Changes: https://git.openjdk.org/jdk/pull/25305/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25305&range=09
  Stats: 418 lines in 8 files changed: 202 ins; 197 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/25305.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25305/head:pull/25305

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

From duke at openjdk.org  Mon Jan  5 08:02:29 2026
From: duke at openjdk.org (Vic Wang)
Date: Mon, 5 Jan 2026 08:02:29 GMT
Subject: RFR: 8367478: Improve UseAVX setting and add cpu descriptions for
 zhaoxin processors [v3]
In-Reply-To: <9R90qVMedt6prUnfCZPBD6Q84zdGHSWyEfBvc8wqlZk=.945c2b8a-bf48-47c7-b15a-e5050ad545c7@github.com>
References: <LBWpAyFqe8AT4WYw6cSWlvouAtJQ2FnsWudpyucG4ic=.4be84eb3-fba2-4954-b024-9803136f80b2@github.com>
 <MDgUlsHJ4C2McXJhDU3fYO-7zmHjwPdpItdwJaw33Os=.b0baa6d3-71da-4aa5-9526-48619f501eac@github.com>
 <9R90qVMedt6prUnfCZPBD6Q84zdGHSWyEfBvc8wqlZk=.945c2b8a-bf48-47c7-b15a-e5050ad545c7@github.com>
Message-ID: <VJT9CUHJDQfFPrTFaOMjRvf_8RM-vA6OjeRMsaQFtGw=.778adb8c-e4da-4a74-b2d9-30f6d7354cd6@github.com>

On Mon, 5 Jan 2026 02:17:50 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Thanks for the update. The changes are all zx-only related, which looks fine to me.
> 
> Can you show us some performance number before and after this change?

The performance improvement from this change is not significant. The main purpose of the patch is to add better selection  for UseUVX across different models. 
Additionally, I noticed that the GHA build (debug) failed due to 'No space left on device,' which is related to disk space. Does it affect the patch submission? And how to solve it?

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

PR Comment: https://git.openjdk.org/jdk/pull/27241#issuecomment-3709323530

From mgronlun at openjdk.org  Mon Jan  5 09:05:27 2026
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 5 Jan 2026 09:05:27 GMT
Subject: RFR: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is
 incorrectly implemented
In-Reply-To: <SiBemHHhiHk3uDElvjRK16U2SNea7P1wsptA_4z7kxA=.0746951f-41b4-46b4-8397-40603dea6298@github.com>
References: <SiBemHHhiHk3uDElvjRK16U2SNea7P1wsptA_4z7kxA=.0746951f-41b4-46b4-8397-40603dea6298@github.com>
Message-ID: <GgFilruNtT2lf2RywGZvtAOh49gv_rzci7-8fne2-Qo=.c174ae8b-0a18-41fc-84ba-4297eca0f236@github.com>

On Sat, 29 Nov 2025 06:06:16 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> The jtreg test TestEmergencyDumpAtOOM.java runs into the following error on ppc64 platforms.
> 
> JFR emergency dump would be kicked at `VMError::report_and_die()`, then Java thread for JFR would not work due to secondary signal handler for error reporting.
> 
> Passed all of jdk_jfr tests on Linux AMD64.

This will not work because there is still a race against the JFR Recorder Thread flushing concurrently with LeakProfiler::emit_events(). This can place the checkpoints and events in a segment before the corresponding classes and methods that were tagged as part of emit_events(). This will break the parser, since constant artifacts will not be resolvable (an invariant is that a flushed segment is self-contained).

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

PR Comment: https://git.openjdk.org/jdk/pull/28563#issuecomment-3709513877

From mgronlun at openjdk.org  Mon Jan  5 09:09:03 2026
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 5 Jan 2026 09:09:03 GMT
Subject: RFR: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is
 incorrectly implemented
In-Reply-To: <SiBemHHhiHk3uDElvjRK16U2SNea7P1wsptA_4z7kxA=.0746951f-41b4-46b4-8397-40603dea6298@github.com>
References: <SiBemHHhiHk3uDElvjRK16U2SNea7P1wsptA_4z7kxA=.0746951f-41b4-46b4-8397-40603dea6298@github.com>
Message-ID: <MsvaLuD485VMf7u3myQwjGv1E2LyEDK0hGUOdp5epos=.53bfc82b-fd66-4c02-9bd6-0dbf522e2a7b@github.com>

On Sat, 29 Nov 2025 06:06:16 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> The jtreg test TestEmergencyDumpAtOOM.java runs into the following error on ppc64 platforms.
> 
> JFR emergency dump would be kicked at `VMError::report_and_die()`, then Java thread for JFR would not work due to secondary signal handler for error reporting.
> 
> Passed all of jdk_jfr tests on Linux AMD64.

This is a very tricky problem to solve correctly, because a VM operation has been introduced as part of error reporting and the VM shutdown sequence.

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

PR Comment: https://git.openjdk.org/jdk/pull/28563#issuecomment-3709521319

From jiefu at openjdk.org  Mon Jan  5 09:13:11 2026
From: jiefu at openjdk.org (Jie Fu)
Date: Mon, 5 Jan 2026 09:13:11 GMT
Subject: RFR: 8367478: Improve UseAVX setting and add cpu descriptions for
 zhaoxin processors [v3]
In-Reply-To: <VJT9CUHJDQfFPrTFaOMjRvf_8RM-vA6OjeRMsaQFtGw=.778adb8c-e4da-4a74-b2d9-30f6d7354cd6@github.com>
References: <LBWpAyFqe8AT4WYw6cSWlvouAtJQ2FnsWudpyucG4ic=.4be84eb3-fba2-4954-b024-9803136f80b2@github.com>
 <MDgUlsHJ4C2McXJhDU3fYO-7zmHjwPdpItdwJaw33Os=.b0baa6d3-71da-4aa5-9526-48619f501eac@github.com>
 <9R90qVMedt6prUnfCZPBD6Q84zdGHSWyEfBvc8wqlZk=.945c2b8a-bf48-47c7-b15a-e5050ad545c7@github.com>
 <VJT9CUHJDQfFPrTFaOMjRvf_8RM-vA6OjeRMsaQFtGw=.778adb8c-e4da-4a74-b2d9-30f6d7354cd6@github.com>
Message-ID: <HaYRRJ5e3baV7Lis5zJbHC0-2-Bau-YnwmYD_qHJXZU=.c82d51f4-b5ea-420d-a377-69a350029961@github.com>

On Mon, 5 Jan 2026 07:58:24 GMT, Vic Wang <duke at openjdk.org> wrote:

> > Thanks for the update. The changes are all zx-only related, which looks fine to me.
> > Can you show us some performance number before and after this change?
> 
> The performance improvement from this change is not significant. 

If no obvious performance improvement, why change it?
Are you sure there is no performance degradation after this change?

> Additionally, I noticed that the GHA build (debug) failed due to 'No space left on device,' which is related to disk space. Does it affect the patch submission? And how to solve it?

Don't worry about this.

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

PR Comment: https://git.openjdk.org/jdk/pull/27241#issuecomment-3709535713

From roland at openjdk.org  Mon Jan  5 09:32:22 2026
From: roland at openjdk.org (Roland Westrelin)
Date: Mon, 5 Jan 2026 09:32:22 GMT
Subject: [jdk26] RFR: 8351889: C2 crash: assertion failed: Base pointers
 must match (addp 344) [v2]
In-Reply-To: <pGBYr16YEbYzSHyQTnMK1EFzWv2dLR2P19P_gzEo7Bo=.0fc3368f-4917-4145-a178-845efaeaa1bd@github.com>
References: <pGBYr16YEbYzSHyQTnMK1EFzWv2dLR2P19P_gzEo7Bo=.0fc3368f-4917-4145-a178-845efaeaa1bd@github.com>
Message-ID: <N1iGJbSKyIhTwoboAQogbwcOZ51ily8lIWkHAGyNg70=.d69a5091-8303-4e94-b534-0074d53b09e6@github.com>

> Hi all,
> 
> This pull request contains a backport of commit [ad29642d](https://github.com/openjdk/jdk/commit/ad29642d8f4e8e0fb1223b14b85ab7841d7b1b51) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Roland Westrelin on 15 Dec 2025 and was reviewed by Roberto Casta?eda Lozano and Emanuel Peter.
> 
> Thanks!

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

 - Merge branch 'jdk26' into backport-rwestrel-ad29642d-jdk26
 - Backport ad29642d8f4e8e0fb1223b14b85ab7841d7b1b51

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28893/files
  - new: https://git.openjdk.org/jdk/pull/28893/files/ff20d122..acd2913c

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

  Stats: 1087 lines in 32 files changed: 746 ins; 238 del; 103 mod
  Patch: https://git.openjdk.org/jdk/pull/28893.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28893/head:pull/28893

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

From roland at openjdk.org  Mon Jan  5 09:34:24 2026
From: roland at openjdk.org (Roland Westrelin)
Date: Mon, 5 Jan 2026 09:34:24 GMT
Subject: [jdk26] RFR: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs [v2]
In-Reply-To: <v5ojW_i9n41OjYszp5CpLQjPUxuNtV_MSGwGN_2_jLU=.4ab9554e-2ef2-4f65-8288-ad7f99f9bdfa@github.com>
References: <v5ojW_i9n41OjYszp5CpLQjPUxuNtV_MSGwGN_2_jLU=.4ab9554e-2ef2-4f65-8288-ad7f99f9bdfa@github.com>
Message-ID: <ARacr6RcrrE8Qi5h-e9mOOU6ZFj8q1Hx-TmL2HIvvjI=.d229aa93-e73f-41b2-8b9e-39127fabc9a2@github.com>

> Hi all,
> 
> This pull request contains a backport of commit [00068a80](https://github.com/openjdk/jdk/commit/00068a80304a809297d0df8698850861e9a1c5e9) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Roland Westrelin on 10 Dec 2025 and was reviewed by Christian Hagedorn, Quan Anh Mai, Galder Zamarre?o and Emanuel Peter.
> 
> Thanks!

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

 - Merge branch 'jdk26' into backport-rwestrel-00068a80-jdk26
 - Backport 00068a80304a809297d0df8698850861e9a1c5e9

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28892/files
  - new: https://git.openjdk.org/jdk/pull/28892/files/ceb2ac15..4121d277

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

  Stats: 1087 lines in 32 files changed: 746 ins; 238 del; 103 mod
  Patch: https://git.openjdk.org/jdk/pull/28892.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28892/head:pull/28892

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

From shade at openjdk.org  Mon Jan  5 09:40:20 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 5 Jan 2026 09:40:20 GMT
Subject: RFR: 8357258: x86: Improve receiver type profiling reliability
 [v10]
In-Reply-To: <ThUdNW8z1RPz_Q6nWF73g7O93F2HIMo_5MqcdXIcazQ=.f9d6c4be-f0a4-4e57-bea9-7f033ffe4281@github.com>
References: <X9RJoDWqk67MlK7P4ACCbzROxLkfEqvU0zDid3zymnc=.7c0086a3-f514-4b0d-8bc0-592bf4a05bba@github.com>
 <ThUdNW8z1RPz_Q6nWF73g7O93F2HIMo_5MqcdXIcazQ=.f9d6c4be-f0a4-4e57-bea9-7f033ffe4281@github.com>
Message-ID: <KVIlC_LdnfloIgJ8tk1XHtuS_Zxv1cLI4_e2gI3lgxg=.c8e1298c-1622-4041-b2bf-402d51fe480f@github.com>

On Mon, 5 Jan 2026 06:38:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for discussion what issues current machinery has. 
>> 
>> This PR executes the plan outlined in the bug:
>>  1. Common the receiver type profiling code in interpreter and C1
>>  2. Rewrite receiver type profiling code to only do atomic receiver slot installations
>>  3. Trim `C1OptimizeVirtualCallProfiling` to only claim slots when receiver is installed 
>> 
>> This PR does _not_ do atomic counter updates themselves, as it may have much wider performance implications, including regressions. This PR should be at least performance neutral.
>> 
>> Additional testing:
>>   - [x] Linux x86_64 server fastdebug, `compiler/`
>>   - [x] Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:
> 
>  - Merge branch 'master' into JDK-8357258-x86-c1-optimize-virt-calls
>  - Merge branch 'master' into JDK-8357258-x86-c1-optimize-virt-calls
>  - Merge branch 'master' into JDK-8357258-x86-c1-optimize-virt-calls
>  - More comments
>  - Tighten up the comments
>  - Simplify third case: no need to loop, just restart the search
>  - Actually have a second "fast" case: receiver is not found in the table, and the table is full
>  - Pushing/popping for rare CAS path is counter-productive
>  - Merge branch 'master' into JDK-8357258-x86-c1-optimize-virt-calls
>  - Tighten up some more
>  - ... and 13 more: https://git.openjdk.org/jdk/compare/6eaabed5...e4a4719f

Remerged from master, re-ran `tier1` and `hotspot_compiler` tests on Linux x86_64, all clean. There is an unrelated GHA infra failure (https://github.com/openjdk/jdk/pull/29030), which IMO does not block the integration, as at least Windows x86_64 passed in GHA, and Linux x86_64 passes locally.

Here goes.

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

PR Comment: https://git.openjdk.org/jdk/pull/25305#issuecomment-3709622490
PR Comment: https://git.openjdk.org/jdk/pull/25305#issuecomment-3709623137

From shade at openjdk.org  Mon Jan  5 09:40:23 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 5 Jan 2026 09:40:23 GMT
Subject: RFR: 8357258: x86: Improve receiver type profiling reliability
 [v8]
In-Reply-To: <cx0cFxMFR8PVPy-wLQe8relCMrhfhdIK761LWYlJEns=.210e1d3e-34d0-40ef-8de6-5247da5ece11@github.com>
References: <X9RJoDWqk67MlK7P4ACCbzROxLkfEqvU0zDid3zymnc=.7c0086a3-f514-4b0d-8bc0-592bf4a05bba@github.com>
 <avqNAcH5MpUoM31mrtm0Z6qnPqpgbpGszW01AtFbYXk=.359b8088-c0b5-4a01-aefc-fe3c02bdd60a@github.com>
 <dEG0Z-h_AKU79xlcWa3tyWqbMZSFqm9m6vEKl19JlBo=.deff71db-d617-4df9-8aa0-7242875b666c@github.com>
 <znkJzX6vqwn6MuX7YdQ6duTJ9srsVC1cjqZV0M2oYuQ=.0b1a7244-40d8-4809-b726-38af03701274@github.com>
 <cx0cFxMFR8PVPy-wLQe8relCMrhfhdIK761LWYlJEns=.210e1d3e-34d0-40ef-8de6-5247da5ece11@github.com>
Message-ID: <Bj0NpqElWMk-_NF3s9ECDx4RCMJkLSTMTgi_dR7hJSM=.00f5647e-92b4-46b8-9c57-8f2057685d62@github.com>

On Thu, 18 Dec 2025 15:23:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I'll task one of our folks to do it after NY break.

That would be: https://bugs.openjdk.org/browse/JDK-8374513

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

PR Comment: https://git.openjdk.org/jdk/pull/25305#issuecomment-3709629142

From shade at openjdk.org  Mon Jan  5 09:40:24 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 5 Jan 2026 09:40:24 GMT
Subject: Integrated: 8357258: x86: Improve receiver type profiling reliability
In-Reply-To: <X9RJoDWqk67MlK7P4ACCbzROxLkfEqvU0zDid3zymnc=.7c0086a3-f514-4b0d-8bc0-592bf4a05bba@github.com>
References: <X9RJoDWqk67MlK7P4ACCbzROxLkfEqvU0zDid3zymnc=.7c0086a3-f514-4b0d-8bc0-592bf4a05bba@github.com>
Message-ID: <Japn92xiRoiJH_4RT1szpQluV70ms0MClKmoQcqfT84=.b186f8ea-7516-4e00-a82a-82d8346dfd88@github.com>

On Mon, 19 May 2025 14:59:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for discussion what issues current machinery has. 
> 
> This PR executes the plan outlined in the bug:
>  1. Common the receiver type profiling code in interpreter and C1
>  2. Rewrite receiver type profiling code to only do atomic receiver slot installations
>  3. Trim `C1OptimizeVirtualCallProfiling` to only claim slots when receiver is installed 
> 
> This PR does _not_ do atomic counter updates themselves, as it may have much wider performance implications, including regressions. This PR should be at least performance neutral.
> 
> Additional testing:
>   - [x] Linux x86_64 server fastdebug, `compiler/`
>   - [x] Linux x86_64 server fastdebug, `all`

This pull request has now been integrated.

Changeset: e676c9de
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e676c9de3da3b820081cde1b11c0df3129787130
Stats:     418 lines in 8 files changed: 202 ins; 197 del; 19 mod

8357258: x86: Improve receiver type profiling reliability

Reviewed-by: kvn, vlivanov

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

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

From duke at openjdk.org  Mon Jan  5 10:37:57 2026
From: duke at openjdk.org (Vic Wang)
Date: Mon, 5 Jan 2026 10:37:57 GMT
Subject: RFR: 8367478: Improve UseAVX setting and add cpu descriptions for
 zhaoxin processors [v3]
In-Reply-To: <HaYRRJ5e3baV7Lis5zJbHC0-2-Bau-YnwmYD_qHJXZU=.c82d51f4-b5ea-420d-a377-69a350029961@github.com>
References: <LBWpAyFqe8AT4WYw6cSWlvouAtJQ2FnsWudpyucG4ic=.4be84eb3-fba2-4954-b024-9803136f80b2@github.com>
 <MDgUlsHJ4C2McXJhDU3fYO-7zmHjwPdpItdwJaw33Os=.b0baa6d3-71da-4aa5-9526-48619f501eac@github.com>
 <9R90qVMedt6prUnfCZPBD6Q84zdGHSWyEfBvc8wqlZk=.945c2b8a-bf48-47c7-b15a-e5050ad545c7@github.com>
 <VJT9CUHJDQfFPrTFaOMjRvf_8RM-vA6OjeRMsaQFtGw=.778adb8c-e4da-4a74-b2d9-30f6d7354cd6@github.com>
 <HaYRRJ5e3baV7Lis5zJbHC0-2-Bau-YnwmYD_qHJXZU=.c82d51f4-b5ea-420d-a377-69a350029961@github.com>
Message-ID: <S2B_WH8cNOWBKNMkV1UrBida1hmcVai8tZ6Z5OzVH48=.52bf5f90-fa9b-4806-b534-7f09161defd6@github.com>

On Mon, 5 Jan 2026 09:09:47 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> > The performance improvement from this change is not significant.
> 
> If no obvious performance improvement, why change it? Are you sure there is no performance degradation after this change?

We have tested this change using benchmarks such as SPECjvm and SPECpower. While there is no obvious performance improvement (the gain is within ~0.5%), there is also no performance degradation.

The primary goal of this patch is to improve how UseAVX is configured across different platforms and to provide a better foundation for future products. Previously, the code did not distinguish between older and newer platforms and effectively defaulted to setting UseAVX=0 for all products, which is clearly not ideal.

Therefore, we hope to improve the code logic for UseAVX. 
Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/27241#issuecomment-3709863284

From mdoerr at openjdk.org  Mon Jan  5 10:41:16 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 5 Jan 2026 10:41:16 GMT
Subject: RFR: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is
 incorrectly implemented
In-Reply-To: <SiBemHHhiHk3uDElvjRK16U2SNea7P1wsptA_4z7kxA=.0746951f-41b4-46b4-8397-40603dea6298@github.com>
References: <SiBemHHhiHk3uDElvjRK16U2SNea7P1wsptA_4z7kxA=.0746951f-41b4-46b4-8397-40603dea6298@github.com>
Message-ID: <Gj6lAeXkmB-WRpe4LzB3s9s7QRTipR9YCBNhPkaeKhE=.620b6d65-0860-4ce8-8d36-60aad720bce6@github.com>

On Sat, 29 Nov 2025 06:06:16 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> The jtreg test TestEmergencyDumpAtOOM.java runs into the following error on ppc64 platforms.
> 
> JFR emergency dump would be kicked at `VMError::report_and_die()`, then Java thread for JFR would not work due to secondary signal handler for error reporting.
> 
> Passed all of jdk_jfr tests on Linux AMD64.

Would it be a better solution to avoid replacing the signal handler? We could keep the Java compatible handler and change it such that it calls `crash_handler` only for the thread which is reporting the error.

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

PR Comment: https://git.openjdk.org/jdk/pull/28563#issuecomment-3709875107

From mgronlun at openjdk.org  Mon Jan  5 11:04:54 2026
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 5 Jan 2026 11:04:54 GMT
Subject: RFR: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is
 incorrectly implemented
In-Reply-To: <Gj6lAeXkmB-WRpe4LzB3s9s7QRTipR9YCBNhPkaeKhE=.620b6d65-0860-4ce8-8d36-60aad720bce6@github.com>
References: <SiBemHHhiHk3uDElvjRK16U2SNea7P1wsptA_4z7kxA=.0746951f-41b4-46b4-8397-40603dea6298@github.com>
 <Gj6lAeXkmB-WRpe4LzB3s9s7QRTipR9YCBNhPkaeKhE=.620b6d65-0860-4ce8-8d36-60aad720bce6@github.com>
Message-ID: <429t5MAqdyAQ7wFsxgYdUa2YPZm3GCI7SU0KwGDzcCQ=.46240518-0447-4e08-97d2-7522ebc1aacf@github.com>

On Mon, 5 Jan 2026 10:37:51 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Would it be a better solution to avoid replacing the signal handler? We could keep the Java compatible handler and change it such that it calls `crash_handler` only for the thread which is reporting the error.

I am thinking about some alternatives.

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

PR Comment: https://git.openjdk.org/jdk/pull/28563#issuecomment-3709957825

From jiefu at openjdk.org  Mon Jan  5 11:11:39 2026
From: jiefu at openjdk.org (Jie Fu)
Date: Mon, 5 Jan 2026 11:11:39 GMT
Subject: RFR: 8367478: Improve UseAVX setting and add cpu descriptions for
 zhaoxin processors [v3]
In-Reply-To: <S2B_WH8cNOWBKNMkV1UrBida1hmcVai8tZ6Z5OzVH48=.52bf5f90-fa9b-4806-b534-7f09161defd6@github.com>
References: <LBWpAyFqe8AT4WYw6cSWlvouAtJQ2FnsWudpyucG4ic=.4be84eb3-fba2-4954-b024-9803136f80b2@github.com>
 <MDgUlsHJ4C2McXJhDU3fYO-7zmHjwPdpItdwJaw33Os=.b0baa6d3-71da-4aa5-9526-48619f501eac@github.com>
 <9R90qVMedt6prUnfCZPBD6Q84zdGHSWyEfBvc8wqlZk=.945c2b8a-bf48-47c7-b15a-e5050ad545c7@github.com>
 <VJT9CUHJDQfFPrTFaOMjRvf_8RM-vA6OjeRMsaQFtGw=.778adb8c-e4da-4a74-b2d9-30f6d7354cd6@github.com>
 <HaYRRJ5e3baV7Lis5zJbHC0-2-Bau-YnwmYD_qHJXZU=.c82d51f4-b5ea-420d-a377-69a350029961@github.com>
 <S2B_WH8cNOWBKNMkV1UrBida1hmcVai8tZ6Z5OzVH48=.52bf5f90-fa9b-4806-b534-7f09161defd6@github.com>
Message-ID: <tOj84aLSX9vWNarS9LZafmAlSvhcQl-dK5Aa43q2zdE=.f7d95a7b-55ba-42d7-9e7e-efbcd49f783b@github.com>

On Mon, 5 Jan 2026 10:34:05 GMT, Vic Wang <duke at openjdk.org> wrote:

> We have tested this change using benchmarks such as SPECjvm and SPECpower. While there is no obvious performance improvement (the gain is within ~0.5%), there is also no performance degradation.

I'm still not sure if there would be performance drop since SPECjvm and SPECpower can't cover all the cases.
Let's see what others think of it.
Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/27241#issuecomment-3709979048

From roland at openjdk.org  Mon Jan  5 13:37:35 2026
From: roland at openjdk.org (Roland Westrelin)
Date: Mon, 5 Jan 2026 13:37:35 GMT
Subject: [jdk26] RFR: 8351889: C2 crash: assertion failed: Base pointers
 must match (addp 344)
In-Reply-To: <XLhdbgYHKHouX87p8rPLg0_bXZh_tp-lqUY-_-qOjcA=.1f04d078-57da-44ba-9ac0-6ecf43e7c300@github.com>
References: <pGBYr16YEbYzSHyQTnMK1EFzWv2dLR2P19P_gzEo7Bo=.0fc3368f-4917-4145-a178-845efaeaa1bd@github.com>
 <XLhdbgYHKHouX87p8rPLg0_bXZh_tp-lqUY-_-qOjcA=.1f04d078-57da-44ba-9ac0-6ecf43e7c300@github.com>
Message-ID: <8cDcqwQHocqJGtC35wq6QgWil63G6hgYLIyU4kjCf9I=.b008c63a-4687-44aa-9ce5-cd40d95bf16f@github.com>

On Thu, 18 Dec 2025 10:12:02 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [ad29642d](https://github.com/openjdk/jdk/commit/ad29642d8f4e8e0fb1223b14b85ab7841d7b1b51) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by Roland Westrelin on 15 Dec 2025 and was reviewed by Roberto Casta?eda Lozano and Emanuel Peter.
>> 
>> Thanks!
>
> Running internal tests, will come back with results.

@robcasloz thanks for testing and approval. I merge with latest. Do you need to rerun testing?

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

PR Comment: https://git.openjdk.org/jdk/pull/28893#issuecomment-3710447323

From chagedorn at openjdk.org  Mon Jan  5 14:50:30 2026
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 5 Jan 2026 14:50:30 GMT
Subject: [jdk26] RFR: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs [v2]
In-Reply-To: <ARacr6RcrrE8Qi5h-e9mOOU6ZFj8q1Hx-TmL2HIvvjI=.d229aa93-e73f-41b2-8b9e-39127fabc9a2@github.com>
References: <v5ojW_i9n41OjYszp5CpLQjPUxuNtV_MSGwGN_2_jLU=.4ab9554e-2ef2-4f65-8288-ad7f99f9bdfa@github.com>
 <ARacr6RcrrE8Qi5h-e9mOOU6ZFj8q1Hx-TmL2HIvvjI=.d229aa93-e73f-41b2-8b9e-39127fabc9a2@github.com>
Message-ID: <JTkaPQo0JHRXLSlSOxTUp_JU4ywscGLUFXryIhUAgX8=.b09d3253-5061-40f9-b402-eb120640a241@github.com>

On Mon, 5 Jan 2026 09:34:24 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [00068a80](https://github.com/openjdk/jdk/commit/00068a80304a809297d0df8698850861e9a1c5e9) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by Roland Westrelin on 10 Dec 2025 and was reviewed by Christian Hagedorn, Quan Anh Mai, Galder Zamarre?o and Emanuel Peter.
>> 
>> Thanks!
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'jdk26' into backport-rwestrel-00068a80-jdk26
>  - Backport 00068a80304a809297d0df8698850861e9a1c5e9

Looks good! I submitted some testing which passed.

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

Marked as reviewed by chagedorn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28892#pullrequestreview-3627129917

From roland at openjdk.org  Mon Jan  5 14:50:31 2026
From: roland at openjdk.org (Roland Westrelin)
Date: Mon, 5 Jan 2026 14:50:31 GMT
Subject: [jdk26] RFR: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs [v2]
In-Reply-To: <JTkaPQo0JHRXLSlSOxTUp_JU4ywscGLUFXryIhUAgX8=.b09d3253-5061-40f9-b402-eb120640a241@github.com>
References: <v5ojW_i9n41OjYszp5CpLQjPUxuNtV_MSGwGN_2_jLU=.4ab9554e-2ef2-4f65-8288-ad7f99f9bdfa@github.com>
 <ARacr6RcrrE8Qi5h-e9mOOU6ZFj8q1Hx-TmL2HIvvjI=.d229aa93-e73f-41b2-8b9e-39127fabc9a2@github.com>
 <JTkaPQo0JHRXLSlSOxTUp_JU4ywscGLUFXryIhUAgX8=.b09d3253-5061-40f9-b402-eb120640a241@github.com>
Message-ID: <c9UPFWP5aFgkA5Pjxl6M8QVSUZXhPjEcbQhXypByLT4=.a41dd5e0-b817-41e1-885a-68592bc5d665@github.com>

On Mon, 5 Jan 2026 14:42:05 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'jdk26' into backport-rwestrel-00068a80-jdk26
>>  - Backport 00068a80304a809297d0df8698850861e9a1c5e9
>
> Looks good! I submitted some testing which passed.

@chhagedorn thanks for review and testing

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

PR Comment: https://git.openjdk.org/jdk/pull/28892#issuecomment-3710731279

From roland at openjdk.org  Mon Jan  5 14:50:32 2026
From: roland at openjdk.org (Roland Westrelin)
Date: Mon, 5 Jan 2026 14:50:32 GMT
Subject: [jdk26] Integrated: 8354282: C2: more crashes in compiled code because
 of dependency on removed range check CastIIs
In-Reply-To: <v5ojW_i9n41OjYszp5CpLQjPUxuNtV_MSGwGN_2_jLU=.4ab9554e-2ef2-4f65-8288-ad7f99f9bdfa@github.com>
References: <v5ojW_i9n41OjYszp5CpLQjPUxuNtV_MSGwGN_2_jLU=.4ab9554e-2ef2-4f65-8288-ad7f99f9bdfa@github.com>
Message-ID: <dZMS5SqOJHWxBBBzSGuESRc6Ywr95SYUueiI0I0c_K0=.e27767cd-741e-40fa-a6a4-f3adcb74739c@github.com>

On Thu, 18 Dec 2025 08:30:52 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [00068a80](https://github.com/openjdk/jdk/commit/00068a80304a809297d0df8698850861e9a1c5e9) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Roland Westrelin on 10 Dec 2025 and was reviewed by Christian Hagedorn, Quan Anh Mai, Galder Zamarre?o and Emanuel Peter.
> 
> Thanks!

This pull request has now been integrated.

Changeset: d8a1c1d0
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d8a1c1d04cab940b4a6cbe82fa2e445102aa9896
Stats:     367 lines in 13 files changed: 266 ins; 27 del; 74 mod

8354282: C2: more crashes in compiled code because of dependency on removed range check CastIIs

Reviewed-by: chagedorn
Backport-of: 00068a80304a809297d0df8698850861e9a1c5e9

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

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

From mdoerr at openjdk.org  Mon Jan  5 15:13:07 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 5 Jan 2026 15:13:07 GMT
Subject: RFR: 8372754: Add wrapper for <cstdlib> [v4]
In-Reply-To: <blpDC9uwyrMnXpRAO7mZ3dXLSA0lXJ-_iVjoMfhGyd0=.1b8a1e99-4edd-488b-af34-697b7e42bc4d@github.com>
References: <7QNN5i5DkBH7c9YXWh5U40JwTKmiBPJSAcLm-f1HE_8=.9b18027e-8274-46d1-ba2d-e70514c40fc3@github.com>
 <blpDC9uwyrMnXpRAO7mZ3dXLSA0lXJ-_iVjoMfhGyd0=.1b8a1e99-4edd-488b-af34-697b7e42bc4d@github.com>
Message-ID: <54JWXhPkg9GyzvR9XnHv0H8Q1kHkkko17-JGwjKXMaM=.03b68e11-f91a-4486-b6ad-8536ebe083fb@github.com>

On Fri, 2 Jan 2026 10:21:44 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change that adds a HotSpot wrapper for <cstdlib>.  It also
>> includes the forbidden function declarations for functions declared there,
>> moving them from forbiddenFunctions.hpp and friends.
>> 
>> The AIX-specific workaround for its macro-based renaming of malloc/calloc is
>> also moved to this wrapper, so there is a single location for it. Also cleaned
>> it up a bit, based on further investigation of the problem.
>> 
>> Also changed uses of `<cstdlib>` and `<stdlib.h>` to include the wrapper instead.
>> There are still a couple of includes of `<stdlib.h>` in the hotspot directory,
>> because they can't use the hotspot wrapper: os/windows/include/jvm_md.h and
>> share/adlc/adlc.hpp.  I looked at removing the one in windows jvm_md.h, but
>> there are a lot of dependencies on that implicit include in non-HotSpot code.
>> 
>> While updating to use the wrapper, I also did a small amount of include
>> cleanup here and there.  The changes around immediate_aarch64.hpp are perhaps
>> a little less trivial than I should have made here.
>> 
>> Testing: mach5 tier1
>> 
>> This should probably be retested by aix port maintainer folks, although I
>> don't think I made any relevant changes since you last tested it.
>> 
>> This change also resolves:
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyrights

Seems like it still works with our more recent AIX version. So, it's probably good. Only the Copyright headers have a merge conflict.

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

PR Comment: https://git.openjdk.org/jdk/pull/28562#issuecomment-3710825487

From wkemper at openjdk.org  Mon Jan  5 17:03:08 2026
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 5 Jan 2026 17:03:08 GMT
Subject: RFR: 8373203: Genshen: Non-strong reference leak in old gen [v6]
In-Reply-To: <JaJt39rlIHDKUiyQmDuh0uSyVslFVLKisMXo0r2gROk=.1056f4b4-441f-4ed2-9e7f-e81cbaca272c@github.com>
References: <JaJt39rlIHDKUiyQmDuh0uSyVslFVLKisMXo0r2gROk=.1056f4b4-441f-4ed2-9e7f-e81cbaca272c@github.com>
Message-ID: <AUq56RyAikWzTyyuY39WQowTmQgmw64GwkjnkvU7DbU=.41a0c29b-86ee-41a0-8af6-bb3f236776e4@github.com>

> The generational mode for Shenandoah will collect _referents_ for the generation being collected. For example, if we have a young reference pointing to an old referent, that young reference will be processed after we finish marking the old generation. This presents a problem for discovery.
>   
> When the young mark _encounters_ a young reference with an old referent, it cannot _discover_ it because old marking hasn't finished. However, if it does not discover it, the old referent will be strongly marked. This, in turn, will prevent the old generation from clearing the referent (if it even reaches it again during old marking).
>   
> To solve this, we let young reference processing discover the old reference by having it use the old generation reference processor to do so. This means the old reference processor can have a discovered list that contains young weak references. If any of these young references reside in a region that is collected, old reference processing will crash when it processes such a reference. Therefore, we add a method `heal_discovered_lists` to traverse the discovered lists after young evacuation is complete. The method will replace any forwarded entries in the discovered list with the forwardee.
> 
> This PR also extends whitebox testing support for Shenandoah, giving us the ability to trigger young/old collections and interrogate some properties of heaps and regions.

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

 - Heal discovered lists for any young collection coincides with old marking
 - Configure thread local mark closure on delegated old reference processor

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28810/files
  - new: https://git.openjdk.org/jdk/pull/28810/files/f621b70c..d5b17d79

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

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

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

From wkemper at openjdk.org  Mon Jan  5 17:03:12 2026
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 5 Jan 2026 17:03:12 GMT
Subject: RFR: 8373203: Genshen: Non-strong reference leak in old gen [v5]
In-Reply-To: <w54mYnLXBC06G1CWUNuNiWaGe_wYb4srV4sKVf0TOy8=.fa3b7b48-480b-4699-94b9-c7356d7b271b@github.com>
References: <JaJt39rlIHDKUiyQmDuh0uSyVslFVLKisMXo0r2gROk=.1056f4b4-441f-4ed2-9e7f-e81cbaca272c@github.com>
 <w54mYnLXBC06G1CWUNuNiWaGe_wYb4srV4sKVf0TOy8=.fa3b7b48-480b-4699-94b9-c7356d7b271b@github.com>
Message-ID: <ErJ0m9Q26EGY1NlrAv16dzhtQ3OSDFxAS2t9GNntlrM=.6c18e954-5f74-4cfb-9d0d-28f2d4cc801f@github.com>

On Fri, 19 Dec 2025 19:02:13 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> The generational mode for Shenandoah will collect _referents_ for the generation being collected. For example, if we have a young reference pointing to an old referent, that young reference will be processed after we finish marking the old generation. This presents a problem for discovery.
>>   
>> When the young mark _encounters_ a young reference with an old referent, it cannot _discover_ it because old marking hasn't finished. However, if it does not discover it, the old referent will be strongly marked. This, in turn, will prevent the old generation from clearing the referent (if it even reaches it again during old marking).
>>   
>> To solve this, we let young reference processing discover the old reference by having it use the old generation reference processor to do so. This means the old reference processor can have a discovered list that contains young weak references. If any of these young references reside in a region that is collected, old reference processing will crash when it processes such a reference. Therefore, we add a method `heal_discovered_lists` to traverse the discovered lists after young evacuation is complete. The method will replace any forwarded entries in the discovered list with the forwardee.
>> 
>> This PR also extends whitebox testing support for Shenandoah, giving us the ability to trigger young/old collections and interrogate some properties of heaps and regions.
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - Merge remote-tracking branch 'jdk/master' into fix-old-reference-processing
>  - Fix idiosyncratic white space in whitebox
>    
>    Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>
>  - Sort includes
>  - Heal old discovered lists in parallel
>  - Fix comment
>  - Factor duplicate code into shared method
>  - Heal discovered oops in common place for degen and concurrent update refs
>  - Merge remote-tracking branch 'jdk/master' into fix-old-reference-processing
>  - Clear bootstrap mode for full GC that might have bypassed degenerated cycle
>  - Do not bypass card barrier when healing discovered list
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/400d8cfb...f621b70c

This change has now passed internal testing pipelines several times.

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

PR Comment: https://git.openjdk.org/jdk/pull/28810#issuecomment-3711294483

From wkemper at openjdk.org  Mon Jan  5 17:11:15 2026
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 5 Jan 2026 17:11:15 GMT
Subject: RFR: 8373203: Genshen: Non-strong reference leak in old gen [v7]
In-Reply-To: <JaJt39rlIHDKUiyQmDuh0uSyVslFVLKisMXo0r2gROk=.1056f4b4-441f-4ed2-9e7f-e81cbaca272c@github.com>
References: <JaJt39rlIHDKUiyQmDuh0uSyVslFVLKisMXo0r2gROk=.1056f4b4-441f-4ed2-9e7f-e81cbaca272c@github.com>
Message-ID: <eDFdZ4cDIAZ-dG8W_tIFriXi_oR-1q950HTjiVxwVjE=.1de70386-b789-4b12-9e75-24768341e9ab@github.com>

> The generational mode for Shenandoah will collect _referents_ for the generation being collected. For example, if we have a young reference pointing to an old referent, that young reference will be processed after we finish marking the old generation. This presents a problem for discovery.
>   
> When the young mark _encounters_ a young reference with an old referent, it cannot _discover_ it because old marking hasn't finished. However, if it does not discover it, the old referent will be strongly marked. This, in turn, will prevent the old generation from clearing the referent (if it even reaches it again during old marking).
>   
> To solve this, we let young reference processing discover the old reference by having it use the old generation reference processor to do so. This means the old reference processor can have a discovered list that contains young weak references. If any of these young references reside in a region that is collected, old reference processing will crash when it processes such a reference. Therefore, we add a method `heal_discovered_lists` to traverse the discovered lists after young evacuation is complete. The method will replace any forwarded entries in the discovered list with the forwardee.
> 
> This PR also extends whitebox testing support for Shenandoah, giving us the ability to trigger young/old collections and interrogate some properties of heaps and regions.

William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - Merge remote-tracking branch 'jdk/master' into fix-old-reference-processing
 - Heal discovered lists for any young collection coincides with old marking
 - Configure thread local mark closure on delegated old reference processor
 - Merge remote-tracking branch 'jdk/master' into fix-old-reference-processing
 - Fix idiosyncratic white space in whitebox
   
   Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>
 - Sort includes
 - Heal old discovered lists in parallel
 - Fix comment
 - Factor duplicate code into shared method
 - Heal discovered oops in common place for degen and concurrent update refs
 - ... and 12 more: https://git.openjdk.org/jdk/compare/4458cab4...ed0d0272

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

Changes: https://git.openjdk.org/jdk/pull/28810/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28810&range=06
  Stats: 669 lines in 20 files changed: 537 ins; 84 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/28810.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28810/head:pull/28810

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

From dev at jonghoonpark.com  Mon Jan  5 17:43:50 2026
From: dev at jonghoonpark.com (=?UTF-8?B?67CV7KKF7ZuI?=)
Date: Tue, 6 Jan 2026 02:43:50 +0900
Subject: 8372040: Remove Prefetch header vs inline header separation - Inquiry
 regarding contributing
Message-ID: <CALFMnY_z2f2HabBue2fLqkY68eQW_JNEPqv+t7YPCBJh0sq9Ww@mail.gmail.com>

Hello,

I would like to contribute to the issue JDK-8372040: Remove Prefetch header
vs inline header separation (https://bugs.openjdk.org/browse/JDK-8372040).

Following the suggestion in the issue description, I have implemented the
changes as follows:

1. Merged `prefetch.hpp` into `prefetch.inline.hpp`.

2. Removed the original `prefetch.hpp`.

3. Updated platform-specific `prefetch_<arch>.inline.hpp` files to include
`prefetch.inline.hpp` instead of `prefetch.hpp`.

4. Updated **`g1YoungGCPostEvacuateTasks.cpp`** to include
`prefetch.inline.hpp`, replacing its current inclusion of the now-removed
`prefetch.hpp`.

I have run the tier1 tests and no new regressions were observed.

Would it be okay to proceed with this approach?

Best regards, Jonghoon Park
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20260106/b344d336/attachment.htm>

From pchilanomate at openjdk.org  Mon Jan  5 19:21:26 2026
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 5 Jan 2026 19:21:26 GMT
Subject: RFR: 8372591: assert(!current->cont_fastpath() ||
 freeze.check_valid_fast_path()) failed
In-Reply-To: <evMtYfVg6JvfAlrQ5NdhSD4_gFM5U9Azx2ux9t9SbME=.98129440-5a57-4267-ab33-1b54562b3722@github.com>
References: <6yaYr_fSazq20-3lshGS-_Lr-LqXMt4lTeaFzDs9U2U=.c865efd1-9b98-4fce-98dd-4e1fe50a45be@github.com>
 <_LgB7c2fIE-RBo1CpmjeirR4oG6v8JBVQZ8spZzDLY8=.a67da689-d204-4550-86b6-c0efde380892@github.com>
 <kCm-ez6k9Jj2bmCrEyNZ_5FbnjsO2yx3V8MK26KO6xw=.bc3645bd-08aa-4f28-a4c1-412b2441e5ba@github.com>
 <x_K0IOvZhCD_PHDZdxXiUBCuhtuZMl8giZ6n2ZbAUnM=.f82bb705-473c-4e55-a3c1-b996a34d8831@github.com>
 <_lvm42phwda7i6vX6U6cFoaLLu07NELtWmW0pg73IVI=.83b5be81-f8a2-4364-8214-cf7638daff67@github.com>
 <evMtYfVg6JvfAlrQ5NdhSD4_gFM5U9Azx2ux9t9SbME=.98129440-5a57-4267-ab33-1b54562b3722@github.com>
Message-ID: <5lP4lrUVNtWTunMOMnkGncADv3FwM6PliTa0uJrULa0=.1fc6f40e-1509-4d54-9754-dccb822c8bfc@github.com>

On Fri, 19 Dec 2025 14:29:22 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>>> > > @reinrich @TheRealMDoerr Could you verify if this fix is correct for ppc too? Thanks.
>>> > 
>>> > 
>>> > The fix looks correct. Strangely the reproducer didn't work on ppc. Not even with 3x the locals in the osr method. I'll look a little more into it...
>>> 
>>> On ppc we reach `OSR_migration_begin` with `_cont_fastpath` that's higher than `sender.sp()` so `push_cont_fastpath(sender.sp())` has no effect. I'm not sure why this is. It might be due to the trimming with i2i calls where the sender is trimmed to a `parent frame` (the top frame always has room for max_stack). The sender is a lambda. Maybe it has done an i2c call as `top frame` (i.e. untrimmed) which set `_cont_fastpath`?
>>> 
>> Maybe, but I don't see which compiled method it could be, since methods before `foo` should be interpreted.
>> 
>>> If max_stack of the sender is very large then, due to trimming, unextended_sp < sp is possible and the assertion could also fail.
>>> 
>>> Maybe the maximum of unextended_sp and sp could be used?
>>>
>> On x64 and AArch64 we build the OSR frame starting from the sender's `unextended_sp` (modulo aligment). Is that not the case for ppc?
>
>> > If max_stack of the sender is very large then, due to trimming, unextended_sp < sp is possible and the assertion could also fail.
>> > Maybe the maximum of unextended_sp and sp could be used?
>> 
>> On x64 and AArch64 we build the OSR frame starting from the sender's `unextended_sp` (modulo aligment). Is that not the case for ppc?
> 
> *EDIT:*
> 
> Yes it is. And I get it now: the OSR frame is built starting from the sender's `unextended_sp`. It doesn't matter if it is below sender's sp. It will surely be within the valid stack (above the sp of the OSR frame).
> 
> *OLD Comment:*
> 
> It is. The difference to x86 is, that the `unextended_sp` can be (much lower) than the `sp` because `unextended_sp` has room for the maximal size of the expression stack. [This diagram](https://github.com/openjdk/jdk/blob/b5ac8f83682ddb9623a1b43bd62f309b2961a504/src/hotspot/cpu/ppc/continuationFreezeThaw_ppc.inline.hpp#L656) shows this.
> 
> Actually aarch64 seems to be similar. I think @dean-long told me once that there an interpreter frame also has room for the maximal expression stack (see [generate_fixed_frame](https://github.com/openjdk/jdk/blob/b5ac8f83682ddb9623a1b43bd62f309b2961a504/src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp#L920-L929)) and that it get's trimmed by an interpreted callee. What's done [just before calling `generate_fixed_frame`](https://github.com/openjdk/jdk/blob/b5ac8f83682ddb9623a1b43bd62f309b2961a504/src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp#L1690-L1712) looks like trimming of the caller frame.

Thanks for checking @reinrich and @RealFYang.

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

PR Comment: https://git.openjdk.org/jdk/pull/28830#issuecomment-3711758998

From pchilanomate at openjdk.org  Mon Jan  5 19:21:28 2026
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 5 Jan 2026 19:21:28 GMT
Subject: Integrated: 8372591: assert(!current->cont_fastpath() ||
 freeze.check_valid_fast_path()) failed
In-Reply-To: <6yaYr_fSazq20-3lshGS-_Lr-LqXMt4lTeaFzDs9U2U=.c865efd1-9b98-4fce-98dd-4e1fe50a45be@github.com>
References: <6yaYr_fSazq20-3lshGS-_Lr-LqXMt4lTeaFzDs9U2U=.c865efd1-9b98-4fce-98dd-4e1fe50a45be@github.com>
Message-ID: <YM0cFMDVdXIt_ioctlp0DpMzK2fb-nq86D2magXbfNY=.e9c5995f-9c8f-4f6c-8c51-0fb9d3575af3@github.com>

On Mon, 15 Dec 2025 16:53:05 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> When a frame is OSR and the caller is interpreted we call `push_cont_fastpath` to possible set `_cont_fastpath` to the `sp` of the sender. This is needed in order to keep track of interpreted frames in the stack, so that in case of unmounting we don't incorrectly execute the freeze fast path, which is only allowed when all frames are compiled.
> 
> The problem is that the OSR frame is created starting from the `unextended_sp` of the sender, not the `sp`, i.e we pop the interpreted frame like in `remove_activation`. This means that we could set a value to `_cont_fastpath` that will point outside the valid stack (below the `sp` of the OSR frame). If the gap between these stack addresses is big enough, `_cont_fastpath` could be later cleared while we still have the interpreter sender in the stack, leading to the reported crash. The simplest case where this will happen is if in a later call to yield all the extra frames leading to `Continuation.doYield` fit within this space [[1]](https://github.com/openjdk/jdk/blob/ad29642d8f4e8e0fb1223b14b85ab7841d7b1b51/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L232). It could also be cleared before that if for example at some point we returned from an interpreted callee and the sender sp it's not below `_cont_fastpath`[[2]](https://github.com/openjdk/jdk/blob/ad29642d8f4e8e0fb1223b
 14b85ab7841d7b1b51/src/hotspot/cpu/x86/interp_masm_x86.cpp#L1060).
> 
> The fix is to change `OSR_migration_begin` to set `_cont_fastpath` with the sender's `unextended_sp` instead. 
> 
> The patch includes new test `OSRWithManyLocals.java` which reliably reproduces the crash. I thought about adding it to the existing `OSRTest.java` but that was created to exercise a different issue. A better name for that test would be `OSRWithManyArgs.java`, so I could rename it in this patch if preferred (I also realized that test could be simplified and made easier to read but that's for another PR).
> 
> I tested the current patch with the new test and also run it through mach5 tiers1-7.
> 
> Thanks,
> Patricio

This pull request has now been integrated.

Changeset: 5fd095fb
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5fd095fb9b8f1d2000760519d42d7d0068b82651
Stats:     91 lines in 2 files changed: 90 ins; 0 del; 1 mod

8372591: assert(!current->cont_fastpath() || freeze.check_valid_fast_path()) failed

Reviewed-by: dholmes, alanb, rrich, fyang

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

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

From kbarrett at openjdk.org  Mon Jan  5 19:32:13 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 5 Jan 2026 19:32:13 GMT
Subject: RFR: 8372754: Add wrapper for <cstdlib> [v5]
In-Reply-To: <7QNN5i5DkBH7c9YXWh5U40JwTKmiBPJSAcLm-f1HE_8=.9b18027e-8274-46d1-ba2d-e70514c40fc3@github.com>
References: <7QNN5i5DkBH7c9YXWh5U40JwTKmiBPJSAcLm-f1HE_8=.9b18027e-8274-46d1-ba2d-e70514c40fc3@github.com>
Message-ID: <WBkCjB_bDLQZVlxLJc9iKEonJ-fM15p-4sYddrUXm2w=.b576ae8c-1984-4dd6-b432-d82a1457f6c0@github.com>

> Please review this change that adds a HotSpot wrapper for <cstdlib>.  It also
> includes the forbidden function declarations for functions declared there,
> moving them from forbiddenFunctions.hpp and friends.
> 
> The AIX-specific workaround for its macro-based renaming of malloc/calloc is
> also moved to this wrapper, so there is a single location for it. Also cleaned
> it up a bit, based on further investigation of the problem.
> 
> Also changed uses of `<cstdlib>` and `<stdlib.h>` to include the wrapper instead.
> There are still a couple of includes of `<stdlib.h>` in the hotspot directory,
> because they can't use the hotspot wrapper: os/windows/include/jvm_md.h and
> share/adlc/adlc.hpp.  I looked at removing the one in windows jvm_md.h, but
> there are a lot of dependencies on that implicit include in non-HotSpot code.
> 
> While updating to use the wrapper, I also did a small amount of include
> cleanup here and there.  The changes around immediate_aarch64.hpp are perhaps
> a little less trivial than I should have made here.
> 
> Testing: mach5 tier1
> 
> This should probably be retested by aix port maintainer folks, although I
> don't think I made any relevant changes since you last tested it.
> 
> This change also resolves:

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

 - Merge branch 'master' into wrap-cstdlib
 - update copyrights
 - Merge branch 'master' into wrap-cstdlib
 - tschatzl review
 - Merge branch 'master' into wrap-cstdlib
 - add wrapper for <cstdlib>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28562/files
  - new: https://git.openjdk.org/jdk/pull/28562/files/ced402c0..039925ee

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

  Stats: 6666 lines in 2034 files changed: 2286 ins; 922 del; 3458 mod
  Patch: https://git.openjdk.org/jdk/pull/28562.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28562/head:pull/28562

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

From kbarrett at openjdk.org  Mon Jan  5 19:41:18 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 5 Jan 2026 19:41:18 GMT
Subject: RFR: 8372754: Add wrapper for <cstdlib> [v5]
In-Reply-To: <WBkCjB_bDLQZVlxLJc9iKEonJ-fM15p-4sYddrUXm2w=.b576ae8c-1984-4dd6-b432-d82a1457f6c0@github.com>
References: <7QNN5i5DkBH7c9YXWh5U40JwTKmiBPJSAcLm-f1HE_8=.9b18027e-8274-46d1-ba2d-e70514c40fc3@github.com>
 <WBkCjB_bDLQZVlxLJc9iKEonJ-fM15p-4sYddrUXm2w=.b576ae8c-1984-4dd6-b432-d82a1457f6c0@github.com>
Message-ID: <StY5YWN0kJo3DV0lN0-aH5meKSHK4No4vqxPwFC-gGg=.c009b773-5fc7-4434-977a-ab09ee121d88@github.com>

On Mon, 5 Jan 2026 19:32:13 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change that adds a HotSpot wrapper for <cstdlib>.  It also
>> includes the forbidden function declarations for functions declared there,
>> moving them from forbiddenFunctions.hpp and friends.
>> 
>> The AIX-specific workaround for its macro-based renaming of malloc/calloc is
>> also moved to this wrapper, so there is a single location for it. Also cleaned
>> it up a bit, based on further investigation of the problem.
>> 
>> Also changed uses of `<cstdlib>` and `<stdlib.h>` to include the wrapper instead.
>> There are still a couple of includes of `<stdlib.h>` in the hotspot directory,
>> because they can't use the hotspot wrapper: os/windows/include/jvm_md.h and
>> share/adlc/adlc.hpp.  I looked at removing the one in windows jvm_md.h, but
>> there are a lot of dependencies on that implicit include in non-HotSpot code.
>> 
>> While updating to use the wrapper, I also did a small amount of include
>> cleanup here and there.  The changes around immediate_aarch64.hpp are perhaps
>> a little less trivial than I should have made here.
>> 
>> Testing: mach5 tier1
>> 
>> This should probably be retested by aix port maintainer folks, although I
>> don't think I made any relevant changes since you last tested it.
>> 
>> This change also resolves:
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into wrap-cstdlib
>  - update copyrights
>  - Merge branch 'master' into wrap-cstdlib
>  - tschatzl review
>  - Merge branch 'master' into wrap-cstdlib
>  - add wrapper for <cstdlib>

Copyright header merge conflicts have been fixed.

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

PR Comment: https://git.openjdk.org/jdk/pull/28562#issuecomment-3711834366

From duke at openjdk.org  Mon Jan  5 20:25:48 2026
From: duke at openjdk.org (Larry Cable)
Date: Mon, 5 Jan 2026 20:25:48 GMT
Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files
 loaded by a process
Message-ID: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>

modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain.

effectively:

someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm()

(where interim oops are null-checked)

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

Commit messages:
 - JDK-8327246: Add a jcmd diagnostic command to list the jar files loaded by a process

Changes: https://git.openjdk.org/jdk/pull/29048/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327246
  Stats: 49 lines in 4 files changed: 41 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/29048.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29048/head:pull/29048

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

From pchilanomate at openjdk.org  Mon Jan  5 20:35:51 2026
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 5 Jan 2026 20:35:51 GMT
Subject: [jdk26] RFR: 8372591: assert(!current->cont_fastpath() ||
 freeze.check_valid_fast_path()) failed
Message-ID: <BEvYFGKr4LlRivjcKBEaYb0o2Tq1XQchg_lc36p1GzA=.1302b3db-dc53-4ab5-867d-65cd81232e3b@github.com>

Please review the following backport of commit [5fd095fb](https://github.com/openjdk/jdk/commit/5fd095fb9b8f1d2000760519d42d7d0068b82651) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was reviewed by David Holmes, Alan Bateman, Richard Reingruber and Fei Yang.

Thanks,
Patricio

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

Commit messages:
 - Backport 5fd095fb9b8f1d2000760519d42d7d0068b82651

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

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

From sspitsyn at openjdk.org  Mon Jan  5 21:12:14 2026
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 5 Jan 2026 21:12:14 GMT
Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files
 loaded by a process
In-Reply-To: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
Message-ID: <hqsjUWQmB08DmLRruKUI08W2QAUslleucNTa_mOjbwA=.db2de627-2476-4346-ae4d-d2fe7a8479f4@github.com>

On Mon, 5 Jan 2026 20:16:37 GMT, Larry Cable <duke at openjdk.org> wrote:

> modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain.
> 
> effectively:
> 
> someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm()
> 
> (where interim oops are null-checked)

I wonder if verbose parameter should cause to print class files location. Was this option considered, and if so then why has it been rejected?

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

PR Comment: https://git.openjdk.org/jdk/pull/29048#issuecomment-3712095241

From lmesnik at openjdk.org  Mon Jan  5 22:23:39 2026
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 5 Jan 2026 22:23:39 GMT
Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files
 loaded by a process
In-Reply-To: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
Message-ID: <MsQ9qU956Mf4BXEaX4nn5GTOOdqIJHqrCE2B-G_KM2I=.b54e8568-f75d-4a78-9924-78aa6aafd597@github.com>

On Mon, 5 Jan 2026 20:16:37 GMT, Larry Cable <duke at openjdk.org> wrote:

> modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain.
> 
> effectively:
> 
> someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm()
> 
> (where interim oops are null-checked)

Changes requested by lmesnik (Reviewer).

src/hotspot/share/services/diagnosticCommand.cpp line 962:

> 960:            "S = is shared class",
> 961:            "BOOLEAN", false, "false"),
> 962:   _location("-location", "print class file location url (if available)", "BOOLEAN", false, "false") {

Not a review yet. But this new functionality deserve a regression test.

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

PR Review: https://git.openjdk.org/jdk/pull/29048#pullrequestreview-3628602391
PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2662962679

From duke at openjdk.org  Mon Jan  5 23:25:55 2026
From: duke at openjdk.org (Larry Cable)
Date: Mon, 5 Jan 2026 23:25:55 GMT
Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files
 loaded by a process
In-Reply-To: <hqsjUWQmB08DmLRruKUI08W2QAUslleucNTa_mOjbwA=.db2de627-2476-4346-ae4d-d2fe7a8479f4@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <hqsjUWQmB08DmLRruKUI08W2QAUslleucNTa_mOjbwA=.db2de627-2476-4346-ae4d-d2fe7a8479f4@github.com>
Message-ID: <zQNvDZtI3hP7JylJo5ubA6zBFg_UCx8xQxYOE4lVw-8=.bd7b1a16-5329-41b2-92b9-4cd5c3d3626a@github.com>

On Mon, 5 Jan 2026 21:09:17 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> I wonder if verbose parameter should cause to print class files location. Was this option considered, and if so then why has it been rejected?

I typically avoid modifying the behavior (and hence o/p) of existing commands; in my view a particular command (and options etc) and the resulting o/p format are part of the API "contract", hence simply modifying the -verbose option to
emit this additional field, would break the existing "contract", which in the case of a programmatic parser client would 
most likely cause failures.

IMO adding a new option preserves the existing contract while providing the additional metadata for new consumers
aware of its availability and desirous of its content.

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

PR Comment: https://git.openjdk.org/jdk/pull/29048#issuecomment-3712445113

From dholmes at openjdk.org  Mon Jan  5 23:57:53 2026
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 5 Jan 2026 23:57:53 GMT
Subject: [jdk26] RFR: 8372591: assert(!current->cont_fastpath() ||
 freeze.check_valid_fast_path()) failed
In-Reply-To: <BEvYFGKr4LlRivjcKBEaYb0o2Tq1XQchg_lc36p1GzA=.1302b3db-dc53-4ab5-867d-65cd81232e3b@github.com>
References: <BEvYFGKr4LlRivjcKBEaYb0o2Tq1XQchg_lc36p1GzA=.1302b3db-dc53-4ab5-867d-65cd81232e3b@github.com>
Message-ID: <fGlGZwfLs_2fTvZv2_phkmzneADMNNmI_QP5Wn6NLNc=.5daf25ce-a369-410e-ad8e-4490ec1e0c00@github.com>

On Mon, 5 Jan 2026 19:45:43 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review the following backport of commit [5fd095fb](https://github.com/openjdk/jdk/commit/5fd095fb9b8f1d2000760519d42d7d0068b82651) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was reviewed by David Holmes, Alan Bateman, Richard Reingruber and Fei Yang.
> 
> Thanks,
> Patricio

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29046#pullrequestreview-3628799672

From david.holmes at oracle.com  Tue Jan  6 00:08:12 2026
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 6 Jan 2026 10:08:12 +1000
Subject: 8372040: Remove Prefetch header vs inline header separation -
 Inquiry regarding contributing
In-Reply-To: <CALFMnY_z2f2HabBue2fLqkY68eQW_JNEPqv+t7YPCBJh0sq9Ww@mail.gmail.com>
References: <CALFMnY_z2f2HabBue2fLqkY68eQW_JNEPqv+t7YPCBJh0sq9Ww@mail.gmail.com>
Message-ID: <df5f0be6-05db-4d5b-a193-64e618f89fe7@oracle.com>

On 6/01/2026 3:43 am, ??? wrote:
> Hello,
> 
> I would like to contribute to the issue JDK-8372040: Remove Prefetch 
> header vs inline header separation (https://bugs.openjdk.org/browse/ 
> JDK-8372040 <https://bugs.openjdk.org/browse/JDK-8372040>).
> 
> Following the suggestion in the issue description, I have implemented 
> the changes as follows:
> 
> 1. Merged `prefetch.hpp` into `prefetch.inline.hpp`.
> 
> 2. Removed the original `prefetch.hpp`.
> 
> 3. Updated platform-specific `prefetch_<arch>.inline.hpp` files to 
> include `prefetch.inline.hpp` instead of `prefetch.hpp`.
> 
> 4. Updated **`g1YoungGCPostEvacuateTasks.cpp`** to include 
> `prefetch.inline.hpp`, replacing its current inclusion of the now- 
> removed `prefetch.hpp`.
> 
> I have run the tier1 tests and no new regressions were observed.
> 
> Would it be okay to proceed with this approach?

That sounds reasonable, but you also need to change 
./share/gc/serial/generation.hpp so that it doesn't include the 
inline.hpp file, and then adjust the serial .cpp files that actually 
need the prefetch functions.

Thanks,
David
> Best regards, Jonghoon Park


From dholmes at openjdk.org  Tue Jan  6 00:52:44 2026
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 6 Jan 2026 00:52:44 GMT
Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files
 loaded by a process
In-Reply-To: <zQNvDZtI3hP7JylJo5ubA6zBFg_UCx8xQxYOE4lVw-8=.bd7b1a16-5329-41b2-92b9-4cd5c3d3626a@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <hqsjUWQmB08DmLRruKUI08W2QAUslleucNTa_mOjbwA=.db2de627-2476-4346-ae4d-d2fe7a8479f4@github.com>
 <zQNvDZtI3hP7JylJo5ubA6zBFg_UCx8xQxYOE4lVw-8=.bd7b1a16-5329-41b2-92b9-4cd5c3d3626a@github.com>
Message-ID: <K7MGC4fh7GrKLg-xYmRfIeo5BgBoBjYHCB3SAcOLFZI=.71d80f8c-c331-419e-bfcb-acee1d19dffa@github.com>

On Mon, 5 Jan 2026 23:22:01 GMT, Larry Cable <duke at openjdk.org> wrote:

> I typically avoid modifying the behavior (and hence o/p) of existing commands; in my view a particular command (and options etc) and the resulting o/p format are part of the API "contract", 

I think our position is that the output of these commands is not a contract and can be changed - it is treated as "diagnostic output" and so not subject to CSR requests. This allows the freedom to adjust/expand the output without being forced to add a new command or option to do so.

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

PR Comment: https://git.openjdk.org/jdk/pull/29048#issuecomment-3712614167

From dholmes at openjdk.org  Tue Jan  6 01:24:07 2026
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 6 Jan 2026 01:24:07 GMT
Subject: RFR: 8367478: Improve UseAVX setting and add cpu descriptions for
 zhaoxin processors [v3]
In-Reply-To: <MDgUlsHJ4C2McXJhDU3fYO-7zmHjwPdpItdwJaw33Os=.b0baa6d3-71da-4aa5-9526-48619f501eac@github.com>
References: <LBWpAyFqe8AT4WYw6cSWlvouAtJQ2FnsWudpyucG4ic=.4be84eb3-fba2-4954-b024-9803136f80b2@github.com>
 <MDgUlsHJ4C2McXJhDU3fYO-7zmHjwPdpItdwJaw33Os=.b0baa6d3-71da-4aa5-9526-48619f501eac@github.com>
Message-ID: <-gMh5Vg1BuNhdoRbSuCwxK7d9WO_6JWkRfpx2dg8rvs=.3bdef6ac-a4ab-4487-a750-e16e7c4ae181@github.com>

On Sun, 4 Jan 2026 10:07:31 GMT, Vic Wang <duke at openjdk.org> wrote:

>> Here is the patch that improving the UseAVX setting and add cpu descriptions for zhaoxin processors.
>> Can you help to review this patch?
>> Thank you!
>
> Vic Wang 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 two new commits since the last revision:
> 
>  - Move cpu_model_id to the zx-specific if branch.
>  - Improve UseAVX setting and add cpu descriptions for zhaoxin processors.

I obviously do not know the specifics of the ZX processors, but as this only affects ZX and you represent the "owners" of ZX processors, then this change seems fine to me.

Somehow this escaped my notice last year - apologies for that.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27241#pullrequestreview-3628974731

From dholmes at openjdk.org  Tue Jan  6 01:40:21 2026
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 6 Jan 2026 01:40:21 GMT
Subject: RFR: 8374190: Convert ConcurrentHashTable atomic lists to use
 Atomic<T> [v2]
In-Reply-To: <1dWWxpfyieTZiPq-2nyC9E6RFu9o6oTbI1Fgu2Yfva4=.15f9f4a3-7b74-47b6-9912-fe9ffda63420@github.com>
References: <AF4ZUl0ny2Mzk2XrJiWpUPvv63oubznivKfrGgbyz20=.a1c8a867-1f21-4ff9-b76b-91c456a126b8@github.com>
 <hAa0LQeoZz5ewi845E8N7_Tg2eCtlclx69j6stTS8MI=.d46906a1-98ea-4575-9c7b-0c348eeac2f3@github.com>
 <1dWWxpfyieTZiPq-2nyC9E6RFu9o6oTbI1Fgu2Yfva4=.15f9f4a3-7b74-47b6-9912-fe9ffda63420@github.com>
Message-ID: <gnJsS2NWTTz_fTsHQHlcIHvGbUIzuOIMtUOLscm9ibI=.f1c2ac1d-51cd-48d4-804a-b7a91ecea865@github.com>

On Tue, 23 Dec 2025 11:14:28 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/utilities/concurrentHashTable.hpp line 178:
>> 
>>> 176:     // assignment, thus here we must cast const part away. Method is not static
>>> 177:     // due to an assert.
>>> 178:     void release_assign_node_ptr(const Atomic<Node*>* dst, Node* node) const;
>> 
>> The `const` part of the comment no longer seems relevant.
>
> The `const` is still relevant, for the reason described. It's at least
> arguable that it's kind of sketchy to do this. It certainly took me a bit of
> study to understand. Note that I moved the position of the `const` qualifier
> to its more usual location (in our code) for declaring a constant object (the
> `Atomic<Node*>` is atomic). It could instead be written as `Atomic<Node*> const*`,
> retaining the ordering from the original. Also see the implementation, where
> we need to cast away the `const` qualifier, which is now being done with
> `const_cast` rather than a C-style cast (that was also stripping off the `volatile`
> qualifier, which the use of `AtomicAccess` implicitly reapplied).

Okay. The comment would make more sense, IMO, on the implementation, rather than the declaration.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28951#discussion_r2663296696

From dholmes at openjdk.org  Tue Jan  6 01:40:17 2026
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 6 Jan 2026 01:40:17 GMT
Subject: RFR: 8374190: Convert ConcurrentHashTable atomic lists to use
 Atomic<T> [v2]
In-Reply-To: <VWZzIImhHtxN-8n3cSq-N6GfufVdymIzHqGYpr0HhFM=.623f2eaa-4307-4fa2-9676-6d6fe407c19d@github.com>
References: <AF4ZUl0ny2Mzk2XrJiWpUPvv63oubznivKfrGgbyz20=.a1c8a867-1f21-4ff9-b76b-91c456a126b8@github.com>
 <VWZzIImhHtxN-8n3cSq-N6GfufVdymIzHqGYpr0HhFM=.623f2eaa-4307-4fa2-9676-6d6fe407c19d@github.com>
Message-ID: <dwBMOzem97oIrWca9PfK-akD_tomfuRhradud4v4-zs=.dc76eb09-d0cb-4323-8381-3ba7b3c0b4ec@github.com>

On Fri, 2 Jan 2026 10:13:38 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to ConcurrentHashTable to use `Atomic<Node*>` for
>> the Node lists.  Note that this does not complete the replacement of direct
>> uses of AtomicAccess by that class; there's still one more group remaining.
>> 
>> Testing: mach5 tier1-3
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyrights

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28951#pullrequestreview-3629011964

From dholmes at openjdk.org  Tue Jan  6 02:02:16 2026
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 6 Jan 2026 02:02:16 GMT
Subject: RFR: 8374316: Update copyright year to 2025 for hotspot in files
 where it was missed [v4]
In-Reply-To: <rLRlxg59ztJPN1eGournxUICh4mvQfqQkNIdbdIhHDM=.4ffd8bb3-8cf5-49e2-af8c-c2a3b23dad7b@github.com>
References: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
 <rLRlxg59ztJPN1eGournxUICh4mvQfqQkNIdbdIhHDM=.4ffd8bb3-8cf5-49e2-af8c-c2a3b23dad7b@github.com>
Message-ID: <JnDBfpSX2boh4MregZIgWpxg8gmgpal0_p7-cmp92Ok=.53d89bd4-7f69-489b-b18b-d48ff354ecbf@github.com>

On Sun, 28 Dec 2025 03:56:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The copyright year in hotspot files updated in 2025 has been bumped to 2025. (to minimize... the patch...for now, all files modified by the commits in src/hotspot have been updated only.)
>> 
>> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
>> 
>> ~~`git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `~~
>> 
>> `git diff origin/master --name-only | while read f; do git log origin/master --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into copy_hotspot
>  - 8374316: Update copyright year to 2025 for hotspot in files where it was missed

Just be aware that if a file was created as part of a refactoring and the code was taken as-is from an existing file, then the copyright year range should have remained the same as the original file. I don't know if any of the files you modified fall into that category but just wanted to point out that looking at the commit date is not always correct.

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

PR Comment: https://git.openjdk.org/jdk/pull/28970#issuecomment-3712798915

From jiefu at openjdk.org  Tue Jan  6 02:02:10 2026
From: jiefu at openjdk.org (Jie Fu)
Date: Tue, 6 Jan 2026 02:02:10 GMT
Subject: RFR: 8367478: Improve UseAVX setting and add cpu descriptions for
 zhaoxin processors [v3]
In-Reply-To: <MDgUlsHJ4C2McXJhDU3fYO-7zmHjwPdpItdwJaw33Os=.b0baa6d3-71da-4aa5-9526-48619f501eac@github.com>
References: <LBWpAyFqe8AT4WYw6cSWlvouAtJQ2FnsWudpyucG4ic=.4be84eb3-fba2-4954-b024-9803136f80b2@github.com>
 <MDgUlsHJ4C2McXJhDU3fYO-7zmHjwPdpItdwJaw33Os=.b0baa6d3-71da-4aa5-9526-48619f501eac@github.com>
Message-ID: <T7l6JdhrJLqJmzbmJwbbsS-h0xLcBMVoBEjxoLGqfLw=.1c7dfa35-797a-47de-86eb-c65af6a2de91@github.com>

On Sun, 4 Jan 2026 10:07:31 GMT, Vic Wang <duke at openjdk.org> wrote:

>> Here is the patch that improving the UseAVX setting and add cpu descriptions for zhaoxin processors.
>> Can you help to review this patch?
>> Thank you!
>
> Vic Wang 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 two new commits since the last revision:
> 
>  - Move cpu_model_id to the zx-specific if branch.
>  - Improve UseAVX setting and add cpu descriptions for zhaoxin processors.

Marked as reviewed by jiefu (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27241#pullrequestreview-3629050403

From jiefu at openjdk.org  Tue Jan  6 02:02:12 2026
From: jiefu at openjdk.org (Jie Fu)
Date: Tue, 6 Jan 2026 02:02:12 GMT
Subject: RFR: 8367478: Improve UseAVX setting and add cpu descriptions for
 zhaoxin processors [v3]
In-Reply-To: <-gMh5Vg1BuNhdoRbSuCwxK7d9WO_6JWkRfpx2dg8rvs=.3bdef6ac-a4ab-4487-a750-e16e7c4ae181@github.com>
References: <LBWpAyFqe8AT4WYw6cSWlvouAtJQ2FnsWudpyucG4ic=.4be84eb3-fba2-4954-b024-9803136f80b2@github.com>
 <MDgUlsHJ4C2McXJhDU3fYO-7zmHjwPdpItdwJaw33Os=.b0baa6d3-71da-4aa5-9526-48619f501eac@github.com>
 <-gMh5Vg1BuNhdoRbSuCwxK7d9WO_6JWkRfpx2dg8rvs=.3bdef6ac-a4ab-4487-a750-e16e7c4ae181@github.com>
Message-ID: <uo97H1UpDBXfYI9xs0ZMqzkkBEC2Ss19FNQTwKAQ1cg=.57960669-e07c-4175-afba-0cf190a4a674@github.com>

On Tue, 6 Jan 2026 01:22:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

> as this only affects ZX and you represent the "owners" of ZX processors, then this change seems fine to me.

Agree +1

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

PR Comment: https://git.openjdk.org/jdk/pull/27241#issuecomment-3712798884

From jiefu at openjdk.org  Tue Jan  6 02:21:40 2026
From: jiefu at openjdk.org (Jie Fu)
Date: Tue, 6 Jan 2026 02:21:40 GMT
Subject: RFR: 8367478: Improve UseAVX setting and add cpu descriptions for
 zhaoxin processors [v3]
In-Reply-To: <MDgUlsHJ4C2McXJhDU3fYO-7zmHjwPdpItdwJaw33Os=.b0baa6d3-71da-4aa5-9526-48619f501eac@github.com>
References: <LBWpAyFqe8AT4WYw6cSWlvouAtJQ2FnsWudpyucG4ic=.4be84eb3-fba2-4954-b024-9803136f80b2@github.com>
 <MDgUlsHJ4C2McXJhDU3fYO-7zmHjwPdpItdwJaw33Os=.b0baa6d3-71da-4aa5-9526-48619f501eac@github.com>
Message-ID: <rxYhtrhJZIKY8WMET8okyYzfTFQilC9CQMoFg3eRb9c=.b682ce09-de9b-4b31-aee2-4bc8457fd130@github.com>

On Sun, 4 Jan 2026 10:07:31 GMT, Vic Wang <duke at openjdk.org> wrote:

>> Here is the patch that improving the UseAVX setting and add cpu descriptions for zhaoxin processors.
>> Can you help to review this patch?
>> Thank you!
>
> Vic Wang 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 two new commits since the last revision:
> 
>  - Move cpu_model_id to the zx-specific if branch.
>  - Improve UseAVX setting and add cpu descriptions for zhaoxin processors.

Please also update the copyright year to 2026.
Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/27241#issuecomment-3712840031

From dholmes at openjdk.org  Tue Jan  6 03:03:58 2026
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 6 Jan 2026 03:03:58 GMT
Subject: RFR: 8374483: Eliminate :serviceability_ttf_virtual group and mark
 svc non-virtual tests with requires
In-Reply-To: <vcJ-FiE-QJuQ7V3p2QU5hbFh48GyYEIf15yOANmSvi4=.737c9a42-5886-4839-a5e6-66e1fe1cf8f0@github.com>
References: <vcJ-FiE-QJuQ7V3p2QU5hbFh48GyYEIf15yOANmSvi4=.737c9a42-5886-4839-a5e6-66e1fe1cf8f0@github.com>
Message-ID: <p0CopD3rLt7Zsf3vrnPHGAMbniMIXXjD92oOmf13Bbw=.e18c6b50-0e64-4f04-a0ff-3f14caff8c1f@github.com>

On Sat, 3 Jan 2026 19:44:50 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Remove group :serviceability_ttf_virtual and mark only failing tests with requires.

This seems reasonable. None of the modified tests should be run on a virtual thread, even if the test itself will be testing some virtual thread functionality.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29024#pullrequestreview-3629167763

From duke at openjdk.org  Tue Jan  6 03:15:42 2026
From: duke at openjdk.org (Vic Wang)
Date: Tue, 6 Jan 2026 03:15:42 GMT
Subject: RFR: 8367478: Improve UseAVX setting and add cpu descriptions for
 zhaoxin processors [v4]
In-Reply-To: <LBWpAyFqe8AT4WYw6cSWlvouAtJQ2FnsWudpyucG4ic=.4be84eb3-fba2-4954-b024-9803136f80b2@github.com>
References: <LBWpAyFqe8AT4WYw6cSWlvouAtJQ2FnsWudpyucG4ic=.4be84eb3-fba2-4954-b024-9803136f80b2@github.com>
Message-ID: <bVqe3Qkm0Z1xwnmfXN9buOeGuiSJ4PrQ3fAWnUQRsoo=.c7045c49-c0a1-47e4-8ae6-581673535a7e@github.com>

> Here is the patch that improving the UseAVX setting and add cpu descriptions for zhaoxin processors.
> Can you help to review this patch?
> Thank you!

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

  Update copyright year to 2026 in src/hotspot/cpu/x86/vm_version_x86.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27241/files
  - new: https://git.openjdk.org/jdk/pull/27241/files/535af7ba..c169cc76

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

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

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

From duke at openjdk.org  Tue Jan  6 03:19:02 2026
From: duke at openjdk.org (Vic Wang)
Date: Tue, 6 Jan 2026 03:19:02 GMT
Subject: RFR: 8367478: Improve UseAVX setting and add cpu descriptions for
 zhaoxin processors [v3]
In-Reply-To: <rxYhtrhJZIKY8WMET8okyYzfTFQilC9CQMoFg3eRb9c=.b682ce09-de9b-4b31-aee2-4bc8457fd130@github.com>
References: <LBWpAyFqe8AT4WYw6cSWlvouAtJQ2FnsWudpyucG4ic=.4be84eb3-fba2-4954-b024-9803136f80b2@github.com>
 <MDgUlsHJ4C2McXJhDU3fYO-7zmHjwPdpItdwJaw33Os=.b0baa6d3-71da-4aa5-9526-48619f501eac@github.com>
 <rxYhtrhJZIKY8WMET8okyYzfTFQilC9CQMoFg3eRb9c=.b682ce09-de9b-4b31-aee2-4bc8457fd130@github.com>
Message-ID: <QRwzO14yjN5s-WzWhr6ozNGYZk6YfCic6k4e9jxSyn0=.1d1ab6df-a2c6-4c50-83f4-da4b4bb65fa3@github.com>

On Tue, 6 Jan 2026 02:18:47 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Please also update the copyright year to 2026. Thanks.

Done. Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/27241#issuecomment-3712946426

From jiefu at openjdk.org  Tue Jan  6 03:27:08 2026
From: jiefu at openjdk.org (Jie Fu)
Date: Tue, 6 Jan 2026 03:27:08 GMT
Subject: RFR: 8367478: Improve UseAVX setting and add cpu descriptions for
 zhaoxin processors [v4]
In-Reply-To: <bVqe3Qkm0Z1xwnmfXN9buOeGuiSJ4PrQ3fAWnUQRsoo=.c7045c49-c0a1-47e4-8ae6-581673535a7e@github.com>
References: <LBWpAyFqe8AT4WYw6cSWlvouAtJQ2FnsWudpyucG4ic=.4be84eb3-fba2-4954-b024-9803136f80b2@github.com>
 <bVqe3Qkm0Z1xwnmfXN9buOeGuiSJ4PrQ3fAWnUQRsoo=.c7045c49-c0a1-47e4-8ae6-581673535a7e@github.com>
Message-ID: <ARQlI63OuYcQcQ0mN83wJgWqfao4jrmUo-S-IhHSGvc=.1a17a657-ee07-4822-8961-0829bc1bce8a@github.com>

On Tue, 6 Jan 2026 03:15:42 GMT, Vic Wang <duke at openjdk.org> wrote:

>> Here is the patch that improving the UseAVX setting and add cpu descriptions for zhaoxin processors.
>> Can you help to review this patch?
>> Thank you!
>
> Vic Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year to 2026 in src/hotspot/cpu/x86/vm_version_x86.cpp

Marked as reviewed by jiefu (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27241#pullrequestreview-3629203443

From dholmes at openjdk.org  Tue Jan  6 07:23:23 2026
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 6 Jan 2026 07:23:23 GMT
Subject: RFR: 8374328: Convert simple AtomicAccess uses in gc/shared to use
 Atomic<T> [v2]
In-Reply-To: <eKtPNvQBTPlQk_hCJrcWWv98vVwtuQ-7s1F5CDAbcUU=.7f8592f1-8a3e-4c96-bb26-9aab7eddf9a2@github.com>
References: <RJp0KKg8demYMWOXkrVs1g_jitLhTsvce6ZFO98ihNw=.2c8e0a03-d56a-450e-91c8-019931a717b8@github.com>
 <eKtPNvQBTPlQk_hCJrcWWv98vVwtuQ-7s1F5CDAbcUU=.7f8592f1-8a3e-4c96-bb26-9aab7eddf9a2@github.com>
Message-ID: <64LeVi555L_rjZxXCXaj4wLuRVI__2ySJd6liHtIX4Q=.b83723e5-fb69-4010-b257-9efee603e0dd@github.com>

On Fri, 2 Jan 2026 10:11:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review these fairly simple changes to code in gc/shared to use
>> `Atomic<T>` instead of directly using `AtomicAccess`.
>> 
>> This change doesn't eliminate all remaining direct uses of `AtomicAccess` in
>> that directory; there are still a few uses that seem less simple, and maybe
>> some that should stay with direct `AtomicAccess`.
>> 
>> The changes are grouped into a series of commits, as a potential aid to reviewers.
>> 
>> Testing: mach5 tier1-5
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyrights

This all looks fine to me. Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28987#pullrequestreview-3629738175

From alanb at openjdk.org  Tue Jan  6 07:54:40 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 Jan 2026 07:54:40 GMT
Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files
 loaded by a process
In-Reply-To: <K7MGC4fh7GrKLg-xYmRfIeo5BgBoBjYHCB3SAcOLFZI=.71d80f8c-c331-419e-bfcb-acee1d19dffa@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <hqsjUWQmB08DmLRruKUI08W2QAUslleucNTa_mOjbwA=.db2de627-2476-4346-ae4d-d2fe7a8479f4@github.com>
 <zQNvDZtI3hP7JylJo5ubA6zBFg_UCx8xQxYOE4lVw-8=.bd7b1a16-5329-41b2-92b9-4cd5c3d3626a@github.com>
 <K7MGC4fh7GrKLg-xYmRfIeo5BgBoBjYHCB3SAcOLFZI=.71d80f8c-c331-419e-bfcb-acee1d19dffa@github.com>
Message-ID: <QCHJmyYi0RYzAbZPkhJ7FKIkS3-D-rDjKOukSRK-9_s=.d4feddb2-efef-48e6-a471-54aaaa8cd470@github.com>

On Tue, 6 Jan 2026 00:49:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I think our position is that the output of these commands is not a contract and can be changed - it is treated as "diagnostic output" and so not subject to CSR requests. This allows the freedom to adjust/expand the output without being forced to add a new command or option to do so.

In time then one could imagine options to these comments to produce structured text (probably JSON) that is intended to be parsed. We have this with Thread.dump_to_file where the output can be plain text or a JSON object.

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

PR Comment: https://git.openjdk.org/jdk/pull/29048#issuecomment-3713559830

From vyazici at openjdk.org  Tue Jan  6 08:23:16 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 6 Jan 2026 08:23:16 GMT
Subject: RFR: 8374523: [BACKOUT] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
Message-ID: <R0eSJy-eVdyNzgcTqEpW55CdubZTRdg6xK_Bmd1WQt4=.71411aaa-f14c-4b12-b594-d6e5410c0663@github.com>

Back out `java.lang.StringCoding` changes delivered in [JDK-8361842] (655dc516c22), which causes regressions reported in [JDK-8374210].

[JDK-8361842]: https://bugs.openjdk.org/browse/JDK-8361842
[JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210

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

Commit messages:
 - Revert "8361842: Move input validation checks to Java for java.lang.StringCoding intrinsics"

Changes: https://git.openjdk.org/jdk/pull/29055/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29055&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374523
  Stats: 437 lines in 23 files changed: 25 ins; 331 del; 81 mod
  Patch: https://git.openjdk.org/jdk/pull/29055.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29055/head:pull/29055

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

From vyazici at openjdk.org  Tue Jan  6 08:23:16 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 6 Jan 2026 08:23:16 GMT
Subject: RFR: 8374523: [BACKOUT] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <R0eSJy-eVdyNzgcTqEpW55CdubZTRdg6xK_Bmd1WQt4=.71411aaa-f14c-4b12-b594-d6e5410c0663@github.com>
References: <R0eSJy-eVdyNzgcTqEpW55CdubZTRdg6xK_Bmd1WQt4=.71411aaa-f14c-4b12-b594-d6e5410c0663@github.com>
Message-ID: <zk3-XGiaG5jLISqVAtPgLgvcEOT9raXjQ_UefbivPCs=.b0496830-92a7-47b8-8696-60b22a7cb106@github.com>

On Tue, 6 Jan 2026 08:16:16 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Back out `java.lang.StringCoding` changes delivered in [JDK-8361842] (655dc516c22), which causes regressions reported in [JDK-8374210].
> 
> [JDK-8361842]: https://bugs.openjdk.org/browse/JDK-8361842
> [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210

Tier 1-3 are clear on c8acc80b8c6.

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

PR Comment: https://git.openjdk.org/jdk/pull/29055#issuecomment-3713645184

From vyazici at openjdk.org  Tue Jan  6 08:40:39 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 6 Jan 2026 08:40:39 GMT
Subject: RFR: 8374523: [BACKOUT] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <R0eSJy-eVdyNzgcTqEpW55CdubZTRdg6xK_Bmd1WQt4=.71411aaa-f14c-4b12-b594-d6e5410c0663@github.com>
References: <R0eSJy-eVdyNzgcTqEpW55CdubZTRdg6xK_Bmd1WQt4=.71411aaa-f14c-4b12-b594-d6e5410c0663@github.com>
Message-ID: <KclGLl0oXVsfvxQSMeB1GuVxCqmiwInwbbxKfq5JRBo=.3944ee18-c87d-4d22-8a20-273c96799764@github.com>

On Tue, 6 Jan 2026 08:16:16 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Back out `java.lang.StringCoding` changes delivered in [JDK-8361842] (#25998 & 655dc516c22), which causes regressions reported in [JDK-8374210].
> 
> [JDK-8361842]: https://bugs.openjdk.org/browse/JDK-8361842
> [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210

Matching the labels with #25998 that this PR is reverting:

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

PR Comment: https://git.openjdk.org/jdk/pull/29055#issuecomment-3713697821

From sparasa at openjdk.org  Tue Jan  6 08:40:41 2026
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 6 Jan 2026 08:40:41 GMT
Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with
 AVX512 [v11]
In-Reply-To: <07NHyGU8bmzafUXXdLP3X81f7OZrqP6JcXZmtPh78J4=.5551605a-ade3-4190-9cf8-ae2a68857694@github.com>
References: <vR7Pzk96gG0PlTn5P5U1qlqyCvISC0dCMxUXyWHfy2g=.e58b097d-790c-4725-8ac8-7e8f2c94ac50@github.com>
 <07NHyGU8bmzafUXXdLP3X81f7OZrqP6JcXZmtPh78J4=.5551605a-ade3-4190-9cf8-ae2a68857694@github.com>
Message-ID: <AgaBCE3g6nhD0isml3KooOg6-j5dZntKBRpHTAaImrg=.1ae89527-2047-4503-9bff-29d695357234@github.com>

On Wed, 24 Dec 2025 22:06:43 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> The goal of this PR is to fix the performance regression in Arrays.fill() x86 stubs caused by masked AVX stores. The fix is to replace the masked AVX stores with store instructions without masks (i.e. unmasked stores). `fill32_masked()` and `fill64_masked()` stubs are replaced with `fill32_unmasked()` and `fill64_unmasked()` respectively.
>> 
>> To speedup unmasked stores, array fills for sizes < 64 bytes are broken down into sequences of 32B, 16B, 8B, 4B, 2B and 1B stores, depending on the size.
>> 
>> 
>> ### **Performance comparison for byte array fills in a loop for 1 million times**
>> 
>> 
>> UseAVX=3   ByteArray Size | +OptimizeFill    (Masked store   stub)     [secs] | -OptimizeFill   (No stub)   [secs] | --->This PR: +OptimizeFill   (Unmasked store   stub)   [secs]
>> -- | -- | -- | --
>> 1 | 0.46 | 0.14 | 0.189
>> 2 | 0.46 | 0.16 | 0.191
>> 3 | 0.46 | 0.176 | 0.199
>> 4 | 0.46 | 0.244 | 0.212
>> 5 | 0.46 | 0.29 | 0.364
>> 10 | 0.46 | 0.58 | 0.354
>> 15 | 0.46 | 0.42 | 0.325
>> 16 | 0.46 | 0.46 | 0.281
>> 17 | 0.21 | 0.5 | 0.365
>> 20 | 0.21 | 0.37 | 0.326
>> 25 | 0.21 | 0.59 | 0.343
>> 31 | 0.21 | 0.53 | 0.317
>> 32 | 0.21 | 0.58 | 0.249
>> 35 | 0.5 | 0.77 | 0.303
>> 40 | 0.5 | 0.61 | 0.312
>> 45 | 0.5 | 0.52 | 0.364
>> 48 | 0.5 | 0.66 | 0.283
>> 49 | 0.22 | 0.69 | 0.367
>> 50 | 0.22 | 0.78 | 0.344
>> 55 | 0.22 | 0.67 | 0.332
>> 60 | 0.22 | 0.67 | 0.312
>> 64 | 0.22 | 0.82 | 0.253
>> 70 | 0.51 | 1.1 | 0.394
>> 80 | 0.49 | 0.89 | 0.346
>> 90 | 0.225 | 0.68 | 0.385
>> 100 | 0.54 | 1.09 | 0.364
>> 110 | 0.6 | 0.98 | 0.416
>> 120 | 0.26 | 0.75 | 0.367
>> 128 | 0.266 | 1.1 | 0.342
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup code related to labels

Hi Emanuel (@eme64),

Could you please run testing on this PR?

Thanks,
Vamsi

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

PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3711664505

From epeter at openjdk.org  Tue Jan  6 08:40:41 2026
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 6 Jan 2026 08:40:41 GMT
Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with
 AVX512 [v11]
In-Reply-To: <AgaBCE3g6nhD0isml3KooOg6-j5dZntKBRpHTAaImrg=.1ae89527-2047-4503-9bff-29d695357234@github.com>
References: <vR7Pzk96gG0PlTn5P5U1qlqyCvISC0dCMxUXyWHfy2g=.e58b097d-790c-4725-8ac8-7e8f2c94ac50@github.com>
 <07NHyGU8bmzafUXXdLP3X81f7OZrqP6JcXZmtPh78J4=.5551605a-ade3-4190-9cf8-ae2a68857694@github.com>
 <AgaBCE3g6nhD0isml3KooOg6-j5dZntKBRpHTAaImrg=.1ae89527-2047-4503-9bff-29d695357234@github.com>
Message-ID: <4DbVeS6SQL4D3AJD1xTxGr3DI9B6XMxOS4r30vDXhCk=.8890e33c-df2e-451d-9dae-1d858b5f06f4@github.com>

On Mon, 5 Jan 2026 18:45:03 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cleanup code related to labels
>
> Hi Emanuel (@eme64),
> 
> Could you please run testing on this PR?
> 
> Thanks,
> Vamsi

@vamsi-parasa Thanks for the ping!
First I have a question: in the pr description, I can see cases with improvements and regressions (e.g. for 120 and 128). Can you explain a bit more, and maybe add an additional column that gives us a speedup number?

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

PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3713704743

From epeter at openjdk.org  Tue Jan  6 08:51:44 2026
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 6 Jan 2026 08:51:44 GMT
Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with
 AVX512 [v11]
In-Reply-To: <07NHyGU8bmzafUXXdLP3X81f7OZrqP6JcXZmtPh78J4=.5551605a-ade3-4190-9cf8-ae2a68857694@github.com>
References: <vR7Pzk96gG0PlTn5P5U1qlqyCvISC0dCMxUXyWHfy2g=.e58b097d-790c-4725-8ac8-7e8f2c94ac50@github.com>
 <07NHyGU8bmzafUXXdLP3X81f7OZrqP6JcXZmtPh78J4=.5551605a-ade3-4190-9cf8-ae2a68857694@github.com>
Message-ID: <cdl_Uh4tO5DqvGtok2FqpNz29emqkAarYgbF-Eh4Gaw=.83ec5131-3918-4375-8198-8881232ee5d5@github.com>

On Wed, 24 Dec 2025 22:06:43 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> The goal of this PR is to fix the performance regression in Arrays.fill() x86 stubs caused by masked AVX stores. The fix is to replace the masked AVX stores with store instructions without masks (i.e. unmasked stores). `fill32_masked()` and `fill64_masked()` stubs are replaced with `fill32_unmasked()` and `fill64_unmasked()` respectively.
>> 
>> To speedup unmasked stores, array fills for sizes < 64 bytes are broken down into sequences of 32B, 16B, 8B, 4B, 2B and 1B stores, depending on the size.
>> 
>> 
>> ### **Performance comparison for byte array fills in a loop for 1 million times**
>> 
>> 
>> UseAVX=3   ByteArray Size | +OptimizeFill    (Masked store   stub)     [secs] | -OptimizeFill   (No stub)   [secs] | --->This PR: +OptimizeFill   (Unmasked store   stub)   [secs]
>> -- | -- | -- | --
>> 1 | 0.46 | 0.14 | 0.189
>> 2 | 0.46 | 0.16 | 0.191
>> 3 | 0.46 | 0.176 | 0.199
>> 4 | 0.46 | 0.244 | 0.212
>> 5 | 0.46 | 0.29 | 0.364
>> 10 | 0.46 | 0.58 | 0.354
>> 15 | 0.46 | 0.42 | 0.325
>> 16 | 0.46 | 0.46 | 0.281
>> 17 | 0.21 | 0.5 | 0.365
>> 20 | 0.21 | 0.37 | 0.326
>> 25 | 0.21 | 0.59 | 0.343
>> 31 | 0.21 | 0.53 | 0.317
>> 32 | 0.21 | 0.58 | 0.249
>> 35 | 0.5 | 0.77 | 0.303
>> 40 | 0.5 | 0.61 | 0.312
>> 45 | 0.5 | 0.52 | 0.364
>> 48 | 0.5 | 0.66 | 0.283
>> 49 | 0.22 | 0.69 | 0.367
>> 50 | 0.22 | 0.78 | 0.344
>> 55 | 0.22 | 0.67 | 0.332
>> 60 | 0.22 | 0.67 | 0.312
>> 64 | 0.22 | 0.82 | 0.253
>> 70 | 0.51 | 1.1 | 0.394
>> 80 | 0.49 | 0.89 | 0.346
>> 90 | 0.225 | 0.68 | 0.385
>> 100 | 0.54 | 1.09 | 0.364
>> 110 | 0.6 | 0.98 | 0.416
>> 120 | 0.26 | 0.75 | 0.367
>> 128 | 0.266 | 1.1 | 0.342
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup code related to labels

Also:
- You only show data for byte arrays, right? What about other element types?
- Do you control for alignment of the array, i.e. what if the intrinsic does not start at the beginning of the array but at some arbitrary offset?
- It would be nice to see a plot for all sizes from 0-300, and maybe some select larger sizes. That would give us a clearer picture of the behavior of your intrinsics.

You could also use some selected benchmarks from my recent PR https://github.com/openjdk/jdk/pull/27315. You could use the series `fill_var_*_arrays_fill`, and compare before and after your PR.

And since this is a regression ... why not also plot the performance from before [JDK-8275047](https://bugs.openjdk.org/browse/JDK-8275047), so we have a more complete picture?

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

PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3713732680
PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3713739854

From shade at openjdk.org  Tue Jan  6 09:14:15 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 6 Jan 2026 09:14:15 GMT
Subject: RFR: 8374523: [BACKOUT] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <R0eSJy-eVdyNzgcTqEpW55CdubZTRdg6xK_Bmd1WQt4=.71411aaa-f14c-4b12-b594-d6e5410c0663@github.com>
References: <R0eSJy-eVdyNzgcTqEpW55CdubZTRdg6xK_Bmd1WQt4=.71411aaa-f14c-4b12-b594-d6e5410c0663@github.com>
Message-ID: <ZBdV01_la8inqiZ23brD_4AY0Vurs8HOdZ3vDvYEBgU=.e53e433f-fc4b-492b-bfa9-05d3fe6e141e@github.com>

On Tue, 6 Jan 2026 08:16:16 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Back out `java.lang.StringCoding` changes delivered in [JDK-8361842] (#25998 & 655dc516c22), which causes regressions reported in [JDK-8374210].
> 
> [JDK-8361842]: https://bugs.openjdk.org/browse/JDK-8361842
> [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210

This does not look like a clean backout -- the incoming/outgoing line counts do not match against the original commit -- so extra caution is needed in reviews.

Apart from the inadverent (?) addition in `JavaLangAccess.java`, there seem to be hunk differences in some `sun/nio/cs` files; I assume those are intentional?

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 455:

> 453:      * compatible.
> 454:      * <p>
> 455:      * <b>WARNING: This method does not perform any bound checks.</b>

These two lines are not in the original commit?

https://github.com/openjdk/jdk/commit/655dc516c22ac84fccee6b1fdc607c492465be6b#diff-bd92d760986b9249dd3c02cc147db4f7e9dbbef90afef4971ee497a50e48c740

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

PR Review: https://git.openjdk.org/jdk/pull/29055#pullrequestreview-3630055594
PR Review Comment: https://git.openjdk.org/jdk/pull/29055#discussion_r2664196789

From vyazici at openjdk.org  Tue Jan  6 09:59:56 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 6 Jan 2026 09:59:56 GMT
Subject: RFR: 8374523: [BACKOUT] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <ZBdV01_la8inqiZ23brD_4AY0Vurs8HOdZ3vDvYEBgU=.e53e433f-fc4b-492b-bfa9-05d3fe6e141e@github.com>
References: <R0eSJy-eVdyNzgcTqEpW55CdubZTRdg6xK_Bmd1WQt4=.71411aaa-f14c-4b12-b594-d6e5410c0663@github.com>
 <ZBdV01_la8inqiZ23brD_4AY0Vurs8HOdZ3vDvYEBgU=.e53e433f-fc4b-492b-bfa9-05d3fe6e141e@github.com>
Message-ID: <XimqVfkqsfef9BIJvkEWmUPDMMw8kzMAYrWarKRzugU=.aa6212de-b2f5-4bd5-bcef-f6cfd5780b57@github.com>

On Tue, 6 Jan 2026 09:06:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Back out `java.lang.StringCoding` changes delivered in [JDK-8361842] (#25998 & 655dc516c22), which causes regressions reported in [JDK-8374210].
>> 
>> [JDK-8361842]: https://bugs.openjdk.org/browse/JDK-8361842
>> [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210
>
> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 455:
> 
>> 453:      * compatible.
>> 454:      * <p>
>> 455:      * <b>WARNING: This method does not perform any bound checks.</b>
> 
> These two lines are not in the original commit?
> 
> https://github.com/openjdk/jdk/commit/655dc516c22ac84fccee6b1fdc607c492465be6b#diff-bd92d760986b9249dd3c02cc147db4f7e9dbbef90afef4971ee497a50e48c740

In chronological order:

1. 8fcfddb2d202 renamed `encodeASCII` to `uncheckedEncodeASCII` and added the `WARNING` clause.
2. 655dc516c22a, the commit this PR is reverting, renamed the method back to `encodeASCII` and removed the `WARNING`. This was possible, since `StringCoding::implEncodeAsciiArray` was hardened with necessary checks in the very same commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29055#discussion_r2664348820

From vyazici at openjdk.org  Tue Jan  6 10:10:59 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 6 Jan 2026 10:10:59 GMT
Subject: RFR: 8374523: [BACKOUT] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <ZBdV01_la8inqiZ23brD_4AY0Vurs8HOdZ3vDvYEBgU=.e53e433f-fc4b-492b-bfa9-05d3fe6e141e@github.com>
References: <R0eSJy-eVdyNzgcTqEpW55CdubZTRdg6xK_Bmd1WQt4=.71411aaa-f14c-4b12-b594-d6e5410c0663@github.com>
 <ZBdV01_la8inqiZ23brD_4AY0Vurs8HOdZ3vDvYEBgU=.e53e433f-fc4b-492b-bfa9-05d3fe6e141e@github.com>
Message-ID: <EjSmaZaE7CUvftBXWNeHT2F9FLrHKXQnO4C82RBhVbE=.8c212e9a-265c-4b4a-bd28-5c68b2aac1c9@github.com>

On Tue, 6 Jan 2026 09:10:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> there seem to be hunk differences in some `sun/nio/cs` files; I assume those are intentional?

Yes, they are clean reverts of the associated files changed in 655dc516c22a.

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

PR Comment: https://git.openjdk.org/jdk/pull/29055#issuecomment-3714049430

From kevinw at openjdk.org  Tue Jan  6 10:54:38 2026
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 6 Jan 2026 10:54:38 GMT
Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files
 loaded by a process
In-Reply-To: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
Message-ID: <WwyPYNitCJzQu-VrRTkJWJ3viKIUzwIAG6ePs3o_GwQ=.324764af-f05f-440f-ac8b-4dd2212dfde2@github.com>

On Mon, 5 Jan 2026 20:16:37 GMT, Larry Cable <duke at openjdk.org> wrote:

> modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain.
> 
> effectively:
> 
> someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm()
> 
> (where interim oops are null-checked)

src/hotspot/share/services/diagnosticCommand.cpp line 962:

> 960:            "S = is shared class",
> 961:            "BOOLEAN", false, "false"),
> 962:   _location("-location", "print class file location url (if available)", "BOOLEAN", false, "false") {

Nit: "Print class.." the option descriptions all begin with capital letters.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2664517932

From shade at openjdk.org  Tue Jan  6 10:55:36 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 6 Jan 2026 10:55:36 GMT
Subject: RFR: 8374210: [BACKOUT] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <R0eSJy-eVdyNzgcTqEpW55CdubZTRdg6xK_Bmd1WQt4=.71411aaa-f14c-4b12-b594-d6e5410c0663@github.com>
References: <R0eSJy-eVdyNzgcTqEpW55CdubZTRdg6xK_Bmd1WQt4=.71411aaa-f14c-4b12-b594-d6e5410c0663@github.com>
Message-ID: <aHrgXZUXvyccgKGxOZDadcnF1PyjqZKl4Nv5IambiiU=.a5f40958-5b7c-4127-8c0d-04ec84083dec@github.com>

On Tue, 6 Jan 2026 08:16:16 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Back out `java.lang.StringCoding` changes delivered in [JDK-8361842] (#25998 & 655dc516c22), which causes regressions reported in [JDK-8374210].
> 
> [JDK-8361842]: https://bugs.openjdk.org/browse/JDK-8361842
> [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29055#pullrequestreview-3630455590

From thartmann at openjdk.org  Tue Jan  6 10:55:36 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 6 Jan 2026 10:55:36 GMT
Subject: RFR: 8374210: [BACKOUT] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <R0eSJy-eVdyNzgcTqEpW55CdubZTRdg6xK_Bmd1WQt4=.71411aaa-f14c-4b12-b594-d6e5410c0663@github.com>
References: <R0eSJy-eVdyNzgcTqEpW55CdubZTRdg6xK_Bmd1WQt4=.71411aaa-f14c-4b12-b594-d6e5410c0663@github.com>
Message-ID: <s9ZJBBPGEpb1gS1KXWwqdkWjj2xkWEuNhqXDe87mRUI=.5910ff3a-31b9-4f7a-878d-1453c987f957@github.com>

On Tue, 6 Jan 2026 08:16:16 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Back out `java.lang.StringCoding` changes delivered in [JDK-8361842] (#25998 & 655dc516c22), which causes regressions reported in [JDK-8374210].
> 
> [JDK-8361842]: https://bugs.openjdk.org/browse/JDK-8361842
> [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210

Looks good to me.

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29055#pullrequestreview-3630459848

From shade at openjdk.org  Tue Jan  6 10:55:38 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 6 Jan 2026 10:55:38 GMT
Subject: RFR: 8374210: [BACKOUT] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <XimqVfkqsfef9BIJvkEWmUPDMMw8kzMAYrWarKRzugU=.aa6212de-b2f5-4bd5-bcef-f6cfd5780b57@github.com>
References: <R0eSJy-eVdyNzgcTqEpW55CdubZTRdg6xK_Bmd1WQt4=.71411aaa-f14c-4b12-b594-d6e5410c0663@github.com>
 <ZBdV01_la8inqiZ23brD_4AY0Vurs8HOdZ3vDvYEBgU=.e53e433f-fc4b-492b-bfa9-05d3fe6e141e@github.com>
 <XimqVfkqsfef9BIJvkEWmUPDMMw8kzMAYrWarKRzugU=.aa6212de-b2f5-4bd5-bcef-f6cfd5780b57@github.com>
Message-ID: <I6WP3e3ZzRly6zwjat0FJJTRAexiVosD8spKN5581j8=.93e9471d-d862-4b60-bbc8-ba3acb40e376@github.com>

On Tue, 6 Jan 2026 09:57:02 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 455:
>> 
>>> 453:      * compatible.
>>> 454:      * <p>
>>> 455:      * <b>WARNING: This method does not perform any bound checks.</b>
>> 
>> These two lines are not in the original commit?
>> 
>> https://github.com/openjdk/jdk/commit/655dc516c22ac84fccee6b1fdc607c492465be6b#diff-bd92d760986b9249dd3c02cc147db4f7e9dbbef90afef4971ee497a50e48c740
>
> In chronological order:
> 
> 1. 8fcfddb2d202 renamed `encodeASCII` to `uncheckedEncodeASCII` and added the `WARNING` clause.
> 2. 655dc516c22a, the commit this PR is reverting, renamed the method back to `encodeASCII` and removed the `WARNING`. This was possible, since `StringCoding::implEncodeAsciiArray` was hardened with necessary checks in the very same commit.

Ah yes, I misread, apologies.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29055#discussion_r2664514651

From kevinw at openjdk.org  Tue Jan  6 11:53:53 2026
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 6 Jan 2026 11:53:53 GMT
Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files
 loaded by a process
In-Reply-To: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
Message-ID: <Kq3nQggB7Q5rVmlcJ49s3tXuAFDpa7AJnxIbXrHSmV4=.22eb6bab-94c5-4c66-b474-9b3418ecb468@github.com>

On Mon, 5 Jan 2026 20:16:37 GMT, Larry Cable <duke at openjdk.org> wrote:

> modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain.
> 
> effectively:
> 
> someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm()
> 
> (where interim oops are null-checked)

"VM.classes -verbose" is _very_ verbose already, so a separate option looks like the right choice to me.  More lightweight queries for just this info.

$ build/linux-x64/images/jdk/bin/jcmd 741576 VM.classes | wc -l
544
$ build/linux-x64/images/jdk/bin/jcmd 741576 VM.classes -verbose | wc -l
18209
(on a trivial test app)

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

PR Comment: https://git.openjdk.org/jdk/pull/29048#issuecomment-3714418866

From iwalulya at openjdk.org  Tue Jan  6 13:43:51 2026
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 6 Jan 2026 13:43:51 GMT
Subject: RFR: 8374350: Convert hotspot gtests to use Atomic<T> [v2]
In-Reply-To: <SYmHDwrLJYMBJgHLgrpZ5BFy_MpDOPNopMwzjD5_KrY=.11a6992a-1d6c-42d1-86af-b0b0ca444999@github.com>
References: <BxRBFQ-RXjXDRiF75q_IepNnhurF97pwc2r_YquJx1U=.485cb8de-9395-41e3-a97e-457da24385dd@github.com>
 <SYmHDwrLJYMBJgHLgrpZ5BFy_MpDOPNopMwzjD5_KrY=.11a6992a-1d6c-42d1-86af-b0b0ca444999@github.com>
Message-ID: <zVwGQIGnhWh_MaH-O6clK0xnaWAhNlCtSPYOPxYuee0=.5d3a1462-2197-480e-895b-f4db4513dca4@github.com>

On Fri, 2 Jan 2026 10:08:26 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to convert HotSpot gtests to use Atomic<T> rather
>> than directly using AtomicAccess.
>> 
>> test_atomicAccess.cpp is, of course, not subject to this conversion.
>> 
>> test_globalCounter.cpp is also not included in this conversion.  The other
>> conversions were straight forward.  This test is less so, and I decided I
>> needed to spend more time studying it, so have left it for followup work.
>> 
>> The conversion of each test is a separate commit, in case that makes it easier
>> to review.
>> 
>> Testing: mach5 tier1
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyrights

Looks good!

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

Marked as reviewed by iwalulya (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29001#pullrequestreview-3630942129

From kbarrett at openjdk.org  Tue Jan  6 15:00:59 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 6 Jan 2026 15:00:59 GMT
Subject: RFR: 8374350: Convert hotspot gtests to use Atomic<T> [v2]
In-Reply-To: <xp1GeD9sxlxv6tGdGdsvlvALexd61xOtyJ9eyiuylio=.6f5ebd2a-fe81-4785-ae70-6f79e82fa4d3@github.com>
References: <BxRBFQ-RXjXDRiF75q_IepNnhurF97pwc2r_YquJx1U=.485cb8de-9395-41e3-a97e-457da24385dd@github.com>
 <SYmHDwrLJYMBJgHLgrpZ5BFy_MpDOPNopMwzjD5_KrY=.11a6992a-1d6c-42d1-86af-b0b0ca444999@github.com>
 <xp1GeD9sxlxv6tGdGdsvlvALexd61xOtyJ9eyiuylio=.6f5ebd2a-fe81-4785-ae70-6f79e82fa4d3@github.com>
Message-ID: <haI0KkrCpJ8ja_0ZNFNY3AsM_2c3lt-8mUb3Bo44Ucc=.5b3090d5-0caa-4883-b9f6-1ac32106c136@github.com>

On Fri, 2 Jan 2026 10:28:13 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update copyrights
>
> lgtm.
> 
> ~~Just wondering if we should use `GrowableArray` instead of NEW/FREE macros and the placement new operator. Or would you rather have such a change as a separate RFE?~~

Thanks for reviews @xmas92 and @walulyai

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

PR Comment: https://git.openjdk.org/jdk/pull/29001#issuecomment-3715023725

From kbarrett at openjdk.org  Tue Jan  6 15:05:19 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 6 Jan 2026 15:05:19 GMT
Subject: Integrated: 8374350: Convert hotspot gtests to use Atomic<T>
In-Reply-To: <BxRBFQ-RXjXDRiF75q_IepNnhurF97pwc2r_YquJx1U=.485cb8de-9395-41e3-a97e-457da24385dd@github.com>
References: <BxRBFQ-RXjXDRiF75q_IepNnhurF97pwc2r_YquJx1U=.485cb8de-9395-41e3-a97e-457da24385dd@github.com>
Message-ID: <OLCbuIKJNTgbkRSoJ1wy966OBG_Tr0stDFiCUk_PIuk=.7facc5e5-f9e8-4911-ba7c-f500b876cc13@github.com>

On Sat, 27 Dec 2025 05:20:52 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to convert HotSpot gtests to use Atomic<T> rather
> than directly using AtomicAccess.
> 
> test_atomicAccess.cpp is, of course, not subject to this conversion.
> 
> test_globalCounter.cpp is also not included in this conversion.  The other
> conversions were straight forward.  This test is less so, and I decided I
> needed to spend more time studying it, so have left it for followup work.
> 
> The conversion of each test is a separate commit, in case that makes it easier
> to review.
> 
> Testing: mach5 tier1

This pull request has now been integrated.

Changeset: e27309f1
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e27309f10d32695972f468df17b2535d36a746a2
Stats:     113 lines in 9 files changed: 6 ins; 0 del; 107 mod

8374350: Convert hotspot gtests to use Atomic<T>

Reviewed-by: aboldtch, iwalulya

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

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

From iwalulya at openjdk.org  Tue Jan  6 15:16:42 2026
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 6 Jan 2026 15:16:42 GMT
Subject: RFR: 8374190: Convert ConcurrentHashTable atomic lists to use
 Atomic<T> [v2]
In-Reply-To: <VWZzIImhHtxN-8n3cSq-N6GfufVdymIzHqGYpr0HhFM=.623f2eaa-4307-4fa2-9676-6d6fe407c19d@github.com>
References: <AF4ZUl0ny2Mzk2XrJiWpUPvv63oubznivKfrGgbyz20=.a1c8a867-1f21-4ff9-b76b-91c456a126b8@github.com>
 <VWZzIImhHtxN-8n3cSq-N6GfufVdymIzHqGYpr0HhFM=.623f2eaa-4307-4fa2-9676-6d6fe407c19d@github.com>
Message-ID: <gxWK6D_JFsDUSzVBvUxQAiPLf0kR8G2Z6TiO8q5eDFg=.95154b6c-7555-493f-adeb-b7c9930d28f2@github.com>

On Fri, 2 Jan 2026 10:13:38 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to ConcurrentHashTable to use `Atomic<Node*>` for
>> the Node lists.  Note that this does not complete the replacement of direct
>> uses of AtomicAccess by that class; there's still one more group remaining.
>> 
>> Testing: mach5 tier1-3
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyrights

Marked as reviewed by iwalulya (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28951#pullrequestreview-3631289438

From pchilanomate at openjdk.org  Tue Jan  6 15:22:31 2026
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 6 Jan 2026 15:22:31 GMT
Subject: [jdk26] RFR: 8372591: assert(!current->cont_fastpath() ||
 freeze.check_valid_fast_path()) failed
In-Reply-To: <BEvYFGKr4LlRivjcKBEaYb0o2Tq1XQchg_lc36p1GzA=.1302b3db-dc53-4ab5-867d-65cd81232e3b@github.com>
References: <BEvYFGKr4LlRivjcKBEaYb0o2Tq1XQchg_lc36p1GzA=.1302b3db-dc53-4ab5-867d-65cd81232e3b@github.com>
Message-ID: <sg9DfV5u9xgHFK7OCfQdacp12oWecBe_iBLzQW_W_dk=.11c1eabc-5477-42fc-ae7d-b34670264271@github.com>

On Mon, 5 Jan 2026 19:45:43 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review the following backport of commit [5fd095fb](https://github.com/openjdk/jdk/commit/5fd095fb9b8f1d2000760519d42d7d0068b82651) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was reviewed by David Holmes, Alan Bateman, Richard Reingruber and Fei Yang.
> 
> Thanks,
> Patricio

Thanks for the review David!

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

PR Comment: https://git.openjdk.org/jdk/pull/29046#issuecomment-3715103148

From pchilanomate at openjdk.org  Tue Jan  6 15:24:42 2026
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 6 Jan 2026 15:24:42 GMT
Subject: [jdk26] Integrated: 8372591: assert(!current->cont_fastpath() ||
 freeze.check_valid_fast_path()) failed
In-Reply-To: <BEvYFGKr4LlRivjcKBEaYb0o2Tq1XQchg_lc36p1GzA=.1302b3db-dc53-4ab5-867d-65cd81232e3b@github.com>
References: <BEvYFGKr4LlRivjcKBEaYb0o2Tq1XQchg_lc36p1GzA=.1302b3db-dc53-4ab5-867d-65cd81232e3b@github.com>
Message-ID: <2ToH1aLLq0wKOUNeWuk1bLQgW8uoXIkLP8LADafqBOk=.d601112e-2ae7-4bc3-a0b4-8f24efaf126b@github.com>

On Mon, 5 Jan 2026 19:45:43 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review the following backport of commit [5fd095fb](https://github.com/openjdk/jdk/commit/5fd095fb9b8f1d2000760519d42d7d0068b82651) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was reviewed by David Holmes, Alan Bateman, Richard Reingruber and Fei Yang.
> 
> Thanks,
> Patricio

This pull request has now been integrated.

Changeset: 46025e45
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/46025e45c01bca7bd1791c041d561ee69243bb18
Stats:     91 lines in 2 files changed: 90 ins; 0 del; 1 mod

8372591: assert(!current->cont_fastpath() || freeze.check_valid_fast_path()) failed

Reviewed-by: dholmes
Backport-of: 5fd095fb9b8f1d2000760519d42d7d0068b82651

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

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

From lmesnik at openjdk.org  Tue Jan  6 15:53:23 2026
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 6 Jan 2026 15:53:23 GMT
Subject: Integrated: 8374483: Eliminate :serviceability_ttf_virtual group and
 mark svc non-virtual tests with requires
In-Reply-To: <vcJ-FiE-QJuQ7V3p2QU5hbFh48GyYEIf15yOANmSvi4=.737c9a42-5886-4839-a5e6-66e1fe1cf8f0@github.com>
References: <vcJ-FiE-QJuQ7V3p2QU5hbFh48GyYEIf15yOANmSvi4=.737c9a42-5886-4839-a5e6-66e1fe1cf8f0@github.com>
Message-ID: <lV9DEcbBBZUpkEXYG7HFScuhBw3YlPwfP7AOeVFTHE4=.57008309-acee-4107-8215-d69045b866e3@github.com>

On Sat, 3 Jan 2026 19:44:50 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Remove group :serviceability_ttf_virtual and mark only failing tests with requires.

This pull request has now been integrated.

Changeset: c611da25
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c611da257f69e9c9b178b85cb705a4b0a42545ac
Stats:     52 lines in 19 files changed: 26 ins; 7 del; 19 mod

8374483: Eliminate :serviceability_ttf_virtual group and mark svc non-virtual tests with requires

Reviewed-by: syan, dholmes

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

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

From kbarrett at openjdk.org  Tue Jan  6 17:11:56 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 6 Jan 2026 17:11:56 GMT
Subject: RFR: 8374190: Convert ConcurrentHashTable atomic lists to use
 Atomic<T> [v2]
In-Reply-To: <dwBMOzem97oIrWca9PfK-akD_tomfuRhradud4v4-zs=.dc76eb09-d0cb-4323-8381-3ba7b3c0b4ec@github.com>
References: <AF4ZUl0ny2Mzk2XrJiWpUPvv63oubznivKfrGgbyz20=.a1c8a867-1f21-4ff9-b76b-91c456a126b8@github.com>
 <VWZzIImhHtxN-8n3cSq-N6GfufVdymIzHqGYpr0HhFM=.623f2eaa-4307-4fa2-9676-6d6fe407c19d@github.com>
 <dwBMOzem97oIrWca9PfK-akD_tomfuRhradud4v4-zs=.dc76eb09-d0cb-4323-8381-3ba7b3c0b4ec@github.com>
Message-ID: <w-Xm8yberWSWmAxeEs3ZOroEbjcLj0m4caxrI2J12sU=.6801d5dd-5a35-43b4-84c9-f81468d7ca3b@github.com>

On Tue, 6 Jan 2026 01:36:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update copyrights
>
> Marked as reviewed by dholmes (Reviewer).

Thanks for reviews @dholmes-ora and @walulyai

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

PR Comment: https://git.openjdk.org/jdk/pull/28951#issuecomment-3715536125

From kbarrett at openjdk.org  Tue Jan  6 17:11:58 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 6 Jan 2026 17:11:58 GMT
Subject: RFR: 8374190: Convert ConcurrentHashTable atomic lists to use
 Atomic<T> [v2]
In-Reply-To: <gnJsS2NWTTz_fTsHQHlcIHvGbUIzuOIMtUOLscm9ibI=.f1c2ac1d-51cd-48d4-804a-b7a91ecea865@github.com>
References: <AF4ZUl0ny2Mzk2XrJiWpUPvv63oubznivKfrGgbyz20=.a1c8a867-1f21-4ff9-b76b-91c456a126b8@github.com>
 <hAa0LQeoZz5ewi845E8N7_Tg2eCtlclx69j6stTS8MI=.d46906a1-98ea-4575-9c7b-0c348eeac2f3@github.com>
 <1dWWxpfyieTZiPq-2nyC9E6RFu9o6oTbI1Fgu2Yfva4=.15f9f4a3-7b74-47b6-9912-fe9ffda63420@github.com>
 <gnJsS2NWTTz_fTsHQHlcIHvGbUIzuOIMtUOLscm9ibI=.f1c2ac1d-51cd-48d4-804a-b7a91ecea865@github.com>
Message-ID: <6qUvIHueHH3KolEkohBHXvJx8b2KYEdcFiJXke6dRZU=.79b5aeee-d9ba-4fb2-b5e9-a6cac35884ef@github.com>

On Tue, 6 Jan 2026 01:36:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The `const` is still relevant, for the reason described. It's at least
>> arguable that it's kind of sketchy to do this. It certainly took me a bit of
>> study to understand. Note that I moved the position of the `const` qualifier
>> to its more usual location (in our code) for declaring a constant object (the
>> `Atomic<Node*>` is atomic). It could instead be written as `Atomic<Node*> const*`,
>> retaining the ordering from the original. Also see the implementation, where
>> we need to cast away the `const` qualifier, which is now being done with
>> `const_cast` rather than a C-style cast (that was also stripping off the `volatile`
>> qualifier, which the use of `AtomicAccess` implicitly reapplied).
>
> Okay. The comment would make more sense, IMO, on the implementation, rather than the declaration.

That part of the comment is explaining a weirdness in the signature, so there is some justification
for being in the header.  Coming up with a different protocol that doesn't have that weirdness might
be better, but far out of scope for this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28951#discussion_r2665626839

From kbarrett at openjdk.org  Tue Jan  6 18:00:33 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 6 Jan 2026 18:00:33 GMT
Subject: Integrated: 8374190: Convert ConcurrentHashTable atomic lists to use
 Atomic<T>
In-Reply-To: <AF4ZUl0ny2Mzk2XrJiWpUPvv63oubznivKfrGgbyz20=.a1c8a867-1f21-4ff9-b76b-91c456a126b8@github.com>
References: <AF4ZUl0ny2Mzk2XrJiWpUPvv63oubznivKfrGgbyz20=.a1c8a867-1f21-4ff9-b76b-91c456a126b8@github.com>
Message-ID: <4XfDWjYeeh1m1PJjM_bsSLJ8h0-qyrKeYhlc5BX0Qj0=.6fafc222-2bcf-4c3a-bb2a-6d1377de912f@github.com>

On Mon, 22 Dec 2025 07:29:55 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to ConcurrentHashTable to use `Atomic<Node*>` for
> the Node lists.  Note that this does not complete the replacement of direct
> uses of AtomicAccess by that class; there's still one more group remaining.
> 
> Testing: mach5 tier1-3

This pull request has now been integrated.

Changeset: cdbc493a
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cdbc493a6d93a0da0db987245daa7b1d00cc8add
Stats:     42 lines in 2 files changed: 12 ins; 0 del; 30 mod

8374190: Convert ConcurrentHashTable atomic lists to use Atomic<T>

Reviewed-by: dholmes, iwalulya

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

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

From kbarrett at openjdk.org  Tue Jan  6 18:11:17 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 6 Jan 2026 18:11:17 GMT
Subject: RFR: 8374623: Move DependentAlwaysFalse variable template to its own
 file
Message-ID: <xW1nnX6smezDQFpj1A2uod-Rb5-cSLnflfm4txVT-ns=.a5a57343-0454-4d98-b1f5-d4393f092661@github.com>

Please review this trivial change that moves the definition of the
DependentAlwaysFalse variable template from globalDefinitions.hpp to its own
file metaprogramming/dependentAlwaysFalse.hpp.  Also updated using files to
include the new header.

Testing: mach5 tier1

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

Commit messages:
 - move variable

Changes: https://git.openjdk.org/jdk/pull/29068/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29068&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374623
  Stats: 49 lines in 4 files changed: 38 ins; 8 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/29068.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29068/head:pull/29068

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

From duke at openjdk.org  Tue Jan  6 21:29:36 2026
From: duke at openjdk.org (Larry Cable)
Date: Tue, 6 Jan 2026 21:29:36 GMT
Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files
 loaded by a process [v2]
In-Reply-To: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
Message-ID: <lr2p6rekVeJbsfofbxPes-gQT-oqTd82W_f4n_18VwY=.50aecfcb-2822-44b1-bc6c-d48a333b3558@github.com>

> modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain.
> 
> effectively:
> 
> someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm()
> 
> (where interim oops are null-checked)

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

  JDK-8327246: updated copyright year. fixed Capitialization nit and restructured use of InstanceKlass local as per comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29048/files
  - new: https://git.openjdk.org/jdk/pull/29048/files/6ce88730..dd11893b

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

  Stats: 16 lines in 4 files changed: 3 ins; 3 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/29048.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29048/head:pull/29048

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

From duke at openjdk.org  Tue Jan  6 21:35:25 2026
From: duke at openjdk.org (Larry Cable)
Date: Tue, 6 Jan 2026 21:35:25 GMT
Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files
 loaded by a process [v2]
In-Reply-To: <WwyPYNitCJzQu-VrRTkJWJ3viKIUzwIAG6ePs3o_GwQ=.324764af-f05f-440f-ac8b-4dd2212dfde2@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <WwyPYNitCJzQu-VrRTkJWJ3viKIUzwIAG6ePs3o_GwQ=.324764af-f05f-440f-ac8b-4dd2212dfde2@github.com>
Message-ID: <O8xUaoNIiv6Ffn1NBTyBeHa5lS6FSNKS3G7U_aZo54U=.0f7b9e9b-4b0d-4d2d-9811-40ffb8713bb6@github.com>

On Tue, 6 Jan 2026 10:51:22 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Larry Cable has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8327246: updated copyright year. fixed Capitialization nit and restructured use of InstanceKlass local as per comments
>
> src/hotspot/share/services/diagnosticCommand.cpp line 962:
> 
>> 960:            "S = is shared class",
>> 961:            "BOOLEAN", false, "false"),
>> 962:   _location("-location", "print class file location url (if available)", "BOOLEAN", false, "false") {
> 
> Nit: "Print class.." the option descriptions all begin with capital letters.

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2666360931

From duke at openjdk.org  Tue Jan  6 21:35:26 2026
From: duke at openjdk.org (Larry Cable)
Date: Tue, 6 Jan 2026 21:35:26 GMT
Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files
 loaded by a process [v2]
In-Reply-To: <MsQ9qU956Mf4BXEaX4nn5GTOOdqIJHqrCE2B-G_KM2I=.b54e8568-f75d-4a78-9924-78aa6aafd597@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <MsQ9qU956Mf4BXEaX4nn5GTOOdqIJHqrCE2B-G_KM2I=.b54e8568-f75d-4a78-9924-78aa6aafd597@github.com>
Message-ID: <Oo6xeE8jAJ7yxl5lBp5_mdI-6_NI3e0TJlRe5ffXtg0=.73aeee65-6899-4bbf-8b0b-a7b92eb2b53a@github.com>

On Mon, 5 Jan 2026 22:20:06 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Larry Cable has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8327246: updated copyright year. fixed Capitialization nit and restructured use of InstanceKlass local as per comments
>
> src/hotspot/share/services/diagnosticCommand.cpp line 962:
> 
>> 960:            "S = is shared class",
>> 961:            "BOOLEAN", false, "false"),
>> 962:   _location("-location", "print class file location url (if available)", "BOOLEAN", false, "false") {
> 
> Not a review yet. But this new functionality deserve a regression test.

noted....

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2666362531

From vpaprotski at openjdk.org  Tue Jan  6 21:35:54 2026
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Tue, 6 Jan 2026 21:35:54 GMT
Subject: RFR: 8374570: Assertion failure in ClearArray.java  with
 -XX:+EnableX86EcoreOpts
Message-ID: <Ktp_W59MQVNSQ6YyBicFyIGJpb3SH7hPyjMuWIm2uUY=.795faf4d-5111-43e0-9fc7-91426382615f@github.com>

Allow for a larger jump distance

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

Commit messages:
 - fix assert

Changes: https://git.openjdk.org/jdk/pull/29070/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29070&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374570
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/29070.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29070/head:pull/29070

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

From duke at openjdk.org  Tue Jan  6 21:43:39 2026
From: duke at openjdk.org (Larry Cable)
Date: Tue, 6 Jan 2026 21:43:39 GMT
Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files
 loaded by a process
In-Reply-To: <Kq3nQggB7Q5rVmlcJ49s3tXuAFDpa7AJnxIbXrHSmV4=.22eb6bab-94c5-4c66-b474-9b3418ecb468@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <Kq3nQggB7Q5rVmlcJ49s3tXuAFDpa7AJnxIbXrHSmV4=.22eb6bab-94c5-4c66-b474-9b3418ecb468@github.com>
Message-ID: <s_EQtwTANnJ40e9oXriagQo4o_pd5SJWv1w35a0Rwno=.be25c431-8938-4026-9606-e10e5bbc1069@github.com>

On Tue, 6 Jan 2026 11:50:30 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> "VM.classes -verbose" is _very_ verbose already, so a separate option looks like the right choice to me. More lightweight queries for just this info.
> 
> $ build/linux-x64/images/jdk/bin/jcmd 741576 VM.classes | wc -l 544 $ build/linux-x64/images/jdk/bin/jcmd 741576 VM.classes -verbose | wc -l 18209 (on a trivial test app)

given the verbosity, its my inclination is to leave the impl as it is, with a distinct option flag for location, perhaps also adding it (location) if -verbose is specified (instead) ... for completeness.

until such time as all jcmds support "human readable", & "machine parseable" formatting options I think that the small incremental effort required to maintain an albeit informal (and unsupported) contract here is worth it in the interim, I for
one have no insight into what extent jcmd users depend on the current (plain text) formats as parseable but would prefer
to avoid breaking any such assumptions for the price of an option flag (in moderation of course)

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

PR Comment: https://git.openjdk.org/jdk/pull/29048#issuecomment-3716463122

From sparasa at openjdk.org  Tue Jan  6 23:44:27 2026
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 6 Jan 2026 23:44:27 GMT
Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with
 AVX512 [v11]
In-Reply-To: <4DbVeS6SQL4D3AJD1xTxGr3DI9B6XMxOS4r30vDXhCk=.8890e33c-df2e-451d-9dae-1d858b5f06f4@github.com>
References: <vR7Pzk96gG0PlTn5P5U1qlqyCvISC0dCMxUXyWHfy2g=.e58b097d-790c-4725-8ac8-7e8f2c94ac50@github.com>
 <07NHyGU8bmzafUXXdLP3X81f7OZrqP6JcXZmtPh78J4=.5551605a-ade3-4190-9cf8-ae2a68857694@github.com>
 <AgaBCE3g6nhD0isml3KooOg6-j5dZntKBRpHTAaImrg=.1ae89527-2047-4503-9bff-29d695357234@github.com>
 <4DbVeS6SQL4D3AJD1xTxGr3DI9B6XMxOS4r30vDXhCk=.8890e33c-df2e-451d-9dae-1d858b5f06f4@github.com>
Message-ID: <_wIrJ7pjq7nJaXKFxqw6q9VRsk-2Motw3UfRVw8LnH4=.7b3febd9-3908-447c-b485-a3428e32a452@github.com>

On Tue, 6 Jan 2026 08:38:36 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> Can you explain a bit more, and maybe add an additional column that gives us a speedup number?
>
Hi Emanuel (@eme64),
Currently, with +OptimizeFill flag, the fill intrinsic uses the **masked vector store** operation. From a performance point of view, the masked store operation, as shown in the left most column, has a **zig-zag pattern for latency** (i.e. time taken for the fill) as the array size increases. For example, for sizes in 1 to 16, it takes 0.43 secs for the masked store, whereas, it takes 0.21 seconds for the same masked store for sizes 17 to 32.

Without the fill intrinsic (-OptimizeFill), in the middle column, the fill latency increases linearly with respect to the size of the array. For small sizes <=16, the JITed code (-OptimizeFill) is faster than the intrinsic (+OptimizeFill) using masked store, thereby causing the performance regression reported.

This PR (right most column), replaces the zig-zig behavior of the masked store (left most column), with a more predictable fill using unmasked stores whose latency increases as log(N), where N is the size of the array. This is better than without the intrinsic (-OptimizeFill) but in some cases is slower than the masked store due to its **zig-zag behavior**.

As suggested, I will also provide the following data:

- Performance data for byte, short and int (the types affected by this PR) with plots for sizes upto 300.
- Performance data taking alignment (arbitrary offset) into consideration (`Arrays.fill(type[] a, int fromIndex, int toIndex, type val`)
- Performance data using fill_var_*_arrays_fill bencharks from your recent PR
- Performance data prior to [JDK-8275047](https://bugs.openjdk.org/browse/JDK-8275047)

Thanks,
Vamsi

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

PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3716740610

From dholmes at openjdk.org  Wed Jan  7 00:05:18 2026
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 7 Jan 2026 00:05:18 GMT
Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files
 loaded by a process [v2]
In-Reply-To: <lr2p6rekVeJbsfofbxPes-gQT-oqTd82W_f4n_18VwY=.50aecfcb-2822-44b1-bc6c-d48a333b3558@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <lr2p6rekVeJbsfofbxPes-gQT-oqTd82W_f4n_18VwY=.50aecfcb-2822-44b1-bc6c-d48a333b3558@github.com>
Message-ID: <vZXgIwgcQD9hQRZTIUy8XJ3DVhZd9FLVYxH2_WYrYmk=.c9c803a0-5f35-46a3-b065-2c607ac978a6@github.com>

On Tue, 6 Jan 2026 21:29:36 GMT, Larry Cable <duke at openjdk.org> wrote:

>> modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain.
>> 
>> effectively:
>> 
>> someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm()
>> 
>> (where interim oops are null-checked)
>
> Larry Cable has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8327246: updated copyright year. fixed Capitialization nit and restructured use of InstanceKlass local as per comments

Overall approach seems reasonable. I have a couple of queries.

Thanks

src/hotspot/share/oops/instanceKlass.cpp line 2359:

> 2357:   // initialization state
> 2358: 
> 2359:   InstanceKlass *ik = k->is_instance_klass() ? InstanceKlass::cast(k) : nullptr;

Suggestion:

  InstanceKlass* ik = k->is_instance_klass() ? InstanceKlass::cast(k) : nullptr;

src/hotspot/share/oops/instanceKlass.cpp line 2386:

> 2384:     oop pd = java_lang_Class::protection_domain(k->java_mirror());
> 2385: 
> 2386:     if (pd != nullptr && (ik = pd->klass()->is_instance_klass() ? InstanceKlass::cast(pd->klass()) : nullptr) != nullptr) {

Is a non-instance-class possible here??

src/hotspot/share/oops/instanceKlass.cpp line 2397:

> 2395:         oop cs = pd->obj_field(csfd.offset());
> 2396: 
> 2397:         if (cs != nullptr && (ik = cs->klass()->is_instance_klass() ? InstanceKlass::cast(cs->klass()) : nullptr) != nullptr) {

Is a non-instance-class possible here??

src/hotspot/share/oops/instanceKlass.cpp line 2406:

> 2404:             oop loc = cs->obj_field(locfd.offset());
> 2405: 
> 2406:             if (loc != nullptr && loc->klass() == vmClasses::String_klass()) {

Why are you checking the class type?

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

PR Review: https://git.openjdk.org/jdk/pull/29048#pullrequestreview-3632862000
PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2666611656
PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2666619018
PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2666619778
PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2666626257

From sspitsyn at openjdk.org  Wed Jan  7 01:05:41 2026
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 7 Jan 2026 01:05:41 GMT
Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files
 loaded by a process
In-Reply-To: <zQNvDZtI3hP7JylJo5ubA6zBFg_UCx8xQxYOE4lVw-8=.bd7b1a16-5329-41b2-92b9-4cd5c3d3626a@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <hqsjUWQmB08DmLRruKUI08W2QAUslleucNTa_mOjbwA=.db2de627-2476-4346-ae4d-d2fe7a8479f4@github.com>
 <zQNvDZtI3hP7JylJo5ubA6zBFg_UCx8xQxYOE4lVw-8=.bd7b1a16-5329-41b2-92b9-4cd5c3d3626a@github.com>
Message-ID: <8iF5lwO870gPlfcozjDBwgYE9hw0WxeIjVfGiTT2ZmA=.a7b55428-5686-4578-b71a-f5d47414b524@github.com>

On Mon, 5 Jan 2026 23:22:01 GMT, Larry Cable <duke at openjdk.org> wrote:

> IMO adding a new option preserves the existing contract while providing the additional metadata for new consumers
aware of its availability and desirous of its content.

I'm with this approach in general but just wanted opinions exchange on this.

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

PR Comment: https://git.openjdk.org/jdk/pull/29048#issuecomment-3716914987

From serb at openjdk.org  Wed Jan  7 02:24:25 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 7 Jan 2026 02:24:25 GMT
Subject: RFR: 8374316: Update copyright year to 2025 for hotspot in files
 where it was missed [v4]
In-Reply-To: <JnDBfpSX2boh4MregZIgWpxg8gmgpal0_p7-cmp92Ok=.53d89bd4-7f69-489b-b18b-d48ff354ecbf@github.com>
References: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
 <rLRlxg59ztJPN1eGournxUICh4mvQfqQkNIdbdIhHDM=.4ffd8bb3-8cf5-49e2-af8c-c2a3b23dad7b@github.com>
 <JnDBfpSX2boh4MregZIgWpxg8gmgpal0_p7-cmp92Ok=.53d89bd4-7f69-489b-b18b-d48ff354ecbf@github.com>
Message-ID: <Y5_mNmjjmMarr5d5NPbcv06zyT2FQh35o3TkJarbr1A=.b0715e43-a3fd-4301-b52e-fdf7e54821e9@github.com>

On Tue, 6 Jan 2026 01:58:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

>Just be aware that if a file was created as part of a refactoring and the code was taken as-is from an existing file, then the copyright year range should have remained the same as the original file. I don't know if any of the files you modified fall into that category but just wanted to point out that looking at the commit date is not always correct.

I tried to catch rename/move-only or copyright-only changes, but I?m not 100% sure I filtered all of them out.

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

PR Comment: https://git.openjdk.org/jdk/pull/28970#issuecomment-3717068454

From fyang at openjdk.org  Wed Jan  7 06:59:48 2026
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 7 Jan 2026 06:59:48 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v9]
In-Reply-To: <tRwCEAHLj8beRKhrrlMdf3Ng0iDe6YnJYcbvWNyvxRE=.d2da523d-8f57-4554-a3e3-0604e05fd214@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <tRwCEAHLj8beRKhrrlMdf3Ng0iDe6YnJYcbvWNyvxRE=.d2da523d-8f57-4554-a3e3-0604e05fd214@github.com>
Message-ID: <zYeqIU71zKJDz6Z-GbEGxrYOjzqxRqsu0NnyK7Rjc74=.977dee3f-78f5-4309-b8ef-86672ff455ab@github.com>

On Wed, 17 Dec 2025 12:56:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
>> - Add necessary inline expander support.
>>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
>> - Use existing Float16 vector IR and backend support.
>> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>>  
>> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
>> 
>> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
>> 
>> <img width="1344" height="532" alt="image" src="https://github.com/user-attachments/assets/c8157c3c-22b0-4bc1-9de9-7a68cadb7b2a" />
>> 
>> Initial RFP[1] was floated on the panama-dev mailing list.
>> 
>> Kindly review the draft PR and share your feedback.
>> 
>> Best Regards,
>> Jatin
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:
> 
>  - Fix from Bhavana Kilambi for failing JTREG regressions on AARCH64
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
>  - Including test changes from Bhavana Kilambi (ARM)
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
>  - Optimizing tail handling
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
>  - Cleanups
>  - Fix failing jtreg test in CI
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
>  - Cleanups
>  - ... and 13 more: https://git.openjdk.org/jdk/compare/5e7ae281...703f313d

Hi, I have a minor question about the tests.

test/jdk/jdk/incubator/vector/Float16Vector64Tests.java line 1893:

> 1891:         VectorMask<Float16> m = three.compare(VectorOperators.LE, higher);
> 1892:         assert(m.allTrue());
> 1893:         m = higher.min((short)-1).test(VectorOperators.IS_NEGATIVE);

I find that `higher.min((short)-1)` produces a float16 vector of 4 NaNs. So are we testing for negative NaNs with `VectorOperators.IS_NEGATIVE`? Is it more reasonable to test `VectorOperators.IS_NAN` instead?

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

PR Review: https://git.openjdk.org/jdk/pull/28002#pullrequestreview-3633583291
PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2667282723

From thartmann at openjdk.org  Wed Jan  7 07:31:40 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 7 Jan 2026 07:31:40 GMT
Subject: RFR: 8374570: Assertion failure in ClearArray.java  with
 -XX:+EnableX86EcoreOpts
In-Reply-To: <Ktp_W59MQVNSQ6YyBicFyIGJpb3SH7hPyjMuWIm2uUY=.795faf4d-5111-43e0-9fc7-91426382615f@github.com>
References: <Ktp_W59MQVNSQ6YyBicFyIGJpb3SH7hPyjMuWIm2uUY=.795faf4d-5111-43e0-9fc7-91426382615f@github.com>
Message-ID: <FmkJw3u9E93aNWMm-a5QDIdnhtYV60r4qwmmQED3OAY=.af52c857-9394-40c5-abb5-1a646154231d@github.com>

On Tue, 6 Jan 2026 21:27:21 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

> Allow for a larger jump distance

Looks good to me.

Could you please add a regression test?

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29070#pullrequestreview-3633657305
Changes requested by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29070#pullrequestreview-3633659002

From tschatzl at openjdk.org  Wed Jan  7 07:48:36 2026
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 7 Jan 2026 07:48:36 GMT
Subject: RFR: 8374328: Convert simple AtomicAccess uses in gc/shared to use
 Atomic<T> [v2]
In-Reply-To: <eKtPNvQBTPlQk_hCJrcWWv98vVwtuQ-7s1F5CDAbcUU=.7f8592f1-8a3e-4c96-bb26-9aab7eddf9a2@github.com>
References: <RJp0KKg8demYMWOXkrVs1g_jitLhTsvce6ZFO98ihNw=.2c8e0a03-d56a-450e-91c8-019931a717b8@github.com>
 <eKtPNvQBTPlQk_hCJrcWWv98vVwtuQ-7s1F5CDAbcUU=.7f8592f1-8a3e-4c96-bb26-9aab7eddf9a2@github.com>
Message-ID: <zgJEBFz2AD04Fxyh0FTmncr_Hc-ne4sou8N4po77AWs=.162e825b-e215-44b0-85b9-0f18184ca829@github.com>

On Fri, 2 Jan 2026 10:11:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review these fairly simple changes to code in gc/shared to use
>> `Atomic<T>` instead of directly using `AtomicAccess`.
>> 
>> This change doesn't eliminate all remaining direct uses of `AtomicAccess` in
>> that directory; there are still a few uses that seem less simple, and maybe
>> some that should stay with direct `AtomicAccess`.
>> 
>> The changes are grouped into a series of commits, as a potential aid to reviewers.
>> 
>> Testing: mach5 tier1-5
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyrights

All good but for copyright notices.

src/hotspot/share/gc/shared/barrierSetNMethod.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2026, Oracle and/or its affiliates. All rights reserved.

Should all be 2027 now...

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

Changes requested by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28987#pullrequestreview-3633694131
PR Review Comment: https://git.openjdk.org/jdk/pull/28987#discussion_r2667384039

From jsjolen at openjdk.org  Wed Jan  7 08:03:32 2026
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 7 Jan 2026 08:03:32 GMT
Subject: RFR: 8374623: Move DependentAlwaysFalse variable template to its
 own file
In-Reply-To: <xW1nnX6smezDQFpj1A2uod-Rb5-cSLnflfm4txVT-ns=.a5a57343-0454-4d98-b1f5-d4393f092661@github.com>
References: <xW1nnX6smezDQFpj1A2uod-Rb5-cSLnflfm4txVT-ns=.a5a57343-0454-4d98-b1f5-d4393f092661@github.com>
Message-ID: <bTRQVxwphrmCxtUofTcyPCQwTjILBk_KwFt42JFqQ20=.c92bf15e-afc9-4682-ae11-1227ffc2f5ae@github.com>

On Tue, 6 Jan 2026 18:05:52 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial change that moves the definition of the
> DependentAlwaysFalse variable template from globalDefinitions.hpp to its own
> file metaprogramming/dependentAlwaysFalse.hpp.  Also updated using files to
> include the new header.
> 
> Testing: mach5 tier1

OK by me and I agree that the change is trivial.

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29068#pullrequestreview-3633745014

From roland at openjdk.org  Wed Jan  7 08:16:55 2026
From: roland at openjdk.org (Roland Westrelin)
Date: Wed, 7 Jan 2026 08:16:55 GMT
Subject: RFR: 8373343: C2: verify AddP base input only set for heap
 addresses [v4]
In-Reply-To: <fdm8TK_FBJheQ_Wkd_KobosU0uTioUuRZhIK38I3Q-g=.8ae8e498-9c14-4cae-8e68-4c39914a8195@github.com>
References: <fdm8TK_FBJheQ_Wkd_KobosU0uTioUuRZhIK38I3Q-g=.8ae8e498-9c14-4cae-8e68-4c39914a8195@github.com>
Message-ID: <X3ATo35ItGD-thnX4VKIiVABa5Kc7fLpJyV1Ez3Xfno=.bc21ce5c-d1f4-4b70-9157-9611074039ee@github.com>

> The base input of `AddP` is expected to only be set for heap accesses
> but I noticed some inconsistencies so I added an assert in the `AddP`
> constructor and fixed issues that it caught. AFAFICT, the
> inconsistencies shouldn't create issues.

Roland Westrelin 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 13 additional commits since the last revision:

 - more
 - more
 - review
 - Merge branch 'master' into JDK-8373343
 - review
 - review
 - review
 - merge
 - more
 - more
 - ... and 3 more: https://git.openjdk.org/jdk/compare/695159e3...b20f41db

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28769/files
  - new: https://git.openjdk.org/jdk/pull/28769/files/007e73cd..b20f41db

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

  Stats: 16548 lines in 2404 files changed: 8811 ins; 2140 del; 5597 mod
  Patch: https://git.openjdk.org/jdk/pull/28769.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28769/head:pull/28769

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

From tschatzl at openjdk.org  Wed Jan  7 08:17:37 2026
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 7 Jan 2026 08:17:37 GMT
Subject: RFR: 8374328: Convert simple AtomicAccess uses in gc/shared to use
 Atomic<T> [v2]
In-Reply-To: <eKtPNvQBTPlQk_hCJrcWWv98vVwtuQ-7s1F5CDAbcUU=.7f8592f1-8a3e-4c96-bb26-9aab7eddf9a2@github.com>
References: <RJp0KKg8demYMWOXkrVs1g_jitLhTsvce6ZFO98ihNw=.2c8e0a03-d56a-450e-91c8-019931a717b8@github.com>
 <eKtPNvQBTPlQk_hCJrcWWv98vVwtuQ-7s1F5CDAbcUU=.7f8592f1-8a3e-4c96-bb26-9aab7eddf9a2@github.com>
Message-ID: <v9Tu6qQxUh2-pYRMW-UfXDR-GZOCUT2ZjT1m5H79Xq0=.74d04a3e-49b8-44b6-8643-5a075ebb01f8@github.com>

On Fri, 2 Jan 2026 10:11:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review these fairly simple changes to code in gc/shared to use
>> `Atomic<T>` instead of directly using `AtomicAccess`.
>> 
>> This change doesn't eliminate all remaining direct uses of `AtomicAccess` in
>> that directory; there are still a few uses that seem less simple, and maybe
>> some that should stay with direct `AtomicAccess`.
>> 
>> The changes are grouped into a series of commits, as a potential aid to reviewers.
>> 
>> Testing: mach5 tier1-5
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyrights

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28987#pullrequestreview-3633789210

From roland at openjdk.org  Wed Jan  7 08:20:43 2026
From: roland at openjdk.org (Roland Westrelin)
Date: Wed, 7 Jan 2026 08:20:43 GMT
Subject: RFR: 8373343: C2: verify AddP base input only set for heap
 addresses [v3]
In-Reply-To: <lFYFZQbpc_c9pEewnw47E8ju-Rqe3pE-wYu66bgnryA=.04f449cc-f02d-40ea-a855-a3c484f59784@github.com>
References: <fdm8TK_FBJheQ_Wkd_KobosU0uTioUuRZhIK38I3Q-g=.8ae8e498-9c14-4cae-8e68-4c39914a8195@github.com>
 <kQMfKDd-5lJ-I3rXLgC2Y_u6lPAMUd_wSpf32HWcZ2s=.e93eda67-479a-44ed-821a-5b122daf062b@github.com>
 <lFYFZQbpc_c9pEewnw47E8ju-Rqe3pE-wYu66bgnryA=.04f449cc-f02d-40ea-a855-a3c484f59784@github.com>
Message-ID: <MXV9ZMiTYvZmgxalWcHcX4S6FBknN6hI57koVmX9M-A=.84df721a-c44c-46a2-96c2-832721c0b86d@github.com>

On Mon, 22 Dec 2025 07:23:34 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review
>
> src/hotspot/share/opto/graphKit.cpp line 3590:
> 
>> 3588:   }
>> 3589:   constant_value = Klass::_lh_neutral_value;  // put in a known value
>> 3590:   Node* lhp = basic_plus_adr(top(), klass_node, in_bytes(Klass::layout_helper_offset()));
> 
> Same thought here: could we have a separate `off_heap_plus_addr()` or something like that instead of passing in `top()` on each call site?
> 
> This and the other suggestion could also be done separately.

I gave that one a try and I found that pattern to be common and I think it would be best done as a separate change. WDYT?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28769#discussion_r2667477734

From roland at openjdk.org  Wed Jan  7 08:30:08 2026
From: roland at openjdk.org (Roland Westrelin)
Date: Wed, 7 Jan 2026 08:30:08 GMT
Subject: RFR: 8373343: C2: verify AddP base input only set for heap
 addresses [v4]
In-Reply-To: <X3ATo35ItGD-thnX4VKIiVABa5Kc7fLpJyV1Ez3Xfno=.bc21ce5c-d1f4-4b70-9157-9611074039ee@github.com>
References: <fdm8TK_FBJheQ_Wkd_KobosU0uTioUuRZhIK38I3Q-g=.8ae8e498-9c14-4cae-8e68-4c39914a8195@github.com>
 <X3ATo35ItGD-thnX4VKIiVABa5Kc7fLpJyV1Ez3Xfno=.bc21ce5c-d1f4-4b70-9157-9611074039ee@github.com>
Message-ID: <Eg6EHKNA--qKqrFSeQ4mG78_JasBKg0Mn3MKcbhCmiM=.ae7ea912-7139-47ba-b4ce-c80060efd428@github.com>

On Wed, 7 Jan 2026 08:16:55 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> The base input of `AddP` is expected to only be set for heap accesses
>> but I noticed some inconsistencies so I added an assert in the `AddP`
>> constructor and fixed issues that it caught. AFAFICT, the
>> inconsistencies shouldn't create issues.
>
> Roland Westrelin 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 13 additional commits since the last revision:
> 
>  - more
>  - more
>  - review
>  - Merge branch 'master' into JDK-8373343
>  - review
>  - review
>  - review
>  - merge
>  - more
>  - more
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/d5b742aa...b20f41db

I made one tweak in the updated change: `ClearArrayNode::clear_memory()` now takes an extra argument that tells whether it's writing to raw memory or not. That feels cleaner given whether raw memory is used or not can be figured out from where `ClearArrayNode::clear_memory()` is called.

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

PR Comment: https://git.openjdk.org/jdk/pull/28769#issuecomment-3717804909

From jbhateja at openjdk.org  Wed Jan  7 09:05:47 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 7 Jan 2026 09:05:47 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v9]
In-Reply-To: <zYeqIU71zKJDz6Z-GbEGxrYOjzqxRqsu0NnyK7Rjc74=.977dee3f-78f5-4309-b8ef-86672ff455ab@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <tRwCEAHLj8beRKhrrlMdf3Ng0iDe6YnJYcbvWNyvxRE=.d2da523d-8f57-4554-a3e3-0604e05fd214@github.com>
 <zYeqIU71zKJDz6Z-GbEGxrYOjzqxRqsu0NnyK7Rjc74=.977dee3f-78f5-4309-b8ef-86672ff455ab@github.com>
Message-ID: <BTvNZTd5A6PrXD1gARtQ0r3wtAkpzcjbunbkBFPwIQs=.c277bf29-1c32-45ef-98a1-536db7f52808@github.com>

On Wed, 7 Jan 2026 06:55:45 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:
>> 
>>  - Fix from Bhavana Kilambi for failing JTREG regressions on AARCH64
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
>>  - Including test changes from Bhavana Kilambi (ARM)
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
>>  - Optimizing tail handling
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
>>  - Cleanups
>>  - Fix failing jtreg test in CI
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
>>  - Cleanups
>>  - ... and 13 more: https://git.openjdk.org/jdk/compare/5e7ae281...703f313d
>
> test/jdk/jdk/incubator/vector/Float16Vector64Tests.java line 1893:
> 
>> 1891:         VectorMask<Float16> m = three.compare(VectorOperators.LE, higher);
>> 1892:         assert(m.allTrue());
>> 1893:         m = higher.min((short)-1).test(VectorOperators.IS_NEGATIVE);
> 
> I find that `higher.min((short)-1)` produces a float16 vector of 4 NaNs. So are we testing for negative NaNs with `VectorOperators.IS_NEGATIVE`? Is it more reasonable to test `VectorOperators.IS_NAN` instead?

Thanks for catching this, all the Float16Vector lanes and short argument passed to shorthand APIs are assumed to be encoded in IEEE 754 binary 16 format,  we should be passing Float16 bit representation of -1 here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2667602759

From shade at openjdk.org  Wed Jan  7 09:18:58 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 7 Jan 2026 09:18:58 GMT
Subject: RFR: 8374698: Stub names should look more like identifiers
Message-ID: <41ClGzK_bnZ3nmexlGdQW7Ncdh1q31ZDX_KZ1vBPNb4=.49a051e8-9345-4fe5-b635-efe44a21c051@github.com>

Noticed this when looking at disassembly. Cosmetic issue in [JDK-8360707](https://bugs.openjdk.org/browse/JDK-8360707) makes the stub identifiers look fairly weird:


0x0000786da3c1a6f2: call Stub::Stub Generator lookup_secondary_supers_table_slow_path_stub
    ; {runtime_call Stub::Stub Generator lookup_secondary_supers_table_slow_path_stub}


Notice "Stub Generator" in the middle of the stub identifier.

After the fix:


0x00007f357bc1a3f2:   call   Stub::lookup_secondary_supers_table_slow_path_stub (stub gen)
     ; {runtime_call Stub::lookup_secondary_supers_table_slow_path_stub (stub gen)}

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

Commit messages:
 - Fix

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

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

From shade at openjdk.org  Wed Jan  7 09:18:58 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 7 Jan 2026 09:18:58 GMT
Subject: RFR: 8374698: Stub names should look more like identifiers
In-Reply-To: <41ClGzK_bnZ3nmexlGdQW7Ncdh1q31ZDX_KZ1vBPNb4=.49a051e8-9345-4fe5-b635-efe44a21c051@github.com>
References: <41ClGzK_bnZ3nmexlGdQW7Ncdh1q31ZDX_KZ1vBPNb4=.49a051e8-9345-4fe5-b635-efe44a21c051@github.com>
Message-ID: <XZqpSNO3TbdLluxav55gMvwQ5ubGO0cKt8WbKSqLe8c=.2af25a3b-ee5b-43d2-bbc4-5fee0566d200@github.com>

On Wed, 7 Jan 2026 09:12:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Noticed this when looking at disassembly. Cosmetic issue in [JDK-8360707](https://bugs.openjdk.org/browse/JDK-8360707) makes the stub identifiers look fairly weird:
> 
> 
> 0x0000786da3c1a6f2: call Stub::Stub Generator lookup_secondary_supers_table_slow_path_stub
>     ; {runtime_call Stub::Stub Generator lookup_secondary_supers_table_slow_path_stub}
> 
> 
> Notice "Stub Generator" in the middle of the stub identifier.
> 
> After the fix:
> 
> 
> 0x00007f357bc1a3f2:   call   Stub::lookup_secondary_supers_table_slow_path_stub (stub gen)
>      ; {runtime_call Stub::lookup_secondary_supers_table_slow_path_stub (stub gen)}

@adinn  ^

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

PR Comment: https://git.openjdk.org/jdk/pull/29080#issuecomment-3717949665

From vyazici at openjdk.org  Wed Jan  7 09:23:28 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 7 Jan 2026 09:23:28 GMT
Subject: RFR: 8374210: [BACKOUT] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <s9ZJBBPGEpb1gS1KXWwqdkWjj2xkWEuNhqXDe87mRUI=.5910ff3a-31b9-4f7a-878d-1453c987f957@github.com>
References: <R0eSJy-eVdyNzgcTqEpW55CdubZTRdg6xK_Bmd1WQt4=.71411aaa-f14c-4b12-b594-d6e5410c0663@github.com>
 <s9ZJBBPGEpb1gS1KXWwqdkWjj2xkWEuNhqXDe87mRUI=.5910ff3a-31b9-4f7a-878d-1453c987f957@github.com>
Message-ID: <3Rpck6RY8Y4e8nra-VY8XWnlOUvYnXPEuwPL6DikCHU=.5a55c9f6-d5e9-431c-9285-d11c594127bd@github.com>

On Tue, 6 Jan 2026 10:53:21 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Back out `java.lang.StringCoding` changes delivered in [JDK-8361842] (#25998 & 655dc516c22), which causes regressions reported in [JDK-8374210].
>> 
>> [JDK-8361842]: https://bugs.openjdk.org/browse/JDK-8361842
>> [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210
>
> Looks good to me.

@TobiHartmann, @shipilev, thanks so much for your kind help, and reviews.
As I stated earlier, Tier 1-3 are clear using c8acc80b8c6, and I see no other remarks.

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

PR Comment: https://git.openjdk.org/jdk/pull/29055#issuecomment-3717974843

From vyazici at openjdk.org  Wed Jan  7 09:26:04 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 7 Jan 2026 09:26:04 GMT
Subject: Integrated: 8374210: [BACKOUT] Move input validation checks to Java
 for java.lang.StringCoding intrinsics
In-Reply-To: <R0eSJy-eVdyNzgcTqEpW55CdubZTRdg6xK_Bmd1WQt4=.71411aaa-f14c-4b12-b594-d6e5410c0663@github.com>
References: <R0eSJy-eVdyNzgcTqEpW55CdubZTRdg6xK_Bmd1WQt4=.71411aaa-f14c-4b12-b594-d6e5410c0663@github.com>
Message-ID: <3JPEbFO_Dlf3D46IlEOn21t0KL9wouC5z-0VQa31tsc=.f8de0911-4fcf-49f2-b25a-0b9e1059dc1a@github.com>

On Tue, 6 Jan 2026 08:16:16 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Back out `java.lang.StringCoding` changes delivered in [JDK-8361842] (#25998 & 655dc516c22), which causes regressions reported in [JDK-8374210].
> 
> [JDK-8361842]: https://bugs.openjdk.org/browse/JDK-8361842
> [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210

This pull request has now been integrated.

Changeset: 7e18de13
Author:    Volkan Yazici <vyazici at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7e18de137c3b5f08a479af2b64eb22923261900b
Stats:     437 lines in 23 files changed: 25 ins; 331 del; 81 mod

8374210: [BACKOUT] Move input validation checks to Java for java.lang.StringCoding intrinsics

Reviewed-by: shade, thartmann

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

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

From lkorinth at openjdk.org  Wed Jan  7 10:02:41 2026
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 7 Jan 2026 10:02:41 GMT
Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v2]
In-Reply-To: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
Message-ID: <Sqy2ecoZvJXHPHOfyOKzbCRID4cERqP9gbNciYUX6EY=.c44e3a4d-dfd6-44eb-8bab-668af696fd7b@github.com>

> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`.  Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads.
> 
> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads.
> 
> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253.
> 
> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look.

Leo Korinth has updated the pull request incrementally with 561 additional commits since the last revision:

 - Merge branch 'master' into _8367993
 - 8366058: Outdated comment in WinCAPISeedGenerator
   
   Reviewed-by: mullan
 - 8357258: x86: Improve receiver type profiling reliability
   
   Reviewed-by: kvn, vlivanov
 - 8373704: Improve "SocketException: Protocol family unavailable" message
   
   Reviewed-by: lucy, jpai
 - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently
   
   Reviewed-by: jiefu, jbhateja, erfang, qamai
 - 8343809: Add requires tag to mark tests that are incompatible with exploded image
   
   Reviewed-by: alanb, dholmes
 - 8374465: Spurious dot in documentation for JVMTI ClassLoad
   
   Reviewed-by: kbarrett
 - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket
   
   Reviewed-by: djelinski, mpowers, ascarpino
 - 8374444: Fix simple -Wzero-as-null-pointer-constant warnings
   
   Reviewed-by: aboldtch
 - 8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the ?Nothing? menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test
   
   Reviewed-by: serb, aivanov, dnguyen
 - ... and 551 more: https://git.openjdk.org/jdk/compare/b907b295...0ece3767

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28723/files
  - new: https://git.openjdk.org/jdk/pull/28723/files/b907b295..0ece3767

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

  Stats: 130212 lines in 3962 files changed: 83750 ins; 29714 del; 16748 mod
  Patch: https://git.openjdk.org/jdk/pull/28723.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28723/head:pull/28723

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

From kevinw at openjdk.org  Wed Jan  7 10:09:59 2026
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 7 Jan 2026 10:09:59 GMT
Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files
 loaded by a process [v2]
In-Reply-To: <lr2p6rekVeJbsfofbxPes-gQT-oqTd82W_f4n_18VwY=.50aecfcb-2822-44b1-bc6c-d48a333b3558@github.com>
References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com>
 <lr2p6rekVeJbsfofbxPes-gQT-oqTd82W_f4n_18VwY=.50aecfcb-2822-44b1-bc6c-d48a333b3558@github.com>
Message-ID: <QWOVCH2EToUov3bumijjB8zjuNL_vZxPjR9p19PJJCg=.4be5beb1-6f7c-4eda-903f-cd8dd279edd1@github.com>

On Tue, 6 Jan 2026 21:29:36 GMT, Larry Cable <duke at openjdk.org> wrote:

>> modified the pre-existing VM.classes jcmd to add a 'location' option, that when specified, will (natively) attempt to obtain the value (if non-null) of the location URL of the CodeSource of each classes ProtectionDomain.
>> 
>> effectively:
>> 
>> someObject.getClass().getProtectionDomain().getCodeSource().getLocation().toExternalForm()
>> 
>> (where interim oops are null-checked)
>
> Larry Cable has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8327246: updated copyright year. fixed Capitialization nit and restructured use of InstanceKlass local as per comments

src/hotspot/share/oops/instanceKlass.cpp line 2360:

> 2358: 
> 2359:   InstanceKlass *ik = k->is_instance_klass() ? InstanceKlass::cast(k) : nullptr;
> 2360: 

Looks good with the new local InstanceKlass ik.
Is it possible to not reassign into ik at lines 2386 and 2397, i.e. ik was the target class as an instanceKlass, but later represents pd or cs, so that can be hard to follow.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2667816732

From kbarrett at openjdk.org  Wed Jan  7 10:10:16 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 7 Jan 2026 10:10:16 GMT
Subject: RFR: 8374623: Move DependentAlwaysFalse variable template to its
 own file
In-Reply-To: <bTRQVxwphrmCxtUofTcyPCQwTjILBk_KwFt42JFqQ20=.c92bf15e-afc9-4682-ae11-1227ffc2f5ae@github.com>
References: <xW1nnX6smezDQFpj1A2uod-Rb5-cSLnflfm4txVT-ns=.a5a57343-0454-4d98-b1f5-d4393f092661@github.com>
 <bTRQVxwphrmCxtUofTcyPCQwTjILBk_KwFt42JFqQ20=.c92bf15e-afc9-4682-ae11-1227ffc2f5ae@github.com>
Message-ID: <negX2pcp4JBLZJfU3oOb96EY0No9TVec7vEI73Fvezk=.88337bd1-2615-4fd9-8438-4f9f02eaff2f@github.com>

On Wed, 7 Jan 2026 08:00:29 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Please review this trivial change that moves the definition of the
>> DependentAlwaysFalse variable template from globalDefinitions.hpp to its own
>> file metaprogramming/dependentAlwaysFalse.hpp.  Also updated using files to
>> include the new header.
>> 
>> Testing: mach5 tier1
>
> OK by me and I agree that the change is trivial.

Thanks for reviewing @jdksjolen

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

PR Comment: https://git.openjdk.org/jdk/pull/29068#issuecomment-3718134555

From kbarrett at openjdk.org  Wed Jan  7 10:10:17 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 7 Jan 2026 10:10:17 GMT
Subject: Integrated: 8374623: Move DependentAlwaysFalse variable template to
 its own file
In-Reply-To: <xW1nnX6smezDQFpj1A2uod-Rb5-cSLnflfm4txVT-ns=.a5a57343-0454-4d98-b1f5-d4393f092661@github.com>
References: <xW1nnX6smezDQFpj1A2uod-Rb5-cSLnflfm4txVT-ns=.a5a57343-0454-4d98-b1f5-d4393f092661@github.com>
Message-ID: <WuPkZupIeU_QThie8feSnJuAgKXU1SF5a7DWt2tODWo=.20a63a97-86b8-4e3f-aa54-8f4e34bbe24b@github.com>

On Tue, 6 Jan 2026 18:05:52 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial change that moves the definition of the
> DependentAlwaysFalse variable template from globalDefinitions.hpp to its own
> file metaprogramming/dependentAlwaysFalse.hpp.  Also updated using files to
> include the new header.
> 
> Testing: mach5 tier1

This pull request has now been integrated.

Changeset: 2074b975
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2074b975c3d08fec2ecd47dab48132be2ec7c3cf
Stats:     49 lines in 4 files changed: 38 ins; 8 del; 3 mod

8374623: Move DependentAlwaysFalse variable template to its own file

Reviewed-by: jsjolen

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

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

From aph at openjdk.org  Wed Jan  7 12:02:36 2026
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 7 Jan 2026 12:02:36 GMT
Subject: RFR: 8365147: AArch64: Replace DMB + LD + DMB with LDAR for C1
 volatile field loads [v4]
In-Reply-To: <nkJYB7G_xrlgKde7zSJzCo5cxgzed1mBSlw2ie_15qQ=.20fb92b7-f694-4225-8602-4a63674234a3@github.com>
References: <p7XaTTrJZA65XAB3EoXH_cI34eOKXcSaPozylNiWMss=.4b218507-adbd-4351-996f-88f1c38f5f18@github.com>
 <nkJYB7G_xrlgKde7zSJzCo5cxgzed1mBSlw2ie_15qQ=.20fb92b7-f694-4225-8602-4a63674234a3@github.com>
Message-ID: <3a_1QZxP59TuI3FewXHDcR_xWH616tlSpcCf1f4BbP0=.c7570d0a-56a6-424d-a5ea-489318734d99@github.com>

On Wed, 19 Nov 2025 12:47:18 GMT, Samuel Chee <duke at openjdk.org> wrote:

>> Replaces the DMB ISH + LD + DMB ISHLD sequence with LDAR for volatile field loads - for example, AtomicLong::get.
>> 
>> This is valid, as originally the DMBs were necessary due to the case described here - https://bugs.openjdk.org/browse/JDK-8179954. As in the rare case where the LD can be reordered with an LDAR or STLR from the C2 implementation for stores and loads, these DMBs are required.
>> However, acquire/release operations use a sequentially consistent model which does not allow reordering between them. Hence, the LD can be replaced with an LDAR to disallow reordering with a STLR/LDAR and the first DMB can be removed.
>> 
>> The LDAR has acquire semantics, so it's impossible for memory accesses after to be reordered before; the DMB ISHLD is not required. Therefore, a singular LDAR is sufficient.
>
> Samuel Chee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename load_generic -> load_relaxed

Where is this patch going? Do we want to close this one and open another?

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

PR Comment: https://git.openjdk.org/jdk/pull/26748#issuecomment-3718548788

From shade at openjdk.org  Wed Jan  7 12:25:38 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 7 Jan 2026 12:25:38 GMT
Subject: RFR: 8374698: Stub names should look more like identifiers [v2]
In-Reply-To: <41ClGzK_bnZ3nmexlGdQW7Ncdh1q31ZDX_KZ1vBPNb4=.49a051e8-9345-4fe5-b635-efe44a21c051@github.com>
References: <41ClGzK_bnZ3nmexlGdQW7Ncdh1q31ZDX_KZ1vBPNb4=.49a051e8-9345-4fe5-b635-efe44a21c051@github.com>
Message-ID: <bd9g-wJdlXSzlSplooeUFC9SZyjUuUjPT57d3xmE0gg=.eb54555f-9d49-4abf-9a57-76bc939e2578@github.com>

> Noticed this when looking at disassembly. Cosmetic issue in [JDK-8360707](https://bugs.openjdk.org/browse/JDK-8360707) makes the stub identifiers look fairly weird:
> 
> 
> 0x0000786da3c1a6f2: call Stub::Stub Generator lookup_secondary_supers_table_slow_path_stub
>     ; {runtime_call Stub::Stub Generator lookup_secondary_supers_table_slow_path_stub}
> 
> 
> Notice "Stub Generator" in the middle of the stub identifier.
> 
> After the fix:
> 
> 
> 0x00007f357bc1a3f2:   call   Stub::lookup_secondary_supers_table_slow_path_stub (stub gen)
>      ; {runtime_call Stub::lookup_secondary_supers_table_slow_path_stub (stub gen)}

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

  Of course there are asserts that verify stub names directly

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29080/files
  - new: https://git.openjdk.org/jdk/pull/29080/files/e3f01c75..eae99d56

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

  Stats: 16 lines in 4 files changed: 10 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/29080.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29080/head:pull/29080

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

From lkorinth at openjdk.org  Wed Jan  7 12:35:42 2026
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 7 Jan 2026 12:35:42 GMT
Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v2]
In-Reply-To: <Sqy2ecoZvJXHPHOfyOKzbCRID4cERqP9gbNciYUX6EY=.c44e3a4d-dfd6-44eb-8bab-668af696fd7b@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
 <Sqy2ecoZvJXHPHOfyOKzbCRID4cERqP9gbNciYUX6EY=.c44e3a4d-dfd6-44eb-8bab-668af696fd7b@github.com>
Message-ID: <rncRewS4A4nkwvAkJRLAAJ-BhEGWXFxsGy8Pl-m0fNI=.af3d6a7d-6a61-4dee-a26a-d09e7215bc4e@github.com>

On Wed, 7 Jan 2026 10:02:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`.  Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads.
>> 
>> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads.
>> 
>> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253.
>> 
>> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look.
>
> Leo Korinth has updated the pull request incrementally with 561 additional commits since the last revision:
> 
>  - Merge branch 'master' into _8367993
>  - 8366058: Outdated comment in WinCAPISeedGenerator
>    
>    Reviewed-by: mullan
>  - 8357258: x86: Improve receiver type profiling reliability
>    
>    Reviewed-by: kvn, vlivanov
>  - 8373704: Improve "SocketException: Protocol family unavailable" message
>    
>    Reviewed-by: lucy, jpai
>  - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently
>    
>    Reviewed-by: jiefu, jbhateja, erfang, qamai
>  - 8343809: Add requires tag to mark tests that are incompatible with exploded image
>    
>    Reviewed-by: alanb, dholmes
>  - 8374465: Spurious dot in documentation for JVMTI ClassLoad
>    
>    Reviewed-by: kbarrett
>  - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket
>    
>    Reviewed-by: djelinski, mpowers, ascarpino
>  - 8374444: Fix simple -Wzero-as-null-pointer-constant warnings
>    
>    Reviewed-by: aboldtch
>  - 8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the ?Nothing? menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test
>    
>    Reviewed-by: serb, aivanov, dnguyen
>  - ... and 551 more: https://git.openjdk.org/jdk/compare/b907b295...0ece3767

I will redo the merge, I have done something strange.

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

PR Comment: https://git.openjdk.org/jdk/pull/28723#issuecomment-3718660595

From lkorinth at openjdk.org  Wed Jan  7 12:58:43 2026
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 7 Jan 2026 12:58:43 GMT
Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v3]
In-Reply-To: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
Message-ID: <F0yu8OvqtdnssFD3SQoQ4DItAxBELEvwD1aAei2J5M8=.df501c22-ac18-4742-a0ab-ec6d1848be1f@github.com>

> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`.  Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads.
> 
> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads.
> 
> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253.
> 
> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look.

Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 564 commits:

 - Merge branch '8373253' into 8367993
 - Merge branch 'master' into _8373253
 - Merge branch 'master' into _8367993
 - 8366058: Outdated comment in WinCAPISeedGenerator
   
   Reviewed-by: mullan
 - 8357258: x86: Improve receiver type profiling reliability
   
   Reviewed-by: kvn, vlivanov
 - 8373704: Improve "SocketException: Protocol family unavailable" message
   
   Reviewed-by: lucy, jpai
 - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently
   
   Reviewed-by: jiefu, jbhateja, erfang, qamai
 - 8343809: Add requires tag to mark tests that are incompatible with exploded image
   
   Reviewed-by: alanb, dholmes
 - 8374465: Spurious dot in documentation for JVMTI ClassLoad
   
   Reviewed-by: kbarrett
 - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket
   
   Reviewed-by: djelinski, mpowers, ascarpino
 - ... and 554 more: https://git.openjdk.org/jdk/compare/2aa8aa4b...28ccbb68

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

Changes: https://git.openjdk.org/jdk/pull/28723/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28723&range=02
  Stats: 130308 lines in 3967 files changed: 83803 ins; 29735 del; 16770 mod
  Patch: https://git.openjdk.org/jdk/pull/28723.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28723/head:pull/28723

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

From mgronlun at openjdk.org  Wed Jan  7 14:23:52 2026
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 7 Jan 2026 14:23:52 GMT
Subject: RFR: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is
 incorrectly implemented
In-Reply-To: <SiBemHHhiHk3uDElvjRK16U2SNea7P1wsptA_4z7kxA=.0746951f-41b4-46b4-8397-40603dea6298@github.com>
References: <SiBemHHhiHk3uDElvjRK16U2SNea7P1wsptA_4z7kxA=.0746951f-41b4-46b4-8397-40603dea6298@github.com>
Message-ID: <hgAyKMzLuFluIKVlWxPAmhx9C-LwKHZF--IclytugAM=.c9e86f72-1147-4720-91e8-1dbf55e3079f@github.com>

On Sat, 29 Nov 2025 06:06:16 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> The jtreg test TestEmergencyDumpAtOOM.java runs into the following error on ppc64 platforms.
> 
> JFR emergency dump would be kicked at `VMError::report_and_die()`, then Java thread for JFR would not work due to secondary signal handler for error reporting.
> 
> Passed all of jdk_jfr tests on Linux AMD64.

Alternative implementation suggestion PR (in draft state) https://github.com/openjdk/jdk/pull/29094

Includes also a solution to [JDK-8373257](https://bugs.openjdk.org/browse/JDK-8373257)
@tstuefe
 
Please take a look, and also if you can, submit for testing on your platforms.

Markus

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

PR Comment: https://git.openjdk.org/jdk/pull/28563#issuecomment-3719105625

From kbarrett at openjdk.org  Wed Jan  7 14:24:37 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 7 Jan 2026 14:24:37 GMT
Subject: RFR: 8374328: Convert simple AtomicAccess uses in gc/shared to use
 Atomic<T> [v3]
In-Reply-To: <RJp0KKg8demYMWOXkrVs1g_jitLhTsvce6ZFO98ihNw=.2c8e0a03-d56a-450e-91c8-019931a717b8@github.com>
References: <RJp0KKg8demYMWOXkrVs1g_jitLhTsvce6ZFO98ihNw=.2c8e0a03-d56a-450e-91c8-019931a717b8@github.com>
Message-ID: <4xK-xF1D4khPfnCGygZ2pLN1SVwdVpjcvPeAl0ZUEOk=.a2de074b-192f-4129-9cf7-da5b7bd347b4@github.com>

> Please review these fairly simple changes to code in gc/shared to use
> `Atomic<T>` instead of directly using `AtomicAccess`.
> 
> This change doesn't eliminate all remaining direct uses of `AtomicAccess` in
> that directory; there are still a few uses that seem less simple, and maybe
> some that should stay with direct `AtomicAccess`.
> 
> The changes are grouped into a series of commits, as a potential aid to reviewers.
> 
> Testing: mach5 tier1-5

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

 - Merge branch 'master' into simple-gc-shared-atomic
 - update copyrights
 - pretouch
 - WorkerThread control
 - SuspendibleThreadSet control
 - GCLocker control
 - ConcurrentGCThread termination protocol
 - DeoptimizeNMethodBarriersALot gating counter

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28987/files
  - new: https://git.openjdk.org/jdk/pull/28987/files/ad121490..c07dae40

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

  Stats: 20206 lines in 1812 files changed: 4190 ins; 2467 del; 13549 mod
  Patch: https://git.openjdk.org/jdk/pull/28987.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28987/head:pull/28987

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

From kbarrett at openjdk.org  Wed Jan  7 14:24:40 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 7 Jan 2026 14:24:40 GMT
Subject: RFR: 8374328: Convert simple AtomicAccess uses in gc/shared to use
 Atomic<T> [v2]
In-Reply-To: <v9Tu6qQxUh2-pYRMW-UfXDR-GZOCUT2ZjT1m5H79Xq0=.74d04a3e-49b8-44b6-8643-5a075ebb01f8@github.com>
References: <RJp0KKg8demYMWOXkrVs1g_jitLhTsvce6ZFO98ihNw=.2c8e0a03-d56a-450e-91c8-019931a717b8@github.com>
 <eKtPNvQBTPlQk_hCJrcWWv98vVwtuQ-7s1F5CDAbcUU=.7f8592f1-8a3e-4c96-bb26-9aab7eddf9a2@github.com>
 <v9Tu6qQxUh2-pYRMW-UfXDR-GZOCUT2ZjT1m5H79Xq0=.74d04a3e-49b8-44b6-8643-5a075ebb01f8@github.com>
Message-ID: <YbGsa1LQvtEokUOQ2OwUYyh98qjUQY1p3TRketCWV6M=.b1a7c353-5a8c-4350-9a39-ec6137017fae@github.com>

On Wed, 7 Jan 2026 08:15:34 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update copyrights
>
> Marked as reviewed by tschatzl (Reviewer).

Fixed merge conflict in copyright header date in gcLocker.hpp.  Needs re-review @tschatzl and @dholmes-ora

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

PR Comment: https://git.openjdk.org/jdk/pull/28987#issuecomment-3719101069

From mdoerr at openjdk.org  Wed Jan  7 16:38:49 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 7 Jan 2026 16:38:49 GMT
Subject: RFR: 8372754: Add wrapper for <cstdlib> [v5]
In-Reply-To: <WBkCjB_bDLQZVlxLJc9iKEonJ-fM15p-4sYddrUXm2w=.b576ae8c-1984-4dd6-b432-d82a1457f6c0@github.com>
References: <7QNN5i5DkBH7c9YXWh5U40JwTKmiBPJSAcLm-f1HE_8=.9b18027e-8274-46d1-ba2d-e70514c40fc3@github.com>
 <WBkCjB_bDLQZVlxLJc9iKEonJ-fM15p-4sYddrUXm2w=.b576ae8c-1984-4dd6-b432-d82a1457f6c0@github.com>
Message-ID: <6a3F4iP79lL5K41emokPCcv9n_mYZ44sTgV6r2MWrJ8=.5382828b-dc4a-4f7e-a605-de2cc5964413@github.com>

On Mon, 5 Jan 2026 19:32:13 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change that adds a HotSpot wrapper for <cstdlib>.  It also
>> includes the forbidden function declarations for functions declared there,
>> moving them from forbiddenFunctions.hpp and friends.
>> 
>> The AIX-specific workaround for its macro-based renaming of malloc/calloc is
>> also moved to this wrapper, so there is a single location for it. Also cleaned
>> it up a bit, based on further investigation of the problem.
>> 
>> Also changed uses of `<cstdlib>` and `<stdlib.h>` to include the wrapper instead.
>> There are still a couple of includes of `<stdlib.h>` in the hotspot directory,
>> because they can't use the hotspot wrapper: os/windows/include/jvm_md.h and
>> share/adlc/adlc.hpp.  I looked at removing the one in windows jvm_md.h, but
>> there are a lot of dependencies on that implicit include in non-HotSpot code.
>> 
>> While updating to use the wrapper, I also did a small amount of include
>> cleanup here and there.  The changes around immediate_aarch64.hpp are perhaps
>> a little less trivial than I should have made here.
>> 
>> Testing: mach5 tier1
>> 
>> This should probably be retested by aix port maintainer folks, although I
>> don't think I made any relevant changes since you last tested it.
>> 
>> This change also resolves:
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into wrap-cstdlib
>  - update copyrights
>  - Merge branch 'master' into wrap-cstdlib
>  - tschatzl review
>  - Merge branch 'master' into wrap-cstdlib
>  - add wrapper for <cstdlib>

I like the new solution more than the old one. Thanks for doing it!

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28562#pullrequestreview-3635731452

From vpaprotski at openjdk.org  Wed Jan  7 17:52:50 2026
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Wed, 7 Jan 2026 17:52:50 GMT
Subject: RFR: 8374570: Assertion failure in ClearArray.java  with
 -XX:+EnableX86EcoreOpts [v2]
In-Reply-To: <Ktp_W59MQVNSQ6YyBicFyIGJpb3SH7hPyjMuWIm2uUY=.795faf4d-5111-43e0-9fc7-91426382615f@github.com>
References: <Ktp_W59MQVNSQ6YyBicFyIGJpb3SH7hPyjMuWIm2uUY=.795faf4d-5111-43e0-9fc7-91426382615f@github.com>
Message-ID: <FEuG-Xpwg_YlcUIKzXM1hThmJdoHOieMFzFr_qMAfko=.9c93b42b-0c79-4650-98f6-3d86f982693a@github.com>

> Allow for a larger jump distance

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

 - whitespace
 - add test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29070/files
  - new: https://git.openjdk.org/jdk/pull/29070/files/a4074e43..389393a7

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

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

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

From vpaprotski at openjdk.org  Wed Jan  7 17:52:51 2026
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Wed, 7 Jan 2026 17:52:51 GMT
Subject: RFR: 8374570: Assertion failure in ClearArray.java  with
 -XX:+EnableX86EcoreOpts [v2]
In-Reply-To: <FmkJw3u9E93aNWMm-a5QDIdnhtYV60r4qwmmQED3OAY=.af52c857-9394-40c5-abb5-1a646154231d@github.com>
References: <Ktp_W59MQVNSQ6YyBicFyIGJpb3SH7hPyjMuWIm2uUY=.795faf4d-5111-43e0-9fc7-91426382615f@github.com>
 <FmkJw3u9E93aNWMm-a5QDIdnhtYV60r4qwmmQED3OAY=.af52c857-9394-40c5-abb5-1a646154231d@github.com>
Message-ID: <IbbtNqgXudkL61u7gx6uw-bN7JUqTdmmg1kr4NCDttw=.7a5b2070-4c35-49d0-bc88-229c4d68e1f2@github.com>

On Wed, 7 Jan 2026 07:28:07 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - whitespace
>>  - add test
>
> Could you please add a regression test?

@TobiHartmann done. I think. Have a look? Test location could be better..

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

PR Comment: https://git.openjdk.org/jdk/pull/29070#issuecomment-3720039387

From duke at openjdk.org  Wed Jan  7 17:57:40 2026
From: duke at openjdk.org (jonghoonpark)
Date: Wed, 7 Jan 2026 17:57:40 GMT
Subject: RFR: 8372040: Remove Prefetch header vs inline header separation
Message-ID: <hOeaeFbD4gZoe74hyGLWmabC4W4PWuyd7IM0imO4MrU=.555401d0-b3da-4e2a-85dd-2758b3912d70@github.com>

related jira issue: https://bugs.openjdk.org/browse/JDK-8372040

---

## Changes

- Merged `prefetch.hpp` into `prefetch.inline.hpp` and removed the redundant `prefetch.hpp`. Updated all call sites accordingly.
- Removed `runtime/prefetch.inline.hpp` from `generation.hpp` to adhere to the rule that standard headers should not include inline headers.
    - Added the inclusion of `runtime/prefetch.inline.hpp` to `cardTableRS.cpp` instead.
- Removed `runtime/prefetch.hpp` from `g1YoungGCPostEvacuateTasks.cpp` as it is already included via `g1HeapRegion.inline.hpp`.

---

Verified with tier1 testing; no regressions found.

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

Commit messages:
 - Merge prefetch.hpp into prefetch.inline.hpp and cleanup dependencies

Changes: https://git.openjdk.org/jdk/pull/29096/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29096&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372040
  Stats: 103 lines in 18 files changed: 17 ins; 68 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/29096.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29096/head:pull/29096

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

From kbarrett at openjdk.org  Wed Jan  7 18:54:39 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 7 Jan 2026 18:54:39 GMT
Subject: RFR: 8372040: Remove Prefetch header vs inline header separation
In-Reply-To: <hOeaeFbD4gZoe74hyGLWmabC4W4PWuyd7IM0imO4MrU=.555401d0-b3da-4e2a-85dd-2758b3912d70@github.com>
References: <hOeaeFbD4gZoe74hyGLWmabC4W4PWuyd7IM0imO4MrU=.555401d0-b3da-4e2a-85dd-2758b3912d70@github.com>
Message-ID: <sW-CJx7cJpHBtmRhIin5hr1muAS-t-Q6H3_dYkrhV7Q=.64cdb246-eff8-4046-b97d-264e2e8fedda@github.com>

On Wed, 7 Jan 2026 17:47:47 GMT, jonghoonpark <duke at openjdk.org> wrote:

> related jira issue: https://bugs.openjdk.org/browse/JDK-8372040
> 
> ---
> 
> ## Changes
> 
> - Merged `prefetch.hpp` into `prefetch.inline.hpp` and removed the redundant `prefetch.hpp`. Updated all call sites accordingly.
> - Removed `runtime/prefetch.inline.hpp` from `generation.hpp` to adhere to the rule that standard headers should not include inline headers.
>     - Added the inclusion of `runtime/prefetch.inline.hpp` to `cardTableRS.cpp` instead.
> - Removed `runtime/prefetch.hpp` from `g1YoungGCPostEvacuateTasks.cpp` as it is already included via `g1HeapRegion.inline.hpp`.
> 
> ---
> 
> Verified with tier1 testing; no regressions found.

Changes requested by kbarrett (Reviewer).

src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp line 49:

> 47: #include "oops/compressedOops.inline.hpp"
> 48: #include "oops/oop.inline.hpp"
> 49: #include "runtime/prefetch.hpp"

This file uses Prefetch, so should be including the inline header.

[from the PR description]
> Removed runtime/prefetch.hpp from g1YoungGCPostEvacuateTasks.cpp as it is already included via g1HeapRegion.inline.hpp.

We prefer being explicit about inclusions ("Include What You Use") rather than depending on
indirect inclusions like that, that break things when one refactors the indirect source of the
include.  There's an open JBS issue for updating the HotSpot Style Guide for this:
https://bugs.openjdk.org/browse/JDK-8252896.
Lots of violations, but please don't knowingly add them.  It would help a lot if we had tooling
support.

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

PR Review: https://git.openjdk.org/jdk/pull/29096#pullrequestreview-3636287122
PR Review Comment: https://git.openjdk.org/jdk/pull/29096#discussion_r2669656101

From duke at openjdk.org  Wed Jan  7 19:04:19 2026
From: duke at openjdk.org (jonghoonpark)
Date: Wed, 7 Jan 2026 19:04:19 GMT
Subject: RFR: 8372040: Remove Prefetch header vs inline header separation
In-Reply-To: <sW-CJx7cJpHBtmRhIin5hr1muAS-t-Q6H3_dYkrhV7Q=.64cdb246-eff8-4046-b97d-264e2e8fedda@github.com>
References: <hOeaeFbD4gZoe74hyGLWmabC4W4PWuyd7IM0imO4MrU=.555401d0-b3da-4e2a-85dd-2758b3912d70@github.com>
 <sW-CJx7cJpHBtmRhIin5hr1muAS-t-Q6H3_dYkrhV7Q=.64cdb246-eff8-4046-b97d-264e2e8fedda@github.com>
Message-ID: <HDML-4EF_0bRpQ8Ib8BbdfjwyOOnTt7P1Qi0ONYfbzI=.492fc22d-8265-4295-a5aa-9bf856084761@github.com>

On Wed, 7 Jan 2026 18:37:08 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> related jira issue: https://bugs.openjdk.org/browse/JDK-8372040
>> 
>> ---
>> 
>> ## Changes
>> 
>> - Merged `prefetch.hpp` into `prefetch.inline.hpp` and removed the redundant `prefetch.hpp`. Updated all call sites accordingly.
>> - Removed `runtime/prefetch.inline.hpp` from `generation.hpp` to adhere to the rule that standard headers should not include inline headers.
>>     - Added the inclusion of `runtime/prefetch.inline.hpp` to `cardTableRS.cpp` instead.
>> - Removed `runtime/prefetch.hpp` from `g1YoungGCPostEvacuateTasks.cpp` as it is already included via `g1HeapRegion.inline.hpp`.
>> 
>> ---
>> 
>> Verified with tier1 testing; no regressions found.
>
> src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp line 49:
> 
>> 47: #include "oops/compressedOops.inline.hpp"
>> 48: #include "oops/oop.inline.hpp"
>> 49: #include "runtime/prefetch.hpp"
> 
> This file uses Prefetch, so should be including the inline header.
> 
> [from the PR description]
>> Removed runtime/prefetch.hpp from g1YoungGCPostEvacuateTasks.cpp as it is already included via g1HeapRegion.inline.hpp.
> 
> We prefer being explicit about inclusions ("Include What You Use") rather than depending on
> indirect inclusions like that, that break things when one refactors the indirect source of the
> include.  There's an open JBS issue for updating the HotSpot Style Guide for this:
> https://bugs.openjdk.org/browse/JDK-8252896.
> Lots of violations, but please don't knowingly add them.  It would help a lot if we had tooling
> support.

@kimbarrett Thank you for your feedback.

Understood.

Since `prefetch.hpp` has been merged into `prefetch.inline.hpp`, I will update to explicitly include `prefetch.inline.hpp`

Does this approach align with what you have in mind?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29096#discussion_r2669731103

From shade at openjdk.org  Wed Jan  7 19:06:02 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 7 Jan 2026 19:06:02 GMT
Subject: RFR: 8373266: Strengthen constant CardTable base accesses [v2]
In-Reply-To: <k38G94Tpq-aEKy5qzf8vaCMgcn0KHYw4JTWm0-RWgIQ=.5da23c7e-d826-41c2-b42f-ec2a90fd2213@github.com>
References: <k38G94Tpq-aEKy5qzf8vaCMgcn0KHYw4JTWm0-RWgIQ=.5da23c7e-d826-41c2-b42f-ec2a90fd2213@github.com>
Message-ID: <gIc95B0VF5sGO0Z6sBX0JE_OLvGNJR77URZFe_vKfpo=.ed0142a9-67ff-4f94-a6ad-1bb8b0104c6c@github.com>

> Shenandoah and G1 are using CardTable for most of its infrastructure, but flip the card tables as they go, and maintain the actual card table reference in TLS. As such, accessing card table base from assembler and compilers runs into risk of accidentally encoding the wrong card table base in generated code. 
> 
> Most of the current code avoids this trouble by carefully implementing their GC barriers to avoid touching shared parts where card table base constness is assumed. _Except_ for JVMCI, that reads the card table base for G1 barrier set, and that is wrong. The JVMCI users would need to rectify this downstream.
> 
> Shenandoah added a few asserts to catch these errors:
>  SHENANDOAHGC_ONLY(assert(!UseShenandoahGC, "Shenandoah byte_map_base is not constant.");)
> 
> ...but G1 would also benefit from the similar safety mechanism.
> 
> This PR strengthens the code to prevent future accidents.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc`
>  - [x] Linux x86_64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z
>  - [x] Linux AArch64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z
>  - [x] GHA, cross-compilation only

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

 - Merge branch 'master' into JDK-8373266-cardtable-asserts
 - Another build fix
 - Fix Minimal builds
 - Shenandoah non-generational can have nullptr card table
 - Also simplify CTBS builder
 - CI should also mention "const"
 - Fix JVMCI by answering proper things
 - Merge branch 'master' into JDK-8373266-cardtable-asserts
 - More fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28703/files
  - new: https://git.openjdk.org/jdk/pull/28703/files/26b6b071..040a84d7

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

  Stats: 25810 lines in 2653 files changed: 14810 ins; 3456 del; 7544 mod
  Patch: https://git.openjdk.org/jdk/pull/28703.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28703/head:pull/28703

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

From shade at openjdk.org  Wed Jan  7 19:06:03 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 7 Jan 2026 19:06:03 GMT
Subject: RFR: 8373266: Strengthen constant CardTable base accesses
In-Reply-To: <k38G94Tpq-aEKy5qzf8vaCMgcn0KHYw4JTWm0-RWgIQ=.5da23c7e-d826-41c2-b42f-ec2a90fd2213@github.com>
References: <k38G94Tpq-aEKy5qzf8vaCMgcn0KHYw4JTWm0-RWgIQ=.5da23c7e-d826-41c2-b42f-ec2a90fd2213@github.com>
Message-ID: <M83l3TCTQ7HeaAsRbZq4Pf2Pru1kleOJdfZQ9v9EaV0=.d8b55ccf-9c55-40cd-94e0-cbe3de3d2ca6@github.com>

On Mon, 8 Dec 2025 18:45:04 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Shenandoah and G1 are using CardTable for most of its infrastructure, but flip the card tables as they go, and maintain the actual card table reference in TLS. As such, accessing card table base from assembler and compilers runs into risk of accidentally encoding the wrong card table base in generated code. 
> 
> Most of the current code avoids this trouble by carefully implementing their GC barriers to avoid touching shared parts where card table base constness is assumed. _Except_ for JVMCI, that reads the card table base for G1 barrier set, and that is wrong. The JVMCI users would need to rectify this downstream.
> 
> Shenandoah added a few asserts to catch these errors:
>  SHENANDOAHGC_ONLY(assert(!UseShenandoahGC, "Shenandoah byte_map_base is not constant.");)
> 
> ...but G1 would also benefit from the similar safety mechanism.
> 
> This PR strengthens the code to prevent future accidents.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc`
>  - [x] Linux x86_64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z
>  - [x] Linux AArch64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z
>  - [x] GHA, cross-compilation only

Still waiting for reviews. @tschatzl, you might be interested in this from G1 side.

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

PR Comment: https://git.openjdk.org/jdk/pull/28703#issuecomment-3720310765

From psandoz at openjdk.org  Wed Jan  7 20:25:31 2026
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 7 Jan 2026 20:25:31 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v9]
In-Reply-To: <tRwCEAHLj8beRKhrrlMdf3Ng0iDe6YnJYcbvWNyvxRE=.d2da523d-8f57-4554-a3e3-0604e05fd214@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <tRwCEAHLj8beRKhrrlMdf3Ng0iDe6YnJYcbvWNyvxRE=.d2da523d-8f57-4554-a3e3-0604e05fd214@github.com>
Message-ID: <3PzPbEnPapV-B3OenjmG6paXsyLFayh33S-f0IBI-LY=.773757f6-c9e0-48ac-b89d-aa81fd6b47f8@github.com>

On Wed, 17 Dec 2025 12:56:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
>> - Add necessary inline expander support.
>>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
>> - Use existing Float16 vector IR and backend support.
>> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>>  
>> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
>> 
>> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
>> 
>> <img width="1344" height="532" alt="image" src="https://github.com/user-attachments/assets/c8157c3c-22b0-4bc1-9de9-7a68cadb7b2a" />
>> 
>> Initial RFP[1] was floated on the panama-dev mailing list.
>> 
>> Kindly review the draft PR and share your feedback.
>> 
>> Best Regards,
>> Jatin
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:
> 
>  - Fix from Bhavana Kilambi for failing JTREG regressions on AARCH64
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
>  - Including test changes from Bhavana Kilambi (ARM)
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
>  - Optimizing tail handling
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
>  - Cleanups
>  - Fix failing jtreg test in CI
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
>  - Cleanups
>  - ... and 13 more: https://git.openjdk.org/jdk/compare/5e7ae281...703f313d

Just some quick comments for now. I think this is better heading in the right direction.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractSpecies.java line 436:

> 434:                 } else {
> 435:                     assert(Float16.valueOf(i).intValue() == i);
> 436:                 }

It would be clearer if the same pattern is copied as for the other types. Assign and assert, no need to check bounds. We don't need to be performant here. (This code may become even clearer when we can leverage patterns on the primitive types and custom numeric types.)

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Vector.java line 3083:

> 3081:      * @return a {@code Float16Vector} with the same shape and information content
> 3082:      */
> 3083:     public abstract Float16Vector reinterpretAsFloat16s();

At some point we should consider consolidating these methods into one which accepts the lane element type as an argument.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorShape.java line 277:

> 275:         if (etype == Float16.class) {
> 276:             etype = short.class;
> 277:         }

My suggestion may not worth it, but i was wondering if we could get the lane type and then use the carrier type, rather then encoding this more specifically.

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

PR Review: https://git.openjdk.org/jdk/pull/28002#pullrequestreview-3636482293
PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2669808367
PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2669818576
PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2669827315

From stefank at openjdk.org  Wed Jan  7 20:34:33 2026
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 7 Jan 2026 20:34:33 GMT
Subject: RFR: 8372040: Remove Prefetch header vs inline header separation
In-Reply-To: <hOeaeFbD4gZoe74hyGLWmabC4W4PWuyd7IM0imO4MrU=.555401d0-b3da-4e2a-85dd-2758b3912d70@github.com>
References: <hOeaeFbD4gZoe74hyGLWmabC4W4PWuyd7IM0imO4MrU=.555401d0-b3da-4e2a-85dd-2758b3912d70@github.com>
Message-ID: <w_RZoWY5LKzRdqfBws0Y60RnJx9o_Z6pDRKTqr20_TU=.0a92adbb-f6c0-4c7b-bc30-70a2b6a2f2eb@github.com>

On Wed, 7 Jan 2026 17:47:47 GMT, jonghoonpark <duke at openjdk.org> wrote:

> related jira issue: https://bugs.openjdk.org/browse/JDK-8372040
> 
> ---
> 
> ## Changes
> 
> - Merged `prefetch.hpp` into `prefetch.inline.hpp` and removed the redundant `prefetch.hpp`. Updated all call sites accordingly.
> - Removed `runtime/prefetch.inline.hpp` from `generation.hpp` to adhere to the rule that standard headers should not include inline headers.
>     - Added the inclusion of `runtime/prefetch.inline.hpp` to `cardTableRS.cpp` instead.
> - Removed `runtime/prefetch.hpp` from `g1YoungGCPostEvacuateTasks.cpp` as it is already included via `g1HeapRegion.inline.hpp`.
> 
> ---
> 
> Verified with tier1 testing; no regressions found.

While looking at this one thing strikes me: with this change the platform-dependent .inline.hpp now stops being compilable stand-alone. That makes those files more obscure to read.

If we take a look at what the file looked like before this PR:

#ifndef OS_CPU_LINUX_X86_PREFETCH_LINUX_X86_INLINE_HPP
#define OS_CPU_LINUX_X86_PREFETCH_LINUX_X86_INLINE_HPP

include "runtime/prefetch.hpp"

inline void Prefetch::read (const void *loc, intx interval) {
...
}

inline void Prefetch::write(void *loc, intx interval) {
...
}

#endif // OS_CPU_LINUX_X86_PREFETCH_LINUX_X86_INLINE_HPP


Then a newcomer could read this and see that the structure made sense and that the class Prefetch came from the include of prefetch.hpp.

If we now look at the code after the PR:

#ifndef OS_CPU_LINUX_X86_PREFETCH_LINUX_X86_INLINE_HPP
#define OS_CPU_LINUX_X86_PREFETCH_LINUX_X86_INLINE_HPP

inline void Prefetch::read (const void *loc, intx interval) {
...
}

inline void Prefetch::write(void *loc, intx interval) {
...
}

#endif // OS_CPU_LINUX_X86_PREFETCH_LINUX_X86_INLINE_HPP


then I wouldn't be surprised if the casual reader would go "wait, what, where does the class Prefetch come from?".

I'm not convinced (yet) that this is a change that we want. I read the RFE report for this, but I'm not sure I understand the real motivation for this change. From the RFE it sounds like just removing the errant include in generation.hpp would be good enough.

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

PR Comment: https://git.openjdk.org/jdk/pull/29096#issuecomment-3720659662

From kbarrett at openjdk.org  Wed Jan  7 22:25:00 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 7 Jan 2026 22:25:00 GMT
Subject: RFR: 8372754: Add wrapper for <cstdlib> [v2]
In-Reply-To: <mX5HpK_uECRN_mnmu4yu1H1GT_Yfp24JhxS_tkXeYCg=.00784e86-4701-43c3-b46c-df7a1df5a262@github.com>
References: <7QNN5i5DkBH7c9YXWh5U40JwTKmiBPJSAcLm-f1HE_8=.9b18027e-8274-46d1-ba2d-e70514c40fc3@github.com>
 <cphviQVoQ7e5Qsupc5SAHZk9fSW-CTU6l1M5bxHNSNo=.e03193a9-8674-48b1-9d74-210a93c0e381@github.com>
 <mX5HpK_uECRN_mnmu4yu1H1GT_Yfp24JhxS_tkXeYCg=.00784e86-4701-43c3-b46c-df7a1df5a262@github.com>
Message-ID: <0_xVjkUW98WQE5w75T-gJeEuxn27IrTbCxTAoPDe3Hw=.8c605a25-04d4-4ac8-8dfd-37228eacd0e2@github.com>

On Tue, 16 Dec 2025 10:08:09 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into wrap-cstdlib
>>  - add wrapper for <cstdlib>
>
> Marked as reviewed by tschatzl (Reviewer).

Thanks for reviews @tschatzl and @TheRealMDoerr

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

PR Comment: https://git.openjdk.org/jdk/pull/28562#issuecomment-3721063324

From kbarrett at openjdk.org  Wed Jan  7 22:27:55 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 7 Jan 2026 22:27:55 GMT
Subject: Integrated: 8372754: Add wrapper for <cstdlib>
In-Reply-To: <7QNN5i5DkBH7c9YXWh5U40JwTKmiBPJSAcLm-f1HE_8=.9b18027e-8274-46d1-ba2d-e70514c40fc3@github.com>
References: <7QNN5i5DkBH7c9YXWh5U40JwTKmiBPJSAcLm-f1HE_8=.9b18027e-8274-46d1-ba2d-e70514c40fc3@github.com>
Message-ID: <oB96oWo1cgob4-OQAdoQNE3xVsLQUX7hKxG7-5GOVYQ=.866ceee0-fbe3-44aa-be98-cc0c3ce41ec9@github.com>

On Sat, 29 Nov 2025 05:09:49 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that adds a HotSpot wrapper for <cstdlib>.  It also
> includes the forbidden function declarations for functions declared there,
> moving them from forbiddenFunctions.hpp and friends.
> 
> The AIX-specific workaround for its macro-based renaming of malloc/calloc is
> also moved to this wrapper, so there is a single location for it. Also cleaned
> it up a bit, based on further investigation of the problem.
> 
> Also changed uses of `<cstdlib>` and `<stdlib.h>` to include the wrapper instead.
> There are still a couple of includes of `<stdlib.h>` in the hotspot directory,
> because they can't use the hotspot wrapper: os/windows/include/jvm_md.h and
> share/adlc/adlc.hpp.  I looked at removing the one in windows jvm_md.h, but
> there are a lot of dependencies on that implicit include in non-HotSpot code.
> 
> While updating to use the wrapper, I also did a small amount of include
> cleanup here and there.  The changes around immediate_aarch64.hpp are perhaps
> a little less trivial than I should have made here.
> 
> Testing: mach5 tier1
> 
> This should probably be retested by aix port maintainer folks, although I
> don't think I made any relevant changes since you last tested it.
> 
> This change also resolves:

This pull request has now been integrated.

Changeset: 9a944e55
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9a944e558733950d135b5a91d093b7a28e934f59
Stats:     252 lines in 34 files changed: 154 ins; 59 del; 39 mod

8372754: Add wrapper for <cstdlib>
8369205: AIX build break in forbiddenFunctions.hpp

Reviewed-by: mdoerr, tschatzl

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

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

From sspitsyn at openjdk.org  Thu Jan  8 00:45:29 2026
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 8 Jan 2026 00:45:29 GMT
Subject: RFR: 6960970: Debugger very slow during stepping [v11]
In-Reply-To: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
References: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
Message-ID: <umGkuNCiL2nogfZNZGv4WnJHxTo0C50tNDuBzkMfeo0=.35e2bbb2-1c1a-435a-8598-118076de4ffa@github.com>

> This change fixes a long standing performance issue related to the debugger single stepping that is using JVMTI `FramePop` events as a part of step over handling. The performance issue is that the target thread continues its execution in very slow `interp-only` mode in a context of frame marked for `FramePop` notification with the JVMTI `NotifyFramePop`. It includes other method calls recursively upon a return from the frame.
> 
> This fix is to avoid enforcing the `interp-only` execution mode for threads when `FramePop` events are enabled with the JVMTI `SetEventNotificationMode()`. Instead, the target frame has been deoptimized and kept interpreted by disabling `OSR` optimization by the function `InterpreterRuntime::frequency_counter_overflow_inner()`. (Big thanks to @fisk for this suggestion!) Additionally, some tweaks are applied in several places where the `java_thread->is_interp_only_mode()` is checked.
> The other details will be provided in the first PR request comment.
> 
> Testing:
>  - test `serviceability/jvmti/vthread/ThreadStateTest` was updated to provide some extra test coverage
>  - submitted mach5 tiers 1-6

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

 - Merge
 - Merge
 - merge: add fragments dropped by incorrect merge
 - merge: fix merge error
 - Merge
 - Merge
 - review: optimize hide_single_stepping and post_method_exit
 - review: renamed two functions; FRAME_POP_BIT removed from INTERP_EVENT_BITS
 - review: fix iteration order in process_vthread_pending_deopts as it uses remove_at(idx)
 - review: fix typo in a EATests.java comment
 - ... and 2 more: https://git.openjdk.org/jdk/compare/9a944e55...08edda18

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

Changes: https://git.openjdk.org/jdk/pull/28407/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28407&range=10
  Stats: 291 lines in 22 files changed: 194 ins; 61 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/28407.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28407/head:pull/28407

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

From jbhateja at openjdk.org  Thu Jan  8 00:48:25 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 8 Jan 2026 00:48:25 GMT
Subject: RFR: 8371955: Support AVX10 floating point comparison instructions
In-Reply-To: <xDRJgBQwsegqBOp50pIl-Mzkadb8U-QpYXxSv01Jaxc=.a4cd1675-eb08-4f08-87be-c7f66a88f37e@github.com>
References: <xDRJgBQwsegqBOp50pIl-Mzkadb8U-QpYXxSv01Jaxc=.a4cd1675-eb08-4f08-87be-c7f66a88f37e@github.com>
Message-ID: <CdtkDrgHPVfwPsgQgHrtxG5hEc_yHuXTwqY40jahbzA=.a3dab93b-ffcf-4cb8-b98d-ba4ef9b94919@github.com>

On Sun, 16 Nov 2025 03:48:31 GMT, Mohamed Issa <missa at openjdk.org> wrote:

> Intel&reg; AVX10 ISA [1] extensions added new floating point comparison instructions. They set the EFLAGS register so that relationships can be tested independently to avoid extra checks when one of the inputs is NaN.
> 
> Most of the work is covered in the architecture definition (`x86.ad`) file. A new comparison operand was created to be used by new CMove and JMP definitions with the APX specific portions of the CMove section being updated to rely on the new instructions because both sets of instructions are always expected to be available on the same platform. New floating point comparison definitions were also added.
> 
> This change uses the new AVX10.2 (UCOMXSS or UCOMXSD) instructions on supported platforms to avoid the extra handling required with existing (UCOMISS or UCOMISD) instructions. To make sure no new failures were introduced, tier1, tier2, and tier3 tests were run on builds with and without the changes. Additionally, the JTREG tests listed below were used to verify correctness with `-XX:-UseAPX` / `-XX:+UseAPX` options. The baseline build used is [OpenJDK v26-b26](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B26).
> 
> 1. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java`
> 2. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFPComparison.java`
> 3. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java`
> 4. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestSignumVector.java`
> 
> Finally, the JMH micro-benchmark listed below was updated to separately exercise CMove and JMP code paths.
> 
> 1. `micro:test/micro/org/openjdk/bench/java/lang/FPComparison.java`
> 
> [1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10

src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp line 2069:

> 2067:       } else {
> 2068:         __ ucomiss(reg1, opr2->as_xmm_float_reg());
> 2069:       }

Please create a new macro assembly routine for this if-else idiom, its getting repeated multiple times.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2579691412

From missa at openjdk.org  Thu Jan  8 00:48:26 2026
From: missa at openjdk.org (Mohamed Issa)
Date: Thu, 8 Jan 2026 00:48:26 GMT
Subject: RFR: 8371955: Support AVX10 floating point comparison instructions
In-Reply-To: <CdtkDrgHPVfwPsgQgHrtxG5hEc_yHuXTwqY40jahbzA=.a3dab93b-ffcf-4cb8-b98d-ba4ef9b94919@github.com>
References: <xDRJgBQwsegqBOp50pIl-Mzkadb8U-QpYXxSv01Jaxc=.a4cd1675-eb08-4f08-87be-c7f66a88f37e@github.com>
 <CdtkDrgHPVfwPsgQgHrtxG5hEc_yHuXTwqY40jahbzA=.a3dab93b-ffcf-4cb8-b98d-ba4ef9b94919@github.com>
Message-ID: <OHJGGJ8NLW6n_fU8onsMm0rncG_WGW1i-HY7mB9A8mM=.2540bab9-d624-4b6f-b868-2ef76d9915af@github.com>

On Tue, 2 Dec 2025 05:59:53 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Intel&reg; AVX10 ISA [1] extensions added new floating point comparison instructions. They set the EFLAGS register so that relationships can be tested independently to avoid extra checks when one of the inputs is NaN.
>> 
>> Most of the work is covered in the architecture definition (`x86.ad`) file. A new comparison operand was created to be used by new CMove and JMP definitions with the APX specific portions of the CMove section being updated to rely on the new instructions because both sets of instructions are always expected to be available on the same platform. New floating point comparison definitions were also added.
>> 
>> This change uses the new AVX10.2 (UCOMXSS or UCOMXSD) instructions on supported platforms to avoid the extra handling required with existing (UCOMISS or UCOMISD) instructions. To make sure no new failures were introduced, tier1, tier2, and tier3 tests were run on builds with and without the changes. Additionally, the JTREG tests listed below were used to verify correctness with `-XX:-UseAPX` / `-XX:+UseAPX` options. The baseline build used is [OpenJDK v26-b26](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B26).
>> 
>> 1. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java`
>> 2. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFPComparison.java`
>> 3. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java`
>> 4. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestSignumVector.java`
>> 
>> Finally, the JMH micro-benchmark listed below was updated to separately exercise CMove and JMP code paths.
>> 
>> 1. `micro:test/micro/org/openjdk/bench/java/lang/FPComparison.java`
>> 
>> [1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10
>
> src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp line 2069:
> 
>> 2067:       } else {
>> 2068:         __ ucomiss(reg1, opr2->as_xmm_float_reg());
>> 2069:       }
> 
> Please create a new macro assembly routine for this if-else idiom, its getting repeated multiple times.

FYI, this portion could be split into a separate PR. However, I created a couple of macros so that you can check and verify if they match what you are thinking of.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2612392221

From missa at openjdk.org  Thu Jan  8 00:48:24 2026
From: missa at openjdk.org (Mohamed Issa)
Date: Thu, 8 Jan 2026 00:48:24 GMT
Subject: RFR: 8371955: Support AVX10 floating point comparison instructions
Message-ID: <xDRJgBQwsegqBOp50pIl-Mzkadb8U-QpYXxSv01Jaxc=.a4cd1675-eb08-4f08-87be-c7f66a88f37e@github.com>

Intel&reg; AVX10 ISA [1] extensions added new floating point comparison instructions. They set the EFLAGS register so that relationships can be tested independently to avoid extra checks when one of the inputs is NaN.

Most of the work is covered in the architecture definition (`x86.ad`) file. A new comparison operand was created to be used by new CMove and JMP definitions with the APX specific portions of the CMove section being updated to rely on the new instructions because both sets of instructions are always expected to be available on the same platform. New floating point comparison definitions were also added.

This change uses the new AVX10.2 (UCOMXSS or UCOMXSD) instructions on supported platforms to avoid the extra handling required with existing (UCOMISS or UCOMISD) instructions. To make sure no new failures were introduced, tier1, tier2, and tier3 tests were run on builds with and without the changes. Additionally, the JTREG tests listed below were used to verify correctness with `-XX:-UseAPX` / `-XX:+UseAPX` options. The baseline build used is [OpenJDK v26-b26](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B26).

1. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java`
2. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFPComparison.java`
3. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java`
4. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestSignumVector.java`

Finally, the JMH micro-benchmark listed below was updated to separately exercise CMove and JMP code paths.

1. `micro:test/micro/org/openjdk/bench/java/lang/FPComparison.java`

[1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10

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

Commit messages:
 - Fix CMove IR tests to account for APX presence
 - Merge branch 'master' into user/missa-prime/avx10_2
 - Update the copyright year in modified files - Happy New Year!
 - Re-introduce two missing UseAPX flag checks in cmov section of x86.ad file
 - Further cmov re-ordering in x86.ad file
 - Re-order cmov definitions for easier review readability
 - Increase measurement iteration duration to 5 seconds in FPComparison.java
 - Correct expensive fixup formatting and use AVX10.2 instructions in new three-way comparison definitions
 - Merge branch 'master' into user/missa-prime/avx10_2
 - Manually resolve conflicts in FPComparion.java
 - ... and 7 more: https://git.openjdk.org/jdk/compare/dd20e915...1e62b5a3

Changes: https://git.openjdk.org/jdk/pull/28337/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28337&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371955
  Stats: 1036 lines in 9 files changed: 852 ins; 92 del; 92 mod
  Patch: https://git.openjdk.org/jdk/pull/28337.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28337/head:pull/28337

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

From missa at openjdk.org  Thu Jan  8 00:48:27 2026
From: missa at openjdk.org (Mohamed Issa)
Date: Thu, 8 Jan 2026 00:48:27 GMT
Subject: RFR: 8371955: Support AVX10 floating point comparison instructions
In-Reply-To: <OHJGGJ8NLW6n_fU8onsMm0rncG_WGW1i-HY7mB9A8mM=.2540bab9-d624-4b6f-b868-2ef76d9915af@github.com>
References: <xDRJgBQwsegqBOp50pIl-Mzkadb8U-QpYXxSv01Jaxc=.a4cd1675-eb08-4f08-87be-c7f66a88f37e@github.com>
 <CdtkDrgHPVfwPsgQgHrtxG5hEc_yHuXTwqY40jahbzA=.a3dab93b-ffcf-4cb8-b98d-ba4ef9b94919@github.com>
 <OHJGGJ8NLW6n_fU8onsMm0rncG_WGW1i-HY7mB9A8mM=.2540bab9-d624-4b6f-b868-2ef76d9915af@github.com>
Message-ID: <wC2chplzoun_m2Kh5qm3lviAxmw14Mw0q38bREJqC6A=.584ac31e-df5c-4c55-b0c2-80af2454d585@github.com>

On Thu, 11 Dec 2025 23:33:41 GMT, Mohamed Issa <missa at openjdk.org> wrote:

>> src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp line 2069:
>> 
>>> 2067:       } else {
>>> 2068:         __ ucomiss(reg1, opr2->as_xmm_float_reg());
>>> 2069:       }
>> 
>> Please create a new macro assembly routine for this if-else idiom, its getting repeated multiple times.
>
> FYI, this portion could be split into a separate PR. However, I created a couple of macros so that you can check and verify if they match what you are thinking of.

I moved the logic out of this PR. I'll create another one containing it that will be linked to [JDK-8373834](https://bugs.openjdk.org/browse/JDK-8373834).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2670502059

From ysuenaga at openjdk.org  Thu Jan  8 01:38:00 2026
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 8 Jan 2026 01:38:00 GMT
Subject: RFR: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is
 incorrectly implemented
In-Reply-To: <hgAyKMzLuFluIKVlWxPAmhx9C-LwKHZF--IclytugAM=.c9e86f72-1147-4720-91e8-1dbf55e3079f@github.com>
References: <SiBemHHhiHk3uDElvjRK16U2SNea7P1wsptA_4z7kxA=.0746951f-41b4-46b4-8397-40603dea6298@github.com>
 <hgAyKMzLuFluIKVlWxPAmhx9C-LwKHZF--IclytugAM=.c9e86f72-1147-4720-91e8-1dbf55e3079f@github.com>
Message-ID: <GbffSdPHPb6t5ZDFE7BxaaoudpAJnlIY9WlCmh9R7go=.69137790-1f34-4e99-b4ed-0af345b81915@github.com>

On Wed, 7 Jan 2026 14:20:34 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> The jtreg test TestEmergencyDumpAtOOM.java runs into the following error on ppc64 platforms.
>> 
>> JFR emergency dump would be kicked at `VMError::report_and_die()`, then Java thread for JFR would not work due to secondary signal handler for error reporting.
>> 
>> Passed all of jdk_jfr tests on Linux AMD64.
>
> Alternative implementation suggestion PR (in draft state) https://github.com/openjdk/jdk/pull/29094
> 
> Includes also a solution to [JDK-8373257](https://bugs.openjdk.org/browse/JDK-8373257)
> @tstuefe
>  
> Please take a look, and also if you can, submit for testing on your platforms.
> 
> Markus

Thanks a lot @mgronlun !
I think JDK-8371014 (and JDK-8373257) should be tackled in #29094 . So should I close this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/28563#issuecomment-3721527637

From duke at openjdk.org  Thu Jan  8 04:46:41 2026
From: duke at openjdk.org (Harshit470250)
Date: Thu, 8 Jan 2026 04:46:41 GMT
Subject: RFR: 8347396: Efficient TypeFunc creations [v4]
In-Reply-To: <VQs3SMtk1y6xTi8nCvTeWsTFfCQlTJtDdCGnfWQmRmw=.f3b33ba1-3efe-477b-b6d2-b43faae9ee2b@github.com>
References: <VQs3SMtk1y6xTi8nCvTeWsTFfCQlTJtDdCGnfWQmRmw=.f3b33ba1-3efe-477b-b6d2-b43faae9ee2b@github.com>
Message-ID: <QWLoZkqqNGsVGaCYPJW5zwHGPbk7zZ2IWWyjw--ZptI=.f7e27433-8c01-4df0-b1e6-3df58ebde966@github.com>

> This PR do similar changes done by [JDK-8330851](https://bugs.openjdk.org/browse/JDK-8330851) on the GC TypeFunc creation as suggested by [JDK-8347396](https://bugs.openjdk.org/browse/JDK-8347396). As discussed in [https://github.com/openjdk/jdk/pull/21782#discussion_r1906535686,](https://github.com/openjdk/jdk/pull/21782#discussion_r1906535686) I have put guard on the shenandoah gc specific part of the code.

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

 - move make_clone to barrierSetC2
 - move make_clone to barrier_stubc2.hpp
 - move clone_type

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27279/files
  - new: https://git.openjdk.org/jdk/pull/27279/files/4dfa36ca..630e4be0

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

  Stats: 52 lines in 4 files changed: 24 ins; 25 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27279.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27279/head:pull/27279

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

From dholmes at openjdk.org  Thu Jan  8 06:23:19 2026
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 8 Jan 2026 06:23:19 GMT
Subject: RFR: 8372040: Remove Prefetch header vs inline header separation
In-Reply-To: <w_RZoWY5LKzRdqfBws0Y60RnJx9o_Z6pDRKTqr20_TU=.0a92adbb-f6c0-4c7b-bc30-70a2b6a2f2eb@github.com>
References: <hOeaeFbD4gZoe74hyGLWmabC4W4PWuyd7IM0imO4MrU=.555401d0-b3da-4e2a-85dd-2758b3912d70@github.com>
 <w_RZoWY5LKzRdqfBws0Y60RnJx9o_Z6pDRKTqr20_TU=.0a92adbb-f6c0-4c7b-bc30-70a2b6a2f2eb@github.com>
Message-ID: <Z5vjnxsOfm0fzy_poNgiyFgFHf7uBkLO9NztqG8wfvU=.ab8e3d55-cde0-49f3-9d0b-c8b0a353c8f9@github.com>

On Wed, 7 Jan 2026 20:30:18 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>  I wouldn't be surprised if the casual reader would go "wait, what, where does the class Prefetch come from?"

Is that any different to looking in, for example,  the platform dependent os_XXX.cpp and wondering where the class OS comes from?

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

PR Comment: https://git.openjdk.org/jdk/pull/29096#issuecomment-3722224445

From dholmes at openjdk.org  Thu Jan  8 07:31:26 2026
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 8 Jan 2026 07:31:26 GMT
Subject: RFR: 8374328: Convert simple AtomicAccess uses in gc/shared to use
 Atomic<T> [v3]
In-Reply-To: <4xK-xF1D4khPfnCGygZ2pLN1SVwdVpjcvPeAl0ZUEOk=.a2de074b-192f-4129-9cf7-da5b7bd347b4@github.com>
References: <RJp0KKg8demYMWOXkrVs1g_jitLhTsvce6ZFO98ihNw=.2c8e0a03-d56a-450e-91c8-019931a717b8@github.com>
 <4xK-xF1D4khPfnCGygZ2pLN1SVwdVpjcvPeAl0ZUEOk=.a2de074b-192f-4129-9cf7-da5b7bd347b4@github.com>
Message-ID: <01TjzVoQfydIB1hGUPH4BdIEQoxYa42GV8mQJ-h7-_M=.3e50e251-e2ea-40b7-a11b-147519817936@github.com>

On Wed, 7 Jan 2026 14:24:37 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review these fairly simple changes to code in gc/shared to use
>> `Atomic<T>` instead of directly using `AtomicAccess`.
>> 
>> This change doesn't eliminate all remaining direct uses of `AtomicAccess` in
>> that directory; there are still a few uses that seem less simple, and maybe
>> some that should stay with direct `AtomicAccess`.
>> 
>> The changes are grouped into a series of commits, as a potential aid to reviewers.
>> 
>> Testing: mach5 tier1-5
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'master' into simple-gc-shared-atomic
>  - update copyrights
>  - pretouch
>  - WorkerThread control
>  - SuspendibleThreadSet control
>  - GCLocker control
>  - ConcurrentGCThread termination protocol
>  - DeoptimizeNMethodBarriersALot gating counter

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28987#pullrequestreview-3638113084

From shade at openjdk.org  Thu Jan  8 08:27:13 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 8 Jan 2026 08:27:13 GMT
Subject: RFR: 8372754: Add wrapper for <cstdlib> [v5]
In-Reply-To: <WBkCjB_bDLQZVlxLJc9iKEonJ-fM15p-4sYddrUXm2w=.b576ae8c-1984-4dd6-b432-d82a1457f6c0@github.com>
References: <7QNN5i5DkBH7c9YXWh5U40JwTKmiBPJSAcLm-f1HE_8=.9b18027e-8274-46d1-ba2d-e70514c40fc3@github.com>
 <WBkCjB_bDLQZVlxLJc9iKEonJ-fM15p-4sYddrUXm2w=.b576ae8c-1984-4dd6-b432-d82a1457f6c0@github.com>
Message-ID: <wuxAcOxDkik7lfKRx6WREQhyT6O4113vn0W3kuQNr60=.9f19ba01-c131-4251-87ab-7d3100f96f04@github.com>

On Mon, 5 Jan 2026 19:32:13 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change that adds a HotSpot wrapper for <cstdlib>.  It also
>> includes the forbidden function declarations for functions declared there,
>> moving them from forbiddenFunctions.hpp and friends.
>> 
>> The AIX-specific workaround for its macro-based renaming of malloc/calloc is
>> also moved to this wrapper, so there is a single location for it. Also cleaned
>> it up a bit, based on further investigation of the problem.
>> 
>> Also changed uses of `<cstdlib>` and `<stdlib.h>` to include the wrapper instead.
>> There are still a couple of includes of `<stdlib.h>` in the hotspot directory,
>> because they can't use the hotspot wrapper: os/windows/include/jvm_md.h and
>> share/adlc/adlc.hpp.  I looked at removing the one in windows jvm_md.h, but
>> there are a lot of dependencies on that implicit include in non-HotSpot code.
>> 
>> While updating to use the wrapper, I also did a small amount of include
>> cleanup here and there.  The changes around immediate_aarch64.hpp are perhaps
>> a little less trivial than I should have made here.
>> 
>> Testing: mach5 tier1
>> 
>> This should probably be retested by aix port maintainer folks, although I
>> don't think I made any relevant changes since you last tested it.
>> 
>> This change also resolves:
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into wrap-cstdlib
>  - update copyrights
>  - Merge branch 'master' into wrap-cstdlib
>  - tschatzl review
>  - Merge branch 'master' into wrap-cstdlib
>  - add wrapper for <cstdlib>

Fails S390X build now: https://github.com/openjdk/jdk/pull/29109. There is a reason why GHA includes some light cross-compilation jobs :)

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

PR Comment: https://git.openjdk.org/jdk/pull/28562#issuecomment-3722752720

From stefank at openjdk.org  Thu Jan  8 09:19:39 2026
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 8 Jan 2026 09:19:39 GMT
Subject: RFR: 8372040: Remove Prefetch header vs inline header separation
In-Reply-To: <Z5vjnxsOfm0fzy_poNgiyFgFHf7uBkLO9NztqG8wfvU=.ab8e3d55-cde0-49f3-9d0b-c8b0a353c8f9@github.com>
References: <hOeaeFbD4gZoe74hyGLWmabC4W4PWuyd7IM0imO4MrU=.555401d0-b3da-4e2a-85dd-2758b3912d70@github.com>
 <w_RZoWY5LKzRdqfBws0Y60RnJx9o_Z6pDRKTqr20_TU=.0a92adbb-f6c0-4c7b-bc30-70a2b6a2f2eb@github.com>
 <Z5vjnxsOfm0fzy_poNgiyFgFHf7uBkLO9NztqG8wfvU=.ab8e3d55-cde0-49f3-9d0b-c8b0a353c8f9@github.com>
Message-ID: <RYqQGOB6JulwdN6WUiAgJ9_2BUU-hkEBgPwgMZFsiX8=.330ab213-94bd-4b79-a816-81674e321edd@github.com>

On Thu, 8 Jan 2026 06:20:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > I wouldn't be surprised if the casual reader would go "wait, what, where does the class Prefetch come from?"
> 
> Is that any different to looking in, for example, the platform dependent os_XXX.cpp and wondering where the class OS comes from?

I think think that the os_XXX.cpp file is different. It has implicit includes all the way to the os.hpp file which defines the OS class:

os_linux.cpp:
. #include "os_linux.inline.hpp" 
.. #include "os_linux.hpp"
... #include "runtime/os.hpp"


Maybe a better example would be orderAccess_linux_x86.hpp, which has a similar layout. In that file we have this comment that shows that this is an odd file compared to most files:


#ifndef OS_CPU_LINUX_X86_ORDERACCESS_LINUX_X86_HPP
#define OS_CPU_LINUX_X86_ORDERACCESS_LINUX_X86_HPP

// Included in orderAccess.hpp header file.


Here we have an orderAccess.hpp and not an orderAccess.inline.hpp. The reason for that is that so much code is currently using the OrderAccess API from headers.

While looking at this I wonder if we couldn't get both wishes by adding an explicit include to prefetch.inline.hpp and relying on the include guards to sort out the circular dependencies:

prefetch.inline.hpp:

#ifndef SHARE_RUNTIME_PREFETCH_INLINE_HPP
#define SHARE_RUNTIME_PREFETCH_INLINE_HPP

class Prefetch {...};

#include OS_CPU_HEADER_INLINE(prefetch)

#endif // SHARE_RUNTIME_PREFETCH_INLINE_HPP


prefetch_linux_x86.inline.hpp:

#ifndef OS_CPU_LINUX_X86_PREFETCH_LINUX_X86_INLINE_HPP
#define OS_CPU_LINUX_X86_PREFETCH_LINUX_X86_INLINE_HPP

#include "runtime/prefetch.inline.hpp"

... implementation of class Prefetch 

#endif // OS_CPU_LINUX_X86_PREFETCH_LINUX_X86_INLINE_HPP


If this works then there not be any mixups of prefetch.hpp vs prefetch.inline.hpp usages (because prefetch.hpp is gone), and at the same time the os_linux_x64.inline.hpp will be complete on its own.

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

PR Comment: https://git.openjdk.org/jdk/pull/29096#issuecomment-3722938306

From vyazici at openjdk.org  Thu Jan  8 09:51:51 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 8 Jan 2026 09:51:51 GMT
Subject: [jdk26] RFR: 8374700: [BACKOUT] Move input validation checks to Java
 for java.lang.StringCoding intrinsics
Message-ID: <VSWSSBWMmja8G_pvHgqm9OIR0-7_6Z1JfNp-cOS5ElU=.bcfa97e6-1c30-4e69-97d2-f8a151ed6d1d@github.com>

Backport of [JDK-8374210] integrated in 7e18de13 by #29055.

[JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210

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

Commit messages:
 - Backport 7e18de137c3b5f08a479af2b64eb22923261900b

Changes: https://git.openjdk.org/jdk/pull/29112/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29112&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374700
  Stats: 437 lines in 23 files changed: 25 ins; 331 del; 81 mod
  Patch: https://git.openjdk.org/jdk/pull/29112.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29112/head:pull/29112

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

From thartmann at openjdk.org  Thu Jan  8 09:59:49 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 8 Jan 2026 09:59:49 GMT
Subject: [jdk26] RFR: 8374210: [BACKOUT] Move input validation checks to
 Java for java.lang.StringCoding intrinsics
In-Reply-To: <VSWSSBWMmja8G_pvHgqm9OIR0-7_6Z1JfNp-cOS5ElU=.bcfa97e6-1c30-4e69-97d2-f8a151ed6d1d@github.com>
References: <VSWSSBWMmja8G_pvHgqm9OIR0-7_6Z1JfNp-cOS5ElU=.bcfa97e6-1c30-4e69-97d2-f8a151ed6d1d@github.com>
Message-ID: <iefzfusRhEPi9CsZ9pcegoBOqImrgaMqZWuFWs_b7bE=.2958237f-b82c-4e9a-85d9-8b61166ba079@github.com>

On Thu, 8 Jan 2026 09:42:58 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Backport of [JDK-8374210] integrated in 7e18de13 by #29055.
> 
> [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210

Thanks, looks good to me!

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29112#pullrequestreview-3638650782

From vyazici at openjdk.org  Thu Jan  8 09:59:49 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 8 Jan 2026 09:59:49 GMT
Subject: [jdk26] RFR: 8374210: [BACKOUT] Move input validation checks to
 Java for java.lang.StringCoding intrinsics
In-Reply-To: <VSWSSBWMmja8G_pvHgqm9OIR0-7_6Z1JfNp-cOS5ElU=.bcfa97e6-1c30-4e69-97d2-f8a151ed6d1d@github.com>
References: <VSWSSBWMmja8G_pvHgqm9OIR0-7_6Z1JfNp-cOS5ElU=.bcfa97e6-1c30-4e69-97d2-f8a151ed6d1d@github.com>
Message-ID: <1D_MQZOrQacI_1-qfW6g_QXKPtxCT5S-J3MN6JxkwGg=.823bcd7b-1758-48ea-b33d-53b337dbc814@github.com>

On Thu, 8 Jan 2026 09:42:58 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Backport of [JDK-8374210] integrated in 7e18de13 by #29055.
> 
> [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210

Matching the labels with #29055 that this PR is backporting:

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

PR Comment: https://git.openjdk.org/jdk/pull/29112#issuecomment-3723094738

From cnorrbin at openjdk.org  Thu Jan  8 10:18:17 2026
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 8 Jan 2026 10:18:17 GMT
Subject: RFR: 8373638: RBTree public interface does not check all input
 parameters for validity [v2]
In-Reply-To: <SOiJJksA_-pAmvj8O-QYI6vbA19kXlvswvChFxqAwl4=.535530cd-6dc8-4d14-a1ae-3ecbe74a927d@github.com>
References: <SOiJJksA_-pAmvj8O-QYI6vbA19kXlvswvChFxqAwl4=.535530cd-6dc8-4d14-a1ae-3ecbe74a927d@github.com>
Message-ID: <Qvyu9hPkmFdiwr-tOk36DS_aTLCkmBxSaBYqVnXDld4=.b6c4019d-4a45-4501-8e8d-aecb017bd488@github.com>

> Hi everyone,
> 
> The public interface for the `RBTree` assumes most input is valid, and does not check for null pointers. This could lead to potential null pointer dereferences. We should instead assert to give clearer errors in debug builds and to avoid trying to dereference these null pointers.
> 
> Testing:
> - Oracle tiers 1-3

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

  changed asserts to precond

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28922/files
  - new: https://git.openjdk.org/jdk/pull/28922/files/5df5c446..1c221184

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

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

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

From cnorrbin at openjdk.org  Thu Jan  8 10:21:07 2026
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 8 Jan 2026 10:21:07 GMT
Subject: RFR: 8373638: RBTree public interface does not check all input
 parameters for validity [v2]
In-Reply-To: <gVxITxIMzXGljoTXMP7u6AQO4FCTBn2RqCtWDM1kM88=.b7da0f6f-2f52-437d-a0e6-4445f1383f6b@github.com>
References: <SOiJJksA_-pAmvj8O-QYI6vbA19kXlvswvChFxqAwl4=.535530cd-6dc8-4d14-a1ae-3ecbe74a927d@github.com>
 <gVxITxIMzXGljoTXMP7u6AQO4FCTBn2RqCtWDM1kM88=.b7da0f6f-2f52-437d-a0e6-4445f1383f6b@github.com>
Message-ID: <LPcqX6QeVWqHXeUM_dRftQXQBiUjXtsLQMn4_hIvgAY=.95c47cd5-e716-4ace-a896-be6942621cc1@github.com>

On Tue, 23 Dec 2025 05:31:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

> These all look like they would be good candidates for using `precond()`.

Good idea, I've changed them all to `precond` instead.

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

PR Comment: https://git.openjdk.org/jdk/pull/28922#issuecomment-3723178895

From kbarrett at openjdk.org  Thu Jan  8 11:09:47 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 8 Jan 2026 11:09:47 GMT
Subject: RFR: 8374328: Convert simple AtomicAccess uses in gc/shared to use
 Atomic<T> [v3]
In-Reply-To: <01TjzVoQfydIB1hGUPH4BdIEQoxYa42GV8mQJ-h7-_M=.3e50e251-e2ea-40b7-a11b-147519817936@github.com>
References: <RJp0KKg8demYMWOXkrVs1g_jitLhTsvce6ZFO98ihNw=.2c8e0a03-d56a-450e-91c8-019931a717b8@github.com>
 <4xK-xF1D4khPfnCGygZ2pLN1SVwdVpjcvPeAl0ZUEOk=.a2de074b-192f-4129-9cf7-da5b7bd347b4@github.com>
 <01TjzVoQfydIB1hGUPH4BdIEQoxYa42GV8mQJ-h7-_M=.3e50e251-e2ea-40b7-a11b-147519817936@github.com>
Message-ID: <eOMvAugr9dyRy157y0lcj6uO4z1gviEBgDZE_AfUIGs=.4c1c7321-0f23-4140-8254-62aa16143270@github.com>

On Thu, 8 Jan 2026 07:28:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
>> 
>>  - Merge branch 'master' into simple-gc-shared-atomic
>>  - update copyrights
>>  - pretouch
>>  - WorkerThread control
>>  - SuspendibleThreadSet control
>>  - GCLocker control
>>  - ConcurrentGCThread termination protocol
>>  - DeoptimizeNMethodBarriersALot gating counter
>
> Marked as reviewed by dholmes (Reviewer).

Thanks for reviews @dholmes-ora and @tschatzl

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

PR Comment: https://git.openjdk.org/jdk/pull/28987#issuecomment-3723360391

From kbarrett at openjdk.org  Thu Jan  8 11:09:49 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 8 Jan 2026 11:09:49 GMT
Subject: Integrated: 8374328: Convert simple AtomicAccess uses in gc/shared to
 use Atomic<T>
In-Reply-To: <RJp0KKg8demYMWOXkrVs1g_jitLhTsvce6ZFO98ihNw=.2c8e0a03-d56a-450e-91c8-019931a717b8@github.com>
References: <RJp0KKg8demYMWOXkrVs1g_jitLhTsvce6ZFO98ihNw=.2c8e0a03-d56a-450e-91c8-019931a717b8@github.com>
Message-ID: <V75eCD0zDLdKbEwCmBrWtUEVz-Owr6Z3oc3M6sDJKfk=.4b83861b-e614-4c93-8cf9-4434da08ecc2@github.com>

On Thu, 25 Dec 2025 04:00:00 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review these fairly simple changes to code in gc/shared to use
> `Atomic<T>` instead of directly using `AtomicAccess`.
> 
> This change doesn't eliminate all remaining direct uses of `AtomicAccess` in
> that directory; there are still a few uses that seem less simple, and maybe
> some that should stay with direct `AtomicAccess`.
> 
> The changes are grouped into a series of commits, as a potential aid to reviewers.
> 
> Testing: mach5 tier1-5

This pull request has now been integrated.

Changeset: c5159fc9
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c5159fc9fa0fd81dec629cd821b3411b4a6df967
Stats:     65 lines in 12 files changed: 9 ins; 3 del; 53 mod

8374328: Convert simple AtomicAccess uses in gc/shared to use Atomic<T>

Reviewed-by: dholmes, tschatzl

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

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

From chagedorn at openjdk.org  Thu Jan  8 11:46:20 2026
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 8 Jan 2026 11:46:20 GMT
Subject: RFR: 8373343: C2: verify AddP base input only set for heap
 addresses [v3]
In-Reply-To: <MXV9ZMiTYvZmgxalWcHcX4S6FBknN6hI57koVmX9M-A=.84df721a-c44c-46a2-96c2-832721c0b86d@github.com>
References: <fdm8TK_FBJheQ_Wkd_KobosU0uTioUuRZhIK38I3Q-g=.8ae8e498-9c14-4cae-8e68-4c39914a8195@github.com>
 <kQMfKDd-5lJ-I3rXLgC2Y_u6lPAMUd_wSpf32HWcZ2s=.e93eda67-479a-44ed-821a-5b122daf062b@github.com>
 <lFYFZQbpc_c9pEewnw47E8ju-Rqe3pE-wYu66bgnryA=.04f449cc-f02d-40ea-a855-a3c484f59784@github.com>
 <MXV9ZMiTYvZmgxalWcHcX4S6FBknN6hI57koVmX9M-A=.84df721a-c44c-46a2-96c2-832721c0b86d@github.com>
Message-ID: <bDCuO2LDT1Iq4BRxA8w1EJawHF4gfBLZyikgypBUDq0=.4f6b04cf-18dc-4c3b-9391-208ceaef3462@github.com>

On Wed, 7 Jan 2026 08:18:25 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> src/hotspot/share/opto/graphKit.cpp line 3590:
>> 
>>> 3588:   }
>>> 3589:   constant_value = Klass::_lh_neutral_value;  // put in a known value
>>> 3590:   Node* lhp = basic_plus_adr(top(), klass_node, in_bytes(Klass::layout_helper_offset()));
>> 
>> Same thought here: could we have a separate `off_heap_plus_addr()` or something like that instead of passing in `top()` on each call site?
>> 
>> This and the other suggestion could also be done separately.
>
> I gave that one a try and I found that pattern to be common and I think it would be best done as a separate change. WDYT?

Sounds good, let's do it separately.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28769#discussion_r2672027289

From chagedorn at openjdk.org  Thu Jan  8 11:51:13 2026
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 8 Jan 2026 11:51:13 GMT
Subject: RFR: 8373343: C2: verify AddP base input only set for heap
 addresses [v4]
In-Reply-To: <X3ATo35ItGD-thnX4VKIiVABa5Kc7fLpJyV1Ez3Xfno=.bc21ce5c-d1f4-4b70-9157-9611074039ee@github.com>
References: <fdm8TK_FBJheQ_Wkd_KobosU0uTioUuRZhIK38I3Q-g=.8ae8e498-9c14-4cae-8e68-4c39914a8195@github.com>
 <X3ATo35ItGD-thnX4VKIiVABa5Kc7fLpJyV1Ez3Xfno=.bc21ce5c-d1f4-4b70-9157-9611074039ee@github.com>
Message-ID: <XPDmAeIq7lPkVcrd3RDCyoHmlrKlNv-irgYbunEvODQ=.7dc6dbc7-6bb1-49f8-97f7-432aca82e477@github.com>

On Wed, 7 Jan 2026 08:16:55 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> The base input of `AddP` is expected to only be set for heap accesses
>> but I noticed some inconsistencies so I added an assert in the `AddP`
>> constructor and fixed issues that it caught. AFAFICT, the
>> inconsistencies shouldn't create issues.
>
> Roland Westrelin 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 13 additional commits since the last revision:
> 
>  - more
>  - more
>  - review
>  - Merge branch 'master' into JDK-8373343
>  - review
>  - review
>  - review
>  - merge
>  - more
>  - more
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/c28f62fa...b20f41db

Update looks good! Let me this another spin in our testing.

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

Marked as reviewed by chagedorn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28769#pullrequestreview-3639046036

From roland at openjdk.org  Thu Jan  8 11:56:32 2026
From: roland at openjdk.org (Roland Westrelin)
Date: Thu, 8 Jan 2026 11:56:32 GMT
Subject: RFR: 8373343: C2: verify AddP base input only set for heap
 addresses [v3]
In-Reply-To: <bDCuO2LDT1Iq4BRxA8w1EJawHF4gfBLZyikgypBUDq0=.4f6b04cf-18dc-4c3b-9391-208ceaef3462@github.com>
References: <fdm8TK_FBJheQ_Wkd_KobosU0uTioUuRZhIK38I3Q-g=.8ae8e498-9c14-4cae-8e68-4c39914a8195@github.com>
 <kQMfKDd-5lJ-I3rXLgC2Y_u6lPAMUd_wSpf32HWcZ2s=.e93eda67-479a-44ed-821a-5b122daf062b@github.com>
 <lFYFZQbpc_c9pEewnw47E8ju-Rqe3pE-wYu66bgnryA=.04f449cc-f02d-40ea-a855-a3c484f59784@github.com>
 <MXV9ZMiTYvZmgxalWcHcX4S6FBknN6hI57koVmX9M-A=.84df721a-c44c-46a2-96c2-832721c0b86d@github.com>
 <bDCuO2LDT1Iq4BRxA8w1EJawHF4gfBLZyikgypBUDq0=.4f6b04cf-18dc-4c3b-9391-208ceaef3462@github.com>
Message-ID: <rnb4YPiqh_x3RsXSZcw7VOc-mRLzQPmPLj6ZqsZnIjU=.8862d9e1-701d-4b39-ba99-d03cc1fcbc3e@github.com>

On Thu, 8 Jan 2026 11:42:40 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> I gave that one a try and I found that pattern to be common and I think it would be best done as a separate change. WDYT?
>
> Sounds good, let's do it separately.

I filed: https://bugs.openjdk.org/browse/JDK-8374789

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28769#discussion_r2672057908

From adinn at openjdk.org  Thu Jan  8 12:04:55 2026
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 8 Jan 2026 12:04:55 GMT
Subject: RFR: 8374698: Stub names should look more like identifiers [v2]
In-Reply-To: <bd9g-wJdlXSzlSplooeUFC9SZyjUuUjPT57d3xmE0gg=.eb54555f-9d49-4abf-9a57-76bc939e2578@github.com>
References: <41ClGzK_bnZ3nmexlGdQW7Ncdh1q31ZDX_KZ1vBPNb4=.49a051e8-9345-4fe5-b635-efe44a21c051@github.com>
 <bd9g-wJdlXSzlSplooeUFC9SZyjUuUjPT57d3xmE0gg=.eb54555f-9d49-4abf-9a57-76bc939e2578@github.com>
Message-ID: <aKjjutEhvW2yQmtj0O0c4ytlKWnj7-X9cG90OdjLbAY=.870dfc13-1a63-4c99-a104-266622dbc42a@github.com>

On Wed, 7 Jan 2026 12:25:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Noticed this when looking at disassembly. Cosmetic issue in [JDK-8360707](https://bugs.openjdk.org/browse/JDK-8360707) makes the stub identifiers look fairly weird:
>> 
>> 
>> 0x0000786da3c1a6f2: call Stub::Stub Generator lookup_secondary_supers_table_slow_path_stub
>>     ; {runtime_call Stub::Stub Generator lookup_secondary_supers_table_slow_path_stub}
>> 
>> 
>> Notice "Stub Generator" in the middle of the stub identifier.
>> 
>> After the fix:
>> 
>> 
>> 0x00007f357bc1a3f2:   call   Stub::lookup_secondary_supers_table_slow_path_stub (stub gen)
>>      ; {runtime_call Stub::lookup_secondary_supers_table_slow_path_stub (stub gen)}
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Of course there are asserts that verify stub names directly

This is a much more coherent format for the names so thumbs up.

I believe there are a few tests that explicitly check stub names and I cannot recall for sure whether they are all in tier1. Have you tried running the non-tier1 runtime tests? Might well be worth doing before committing.

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

Marked as reviewed by adinn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29080#pullrequestreview-3639092283

From mgronlun at openjdk.org  Thu Jan  8 12:24:06 2026
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 8 Jan 2026 12:24:06 GMT
Subject: RFR: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is
 incorrectly implemented
In-Reply-To: <hgAyKMzLuFluIKVlWxPAmhx9C-LwKHZF--IclytugAM=.c9e86f72-1147-4720-91e8-1dbf55e3079f@github.com>
References: <SiBemHHhiHk3uDElvjRK16U2SNea7P1wsptA_4z7kxA=.0746951f-41b4-46b4-8397-40603dea6298@github.com>
 <hgAyKMzLuFluIKVlWxPAmhx9C-LwKHZF--IclytugAM=.c9e86f72-1147-4720-91e8-1dbf55e3079f@github.com>
Message-ID: <ebjLMpvvUjQm6UWGEot7XvyF72D7WlmCMaF7oCCL9h0=.2e13656b-3ec7-466f-a449-d1c56b810457@github.com>

On Wed, 7 Jan 2026 14:20:34 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> The jtreg test TestEmergencyDumpAtOOM.java runs into the following error on ppc64 platforms.
>> 
>> JFR emergency dump would be kicked at `VMError::report_and_die()`, then Java thread for JFR would not work due to secondary signal handler for error reporting.
>> 
>> Passed all of jdk_jfr tests on Linux AMD64.
>
> Alternative implementation suggestion PR (in draft state) https://github.com/openjdk/jdk/pull/29094
> 
> Includes also a solution to [JDK-8373257](https://bugs.openjdk.org/browse/JDK-8373257)
> @tstuefe
>  
> Please take a look, and also if you can, submit for testing on your platforms.
> 
> Markus

> Thanks a lot @mgronlun ! I think JDK-8371014 (and JDK-8373257) should be tackled in #29094 . So should I close this PR?

Yes, I think we should do it in https://github.com/openjdk/jdk/pull/29094. You can close this one, and I will officially publish https://github.com/openjdk/jdk/pull/29094.

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

PR Comment: https://git.openjdk.org/jdk/pull/28563#issuecomment-3723622934

From mgronlun at openjdk.org  Thu Jan  8 12:29:48 2026
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 8 Jan 2026 12:29:48 GMT
Subject: RFR: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is
 incorrectly implemented
Message-ID: <wlLXEGgDYePiM-XzCJJAmh-M2uycSiCuI3epumf-Byw=.3fd63eb6-6616-42f5-a6e1-daf7b3286317@github.com>

Alternative for solving [JDK-8371014](https://bugs.openjdk.org/browse/JDK-8371014)

Also includes a fix for [JDK-8373257](https://bugs.openjdk.org/browse/JDK-8373257)

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

Commit messages:
 - reordering
 - update comment
 - is_recording() conditional
 - remove tautology
 - 8371014

Changes: https://git.openjdk.org/jdk/pull/29094/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29094&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371014
  Stats: 292 lines in 15 files changed: 219 ins; 18 del; 55 mod
  Patch: https://git.openjdk.org/jdk/pull/29094.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29094/head:pull/29094

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

From mdoerr at openjdk.org  Thu Jan  8 12:29:49 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 8 Jan 2026 12:29:49 GMT
Subject: RFR: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is
 incorrectly implemented
In-Reply-To: <wlLXEGgDYePiM-XzCJJAmh-M2uycSiCuI3epumf-Byw=.3fd63eb6-6616-42f5-a6e1-daf7b3286317@github.com>
References: <wlLXEGgDYePiM-XzCJJAmh-M2uycSiCuI3epumf-Byw=.3fd63eb6-6616-42f5-a6e1-daf7b3286317@github.com>
Message-ID: <8LD4JmIZnVSwmhLeVZROok-0h-nCD1TxlaSRHe586-E=.99a49bfa-444f-4ddf-b206-0a75fe1dad23@github.com>

On Wed, 7 Jan 2026 14:14:19 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Alternative for solving [JDK-8371014](https://bugs.openjdk.org/browse/JDK-8371014)
> 
> Also includes a fix for [JDK-8373257](https://bugs.openjdk.org/browse/JDK-8373257)

TestEmergencyDumpAtOOM.java has passed on both, AIX and linux on PPC64. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/29094#issuecomment-3719926832

From mgronlun at openjdk.org  Thu Jan  8 12:29:51 2026
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 8 Jan 2026 12:29:51 GMT
Subject: RFR: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is
 incorrectly implemented
In-Reply-To: <8LD4JmIZnVSwmhLeVZROok-0h-nCD1TxlaSRHe586-E=.99a49bfa-444f-4ddf-b206-0a75fe1dad23@github.com>
References: <wlLXEGgDYePiM-XzCJJAmh-M2uycSiCuI3epumf-Byw=.3fd63eb6-6616-42f5-a6e1-daf7b3286317@github.com>
 <8LD4JmIZnVSwmhLeVZROok-0h-nCD1TxlaSRHe586-E=.99a49bfa-444f-4ddf-b206-0a75fe1dad23@github.com>
Message-ID: <Tsv-WPps-PcBmz3MbSppZRCYJR8uE3favrOzdu62nwM=.21a1df29-8a01-45be-bfee-eea856ecc53c@github.com>

On Wed, 7 Jan 2026 17:23:25 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> TestEmergencyDumpAtOOM.java has passed on both, AIX and linux on PPC64. Thanks!

Thanks Martin.

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

PR Comment: https://git.openjdk.org/jdk/pull/29094#issuecomment-3720022380

From ysuenaga at openjdk.org  Thu Jan  8 12:29:52 2026
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 8 Jan 2026 12:29:52 GMT
Subject: RFR: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is
 incorrectly implemented
In-Reply-To: <Tsv-WPps-PcBmz3MbSppZRCYJR8uE3favrOzdu62nwM=.21a1df29-8a01-45be-bfee-eea856ecc53c@github.com>
References: <wlLXEGgDYePiM-XzCJJAmh-M2uycSiCuI3epumf-Byw=.3fd63eb6-6616-42f5-a6e1-daf7b3286317@github.com>
 <8LD4JmIZnVSwmhLeVZROok-0h-nCD1TxlaSRHe586-E=.99a49bfa-444f-4ddf-b206-0a75fe1dad23@github.com>
 <Tsv-WPps-PcBmz3MbSppZRCYJR8uE3favrOzdu62nwM=.21a1df29-8a01-45be-bfee-eea856ecc53c@github.com>
Message-ID: <RFkIMlajNhZ7Rxcch66Nly4BsYfflNVv6d7W57BM6rs=.cdd38c9e-ba29-4475-92b7-08f106351c0d@github.com>

On Wed, 7 Jan 2026 17:45:55 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> TestEmergencyDumpAtOOM.java has passed on both, AIX and linux on PPC64. Thanks!
>
>> TestEmergencyDumpAtOOM.java has passed on both, AIX and linux on PPC64. Thanks!
> 
> Thanks Martin.

Thanks a lot @mgronlun ! Looks good in general.

Can we wait to finish `service.emit_leakprofiler_events()` in JFR recorder thread before the crash at `report_java_out_of_memory()` in debug.cpp? whether `abort()` is called before finishing to dump events by recorder thread.

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

PR Comment: https://git.openjdk.org/jdk/pull/29094#issuecomment-3721524743

From mgronlun at openjdk.org  Thu Jan  8 12:29:53 2026
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 8 Jan 2026 12:29:53 GMT
Subject: RFR: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is
 incorrectly implemented
In-Reply-To: <Tsv-WPps-PcBmz3MbSppZRCYJR8uE3favrOzdu62nwM=.21a1df29-8a01-45be-bfee-eea856ecc53c@github.com>
References: <wlLXEGgDYePiM-XzCJJAmh-M2uycSiCuI3epumf-Byw=.3fd63eb6-6616-42f5-a6e1-daf7b3286317@github.com>
 <8LD4JmIZnVSwmhLeVZROok-0h-nCD1TxlaSRHe586-E=.99a49bfa-444f-4ddf-b206-0a75fe1dad23@github.com>
 <Tsv-WPps-PcBmz3MbSppZRCYJR8uE3favrOzdu62nwM=.21a1df29-8a01-45be-bfee-eea856ecc53c@github.com>
Message-ID: <Zyf2SPbqc1cw8xxcUYVt0y8Rw9CRLKpNiksCxwSjoYo=.8defd264-1e44-4cc4-9ddd-5a9ea5eaf532@github.com>

On Wed, 7 Jan 2026 17:45:55 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> TestEmergencyDumpAtOOM.java has passed on both, AIX and linux on PPC64. Thanks!
>
>> TestEmergencyDumpAtOOM.java has passed on both, AIX and linux on PPC64. Thanks!
> 
> Thanks Martin.

> Thanks a lot @mgronlun ! Looks good in general.
> 
> Can we wait to finish `service.emit_leakprofiler_events()` in JFR recorder thread before the crash at `report_java_out_of_memory()` in debug.cpp? whether `abort()` is called before finishing to dump events by recorder thread.

The solution to is avoid someone calling abort() concurrently until at least one service.emit_leakprofiler_events(); has completed. That's why the invocation is done by all threads coming into report_java_out_of_memory(), not only a cas-selected one. Why?

Because it is only by taking the threads from thread state _thread_in_vm to state _thread_blocked (which we manage as part of posting the JFR msg), that a VM operation in service.emit_leakprofiler_events() can proceed.

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

PR Comment: https://git.openjdk.org/jdk/pull/29094#issuecomment-3723611490

From thartmann at openjdk.org  Thu Jan  8 12:35:16 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 8 Jan 2026 12:35:16 GMT
Subject: RFR: 8374570: Assertion failure in ClearArray.java  with
 -XX:+EnableX86EcoreOpts [v2]
In-Reply-To: <FEuG-Xpwg_YlcUIKzXM1hThmJdoHOieMFzFr_qMAfko=.9c93b42b-0c79-4650-98f6-3d86f982693a@github.com>
References: <Ktp_W59MQVNSQ6YyBicFyIGJpb3SH7hPyjMuWIm2uUY=.795faf4d-5111-43e0-9fc7-91426382615f@github.com>
 <FEuG-Xpwg_YlcUIKzXM1hThmJdoHOieMFzFr_qMAfko=.9c93b42b-0c79-4650-98f6-3d86f982693a@github.com>
Message-ID: <V0yX1GM4msadsFretp8AiteRtB2a6fG2En1V8jQgkYM=.4dd8429a-5ffb-4134-8df2-54deb63053ce@github.com>

On Wed, 7 Jan 2026 17:52:50 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> Allow for a larger jump distance
>
> Volodymyr Paprotski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - whitespace
>  - add test

test/hotspot/jtreg/compiler/allocation/Test8374570.java line 33:

> 31:  */
> 32: 
> 33: public class Test8374570 {

Couldn't we just modify the test that originally triggered this issue (`test/hotspot/jtreg/compiler/c2/ClearArray.java`)? Please verify that it triggers the issue though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29070#discussion_r2672173827

From vyazici at openjdk.org  Thu Jan  8 12:35:26 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 8 Jan 2026 12:35:26 GMT
Subject: [jdk26] RFR: 8374210: [BACKOUT] Move input validation checks to
 Java for java.lang.StringCoding intrinsics
In-Reply-To: <iefzfusRhEPi9CsZ9pcegoBOqImrgaMqZWuFWs_b7bE=.2958237f-b82c-4e9a-85d9-8b61166ba079@github.com>
References: <VSWSSBWMmja8G_pvHgqm9OIR0-7_6Z1JfNp-cOS5ElU=.bcfa97e6-1c30-4e69-97d2-f8a151ed6d1d@github.com>
 <iefzfusRhEPi9CsZ9pcegoBOqImrgaMqZWuFWs_b7bE=.2958237f-b82c-4e9a-85d9-8b61166ba079@github.com>
Message-ID: <31ndTk5iWs478rKrz34crpL5m9IoQEXbU1EwqwIKpCU=.faef8dff-858f-4a68-990c-c7716abb625f@github.com>

On Thu, 8 Jan 2026 09:53:56 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Backport of [JDK-8374210] integrated in 7e18de13 by #29055.
>> 
>> [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210
>
> Thanks, looks good to me!

@TobiHartmann, thanks so much for your kind assistance.

Tier 1 is clear on c2ee487015b.

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

PR Comment: https://git.openjdk.org/jdk/pull/29112#issuecomment-3723665752

From vyazici at openjdk.org  Thu Jan  8 12:35:27 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 8 Jan 2026 12:35:27 GMT
Subject: [jdk26] Integrated: 8374210: [BACKOUT] Move input validation checks to
 Java for java.lang.StringCoding intrinsics
In-Reply-To: <VSWSSBWMmja8G_pvHgqm9OIR0-7_6Z1JfNp-cOS5ElU=.bcfa97e6-1c30-4e69-97d2-f8a151ed6d1d@github.com>
References: <VSWSSBWMmja8G_pvHgqm9OIR0-7_6Z1JfNp-cOS5ElU=.bcfa97e6-1c30-4e69-97d2-f8a151ed6d1d@github.com>
Message-ID: <ZeH48y9BM6KgoOV2iRDxNOrIvZOhRZqEQwqh49VBl2g=.aaa546cc-23ee-4d3c-aea0-ab6434f7a540@github.com>

On Thu, 8 Jan 2026 09:42:58 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Backport of [JDK-8374210] integrated in 7e18de13 by #29055.
> 
> [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210

This pull request has now been integrated.

Changeset: 867f4620
Author:    Volkan Yazici <vyazici at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/867f4620db9cbd66ae7ed9d11fb919fb3679b012
Stats:     437 lines in 23 files changed: 25 ins; 331 del; 81 mod

8374210: [BACKOUT] Move input validation checks to Java for java.lang.StringCoding intrinsics

Reviewed-by: thartmann
Backport-of: 7e18de137c3b5f08a479af2b64eb22923261900b

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

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

From shade at openjdk.org  Thu Jan  8 12:37:25 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 8 Jan 2026 12:37:25 GMT
Subject: RFR: 8374698: Stub names should look more like identifiers [v2]
In-Reply-To: <aKjjutEhvW2yQmtj0O0c4ytlKWnj7-X9cG90OdjLbAY=.870dfc13-1a63-4c99-a104-266622dbc42a@github.com>
References: <41ClGzK_bnZ3nmexlGdQW7Ncdh1q31ZDX_KZ1vBPNb4=.49a051e8-9345-4fe5-b635-efe44a21c051@github.com>
 <bd9g-wJdlXSzlSplooeUFC9SZyjUuUjPT57d3xmE0gg=.eb54555f-9d49-4abf-9a57-76bc939e2578@github.com>
 <aKjjutEhvW2yQmtj0O0c4ytlKWnj7-X9cG90OdjLbAY=.870dfc13-1a63-4c99-a104-266622dbc42a@github.com>
Message-ID: <FgyigPkHssJEG8WFLYUV1-f-lX1aPUNql7dIxd4pvCI=.dfd8ddf7-99b7-4a77-83a7-f846407f1a02@github.com>

On Thu, 8 Jan 2026 12:02:07 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> Have you tried running the non-tier1 runtime tests?

I ran entire `hotspot_compiler` without a problem. But yeah, I will run `all` tests and see if there are any other surprises.

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

PR Comment: https://git.openjdk.org/jdk/pull/29080#issuecomment-3723674601

From tschatzl at openjdk.org  Thu Jan  8 14:03:36 2026
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 8 Jan 2026 14:03:36 GMT
Subject: RFR: 8374780: G1: Do not iterate klass metadata when splitting
 objArrays for every slice
Message-ID: <4iFTIPttYFA_jy2n-gPTPj-kKhbvifpaQ5pQWEW6xaQ=.71645432-df6a-4b6f-ac18-1d7d85cf2fb2@github.com>

Hi all,

  please review this change that makes concurrent mark not try to iterate over `objArray` metadata for every slice, to make behavior uniform with other garbage collection types/garbage collectors.

Testing: tier1-5

Thanks,
  Thomas

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

Commit messages:
 - 8374780

Changes: https://git.openjdk.org/jdk/pull/29116/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29116&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374780
  Stats: 22 lines in 5 files changed: 12 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/29116.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29116/head:pull/29116

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

From vpaprotski at openjdk.org  Thu Jan  8 15:38:53 2026
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Thu, 8 Jan 2026 15:38:53 GMT
Subject: RFR: 8374570: Assertion failure in ClearArray.java  with
 -XX:+EnableX86EcoreOpts [v3]
In-Reply-To: <Ktp_W59MQVNSQ6YyBicFyIGJpb3SH7hPyjMuWIm2uUY=.795faf4d-5111-43e0-9fc7-91426382615f@github.com>
References: <Ktp_W59MQVNSQ6YyBicFyIGJpb3SH7hPyjMuWIm2uUY=.795faf4d-5111-43e0-9fc7-91426382615f@github.com>
Message-ID: <b5E6T8TII6aHjg9dxvq2GUGEEkQWRgfETU71t3iLgtg=.ebc5a0d4-b8b2-4a93-9c7f-853cf8798f8c@github.com>

> Allow for a larger jump distance

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

  testcase change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29070/files
  - new: https://git.openjdk.org/jdk/pull/29070/files/389393a7..6a5f239f

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

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

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

From vpaprotski at openjdk.org  Thu Jan  8 15:38:56 2026
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Thu, 8 Jan 2026 15:38:56 GMT
Subject: RFR: 8374570: Assertion failure in ClearArray.java  with
 -XX:+EnableX86EcoreOpts [v2]
In-Reply-To: <V0yX1GM4msadsFretp8AiteRtB2a6fG2En1V8jQgkYM=.4dd8429a-5ffb-4134-8df2-54deb63053ce@github.com>
References: <Ktp_W59MQVNSQ6YyBicFyIGJpb3SH7hPyjMuWIm2uUY=.795faf4d-5111-43e0-9fc7-91426382615f@github.com>
 <FEuG-Xpwg_YlcUIKzXM1hThmJdoHOieMFzFr_qMAfko=.9c93b42b-0c79-4650-98f6-3d86f982693a@github.com>
 <V0yX1GM4msadsFretp8AiteRtB2a6fG2En1V8jQgkYM=.4dd8429a-5ffb-4134-8df2-54deb63053ce@github.com>
Message-ID: <SULujepUupB4hkE97i9Ny4bvNm0suVV3cbnR9bfWSTc=.9b1a84f9-125e-4d86-9f24-2babff366b19@github.com>

On Thu, 8 Jan 2026 12:31:50 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - whitespace
>>  - add test
>
> test/hotspot/jtreg/compiler/allocation/Test8374570.java line 33:
> 
>> 31:  */
>> 32: 
>> 33: public class Test8374570 {
> 
> Couldn't we just modify the test that originally triggered this issue (`test/hotspot/jtreg/compiler/c2/ClearArray.java`)? Please verify that it triggers the issue though.

Much better, thanks.
Just added another `@run` to that test; I think with `IgnoreUnrecognizedOptions`, I don't have to limit it to an arch either. 
Does fail without the fix and passes with. (Its not the minimum option set, but left the options that made sense to me. Can add/remove if you like..)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29070#discussion_r2672843584

From epeter at openjdk.org  Thu Jan  8 16:10:08 2026
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 8 Jan 2026 16:10:08 GMT
Subject: RFR: 8373480: Optimize multiplication by constant multiplier using
 LEA instructions [v6]
In-Reply-To: <vTZKK9fSVJPpo0sIXV1s-2hRvTOSLt78JbB3PYxiQNk=.f790a1d3-a515-4544-a304-85d80f20a927@github.com>
References: <uo_ugfdLTrURHDpmWF4Xfh2Hspum8XDJNYsUjhAEc1I=.131ef8cd-e2f3-4d8c-981c-a701452cb264@github.com>
 <vTZKK9fSVJPpo0sIXV1s-2hRvTOSLt78JbB3PYxiQNk=.f790a1d3-a515-4544-a304-85d80f20a927@github.com>
Message-ID: <-hubTcbRW128C1Uuvoq1xx9KfIFLnYGh8gUB757p6iA=.3596b81a-b8b8-491a-a709-7268e3300a92@github.com>

On Mon, 22 Dec 2025 12:09:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Emulate multiplier using LEA addressing scheme, where effective address = BASE + INDEX * SCALE + OFFSET
>> Refer to section "3.5.1.2 Using LEA" of Intel's optimization manual for details reagarding slow vs fast lea instructions.
>> Given that latency of IMUL with register operands is 3 cycles, a combination of two fast LEAs each with 1 cycle latency to emulate multipler is performant.
>> 
>> Consider X as the multiplicand, by variying the scale of  first LEA instruction we can generate 4 input i.e.
>> 
>> 
>>     X + X * 1 = 2X
>>     X + X * 2 = 3X
>>     X + X * 4 = 5X
>>     X + X * 8 = 9X
>> 
>> 
>> Following table list downs various multiplier combinations for output of first LEA at BASE and/or INDEX by varying the 
>> scale of second fast LEA instruction. We will only handle the cases which cannot be handled by just shift + add.
>> 
>> 
>>       BASE   INDEX   SCALE  MULTIPLER
>>         X      X       1       2       (Terminal)
>>         X      X       2       3       (Terminal)
>>         X      X       4       5       (Terminal)
>>         X      X       8       9       (Terminal)
>>        3X     3X       1       6
>>         X     3X       2       7
>>        5X     5X       1      10
>>         X     5X       2      11
>>         X     3X       4      13
>>        5X     5X       2      15
>>         X     2X       8      17
>>        9X     9X       1      18
>>         X     9X       2      19
>>         X     5X       4      21
>>        5X     5X       4      25
>>        9X     9X       2      27
>>         X     9X       4      37
>>         X     5X       8      41
>>        9X     9X       4      45
>>         X     9X       8      73
>>        9X     9X       8      81
>> 
>> 
>> All the non-unity inputs tied to BASE / INDEX  are derived out of terminal cases which represent first FAST LEA. Thus, all the multipliers can be computed using just two LEA instructions.
>> 
>> Performance numbers for new micro benchmark included with this patch shows around **5-50% improvments** on latest x86 servers.
>> 
>> 
>> System: INTEL(R) XEON(R) PLATINUM 8581C CPU @ 2.10GHz Emerald Rapids:-
>> Baseline:-
>> Benchmark                                             Mode  Cnt    Score   Error    Units
>> ConstantMultiplierOptimization.testConstMultiplierI  thrpt    2  189.690          ops/min
>> ConstantMultiplierOptimization.testConstMultiplierL  thrpt    2  196.283          ops/min
>> 
>> 
>> Withopt:-
>> Benchmark                                             Mode  Cnt    Score   Error    Units
>> Constant...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extending micro and jtreg tests for memory patterns

Looks like a neat optimization :)
I have a few initial comments.

test/hotspot/jtreg/compiler/c2/TestConstantMultiplier.java line 89:

> 87:         ));
> 88:         var testTemplate1 = Template.make(() -> scope(
> 89:             IntStream.of(81, 73, 45, 41, 37, 27, 25, 21, 19, 13, 11).mapToObj(

Is there something special about these values? If yes: add a code comment :)
If no: could we add random values to the list to improve coverage and find edge cases?

test/hotspot/jtreg/compiler/c2/TestConstantMultiplier.java line 102:

> 100:                         private static void runMultBy#{multiplier}I() {
> 101:                             int multiplicand = RANDOM.nextInt();
> 102:                             Verify.checkEQ(#{multiplier} * multiplicand, testMultBy#{multiplier}I(multiplicand));

I think that the `@Run` method also gets compiled, so probably both sides of the verification are compiled. Is that your intention? Probably not, right?

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

PR Review: https://git.openjdk.org/jdk/pull/28759#pullrequestreview-3640094256
PR Review Comment: https://git.openjdk.org/jdk/pull/28759#discussion_r2672927447
PR Review Comment: https://git.openjdk.org/jdk/pull/28759#discussion_r2672963980

From epeter at openjdk.org  Thu Jan  8 16:10:10 2026
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 8 Jan 2026 16:10:10 GMT
Subject: RFR: 8373480: Optimize multiplication by constant multiplier using
 LEA instructions [v6]
In-Reply-To: <-hubTcbRW128C1Uuvoq1xx9KfIFLnYGh8gUB757p6iA=.3596b81a-b8b8-491a-a709-7268e3300a92@github.com>
References: <uo_ugfdLTrURHDpmWF4Xfh2Hspum8XDJNYsUjhAEc1I=.131ef8cd-e2f3-4d8c-981c-a701452cb264@github.com>
 <vTZKK9fSVJPpo0sIXV1s-2hRvTOSLt78JbB3PYxiQNk=.f790a1d3-a515-4544-a304-85d80f20a927@github.com>
 <-hubTcbRW128C1Uuvoq1xx9KfIFLnYGh8gUB757p6iA=.3596b81a-b8b8-491a-a709-7268e3300a92@github.com>
Message-ID: <UkGBrTojhlN0wbKjAp3yHcRWhOemePWwcU_RxcX4umQ=.31730bf4-6e63-4d57-8b4c-22df38f8e0b1@github.com>

On Thu, 8 Jan 2026 15:57:39 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Extending micro and jtreg tests for memory patterns
>
> test/hotspot/jtreg/compiler/c2/TestConstantMultiplier.java line 89:
> 
>> 87:         ));
>> 88:         var testTemplate1 = Template.make(() -> scope(
>> 89:             IntStream.of(81, 73, 45, 41, 37, 27, 25, 21, 19, 13, 11).mapToObj(
> 
> Is there something special about these values? If yes: add a code comment :)
> If no: could we add random values to the list to improve coverage and find edge cases?

Ah, I see now that these are the values from your lookup table in the optimization.

I think it would still be good if you added random values, just for result verification.
And only enable IR rules for the special values.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28759#discussion_r2672960296

From shade at openjdk.org  Thu Jan  8 18:03:33 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 8 Jan 2026 18:03:33 GMT
Subject: RFR: 8374698: Stub names should look more like identifiers [v2]
In-Reply-To: <bd9g-wJdlXSzlSplooeUFC9SZyjUuUjPT57d3xmE0gg=.eb54555f-9d49-4abf-9a57-76bc939e2578@github.com>
References: <41ClGzK_bnZ3nmexlGdQW7Ncdh1q31ZDX_KZ1vBPNb4=.49a051e8-9345-4fe5-b635-efe44a21c051@github.com>
 <bd9g-wJdlXSzlSplooeUFC9SZyjUuUjPT57d3xmE0gg=.eb54555f-9d49-4abf-9a57-76bc939e2578@github.com>
Message-ID: <ItCJrJqFHPdeef2Clk6-McKX0fKZbPs1U-QRyjZQYIo=.efa59202-a2bb-4027-b0e4-811efb460058@github.com>

On Wed, 7 Jan 2026 12:25:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Noticed this when looking at disassembly. Cosmetic issue in [JDK-8360707](https://bugs.openjdk.org/browse/JDK-8360707) makes the stub identifiers look fairly weird:
>> 
>> 
>> 0x0000786da3c1a6f2: call Stub::Stub Generator lookup_secondary_supers_table_slow_path_stub
>>     ; {runtime_call Stub::Stub Generator lookup_secondary_supers_table_slow_path_stub}
>> 
>> 
>> Notice "Stub Generator" in the middle of the stub identifier.
>> 
>> After the fix:
>> 
>> 
>> 0x00007f357bc1a3f2:   call   Stub::lookup_secondary_supers_table_slow_path_stub (stub gen)
>>      ; {runtime_call Stub::lookup_secondary_supers_table_slow_path_stub (stub gen)}
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Of course there are asserts that verify stub names directly

Linux x86_64 server fastdebug `all` passes as well, no surprises.

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

PR Comment: https://git.openjdk.org/jdk/pull/29080#issuecomment-3725022146

From missa at openjdk.org  Thu Jan  8 19:16:12 2026
From: missa at openjdk.org (Mohamed Issa)
Date: Thu, 8 Jan 2026 19:16:12 GMT
Subject: RFR: 8371955: Support AVX10 floating point comparison instructions
 [v2]
In-Reply-To: <xDRJgBQwsegqBOp50pIl-Mzkadb8U-QpYXxSv01Jaxc=.a4cd1675-eb08-4f08-87be-c7f66a88f37e@github.com>
References: <xDRJgBQwsegqBOp50pIl-Mzkadb8U-QpYXxSv01Jaxc=.a4cd1675-eb08-4f08-87be-c7f66a88f37e@github.com>
Message-ID: <hXwxjYBbhlE2r7xfWrC9JuuZHPkolrejK60kwDz4BMk=.8af97837-54a6-4921-936c-9bcfec7062e7@github.com>

> Intel&reg; AVX10 ISA [1] extensions added new floating point comparison instructions. They set the EFLAGS register so that relationships can be tested independently to avoid extra checks when one of the inputs is NaN.
> 
> Most of the work is covered in the architecture definition (`x86.ad`) file. A new comparison operand was created to be used by new CMove and JMP definitions with the APX specific portions of the CMove section being updated to rely on the new instructions because both sets of instructions are always expected to be available on the same platform. New floating point comparison definitions were also added.
> 
> This change uses the new AVX10.2 (UCOMXSS or UCOMXSD) instructions on supported platforms to avoid the extra handling required with existing (UCOMISS or UCOMISD) instructions. To make sure no new failures were introduced, tier1, tier2, and tier3 tests were run on builds with and without the changes. Additionally, the JTREG tests listed below were used to verify correctness with `-XX:-UseAPX` / `-XX:+UseAPX` options. The baseline build used is [OpenJDK v26-b26](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B26).
> 
> 1. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java`
> 2. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFPComparison.java`
> 3. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java`
> 4. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestSignumVector.java`
> 
> Finally, the JMH micro-benchmark listed below was updated to separately exercise CMove and JMP code paths.
> 
> 1. `micro:test/micro/org/openjdk/bench/java/lang/FPComparison.java`
> 
> [1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10

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

  Include apx_f in list of verified CPU features for IR encoding

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28337/files
  - new: https://git.openjdk.org/jdk/pull/28337/files/1e62b5a3..01bf4573

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

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

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

From kfarrell at openjdk.org  Thu Jan  8 19:19:37 2026
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Thu, 8 Jan 2026 19:19:37 GMT
Subject: RFR: 8359706: Add file descriptor count and maximum limit to
 VM.info [v6]
In-Reply-To: <a1HhcupsCROYETAf5X3Gbz5WqojDYbwjMcR4ZKx7uGI=.bedae8d1-08e8-426e-b073-5e207e18573a@github.com>
References: <a1HhcupsCROYETAf5X3Gbz5WqojDYbwjMcR4ZKx7uGI=.bedae8d1-08e8-426e-b073-5e207e18573a@github.com>
Message-ID: <InEGAmmLbM5ZUT0XAkSHwwP2hatQkFvdjdXZ4NnJ2_0=.dcd7ac1a-e08a-4f91-8876-3d80ff9481cd@github.com>

> Currently, it is only possible to read the number of open file descriptors of a Java process via the `UnixOperatingSystemMXBean` which is only accessible via JMX enabled tools. To improve servicability, it would be benifical to be able to view this information from jcmd VM.info output or hs_err_pid crash logs. This could help diagnose resource exhaustion and troubleshoot "too many open files" errors in Java processes on Unix platforms.
> 
> This PR adds reporting the current open file descriptor count to both jcmd VM.info output or hs_err_pid crash logs by refactoring the native JNI logic from `Java_com_sun_management_internal_OperatingSystemImpl_getOpenFileDescriptorCount0` of the `UnixOperatingSystemMXBean` into hotspot. Apple's API for retrieving open file descriptor count provides an array of the actual FDs to determine the count. To avoid using `malloc` to store this array in a potential signal handling context where stack space may be limited, the apple implementation instead allocates a fixed 32KB struct on the stack to store the open FDs and only reports the result if the struct is less than the max (1024 FDs). This should cover the majoirty of use cases.

Kieran Farrell has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - Merge branch 'openjdk:master' into JDK_8359706
 - comment
 - timed loop for aix and linux proc read
 - rm unused variables
 - updates
 - clean up
 - clean up
 - undo commit to linux.cpp
 - rm max count and malloc
 - bsd.cpp
 - ... and 13 more: https://git.openjdk.org/jdk/compare/1342db0b...1f34d255

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

Changes: https://git.openjdk.org/jdk/pull/27971/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27971&range=05
  Stats: 134 lines in 6 files changed: 134 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27971.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27971/head:pull/27971

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

From missa at openjdk.org  Thu Jan  8 19:20:06 2026
From: missa at openjdk.org (Mohamed Issa)
Date: Thu, 8 Jan 2026 19:20:06 GMT
Subject: RFR: 8371955: Support AVX10 floating point comparison instructions
 [v3]
In-Reply-To: <xDRJgBQwsegqBOp50pIl-Mzkadb8U-QpYXxSv01Jaxc=.a4cd1675-eb08-4f08-87be-c7f66a88f37e@github.com>
References: <xDRJgBQwsegqBOp50pIl-Mzkadb8U-QpYXxSv01Jaxc=.a4cd1675-eb08-4f08-87be-c7f66a88f37e@github.com>
Message-ID: <_GAfe6pIqFre0blQwFU-JXJ79CCSk5Ft_kxJhcg0agw=.acf06ec5-399e-4c48-bd26-f15e8b647908@github.com>

> Intel&reg; AVX10 ISA [1] extensions added new floating point comparison instructions. They set the EFLAGS register so that relationships can be tested independently to avoid extra checks when one of the inputs is NaN.
> 
> Most of the work is covered in the architecture definition (`x86.ad`) file. A new comparison operand was created to be used by new CMove and JMP definitions with the APX specific portions of the CMove section being updated to rely on the new instructions because both sets of instructions are always expected to be available on the same platform. New floating point comparison definitions were also added.
> 
> This change uses the new AVX10.2 (UCOMXSS or UCOMXSD) instructions on supported platforms to avoid the extra handling required with existing (UCOMISS or UCOMISD) instructions. To make sure no new failures were introduced, tier1, tier2, and tier3 tests were run on builds with and without the changes. Additionally, the JTREG tests listed below were used to verify correctness with `-XX:-UseAPX` / `-XX:+UseAPX` options. The baseline build used is [OpenJDK v26-b26](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B26).
> 
> 1. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java`
> 2. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFPComparison.java`
> 3. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java`
> 4. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestSignumVector.java`
> 
> Finally, the JMH micro-benchmark listed below was updated to separately exercise CMove and JMP code paths.
> 
> 1. `micro:test/micro/org/openjdk/bench/java/lang/FPComparison.java`
> 
> [1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10

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

  Also update copyright year in IREncodingPrinter.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28337/files
  - new: https://git.openjdk.org/jdk/pull/28337/files/01bf4573..38735c37

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

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

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

From kfarrell at openjdk.org  Thu Jan  8 19:42:50 2026
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Thu, 8 Jan 2026 19:42:50 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command
Message-ID: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>

The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 

This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.

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

Commit messages:
 - static helper method for both jcmd calls
 - missing )
 - working with single arg
 - updates
 - update args
 - two args -not yet tested
 - initial patch

Changes: https://git.openjdk.org/jdk/pull/29124/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364182
  Stats: 304 lines in 18 files changed: 186 ins; 77 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/29124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29124/head:pull/29124

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

From kfarrell at openjdk.org  Thu Jan  8 19:50:08 2026
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Thu, 8 Jan 2026 19:50:08 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command [v2]
In-Reply-To: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
Message-ID: <piIU9wsTeF54r_ADGt7Y5JzMH1c0Ne-bgZuZscBO1Ow=.c8ed4598-8ea4-41ab-8b74-57a3329953d8@github.com>

> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
> 
> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.

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

 - Merge remote-tracking branch 'origin/master' into sec_props2
 - static helper method for both jcmd calls
 - missing )
 - working with single arg
 - updates
 - update args
 - two args -not yet tested
 - initial patch

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29124/files
  - new: https://git.openjdk.org/jdk/pull/29124/files/cda609fc..232feeaa

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

  Stats: 211900 lines in 2740 files changed: 163444 ins; 31329 del; 17127 mod
  Patch: https://git.openjdk.org/jdk/pull/29124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29124/head:pull/29124

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

From dholmes at openjdk.org  Thu Jan  8 20:00:30 2026
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 8 Jan 2026 20:00:30 GMT
Subject: RFR: 8372040: Remove Prefetch header vs inline header separation
In-Reply-To: <hOeaeFbD4gZoe74hyGLWmabC4W4PWuyd7IM0imO4MrU=.555401d0-b3da-4e2a-85dd-2758b3912d70@github.com>
References: <hOeaeFbD4gZoe74hyGLWmabC4W4PWuyd7IM0imO4MrU=.555401d0-b3da-4e2a-85dd-2758b3912d70@github.com>
Message-ID: <_poEM0jDKsWBuurL7QIKXnl9fBQV596DFHgNIcNPUpI=.4c229767-47d5-4997-ad45-a53b622ded19@github.com>

On Wed, 7 Jan 2026 17:47:47 GMT, jonghoonpark <duke at openjdk.org> wrote:

> related jira issue: https://bugs.openjdk.org/browse/JDK-8372040
> 
> ---
> 
> ## Changes
> 
> - Merged `prefetch.hpp` into `prefetch.inline.hpp` and removed the redundant `prefetch.hpp`. Updated all call sites accordingly.
> - Removed `runtime/prefetch.inline.hpp` from `generation.hpp` to adhere to the rule that standard headers should not include inline headers.
>     - Added the inclusion of `runtime/prefetch.inline.hpp` to `cardTableRS.cpp` instead.
> - Removed `runtime/prefetch.hpp` from `g1YoungGCPostEvacuateTasks.cpp` as it is already included via `g1HeapRegion.inline.hpp`.
> 
> ---
> 
> Verified with tier1 testing; no regressions found.

Given the OS_CPU_HEADER_INLINE files are not intended to be included directly by anything except their shared counterpart, I think it looks very odd to write it as-if we expect it to be included directly. To me the comment, per orderAccess files suffices if this is a concern.

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

PR Comment: https://git.openjdk.org/jdk/pull/29096#issuecomment-3725510972

From duke at openjdk.org  Thu Jan  8 20:07:45 2026
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Thu, 8 Jan 2026 20:07:45 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command [v2]
In-Reply-To: <piIU9wsTeF54r_ADGt7Y5JzMH1c0Ne-bgZuZscBO1Ow=.c8ed4598-8ea4-41ab-8b74-57a3329953d8@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <piIU9wsTeF54r_ADGt7Y5JzMH1c0Ne-bgZuZscBO1Ow=.c8ed4598-8ea4-41ab-8b74-57a3329953d8@github.com>
Message-ID: <o3an77G-d1JaxsjRhw5YFL0rtgqMEno0Mhd3WUeoQ50=.a78fc05b-b71f-4a16-9561-acc3ba9e5b32@github.com>

On Thu, 8 Jan 2026 19:50:08 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
>> 
>> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.
>
> Kieran Farrell has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into sec_props2
>  - static helper method for both jcmd calls
>  - missing )
>  - working with single arg
>  - updates
>  - update args
>  - two args -not yet tested
>  - initial patch

src/java.base/share/classes/java/security/Security.java line 802:

> 800:     }
> 801: 
> 802:     static Properties getAllSecurityPropertiesReadOnly() {

is this method used?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29124#discussion_r2673707473

From kfarrell at openjdk.org  Thu Jan  8 20:35:33 2026
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Thu, 8 Jan 2026 20:35:33 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command [v3]
In-Reply-To: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
Message-ID: <ZZrvr-QWrDu5tglz1eEZ_XU-HV5aROHbuLw0dCeUTTM=.712f8dd5-d5db-43da-aa7b-c39631da7597@github.com>

> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
> 
> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.

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

  rm unused code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29124/files
  - new: https://git.openjdk.org/jdk/pull/29124/files/232feeaa..81655c07

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

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

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

From kfarrell at openjdk.org  Thu Jan  8 20:35:37 2026
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Thu, 8 Jan 2026 20:35:37 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command [v2]
In-Reply-To: <piIU9wsTeF54r_ADGt7Y5JzMH1c0Ne-bgZuZscBO1Ow=.c8ed4598-8ea4-41ab-8b74-57a3329953d8@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <piIU9wsTeF54r_ADGt7Y5JzMH1c0Ne-bgZuZscBO1Ow=.c8ed4598-8ea4-41ab-8b74-57a3329953d8@github.com>
Message-ID: <HP2MuR3CPGXVm15_SO6oYLX6hg8YEB0qnBGSFQEMApM=.fe2d338c-ce68-4b4f-a351-c87a23cc258a@github.com>

On Thu, 8 Jan 2026 19:50:08 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
>> 
>> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.
>
> Kieran Farrell has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into sec_props2
>  - static helper method for both jcmd calls
>  - missing )
>  - working with single arg
>  - updates
>  - update args
>  - two args -not yet tested
>  - initial patch

it seems the ability to hide JCMD commands via DCmdFactory, _hidden has been removed in JDK-8373441, I will search for an alternative method.

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

PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3725657806

From kvn at openjdk.org  Thu Jan  8 20:52:35 2026
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 8 Jan 2026 20:52:35 GMT
Subject: RFR: 8374698: Stub names should look more like identifiers [v2]
In-Reply-To: <bd9g-wJdlXSzlSplooeUFC9SZyjUuUjPT57d3xmE0gg=.eb54555f-9d49-4abf-9a57-76bc939e2578@github.com>
References: <41ClGzK_bnZ3nmexlGdQW7Ncdh1q31ZDX_KZ1vBPNb4=.49a051e8-9345-4fe5-b635-efe44a21c051@github.com>
 <bd9g-wJdlXSzlSplooeUFC9SZyjUuUjPT57d3xmE0gg=.eb54555f-9d49-4abf-9a57-76bc939e2578@github.com>
Message-ID: <kE-e0xx7xR0lneVs1MM6US1lsoP0ls8umGOcsOe1Xjw=.2a7b6d85-6bf6-45bf-b4cf-4888302fe7c6@github.com>

On Wed, 7 Jan 2026 12:25:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Noticed this when looking at disassembly. Cosmetic issue in [JDK-8360707](https://bugs.openjdk.org/browse/JDK-8360707) makes the stub identifiers look fairly weird:
>> 
>> 
>> 0x0000786da3c1a6f2: call Stub::Stub Generator lookup_secondary_supers_table_slow_path_stub
>>     ; {runtime_call Stub::Stub Generator lookup_secondary_supers_table_slow_path_stub}
>> 
>> 
>> Notice "Stub Generator" in the middle of the stub identifier.
>> 
>> After the fix:
>> 
>> 
>> 0x00007f357bc1a3f2:   call   Stub::lookup_secondary_supers_table_slow_path_stub (stub gen)
>>      ; {runtime_call Stub::lookup_secondary_supers_table_slow_path_stub (stub gen)}
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Of course there are asserts that verify stub names directly

Looks good to me too.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29080#pullrequestreview-3641254557

From duke at openjdk.org  Thu Jan  8 20:52:35 2026
From: duke at openjdk.org (Larry Cable)
Date: Thu, 8 Jan 2026 20:52:35 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command [v3]
In-Reply-To: <ZZrvr-QWrDu5tglz1eEZ_XU-HV5aROHbuLw0dCeUTTM=.712f8dd5-d5db-43da-aa7b-c39631da7597@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <ZZrvr-QWrDu5tglz1eEZ_XU-HV5aROHbuLw0dCeUTTM=.712f8dd5-d5db-43da-aa7b-c39631da7597@github.com>
Message-ID: <vpUid8KNRxuS_f7Ra4ybZ7hHRq0mYyDR2o0q4gLaY74=.19c8e5ad-8fd8-42f0-9fb1-10ae2d5c224d@github.com>

On Thu, 8 Jan 2026 20:35:33 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
>> 
>> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.
>
> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rm unused code

was there a reason why this was not simply added as an option to the existing Vm.system_properties jcmd?

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

PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3725733678

From kevinw at openjdk.org  Thu Jan  8 21:04:41 2026
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 8 Jan 2026 21:04:41 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command [v3]
In-Reply-To: <ZZrvr-QWrDu5tglz1eEZ_XU-HV5aROHbuLw0dCeUTTM=.712f8dd5-d5db-43da-aa7b-c39631da7597@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <ZZrvr-QWrDu5tglz1eEZ_XU-HV5aROHbuLw0dCeUTTM=.712f8dd5-d5db-43da-aa7b-c39631da7597@github.com>
Message-ID: <0n3cejZUsIIyKQqkBh36ykAx9bhB_GApD7l14BCBjX0=.2fd420ac-ea86-41ef-a1f9-927b8032b670@github.com>

On Thu, 8 Jan 2026 20:35:33 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
>> 
>> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.
>
> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rm unused code

src/hotspot/share/services/attachListener.cpp line 308:

> 306: }
> 307: 
> 308: // Implementation of "properties -security" command.

We don't need this: the attach API provides some basic commands, but most of the time we use the "jcmd" attach api command, which runs a DiagnosticCommand.  That's how we attach and run VM.properties etc...

This makes your life easier, we don't need serializeSecurityPropertiesToByteArray(), just updated DCmd and register_DCMDFactory lines.
(you'll need to merge in the later repo changes and resolve the register_DCMDFactory changes)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29124#discussion_r2673891775

From kfarrell at openjdk.org  Thu Jan  8 21:27:18 2026
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Thu, 8 Jan 2026 21:27:18 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command [v4]
In-Reply-To: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
Message-ID: <BOeQkw3Zf4yrkz_kWLcylC-FrtG4saZLnSSdnxCZbNI=.73818470-7d62-4207-bf04-b149b3db99a3@github.com>

> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
> 
> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.

Kieran Farrell has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - merge
 - rm unused code
 - Merge remote-tracking branch 'origin/master' into sec_props2
 - static helper method for both jcmd calls
 - missing )
 - working with single arg
 - updates
 - update args
 - two args -not yet tested
 - initial patch

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

Changes: https://git.openjdk.org/jdk/pull/29124/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=03
  Stats: 29 lines in 6 files changed: 29 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/29124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29124/head:pull/29124

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

From duke at openjdk.org  Thu Jan  8 21:48:11 2026
From: duke at openjdk.org (Robert Toyonaga)
Date: Thu, 8 Jan 2026 21:48:11 GMT
Subject: RFR: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is
 incorrectly implemented
In-Reply-To: <wlLXEGgDYePiM-XzCJJAmh-M2uycSiCuI3epumf-Byw=.3fd63eb6-6616-42f5-a6e1-daf7b3286317@github.com>
References: <wlLXEGgDYePiM-XzCJJAmh-M2uycSiCuI3epumf-Byw=.3fd63eb6-6616-42f5-a6e1-daf7b3286317@github.com>
Message-ID: <UokcXQpVFrVbpQRnd5sK-hOhLoODirZ6KpsmOXscv5w=.11b868a0-e570-4d7f-a057-8a49d5fc72ee@github.com>

On Wed, 7 Jan 2026 14:14:19 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Alternative for solving [JDK-8371014](https://bugs.openjdk.org/browse/JDK-8371014)
> 
> Also includes a fix for [JDK-8373257](https://bugs.openjdk.org/browse/JDK-8373257)
> 
> Testing: jdk_jfr, stress testing, manual testing with CrashOnOutOfMemoryError, tier1-6

src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp line 611:

> 609:   if (thread->is_VM_thread()) {
> 610:     const VM_Operation* const operation = VMThread::vm_operation();
> 611:     if (operation != nullptr && operation->type() == VM_Operation::VMOp_JFROldObject) {

Is it better/possible to directly check the rotation lock instead? Maybe it's possible the thread crashed before starting the vm operation, or the lock is held by something else.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29094#discussion_r2674002541

From duke at openjdk.org  Thu Jan  8 22:11:18 2026
From: duke at openjdk.org (Larry Cable)
Date: Thu, 8 Jan 2026 22:11:18 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command [v3]
In-Reply-To: <0n3cejZUsIIyKQqkBh36ykAx9bhB_GApD7l14BCBjX0=.2fd420ac-ea86-41ef-a1f9-927b8032b670@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <ZZrvr-QWrDu5tglz1eEZ_XU-HV5aROHbuLw0dCeUTTM=.712f8dd5-d5db-43da-aa7b-c39631da7597@github.com>
 <0n3cejZUsIIyKQqkBh36ykAx9bhB_GApD7l14BCBjX0=.2fd420ac-ea86-41ef-a1f9-927b8032b670@github.com>
Message-ID: <XuGzZPQlzToWgViTRRHCfcX8Yab3I0eN0LvK5icr6A8=.47c37362-fd31-441e-aa0c-ad030a96f004@github.com>

On Thu, 8 Jan 2026 21:02:37 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rm unused code
>
> src/hotspot/share/services/attachListener.cpp line 308:
> 
>> 306: }
>> 307: 
>> 308: // Implementation of "properties -security" command.
> 
> We don't need this: the attach API provides some basic commands, but most of the time we use the "jcmd" attach api command, which runs a DiagnosticCommand.  That's how we attach and run VM.properties etc...
> 
> This makes your life easier, we don't need serializeSecurityPropertiesToByteArray(), just updated DCmd and register_DCMDFactory lines.
> (you'll need to merge in the later repo changes and resolve the register_DCMDFactory changes)

I agree, this functionality should probably be added to the existing VM.system_properties jcmd as an option (if necessary)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29124#discussion_r2674071763

From sparasa at openjdk.org  Thu Jan  8 23:21:08 2026
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Thu, 8 Jan 2026 23:21:08 GMT
Subject: RFR: 8374744: Enable dumping of APX EGPRs =?UTF-8?B?KFIxNuKAk1IzMSk=?=
 in JVM fatal error logs
Message-ID: <WjMTlggj_9O3RLfKmsMcFXuRynnFmMSfflH99E9xOe0=.380518aa-ebaa-4b9f-83de-ab7303d0a7df@github.com>

The goal of this PR is to add support for printing the values of APX extended general-purpose registers (EGPRs, R16-R31) in hs_err_pid* crash logs on x86 platforms with APX support. The implementation detects APX support at runtime and attempts to dump the additional registers when available, improving post-mortem debugging capabilities.

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

Commit messages:
 - dump EGPRs only when UseAPX is enabled; also add nullptr reference check for apx state
 - 8374744: Enable dumping of APX EGPRs (R16?R31) in JVM fatal error logs

Changes: https://git.openjdk.org/jdk/pull/29098/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29098&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374744
  Stats: 139 lines in 3 files changed: 117 ins; 1 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/29098.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29098/head:pull/29098

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

From sviswanathan at openjdk.org  Fri Jan  9 00:36:53 2026
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 9 Jan 2026 00:36:53 GMT
Subject: RFR: 8371955: Support AVX10 floating point comparison instructions
 [v3]
In-Reply-To: <_GAfe6pIqFre0blQwFU-JXJ79CCSk5Ft_kxJhcg0agw=.acf06ec5-399e-4c48-bd26-f15e8b647908@github.com>
References: <xDRJgBQwsegqBOp50pIl-Mzkadb8U-QpYXxSv01Jaxc=.a4cd1675-eb08-4f08-87be-c7f66a88f37e@github.com>
 <_GAfe6pIqFre0blQwFU-JXJ79CCSk5Ft_kxJhcg0agw=.acf06ec5-399e-4c48-bd26-f15e8b647908@github.com>
Message-ID: <Hqdrxeu6tM5ewCBwOezQpKb94M1YSYeygeNktBZCHU8=.09b0dc2a-7d4a-4fbf-9bf1-89630360476d@github.com>

On Thu, 8 Jan 2026 19:20:06 GMT, Mohamed Issa <missa at openjdk.org> wrote:

>> Intel&reg; AVX10 ISA [1] extensions added new floating point comparison instructions. They set the EFLAGS register so that relationships can be tested independently to avoid extra checks when one of the inputs is NaN.
>> 
>> Most of the work is covered in the architecture definition (`x86.ad`) file. A new comparison operand was created to be used by new CMove and JMP definitions with the APX specific portions of the CMove section being updated to rely on the new instructions because both sets of instructions are always expected to be available on the same platform. New floating point comparison definitions were also added.
>> 
>> This change uses the new AVX10.2 (UCOMXSS or UCOMXSD) instructions on supported platforms to avoid the extra handling required with existing (UCOMISS or UCOMISD) instructions. To make sure no new failures were introduced, tier1, tier2, and tier3 tests were run on builds with and without the changes. Additionally, the JTREG tests listed below were used to verify correctness with `-XX:-UseAPX` / `-XX:+UseAPX` options. The baseline build used is [OpenJDK v26-b26](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B26).
>> 
>> 1. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java`
>> 2. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFPComparison.java`
>> 3. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java`
>> 4. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestSignumVector.java`
>> 
>> Finally, the JMH micro-benchmark listed below was updated to separately exercise CMove and JMP code paths.
>> 
>> 1. `micro:test/micro/org/openjdk/bench/java/lang/FPComparison.java`
>> 
>> [1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10
>
> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also update copyright year in IREncodingPrinter.java

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1056:

> 1054:     }
> 1055:     jcc(Assembler::equal, DONE_LABEL);    // handle special case +0.0/-0.0, if argument is +0.0/-0.0, return argument
> 1056:     jcc(Assembler::parity, DONE_LABEL);   // handle special case NaN, if argument NaN, return NaN

It looks to me that these two could be replaced by one jcc.
For with AVX 10.2:
  jcc if Sign flag is set to DONE_LABEL
For without AVX 10.2:
  jcc if equal to DONE_LABEL

src/hotspot/cpu/x86/x86.ad line 1706:

> 1704:     __ setcc(Assembler::above, dst);
> 1705:     __ jcc(Assembler::aboveEqual, done);
> 1706:     __ movl(dst, -1);

This seems to be applicable for both with/without AVX 10.2.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2674351156
PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2674367618

From missa at openjdk.org  Fri Jan  9 01:14:36 2026
From: missa at openjdk.org (Mohamed Issa)
Date: Fri, 9 Jan 2026 01:14:36 GMT
Subject: RFR: 8371955: Support AVX10 floating point comparison instructions
 [v3]
In-Reply-To: <Hqdrxeu6tM5ewCBwOezQpKb94M1YSYeygeNktBZCHU8=.09b0dc2a-7d4a-4fbf-9bf1-89630360476d@github.com>
References: <xDRJgBQwsegqBOp50pIl-Mzkadb8U-QpYXxSv01Jaxc=.a4cd1675-eb08-4f08-87be-c7f66a88f37e@github.com>
 <_GAfe6pIqFre0blQwFU-JXJ79CCSk5Ft_kxJhcg0agw=.acf06ec5-399e-4c48-bd26-f15e8b647908@github.com>
 <Hqdrxeu6tM5ewCBwOezQpKb94M1YSYeygeNktBZCHU8=.09b0dc2a-7d4a-4fbf-9bf1-89630360476d@github.com>
Message-ID: <iXmlx8GbxQbmXn6CblM-gtInAgBlzzHpcBsU9nOYozI=.a5675bfc-4012-4cef-9740-1d967a331bff@github.com>

On Fri, 9 Jan 2026 00:26:17 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Also update copyright year in IREncodingPrinter.java
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1056:
> 
>> 1054:     }
>> 1055:     jcc(Assembler::equal, DONE_LABEL);    // handle special case +0.0/-0.0, if argument is +0.0/-0.0, return argument
>> 1056:     jcc(Assembler::parity, DONE_LABEL);   // handle special case NaN, if argument NaN, return NaN
> 
> It looks to me that these two could be replaced by one jcc.
> For with AVX 10.2:
>   jcc if Sign flag is set to DONE_LABEL
> For without AVX 10.2:
>   jcc if equal to DONE_LABEL

Yes, that would work. The code becomes a little more cryptic, but it should be fine with enough explanation in the comments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2674435533

From ysuenaga at openjdk.org  Fri Jan  9 01:19:25 2026
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Fri, 9 Jan 2026 01:19:25 GMT
Subject: Withdrawn: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is
 incorrectly implemented
In-Reply-To: <SiBemHHhiHk3uDElvjRK16U2SNea7P1wsptA_4z7kxA=.0746951f-41b4-46b4-8397-40603dea6298@github.com>
References: <SiBemHHhiHk3uDElvjRK16U2SNea7P1wsptA_4z7kxA=.0746951f-41b4-46b4-8397-40603dea6298@github.com>
Message-ID: <u_mxQr2bDJLma5SUB0otMKDGTVG89fZ9NMVAh2xhHqs=.f821dc53-422c-4aec-89ae-a66f9dd1ef4f@github.com>

On Sat, 29 Nov 2025 06:06:16 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> The jtreg test TestEmergencyDumpAtOOM.java runs into the following error on ppc64 platforms.
> 
> JFR emergency dump would be kicked at `VMError::report_and_die()`, then Java thread for JFR would not work due to secondary signal handler for error reporting.
> 
> Passed all of jdk_jfr tests on Linux AMD64.

This pull request has been closed without being integrated.

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

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

From missa at openjdk.org  Fri Jan  9 01:28:16 2026
From: missa at openjdk.org (Mohamed Issa)
Date: Fri, 9 Jan 2026 01:28:16 GMT
Subject: RFR: 8371955: Support AVX10 floating point comparison instructions
 [v3]
In-Reply-To: <Hqdrxeu6tM5ewCBwOezQpKb94M1YSYeygeNktBZCHU8=.09b0dc2a-7d4a-4fbf-9bf1-89630360476d@github.com>
References: <xDRJgBQwsegqBOp50pIl-Mzkadb8U-QpYXxSv01Jaxc=.a4cd1675-eb08-4f08-87be-c7f66a88f37e@github.com>
 <_GAfe6pIqFre0blQwFU-JXJ79CCSk5Ft_kxJhcg0agw=.acf06ec5-399e-4c48-bd26-f15e8b647908@github.com>
 <Hqdrxeu6tM5ewCBwOezQpKb94M1YSYeygeNktBZCHU8=.09b0dc2a-7d4a-4fbf-9bf1-89630360476d@github.com>
Message-ID: <ahI50w9-uSd-4xiVQcpSr2seDmMI2ZAgcK--B3TZO1A=.2c597410-635e-437c-bc9d-1cc88c79061e@github.com>

On Fri, 9 Jan 2026 00:32:09 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Also update copyright year in IREncodingPrinter.java
>
> src/hotspot/cpu/x86/x86.ad line 1706:
> 
>> 1704:     __ setcc(Assembler::above, dst);
>> 1705:     __ jcc(Assembler::aboveEqual, done);
>> 1706:     __ movl(dst, -1);
> 
> This seems to be applicable for both with/without AVX 10.2.

Yes, I'll merge and add comments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2674476014

From duke at openjdk.org  Fri Jan  9 04:17:07 2026
From: duke at openjdk.org (duke)
Date: Fri, 9 Jan 2026 04:17:07 GMT
Subject: Withdrawn: 8371048: ImageFileReader::open fails to check return value
 of osSupport::map_memory
In-Reply-To: <tMiURM1fFzdKlQ3PLifstr4XjkRclx2CdCrkpD7wmFA=.32d24cfb-d4ff-433f-876c-ba8bdb0f4247@github.com>
References: <tMiURM1fFzdKlQ3PLifstr4XjkRclx2CdCrkpD7wmFA=.32d24cfb-d4ff-433f-876c-ba8bdb0f4247@github.com>
Message-ID: <sEKvOIkX1cKMntZyTYx40ossyP7gCeAyl4TjsPF3_38=.3dc8de32-4998-4806-9a0c-2ec6979606c9@github.com>

On Fri, 31 Oct 2025 14:00:38 GMT, Justin King <jcking at openjdk.org> wrote:

> Check whether `osSupport::map_memory` actually succeeded in all compliation modes, instead of crashing shortly after in non-debug builds. Ideally we should fall back to just reading the entire file into memory manually or use seek+read, but this is good enough for now to avoid crashing.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Fri Jan  9 04:44:39 2026
From: duke at openjdk.org (duke)
Date: Fri, 9 Jan 2026 04:44:39 GMT
Subject: Withdrawn: 8369828: Generalize share/utilities/bytes.hpp
In-Reply-To: <l8CneheSGfOkJMr5wHhwjMBbylD_zu4j8L197lbnT0M=.78bf14ce-d59e-4de9-a51d-b6f207b4a750@github.com>
References: <l8CneheSGfOkJMr5wHhwjMBbylD_zu4j8L197lbnT0M=.78bf14ce-d59e-4de9-a51d-b6f207b4a750@github.com>
Message-ID: <WJXyIkmqWJfVGepVHXtTjgmR31QSA5jC4urGLDZ8ywI=.3d30d74c-e56f-4cba-af20-a5421c1b2ce3@github.com>

On Tue, 14 Oct 2025 13:20:40 GMT, Justin King <jcking at openjdk.org> wrote:

> Implement portable `share/utilities/bytes.hpp` and remove CPU-specific headers.

This pull request has been closed without being integrated.

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

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

From shade at openjdk.org  Fri Jan  9 07:19:42 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 9 Jan 2026 07:19:42 GMT
Subject: RFR: 8374698: Stub names should look more like identifiers [v2]
In-Reply-To: <bd9g-wJdlXSzlSplooeUFC9SZyjUuUjPT57d3xmE0gg=.eb54555f-9d49-4abf-9a57-76bc939e2578@github.com>
References: <41ClGzK_bnZ3nmexlGdQW7Ncdh1q31ZDX_KZ1vBPNb4=.49a051e8-9345-4fe5-b635-efe44a21c051@github.com>
 <bd9g-wJdlXSzlSplooeUFC9SZyjUuUjPT57d3xmE0gg=.eb54555f-9d49-4abf-9a57-76bc939e2578@github.com>
Message-ID: <tnauBuzZqfD_n-tpG_i8_Zy4lCIwDthcktsmfQOXt_4=.5e0bb796-8085-4416-a5fc-324f3a4e869a@github.com>

On Wed, 7 Jan 2026 12:25:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Noticed this when looking at disassembly. Cosmetic issue in [JDK-8360707](https://bugs.openjdk.org/browse/JDK-8360707) makes the stub identifiers look fairly weird:
>> 
>> 
>> 0x0000786da3c1a6f2: call Stub::Stub Generator lookup_secondary_supers_table_slow_path_stub
>>     ; {runtime_call Stub::Stub Generator lookup_secondary_supers_table_slow_path_stub}
>> 
>> 
>> Notice "Stub Generator" in the middle of the stub identifier.
>> 
>> After the fix:
>> 
>> 
>> 0x00007f357bc1a3f2:   call   Stub::lookup_secondary_supers_table_slow_path_stub (stub gen)
>>      ; {runtime_call Stub::lookup_secondary_supers_table_slow_path_stub (stub gen)}
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Of course there are asserts that verify stub names directly

Thanks folks! Here goes.

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

PR Comment: https://git.openjdk.org/jdk/pull/29080#issuecomment-3727512879

From shade at openjdk.org  Fri Jan  9 07:19:43 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 9 Jan 2026 07:19:43 GMT
Subject: Integrated: 8374698: Stub names should look more like identifiers
In-Reply-To: <41ClGzK_bnZ3nmexlGdQW7Ncdh1q31ZDX_KZ1vBPNb4=.49a051e8-9345-4fe5-b635-efe44a21c051@github.com>
References: <41ClGzK_bnZ3nmexlGdQW7Ncdh1q31ZDX_KZ1vBPNb4=.49a051e8-9345-4fe5-b635-efe44a21c051@github.com>
Message-ID: <7Awhj3DjhP-UYjdn1bKTn5_8dL0FzqZDUo1_5-rk8qE=.a97733e0-1f1d-4c71-b6bf-8269c2043bec@github.com>

On Wed, 7 Jan 2026 09:12:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Noticed this when looking at disassembly. Cosmetic issue in [JDK-8360707](https://bugs.openjdk.org/browse/JDK-8360707) makes the stub identifiers look fairly weird:
> 
> 
> 0x0000786da3c1a6f2: call Stub::Stub Generator lookup_secondary_supers_table_slow_path_stub
>     ; {runtime_call Stub::Stub Generator lookup_secondary_supers_table_slow_path_stub}
> 
> 
> Notice "Stub Generator" in the middle of the stub identifier.
> 
> After the fix:
> 
> 
> 0x00007f357bc1a3f2:   call   Stub::lookup_secondary_supers_table_slow_path_stub (stub gen)
>      ; {runtime_call Stub::lookup_secondary_supers_table_slow_path_stub (stub gen)}

This pull request has now been integrated.

Changeset: 42313289
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/423132895d4ee787d13daa412f9a3f9438834117
Stats:     26 lines in 5 files changed: 10 ins; 3 del; 13 mod

8374698: Stub names should look more like identifiers

Reviewed-by: adinn, kvn

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

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

From alanb at openjdk.org  Fri Jan  9 08:04:24 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 Jan 2026 08:04:24 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command [v3]
In-Reply-To: <XuGzZPQlzToWgViTRRHCfcX8Yab3I0eN0LvK5icr6A8=.47c37362-fd31-441e-aa0c-ad030a96f004@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <ZZrvr-QWrDu5tglz1eEZ_XU-HV5aROHbuLw0dCeUTTM=.712f8dd5-d5db-43da-aa7b-c39631da7597@github.com>
 <0n3cejZUsIIyKQqkBh36ykAx9bhB_GApD7l14BCBjX0=.2fd420ac-ea86-41ef-a1f9-927b8032b670@github.com>
 <XuGzZPQlzToWgViTRRHCfcX8Yab3I0eN0LvK5icr6A8=.47c37362-fd31-441e-aa0c-ad030a96f004@github.com>
Message-ID: <BPQSgCDzySWsGDQ8aLbw6-lrt6QUvf0_1ji46PKKtGg=.b09d4fe8-5715-4b25-a834-0426dd4fdc09@github.com>

On Thu, 8 Jan 2026 22:08:21 GMT, Larry Cable <duke at openjdk.org> wrote:

>> src/hotspot/share/services/attachListener.cpp line 308:
>> 
>>> 306: }
>>> 307: 
>>> 308: // Implementation of "properties -security" command.
>> 
>> We don't need this: the attach API provides some basic commands, but most of the time we use the "jcmd" attach api command, which runs a DiagnosticCommand.  That's how we attach and run VM.properties etc...
>> 
>> This makes your life easier, we don't need serializeSecurityPropertiesToByteArray(), just updated DCmd and register_DCMDFactory lines.
>> (you'll need to merge in the later repo changes and resolve the register_DCMDFactory changes)
>
> I agree, this functionality should probably be added to the existing VM.system_properties jcmd as an option (if necessary)

Just some more history there. The reason the attachListener knows about the system properties command is because it dates back to JDK 6 when we introduced the attach mechanism and the Attach API. The Attach API defines VirtualMachine::getSystemProperties so both the tool and VM know about this "command". This all pre-dates jcmd and the diagnostic command framework that has been added since then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29124#discussion_r2675223455

From thartmann at openjdk.org  Fri Jan  9 08:35:33 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 9 Jan 2026 08:35:33 GMT
Subject: RFR: 8374570: Assertion failure in ClearArray.java  with
 -XX:+EnableX86EcoreOpts [v3]
In-Reply-To: <b5E6T8TII6aHjg9dxvq2GUGEEkQWRgfETU71t3iLgtg=.ebc5a0d4-b8b2-4a93-9c7f-853cf8798f8c@github.com>
References: <Ktp_W59MQVNSQ6YyBicFyIGJpb3SH7hPyjMuWIm2uUY=.795faf4d-5111-43e0-9fc7-91426382615f@github.com>
 <b5E6T8TII6aHjg9dxvq2GUGEEkQWRgfETU71t3iLgtg=.ebc5a0d4-b8b2-4a93-9c7f-853cf8798f8c@github.com>
Message-ID: <P9Lkjk2nO4yk_kEgCrpFxScHErvEcKtpNF_pFXOO16g=.5145f10a-6ed4-47a3-bc43-d39cb8ea913c@github.com>

On Thu, 8 Jan 2026 15:38:53 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> Allow for a larger jump distance
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   testcase change

test/hotspot/jtreg/compiler/c2/ClearArray.java line 36:

> 34:  * @run main/othervm -XX:+UnlockDiagnosticVMOptions -XX:+IgnoreUnrecognizedVMOptions -XX:-TieredCompilation -Xbatch
> 35:  *   -XX:InitArrayShortSize=32768 -XX:MaxVectorSize=8 -XX:-IdealizeClearArrayNode -XX:UseAVX=3 compiler.c2.ClearArray
> 36:  * @run main/othervm -XX:+UnlockDiagnosticVMOptions -XX:+IgnoreUnrecognizedVMOptions -XX:-TieredCompilation -Xbatch

Please add the bug number to the `@bug` tag and also update the copyright. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29070#discussion_r2675301374

From rrich at openjdk.org  Fri Jan  9 08:38:03 2026
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 9 Jan 2026 08:38:03 GMT
Subject: RFR: 8374769: PPC: MASM::pop_cont_fastpath() should reset
 _cont_fastpath if SP == _cont_fastpath
Message-ID: <bYRAqz2IVWD7Mkt9_ex1pJFS0UZyR5IoJfc1-3ZP9Bc=.7a9248a8-c674-40fa-ac94-2cd3c76a0b10@github.com>

This pr changes `MacroAssembler::pop_cont_fastpath()` to reset `JavaThread::_cont_fastpath` also if it is equal to the current sp as it is done on x86 and aarch64.

Background:

`JavaThread::_cont_fastpath` is set to the sp of the oldest (highest) known interpreted frame inside the continuation. It prevents fast path freezing if set.

Setting is lazy, e.g. only in i2c transitions. This is sufficient because freezing is done with a special native wrapper (see `gen_continuation_yield`). So if there is an interpreted frame in the continuation an i2c transition is required to call it.

There is only one location where a possible fast path freeze might be missed on the slow path for synchronization in a native wrapper:
 [SharedRuntime::generate_native_wrapper()](https://github.com/openjdk/jdk/blob/78b1ca6cc14e1a92bf25cbcfb687067ac17af92b/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp#L2402-L2404)
```c++
2402	    __ push_cont_fastpath();
2403	    __ call_VM_leaf(CAST_FROM_FN_PTR(address, SharedRuntime::complete_monitor_locking_C), r_oop, r_box, R16_thread);
2404	    __ pop_cont_fastpath();

`pop_cont_fastpath()` at L2404 fails to reset `_cont_fastpath` if it was set at L2402. Consequently a fast path freeze can be missed when returning from the native method.

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

Commit messages:
 - Fix

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

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

From rrich at openjdk.org  Fri Jan  9 08:38:04 2026
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 9 Jan 2026 08:38:04 GMT
Subject: RFR: 8374769: PPC: MASM::pop_cont_fastpath() should reset
 _cont_fastpath if SP == _cont_fastpath
In-Reply-To: <bYRAqz2IVWD7Mkt9_ex1pJFS0UZyR5IoJfc1-3ZP9Bc=.7a9248a8-c674-40fa-ac94-2cd3c76a0b10@github.com>
References: <bYRAqz2IVWD7Mkt9_ex1pJFS0UZyR5IoJfc1-3ZP9Bc=.7a9248a8-c674-40fa-ac94-2cd3c76a0b10@github.com>
Message-ID: <tOM8QLvx5lqzUZblBtnzG6ROkSrDoF-TOx0Tly5v6HY=.bcf63c8c-61f6-4e1c-9a1f-28e5ccda887b@github.com>

On Fri, 9 Jan 2026 08:17:53 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This pr changes `MacroAssembler::pop_cont_fastpath()` to reset `JavaThread::_cont_fastpath` also if it is equal to the current sp as it is done on x86 and aarch64.
> 
> Background:
> 
> `JavaThread::_cont_fastpath` is set to the sp of the oldest (highest) known interpreted frame inside the continuation. It prevents fast path freezing if set.
> 
> Setting is lazy, e.g. only in i2c transitions. This is sufficient because freezing is done with a special native wrapper (see `gen_continuation_yield`). So if there is an interpreted frame in the continuation an i2c transition is required to call it.
> 
> There is only one location where a possible fast path freeze might be missed on the slow path for synchronization in a native wrapper:
>  [SharedRuntime::generate_native_wrapper()](https://github.com/openjdk/jdk/blob/78b1ca6cc14e1a92bf25cbcfb687067ac17af92b/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp#L2402-L2404)
> ```c++
> 2402	    __ push_cont_fastpath();
> 2403	    __ call_VM_leaf(CAST_FROM_FN_PTR(address, SharedRuntime::complete_monitor_locking_C), r_oop, r_box, R16_thread);
> 2404	    __ pop_cont_fastpath();
> 
> `pop_cont_fastpath()` at L2404 fails to reset `_cont_fastpath` if it was set at L2402. Consequently a fast path freeze can be missed when returning from the native method.

The difference to other platforms was the reason that the reproducer for JDK-8372591 did not work on ppc.
See https://github.com/openjdk/jdk/pull/28830#issuecomment-3671801749

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

PR Comment: https://git.openjdk.org/jdk/pull/29133#issuecomment-3727781549

From thartmann at openjdk.org  Fri Jan  9 08:40:57 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 9 Jan 2026 08:40:57 GMT
Subject: [jdk26] RFR: 8351889: C2 crash: assertion failed: Base pointers
 must match (addp 344) [v2]
In-Reply-To: <N1iGJbSKyIhTwoboAQogbwcOZ51ily8lIWkHAGyNg70=.d69a5091-8303-4e94-b534-0074d53b09e6@github.com>
References: <pGBYr16YEbYzSHyQTnMK1EFzWv2dLR2P19P_gzEo7Bo=.0fc3368f-4917-4145-a178-845efaeaa1bd@github.com>
 <N1iGJbSKyIhTwoboAQogbwcOZ51ily8lIWkHAGyNg70=.d69a5091-8303-4e94-b534-0074d53b09e6@github.com>
Message-ID: <2bdHW_mOgPUvd8Zb8nce0D2uzw99zHgHnRnlbVifnus=.8ca9cd5c-6cd5-4b52-9df4-7f4662a2b7e2@github.com>

On Mon, 5 Jan 2026 09:32:22 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [ad29642d](https://github.com/openjdk/jdk/commit/ad29642d8f4e8e0fb1223b14b85ab7841d7b1b51) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by Roland Westrelin on 15 Dec 2025 and was reviewed by Roberto Casta?eda Lozano and Emanuel Peter.
>> 
>> Thanks!
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'jdk26' into backport-rwestrel-ad29642d-jdk26
>  - Backport ad29642d8f4e8e0fb1223b14b85ab7841d7b1b51

Roberto is still on vacation. I think we are good here. Ship it!

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28893#pullrequestreview-3642917244

From roland at openjdk.org  Fri Jan  9 08:43:17 2026
From: roland at openjdk.org (Roland Westrelin)
Date: Fri, 9 Jan 2026 08:43:17 GMT
Subject: [jdk26] Integrated: 8351889: C2 crash: assertion failed:  Base
 pointers must match (addp 344)
In-Reply-To: <pGBYr16YEbYzSHyQTnMK1EFzWv2dLR2P19P_gzEo7Bo=.0fc3368f-4917-4145-a178-845efaeaa1bd@github.com>
References: <pGBYr16YEbYzSHyQTnMK1EFzWv2dLR2P19P_gzEo7Bo=.0fc3368f-4917-4145-a178-845efaeaa1bd@github.com>
Message-ID: <DjZZNvdczg9RlzSj9UfPu-XS3RQsOxgg3ttEyq6dVLQ=.fe0cfd20-66a7-4ced-8e8f-17006ee821d2@github.com>

On Thu, 18 Dec 2025 08:31:35 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [ad29642d](https://github.com/openjdk/jdk/commit/ad29642d8f4e8e0fb1223b14b85ab7841d7b1b51) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Roland Westrelin on 15 Dec 2025 and was reviewed by Roberto Casta?eda Lozano and Emanuel Peter.
> 
> Thanks!

This pull request has now been integrated.

Changeset: e0f1c3a7
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e0f1c3a7463796afd0d67a1d57cc39f3a50c5cfd
Stats:     159 lines in 10 files changed: 148 ins; 3 del; 8 mod

8351889: C2 crash: assertion failed:  Base pointers must match (addp 344)

Reviewed-by: rcastanedalo, thartmann
Backport-of: ad29642d8f4e8e0fb1223b14b85ab7841d7b1b51

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

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

From sjohanss at openjdk.org  Fri Jan  9 08:47:01 2026
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 9 Jan 2026 08:47:01 GMT
Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v3]
In-Reply-To: <F0yu8OvqtdnssFD3SQoQ4DItAxBELEvwD1aAei2J5M8=.df501c22-ac18-4742-a0ab-ec6d1848be1f@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
 <F0yu8OvqtdnssFD3SQoQ4DItAxBELEvwD1aAei2J5M8=.df501c22-ac18-4742-a0ab-ec6d1848be1f@github.com>
Message-ID: <CNxPXaG8qXqVrPo5NsiiGa6M6r3hPE9UcLKaDYkr5is=.26f84708-d442-45b0-b787-fda252292bee@github.com>

On Wed, 7 Jan 2026 12:58:43 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`.  Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads.
>> 
>> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads.
>> 
>> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253.
>> 
>> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look.
>
> Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 564 commits:
> 
>  - Merge branch '8373253' into 8367993
>  - Merge branch 'master' into _8373253
>  - Merge branch 'master' into _8367993
>  - 8366058: Outdated comment in WinCAPISeedGenerator
>    
>    Reviewed-by: mullan
>  - 8357258: x86: Improve receiver type profiling reliability
>    
>    Reviewed-by: kvn, vlivanov
>  - 8373704: Improve "SocketException: Protocol family unavailable" message
>    
>    Reviewed-by: lucy, jpai
>  - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently
>    
>    Reviewed-by: jiefu, jbhateja, erfang, qamai
>  - 8343809: Add requires tag to mark tests that are incompatible with exploded image
>    
>    Reviewed-by: alanb, dholmes
>  - 8374465: Spurious dot in documentation for JVMTI ClassLoad
>    
>    Reviewed-by: kbarrett
>  - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket
>    
>    Reviewed-by: djelinski, mpowers, ascarpino
>  - ... and 554 more: https://git.openjdk.org/jdk/compare/2aa8aa4b...28ccbb68

Thanks for looking into this Leo. 

Overall I think it looks good, just some small questions and suggestions.

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1637:

> 1635: 
> 1636: bool G1CollectedHeap::concurrent_mark_is_terminating() const {
> 1637:   assert(_cm != nullptr, "thread must exist in order to check if mark is terminating");

I think it would make sense to add `&& _cm->is_fully_initialized()` to really make sure the thread has been created.

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2427:

> 2425:   if (_cm->is_fully_initialized()) {
> 2426:     tc->do_thread(_cm->cm_thread());
> 2427:   }

Since the _cm_thread is now in `G1ConcurrentMark` this should be handled in `G1ConcurrentMark::threads_do()`

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2549:

> 2547: void G1CollectedHeap::start_concurrent_cycle(bool concurrent_operation_is_full_mark) {
> 2548:   assert(!_cm->in_progress(), "Can not start concurrent operation while in progress");
> 2549:   assert(_cm->is_fully_initialized(), "sanity");

Not sure this sanity assert is needed `_cm->in_progress()` will always return `false` if not fully initialized, so the above assert will cover this. If we still want it, I think it should be moved above the `in_progress()` assert.

src/hotspot/share/gc/g1/g1PeriodicGCTask.cpp line 46:

> 44:     return false;
> 45:   }
> 46: 

Why is this needed? The initial young collection will make sure concurrent marking gets initialized, right?

src/hotspot/share/gc/g1/g1Policy.cpp line 744:

> 742:   if (!_g1h->concurrent_mark()->is_fully_initialized()) {
> 743:     return false;
> 744:   }

Is this needed? The `in_progress()` check below makes sure to only check the cm_thread when fully initialized.

src/hotspot/share/gc/g1/g1YoungCollector.cpp line 1127:

> 1125: 
> 1126: void G1YoungCollector::collect() {
> 1127:   _g1h->_cm->fully_initialize();

I think it would make more sense to do this in `G1CollectedHeap::do_collection_pause_at_safepoint()`. There we check if we should start concurrent mark, so maybe the initialization could be done only if we are about to start concurrent mark. If we can do the initialization after the actual young collection, then we could maybe even move the initialization into `G1CollectedHeap::start_concurrent_cycle(...)`

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

Changes requested by sjohanss (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28723#pullrequestreview-3639436840
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2672366755
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675276733
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675291347
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675313622
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675328503
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675249630

From alanb at openjdk.org  Fri Jan  9 08:53:59 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 Jan 2026 08:53:59 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command [v4]
In-Reply-To: <BOeQkw3Zf4yrkz_kWLcylC-FrtG4saZLnSSdnxCZbNI=.73818470-7d62-4207-bf04-b149b3db99a3@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <BOeQkw3Zf4yrkz_kWLcylC-FrtG4saZLnSSdnxCZbNI=.73818470-7d62-4207-bf04-b149b3db99a3@github.com>
Message-ID: <2vYchq-CkYIofednbT3mCis7UFBKeajU134sdoyssRo=.015da7ff-63ba-4105-8054-1991c339d742@github.com>

On Thu, 8 Jan 2026 21:27:18 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
>> 
>> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.
>
> Kieran Farrell has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - merge
>  - rm unused code
>  - Merge remote-tracking branch 'origin/master' into sec_props2
>  - static helper method for both jcmd calls
>  - missing )
>  - working with single arg
>  - updates
>  - update args
>  - two args -not yet tested
>  - initial patch

> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.

Security properties are a somewhat niche set of non-system properties for the security/crypto area. They can't be set on the command line, need to use -Djava.security.properties==<url>  to locate a properties file to augment the security properties defined in java.security. So very confusing to developers and maybe it's time to think about whether security properties make sense in 2026.

As regards the proposal then my initial reaction is to keep it separate, meaning a security_properties rather than properties command.

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

PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3727870283

From stefank at openjdk.org  Fri Jan  9 09:05:27 2026
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 Jan 2026 09:05:27 GMT
Subject: RFR: 8372040: Remove Prefetch header vs inline header separation
In-Reply-To: <_poEM0jDKsWBuurL7QIKXnl9fBQV596DFHgNIcNPUpI=.4c229767-47d5-4997-ad45-a53b622ded19@github.com>
References: <hOeaeFbD4gZoe74hyGLWmabC4W4PWuyd7IM0imO4MrU=.555401d0-b3da-4e2a-85dd-2758b3912d70@github.com>
 <_poEM0jDKsWBuurL7QIKXnl9fBQV596DFHgNIcNPUpI=.4c229767-47d5-4997-ad45-a53b622ded19@github.com>
Message-ID: <k-VTydMhqTAO3wchRtDzjAlZgfBVMYuKh921wrhT3kU=.1070a39d-10f0-4833-8df6-25417eb0edac@github.com>

On Thu, 8 Jan 2026 19:55:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Given the OS_CPU_HEADER_INLINE files are not intended to be included directly by anything except their shared counterpart, I think it looks very odd to write it as-if we expect it to be included directly. To me the comment, per orderAccess files suffices if this is a concern.

I somewhat agree. With a comment this helps readers enough.

The following is an explanation why I still think this is a bit unfortunate (but not enough to push further against this change):

IDEs don't always understand what's going. Another drawback is that you now can't compile the file stand-alone. That's not a problem for day-to-day building HotSpot, but for those of us that often clean out warnings in HotSpot, this makes it a tad bit more annoying when you can't compile the .hpp stand-alone. I compile .hpp files quite often. OTOH, I personally know enough of the HotSpot include systems so I'll compile prefetch.inline.hpp instead.

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

PR Comment: https://git.openjdk.org/jdk/pull/29096#issuecomment-3727906836

From kfarrell at openjdk.org  Fri Jan  9 09:54:08 2026
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Fri, 9 Jan 2026 09:54:08 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command [v5]
In-Reply-To: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
Message-ID: <3qlmxsr_9xjvyzplwqR6Q0Z5smdoGqVfQ7wsCiafad0=.daf5745a-4c15-420a-b76a-82a8543c2fdb@github.com>

> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
> 
> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.

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

  hide command

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29124/files
  - new: https://git.openjdk.org/jdk/pull/29124/files/6675081d..ee7d4707

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

  Stats: 65 lines in 1 file changed: 25 ins; 10 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/29124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29124/head:pull/29124

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

From stefank at openjdk.org  Fri Jan  9 09:54:34 2026
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 Jan 2026 09:54:34 GMT
Subject: RFR: 8374780: G1: Do not iterate klass metadata when splitting
 objArrays for every slice
In-Reply-To: <4iFTIPttYFA_jy2n-gPTPj-kKhbvifpaQ5pQWEW6xaQ=.71645432-df6a-4b6f-ac18-1d7d85cf2fb2@github.com>
References: <4iFTIPttYFA_jy2n-gPTPj-kKhbvifpaQ5pQWEW6xaQ=.71645432-df6a-4b6f-ac18-1d7d85cf2fb2@github.com>
Message-ID: <FzZbzUhBJbOdE_V2j90OdnHULEinSaCqKatTyB5O9Tk=.4eb3fec8-2cc8-4a4a-b032-69908838eb30@github.com>

On Thu, 8 Jan 2026 13:54:59 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that makes concurrent mark not try to iterate over `objArray` metadata for every slice, to make behavior uniform with other garbage collection types/garbage collectors.
> 
> Testing: tier1-5
> 
> Thanks,
>   Thomas

I agree that we should do a change like this.

I've given some feedback that I think the code would be easier to read if you operated on array indices instead of `MemRegion`. We do that in other GCs.

Then I have given some length comments about the oop iterate functions. I find their names misleading and inconsistent. I would like to take a stab at slightly tweaking them, if you don't mind. That can be done in parallel with this change, and doesn't block the PR.

src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp line 192:

> 190:   int start = checked_cast<int>(pointer_delta(MAX2(mr.start(), obj->base()), obj->base(), heapOopSize));
> 191:   int end = checked_cast<int>(pointer_delta(mr.end(), obj->base(), heapOopSize));
> 192:   obj->oop_iterate_range(_cm_oop_closure, start, end);

I think this becomes a bit obscure when the lines perform multiple tasks, and having one line per operation makes it easier to make sure that the code is correct.

If we look at the operations we also see an inconsistency between `start` and `end` calculation:

For `start` it calculates the lower boundary and then it converts to an index.
For `end` it *skips* calculating a upper boundary and then it converts to an index.

You need to read the callers to figure out if skipping calculating the upper boundary for `end` is correct.

I would strongly suggest that this code is rewritten so that `scan_objArray` takes a `start` and `end` as array indices, instead of using a `MemRegion`. And that the same is done for `process_array_slice`. I think then some of these casts and `pointer_deltas` will go away and the code will be easier to read and reason about.

src/hotspot/share/oops/objArrayKlass.hpp line 138:

> 136:   inline void oop_oop_iterate_bounded(oop obj, OopClosureType* closure, MemRegion mr);
> 137: 
> 138:   // Iterate over oop elements within [start, end) without metadata.

I know that you didn't change this, but this inconsistency in the API between `oop_oop_iterate_bounded` and `oop_oop_iterate_range` is unsettling. I think they both should be visiting the klass metadata if the obj falls within mr.

FWIW, the `InstanceKlass` implementation is also slightly different in that it checks if `mr` spans the start of `obj`:

ALWAYSINLINE void InstanceKlass::oop_oop_iterate_bounded(oop obj, OopClosureType* closure, MemRegion mr) {
  if (Devirtualizer::do_metadata(closure)) {
    if (mr.contains(obj)) {
      Devirtualizer::do_klass(closure, this);
    }
  }

I wonder if we should (maybe later) do an experiment where we check that we don't pass down a metadata-visiting closure when we iterate over a range. Similar to:

ALWAYSINLINE void InstanceKlass::oop_oop_iterate_reverse(oop obj, OopClosureType* closure) {
  assert(!Devirtualizer::do_metadata(closure),
      "Code to handle metadata is not implemented");

And then remove the metadata visiting from `oop_oop_iterate_bounded` as well.

src/hotspot/share/oops/objArrayOop.hpp line 86:

> 84: 
> 85: public:
> 86:   // Special iterator for index ranges.

This comment goes together with the one above in the objArrayKlass file. While looking at the various oop_oop_iterate functions in `ObjArrayKlass` I think it would be better if this was called `oop_iterate_elements`. Given the inconsistency described above, we might also have to do something about the `ObjArrayKlass::oop_oop_iterate_range` name. Let me take a closer look at these names separately from your patch.

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29116#pullrequestreview-3643080539
PR Review Comment: https://git.openjdk.org/jdk/pull/29116#discussion_r2675491836
PR Review Comment: https://git.openjdk.org/jdk/pull/29116#discussion_r2675445556
PR Review Comment: https://git.openjdk.org/jdk/pull/29116#discussion_r2675527141

From shade at openjdk.org  Fri Jan  9 09:55:01 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 9 Jan 2026 09:55:01 GMT
Subject: RFR: 8374878: Add Atomic<T>::compare_set
Message-ID: <F8TT0Z7lNzlE_gc5BjesYXWpZaDgCIcPo-8MS5HmIL4=.062534be-2f4b-4f58-b7a9-99348ff364cd@github.com>

Following up on [JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013) improvement, there is an opportunity to rewrite some of our low-level `cas(oldv, newv) == oldv` patterns to more straight-forward compare-and-set helper method. This is useful when you do not actually care about the result that used to be in memory or that is currently in memory.

Java atomics already have this distinction; arguably due to historical timeline of having compare-and-set before introducing compare-and-exchange.

Found this when converting Epsilon to Atomic<T> ([JDK-8374876](https://bugs.openjdk.org/browse/JDK-8374876)), where this method would simplify the code a bit. I looked around current uses of `compare_exchange` and rewrote them to `compare_set` to show what simplifications are possible.

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

Commit messages:
 - Indenting is a bit off
 - Fix

Changes: https://git.openjdk.org/jdk/pull/29135/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29135&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374878
  Stats: 55 lines in 7 files changed: 42 ins; 1 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/29135.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29135/head:pull/29135

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

From shade at openjdk.org  Fri Jan  9 09:55:02 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 9 Jan 2026 09:55:02 GMT
Subject: RFR: 8374878: Add Atomic<T>::compare_set
In-Reply-To: <F8TT0Z7lNzlE_gc5BjesYXWpZaDgCIcPo-8MS5HmIL4=.062534be-2f4b-4f58-b7a9-99348ff364cd@github.com>
References: <F8TT0Z7lNzlE_gc5BjesYXWpZaDgCIcPo-8MS5HmIL4=.062534be-2f4b-4f58-b7a9-99348ff364cd@github.com>
Message-ID: <Yj4mSEuRMTWJb4x1ys8AYKJGzNE7ctYbO-g-tv6ACXo=.d933907f-6702-4f78-bc0b-a80510b417f7@github.com>

On Fri, 9 Jan 2026 09:47:18 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Following up on [JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013) improvement, there is an opportunity to rewrite some of our low-level `cas(oldv, newv) == oldv` patterns to more straight-forward compare-and-set helper method. This is useful when you do not actually care about the result that used to be in memory or that is currently in memory.
> 
> Java atomics already have this distinction; arguably due to historical timeline of having compare-and-set before introducing compare-and-exchange.
> 
> Found this when converting Epsilon to Atomic<T> ([JDK-8374876](https://bugs.openjdk.org/browse/JDK-8374876)), where this method would simplify the code a bit. I looked around current uses of `compare_exchange` and rewrote them to `compare_set` to show what simplifications are possible.

@kimbarrett, tell me what you think. I can polish and test it further if this is sensible.

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

PR Comment: https://git.openjdk.org/jdk/pull/29135#issuecomment-3728135411

From stefank at openjdk.org  Fri Jan  9 10:10:20 2026
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 Jan 2026 10:10:20 GMT
Subject: RFR: 8374878: Add Atomic<T>::compare_set
In-Reply-To: <F8TT0Z7lNzlE_gc5BjesYXWpZaDgCIcPo-8MS5HmIL4=.062534be-2f4b-4f58-b7a9-99348ff364cd@github.com>
References: <F8TT0Z7lNzlE_gc5BjesYXWpZaDgCIcPo-8MS5HmIL4=.062534be-2f4b-4f58-b7a9-99348ff364cd@github.com>
Message-ID: <Htrbmy47ja-8G6XwidsGCKI9QXowbVYbNqUj-hgrZt4=.c3bbb011-cdd2-4cd4-91e3-3260e96eaf61@github.com>

On Fri, 9 Jan 2026 09:47:18 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Following up on [JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013) improvement, there is an opportunity to rewrite some of our low-level `cas(oldv, newv) == oldv` patterns to more straight-forward compare-and-set helper method. This is useful when you do not actually care about the result that used to be in memory or that is currently in memory.
> 
> Java atomics already have this distinction; arguably due to historical timeline of having compare-and-set before introducing compare-and-exchange.
> 
> Found this when converting Epsilon to Atomic<T> ([JDK-8374876](https://bugs.openjdk.org/browse/JDK-8374876)), where this method would simplify the code a bit. I looked around current uses of `compare_exchange` and rewrote them to `compare_set` to show what simplifications are possible.

Looks good to me, but let's at least wait for Kim's review.

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29135#pullrequestreview-3643260173

From jbhateja at openjdk.org  Fri Jan  9 10:28:00 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 9 Jan 2026 10:28:00 GMT
Subject: RFR: 8373480: Optimize multiplication by constant multiplier using
 LEA instructions [v6]
In-Reply-To: <UkGBrTojhlN0wbKjAp3yHcRWhOemePWwcU_RxcX4umQ=.31730bf4-6e63-4d57-8b4c-22df38f8e0b1@github.com>
References: <uo_ugfdLTrURHDpmWF4Xfh2Hspum8XDJNYsUjhAEc1I=.131ef8cd-e2f3-4d8c-981c-a701452cb264@github.com>
 <vTZKK9fSVJPpo0sIXV1s-2hRvTOSLt78JbB3PYxiQNk=.f790a1d3-a515-4544-a304-85d80f20a927@github.com>
 <-hubTcbRW128C1Uuvoq1xx9KfIFLnYGh8gUB757p6iA=.3596b81a-b8b8-491a-a709-7268e3300a92@github.com>
 <UkGBrTojhlN0wbKjAp3yHcRWhOemePWwcU_RxcX4umQ=.31730bf4-6e63-4d57-8b4c-22df38f8e0b1@github.com>
Message-ID: <WVyUMrLIBYBakcY2iAwK281I4HajfV-PgmE9lrUgqKE=.7136334f-c07d-40ec-9962-02d7351180ab@github.com>

On Thu, 8 Jan 2026 16:05:47 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/c2/TestConstantMultiplier.java line 89:
>> 
>>> 87:         ));
>>> 88:         var testTemplate1 = Template.make(() -> scope(
>>> 89:             IntStream.of(81, 73, 45, 41, 37, 27, 25, 21, 19, 13, 11).mapToObj(
>> 
>> Is there something special about these values? If yes: add a code comment :)
>> If no: could we add random values to the list to improve coverage and find edge cases?
>
> Ah, I see now that these are the values from your lookup table in the optimization.
> 
> I think it would still be good if you added random values, just for result verification.
> And only enable IR rules for the special values.

We also do some clever optimization for POT multiplier in MulI/MulLNode::Ideal routines which breaks multiplication into LShift/Add/Sub nodes and but its target agnostic.

Reason why I only selected these constants were because we are specifically handling these cases through optimum LEA based instruction sequence in the backend and Machine level IR annotation guarantees that required constant operand patten was indeed selected during matching.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28759#discussion_r2675631954

From jbhateja at openjdk.org  Fri Jan  9 10:28:05 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 9 Jan 2026 10:28:05 GMT
Subject: RFR: 8373480: Optimize multiplication by constant multiplier using
 LEA instructions [v6]
In-Reply-To: <-hubTcbRW128C1Uuvoq1xx9KfIFLnYGh8gUB757p6iA=.3596b81a-b8b8-491a-a709-7268e3300a92@github.com>
References: <uo_ugfdLTrURHDpmWF4Xfh2Hspum8XDJNYsUjhAEc1I=.131ef8cd-e2f3-4d8c-981c-a701452cb264@github.com>
 <vTZKK9fSVJPpo0sIXV1s-2hRvTOSLt78JbB3PYxiQNk=.f790a1d3-a515-4544-a304-85d80f20a927@github.com>
 <-hubTcbRW128C1Uuvoq1xx9KfIFLnYGh8gUB757p6iA=.3596b81a-b8b8-491a-a709-7268e3300a92@github.com>
Message-ID: <7vaiclFr4CafZJPXdzEDMSHZKKQ9KeE5h23NOetMI-A=.1d794b6e-e744-43b8-8407-2a00f24e81e9@github.com>

On Thu, 8 Jan 2026 16:06:51 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Extending micro and jtreg tests for memory patterns
>
> test/hotspot/jtreg/compiler/c2/TestConstantMultiplier.java line 102:
> 
>> 100:                         private static void runMultBy#{multiplier}I() {
>> 101:                             int multiplicand = RANDOM.nextInt();
>> 102:                             Verify.checkEQ(#{multiplier} * multiplicand, testMultBy#{multiplier}I(multiplicand));
> 
> I think that the `@Run` method also gets compiled, so probably both sides of the verification are compiled. Is that your intention? Probably not, right?

I didn't follow it, I don't intend to invoke Run in StandAlone Mode.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28759#discussion_r2675637149

From mgronlun at openjdk.org  Fri Jan  9 11:07:17 2026
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 9 Jan 2026 11:07:17 GMT
Subject: RFR: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is
 incorrectly implemented
In-Reply-To: <UokcXQpVFrVbpQRnd5sK-hOhLoODirZ6KpsmOXscv5w=.11b868a0-e570-4d7f-a057-8a49d5fc72ee@github.com>
References: <wlLXEGgDYePiM-XzCJJAmh-M2uycSiCuI3epumf-Byw=.3fd63eb6-6616-42f5-a6e1-daf7b3286317@github.com>
 <UokcXQpVFrVbpQRnd5sK-hOhLoODirZ6KpsmOXscv5w=.11b868a0-e570-4d7f-a057-8a49d5fc72ee@github.com>
Message-ID: <GXRuTPJodVvrpxM4Luil76RV95Q3OkQbSxmIDXeJkIs=.99a165fb-b72e-43d4-9700-d346bd49e670@github.com>

On Thu, 8 Jan 2026 21:42:16 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

> Is it better/possible to directly check the rotation lock instead? Maybe it's possible the thread crashed before starting the vm operation, or the lock is held by something else.

Lock testing is inherently racy, and would also include false negatives (i.e., say the rotation lock is currently held during a normal flush / rotation by the JFR Recorder Thread, then its perfectly fine even for the VM Thread to block waiting for it to be released).

It is only the above implication that makes it impossible for the VM Thread to wait on rotation lock release.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29094#discussion_r2675762122

From kfarrell at openjdk.org  Fri Jan  9 11:34:44 2026
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Fri, 9 Jan 2026 11:34:44 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command [v5]
In-Reply-To: <3qlmxsr_9xjvyzplwqR6Q0Z5smdoGqVfQ7wsCiafad0=.daf5745a-4c15-420a-b76a-82a8543c2fdb@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <3qlmxsr_9xjvyzplwqR6Q0Z5smdoGqVfQ7wsCiafad0=.daf5745a-4c15-420a-b76a-82a8543c2fdb@github.com>
Message-ID: <pFneoc7ufp19IH-oYIFksyL-V2JAzaUFk-I7-J4k_mQ=.7eba636f-5df9-42dc-81c8-61697cd50120@github.com>

On Fri, 9 Jan 2026 09:54:08 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
>> 
>> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.
>
> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   hide command

> Security properties are a somewhat niche set of non-system properties for the security/crypto area. They can't be set on the command line, need to use -Djava.security.properties== to locate a properties file to augment the security properties defined in java.security. So very confusing to developers and maybe it's time to think about whether security properties make sense in 2026.
> 
Should this PR be put on hold until such a disccusion takes place or maybe that would be something a little further down the line?

> As regards the proposal then my initial reaction is to keep it separate, meaning a security_properties rather than properties command.

My initial patch added a seperate command `VM.security_properties` but I merged the two following a suggestion reduce clutter in the the `jcmd <PID> help` output. Happy to revert to a seperate command if we proceed with this and there is a preference to do so.

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

PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3728531839

From mdoerr at openjdk.org  Fri Jan  9 11:47:48 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 9 Jan 2026 11:47:48 GMT
Subject: RFR: 8374769: PPC: MASM::pop_cont_fastpath() should reset
 _cont_fastpath if SP == _cont_fastpath
In-Reply-To: <bYRAqz2IVWD7Mkt9_ex1pJFS0UZyR5IoJfc1-3ZP9Bc=.7a9248a8-c674-40fa-ac94-2cd3c76a0b10@github.com>
References: <bYRAqz2IVWD7Mkt9_ex1pJFS0UZyR5IoJfc1-3ZP9Bc=.7a9248a8-c674-40fa-ac94-2cd3c76a0b10@github.com>
Message-ID: <zez5F7-vWQbYwmxxDoo5aQ_O_v_1H7zK7cqfWhJszOY=.4188f218-8e20-49bd-9c15-68a3ee22c563@github.com>

On Fri, 9 Jan 2026 08:17:53 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This pr changes `MacroAssembler::pop_cont_fastpath()` to reset `JavaThread::_cont_fastpath` also if it is equal to the current sp as it is done on x86 and aarch64.
> 
> Background:
> 
> `JavaThread::_cont_fastpath` is set to the sp of the oldest (highest) known interpreted frame inside the continuation. It prevents fast path freezing if set.
> 
> Setting is lazy, e.g. only in i2c transitions. This is sufficient because freezing is done with a special native wrapper (see `gen_continuation_yield`). So if there is an interpreted frame in the continuation an i2c transition is required to call it.
> 
> There is only one location where a possible fast path freeze might be missed on the slow path for synchronization in a native wrapper:
>  [SharedRuntime::generate_native_wrapper()](https://github.com/openjdk/jdk/blob/78b1ca6cc14e1a92bf25cbcfb687067ac17af92b/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp#L2402-L2404)
> ```c++
> 2402	    __ push_cont_fastpath();
> 2403	    __ call_VM_leaf(CAST_FROM_FN_PTR(address, SharedRuntime::complete_monitor_locking_C), r_oop, r_box, R16_thread);
> 2404	    __ pop_cont_fastpath();
> 
> `pop_cont_fastpath()` at L2404 fails to reset `_cont_fastpath` if it was set at L2402. Consequently a fast path freeze can be missed when returning from the native method.

LGTM.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29133#pullrequestreview-3643576220

From epeter at openjdk.org  Fri Jan  9 12:07:12 2026
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 9 Jan 2026 12:07:12 GMT
Subject: RFR: 8373480: Optimize multiplication by constant multiplier using
 LEA instructions [v6]
In-Reply-To: <WVyUMrLIBYBakcY2iAwK281I4HajfV-PgmE9lrUgqKE=.7136334f-c07d-40ec-9962-02d7351180ab@github.com>
References: <uo_ugfdLTrURHDpmWF4Xfh2Hspum8XDJNYsUjhAEc1I=.131ef8cd-e2f3-4d8c-981c-a701452cb264@github.com>
 <vTZKK9fSVJPpo0sIXV1s-2hRvTOSLt78JbB3PYxiQNk=.f790a1d3-a515-4544-a304-85d80f20a927@github.com>
 <-hubTcbRW128C1Uuvoq1xx9KfIFLnYGh8gUB757p6iA=.3596b81a-b8b8-491a-a709-7268e3300a92@github.com>
 <UkGBrTojhlN0wbKjAp3yHcRWhOemePWwcU_RxcX4umQ=.31730bf4-6e63-4d57-8b4c-22df38f8e0b1@github.com>
 <WVyUMrLIBYBakcY2iAwK281I4HajfV-PgmE9lrUgqKE=.7136334f-c07d-40ec-9962-02d7351180ab@github.com>
Message-ID: <xTcn-Qt_e8cz6tu93Z2HIiWTbqkTmYrdd5aBOfqsJ34=.31e073ac-63f2-4c33-8acd-9c7a66a4896d@github.com>

On Fri, 9 Jan 2026 10:20:40 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Ah, I see now that these are the values from your lookup table in the optimization.
>> 
>> I think it would still be good if you added random values, just for result verification.
>> And only enable IR rules for the special values.
>
> We also do some clever optimization for POT multiplier in MulI/MulLNode::Ideal routines which breaks multiplication into LShift/Add/Sub nodes and but its target agnostic.
> 
> Reason why I only selected these constants were because we are specifically handling these cases through optimum LEA based instruction sequence in the backend and Machine level IR annotation guarantees that required constant operand patten was indeed selected during matching.

Right I understand. But it is generally a good idea to not just verify your specific values, but also fuzz around a bit, just in case your optimization messes up and touches other cases near by.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28759#discussion_r2675947140

From stefank at openjdk.org  Fri Jan  9 12:09:22 2026
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 Jan 2026 12:09:22 GMT
Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v2]
In-Reply-To: <rncRewS4A4nkwvAkJRLAAJ-BhEGWXFxsGy8Pl-m0fNI=.af3d6a7d-6a61-4dee-a26a-d09e7215bc4e@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
 <Sqy2ecoZvJXHPHOfyOKzbCRID4cERqP9gbNciYUX6EY=.c44e3a4d-dfd6-44eb-8bab-668af696fd7b@github.com>
 <rncRewS4A4nkwvAkJRLAAJ-BhEGWXFxsGy8Pl-m0fNI=.af3d6a7d-6a61-4dee-a26a-d09e7215bc4e@github.com>
Message-ID: <aSHHOBAAdNFMkL3dy7qiMutT8mTtX0R5pLQU6kB4Diw=.38610782-7ad7-44f6-9d44-4cf8164b9562@github.com>

On Wed, 7 Jan 2026 12:33:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with 561 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into _8367993
>>  - 8366058: Outdated comment in WinCAPISeedGenerator
>>    
>>    Reviewed-by: mullan
>>  - 8357258: x86: Improve receiver type profiling reliability
>>    
>>    Reviewed-by: kvn, vlivanov
>>  - 8373704: Improve "SocketException: Protocol family unavailable" message
>>    
>>    Reviewed-by: lucy, jpai
>>  - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently
>>    
>>    Reviewed-by: jiefu, jbhateja, erfang, qamai
>>  - 8343809: Add requires tag to mark tests that are incompatible with exploded image
>>    
>>    Reviewed-by: alanb, dholmes
>>  - 8374465: Spurious dot in documentation for JVMTI ClassLoad
>>    
>>    Reviewed-by: kbarrett
>>  - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket
>>    
>>    Reviewed-by: djelinski, mpowers, ascarpino
>>  - 8374444: Fix simple -Wzero-as-null-pointer-constant warnings
>>    
>>    Reviewed-by: aboldtch
>>  - 8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the ?Nothing? menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test
>>    
>>    Reviewed-by: serb, aivanov, dnguyen
>>  - ... and 551 more: https://git.openjdk.org/jdk/compare/b907b295...0ece3767
>
> I will redo the merge, I have done something strange.

@lkorinth Something went wrong with your merge and now there's a bunch of unrelated labels, which results in updates being sent to misc mailing lists that has no interest in this PR. Could you remove all those labels?

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

PR Comment: https://git.openjdk.org/jdk/pull/28723#issuecomment-3728642315

From kbarrett at openjdk.org  Fri Jan  9 12:21:07 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 9 Jan 2026 12:21:07 GMT
Subject: RFR: 8372040: Remove Prefetch header vs inline header separation
In-Reply-To: <k-VTydMhqTAO3wchRtDzjAlZgfBVMYuKh921wrhT3kU=.1070a39d-10f0-4833-8df6-25417eb0edac@github.com>
References: <hOeaeFbD4gZoe74hyGLWmabC4W4PWuyd7IM0imO4MrU=.555401d0-b3da-4e2a-85dd-2758b3912d70@github.com>
 <_poEM0jDKsWBuurL7QIKXnl9fBQV596DFHgNIcNPUpI=.4c229767-47d5-4997-ad45-a53b622ded19@github.com>
 <k-VTydMhqTAO3wchRtDzjAlZgfBVMYuKh921wrhT3kU=.1070a39d-10f0-4833-8df6-25417eb0edac@github.com>
Message-ID: <5nRut_ycvMhKBQgZoGqSJDrurmWa-IIY5V3fLcSKfKY=.5b338580-9744-4dba-8d02-4264d27da6de@github.com>

On Fri, 9 Jan 2026 08:59:16 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> I compile .hpp files quite often.

+1. I occasionally think about writing a tool for this, perhaps also to be
used as part of a "build" test, but never seem to gather sufficient 'tuits.
But such a tool would need a mechanism for listing exceptions anyway...

A comment similar to that in the orderAccess files would suffice for me as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/29096#issuecomment-3728674425

From kbarrett at openjdk.org  Fri Jan  9 12:33:54 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 9 Jan 2026 12:33:54 GMT
Subject: RFR: 8374878: Add Atomic<T>::compare_set
In-Reply-To: <F8TT0Z7lNzlE_gc5BjesYXWpZaDgCIcPo-8MS5HmIL4=.062534be-2f4b-4f58-b7a9-99348ff364cd@github.com>
References: <F8TT0Z7lNzlE_gc5BjesYXWpZaDgCIcPo-8MS5HmIL4=.062534be-2f4b-4f58-b7a9-99348ff364cd@github.com>
Message-ID: <zvjalR8vEDtxxIFOaUpzH_L1zfsvEfd4l-vz8LL2k-A=.c6521228-70fd-476b-a9df-1894de069b95@github.com>

On Fri, 9 Jan 2026 09:47:18 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Following up on [JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013) improvement, there is an opportunity to rewrite some of our low-level `cas(oldv, newv) == oldv` patterns to more straight-forward compare-and-set helper method. This is useful when you do not actually care about the result that used to be in memory or that is currently in memory, you only care if CAS succeeded or not.
> 
> Java atomics already have this duality; arguably due to historical timeline of having compare-and-set before introducing compare-and-exchange.
> 
> Found this when converting Epsilon to Atomic<T> ([JDK-8374876](https://bugs.openjdk.org/browse/JDK-8374876)), where this method would simplify the code a bit. I looked around current uses of `compare_exchange` and rewrote them to `compare_set` to show what simplifications are possible.

I like this addition.  One optional suggestion.

src/hotspot/share/runtime/atomic.hpp line 273:

> 271:   bool compare_set(T compare_value, T new_value,
> 272:                    atomic_memory_order order = memory_order_conservative) {
> 273:     return AtomicAccess::cmpxchg(value_ptr(), compare_value, new_value, order) == compare_value;

I think I would prefer both this and (especially) the translated case be

return compare_exchange(compare_value, new_value, order) == compare_value;

rather than duplicating some of the respective `compare_exchange`
implementations. I won't block for this though.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29135#pullrequestreview-3643716862
PR Review Comment: https://git.openjdk.org/jdk/pull/29135#discussion_r2676010126

From shade at openjdk.org  Fri Jan  9 12:33:55 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 9 Jan 2026 12:33:55 GMT
Subject: RFR: 8374878: Add Atomic<T>::compare_set
In-Reply-To: <zvjalR8vEDtxxIFOaUpzH_L1zfsvEfd4l-vz8LL2k-A=.c6521228-70fd-476b-a9df-1894de069b95@github.com>
References: <F8TT0Z7lNzlE_gc5BjesYXWpZaDgCIcPo-8MS5HmIL4=.062534be-2f4b-4f58-b7a9-99348ff364cd@github.com>
 <zvjalR8vEDtxxIFOaUpzH_L1zfsvEfd4l-vz8LL2k-A=.c6521228-70fd-476b-a9df-1894de069b95@github.com>
Message-ID: <PT6pnqFSyz34d4E6_O9HKRmhuU3UhQJJ_TNn77NqfF8=.e79e9fbd-bf91-4ba8-b8bc-95a12bcf720a@github.com>

On Fri, 9 Jan 2026 12:26:29 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Following up on [JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013) improvement, there is an opportunity to rewrite some of our low-level `cas(oldv, newv) == oldv` patterns to more straight-forward compare-and-set helper method. This is useful when you do not actually care about the result that used to be in memory or that is currently in memory, you only care if CAS succeeded or not.
>> 
>> Java atomics already have this duality; arguably due to historical timeline of having compare-and-set before introducing compare-and-exchange.
>> 
>> Found this when converting Epsilon to Atomic<T> ([JDK-8374876](https://bugs.openjdk.org/browse/JDK-8374876)), where this method would simplify the code a bit. I looked around current uses of `compare_exchange` and rewrote them to `compare_set` to show what simplifications are possible.
>
> src/hotspot/share/runtime/atomic.hpp line 273:
> 
>> 271:   bool compare_set(T compare_value, T new_value,
>> 272:                    atomic_memory_order order = memory_order_conservative) {
>> 273:     return AtomicAccess::cmpxchg(value_ptr(), compare_value, new_value, order) == compare_value;
> 
> I think I would prefer both this and (especially) the translated case be
> 
> return compare_exchange(compare_value, new_value, order) == compare_value;
> 
> rather than duplicating some of the respective `compare_exchange`
> implementations. I won't block for this though.

Thanks. For non-translated version, I agree with the simplification.

For translated case: I actually thought it is a good thing to avoid calling `recover()` on return value, because it did not need to? Does it save anything, really?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29135#discussion_r2676021747

From epeter at openjdk.org  Fri Jan  9 12:36:02 2026
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 9 Jan 2026 12:36:02 GMT
Subject: RFR: 8373480: Optimize multiplication by constant multiplier using
 LEA instructions [v6]
In-Reply-To: <7vaiclFr4CafZJPXdzEDMSHZKKQ9KeE5h23NOetMI-A=.1d794b6e-e744-43b8-8407-2a00f24e81e9@github.com>
References: <uo_ugfdLTrURHDpmWF4Xfh2Hspum8XDJNYsUjhAEc1I=.131ef8cd-e2f3-4d8c-981c-a701452cb264@github.com>
 <vTZKK9fSVJPpo0sIXV1s-2hRvTOSLt78JbB3PYxiQNk=.f790a1d3-a515-4544-a304-85d80f20a927@github.com>
 <-hubTcbRW128C1Uuvoq1xx9KfIFLnYGh8gUB757p6iA=.3596b81a-b8b8-491a-a709-7268e3300a92@github.com>
 <7vaiclFr4CafZJPXdzEDMSHZKKQ9KeE5h23NOetMI-A=.1d794b6e-e744-43b8-8407-2a00f24e81e9@github.com>
Message-ID: <TGSjdwqfJsrMqxPQFpciZ58mHspgCZeWrDvuTM_FQqc=.cdb18812-1620-4763-ad4c-6d5c637a52d8@github.com>

On Fri, 9 Jan 2026 10:22:23 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/c2/TestConstantMultiplier.java line 102:
>> 
>>> 100:                         private static void runMultBy#{multiplier}I() {
>>> 101:                             int multiplicand = RANDOM.nextInt();
>>> 102:                             Verify.checkEQ(#{multiplier} * multiplicand, testMultBy#{multiplier}I(multiplicand));
>> 
>> I think that the `@Run` method also gets compiled, so probably both sides of the verification are compiled. Is that your intention? Probably not, right?
>
> I didn't follow it, I don't intend to invoke Run in StandAlone Mode.

Let me clarify:
- Your `@Run` gets invoked many times, eventually it will compile.
- You invoke the `testMultBy`, and eventually it will get compiled.
- Now, both the multiplication in the test, and the run method are compiled. If there was a bug, it would be the same wrong result in the test and run, verification would pass, and we would not catch the bug.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28759#discussion_r2676027884

From kbarrett at openjdk.org  Fri Jan  9 12:51:47 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 9 Jan 2026 12:51:47 GMT
Subject: RFR: 8374878: Add Atomic<T>::compare_set
In-Reply-To: <PT6pnqFSyz34d4E6_O9HKRmhuU3UhQJJ_TNn77NqfF8=.e79e9fbd-bf91-4ba8-b8bc-95a12bcf720a@github.com>
References: <F8TT0Z7lNzlE_gc5BjesYXWpZaDgCIcPo-8MS5HmIL4=.062534be-2f4b-4f58-b7a9-99348ff364cd@github.com>
 <zvjalR8vEDtxxIFOaUpzH_L1zfsvEfd4l-vz8LL2k-A=.c6521228-70fd-476b-a9df-1894de069b95@github.com>
 <PT6pnqFSyz34d4E6_O9HKRmhuU3UhQJJ_TNn77NqfF8=.e79e9fbd-bf91-4ba8-b8bc-95a12bcf720a@github.com>
Message-ID: <7rLOjIFkhzajElaT0Qb9Wo5BlC2ZsPKQhnDDmcCUa8Y=.b13dea73-6a0e-45dd-960e-c3e8f08a467e@github.com>

On Fri, 9 Jan 2026 12:30:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/runtime/atomic.hpp line 273:
>> 
>>> 271:   bool compare_set(T compare_value, T new_value,
>>> 272:                    atomic_memory_order order = memory_order_conservative) {
>>> 273:     return AtomicAccess::cmpxchg(value_ptr(), compare_value, new_value, order) == compare_value;
>> 
>> I think I would prefer both this and (especially) the translated case be
>> 
>> return compare_exchange(compare_value, new_value, order) == compare_value;
>> 
>> rather than duplicating some of the respective `compare_exchange`
>> implementations. I won't block for this though.
>
> Thanks. For non-translated version, I agree with the simplification.
> 
> For translated case: I actually thought it is a good thing to avoid calling `recover()` on return value, because it did not need to? Does it save anything, really?

I missed that detail about the translated case, and agree with that rationale.

Note that `decay` and `recover` are typically type interpretation conversions,
probably with no code generation involved. But that doesn't change the
conceptual argument for the current proposed code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29135#discussion_r2676072972

From duke at openjdk.org  Fri Jan  9 13:08:26 2026
From: duke at openjdk.org (jonghoonpark)
Date: Fri, 9 Jan 2026 13:08:26 GMT
Subject: RFR: 8372040: Remove Prefetch header vs inline header separation
In-Reply-To: <hOeaeFbD4gZoe74hyGLWmabC4W4PWuyd7IM0imO4MrU=.555401d0-b3da-4e2a-85dd-2758b3912d70@github.com>
References: <hOeaeFbD4gZoe74hyGLWmabC4W4PWuyd7IM0imO4MrU=.555401d0-b3da-4e2a-85dd-2758b3912d70@github.com>
Message-ID: <yb6RiiJUiaBJ0F9Ljk7tddKfEqPkZIIEQIKI_tpjxbU=.813c5a24-2906-4132-a876-372acc13c6bc@github.com>

On Wed, 7 Jan 2026 17:47:47 GMT, jonghoonpark <duke at openjdk.org> wrote:

> related jira issue: https://bugs.openjdk.org/browse/JDK-8372040
> 
> ---
> 
> ## Changes
> 
> - Merged `prefetch.hpp` into `prefetch.inline.hpp` and removed the redundant `prefetch.hpp`. Updated all call sites accordingly.
> - Removed `runtime/prefetch.inline.hpp` from `generation.hpp` to adhere to the rule that standard headers should not include inline headers.
>     - Added the inclusion of `runtime/prefetch.inline.hpp` to `cardTableRS.cpp` instead.
> - Removed `runtime/prefetch.hpp` from `g1YoungGCPostEvacuateTasks.cpp` as it is already included via `g1HeapRegion.inline.hpp`.
> 
> ---
> 
> Verified with tier1 testing; no regressions found.

Thank you for the insightful discussion and feedback.

To summarize the next steps, I will:

1. Explicitly include `prefetch.inline.hpp` in `g1YoungGCPostEvacuateTasks.cpp` to follow the "Include What You Use" principle.

2. Add a comment to each platform-dependent prefetch inline file (e.g., `prefetch_linux_x86.inline.hpp`) stating: `// Included in runtime/prefetch.inline.hpp`

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

PR Comment: https://git.openjdk.org/jdk/pull/29096#issuecomment-3728837840

From jbhateja at openjdk.org  Fri Jan  9 14:06:41 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 9 Jan 2026 14:06:41 GMT
Subject: RFR: 8373480: Optimize multiplication by constant multiplier using
 LEA instructions [v7]
In-Reply-To: <uo_ugfdLTrURHDpmWF4Xfh2Hspum8XDJNYsUjhAEc1I=.131ef8cd-e2f3-4d8c-981c-a701452cb264@github.com>
References: <uo_ugfdLTrURHDpmWF4Xfh2Hspum8XDJNYsUjhAEc1I=.131ef8cd-e2f3-4d8c-981c-a701452cb264@github.com>
Message-ID: <8ccfiOiaL6cfTltcKo3FxCUP1X8ECsW6JchUFt2YSkI=.5c44da1f-c19c-42ab-80d9-7e438a84536b@github.com>

> Emulate multiplier using LEA addressing scheme, where effective address = BASE + INDEX * SCALE + OFFSET
> Refer to section "3.5.1.2 Using LEA" of Intel's optimization manual for details reagarding slow vs fast lea instructions.
> Given that latency of IMUL with register operands is 3 cycles, a combination of two fast LEAs each with 1 cycle latency to emulate multipler is performant.
> 
> Consider X as the multiplicand, by variying the scale of  first LEA instruction we can generate 4 input i.e.
> 
> 
>     X + X * 1 = 2X
>     X + X * 2 = 3X
>     X + X * 4 = 5X
>     X + X * 8 = 9X
> 
> 
> Following table list downs various multiplier combinations for output of first LEA at BASE and/or INDEX by varying the 
> scale of second fast LEA instruction. We will only handle the cases which cannot be handled by just shift + add.
> 
> 
>       BASE   INDEX   SCALE  MULTIPLER
>         X      X       1       2       (Terminal)
>         X      X       2       3       (Terminal)
>         X      X       4       5       (Terminal)
>         X      X       8       9       (Terminal)
>        3X     3X       1       6
>         X     3X       2       7
>        5X     5X       1      10
>         X     5X       2      11
>         X     3X       4      13
>        5X     5X       2      15
>         X     2X       8      17
>        9X     9X       1      18
>         X     9X       2      19
>         X     5X       4      21
>        5X     5X       4      25
>        9X     9X       2      27
>         X     9X       4      37
>         X     5X       8      41
>        9X     9X       4      45
>         X     9X       8      73
>        9X     9X       8      81
> 
> 
> All the non-unity inputs tied to BASE / INDEX  are derived out of terminal cases which represent first FAST LEA. Thus, all the multipliers can be computed using just two LEA instructions.
> 
> Performance numbers for new micro benchmark included with this patch shows around **5-50% improvments** on latest x86 servers.
> 
> 
> System: INTEL(R) XEON(R) PLATINUM 8581C CPU @ 2.10GHz Emerald Rapids:-
> Baseline:-
> Benchmark                                             Mode  Cnt    Score   Error    Units
> ConstantMultiplierOptimization.testConstMultiplierI  thrpt    2  189.690          ops/min
> ConstantMultiplierOptimization.testConstMultiplierL  thrpt    2  196.283          ops/min
> 
> 
> Withopt:-
> Benchmark                                             Mode  Cnt    Score   Error    Units
> ConstantMultiplierOptimization.testConstMultiplierI  thrpt    2  283.827          ops/min
> ConstantMultiplierOptimization...

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

 - Review comments resolutions
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8373480
 - Extending micro and jtreg tests for memory patterns
 - Review comments resolutions
 - Minor cleanup in Template-Framework test
 - Using template-framework for JTREG test generation
 - Adding IR framework tests
 - Adding benchmark
 - 8373480: Optimize constant input multiplication using LEA instructions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28759/files
  - new: https://git.openjdk.org/jdk/pull/28759/files/b7756730..13c71c16

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28759&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28759&range=05-06

  Stats: 46866 lines in 3224 files changed: 20314 ins; 7158 del; 19394 mod
  Patch: https://git.openjdk.org/jdk/pull/28759.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28759/head:pull/28759

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

From jbhateja at openjdk.org  Fri Jan  9 14:06:42 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 9 Jan 2026 14:06:42 GMT
Subject: RFR: 8373480: Optimize multiplication by constant multiplier using
 LEA instructions [v6]
In-Reply-To: <TGSjdwqfJsrMqxPQFpciZ58mHspgCZeWrDvuTM_FQqc=.cdb18812-1620-4763-ad4c-6d5c637a52d8@github.com>
References: <uo_ugfdLTrURHDpmWF4Xfh2Hspum8XDJNYsUjhAEc1I=.131ef8cd-e2f3-4d8c-981c-a701452cb264@github.com>
 <vTZKK9fSVJPpo0sIXV1s-2hRvTOSLt78JbB3PYxiQNk=.f790a1d3-a515-4544-a304-85d80f20a927@github.com>
 <-hubTcbRW128C1Uuvoq1xx9KfIFLnYGh8gUB757p6iA=.3596b81a-b8b8-491a-a709-7268e3300a92@github.com>
 <7vaiclFr4CafZJPXdzEDMSHZKKQ9KeE5h23NOetMI-A=.1d794b6e-e744-43b8-8407-2a00f24e81e9@github.com>
 <TGSjdwqfJsrMqxPQFpciZ58mHspgCZeWrDvuTM_FQqc=.cdb18812-1620-4763-ad4c-6d5c637a52d8@github.com>
Message-ID: <-KKGCQRZroe5N_-ftHQBuyu2M2ukHJ8yZTCxPBngJGA=.de3f8524-5ab0-40d5-b024-dab49731d217@github.com>

On Fri, 9 Jan 2026 12:32:39 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> I didn't follow it, I don't intend to invoke Run in StandAlone Mode.
>
> Let me clarify:
> - Your `@Run` gets invoked many times, eventually it will compile.
> - You invoke the `testMultBy`, and eventually it will get compiled.
> - Now, both the multiplication in the test, and the run method are compiled. If there was a bug, it would be the same wrong result in the test and run, verification would pass, and we would not catch the bug.

Got it, fixed!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28759#discussion_r2676304297

From duke at openjdk.org  Fri Jan  9 14:10:42 2026
From: duke at openjdk.org (jonghoonpark)
Date: Fri, 9 Jan 2026 14:10:42 GMT
Subject: RFR: 8372040: Remove Prefetch header vs inline header separation
 [v2]
In-Reply-To: <hOeaeFbD4gZoe74hyGLWmabC4W4PWuyd7IM0imO4MrU=.555401d0-b3da-4e2a-85dd-2758b3912d70@github.com>
References: <hOeaeFbD4gZoe74hyGLWmabC4W4PWuyd7IM0imO4MrU=.555401d0-b3da-4e2a-85dd-2758b3912d70@github.com>
Message-ID: <Rh0k4q8mQYS6197JxYUIhYQ6Iv4n8rnN4cMY8r8OKaM=.25c0709a-e49e-4a45-b953-fad1749b3b90@github.com>

> related jira issue: https://bugs.openjdk.org/browse/JDK-8372040
> 
> ---
> 
> ## Changes
> 
> - Merged `prefetch.hpp` into `prefetch.inline.hpp` and removed the redundant `prefetch.hpp`. Updated all call sites accordingly.
> - Removed `runtime/prefetch.inline.hpp` from `generation.hpp` to adhere to the rule that standard headers should not include inline headers.
>     - Added the inclusion of `runtime/prefetch.inline.hpp` to `cardTableRS.cpp` instead.
> - Removed `runtime/prefetch.hpp` from `g1YoungGCPostEvacuateTasks.cpp` as it is already included via `g1HeapRegion.inline.hpp`.
> 
> ---
> 
> Verified with tier1 testing; no regressions found.

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

  Add explicit prefetch include and clarify platform dependencies
  
  Signed-off-by: jonghoonpark <dev at jonghoonpark.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29096/files
  - new: https://git.openjdk.org/jdk/pull/29096/files/23f96e21..f0a7117f

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

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

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

From alanb at openjdk.org  Fri Jan  9 14:33:22 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 Jan 2026 14:33:22 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command [v5]
In-Reply-To: <pFneoc7ufp19IH-oYIFksyL-V2JAzaUFk-I7-J4k_mQ=.7eba636f-5df9-42dc-81c8-61697cd50120@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <3qlmxsr_9xjvyzplwqR6Q0Z5smdoGqVfQ7wsCiafad0=.daf5745a-4c15-420a-b76a-82a8543c2fdb@github.com>
 <pFneoc7ufp19IH-oYIFksyL-V2JAzaUFk-I7-J4k_mQ=.7eba636f-5df9-42dc-81c8-61697cd50120@github.com>
Message-ID: <CuZJc6rlOnkQQcx_MnFCf88oo9v3VqdlH5eiRV6mNKs=.71e51174-39be-4540-b939-9b8ef01eef76@github.com>

On Fri, 9 Jan 2026 11:31:17 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

> My initial patch added a seperate command `VM.security_properties` 

Maybe revert to that as it's a better starting point to discuss.

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

PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3729139127

From stefank at openjdk.org  Fri Jan  9 14:38:29 2026
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 Jan 2026 14:38:29 GMT
Subject: RFR: 8372040: Remove Prefetch header vs inline header separation
 [v2]
In-Reply-To: <Rh0k4q8mQYS6197JxYUIhYQ6Iv4n8rnN4cMY8r8OKaM=.25c0709a-e49e-4a45-b953-fad1749b3b90@github.com>
References: <hOeaeFbD4gZoe74hyGLWmabC4W4PWuyd7IM0imO4MrU=.555401d0-b3da-4e2a-85dd-2758b3912d70@github.com>
 <Rh0k4q8mQYS6197JxYUIhYQ6Iv4n8rnN4cMY8r8OKaM=.25c0709a-e49e-4a45-b953-fad1749b3b90@github.com>
Message-ID: <1b5bZ4dnTl9J2GIWKpHg9DjIysgFdjEjLBMjkhFXh9k=.c14551ee-9012-4bf5-bb37-863b0c00741a@github.com>

On Fri, 9 Jan 2026 14:10:42 GMT, jonghoonpark <duke at openjdk.org> wrote:

>> related jira issue: https://bugs.openjdk.org/browse/JDK-8372040
>> 
>> ---
>> 
>> ## Changes
>> 
>> - Merged `prefetch.hpp` into `prefetch.inline.hpp` and removed the redundant `prefetch.hpp`. Updated all call sites accordingly.
>> - Removed `runtime/prefetch.inline.hpp` from `generation.hpp` to adhere to the rule that standard headers should not include inline headers.
>>     - Added the inclusion of `runtime/prefetch.inline.hpp` to `cardTableRS.cpp` instead.
>> - Removed `runtime/prefetch.hpp` from `g1YoungGCPostEvacuateTasks.cpp` as it is already included via `g1HeapRegion.inline.hpp`.
>> 
>> ---
>> 
>> Verified with tier1 testing; no regressions found.
>
> jonghoonpark has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add explicit prefetch include and clarify platform dependencies
>   
>   Signed-off-by: jonghoonpark <dev at jonghoonpark.com>

Looks good to me.

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29096#pullrequestreview-3644185575