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: References: Message-ID: On Sat, 29 Nov 2025 06:06:16 GMT, Yasumasa Suenaga 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: References: Message-ID: On Tue, 2 Dec 2025 14:56:49 GMT, Ruben 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: References: <15wAKoik-66gfbUzGQEROBTv_cTV_I_6jq96S2ErOyA=.22e19b52-220c-4c35-9aaa-9f08719e16fa@github.com> Message-ID: On Wed, 31 Dec 2025 16:06:53 GMT, Evgeny Astigeevich wrote: > > Is there any reason not to do this by default on all AArch64? > > It will be turned on if AArch64 has `ctr_el0.IDC` and `ctr_el0.DIC` set. See https://github.com/openjdk/jdk/pull/28328/changes#diff-a87e260510f34ca7d9b0feb089ad982be8268c5c8aa5a71221f6738b051ea488R663 Sure, I can see that, but is there any reason not to do this by default on all AArch64? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28328#issuecomment-3703679652 From 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: 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: References: Message-ID: <1-X6XEzhKOyBhAdV8K-43abGJWYx4IOhZvp3b1tlwto=.cfbc37ec-45e8-4b47-bff0-a8fc93ad61b3@github.com> On Tue, 16 Dec 2025 16:51:56 GMT, Leonid Mesnik 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: References: <15wAKoik-66gfbUzGQEROBTv_cTV_I_6jq96S2ErOyA=.22e19b52-220c-4c35-9aaa-9f08719e16fa@github.com> Message-ID: On Thu, 1 Jan 2026 13:13:07 GMT, Andrew Haley wrote: > Sure, I can see that, but is there any reason not to do this by default on all AArch64? Do you mean to do this for all AArch64 OSes, not only for Linux AArch64? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28328#issuecomment-3704085326 From aboldtch at openjdk.org Fri Jan 2 04: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: References: 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: References: Message-ID: > 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: References: Message-ID: > 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: References: Message-ID: On Tue, 16 Dec 2025 16:51:56 GMT, Leonid Mesnik 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: References: Message-ID: On Fri, 2 Jan 2026 05:12:47 GMT, Kim Barrett 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: References: Message-ID: <-Vb3RjzTqS7Lo9tMqVYqEbRQ1nYLg20mfcehWEe6Vm4=.e4dba3af-59af-42c9-b0bc-0d6e57122121@github.com> On Sat, 29 Nov 2025 06:06:16 GMT, Yasumasa Suenaga 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: References: Message-ID: > 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 [v2] In-Reply-To: References: Message-ID: > Please review this change to convert HotSpot gtests to use Atomic 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 [v2] In-Reply-To: References: Message-ID: > Please review these fairly simple changes to code in gc/shared to use > `Atomic` 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 [v2] In-Reply-To: References: Message-ID: > Please review this change to ConcurrentHashTable to use `Atomic` 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 [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: > Please review this change that adds a HotSpot wrapper for . 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 `` and `` to include the wrapper instead. > There are still a couple of includes of `` 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: References: Message-ID: On Fri, 2 Jan 2026 07:31:39 GMT, Axel Boldt-Christmas 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: References: Message-ID: On Thu, 1 Jan 2026 13:23:02 GMT, Kim Barrett 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 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 [v2] In-Reply-To: References: Message-ID: On Fri, 2 Jan 2026 10:08:26 GMT, Kim Barrett wrote: >> Please review this change to convert HotSpot gtests to use Atomic 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* _do_work_called_by; Can we use `GrowableArrayCHeap, 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 [v2] In-Reply-To: References: Message-ID: <0NPTXVswTQTbg52zjeuB26o5JHlFO8L_b_Ryy31nfNw=.1629bb1c-f153-4812-aaef-8fb4ddd767f9@github.com> On Fri, 2 Jan 2026 10:19:59 GMT, Axel Boldt-Christmas 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* _do_work_called_by; > > Can we use `GrowableArrayCHeap, 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: 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: References: <15wAKoik-66gfbUzGQEROBTv_cTV_I_6jq96S2ErOyA=.22e19b52-220c-4c35-9aaa-9f08719e16fa@github.com> Message-ID: <2b8w_8NwTITCCqqyirLgPcfxyQd35yS-MmPlO8rEwS0=.74b73b12-1b0a-4d73-b18f-1f6ac0e5f18d@github.com> On Thu, 1 Jan 2026 20:35:25 GMT, Evgeny Astigeevich wrote: > > Sure, I can see that, but is there any reason not to do this by default on all AArch64? > > Do you mean to do this for all AArch64 OSes, not only for Linux AArch64? In a perfect world we'd do this for all AArch64. But Linux-only would be good too. But is there any reason not to do this on all Linux systems? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28328#issuecomment-3705195536 From kbarrett at openjdk.org Fri Jan 2 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: References: Message-ID: On Fri, 2 Jan 2026 11:48:16 GMT, Francesco Andreuzzi 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: References: Message-ID: On Fri, 2 Jan 2026 11:48:16 GMT, Francesco Andreuzzi 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: References: Message-ID: <1HoFAoxwMTDW1GJteYe1Bl3X9erLJtcdjdY7kEqOMgE=.f34e8855-352e-4654-9297-6af29b5f17de@github.com> On Mon, 29 Dec 2025 21:51:20 GMT, Evgeny Astigeevich wrote: >> Arm Neoverse N1 erratum 1542419: "The core might fetch a stale instruction from memory which violates the ordering of instruction fetches". It is fixed in Neoverse N1 r4p1. >> >> Neoverse-N1 implementations mitigate erratum 1542419 with a workaround: >> - Disable coherent icache. >> - Trap IC IVAU instructions. >> - Execute: >> - `tlbi vae3is, xzr` >> - `dsb sy` >> >> `tlbi vae3is, xzr` invalidates translations for all address spaces (global for address). It waits for all memory accesses using in-scope old translation information to complete before it is considered complete. >> >> As this workaround has significant overhead, Arm Neoverse N1 (MP050) Software Developer Errata Notice version 29.0 suggests: >> >> "Since one TLB inner-shareable invalidation is enough to avoid this erratum, the number of injected TLB invalidations should be minimized in the trap handler to mitigate the performance impact due to this workaround." >> >> This PR introduces a mechanism to defer instruction cache (ICache) invalidation for AArch64 to address the Arm Neoverse N1 erratum 1542419, which causes significant performance overhead if ICache invalidation is performed too frequently. The implementation includes detection of affected Neoverse N1 CPUs and automatic enabling of the workaround for relevant Neoverse N1 revisions. >> >> Changes include: >> >> * Added a new diagnostic JVM flag `NeoverseN1Errata1542419` to enable or disable the workaround for the erratum. The flag is automatically enabled for Neoverse N1 CPUs prior to r4p1, as detected during VM initialization. >> * Introduced the `ICacheInvalidationContext` class to manage deferred ICache invalidation, with platform-specific logic for AArch64. This context is used to batch ICache invalidations, reducing performance impact. As the address for icache invalidation is not relevant, we use the nmethod's code start address. >> * Provided a default (no-op) implementation for `ICacheInvalidationContext` on platforms where the workaround is not needed, ensuring portability and minimal impact on other architectures. >> * Modified barrier patching and relocation logic (`ZBarrierSetAssembler`, `ZNMethod`, `RelocIterator`, and related code) to accept a `defer_icache_invalidation` parameter, allowing ICache invalidation to be deferred and later performed in bulk. >> >> Testing results: linux fastdebug build >> - Neoverse-N1 (Graviton 2) >> - [x] tier1: passed >> - [x] tier2: passed >> - [x] tier3: passed >> - [x] tier4: 3 failu... > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Fix linux-cross-compile riscv64 build src/hotspot/share/runtime/icache.hpp line 139: > 137: class DefaultICacheInvalidationContext : StackObj { > 138: private: > 139: NONCOPYABLE(DefaultICacheInvalidationContext); Not a review, just a drive-by comment. @xmas92 suggested moving the `NONCOPYABLE` to the private part of the class, as a style issue. It used to be that `NONCOPYABLE` was best used in the private part of a class, because of how it was implemented. But with the change to using deleted definitions, it's actually better to have it in the public part. That way you get an "attempt to use a deleted function" error rather than possibly getting an "attempt to use an inaccessible function" error. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28328#discussion_r2657751265 From 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: References: Message-ID: On Fri, 2 Jan 2026 12:23:48 GMT, Kim Barrett 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: References: Message-ID: On Fri, 2 Jan 2026 11:48:16 GMT, Francesco Andreuzzi 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 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: <15wAKoik-66gfbUzGQEROBTv_cTV_I_6jq96S2ErOyA=.22e19b52-220c-4c35-9aaa-9f08719e16fa@github.com> <2b8w_8NwTITCCqqyirLgPcfxyQd35yS-MmPlO8rEwS0=.74b73b12-1b0a-4d73-b18f-1f6ac0e5f18d@github.com> Message-ID: On Fri, 2 Jan 2026 12:07:57 GMT, Andrew Haley wrote: > > > Sure, I can see that, but is there any reason not to do this by default on all AArch64? > > > > > > Do you mean to do this for all AArch64 OSes, not only for Linux AArch64? > > In a perfect world we'd do this for all AArch64. But Linux-only would be good too. But is there any reason not to do this on all Linux systems? IMO, a reason is that not all AArch64 might have both `ctr_el0.IDC` and `ctr_el0.DIC` set. If either of `ctr_el0.IDC`/`ctr_el0.DIC` or both are not set, we will need to use `DC`/`IC` with real addresses to clean and to invalidate caches. We will need to choose between invalidating modified instructions or the whole nmethod's code. Invalidating modified instructions will need tracking of modified instructions. Invalidating the whole nmethod does not need tracking but it can be expensive vs invalidating particular instructions. IMO cases of Java running on AArch64 CPU where both `ctr_el0.IDC` and `ctr_el0.DIC` are not set, might be rare. Jacob Bramley from Arm has nice blog posts about Caches and Self-Modifying Code: - [Caches and Self-Modifying Code: Implementing `__clear_cache`](https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-implementing-clear-cache) - [Caches and Self-Modifying Code: Working with Threads](https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-working-with-threads) In this PR we optimize two parts invalidating caches: 1. GCs patching code. This is invalidation of modified instructions. 2. Generation and installation of code. This is invalidation of the whole code. The second case can be optimized for all AArch64. Is there anything I am missing? And we can do optimized cache invalidation on all AArch64? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28328#issuecomment-3705607781 From aph at openjdk.org Fri Jan 2 18:06:58 2026 From: aph at openjdk.org (Andrew Haley) Date: Fri, 2 Jan 2026 18:06:58 GMT Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact on GCs and JIT performance [v21] In-Reply-To: References: <15wAKoik-66gfbUzGQEROBTv_cTV_I_6jq96S2ErOyA=.22e19b52-220c-4c35-9aaa-9f08719e16fa@github.com> <2b8w_8NwTITCCqqyirLgPcfxyQd35yS-MmPlO8rEwS0=.74b73b12-1b0a-4d73-b18f-1f6ac0e5f18d@github.com> Message-ID: On Fri, 2 Jan 2026 15:39:50 GMT, Evgeny Astigeevich wrote: > > > > Sure, I can see that, but is there any reason not to do this by default on all AArch64? > > > > > > > > > Do you mean to do this for all AArch64 OSes, not only for Linux AArch64? > > > > > > In a perfect world we'd do this for all AArch64. But Linux-only would be good too. But is there any reason not to do this on all Linux systems? > > IMO, a reason is that not all AArch64 might have both `ctr_el0.IDC` and `ctr_el0.DIC` set. If either of `ctr_el0.IDC`/`ctr_el0.DIC` or both are not set, we will need to use `DC`/`IC` with real addresses to clean and to invalidate caches. We will need to choose between invalidating modified instructions or the whole nmethod's code. Invalidating modified instructions will need tracking of modified instructions. Invalidating the whole nmethod does not need tracking but it can be expensive vs invalidating particular instructions. Ah, I see. So it looks like we'll have to maintain two entirely different bodies of code to do the cache management. That will be a recurring pain, and is disappointing. > > IMO cases of Java running on AArch64 CPU where both `ctr_el0.IDC` and `ctr_el0.DIC` are not set, might be rare. > > Jacob Bramley from Arm has nice blog posts about Caches and Self-Modifying Code: > > * [Caches and Self-Modifying Code: Implementing `__clear_cache`](https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-implementing-clear-cache) That's useful. It's worth taking advantage of cache-coherent implementations (when they're not broken!) by not emitting unnecessary instructions. > * [Caches and Self-Modifying Code: Working with Threads](https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-working-with-threads) Thanks. That's a good read, but no surprises. I'm fairly sure we've been doing most of that for as long as the port has existed. > In this PR we optimize two parts invalidating caches: > > 1. GCs patching code. This is invalidation of modified instructions. > > 2. Generation and installation of code. This is invalidation of the whole code. > > > The second case can be optimized for all AArch64. > > Is there anything I am missing? And we can do optimized cache invalidation on all AArch64? Probably not, but I've been working on a patch to minimize the invalidation we do today. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28328#issuecomment-3705936075 From eastigeevich at openjdk.org Fri Jan 2 22:07:00 2026 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Fri, 2 Jan 2026 22:07:00 GMT Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact on GCs and JIT performance [v21] In-Reply-To: References: <15wAKoik-66gfbUzGQEROBTv_cTV_I_6jq96S2ErOyA=.22e19b52-220c-4c35-9aaa-9f08719e16fa@github.com> <2b8w_8NwTITCCqqyirLgPcfxyQd35yS-MmPlO8rEwS0=.74b73b12-1b0a-4d73-b18f-1f6ac0e5f18d@github.com> Message-ID: On Fri, 2 Jan 2026 18:02:49 GMT, Andrew Haley wrote: >>> > > Sure, I can see that, but is there any reason not to do this by default on all AArch64? >>> > >>> > >>> > Do you mean to do this for all AArch64 OSes, not only for Linux AArch64? >>> >>> In a perfect world we'd do this for all AArch64. But Linux-only would be good too. But is there any reason not to do this on all Linux systems? >> >> IMO, a reason is that not all AArch64 might have both `ctr_el0.IDC` and `ctr_el0.DIC` set. If either of `ctr_el0.IDC`/`ctr_el0.DIC` or both are not set, we will need to use `DC`/`IC` with real addresses to clean and to invalidate caches. We will need to choose between invalidating modified instructions or the whole nmethod's code. Invalidating modified instructions will need tracking of modified instructions. Invalidating the whole nmethod does not need tracking but it can be expensive vs invalidating particular instructions. >> >> IMO cases of Java running on AArch64 CPU where both `ctr_el0.IDC` and `ctr_el0.DIC` are not set, might be rare. >> >> Jacob Bramley from Arm has nice blog posts about Caches and Self-Modifying Code: >> - [Caches and Self-Modifying Code: Implementing `__clear_cache`](https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-implementing-clear-cache) >> - [Caches and Self-Modifying Code: Working with Threads](https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-working-with-threads) >> >> In this PR we optimize two parts invalidating caches: >> 1. GCs patching code. This is invalidation of modified instructions. >> 2. Generation and installation of code. This is invalidation of the whole code. >> >> The second case can be optimized for all AArch64. >> >> Is there anything I am missing? And we can do optimized cache invalidation on all AArch64? > >> > > > Sure, I can see that, but is there any reason not to do this by default on all AArch64? >> > > >> > > >> > > Do you mean to do this for all AArch64 OSes, not only for Linux AArch64? >> > >> > >> > In a perfect world we'd do this for all AArch64. But Linux-only would be good too. But is there any reason not to do this on all Linux systems? >> >> IMO, a reason is that not all AArch64 might have both `ctr_el0.IDC` and `ctr_el0.DIC` set. If either of `ctr_el0.IDC`/`ctr_el0.DIC` or both are not set, we will need to use `DC`/`IC` with real addresses to clean and to invalidate caches. We will need to choose between invalidating modified instructions or the whole nmethod's code. Invalidating modified instructions will need tracking of modified instructions. Invalidating the whole nmethod does not need tracking but it can be expensive vs invalidating particular instructions. > > Ah, I see. So it looks like we'll have to maintain two entirely different bodies of code to do the cache management. That will be a recurring pain, and is disappointing. > >> >> IMO cases of Java running on AArch64 CPU where both `ctr_el0.IDC` and `ctr_el0.DIC` are not set, might be rare. >> >> Jacob Bramley from Arm has nice blog posts about Caches and Self-Modifying Code: >> >> * [Caches and Self-Modifying Code: Implementing `__clear_cache`](https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-implementing-clear-cache) > > That's useful. It's worth taking advantage of cache-coherent implementations (when they're not broken!) by not emitting unnecessary instructions. > >> * [Caches and Self-Modifying Code: Working with Threads](https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-working-with-threads) > > Thanks. That's a good read, but no surprises. I'm fairly sure we've been doing most of that for as long as the port has existed. > >> In this PR we optimize two parts invalidating caches: >> >> 1. GCs patching code. This is invalidation of modified instructions. >> >> 2. Generation and installation of code. This is invalidation of the whole code. >> >> >> The second case can be optimized for all AArch64. >> >> Is there anything I am missing? And we can do optimized cache invalidation on all AArch64? > > Probably not, but I've been working on a patch to minimize the invalidation we do today. @theRealAph > ... > Probably not, but I've been working on a patch to minimize the invalidation we do today. Does this mean we don't need this PR or need to rework it? Could you please provide more details? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28328#issuecomment-3706299227 From 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: References: Message-ID: On Sat, 13 Dec 2025 20:01:13 GMT, Leonid Mesnik 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 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 [v2] In-Reply-To: References: Message-ID: <2BsNqPX7px4ySEnRdMif4KFSqS8cE8oIyi_BmO8Qkts=.afb1a1fd-385d-4a53-a1b8-355fe4eec80c@github.com> On Fri, 2 Jan 2026 10:08:26 GMT, Kim Barrett wrote: >> Please review this change to convert HotSpot gtests to use Atomic 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: References: <15wAKoik-66gfbUzGQEROBTv_cTV_I_6jq96S2ErOyA=.22e19b52-220c-4c35-9aaa-9f08719e16fa@github.com> <2b8w_8NwTITCCqqyirLgPcfxyQd35yS-MmPlO8rEwS0=.74b73b12-1b0a-4d73-b18f-1f6ac0e5f18d@github.com> Message-ID: <8hQOV9QhPL_j5g7WpcwzJc_8QPeAzLSIFk3ASRlCXa8=.3e1ac93f-2f6a-4dce-bead-31241240cb6e@github.com> On Fri, 2 Jan 2026 22:04:00 GMT, Evgeny Astigeevich wrote: > > Probably not, but I've been working on a patch to minimize the invalidation we do today. > > Does this mean we don't need this PR or need to rework it? Could you please provide more details? It makes no difference to this patch. I'm still experimenting. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28328#issuecomment-3706937169 From 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: 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: References: Message-ID: <-sYToet_Qr8ddZAeRXW_5HoEJqfwCYNcWm0myfHVO-w=.a4955764-1b19-450c-b1cd-ca71d74376d0@github.com> On Sat, 3 Jan 2026 19:44:50 GMT, Leonid Mesnik 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 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: References: Message-ID: On Fri, 12 Sep 2025 01:49:23 GMT, Vic Wang 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: References: Message-ID: > 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: References: Message-ID: > 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: References: Message-ID: On Sun, 4 Jan 2026 03:36:33 GMT, Jie Fu 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: References: Message-ID: <9R90qVMedt6prUnfCZPBD6Q84zdGHSWyEfBvc8wqlZk=.945c2b8a-bf48-47c7-b15a-e5050ad545c7@github.com> On Sun, 4 Jan 2026 10:07:31 GMT, Vic Wang 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: References: Message-ID: > 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: <9R90qVMedt6prUnfCZPBD6Q84zdGHSWyEfBvc8wqlZk=.945c2b8a-bf48-47c7-b15a-e5050ad545c7@github.com> Message-ID: On Mon, 5 Jan 2026 02:17:50 GMT, Jie Fu 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: References: Message-ID: On Sat, 29 Nov 2025 06:06:16 GMT, Yasumasa Suenaga 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: References: Message-ID: On Sat, 29 Nov 2025 06:06:16 GMT, Yasumasa Suenaga 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: References: <9R90qVMedt6prUnfCZPBD6Q84zdGHSWyEfBvc8wqlZk=.945c2b8a-bf48-47c7-b15a-e5050ad545c7@github.com> Message-ID: On Mon, 5 Jan 2026 07:58:24 GMT, Vic Wang 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: References: Message-ID: > 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: References: Message-ID: > 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: References: Message-ID: On Mon, 5 Jan 2026 06:38:07 GMT, Aleksey Shipilev 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: References: Message-ID: On Thu, 18 Dec 2025 15:23:42 GMT, Aleksey Shipilev 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: References: Message-ID: On Mon, 19 May 2025 14:59:36 GMT, Aleksey Shipilev 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 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: References: <9R90qVMedt6prUnfCZPBD6Q84zdGHSWyEfBvc8wqlZk=.945c2b8a-bf48-47c7-b15a-e5050ad545c7@github.com> Message-ID: On Mon, 5 Jan 2026 09:09:47 GMT, Jie Fu 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: References: Message-ID: On Sat, 29 Nov 2025 06:06:16 GMT, Yasumasa Suenaga 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: References: Message-ID: <429t5MAqdyAQ7wFsxgYdUa2YPZm3GCI7SU0KwGDzcCQ=.46240518-0447-4e08-97d2-7522ebc1aacf@github.com> On Mon, 5 Jan 2026 10:37:51 GMT, Martin Doerr 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: References: <9R90qVMedt6prUnfCZPBD6Q84zdGHSWyEfBvc8wqlZk=.945c2b8a-bf48-47c7-b15a-e5050ad545c7@github.com> Message-ID: On Mon, 5 Jan 2026 10:34:05 GMT, Vic Wang 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: References: Message-ID: <8cDcqwQHocqJGtC35wq6QgWil63G6hgYLIyU4kjCf9I=.b008c63a-4687-44aa-9ce5-cd40d95bf16f@github.com> On Thu, 18 Dec 2025 10:12:02 GMT, Roberto Casta?eda Lozano 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: References: Message-ID: On Mon, 5 Jan 2026 09:34:24 GMT, Roland Westrelin 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: References: Message-ID: On Mon, 5 Jan 2026 14:42:05 GMT, Christian Hagedorn 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: References: Message-ID: On Thu, 18 Dec 2025 08:30:52 GMT, Roland Westrelin 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 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 [v4] In-Reply-To: References: <7QNN5i5DkBH7c9YXWh5U40JwTKmiBPJSAcLm-f1HE_8=.9b18027e-8274-46d1-ba2d-e70514c40fc3@github.com> Message-ID: <54JWXhPkg9GyzvR9XnHv0H8Q1kHkkko17-JGwjKXMaM=.03b68e11-f91a-4486-b6ad-8536ebe083fb@github.com> On Fri, 2 Jan 2026 10:21:44 GMT, Kim Barrett wrote: >> Please review this change that adds a HotSpot wrapper for . 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 `` and `` to include the wrapper instead. >> There are still a couple of includes of `` 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: References: Message-ID: > 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: References: Message-ID: On Fri, 19 Dec 2025 19:02:13 GMT, William Kemper 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 > - 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: References: Message-ID: > 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 - 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: 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_.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: 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: References: <6yaYr_fSazq20-3lshGS-_Lr-LqXMt4lTeaFzDs9U2U=.c865efd1-9b98-4fce-98dd-4e1fe50a45be@github.com> <_LgB7c2fIE-RBo1CpmjeirR4oG6v8JBVQZ8spZzDLY8=.a67da689-d204-4550-86b6-c0efde380892@github.com> <_lvm42phwda7i6vX6U6cFoaLLu07NELtWmW0pg73IVI=.83b5be81-f8a2-4364-8214-cf7638daff67@github.com> Message-ID: <5lP4lrUVNtWTunMOMnkGncADv3FwM6PliTa0uJrULa0=.1fc6f40e-1509-4d54-9754-dccb822c8bfc@github.com> On Fri, 19 Dec 2025 14:29:22 GMT, Richard Reingruber 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: On Mon, 15 Dec 2025 16:53:05 GMT, Patricio Chilano Mateo 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 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 [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: > Please review this change that adds a HotSpot wrapper for . 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 `` and `` to include the wrapper instead. > There are still a couple of includes of `` 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 ------------- 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 [v5] In-Reply-To: References: <7QNN5i5DkBH7c9YXWh5U40JwTKmiBPJSAcLm-f1HE_8=.9b18027e-8274-46d1-ba2d-e70514c40fc3@github.com> Message-ID: On Mon, 5 Jan 2026 19:32:13 GMT, Kim Barrett wrote: >> Please review this change that adds a HotSpot wrapper for . 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 `` and `` to include the wrapper instead. >> There are still a couple of includes of `` 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 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: 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: On Mon, 5 Jan 2026 20:16:37 GMT, Larry Cable 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: On Mon, 5 Jan 2026 20:16:37 GMT, Larry Cable 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: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Mon, 5 Jan 2026 21:09:17 GMT, Serguei Spitsyn 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: References: Message-ID: On Mon, 5 Jan 2026 19:45:43 GMT, Patricio Chilano Mateo 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: References: Message-ID: 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 ). > > 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_.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: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Mon, 5 Jan 2026 23:22:01 GMT, Larry Cable 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: References: Message-ID: <-gMh5Vg1BuNhdoRbSuCwxK7d9WO_6JWkRfpx2dg8rvs=.3bdef6ac-a4ab-4487-a750-e16e7c4ae181@github.com> On Sun, 4 Jan 2026 10:07:31 GMT, Vic Wang 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 [v2] In-Reply-To: <1dWWxpfyieTZiPq-2nyC9E6RFu9o6oTbI1Fgu2Yfva4=.15f9f4a3-7b74-47b6-9912-fe9ffda63420@github.com> References: <1dWWxpfyieTZiPq-2nyC9E6RFu9o6oTbI1Fgu2Yfva4=.15f9f4a3-7b74-47b6-9912-fe9ffda63420@github.com> Message-ID: On Tue, 23 Dec 2025 11:14:28 GMT, Kim Barrett 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* 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` is atomic). It could instead be written as `Atomic 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 [v2] In-Reply-To: References: Message-ID: On Fri, 2 Jan 2026 10:13:38 GMT, Kim Barrett wrote: >> Please review this change to ConcurrentHashTable to use `Atomic` 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: References: Message-ID: On Sun, 28 Dec 2025 03:56:39 GMT, Sergey Bylokhov 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: References: Message-ID: On Sun, 4 Jan 2026 10:07:31 GMT, Vic Wang 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: <-gMh5Vg1BuNhdoRbSuCwxK7d9WO_6JWkRfpx2dg8rvs=.3bdef6ac-a4ab-4487-a750-e16e7c4ae181@github.com> Message-ID: On Tue, 6 Jan 2026 01:22:00 GMT, David Holmes 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: References: Message-ID: On Sun, 4 Jan 2026 10:07:31 GMT, Vic Wang 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: References: Message-ID: On Sat, 3 Jan 2026 19:44:50 GMT, Leonid Mesnik 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: References: Message-ID: > 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: References: Message-ID: On Tue, 6 Jan 2026 02:18:47 GMT, Jie Fu 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: References: Message-ID: On Tue, 6 Jan 2026 03:15:42 GMT, Vic Wang 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 [v2] In-Reply-To: References: Message-ID: <64LeVi555L_rjZxXCXaj4wLuRVI__2ySJd6liHtIX4Q=.b83723e5-fb69-4010-b257-9efee603e0dd@github.com> On Fri, 2 Jan 2026 10:11:58 GMT, Kim Barrett wrote: >> Please review these fairly simple changes to code in gc/shared to use >> `Atomic` 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: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Tue, 6 Jan 2026 00:49:14 GMT, David Holmes 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: 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: References: Message-ID: On Tue, 6 Jan 2026 08:16:16 GMT, Volkan Yazici 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: References: Message-ID: On Tue, 6 Jan 2026 08:16:16 GMT, Volkan Yazici 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: <07NHyGU8bmzafUXXdLP3X81f7OZrqP6JcXZmtPh78J4=.5551605a-ade3-4190-9cf8-ae2a68857694@github.com> Message-ID: On Wed, 24 Dec 2025 22:06:43 GMT, Srinivas Vamsi Parasa 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: References: <07NHyGU8bmzafUXXdLP3X81f7OZrqP6JcXZmtPh78J4=.5551605a-ade3-4190-9cf8-ae2a68857694@github.com> Message-ID: <4DbVeS6SQL4D3AJD1xTxGr3DI9B6XMxOS4r30vDXhCk=.8890e33c-df2e-451d-9dae-1d858b5f06f4@github.com> On Mon, 5 Jan 2026 18:45:03 GMT, Srinivas Vamsi Parasa 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: <07NHyGU8bmzafUXXdLP3X81f7OZrqP6JcXZmtPh78J4=.5551605a-ade3-4190-9cf8-ae2a68857694@github.com> Message-ID: On Wed, 24 Dec 2025 22:06:43 GMT, Srinivas Vamsi Parasa 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: References: Message-ID: On Tue, 6 Jan 2026 08:16:16 GMT, Volkan Yazici 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: *

> 455: * WARNING: This method does not perform any bound checks. 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: References: Message-ID: On Tue, 6 Jan 2026 09:06:27 GMT, Aleksey Shipilev 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: *

>> 455: * WARNING: This method does not perform any bound checks. > > 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: References: Message-ID: On Tue, 6 Jan 2026 09:10:53 GMT, Aleksey Shipilev 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: On Mon, 5 Jan 2026 20:16:37 GMT, Larry Cable 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: References: Message-ID: On Tue, 6 Jan 2026 08:16:16 GMT, Volkan Yazici 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: References: Message-ID: On Tue, 6 Jan 2026 08:16:16 GMT, Volkan Yazici 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: References: Message-ID: On Tue, 6 Jan 2026 09:57:02 GMT, Volkan Yazici wrote: >> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 455: >> >>> 453: * compatible. >>> 454: *

>>> 455: * WARNING: This method does not perform any bound checks. >> >> 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: On Mon, 5 Jan 2026 20:16:37 GMT, Larry Cable 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 [v2] In-Reply-To: References: Message-ID: On Fri, 2 Jan 2026 10:08:26 GMT, Kim Barrett wrote: >> Please review this change to convert HotSpot gtests to use Atomic 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 [v2] In-Reply-To: References: Message-ID: On Fri, 2 Jan 2026 10:28:13 GMT, Axel Boldt-Christmas 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 In-Reply-To: References: Message-ID: On Sat, 27 Dec 2025 05:20:52 GMT, Kim Barrett wrote: > Please review this change to convert HotSpot gtests to use Atomic 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 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 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 [v2] In-Reply-To: References: Message-ID: On Fri, 2 Jan 2026 10:13:38 GMT, Kim Barrett wrote: >> Please review this change to ConcurrentHashTable to use `Atomic` 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: References: Message-ID: On Mon, 5 Jan 2026 19:45:43 GMT, Patricio Chilano Mateo 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: References: Message-ID: <2ToH1aLLq0wKOUNeWuk1bLQgW8uoXIkLP8LADafqBOk=.d601112e-2ae7-4bc3-a0b4-8f24efaf126b@github.com> On Mon, 5 Jan 2026 19:45:43 GMT, Patricio Chilano Mateo 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 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: References: Message-ID: On Sat, 3 Jan 2026 19:44:50 GMT, Leonid Mesnik 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 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 [v2] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 01:36:18 GMT, David Holmes 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 [v2] In-Reply-To: References: <1dWWxpfyieTZiPq-2nyC9E6RFu9o6oTbI1Fgu2Yfva4=.15f9f4a3-7b74-47b6-9912-fe9ffda63420@github.com> Message-ID: <6qUvIHueHH3KolEkohBHXvJx8b2KYEdcFiJXke6dRZU=.79b5aeee-d9ba-4fb2-b5e9-a6cac35884ef@github.com> On Tue, 6 Jan 2026 01:36:14 GMT, David Holmes 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` is atomic). It could instead be written as `Atomic 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 In-Reply-To: References: Message-ID: <4XfDWjYeeh1m1PJjM_bsSLJ8h0-qyrKeYhlc5BX0Qj0=.6fafc222-2bcf-4c3a-bb2a-6d1377de912f@github.com> On Mon, 22 Dec 2025 07:29:55 GMT, Kim Barrett wrote: > Please review this change to ConcurrentHashTable to use `Atomic` 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 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 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: 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: > 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: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Tue, 6 Jan 2026 10:51:22 GMT, Kevin Walls 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: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Mon, 5 Jan 2026 22:20:06 GMT, Leonid Mesnik 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: 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: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Tue, 6 Jan 2026 11:50:30 GMT, Kevin Walls 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: <07NHyGU8bmzafUXXdLP3X81f7OZrqP6JcXZmtPh78J4=.5551605a-ade3-4190-9cf8-ae2a68857694@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 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: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Tue, 6 Jan 2026 21:29:36 GMT, Larry Cable 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: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: <8iF5lwO870gPlfcozjDBwgYE9hw0WxeIjVfGiTT2ZmA=.a7b55428-5686-4578-b71a-f5d47414b524@github.com> On Mon, 5 Jan 2026 23:22:01 GMT, Larry Cable 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: References: Message-ID: On Tue, 6 Jan 2026 01:58:22 GMT, David Holmes 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: References: Message-ID: On Wed, 17 Dec 2025 12:56:01 GMT, Jatin Bhateja 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. >> >> image >> >> 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 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: References: Message-ID: On Tue, 6 Jan 2026 21:27:21 GMT, Volodymyr Paprotski 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 [v2] In-Reply-To: References: Message-ID: On Fri, 2 Jan 2026 10:11:58 GMT, Kim Barrett wrote: >> Please review these fairly simple changes to code in gc/shared to use >> `Atomic` 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: References: Message-ID: On Tue, 6 Jan 2026 18:05:52 GMT, Kim Barrett 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: References: Message-ID: > 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 [v2] In-Reply-To: References: Message-ID: On Fri, 2 Jan 2026 10:11:58 GMT, Kim Barrett wrote: >> Please review these fairly simple changes to code in gc/shared to use >> `Atomic` 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: References: Message-ID: On Mon, 22 Dec 2025 07:23:34 GMT, Christian Hagedorn 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: References: Message-ID: On Wed, 7 Jan 2026 08:16:55 GMT, Roland Westrelin 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: References: Message-ID: On Wed, 7 Jan 2026 06:55:45 GMT, Fei Yang 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 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: On Wed, 7 Jan 2026 09:12:03 GMT, Aleksey Shipilev 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: References: Message-ID: <3Rpck6RY8Y4e8nra-VY8XWnlOUvYnXPEuwPL6DikCHU=.5a55c9f6-d5e9-431c-9285-d11c594127bd@github.com> On Tue, 6 Jan 2026 10:53:21 GMT, Tobias Hartmann 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: References: Message-ID: <3JPEbFO_Dlf3D46IlEOn21t0KL9wouC5z-0VQa31tsc=.f8de0911-4fcf-49f2-b25a-0b9e1059dc1a@github.com> On Tue, 6 Jan 2026 08:16:16 GMT, Volkan Yazici 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 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: References: Message-ID: > This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. > > It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. > > This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. > > I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. Leo Korinth has updated the pull request incrementally with 561 additional commits since the last revision: - Merge branch 'master' into _8367993 - 8366058: Outdated comment in WinCAPISeedGenerator Reviewed-by: mullan - 8357258: x86: Improve receiver type profiling reliability Reviewed-by: kvn, vlivanov - 8373704: Improve "SocketException: Protocol family unavailable" message Reviewed-by: lucy, jpai - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently Reviewed-by: jiefu, jbhateja, erfang, qamai - 8343809: Add requires tag to mark tests that are incompatible with exploded image Reviewed-by: alanb, dholmes - 8374465: Spurious dot in documentation for JVMTI ClassLoad Reviewed-by: kbarrett - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket Reviewed-by: djelinski, mpowers, ascarpino - 8374444: Fix simple -Wzero-as-null-pointer-constant warnings Reviewed-by: aboldtch - 8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the ?Nothing? menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test Reviewed-by: serb, aivanov, dnguyen - ... and 551 more: https://git.openjdk.org/jdk/compare/b907b295...0ece3767 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28723/files - new: https://git.openjdk.org/jdk/pull/28723/files/b907b295..0ece3767 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28723&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28723&range=00-01 Stats: 130212 lines in 3962 files changed: 83750 ins; 29714 del; 16748 mod Patch: https://git.openjdk.org/jdk/pull/28723.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28723/head:pull/28723 PR: https://git.openjdk.org/jdk/pull/28723 From 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: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Tue, 6 Jan 2026 21:29:36 GMT, Larry Cable 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: References: Message-ID: On Wed, 7 Jan 2026 08:00:29 GMT, Johan Sj?len 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: References: Message-ID: On Tue, 6 Jan 2026 18:05:52 GMT, Kim Barrett 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 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: References: Message-ID: <3a_1QZxP59TuI3FewXHDcR_xWH616tlSpcCf1f4BbP0=.c7570d0a-56a6-424d-a5ea-489318734d99@github.com> On Wed, 19 Nov 2025 12:47:18 GMT, Samuel Chee 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: > 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: References: Message-ID: On Wed, 7 Jan 2026 10:02:41 GMT, Leo Korinth wrote: >> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. >> >> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. >> >> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. >> >> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. > > Leo Korinth has updated the pull request incrementally with 561 additional commits since the last revision: > > - Merge branch 'master' into _8367993 > - 8366058: Outdated comment in WinCAPISeedGenerator > > Reviewed-by: mullan > - 8357258: x86: Improve receiver type profiling reliability > > Reviewed-by: kvn, vlivanov > - 8373704: Improve "SocketException: Protocol family unavailable" message > > Reviewed-by: lucy, jpai > - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently > > Reviewed-by: jiefu, jbhateja, erfang, qamai > - 8343809: Add requires tag to mark tests that are incompatible with exploded image > > Reviewed-by: alanb, dholmes > - 8374465: Spurious dot in documentation for JVMTI ClassLoad > > Reviewed-by: kbarrett > - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket > > Reviewed-by: djelinski, mpowers, ascarpino > - 8374444: Fix simple -Wzero-as-null-pointer-constant warnings > > Reviewed-by: aboldtch > - 8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the ?Nothing? menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test > > Reviewed-by: serb, aivanov, dnguyen > - ... and 551 more: https://git.openjdk.org/jdk/compare/b907b295...0ece3767 I will redo the merge, I have done something strange. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28723#issuecomment-3718660595 From lkorinth at openjdk.org Wed Jan 7 12:58:43 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 7 Jan 2026 12:58:43 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v3] In-Reply-To: References: Message-ID: > This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. > > It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. > > This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. > > I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 564 commits: - Merge branch '8373253' into 8367993 - Merge branch 'master' into _8373253 - Merge branch 'master' into _8367993 - 8366058: Outdated comment in WinCAPISeedGenerator Reviewed-by: mullan - 8357258: x86: Improve receiver type profiling reliability Reviewed-by: kvn, vlivanov - 8373704: Improve "SocketException: Protocol family unavailable" message Reviewed-by: lucy, jpai - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently Reviewed-by: jiefu, jbhateja, erfang, qamai - 8343809: Add requires tag to mark tests that are incompatible with exploded image Reviewed-by: alanb, dholmes - 8374465: Spurious dot in documentation for JVMTI ClassLoad Reviewed-by: kbarrett - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket Reviewed-by: djelinski, mpowers, ascarpino - ... and 554 more: https://git.openjdk.org/jdk/compare/2aa8aa4b...28ccbb68 ------------- Changes: https://git.openjdk.org/jdk/pull/28723/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28723&range=02 Stats: 130308 lines in 3967 files changed: 83803 ins; 29735 del; 16770 mod Patch: https://git.openjdk.org/jdk/pull/28723.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28723/head:pull/28723 PR: https://git.openjdk.org/jdk/pull/28723 From 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: References: Message-ID: On Sat, 29 Nov 2025 06:06:16 GMT, Yasumasa Suenaga 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 [v3] In-Reply-To: References: 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` 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 [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 08:15:34 GMT, Thomas Schatzl 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 [v5] In-Reply-To: References: <7QNN5i5DkBH7c9YXWh5U40JwTKmiBPJSAcLm-f1HE_8=.9b18027e-8274-46d1-ba2d-e70514c40fc3@github.com> Message-ID: <6a3F4iP79lL5K41emokPCcv9n_mYZ44sTgV6r2MWrJ8=.5382828b-dc4a-4f7e-a605-de2cc5964413@github.com> On Mon, 5 Jan 2026 19:32:13 GMT, Kim Barrett wrote: >> Please review this change that adds a HotSpot wrapper for . 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 `` and `` to include the wrapper instead. >> There are still a couple of includes of `` 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 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: References: Message-ID: > 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: References: Message-ID: On Wed, 7 Jan 2026 07:28:07 GMT, Tobias Hartmann 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: 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: References: Message-ID: On Wed, 7 Jan 2026 17:47:47 GMT, jonghoonpark 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: References: Message-ID: On Wed, 7 Jan 2026 18:37:08 GMT, Kim Barrett 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: References: Message-ID: > 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: References: Message-ID: On Mon, 8 Dec 2025 18:45:04 GMT, Aleksey Shipilev 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: References: Message-ID: <3PzPbEnPapV-B3OenjmG6paXsyLFayh33S-f0IBI-LY=.773757f6-c9e0-48ac-b89d-aa81fd6b47f8@github.com> On Wed, 17 Dec 2025 12:56:01 GMT, Jatin Bhateja 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. >> >> image >> >> 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: References: Message-ID: On Wed, 7 Jan 2026 17:47:47 GMT, jonghoonpark 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 [v2] In-Reply-To: References: <7QNN5i5DkBH7c9YXWh5U40JwTKmiBPJSAcLm-f1HE_8=.9b18027e-8274-46d1-ba2d-e70514c40fc3@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 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 > > 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 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: On Sat, 29 Nov 2025 05:09:49 GMT, Kim Barrett wrote: > Please review this change that adds a HotSpot wrapper for . 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 `` and `` to include the wrapper instead. > There are still a couple of includes of `` 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 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 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: References: Message-ID: > 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: References: Message-ID: On Sun, 16 Nov 2025 03:48:31 GMT, Mohamed Issa wrote: > Intel® 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: References: Message-ID: On Tue, 2 Dec 2025 05:59:53 GMT, Jatin Bhateja wrote: >> Intel® 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: Intel® 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: References: Message-ID: On Thu, 11 Dec 2025 23:33:41 GMT, Mohamed Issa 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: References: Message-ID: On Wed, 7 Jan 2026 14:20:34 GMT, Markus Gr?nlund 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: References: Message-ID: > 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: References: Message-ID: On Wed, 7 Jan 2026 20:30:18 GMT, Stefan Karlsson 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 [v3] In-Reply-To: <4xK-xF1D4khPfnCGygZ2pLN1SVwdVpjcvPeAl0ZUEOk=.a2de074b-192f-4129-9cf7-da5b7bd347b4@github.com> References: <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 wrote: >> Please review these fairly simple changes to code in gc/shared to use >> `Atomic` 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 [v5] In-Reply-To: References: <7QNN5i5DkBH7c9YXWh5U40JwTKmiBPJSAcLm-f1HE_8=.9b18027e-8274-46d1-ba2d-e70514c40fc3@github.com> Message-ID: On Mon, 5 Jan 2026 19:32:13 GMT, Kim Barrett wrote: >> Please review this change that adds a HotSpot wrapper for . 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 `` and `` to include the wrapper instead. >> There are still a couple of includes of `` 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 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: References: Message-ID: On Thu, 8 Jan 2026 06:20:12 GMT, David Holmes 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: 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: References: Message-ID: On Thu, 8 Jan 2026 09:42:58 GMT, Volkan Yazici 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: References: 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 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: References: Message-ID: > 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: References: Message-ID: On Tue, 23 Dec 2025 05:31:30 GMT, David Holmes 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 [v3] In-Reply-To: <01TjzVoQfydIB1hGUPH4BdIEQoxYa42GV8mQJ-h7-_M=.3e50e251-e2ea-40b7-a11b-147519817936@github.com> References: <4xK-xF1D4khPfnCGygZ2pLN1SVwdVpjcvPeAl0ZUEOk=.a2de074b-192f-4129-9cf7-da5b7bd347b4@github.com> <01TjzVoQfydIB1hGUPH4BdIEQoxYa42GV8mQJ-h7-_M=.3e50e251-e2ea-40b7-a11b-147519817936@github.com> Message-ID: On Thu, 8 Jan 2026 07:28:28 GMT, David Holmes 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 In-Reply-To: References: Message-ID: On Thu, 25 Dec 2025 04:00:00 GMT, Kim Barrett wrote: > Please review these fairly simple changes to code in gc/shared to use > `Atomic` 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 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 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: References: Message-ID: On Wed, 7 Jan 2026 08:18:25 GMT, Roland Westrelin 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: References: Message-ID: On Wed, 7 Jan 2026 08:16:55 GMT, Roland Westrelin 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: References: Message-ID: On Thu, 8 Jan 2026 11:42:40 GMT, Christian Hagedorn 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: References: <41ClGzK_bnZ3nmexlGdQW7Ncdh1q31ZDX_KZ1vBPNb4=.49a051e8-9345-4fe5-b635-efe44a21c051@github.com> Message-ID: On Wed, 7 Jan 2026 12:25:38 GMT, Aleksey Shipilev 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: References: Message-ID: On Wed, 7 Jan 2026 14:20:34 GMT, Markus Gr?nlund 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: 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: References: 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 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: <8LD4JmIZnVSwmhLeVZROok-0h-nCD1TxlaSRHe586-E=.99a49bfa-444f-4ddf-b206-0a75fe1dad23@github.com> Message-ID: On Wed, 7 Jan 2026 17:23:25 GMT, Martin Doerr 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: References: <8LD4JmIZnVSwmhLeVZROok-0h-nCD1TxlaSRHe586-E=.99a49bfa-444f-4ddf-b206-0a75fe1dad23@github.com> Message-ID: On Wed, 7 Jan 2026 17:45:55 GMT, Markus Gr?nlund 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: References: <8LD4JmIZnVSwmhLeVZROok-0h-nCD1TxlaSRHe586-E=.99a49bfa-444f-4ddf-b206-0a75fe1dad23@github.com> Message-ID: On Wed, 7 Jan 2026 17:45:55 GMT, Markus Gr?nlund 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: References: Message-ID: On Wed, 7 Jan 2026 17:52:50 GMT, Volodymyr Paprotski 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: References: Message-ID: <31ndTk5iWs478rKrz34crpL5m9IoQEXbU1EwqwIKpCU=.faef8dff-858f-4a68-990c-c7716abb625f@github.com> On Thu, 8 Jan 2026 09:53:56 GMT, Tobias Hartmann 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: References: Message-ID: On Thu, 8 Jan 2026 09:42:58 GMT, Volkan Yazici 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 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: References: <41ClGzK_bnZ3nmexlGdQW7Ncdh1q31ZDX_KZ1vBPNb4=.49a051e8-9345-4fe5-b635-efe44a21c051@github.com> Message-ID: On Thu, 8 Jan 2026 12:02:07 GMT, Andrew Dinn 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: References: Message-ID: > 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: References: Message-ID: On Thu, 8 Jan 2026 12:31:50 GMT, Tobias Hartmann 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: References: Message-ID: <-hubTcbRW128C1Uuvoq1xx9KfIFLnYGh8gUB757p6iA=.3596b81a-b8b8-491a-a709-7268e3300a92@github.com> On Mon, 22 Dec 2025 12:09:01 GMT, Jatin Bhateja 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: <-hubTcbRW128C1Uuvoq1xx9KfIFLnYGh8gUB757p6iA=.3596b81a-b8b8-491a-a709-7268e3300a92@github.com> Message-ID: On Thu, 8 Jan 2026 15:57:39 GMT, Emanuel Peter 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: References: <41ClGzK_bnZ3nmexlGdQW7Ncdh1q31ZDX_KZ1vBPNb4=.49a051e8-9345-4fe5-b635-efe44a21c051@github.com> Message-ID: On Wed, 7 Jan 2026 12:25:38 GMT, Aleksey Shipilev 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: References: Message-ID: > Intel® 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: References: Message-ID: > 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: References: Message-ID: <_GAfe6pIqFre0blQwFU-JXJ79CCSk5Ft_kxJhcg0agw=.acf06ec5-399e-4c48-bd26-f15e8b647908@github.com> > Intel® 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: 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: References: Message-ID: > 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: References: Message-ID: <_poEM0jDKsWBuurL7QIKXnl9fBQV596DFHgNIcNPUpI=.4c229767-47d5-4997-ad45-a53b622ded19@github.com> On Wed, 7 Jan 2026 17:47:47 GMT, jonghoonpark 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: References: Message-ID: On Thu, 8 Jan 2026 19:50:08 GMT, Kieran Farrell 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: References: Message-ID: > 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: References: Message-ID: On Thu, 8 Jan 2026 19:50:08 GMT, Kieran Farrell 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: References: <41ClGzK_bnZ3nmexlGdQW7Ncdh1q31ZDX_KZ1vBPNb4=.49a051e8-9345-4fe5-b635-efe44a21c051@github.com> Message-ID: On Wed, 7 Jan 2026 12:25:38 GMT, Aleksey Shipilev 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: References: Message-ID: On Thu, 8 Jan 2026 20:35:33 GMT, Kieran Farrell 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: References: Message-ID: <0n3cejZUsIIyKQqkBh36ykAx9bhB_GApD7l14BCBjX0=.2fd420ac-ea86-41ef-a1f9-927b8032b670@github.com> On Thu, 8 Jan 2026 20:35:33 GMT, Kieran Farrell 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: References: Message-ID: > 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: References: Message-ID: On Wed, 7 Jan 2026 14:14:19 GMT, Markus Gr?nlund 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: <0n3cejZUsIIyKQqkBh36ykAx9bhB_GApD7l14BCBjX0=.2fd420ac-ea86-41ef-a1f9-927b8032b670@github.com> Message-ID: On Thu, 8 Jan 2026 21:02:37 GMT, Kevin Walls 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: 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: <_GAfe6pIqFre0blQwFU-JXJ79CCSk5Ft_kxJhcg0agw=.acf06ec5-399e-4c48-bd26-f15e8b647908@github.com> Message-ID: On Thu, 8 Jan 2026 19:20:06 GMT, Mohamed Issa wrote: >> Intel® 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: References: <_GAfe6pIqFre0blQwFU-JXJ79CCSk5Ft_kxJhcg0agw=.acf06ec5-399e-4c48-bd26-f15e8b647908@github.com> Message-ID: On Fri, 9 Jan 2026 00:26:17 GMT, Sandhya Viswanathan 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: References: Message-ID: On Sat, 29 Nov 2025 06:06:16 GMT, Yasumasa Suenaga 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: References: <_GAfe6pIqFre0blQwFU-JXJ79CCSk5Ft_kxJhcg0agw=.acf06ec5-399e-4c48-bd26-f15e8b647908@github.com> Message-ID: On Fri, 9 Jan 2026 00:32:09 GMT, Sandhya Viswanathan 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: References: Message-ID: On Fri, 31 Oct 2025 14:00:38 GMT, Justin King 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: References: Message-ID: On Tue, 14 Oct 2025 13:20:40 GMT, Justin King 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: References: <41ClGzK_bnZ3nmexlGdQW7Ncdh1q31ZDX_KZ1vBPNb4=.49a051e8-9345-4fe5-b635-efe44a21c051@github.com> Message-ID: On Wed, 7 Jan 2026 12:25:38 GMT, Aleksey Shipilev 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 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 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: References: <0n3cejZUsIIyKQqkBh36ykAx9bhB_GApD7l14BCBjX0=.2fd420ac-ea86-41ef-a1f9-927b8032b670@github.com> Message-ID: On Thu, 8 Jan 2026 22:08:21 GMT, Larry Cable 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: References: Message-ID: On Thu, 8 Jan 2026 15:38:53 GMT, Volodymyr Paprotski 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: 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: References: Message-ID: On Fri, 9 Jan 2026 08:17:53 GMT, Richard Reingruber 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: References: Message-ID: <2bdHW_mOgPUvd8Zb8nce0D2uzw99zHgHnRnlbVifnus=.8ca9cd5c-6cd5-4b52-9df4-7f4662a2b7e2@github.com> On Mon, 5 Jan 2026 09:32:22 GMT, Roland Westrelin 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: References: Message-ID: On Thu, 18 Dec 2025 08:31:35 GMT, Roland Westrelin 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 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: References: Message-ID: On Wed, 7 Jan 2026 12:58:43 GMT, Leo Korinth wrote: >> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. >> >> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. >> >> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. >> >> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. > > Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 564 commits: > > - Merge branch '8373253' into 8367993 > - Merge branch 'master' into _8373253 > - Merge branch 'master' into _8367993 > - 8366058: Outdated comment in WinCAPISeedGenerator > > Reviewed-by: mullan > - 8357258: x86: Improve receiver type profiling reliability > > Reviewed-by: kvn, vlivanov > - 8373704: Improve "SocketException: Protocol family unavailable" message > > Reviewed-by: lucy, jpai > - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently > > Reviewed-by: jiefu, jbhateja, erfang, qamai > - 8343809: Add requires tag to mark tests that are incompatible with exploded image > > Reviewed-by: alanb, dholmes > - 8374465: Spurious dot in documentation for JVMTI ClassLoad > > Reviewed-by: kbarrett > - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket > > Reviewed-by: djelinski, mpowers, ascarpino > - ... and 554 more: https://git.openjdk.org/jdk/compare/2aa8aa4b...28ccbb68 Thanks for looking into this Leo. Overall I think it looks good, just some small questions and suggestions. src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1637: > 1635: > 1636: bool G1CollectedHeap::concurrent_mark_is_terminating() const { > 1637: assert(_cm != nullptr, "thread must exist in order to check if mark is terminating"); I think it would make sense to add `&& _cm->is_fully_initialized()` to really make sure the thread has been created. src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2427: > 2425: if (_cm->is_fully_initialized()) { > 2426: tc->do_thread(_cm->cm_thread()); > 2427: } Since the _cm_thread is now in `G1ConcurrentMark` this should be handled in `G1ConcurrentMark::threads_do()` src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2549: > 2547: void G1CollectedHeap::start_concurrent_cycle(bool concurrent_operation_is_full_mark) { > 2548: assert(!_cm->in_progress(), "Can not start concurrent operation while in progress"); > 2549: assert(_cm->is_fully_initialized(), "sanity"); Not sure this sanity assert is needed `_cm->in_progress()` will always return `false` if not fully initialized, so the above assert will cover this. If we still want it, I think it should be moved above the `in_progress()` assert. src/hotspot/share/gc/g1/g1PeriodicGCTask.cpp line 46: > 44: return false; > 45: } > 46: Why is this needed? The initial young collection will make sure concurrent marking gets initialized, right? src/hotspot/share/gc/g1/g1Policy.cpp line 744: > 742: if (!_g1h->concurrent_mark()->is_fully_initialized()) { > 743: return false; > 744: } Is this needed? The `in_progress()` check below makes sure to only check the cm_thread when fully initialized. src/hotspot/share/gc/g1/g1YoungCollector.cpp line 1127: > 1125: > 1126: void G1YoungCollector::collect() { > 1127: _g1h->_cm->fully_initialize(); I think it would make more sense to do this in `G1CollectedHeap::do_collection_pause_at_safepoint()`. There we check if we should start concurrent mark, so maybe the initialization could be done only if we are about to start concurrent mark. If we can do the initialization after the actual young collection, then we could maybe even move the initialization into `G1CollectedHeap::start_concurrent_cycle(...)` ------------- Changes requested by sjohanss (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28723#pullrequestreview-3639436840 PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2672366755 PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675276733 PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675291347 PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675313622 PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675328503 PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675249630 From 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: References: Message-ID: <2vYchq-CkYIofednbT3mCis7UFBKeajU134sdoyssRo=.015da7ff-63ba-4105-8054-1991c339d742@github.com> On Thu, 8 Jan 2026 21:27:18 GMT, Kieran Farrell 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== 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: <_poEM0jDKsWBuurL7QIKXnl9fBQV596DFHgNIcNPUpI=.4c229767-47d5-4997-ad45-a53b622ded19@github.com> Message-ID: On Thu, 8 Jan 2026 19:55:38 GMT, David Holmes 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: References: 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: On Thu, 8 Jan 2026 13:54:59 GMT, Thomas Schatzl 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(pointer_delta(MAX2(mr.start(), obj->base()), obj->base(), heapOopSize)); > 191: int end = checked_cast(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::compare_set Message-ID: 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 ([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::compare_set In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 09:47:18 GMT, Aleksey Shipilev 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 ([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::compare_set In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 09:47:18 GMT, Aleksey Shipilev 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 ([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: References: <-hubTcbRW128C1Uuvoq1xx9KfIFLnYGh8gUB757p6iA=.3596b81a-b8b8-491a-a709-7268e3300a92@github.com> Message-ID: On Thu, 8 Jan 2026 16:05:47 GMT, Emanuel Peter 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: <-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 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: References: Message-ID: On Thu, 8 Jan 2026 21:42:16 GMT, Robert Toyonaga 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: <3qlmxsr_9xjvyzplwqR6Q0Z5smdoGqVfQ7wsCiafad0=.daf5745a-4c15-420a-b76a-82a8543c2fdb@github.com> Message-ID: On Fri, 9 Jan 2026 09:54:08 GMT, Kieran Farrell 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 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: References: Message-ID: On Fri, 9 Jan 2026 08:17:53 GMT, Richard Reingruber 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: References: <-hubTcbRW128C1Uuvoq1xx9KfIFLnYGh8gUB757p6iA=.3596b81a-b8b8-491a-a709-7268e3300a92@github.com> Message-ID: On Fri, 9 Jan 2026 10:20:40 GMT, Jatin Bhateja 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: References: Message-ID: On Wed, 7 Jan 2026 12:33:41 GMT, Leo Korinth wrote: >> Leo Korinth has updated the pull request incrementally with 561 additional commits since the last revision: >> >> - Merge branch 'master' into _8367993 >> - 8366058: Outdated comment in WinCAPISeedGenerator >> >> Reviewed-by: mullan >> - 8357258: x86: Improve receiver type profiling reliability >> >> Reviewed-by: kvn, vlivanov >> - 8373704: Improve "SocketException: Protocol family unavailable" message >> >> Reviewed-by: lucy, jpai >> - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently >> >> Reviewed-by: jiefu, jbhateja, erfang, qamai >> - 8343809: Add requires tag to mark tests that are incompatible with exploded image >> >> Reviewed-by: alanb, dholmes >> - 8374465: Spurious dot in documentation for JVMTI ClassLoad >> >> Reviewed-by: kbarrett >> - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket >> >> Reviewed-by: djelinski, mpowers, ascarpino >> - 8374444: Fix simple -Wzero-as-null-pointer-constant warnings >> >> Reviewed-by: aboldtch >> - 8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the ?Nothing? menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test >> >> Reviewed-by: serb, aivanov, dnguyen >> - ... and 551 more: https://git.openjdk.org/jdk/compare/b907b295...0ece3767 > > I will redo the merge, I have done something strange. @lkorinth Something went wrong with your merge and now there's a bunch of unrelated labels, which results in updates being sent to misc mailing lists that has no interest in this PR. Could you remove all those labels? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28723#issuecomment-3728642315 From 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: References: <_poEM0jDKsWBuurL7QIKXnl9fBQV596DFHgNIcNPUpI=.4c229767-47d5-4997-ad45-a53b622ded19@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 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::compare_set In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 09:47:18 GMT, Aleksey Shipilev 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 ([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::compare_set In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 12:26:29 GMT, Kim Barrett 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 ([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: <-hubTcbRW128C1Uuvoq1xx9KfIFLnYGh8gUB757p6iA=.3596b81a-b8b8-491a-a709-7268e3300a92@github.com> <7vaiclFr4CafZJPXdzEDMSHZKKQ9KeE5h23NOetMI-A=.1d794b6e-e744-43b8-8407-2a00f24e81e9@github.com> Message-ID: On Fri, 9 Jan 2026 10:22:23 GMT, Jatin Bhateja 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::compare_set In-Reply-To: References: Message-ID: <7rLOjIFkhzajElaT0Qb9Wo5BlC2ZsPKQhnDDmcCUa8Y=.b13dea73-6a0e-45dd-960e-c3e8f08a467e@github.com> On Fri, 9 Jan 2026 12:30:36 GMT, Aleksey Shipilev 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: References: Message-ID: On Wed, 7 Jan 2026 17:47:47 GMT, jonghoonpark 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: References: 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: References: <-hubTcbRW128C1Uuvoq1xx9KfIFLnYGh8gUB757p6iA=.3596b81a-b8b8-491a-a709-7268e3300a92@github.com> <7vaiclFr4CafZJPXdzEDMSHZKKQ9KeE5h23NOetMI-A=.1d794b6e-e744-43b8-8407-2a00f24e81e9@github.com> Message-ID: <-KKGCQRZroe5N_-ftHQBuyu2M2ukHJ8yZTCxPBngJGA=.de3f8524-5ab0-40d5-b024-dab49731d217@github.com> On Fri, 9 Jan 2026 12:32:39 GMT, Emanuel Peter 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: References: Message-ID: > 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 ------------- 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: References: <3qlmxsr_9xjvyzplwqR6Q0Z5smdoGqVfQ7wsCiafad0=.daf5745a-4c15-420a-b76a-82a8543c2fdb@github.com> Message-ID: On Fri, 9 Jan 2026 11:31:17 GMT, Kieran Farrell 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: References: Message-ID: <1b5bZ4dnTl9J2GIWKpHg9DjIysgFdjEjLBMjkhFXh9k=.c14551ee-9012-4bf5-bb37-863b0c00741a@github.com> On Fri, 9 Jan 2026 14:10:42 GMT, jonghoonpark 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 Looks good to me. ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29096#pullrequestreview-3644185575 From vpaprotski at openjdk.org Fri Jan 9 16:27:13 2026 From: vpaprotski at openjdk.org (Volodymyr Paprotski) Date: Fri, 9 Jan 2026 16:27:13 GMT Subject: RFR: 8374570: Assertion failure in ClearArray.java with -XX:+EnableX86EcoreOpts [v4] In-Reply-To: References: Message-ID: <-CLnjzNm0uOoLBvw7bj8SY5dIJnY_L99R1RSWOFriKs=.88dba93a-381b-4c93-8536-69c88780c846@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/6a5f239f..41ea8da0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29070&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29070&range=02-03 Stats: 3 lines in 1 file changed: 2 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 vpaprotski at openjdk.org Fri Jan 9 16:37:48 2026 From: vpaprotski at openjdk.org (Volodymyr Paprotski) Date: Fri, 9 Jan 2026 16:37:48 GMT Subject: RFR: 8374570: Assertion failure in ClearArray.java with -XX:+EnableX86EcoreOpts [v5] In-Reply-To: References: Message-ID: > 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/41ea8da0..4b526d8e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29070&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29070&range=03-04 Stats: 3 lines in 1 file changed: 0 ins; 2 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 jwaters at openjdk.org Fri Jan 9 16:50:32 2026 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 9 Jan 2026 16:50:32 GMT Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v7] In-Reply-To: References: Message-ID: > This is a general cleanup and improvement of LTO, as well as a quick fix to remove a workaround in the Makefiles that disabled LTO for g1ParScanThreadState.cpp due to the old poisoning mechanism causing trouble. The -Wno-attribute-warning change here can be removed once Kim's new poisoning solution is integrated. > > - -fno-omit-frame-pointer is added to gcc to stop the linker from emitting code without the frame pointer > - -flto is set to $(JOBS) instead of auto to better match what the user requested > - -Gy is passed to the Microsoft compiler. This does not fully fix LTO under Microsoft, but prevents warnings about -LTCG:INCREMENTAL at least Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: - Merge branch 'openjdk:master' into patch-16 - Implement basic Link Time Optimization in LibCommon.gmk - Implement basic Link Time Optimization for executables in LauncherCommon.gmk - Revert LINK_TIME_OPTIMIZATION in ClientLibraries.gmk - Merge branch 'master' into patch-16 - Merge branch 'master' into patch-16 - Revert recent changes to ClientLibraries.gmk - Revert recent changes to CompileJvm.gmk - Revert recent changes to Flags.gmk - Revert recent changes to NativeCompilation.gmk - ... and 17 more: https://git.openjdk.org/jdk/compare/8737a8ca...47a6dc55 ------------- Changes: https://git.openjdk.org/jdk/pull/22464/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22464&range=06 Stats: 85 lines in 11 files changed: 35 ins; 46 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22464.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22464/head:pull/22464 PR: https://git.openjdk.org/jdk/pull/22464 From jwaters at openjdk.org Fri Jan 9 17:10:01 2026 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 9 Jan 2026 17:10:01 GMT Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2] In-Reply-To: References: Message-ID: On Tue, 21 Oct 2025 13:37:47 GMT, Kim Barrett wrote: > FWIW, I'm prototyping a possible change in g1ParScanThreadState.cpp that might substantially reduce the amount of generated code there. It might not work out; I haven't done any performance testing yet, and it's really easy to introduce performance regressions when making changes to that code. But if it does work, that might help with the problems here. Hi, I didn't ask initially because I didn't want to sound rude, but did this go anywhere? It would be a huge help if this change managed to curb the inlining in that file. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3729828280 From duke at openjdk.org Fri Jan 9 17:30:37 2026 From: duke at openjdk.org (Larry Cable) Date: Fri, 9 Jan 2026 17:30:37 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v2] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Wed, 7 Jan 2026 10:07:02 GMT, Kevin Walls 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/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. I view "ik" like "i" in a for loop, I dont think that defining two additional InstanceKlass'es for "pd" or "cs" when their values are subsequently only used once is merited, but its subjective. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2676994050 From duke at openjdk.org Fri Jan 9 17:30:41 2026 From: duke at openjdk.org (Larry Cable) Date: Fri, 9 Jan 2026 17:30:41 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v2] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Tue, 6 Jan 2026 23:46:44 GMT, David Holmes 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/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?? good question, but I think defensive coding is warranted, and this is not a performance sensitive code path IMO, > 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?? good question, but I think defensive coding is warranted, and this is not a performance sensitive code path IMO > 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? I am simply reusing an existing pattern I found elsewhere in the corpus where code that accessed a field by name with the intent to process as a String tested the type, its my practice to code with safety, while its unlikely that the type of the field will change, I think its safer to test prior to invoking a type specific API. If you feel strongly about this, I will remove the klass comparision. :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2676996740 PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2677014140 PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2677011507 From lmesnik at openjdk.org Fri Jan 9 17:40:38 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 9 Jan 2026 17:40:38 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v15] In-Reply-To: <6rYc9li648OsjOTvIZNadA0M4Dw_g0zwWtwPqCKGgxU=.e6b7b01d-5af8-421f-b2ae-9fedc5a69ba2@github.com> References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> <6rYc9li648OsjOTvIZNadA0M4Dw_g0zwWtwPqCKGgxU=.e6b7b01d-5af8-421f-b2ae-9fedc5a69ba2@github.com> Message-ID: On Wed, 24 Dec 2025 08:22:58 GMT, SendaoYan wrote: >> Hi all, >> >> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. >> >> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. >> >> Additional testing: >> >> - [x] All jtreg tests by fastdebug build > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Change the copyright year from 2025 to 2026 The fix looks good. Thank you for this improvement. Hope it makes our testing more stable. ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28891#pullrequestreview-3644932150 From lmesnik at openjdk.org Fri Jan 9 17:46:02 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 9 Jan 2026 17:46:02 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v2] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Fri, 9 Jan 2026 17:26:30 GMT, Larry Cable wrote: >> 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?? > > good question, but I think defensive coding is warranted, and this is not a performance sensitive code path IMO I would prefer to add assertion it such cases. So we can see during testing if assumption is incorrect. It also helps to find changed invariants earlier. The defensive code path might be fine for product to don't bother users with crashes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2677066611 From wkemper at openjdk.org Fri Jan 9 17:52:35 2026 From: wkemper at openjdk.org (William Kemper) Date: Fri, 9 Jan 2026 17:52:35 GMT Subject: RFR: 8373203: Genshen: Non-strong reference leak in old gen [v8] In-Reply-To: References: Message-ID: > 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 23 commits: - Merge remote-tracking branch 'jdk/master' into fix-old-reference-processing - 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 - Sort includes - Heal old discovered lists in parallel - Fix comment - Factor duplicate code into shared method - ... and 13 more: https://git.openjdk.org/jdk/compare/f5fa9e40...abccb8b6 ------------- Changes: https://git.openjdk.org/jdk/pull/28810/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28810&range=07 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 shade at openjdk.org Fri Jan 9 17:55:21 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 9 Jan 2026 17:55:21 GMT Subject: RFR: 8374878: Add Atomic::compare_set [v2] In-Reply-To: References: Message-ID: > 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 ([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. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `all` Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Missed another use - Delegate non-translating version - Merge branch 'master' into JDK-8374878-atomic-compare-set - Indenting is a bit off - Fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29135/files - new: https://git.openjdk.org/jdk/pull/29135/files/b06ab798..3eeec457 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29135&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29135&range=00-01 Stats: 4551 lines in 112 files changed: 2605 ins; 1587 del; 359 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 17:55:21 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 9 Jan 2026 17:55:21 GMT Subject: RFR: 8374878: Add Atomic::compare_set In-Reply-To: References: Message-ID: <3jaxOKWheyM1rPYdRDzyG4qJWcNMAcnz3uhDAsL51Jc=.4ec9ba70-3518-43a4-a288-f1dacd301460@github.com> On Fri, 9 Jan 2026 09:47:18 GMT, Aleksey Shipilev 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 ([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. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `all` First run of Linux x86_64 server fastdebug, `all` yields no failures. I polished the patch a little, and now running the second iteration. If it is still clean, and I have no other comments, I'll integrate. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29135#issuecomment-3729965567 From shade at openjdk.org Fri Jan 9 17:55:22 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 9 Jan 2026 17:55:22 GMT Subject: RFR: 8374878: Add Atomic::compare_set [v2] In-Reply-To: <7rLOjIFkhzajElaT0Qb9Wo5BlC2ZsPKQhnDDmcCUa8Y=.b13dea73-6a0e-45dd-960e-c3e8f08a467e@github.com> References: <7rLOjIFkhzajElaT0Qb9Wo5BlC2ZsPKQhnDDmcCUa8Y=.b13dea73-6a0e-45dd-960e-c3e8f08a467e@github.com> Message-ID: On Fri, 9 Jan 2026 12:48:08 GMT, Kim Barrett wrote: >> 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. Non-translated version updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29135#discussion_r2677085854 From kevinw at openjdk.org Fri Jan 9 17:58:35 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 9 Jan 2026 17:58:35 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v2] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Fri, 9 Jan 2026 17:22:04 GMT, Larry Cable wrote: >> 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. > > I view "ik" like "i" in a for loop, I dont think that defining two additional InstanceKlass'es for "pd" or "cs" when their values are subsequently only used once is merited, but its subjective. ok no problem ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2677101240 From kfarrell at openjdk.org Fri Jan 9 18:38:53 2026 From: kfarrell at openjdk.org (Kieran Farrell) Date: Fri, 9 Jan 2026 18:38:53 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v6] In-Reply-To: References: Message-ID: <10YcFooDOHT6M4PWRHBAUzYNhQW1X1nnaLPGIcDrgFE=.1e66f22a-8643-4ee1-bd88-e854fd4d48f7@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: sperate VM.sec_props command ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29124/files - new: https://git.openjdk.org/jdk/pull/29124/files/ee7d4707..db9e0e97 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=04-05 Stats: 63 lines in 3 files changed: 0 ins; 26 del; 37 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 kbarrett at openjdk.org Fri Jan 9 19:15:23 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 9 Jan 2026 19:15:23 GMT Subject: RFR: 8374878: Add Atomic::compare_set [v2] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 17:55:21 GMT, Aleksey Shipilev 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 ([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. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Missed another use > - Delegate non-translating version > - Merge branch 'master' into JDK-8374878-atomic-compare-set > - Indenting is a bit off > - Fix Looks good. Note that the recent updates invalidated prior approvals. So here's a re-approval. src/hotspot/share/gc/shared/taskqueue.inline.hpp line 289: > 287: // Note that using "bottom" here might fail, since a pop_local might > 288: // have decremented it. > 289: assert_not_underflow(localBot, newAge.top()); [pre-existing] This assertion seems weird. It is checking `newAge.top()` after already using been installed. Maybe it is misplaced? Or maybe it is checking the wrong thing? Needs to be investigated. I've filed https://bugs.openjdk.org/browse/JDK-8374915 ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29135#pullrequestreview-3645249668 PR Review Comment: https://git.openjdk.org/jdk/pull/29135#discussion_r2677331195 From cjplummer at openjdk.org Fri Jan 9 19:57:11 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 9 Jan 2026 19:57:11 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v15] In-Reply-To: <6rYc9li648OsjOTvIZNadA0M4Dw_g0zwWtwPqCKGgxU=.e6b7b01d-5af8-421f-b2ae-9fedc5a69ba2@github.com> References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> <6rYc9li648OsjOTvIZNadA0M4Dw_g0zwWtwPqCKGgxU=.e6b7b01d-5af8-421f-b2ae-9fedc5a69ba2@github.com> Message-ID: On Wed, 24 Dec 2025 08:22:58 GMT, SendaoYan wrote: >> Hi all, >> >> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. >> >> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. >> >> Additional testing: >> >> - [x] All jtreg tests by fastdebug build > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Change the copyright year from 2025 to 2026 Changes requested by cjplummer (Reviewer). test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java line 112: > 110: int iter = 0; > 111: while (num == 0) { > 112: // The unload is delayed because it happens asyns should be "async" ------------- PR Review: https://git.openjdk.org/jdk/pull/28891#pullrequestreview-3609731661 PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2677442634 From cjplummer at openjdk.org Fri Jan 9 19:57:15 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 9 Jan 2026 19:57:15 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v11] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: <3to4xyHNoj9lZCwBS4HgkvRvvTTUmpYuZTnzznsGNN8=.dc847c71-f018-4845-8c24-8c1cf8cbd4dc@github.com> On Tue, 23 Dec 2025 07:32:47 GMT, SendaoYan wrote: >> Hi all, >> >> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. >> >> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. >> >> Additional testing: >> >> - [x] All jtreg tests by fastdebug build > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Update commnets for ClassUnloader test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 42: > 40: * using WhiteBox.fullGC technique. > 41: * > 42: *

The method unloadClass() is provided which call should be "calls" test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 238: > 236: * > 237: * @throws Failure if exception other than OutOfMemoryError > 238: * is thrown while trigger full GC should be "triggering" test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 248: > 246: customClassLoader = null; > 247: > 248: // force class unloading by trigger full GC should be "triggering" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2644615480 PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2644616395 PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2644616746 From duke at openjdk.org Fri Jan 9 21:04:01 2026 From: duke at openjdk.org (duke) Date: Fri, 9 Jan 2026 21:04:01 GMT Subject: Withdrawn: 8367320: Sort cpu/x86 includes In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 09:17:07 GMT, Francesco Andreuzzi wrote: > Sort includes in `cpu/x86` using `SortIncludes.java`. I'm also removing a couple unnecessary ones. > > Passes `tier1` and `tier2`. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27189 From duke at openjdk.org Fri Jan 9 21:11:18 2026 From: duke at openjdk.org (Larry Cable) Date: Fri, 9 Jan 2026 21:11:18 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v3] In-Reply-To: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: > 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: added asserts ar per lmesnik comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29048/files - new: https://git.openjdk.org/jdk/pull/29048/files/dd11893b..b4a97882 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=01-02 Stats: 10 lines in 1 file changed: 8 ins; 0 del; 2 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 kbarrett at openjdk.org Fri Jan 9 22:36:18 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 9 Jan 2026 22:36:18 GMT Subject: RFR: 8372040: Remove Prefetch header vs inline header separation [v2] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 14:10:42 GMT, jonghoonpark 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 Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29096#pullrequestreview-3645767460 From duke at openjdk.org Fri Jan 9 22:36:19 2026 From: duke at openjdk.org (duke) Date: Fri, 9 Jan 2026 22:36:19 GMT Subject: RFR: 8372040: Remove Prefetch header vs inline header separation [v2] In-Reply-To: References: Message-ID: <_dqs4-01n5ok-nLPxufeB8J1g2s-oeJo8gpSq9JSaa0=.a64eab07-4e0b-4cd6-b569-da09c13ba027@github.com> On Fri, 9 Jan 2026 14:10:42 GMT, jonghoonpark 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-jonghoonpark Your change (at version f0a7117f1274d17eca5dbacb02db4b54b77fd438) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29096#issuecomment-3730802320 From kbarrett at openjdk.org Fri Jan 9 22:38:52 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 9 Jan 2026 22:38:52 GMT Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 17:05:37 GMT, Julian Waters wrote: > Hi, I didn't ask initially because I didn't want to sound rude, but did this go anywhere? It would be a huge help if this change managed to curb the inlining in that file. It's still in progress, and going slowly. There's a lot of performance testing involved, and even small changes can affect that. It's one of the most performance-critical pieces of G1. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3730804968 From kbarrett at openjdk.org Fri Jan 9 22:43:57 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 9 Jan 2026 22:43:57 GMT Subject: RFR: 8372040: Remove Prefetch header vs inline header separation [v2] In-Reply-To: References: Message-ID: <44R7eoNsWdHz6nAT8T_vyjSsWd7sfAE5DfRtjs2heug=.41b5914d-7ad1-4cec-a87c-f502c7f65874@github.com> On Fri, 9 Jan 2026 14:10:42 GMT, jonghoonpark 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 This PR (https://github.com/openjdk/jdk/pull/27189) (which was just closed as inactive) discusses some issues similar to what came up here, about headers that can't or shouldn't be included directly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29096#issuecomment-3730823189 From duke at openjdk.org Fri Jan 9 22:46:37 2026 From: duke at openjdk.org (jonghoonpark) Date: Fri, 9 Jan 2026 22:46:37 GMT Subject: Integrated: 8372040: Remove Prefetch header vs inline header separation In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 17:47:47 GMT, jonghoonpark 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. This pull request has now been integrated. Changeset: 805866bb Author: jonghoonpark Committer: Kim Barrett URL: https://git.openjdk.org/jdk/commit/805866bbf680f44219e5c634eb9726e1c5dea690 Stats: 103 lines in 18 files changed: 17 ins; 54 del; 32 mod 8372040: Remove Prefetch header vs inline header separation Reviewed-by: kbarrett, stefank ------------- PR: https://git.openjdk.org/jdk/pull/29096 From chagedorn at openjdk.org Fri Jan 9 22:51:14 2026 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Fri, 9 Jan 2026 22:51:14 GMT Subject: RFR: 8373343: C2: verify AddP base input only set for heap addresses [v3] In-Reply-To: References: Message-ID: <7AGclBaK6DfxQoJmjWgcjUamtX8ueUTJC8PdC9hC2dU=.e1881c83-2f73-4556-b00b-fb10be886bec@github.com> On Thu, 8 Jan 2026 11:53:25 GMT, Roland Westrelin wrote: >> Sounds good, let's do it separately. > > I filed: https://bugs.openjdk.org/browse/JDK-8374789 Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28769#discussion_r2677831123 From missa at openjdk.org Fri Jan 9 22:59:16 2026 From: missa at openjdk.org (Mohamed Issa) Date: Fri, 9 Jan 2026 22:59:16 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v4] In-Reply-To: References: Message-ID: > Intel® 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: Remove extra jump instruction in signum floating point and unify three-way floating point comparison logic in x86.ad ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28337/files - new: https://git.openjdk.org/jdk/pull/28337/files/38735c37..cd7acad7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28337&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28337&range=02-03 Stats: 23 lines in 2 files changed: 9 ins; 11 del; 3 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 ghan at openjdk.org Sat Jan 10 00:15:16 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Sat, 10 Jan 2026 00:15:16 GMT Subject: RFR: 8374807: Crash in MethodData::extra_data_lock()+0x0 when running -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp -version Message-ID: Please review this change. Thanks! Description: This change fixes a crash in Deoptimization::uncommon_trap_inner when running with -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp. With -XX:-ProfileTraps, create_if_missing is set to false. https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L2121-L2122 When create_if_missing is false, new mdo can not be created when m()->method_data() return null, so get_method_data() may return null . https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L1911-L1912 and trap_mdo can be null as a result https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L2134-L2136 The crash happens here because trap_mdo is null https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L2157 Fix: The fix makes acquisition of extra_data_lock conditional on trap_mdo being non-null, preserving the required lock ordering (extra_data_lock before ttyLocker) when an MDO exists. Test: GHA ------------- Commit messages: - fix 8374807 Changes: https://git.openjdk.org/jdk/pull/29147/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29147&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374807 Stats: 42 lines in 2 files changed: 41 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29147.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29147/head:pull/29147 PR: https://git.openjdk.org/jdk/pull/29147 From dlong at openjdk.org Sat Jan 10 00:20:11 2026 From: dlong at openjdk.org (Dean Long) Date: Sat, 10 Jan 2026 00:20:11 GMT Subject: RFR: 8373343: C2: verify AddP base input only set for heap addresses [v4] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 08:16:55 GMT, Roland Westrelin 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/6b450b5c...b20f41db src/hotspot/share/opto/macroArrayCopy.cpp line 936: > 934: end = transform_later(new AndXNode(end, MakeConX(~end_round)) ); > 935: mem = ClearArrayNode::clear_memory(ctrl, mem, dest, > 936: start_con, end, false,&_igvn); Suggestion: start_con, end, false, &_igvn); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28769#discussion_r2677995370 From ysr at openjdk.org Sat Jan 10 01:00:22 2026 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Sat, 10 Jan 2026 01:00:22 GMT Subject: RFR: 8373203: Genshen: Non-strong reference leak in old gen [v8] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 17:52:35 GMT, William Kemper 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 23 commits: > > - Merge remote-tracking branch 'jdk/master' into fix-old-reference-processing > - 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 > - Sort includes > - Heal old discovered lists in parallel > - Fix comment > - Factor duplicate code into shared method > - ... and 13 more: https://git.openjdk.org/jdk/compare/f5fa9e40...abccb8b6 > 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). Naive question: The basic issue appears to be that the marking state of the referent may not be visible to the gc that is processing the reference when they are in different generations. If we wait for them to both be in the same generation, the same marking will both discover the reference and know the reachability of the referent whence it can be collected. Why can't we just wait for the reference and referent to both be tenured into the old generation before they are processed? I realize this delays processing until such time that we have either a global marking, a full collection, or the reference and referent both end up in the old generation. It is possible I misunderstood the original problem. Can you explain what is causing the leak here? i.e. what causes us not to eventually discover and process the reference when both it and its referent are in the old generation? Why does the `should_discover()` on the reference in the old generation return false when its referent is also in the same genereation. Many years ago the concept of this visibility across generations was handled by means of a "span" (of marking visiblity if you will) that the reference processor carried, so that it would leave alone and not discover references whose referent was in a different generation. The same issue existed in CMS where it was dealt with by allowing the reference and referent to both migrate into the same (old) generation at which point reference processing would deal with it because it had full reachability visibility at that point on. Here we seem to be considering a leak where we are left in a state where we never discover the reference even after it and its referent are both in the old generation. How does that happen? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28810#issuecomment-3731179370 From syan at openjdk.org Sat Jan 10 03:23:52 2026 From: syan at openjdk.org (SendaoYan) Date: Sat, 10 Jan 2026 03:23:52 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v16] In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: > Hi all, > > This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. > > Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. > > Additional testing: > > - [x] All jtreg tests by fastdebug build SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Fix several typos ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28891/files - new: https://git.openjdk.org/jdk/pull/28891/files/f72866e6..445515d8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=14-15 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28891.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28891/head:pull/28891 PR: https://git.openjdk.org/jdk/pull/28891 From syan at openjdk.org Sat Jan 10 03:23:54 2026 From: syan at openjdk.org (SendaoYan) Date: Sat, 10 Jan 2026 03:23:54 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v15] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> <6rYc9li648OsjOTvIZNadA0M4Dw_g0zwWtwPqCKGgxU=.e6b7b01d-5af8-421f-b2ae-9fedc5a69ba2@github.com> Message-ID: <9ddgWMyuGEZC-ZMrnKQkD77T8ufCwsEsbUInbL8_eIM=.87e835a9-f05b-45d4-a437-ae5e00344fa5@github.com> On Fri, 9 Jan 2026 19:51:19 GMT, Chris Plummer wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> Change the copyright year from 2025 to 2026 > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java line 112: > >> 110: int iter = 0; >> 111: while (num == 0) { >> 112: // The unload is delayed because it happens asyns > > should be "async" Sorry for the typo bug. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2678273418 From syan at openjdk.org Sat Jan 10 03:23:56 2026 From: syan at openjdk.org (SendaoYan) Date: Sat, 10 Jan 2026 03:23:56 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v11] In-Reply-To: <3to4xyHNoj9lZCwBS4HgkvRvvTTUmpYuZTnzznsGNN8=.dc847c71-f018-4845-8c24-8c1cf8cbd4dc@github.com> References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> <3to4xyHNoj9lZCwBS4HgkvRvvTTUmpYuZTnzznsGNN8=.dc847c71-f018-4845-8c24-8c1cf8cbd4dc@github.com> Message-ID: On Wed, 24 Dec 2025 02:05:21 GMT, Chris Plummer wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> Update commnets for ClassUnloader > > test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 42: > >> 40: * using WhiteBox.fullGC technique. >> 41: * >> 42: *

The method unloadClass() is provided which call > > should be "calls" Thanks. Fixed. > test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 238: > >> 236: * >> 237: * @throws Failure if exception other than OutOfMemoryError >> 238: * is thrown while trigger full GC > > should be "triggering" Thanks. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2678272674 PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2678273095 From ysuenaga at openjdk.org Sat Jan 10 03:42:54 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 10 Jan 2026 03:42:54 GMT Subject: RFR: 8374926: EnableX86ECoreOpts was not enabled on some hybrid CPU Message-ID: `EnableX86ECoreOpts` has been introduced in [JDK-8319429](https://bugs.openjdk.org/browse/JDK-8319429), however model numbers which should be enabled are hard-coded, so the flag would not be enabled by default on some models like Arrow Lake. I ran a [benchmark](https://github.com/YaSuenag/garakuta/tree/master/randminmax) to check for effectiveness of `-XX:+EnableX86ECoreOpts` with JDK 25.0.1 on Windows 11 25H2, I saw performance improvement a bit on Intel Core 5 Ultra 225U as following: Disabled (default) Benchmark Mode Cnt Score Error Units RandMinVal.getMax thrpt 3 9707774.405 ? 27082629.015 ops/s RandMinVal.getMin thrpt 3 7510319.839 ? 10923547.382 ops/s Enabled Benchmark Mode Cnt Score Error Units RandMinVal.getMax thrpt 3 10127809.127 ? 45404142.338 ops/s RandMinVal.getMin thrpt 3 8467677.056 ? 1211998.200 ops/s So I think it is better to enable this flag by default on all of hybrid CPUs. To check what processor would be enabled E-core optimization, I made a [commit](https://github.com/openjdk/jdk/commit/f363ea1436b8100021fdac87b48ec43bcf6820af) to add comments for CPU models at first. I couldn't find out all of models (some models has not listed in SDM vol.4 so far), but most of models (excepts Sierra Forest) could be treated as hybrid CPU. Fortunately HotSpot identify hybrid flag from `CPUID`, so we can leverage it for this purpose. ------------- Commit messages: - Use supports_hybrid() to check for EnableX86ECoreOpts - Add comments for CPU models Changes: https://git.openjdk.org/jdk/pull/29149/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29149&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374926 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29149.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29149/head:pull/29149 PR: https://git.openjdk.org/jdk/pull/29149 From ysuenaga at openjdk.org Sat Jan 10 04:58:02 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 10 Jan 2026 04:58:02 GMT Subject: RFR: 8374926: EnableX86ECoreOpts was not enabled on some hybrid CPU [v2] In-Reply-To: References: Message-ID: > `EnableX86ECoreOpts` has been introduced in [JDK-8319429](https://bugs.openjdk.org/browse/JDK-8319429), however model numbers which should be enabled are hard-coded, so the flag would not be enabled by default on some models like Arrow Lake. > > I ran a [benchmark](https://github.com/YaSuenag/garakuta/tree/master/randminmax) to check for effectiveness of `-XX:+EnableX86ECoreOpts` with JDK 25.0.1 on Windows 11 25H2, I saw performance improvement a bit on Intel Core 5 Ultra 225U as following: > > Disabled (default) > > Benchmark Mode Cnt Score Error Units > RandMinVal.getMax thrpt 3 9707774.405 ? 27082629.015 ops/s > RandMinVal.getMin thrpt 3 7510319.839 ? 10923547.382 ops/s > > > Enabled > > Benchmark Mode Cnt Score Error Units > RandMinVal.getMax thrpt 3 10127809.127 ? 45404142.338 ops/s > RandMinVal.getMin thrpt 3 8467677.056 ? 1211998.200 ops/s > > > So I think it is better to enable this flag by default on all of hybrid CPUs. > > > To check what processor would be enabled E-core optimization, I made a [commit](https://github.com/openjdk/jdk/commit/f363ea1436b8100021fdac87b48ec43bcf6820af) to add comments for CPU models at first. I couldn't find out all of models (some models has not listed in SDM vol.4 so far), but most of models (excepts Sierra Forest) could be treated as hybrid CPU. Fortunately HotSpot identify hybrid flag from `CPUID`, so we can leverage it for this purpose. Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into ecoreopt-hybrid - Use supports_hybrid() to check for EnableX86ECoreOpts - Add comments for CPU models ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29149/files - new: https://git.openjdk.org/jdk/pull/29149/files/96880609..8284b462 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29149&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29149&range=00-01 Stats: 163 lines in 5 files changed: 99 ins; 39 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/29149.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29149/head:pull/29149 PR: https://git.openjdk.org/jdk/pull/29149 From ysuenaga at openjdk.org Sun Jan 11 07:46:33 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sun, 11 Jan 2026 07:46:33 GMT Subject: RFR: 8374926: EnableX86ECoreOpts was not enabled on some hybrid CPU [v3] In-Reply-To: References: Message-ID: > `EnableX86ECoreOpts` has been introduced in [JDK-8319429](https://bugs.openjdk.org/browse/JDK-8319429), however model numbers which should be enabled are hard-coded, so the flag would not be enabled by default on some models like Arrow Lake. > > I ran a [benchmark](https://github.com/YaSuenag/garakuta/tree/master/randminmax) to check for effectiveness of `-XX:+EnableX86ECoreOpts` with JDK 25.0.1 on Windows 11 25H2, I saw performance improvement a bit on Intel Core 5 Ultra 225U as following: > > Disabled (default) > > Benchmark Mode Cnt Score Error Units > RandMinVal.getMax thrpt 3 9707774.405 ? 27082629.015 ops/s > RandMinVal.getMin thrpt 3 7510319.839 ? 10923547.382 ops/s > > > Enabled > > Benchmark Mode Cnt Score Error Units > RandMinVal.getMax thrpt 3 10127809.127 ? 45404142.338 ops/s > RandMinVal.getMin thrpt 3 8467677.056 ? 1211998.200 ops/s > > > So I think it is better to enable this flag by default on all of hybrid CPUs. > > > To check what processor would be enabled E-core optimization, I made a [commit](https://github.com/openjdk/jdk/commit/f363ea1436b8100021fdac87b48ec43bcf6820af) to add comments for CPU models at first. I couldn't find out all of models (some models has not listed in SDM vol.4 so far), but most of models (excepts Sierra Forest) could be treated as hybrid CPU. Fortunately HotSpot identify hybrid flag from `CPUID`, so we can leverage it for this purpose. Yasumasa Suenaga 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 four additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into ecoreopt-hybrid - Merge remote-tracking branch 'origin/master' into ecoreopt-hybrid - Use supports_hybrid() to check for EnableX86ECoreOpts - Add comments for CPU models ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29149/files - new: https://git.openjdk.org/jdk/pull/29149/files/8284b462..92e91552 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29149&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29149&range=01-02 Stats: 18 lines in 2 files changed: 7 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/29149.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29149/head:pull/29149 PR: https://git.openjdk.org/jdk/pull/29149 From shade at openjdk.org Sun Jan 11 20:41:11 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Sun, 11 Jan 2026 20:41:11 GMT Subject: RFR: 8374878: Add Atomic::compare_set [v2] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 17:55:21 GMT, Aleksey Shipilev 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 ([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. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Missed another use > - Delegate non-translating version > - Merge branch 'master' into JDK-8374878-atomic-compare-set > - Indenting is a bit off > - Fix Testing is still clean. I am integrating now, thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29135#issuecomment-3735730728 From shade at openjdk.org Sun Jan 11 20:41:13 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Sun, 11 Jan 2026 20:41:13 GMT Subject: Integrated: 8374878: Add Atomic::compare_set In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 09:47:18 GMT, Aleksey Shipilev 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 ([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. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `all` This pull request has now been integrated. Changeset: 33689485 Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/336894857bfc9f610da55e6180dd7b668bf67752 Stats: 56 lines in 8 files changed: 42 ins; 1 del; 13 mod 8374878: Add Atomic::compare_set Reviewed-by: kbarrett, stefank ------------- PR: https://git.openjdk.org/jdk/pull/29135 From aboldtch at openjdk.org Mon Jan 12 06:53:12 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 12 Jan 2026 06:53:12 GMT Subject: RFR: 8372241: Add GTestCheckers [v6] In-Reply-To: References: Message-ID: > 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 seven additional commits since the last revision: - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8372241 - 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/279c4430..ed372f17 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28409&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28409&range=04-05 Stats: 33779 lines in 805 files changed: 15462 ins; 5791 del; 12526 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 thartmann at openjdk.org Mon Jan 12 08:54:04 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 12 Jan 2026 08:54:04 GMT Subject: RFR: 8374570: Assertion failure in ClearArray.java with -XX:+EnableX86EcoreOpts [v5] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 16:37:48 GMT, Volodymyr Paprotski 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 Looks good to me. ------------- Marked as reviewed by thartmann (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29070#pullrequestreview-3649685618 From aboldtch at openjdk.org Mon Jan 12 09:58:43 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 12 Jan 2026 09:58:43 GMT Subject: RFR: 8372241: Add GTestCheckers [v7] In-Reply-To: References: Message-ID: > 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 incrementally with one additional commit since the last revision: Update copyright years ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28409/files - new: https://git.openjdk.org/jdk/pull/28409/files/ed372f17..990f4f58 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28409&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28409&range=05-06 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 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 tschatzl at openjdk.org Mon Jan 12 10:13:07 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 12 Jan 2026 10:13:07 GMT Subject: RFR: 8374780: G1: Do not iterate klass metadata when splitting objArrays for every slice In-Reply-To: References: <4iFTIPttYFA_jy2n-gPTPj-kKhbvifpaQ5pQWEW6xaQ=.71645432-df6a-4b6f-ac18-1d7d85cf2fb2@github.com> Message-ID: On Fri, 9 Jan 2026 09:37:47 GMT, Stefan Karlsson 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 > > src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp line 192: > >> 190: int start = checked_cast(pointer_delta(MAX2(mr.start(), obj->base()), obj->base(), heapOopSize)); >> 191: int end = checked_cast(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. I think most of the complexity you correctly point out comes from the unusual way G1 concurrent mark handles object array splitting. To avoid having two queues (e.g. one for objArrayOops, one for other oops), and then dealing with the question and complexity which to prefer to work on, it encodes objArrayOops as pointers somewhere into that oop. Everything else follows - the `MemRegion` passed to this method can be any part of the object, that may include the header. It needs to be skipped when calling the existing API to just iterate over array elements as it takes indexes. On hindsight I agree splitting out the MAX2() would have been better though. I will wait with this change on @walulyai 's effort to have g1 concurrent mark use the `PartialArraySplitter` used everywhere else, which will afaik naturally use indexes and all this conversion going away. Should have done that in the first place :I ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29116#discussion_r2681599476 From epeter at openjdk.org Mon Jan 12 10:14:28 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 12 Jan 2026 10:14:28 GMT Subject: RFR: 8374570: Assertion failure in ClearArray.java with -XX:+EnableX86EcoreOpts [v5] In-Reply-To: References: Message-ID: <-rUsu6HQ7w0J_D6BBMBRZc07QbYXBp4M-iC8IHRXqwY=.58bf85f6-d801-45e2-9271-e245805180e7@github.com> On Fri, 9 Jan 2026 16:37:48 GMT, Volodymyr Paprotski 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 Looks reasonable, thanks for fixing this! ------------- Marked as reviewed by epeter (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29070#pullrequestreview-3650014736 From qamai at openjdk.org Mon Jan 12 10:17:02 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 12 Jan 2026 10:17:02 GMT Subject: RFR: 8374570: Assertion failure in ClearArray.java with -XX:+EnableX86EcoreOpts [v5] In-Reply-To: References: Message-ID: <6Ie4tM8a3znNImryf3Ajp3kRhO4mL91BZ-5Quz7FeMc=.27fb6d94-0663-43f0-bf86-978b8402b938@github.com> On Fri, 9 Jan 2026 16:37:48 GMT, Volodymyr Paprotski 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 LGTM src/hotspot/cpu/x86/macroAssembler_x86.cpp line 6089: > 6087: > 6088: subptr(count, 16 << shift); > 6089: jcc(Assembler::less, L_check_fill_32_bytes); The copyright of this file needs fixing, too ------------- Marked as reviewed by qamai (Committer). PR Review: https://git.openjdk.org/jdk/pull/29070#pullrequestreview-3650024128 PR Review Comment: https://git.openjdk.org/jdk/pull/29070#discussion_r2681617709 From tschatzl at openjdk.org Mon Jan 12 10:24:27 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 12 Jan 2026 10:24:27 GMT Subject: RFR: 8374780: G1: Do not iterate klass metadata when splitting objArrays for every slice In-Reply-To: References: <4iFTIPttYFA_jy2n-gPTPj-kKhbvifpaQ5pQWEW6xaQ=.71645432-df6a-4b6f-ac18-1d7d85cf2fb2@github.com> Message-ID: On Fri, 9 Jan 2026 09:22:53 GMT, Stefan Karlsson wrote: > 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. Not sure if it is an inconsistency if the API clearly spells out the difference between `_range` and `_bounded`: `_range` gets array element indexes passed to it, so it is not possible that the given range can cover metadata, `_bounded` iterates a part of the entire object which contains metadata. I can see your point about changing `_bounded` maybe not iterating over the metadata if it does not cover it. As for checking whether the closure is not a metadata-processing one for `_range` is useful, but I would not recommend it for `_bounded` as this would likely just complicate code. `InstanceKlass::oop_oop_iterate_reverse/backwards` is already kind of a special hack for G1/Parallel young gc as some benchmark(s) shows significantly better performance if doing so (iirc). > 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. I would keep the names consistent. Also maybe, to make its use abundantly clear, call it `oop_iterate_array_elements`. (The header could also be considered a element/part of the `objArray`). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29116#discussion_r2681629009 PR Review Comment: https://git.openjdk.org/jdk/pull/29116#discussion_r2681637521 From aboldtch at openjdk.org Mon Jan 12 10:46:04 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 12 Jan 2026 10:46:04 GMT Subject: RFR: 8374878: Add Atomic::compare_set [v2] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 17:55:21 GMT, Aleksey Shipilev 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 ([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. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Missed another use > - Delegate non-translating version > - Merge branch 'master' into JDK-8374878-atomic-compare-set > - Indenting is a bit off > - Fix src/hotspot/share/runtime/atomic.hpp line 492: > 490: return _value.compare_set(decay(compare_value), > 491: decay(new_value), > 492: order); This is subtly different from what we usually did with AtomicAccess / Atomic compare_exchange on translated types. We used to check equality with the `bool operator==(const T&, constT&)` rather than `bool operator==(const PrimitiveConversions::Translate::Decayed&, const PrimitiveConversions::Translate::Decayed&)`. For the `PrimitiveConversions::Translate` we currently have I do not think there is an issues as they are `memcmp` equivalent in both cases. But we may introduce a PrimitiveConversion in the future where this is not the case and this function returns false when using `recover` and `bool operator==(const T&, constT&)` would have returned true. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29135#discussion_r2681709542 From roland at openjdk.org Mon Jan 12 12:11:51 2026 From: roland at openjdk.org (Roland Westrelin) Date: Mon, 12 Jan 2026 12:11:51 GMT Subject: RFR: 8373343: C2: verify AddP base input only set for heap addresses [v5] In-Reply-To: References: Message-ID: <_qZm_vXhwEf_OcRMb72w4t7vk1XKxjxwc_8eO1SmJsk=.d5ed1803-78b5-403a-baea-bbc5567facc7@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 incrementally with one additional commit since the last revision: Update src/hotspot/share/opto/macroArrayCopy.cpp Co-authored-by: Dean Long <17332032+dean-long at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28769/files - new: https://git.openjdk.org/jdk/pull/28769/files/b20f41db..507b8f45 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28769&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28769&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 aboldtch at openjdk.org Mon Jan 12 13:12:42 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 12 Jan 2026 13:12:42 GMT Subject: RFR: 8372248: GTest istream.coverage depends on istream.basic [v3] In-Reply-To: References: Message-ID: > These two GTests have a strong dependency that `istream.coverage` is ran after `istream.basic`. This goes against the intended design of GTests. (They should be independent). > > As such I propose we merge this into one test. > > I kept the two `VERBOSE` variables separate. However I am not sure I understand their purpose. > Currently changing `VERBOSE_TEST` to `true` will cause the test to fail, (not all cases are covered). And the value have of `VERBOSE_COVERAGE` has no effect. What is observed: > * `(VERBOSE_TEST: false, VERBOSE_COVERAGE: false) -> Success` > * `(VERBOSE_TEST: false, VERBOSE_COVERAGE: true) -> Success` > * `(VERBOSE_TEST: true, VERBOSE_COVERAGE: false) -> Failure` > * `(VERBOSE_TEST: true, VERBOSE_COVERAGE: true) -> Failure` > > But I kept the original behaviour, just merged into one test case rather than two. Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'JDK-8372241' into JDK-8372248 - Merge branch 'JDK-8372241' into JDK-8372248 - gtest istream.coverage depends on istream.basic ------------- Changes: https://git.openjdk.org/jdk/pull/28418/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28418&range=02 Stats: 9 lines in 2 files changed: 0 ins; 5 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28418.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28418/head:pull/28418 PR: https://git.openjdk.org/jdk/pull/28418 From aboldtch at openjdk.org Mon Jan 12 13:13:19 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 12 Jan 2026 13:13:19 GMT Subject: RFR: 8372245: GTest globalDefinitions.format_specifiers cannot run without VM [v3] In-Reply-To: References: Message-ID: > globalDefinitions.format_specifiers uses `ResourceMark` which requires a created VM. > Either we stop using resource allocations, or we run the test in VM. > > I propose we let this test simply use `stringStream::base` rather than `stringStream::as_string` which is an already managed string and the stream is in scope for as long as the string is used. The string is guaranteed to be valid as long as we do not write to the stream. Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'JDK-8372241' into JDK-8372245 - Merge branch 'JDK-8372241' into JDK-8372245 - gtest globalDefinitions.format_specifiers cannot run without VM ------------- Changes: https://git.openjdk.org/jdk/pull/28415/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28415&range=02 Stats: 5 lines in 2 files changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28415.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28415/head:pull/28415 PR: https://git.openjdk.org/jdk/pull/28415 From stefank at openjdk.org Mon Jan 12 14:27:41 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 12 Jan 2026 14:27:41 GMT Subject: RFR: 8375040: Clearer names for non-metadata oop iterators in ObjArrayKlass Message-ID: During the review of [JDK-8374780](https://bugs.openjdk.org/browse/JDK-8374780) it was clear that the naming of the various oop iterators, and also their comments, were somewhat misleading about if they visited the metadata or not. I propose that we make a clear separation and have it so that all iterators that only visit the array elements are named to contain the word "elements" to make it slightly clearer that these iterators only visits the elements. So, we know how the following ObjArrayKlass oop iterators: Iterators that also visit the metadata: oop_oop_iterate oop_oop_iterate_reverse oop_oop_iterate_bounded Iterators that are not visiting the metadata: oop_oop_iterate_elements oop_oop_iterate_elements_range oop_oop_iterate_elements_bounded The objArrayOopDesc class also exposes an oop iterator and that function has been renamed to mimic the above scheme to add the `_elements` to functions that does not visit the metadata: oop_iterate_elements_range Two extra things to check in the patch: 1) I did some slight tweaks to the code so that `oop_oop_iterate_elements` is implemented with `oop_oop_iterate_elements_range`. 2) I moved the objArrayOopDesc function back to the oopArrayOop.inline.hpp. The reason is that we have now solved the problems with circular dependencies between .inline.hpp files, so this workaround isn't needed anymore. ------------- Commit messages: - 8375040: Clearer names for non-metadata oop iterators in ObjArrayKlass Changes: https://git.openjdk.org/jdk/pull/29170/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29170&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375040 Stats: 62 lines in 11 files changed: 18 ins; 21 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/29170.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29170/head:pull/29170 PR: https://git.openjdk.org/jdk/pull/29170 From stefank at openjdk.org Mon Jan 12 14:27:42 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 12 Jan 2026 14:27:42 GMT Subject: RFR: 8375040: Clearer names for non-metadata oop iterators in ObjArrayKlass In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 14:15:57 GMT, Stefan Karlsson wrote: > During the review of [JDK-8374780](https://bugs.openjdk.org/browse/JDK-8374780) it was clear that the naming of the various oop iterators, and also their comments, were somewhat misleading about if they visited the metadata or not. > > I propose that we make a clear separation and have it so that all iterators that only visit the array elements are named to contain the word "elements" to make it slightly clearer that these iterators only visits the elements. > > So, we know how the following ObjArrayKlass oop iterators: > > Iterators that also visit the metadata: > > oop_oop_iterate > oop_oop_iterate_reverse > oop_oop_iterate_bounded > > > Iterators that are not visiting the metadata: > > oop_oop_iterate_elements > oop_oop_iterate_elements_range > oop_oop_iterate_elements_bounded > > > The objArrayOopDesc class also exposes an oop iterator and that function has been renamed to mimic the above scheme to add the `_elements` to functions that does not visit the metadata: > > oop_iterate_elements_range > > > Two extra things to check in the patch: > > 1) I did some slight tweaks to the code so that `oop_oop_iterate_elements` is implemented with `oop_oop_iterate_elements_range`. > > 2) I moved the objArrayOopDesc function back to the oopArrayOop.inline.hpp. The reason is that we have now solved the problems with circular dependencies between .inline.hpp files, so this workaround isn't needed anymore. Ping #29116 ------------- PR Comment: https://git.openjdk.org/jdk/pull/29170#issuecomment-3738773609 From jsjolen at openjdk.org Mon Jan 12 14:40:57 2026 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 12 Jan 2026 14:40:57 GMT Subject: RFR: 8366457: Add ResourceArea and Arena allocators for the RBTree In-Reply-To: <3Twy5bKqGLnCGzPgNHEGq5L9i1Qh1LM7WU-erWO-VDU=.935320d9-3b28-45d9-9135-b79de40f027d@github.com> References: <3Twy5bKqGLnCGzPgNHEGq5L9i1Qh1LM7WU-erWO-VDU=.935320d9-3b28-45d9-9135-b79de40f027d@github.com> Message-ID: On Fri, 9 Jan 2026 11:56:25 GMT, Casper Norrbin wrote: >> This PR adds Arena and ResourceArea allocators to the RBTree. The test checks that we can make RBTrees from these allocators and that a basic upsert works. > > src/hotspot/share/utilities/rbTree.hpp line 35: > >> 33: #include "nmt/memTag.hpp" >> 34: #include "runtime/os.hpp" >> 35: #include "runtime/thread.hpp" > > Do we need to include `allocation.hpp` and `thread.hpp`? I can't find what's using these and it builds fine for me with those includes removed. We need `allocation.hpp` as that provides AllocFailStrategy, etc. `thread.hpp` isn't needed, that was unfortunate left overs from my first draft. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29082#discussion_r2682541106 From jsjolen at openjdk.org Mon Jan 12 14:40:52 2026 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 12 Jan 2026 14:40:52 GMT Subject: RFR: 8366457: Add ResourceArea and Arena allocators for the RBTree Message-ID: This PR adds Arena and ResourceArea allocators to the RBTree. The test checks that we can make RBTrees from these allocators and that a basic upsert works. ------------- Commit messages: - Add allocators Changes: https://git.openjdk.org/jdk/pull/29082/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29082&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366457 Stats: 50 lines in 2 files changed: 49 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29082.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29082/head:pull/29082 PR: https://git.openjdk.org/jdk/pull/29082 From cnorrbin at openjdk.org Mon Jan 12 14:40:55 2026 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Mon, 12 Jan 2026 14:40:55 GMT Subject: RFR: 8366457: Add ResourceArea and Arena allocators for the RBTree In-Reply-To: References: Message-ID: <3Twy5bKqGLnCGzPgNHEGq5L9i1Qh1LM7WU-erWO-VDU=.935320d9-3b28-45d9-9135-b79de40f027d@github.com> On Wed, 7 Jan 2026 09:37:50 GMT, Johan Sj?len wrote: > This PR adds Arena and ResourceArea allocators to the RBTree. The test checks that we can make RBTrees from these allocators and that a basic upsert works. Looks good! Thank's for adding these. Only got one small nit. src/hotspot/share/utilities/rbTree.hpp line 35: > 33: #include "nmt/memTag.hpp" > 34: #include "runtime/os.hpp" > 35: #include "runtime/thread.hpp" Do we need to include `allocation.hpp` and `thread.hpp`? I can't find what's using these and it builds fine for me with those includes removed. ------------- PR Review: https://git.openjdk.org/jdk/pull/29082#pullrequestreview-3643625475 PR Review Comment: https://git.openjdk.org/jdk/pull/29082#discussion_r2675924268 From tschatzl at openjdk.org Mon Jan 12 15:17:10 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 12 Jan 2026 15:17:10 GMT Subject: RFR: 8375040: Clearer names for non-metadata oop iterators in ObjArrayKlass In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 14:15:57 GMT, Stefan Karlsson wrote: > During the review of [JDK-8374780](https://bugs.openjdk.org/browse/JDK-8374780) it was clear that the naming of the various oop iterators, and also their comments, were somewhat misleading about if they visited the metadata or not. > > I propose that we make a clear separation and have it so that all iterators that only visit the array elements are named to contain the word "elements" to make it slightly clearer that these iterators only visits the elements. > > So, we know how the following ObjArrayKlass oop iterators: > > Iterators that also visit the metadata: > > oop_oop_iterate > oop_oop_iterate_reverse > oop_oop_iterate_bounded > > > Iterators that are not visiting the metadata: > > oop_oop_iterate_elements > oop_oop_iterate_elements_range > oop_oop_iterate_elements_bounded > > > The objArrayOopDesc class also exposes an oop iterator and that function has been renamed to mimic the above scheme to add the `_elements` to functions that does not visit the metadata: > > oop_iterate_elements_range > > > Two extra things to check in the patch: > > 1) I did some slight tweaks to the code so that `oop_oop_iterate_elements` is implemented with `oop_oop_iterate_elements_range`. > > 2) I moved the objArrayOopDesc function back to the oopArrayOop.inline.hpp. The reason is that we have now solved the problems with circular dependencies between .inline.hpp files, so this workaround isn't needed anymore. Marked as reviewed by tschatzl (Reviewer). src/hotspot/share/oops/objArrayOop.hpp line 86: > 84: > 85: public: > 86: // Special iterators for an element index range Suggestion: // Special iterators for an element index range. ------------- PR Review: https://git.openjdk.org/jdk/pull/29170#pullrequestreview-3651284570 PR Review Comment: https://git.openjdk.org/jdk/pull/29170#discussion_r2682709497 From stefank at openjdk.org Mon Jan 12 15:38:08 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 12 Jan 2026 15:38:08 GMT Subject: RFR: 8375040: Clearer names for non-metadata oop iterators in ObjArrayKlass [v2] In-Reply-To: References: Message-ID: > During the review of [JDK-8374780](https://bugs.openjdk.org/browse/JDK-8374780) it was clear that the naming of the various oop iterators, and also their comments, were somewhat misleading about if they visited the metadata or not. > > I propose that we make a clear separation and have it so that all iterators that only visit the array elements are named to contain the word "elements" to make it slightly clearer that these iterators only visits the elements. > > So, we know how the following ObjArrayKlass oop iterators: > > Iterators that also visit the metadata: > > oop_oop_iterate > oop_oop_iterate_reverse > oop_oop_iterate_bounded > > > Iterators that are not visiting the metadata: > > oop_oop_iterate_elements > oop_oop_iterate_elements_range > oop_oop_iterate_elements_bounded > > > The objArrayOopDesc class also exposes an oop iterator and that function has been renamed to mimic the above scheme to add the `_elements` to functions that does not visit the metadata: > > oop_iterate_elements_range > > > Two extra things to check in the patch: > > 1) I did some slight tweaks to the code so that `oop_oop_iterate_elements` is implemented with `oop_oop_iterate_elements_range`. > > 2) I moved the objArrayOopDesc function back to the oopArrayOop.inline.hpp. The reason is that we have now solved the problems with circular dependencies between .inline.hpp files, so this workaround isn't needed anymore. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/share/oops/objArrayOop.hpp Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29170/files - new: https://git.openjdk.org/jdk/pull/29170/files/1c9a8869..ad81a47e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29170&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29170&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29170.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29170/head:pull/29170 PR: https://git.openjdk.org/jdk/pull/29170 From vpaprotski at openjdk.org Mon Jan 12 15:39:11 2026 From: vpaprotski at openjdk.org (Volodymyr Paprotski) Date: Mon, 12 Jan 2026 15:39:11 GMT Subject: RFR: 8374570: Assertion failure in ClearArray.java with -XX:+EnableX86EcoreOpts [v6] In-Reply-To: References: Message-ID: > Allow for a larger jump distance Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision: copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29070/files - new: https://git.openjdk.org/jdk/pull/29070/files/4b526d8e..154b05b4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29070&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29070&range=04-05 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 shade at openjdk.org Mon Jan 12 15:43:15 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 12 Jan 2026 15:43:15 GMT Subject: RFR: 8375046: C2: Assertion failed in GrowableArray::remove_till(0) In-Reply-To: <_tSvASngm2bL0X2wavXI63kJZoypsY5S-dus_KGhs18=.ace489be-48bf-4254-a88e-b4fe456edf02@github.com> References: <_tSvASngm2bL0X2wavXI63kJZoypsY5S-dus_KGhs18=.ace489be-48bf-4254-a88e-b4fe456edf02@github.com> Message-ID: On Mon, 12 Jan 2026 15:33:28 GMT, Aleksey Shipilev wrote: > Seen this assert in stress CTW runs: > > > # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/utilities/growableArray.hpp:498), pid=2972347, tid=2973775 > # assert(start < end && end <= this->_len) failed: erase called with invalid range (0, 0) for length 0 > > Stack: [0x00007fd660bea000,0x00007fd660cea000], sp=0x00007fd660ce4fc0, free space=1003k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0xc00a41] Compile::inline_incrementally_one()+0x801 (growableArray.hpp:498) > V [libjvm.so+0xc01650] Compile::inline_incrementally(PhaseIterGVN&)+0x2f0 (compile.cpp:2212) > V [libjvm.so+0xc04581] Compile::Optimize()+0x7d1 (compile.cpp:2357) > > > It looks innocuous, as `GrowableArray::remove_range` does nothing real on `[0, 0)`. It is still IMO a bug to call it with `[0, 0)`, as it is not clear whether to trust inclusive or exclusive boundary. But for `remove_till`, it looks plausible that `remove_till(0)` should work and be a no-op. > > Additional testing: > - [x] Linux x86_64 server fastdebug, new gtest used to fail without the fix, now passes Oh, `GrowableArray::remove_till` is also used in G1, dang. For clarity, I think we can just use `remove_range` then and only handle this on C2 side. Let me do that... ------------- PR Comment: https://git.openjdk.org/jdk/pull/29171#issuecomment-3739197443 From shade at openjdk.org Mon Jan 12 15:43:14 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 12 Jan 2026 15:43:14 GMT Subject: RFR: 8375046: C2: Assertion failed in GrowableArray::remove_till(0) Message-ID: <_tSvASngm2bL0X2wavXI63kJZoypsY5S-dus_KGhs18=.ace489be-48bf-4254-a88e-b4fe456edf02@github.com> Seen this assert in stress CTW runs: # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/utilities/growableArray.hpp:498), pid=2972347, tid=2973775 # assert(start < end && end <= this->_len) failed: erase called with invalid range (0, 0) for length 0 Stack: [0x00007fd660bea000,0x00007fd660cea000], sp=0x00007fd660ce4fc0, free space=1003k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xc00a41] Compile::inline_incrementally_one()+0x801 (growableArray.hpp:498) V [libjvm.so+0xc01650] Compile::inline_incrementally(PhaseIterGVN&)+0x2f0 (compile.cpp:2212) V [libjvm.so+0xc04581] Compile::Optimize()+0x7d1 (compile.cpp:2357) It looks innocuous, as `GrowableArray::remove_range` does nothing real on `[0, 0)`. It is still IMO a bug to call it with `[0, 0)`, as it is not clear whether to trust inclusive or exclusive boundary. But for `remove_till`, it looks plausible that `remove_till(0)` should work and be a no-op. Additional testing: - [x] Linux x86_64 server fastdebug, new gtest used to fail without the fix, now passes ------------- Commit messages: - No trailing comma - Fix Changes: https://git.openjdk.org/jdk/pull/29171/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29171&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375046 Stats: 84 lines in 2 files changed: 82 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29171/head:pull/29171 PR: https://git.openjdk.org/jdk/pull/29171 From shade at openjdk.org Mon Jan 12 15:48:45 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 12 Jan 2026 15:48:45 GMT Subject: RFR: 8375046: C2: Assertion failed in GrowableArray::remove_till(0) [v2] In-Reply-To: <_tSvASngm2bL0X2wavXI63kJZoypsY5S-dus_KGhs18=.ace489be-48bf-4254-a88e-b4fe456edf02@github.com> References: <_tSvASngm2bL0X2wavXI63kJZoypsY5S-dus_KGhs18=.ace489be-48bf-4254-a88e-b4fe456edf02@github.com> Message-ID: > Seen this assert in stress CTW runs: > > > # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/utilities/growableArray.hpp:498), pid=2972347, tid=2973775 > # assert(start < end && end <= this->_len) failed: erase called with invalid range (0, 0) for length 0 > > Stack: [0x00007fd660bea000,0x00007fd660cea000], sp=0x00007fd660ce4fc0, free space=1003k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0xc00a41] Compile::inline_incrementally_one()+0x801 (growableArray.hpp:498) > V [libjvm.so+0xc01650] Compile::inline_incrementally(PhaseIterGVN&)+0x2f0 (compile.cpp:2212) > V [libjvm.so+0xc04581] Compile::Optimize()+0x7d1 (compile.cpp:2357) > > > It looks innocuous, as `GrowableArray::remove_range` does nothing real on `[0, 0)`. It is still IMO a bug to call it with `[0, 0)`, as it is not clear whether to trust inclusive or exclusive boundary. But for `remove_till`, it looks plausible that `remove_till(0)` should work and be a no-op. > > Additional testing: > - [x] Linux x86_64 server fastdebug, additional new gtest to verify `remove_range` works > - [ ] Linux x86_64 server fastdebug, `all` Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Handle the C2 side by removing/inlining remove_till ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29171/files - new: https://git.openjdk.org/jdk/pull/29171/files/b6189484..b32262de Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29171&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29171&range=00-01 Stats: 44 lines in 4 files changed: 2 ins; 28 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/29171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29171/head:pull/29171 PR: https://git.openjdk.org/jdk/pull/29171 From shade at openjdk.org Mon Jan 12 15:55:47 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 12 Jan 2026 15:55:47 GMT Subject: RFR: 8375046: C2: Assertion failed in GrowableArray::remove_till(0) [v3] In-Reply-To: <_tSvASngm2bL0X2wavXI63kJZoypsY5S-dus_KGhs18=.ace489be-48bf-4254-a88e-b4fe456edf02@github.com> References: <_tSvASngm2bL0X2wavXI63kJZoypsY5S-dus_KGhs18=.ace489be-48bf-4254-a88e-b4fe456edf02@github.com> Message-ID: > Seen this assert in stress CTW runs: > > > # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/utilities/growableArray.hpp:498), pid=2972347, tid=2973775 > # assert(start < end && end <= this->_len) failed: erase called with invalid range (0, 0) for length 0 > > Stack: [0x00007fd660bea000,0x00007fd660cea000], sp=0x00007fd660ce4fc0, free space=1003k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0xc00a41] Compile::inline_incrementally_one()+0x801 (growableArray.hpp:498) > V [libjvm.so+0xc01650] Compile::inline_incrementally(PhaseIterGVN&)+0x2f0 (compile.cpp:2212) > V [libjvm.so+0xc04581] Compile::Optimize()+0x7d1 (compile.cpp:2357) > > > It looks innocuous, as `GrowableArray::remove_range` does nothing real on `[0, 0)`. It is still IMO a bug to call it with `[0, 0)`, as it is not clear whether to trust inclusive or exclusive boundary. But for `remove_till`, it looks plausible that `remove_till(0)` should work and be a no-op. Looks like it readily happens in C2 CTW when `_late_inlines` is empty. > > Additional testing: > - [x] Linux x86_64 server fastdebug, additional new gtest to verify `remove_range` works > - [ ] Linux x86_64 server fastdebug, `all` Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Only clear pos when needed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29171/files - new: https://git.openjdk.org/jdk/pull/29171/files/b32262de..3f687702 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29171&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29171&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29171/head:pull/29171 PR: https://git.openjdk.org/jdk/pull/29171 From eastigeevich at openjdk.org Mon Jan 12 16:50:30 2026 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Mon, 12 Jan 2026 16:50:30 GMT Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact on GCs and JIT performance [v22] In-Reply-To: References: Message-ID: <0es2jUteLFJzSAHjGwnkoW4SDTZ7-7yQXsyloBNMs6E=.3bd217be-e5c3-4d1a-88c0-08e43acdc92b@github.com> > Arm Neoverse N1 erratum 1542419: "The core might fetch a stale instruction from memory which violates the ordering of instruction fetches". It is fixed in Neoverse N1 r4p1. > > Neoverse-N1 implementations mitigate erratum 1542419 with a workaround: > - Disable coherent icache. > - Trap IC IVAU instructions. > - Execute: > - `tlbi vae3is, xzr` > - `dsb sy` > > `tlbi vae3is, xzr` invalidates translations for all address spaces (global for address). It waits for all memory accesses using in-scope old translation information to complete before it is considered complete. > > As this workaround has significant overhead, Arm Neoverse N1 (MP050) Software Developer Errata Notice version 29.0 suggests: > > "Since one TLB inner-shareable invalidation is enough to avoid this erratum, the number of injected TLB invalidations should be minimized in the trap handler to mitigate the performance impact due to this workaround." > > This PR introduces a mechanism to defer instruction cache (ICache) invalidation for AArch64 to address the Arm Neoverse N1 erratum 1542419, which causes significant performance overhead if ICache invalidation is performed too frequently. The implementation includes detection of affected Neoverse N1 CPUs and automatic enabling of the workaround for relevant Neoverse N1 revisions. > > Changes include: > > * Added a new diagnostic AArch64 JVM flag `NeoverseN1Errata1542419` to enable or disable the workaround for the erratum. The flag is automatically enabled for Neoverse N1 CPUs prior to r4p1, as detected during VM initialization. > * Added a new diagnostic JVM flag `UseDeferredICacheInvalidation` to enable or disable defered icache invalidation. The flag is automatically enabled for AArch64 if CPU supports hardware cache coherence. > * Introduced the `ICacheInvalidationContext` class to manage deferred ICache invalidation, with platform-specific logic for AArch64. This context is used to batch ICache invalidations, reducing performance impact. > * Provided a default (no-op) implementation for `DefaultICacheInvalidationContext` on platforms where the workaround is not needed, ensuring portability and minimal impact on other architectures. > > Testing results: linux fastdebug build > - Neoverse-N1 (Graviton 2) > - [x] tier1: passed > - [x] tier2: passed > - [x] tier3: passed > - [x] tier4: 3 failures > - `containers/docker/TestJcmdWithSideCar.java`: JDK-8341518 > - `com/sun/nio/sctp/SctpChannel/CloseDescriptors.java`: JDK-8298466 > - `java/awt/print/PrinterJob/Prin... Evgeny Astigeevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits: - Remove redundant code - Merge branch 'master' into JDK-8370947 - Fix linux-cross-compile riscv64 build - Restore deleted comment - Remove redundant blank line - Remove redundant include - Merge branch 'master' into JDK-8370947 - Fix SpecJVM2008 regressions - Merge branch 'master' into JDK-8370947 - Fix macos and windows aarch64 builds - ... and 23 more: https://git.openjdk.org/jdk/compare/fb13abef...7153eb5c ------------- Changes: https://git.openjdk.org/jdk/pull/28328/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28328&range=21 Stats: 819 lines in 32 files changed: 755 ins; 22 del; 42 mod Patch: https://git.openjdk.org/jdk/pull/28328.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28328/head:pull/28328 PR: https://git.openjdk.org/jdk/pull/28328 From duke at openjdk.org Mon Jan 12 18:41:07 2026 From: duke at openjdk.org (Larry Cable) Date: Mon, 12 Jan 2026 18:41:07 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v4] In-Reply-To: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: > 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: added test for VM.classes -location as per lmesnik ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29048/files - new: https://git.openjdk.org/jdk/pull/29048/files/b4a97882..c4d914ea Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=02-03 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 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 Mon Jan 12 19:04:02 2026 From: duke at openjdk.org (Roger Calnan) Date: Mon, 12 Jan 2026 19:04:02 GMT Subject: RFR: 8373836: add anchors to the java options in the java man page Message-ID: adjust each of the command line options to include an html anchor so that one can give a link that goes directly to the section in the man page that covers a specific option ------------- Commit messages: - replace arg:-something with arg__something - updated copyright year - back out changes to keytool.md - Initial links added Changes: https://git.openjdk.org/jdk/pull/28954/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28954&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373836 Stats: 247 lines in 1 file changed: 0 ins; 0 del; 247 mod Patch: https://git.openjdk.org/jdk/pull/28954.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28954/head:pull/28954 PR: https://git.openjdk.org/jdk/pull/28954 From jwilhelm at openjdk.org Mon Jan 12 19:04:03 2026 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Mon, 12 Jan 2026 19:04:03 GMT Subject: RFR: 8373836: add anchors to the java options in the java man page In-Reply-To: References: Message-ID: On Mon, 22 Dec 2025 13:31:54 GMT, Roger Calnan wrote: > adjust each of the command line options to include an html anchor so that one can give a link that goes directly to the section in the man page that covers a specific option Looks good! ------------- Marked as reviewed by jwilhelm (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28954#pullrequestreview-3641639372 From iris at openjdk.org Mon Jan 12 19:17:32 2026 From: iris at openjdk.org (Iris Clark) Date: Mon, 12 Jan 2026 19:17:32 GMT Subject: RFR: 8373836: add anchors to the java options in the java man page In-Reply-To: References: Message-ID: On Mon, 22 Dec 2025 13:31:54 GMT, Roger Calnan wrote: > adjust each of the command line options to include an html anchor so that one can give a link that goes directly to the section in the man page that covers a specific option Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28954#pullrequestreview-3652316335 From wkemper at openjdk.org Mon Jan 12 19:41:47 2026 From: wkemper at openjdk.org (William Kemper) Date: Mon, 12 Jan 2026 19:41:47 GMT Subject: RFR: 8373203: Genshen: Non-strong reference leak in old gen [v8] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 17:52:35 GMT, William Kemper 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 23 commits: > > - Merge remote-tracking branch 'jdk/master' into fix-old-reference-processing > - 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 > - Sort includes > - Heal old discovered lists in parallel > - Fix comment > - Factor duplicate code into shared method > - ... and 13 more: https://git.openjdk.org/jdk/compare/f5fa9e40...abccb8b6 Consider a situation where an old and young reference both point to an old referent: young_reference old_reference \ / \ / old_referent Genshen "bootstraps" old marking with a young collection. During young generation marking, oop iteration will "encounter" `young_reference`, and ask our reference processor to "discover" it. If the reference processor _discovers_ `old_referent`, then the reference processor is responsible for it and the mark thread will _not_ mark through the referent. Conversely, if the reference processor does _not_ discover the referent, then oop iteration will mark the referent and trace through it. This behavior is baked pretty deep into oop iteration and any changes in this code would affect all collectors. The young reference processor cannot _discover_ old referents because it will not have complete mark information when it comes time to process the discovered list. By not discovering the old referent, the mark thread will mark and trace through the old referent. Following the bootstrap, when old marking encounters `old_reference`, it sees that `old_referent` is already strongly marked and so similarly does not _discover_ it. We could continue to wait for `young_reference` to die or be promoted, but you can see that a single `young_reference` to any `old_referent` can prevent the reference from being cleared. This PR has the young reference processor defer discovery to the old reference processor. This is simple enough, except that the young references now live in the old reference processor's discovered list. This list runs through the heap so these young references can be evacuated. This requires us to update references for the old processor's discovered list. Note that the list already updates the card table when young references are placed on the discovered list, so they become roots for subsequent young collections by virtue of being in the remembered set. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28810#issuecomment-3740189396 From kevinw at openjdk.org Mon Jan 12 20:15:00 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 12 Jan 2026 20:15:00 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v4] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Mon, 12 Jan 2026 18:41:07 GMT, Larry Cable 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: added test for VM.classes -location as per lmesnik src/hotspot/share/oops/instanceKlass.cpp line 2401: > 2399: oop cs = pd->obj_field(csfd.offset()); > 2400: > 2401: assert(cs !=nullptr && !cs->klass()->is_instance_klass(), "cs klass is not InstanceKlass"); Should we be asserting it is an instanceklass? (also int: cs != space nullptr while we are here) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2683759759 From ysr at openjdk.org Mon Jan 12 21:41:27 2026 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Mon, 12 Jan 2026 21:41:27 GMT Subject: RFR: 8373203: Genshen: Non-strong reference leak in old gen [v8] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 17:52:35 GMT, William Kemper 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 23 commits: > > - Merge remote-tracking branch 'jdk/master' into fix-old-reference-processing > - 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 > - Sort includes > - Heal old discovered lists in parallel > - Fix comment > - Factor duplicate code into shared method > - ... and 13 more: https://git.openjdk.org/jdk/compare/f5fa9e40...abccb8b6 Thank you for explaining clearly here. I have some related questions below: > Consider a situation where an old and young reference both point to an old referent: > > ``` > young_reference old_reference > \ / > \ / > old_referent > ``` ... > > The young reference processor cannot _discover_ old referents because it will not have complete mark information when it comes time to process the discovered list. Correct. > By not discovering the old referent, the mark thread will mark and trace through the old referent. Why? It should find the old referent to be in the old generation and leave it alone? Are you specifically talking about the case of bootstrap young that is seeding work for the old collection? In that case, it should mark old referent and leave it alone, but go no further. The old marking will find the referent marked and not clear it. > Following the bootstrap, when old marking encounters `old_reference`, it sees that `old_referent` is already strongly marked and so similarly does not _discover_ it. I would think that this is indeed the correct behaviour. > We could continue to wait for `young_reference` to die or be promoted, but you can see that a single `young_reference` to any `old_referent` can prevent the reference from being cleared. Yes, and that should be ok. Once reference and referent are both in old, it'll be cleared. I realize this is a consequence of the split local marking that each generation does. You are concerned that this will keep the referent perpetually around because of such "hand-over-hand" reference to it from each generation. One question is whether this ends up violating anything in the spec of java.lang.Reference. If so, which spec? Or is it a quality of implementation issue? Is there an example of that from an application/service where we see this? > > This PR has the young reference processor defer discovery to the old reference processor. This is simple enough, except that the young references now live in the old reference processor's discovered list. This list runs through the heap so these young references can be evacuated. This requires us to update references for the old processor's discovered list. Note that the list already updates the card table when young references are placed on the discovered list, so they become roots for subsequent young collections by virtue of being in the remembered set. I am concerned about creating this extra coordination complexity unless there is a good practical reason to fix it in this manner. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28810#issuecomment-3740590447 From vpaprotski at openjdk.org Mon Jan 12 22:34:27 2026 From: vpaprotski at openjdk.org (Volodymyr Paprotski) Date: Mon, 12 Jan 2026 22:34:27 GMT Subject: RFR: 8374570: Assertion failure in ClearArray.java with -XX:+EnableX86EcoreOpts [v6] In-Reply-To: References: Message-ID: <4tRQ01oSl9804alYdb9M6dZkQfTelNzCNvrryOqL8PA=.6b24b94a-a4f7-4c9b-ac97-6fb86e0535e0@github.com> On Mon, 12 Jan 2026 15:39:11 GMT, Volodymyr Paprotski wrote: >> Allow for a larger jump distance > > Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision: > > copyright Looks like the build was successful, if I could get an approval again, will integrate ------------- PR Comment: https://git.openjdk.org/jdk/pull/29070#issuecomment-3740815788 From jwilhelm at openjdk.org Mon Jan 12 22:50:01 2026 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Mon, 12 Jan 2026 22:50:01 GMT Subject: RFR: 8373836: add anchors to the java options in the java man page In-Reply-To: References: Message-ID: On Mon, 22 Dec 2025 13:31:54 GMT, Roger Calnan wrote: > adjust each of the command line options to include an html anchor so that one can give a link that goes directly to the section in the man page that covers a specific option Marked as reviewed by jwilhelm (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28954#pullrequestreview-3653025338 From ysr at openjdk.org Mon Jan 12 23:06:23 2026 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Mon, 12 Jan 2026 23:06:23 GMT Subject: RFR: 8373203: Genshen: Non-strong reference leak in old gen [v8] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 21:37:32 GMT, Y. Srinivas Ramakrishna wrote: > ... unless there is a good practical reason to fix it in this manner. Got more info from William offline; I am going to take a closer look at the changes in light of that, the explanation he provided above, and the example provided by the submitter. Thanks William! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28810#issuecomment-3740900759 From ysuenaga at openjdk.org Mon Jan 12 23:44:59 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Mon, 12 Jan 2026 23:44:59 GMT Subject: RFR: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is incorrectly implemented In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 14:14:19 GMT, Markus Gr?nlund 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 Thanks a lot for working on this! ------------- Marked as reviewed by ysuenaga (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29094#pullrequestreview-3653157591 From wkemper at openjdk.org Tue Jan 13 01:11:55 2026 From: wkemper at openjdk.org (William Kemper) Date: Tue, 13 Jan 2026 01:11:55 GMT Subject: RFR: 8373203: Genshen: Non-strong reference leak in old gen [v9] In-Reply-To: References: Message-ID: > 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 24 commits: - Merge remote-tracking branch 'jdk/master' into fix-old-reference-processing - Merge remote-tracking branch 'jdk/master' into fix-old-reference-processing - 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 - Sort includes - Heal old discovered lists in parallel - Fix comment - ... and 14 more: https://git.openjdk.org/jdk/compare/15b7a425...88101211 ------------- Changes: https://git.openjdk.org/jdk/pull/28810/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28810&range=08 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 kbarrett at openjdk.org Tue Jan 13 01:36:04 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 13 Jan 2026 01:36:04 GMT Subject: RFR: 8372248: GTest istream.coverage depends on istream.basic [v3] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 13:12:42 GMT, Axel Boldt-Christmas wrote: >> These two GTests have a strong dependency that `istream.coverage` is ran after `istream.basic`. This goes against the intended design of GTests. (They should be independent). >> >> As such I propose we merge this into one test. >> >> I kept the two `VERBOSE` variables separate. However I am not sure I understand their purpose. >> Currently changing `VERBOSE_TEST` to `true` will cause the test to fail, (not all cases are covered). And the value have of `VERBOSE_COVERAGE` has no effect. What is observed: >> * `(VERBOSE_TEST: false, VERBOSE_COVERAGE: false) -> Success` >> * `(VERBOSE_TEST: false, VERBOSE_COVERAGE: true) -> Success` >> * `(VERBOSE_TEST: true, VERBOSE_COVERAGE: false) -> Failure` >> * `(VERBOSE_TEST: true, VERBOSE_COVERAGE: true) -> Failure` >> >> But I kept the original behaviour, just merged into one test case rather than two. > > Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'JDK-8372241' into JDK-8372248 > - Merge branch 'JDK-8372241' into JDK-8372248 > - gtest istream.coverage depends on istream.basic Why is this PR dependent on https://github.com/openjdk/jdk/pull/28409. If the change to CheckGtestDependencies.java was removed, this PR could go in immediately. (And then update https://github.com/openjdk/jdk/pull/28409 accordingly.) ------------- PR Review: https://git.openjdk.org/jdk/pull/28418#pullrequestreview-3653409958 From kbarrett at openjdk.org Tue Jan 13 01:37:06 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 13 Jan 2026 01:37:06 GMT Subject: RFR: 8372245: GTest globalDefinitions.format_specifiers cannot run without VM [v3] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 13:13:19 GMT, Axel Boldt-Christmas wrote: >> globalDefinitions.format_specifiers uses `ResourceMark` which requires a created VM. >> Either we stop using resource allocations, or we run the test in VM. >> >> I propose we let this test simply use `stringStream::base` rather than `stringStream::as_string` which is an already managed string and the stream is in scope for as long as the string is used. The string is guaranteed to be valid as long as we do not write to the stream. > > Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'JDK-8372241' into JDK-8372245 > - Merge branch 'JDK-8372241' into JDK-8372245 > - gtest globalDefinitions.format_specifiers cannot run without VM Why is this PR dependent on https://github.com/openjdk/jdk/pull/28409. If the change to CheckGtestDependencies.java was removed, this PR could go in immediately. (And then update https://github.com/openjdk/jdk/pull/28409 accordingly.) I would approve this PR now if that dependency was removed. ------------- PR Review: https://git.openjdk.org/jdk/pull/28415#pullrequestreview-3653415156 From kbarrett at openjdk.org Tue Jan 13 01:43:35 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 13 Jan 2026 01:43:35 GMT Subject: RFR: 8375040: Clearer names for non-metadata oop iterators in ObjArrayKlass [v2] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 15:38:08 GMT, Stefan Karlsson wrote: >> During the review of [JDK-8374780](https://bugs.openjdk.org/browse/JDK-8374780) it was clear that the naming of the various oop iterators, and also their comments, were somewhat misleading about if they visited the metadata or not. >> >> I propose that we make a clear separation and have it so that all iterators that only visit the array elements are named to contain the word "elements" to make it slightly clearer that these iterators only visits the elements. >> >> So, we know how the following ObjArrayKlass oop iterators: >> >> Iterators that also visit the metadata: >> >> oop_oop_iterate >> oop_oop_iterate_reverse >> oop_oop_iterate_bounded >> >> >> Iterators that are not visiting the metadata: >> >> oop_oop_iterate_elements >> oop_oop_iterate_elements_range >> oop_oop_iterate_elements_bounded >> >> >> The objArrayOopDesc class also exposes an oop iterator and that function has been renamed to mimic the above scheme to add the `_elements` to functions that does not visit the metadata: >> >> oop_iterate_elements_range >> >> >> Two extra things to check in the patch: >> >> 1) I did some slight tweaks to the code so that `oop_oop_iterate_elements` is implemented with `oop_oop_iterate_elements_range`. >> >> 2) I moved the objArrayOopDesc function back to the oopArrayOop.inline.hpp. The reason is that we have now solved the problems with circular dependencies between .inline.hpp files, so this workaround isn't needed anymore. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/share/oops/objArrayOop.hpp > > Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com> Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29170#pullrequestreview-3653423624 From qamai at openjdk.org Tue Jan 13 03:31:36 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 13 Jan 2026 03:31:36 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v4] In-Reply-To: References: Message-ID: On Mon, 15 Dec 2025 19:49:52 GMT, Chen Liang wrote: >> Folding identity hash as constant if the incoming argument is constant would be useful for quick map lookups, such as for the [Classifier proposal](https://openjdk.org/jeps/8357674). Currently, identity hash is not constant because it loads the object header/mark word. We can add an explicit bypass to load an existing hash eagerly instead. > > Chen Liang 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 12 additional commits since the last revision: > > - Move test, fix merge garbage > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const > - Typo > - assert > - refactorings > - Typo > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const > - Cleanup > - identity hash support in C2 > - ... and 2 more: https://git.openjdk.org/jdk/compare/91227712...67a3954f src/hotspot/share/ci/ciArray.cpp line 93: > 91: // Returns T_ILLEGAL if there is no element at the given index. > 92: ciConstant ciArray::element_value(int index) { > 93: assert(index >= 0, "out-of-bounds index: %d", index); IIUC, this is because you use `-1` as the offset for hashcode, so you need to make sure we are accessing a real element here, or the cache access will return something dubious. I think it is then more uniform to save the value at the cache using the offset instead of the element index. src/hotspot/share/ci/ciObject.cpp line 233: > 231: // Observed value is cached, so it doesn't change during compilation. > 232: ciConstant ciObject::identity_hash() { > 233: if (!is_null_object()) { Just a very small nitpick: Usually it is recommended to do an early return pattern instead. src/hotspot/share/ci/ciObject.hpp line 76: > 74: }; > 75: > 76: const int IDENTITY_HASH_OFFSET = -1; `const` is fine, but `constexpr` is often preferred. Also, is `static` needed here? Another nitpick is that constants are usually not in uppercase in C++, as macros are often in uppercase. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2684670938 PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2684645067 PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2684655292 From qamai at openjdk.org Tue Jan 13 03:31:36 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 13 Jan 2026 03:31:36 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v4] In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 03:16:44 GMT, Quan Anh Mai wrote: >> Chen Liang 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 12 additional commits since the last revision: >> >> - Move test, fix merge garbage >> - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const >> - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const >> - Typo >> - assert >> - refactorings >> - Typo >> - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const >> - Cleanup >> - identity hash support in C2 >> - ... and 2 more: https://git.openjdk.org/jdk/compare/91227712...67a3954f > > src/hotspot/share/ci/ciObject.hpp line 76: > >> 74: }; >> 75: >> 76: const int IDENTITY_HASH_OFFSET = -1; > > `const` is fine, but `constexpr` is often preferred. Also, is `static` needed here? Another nitpick is that constants are usually not in uppercase in C++, as macros are often in uppercase. It is also useful to note what this value is. It is not clear at first glance why offset is -1 here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2684658970 From dzhang at openjdk.org Tue Jan 13 05:01:32 2026 From: dzhang at openjdk.org (Dingli Zhang) Date: Tue, 13 Jan 2026 05:01:32 GMT Subject: RFR: 8375094: RISC-V: Fix client builds after JDK-8368732 Message-ID: Hi, Can you help to review this patch? Thanks! [JDK-8368732](https://bugs.openjdk.org/browse/JDK-8368732) broke RISC-V client builds because `AlignVector` is a C2-only option. This pr is to put `AlignVector` under COMPILER2 macro protection. Builds tested w/ and w/o `--with-jvm-variants=client`. ------------- Commit messages: - 8375094: RISC-V: Fix client builds after JDK-8368732 Changes: https://git.openjdk.org/jdk/pull/29182/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29182&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375094 Stats: 10 lines in 1 file changed: 5 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29182.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29182/head:pull/29182 PR: https://git.openjdk.org/jdk/pull/29182 From dholmes at openjdk.org Tue Jan 13 05:36:40 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 13 Jan 2026 05:36:40 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v2] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Tue, 6 Jan 2026 23:41:52 GMT, David Holmes 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/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; Hotspot-style places the asterisk adjacent to the type not the variable name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2684891342 From dholmes at openjdk.org Tue Jan 13 05:36:41 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 13 Jan 2026 05:36:41 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v2] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Fri, 9 Jan 2026 17:43:14 GMT, Leonid Mesnik wrote: >> good question, but I think defensive coding is warranted, and this is not a performance sensitive code path IMO > > I would prefer to add assertion it such cases. So we can see during testing if assumption is incorrect. It also helps to find changed invariants earlier. > The defensive code path might be fine for product to don't bother users with crashes. My concern with "defensive coding" like this is that it implies we do not know the answer to the question and we should know it. In this case asserting we have an InstanceKlass seems preferabled to me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2684879556 From dholmes at openjdk.org Tue Jan 13 05:36:44 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 13 Jan 2026 05:36:44 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v2] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Fri, 9 Jan 2026 17:26:04 GMT, Larry Cable wrote: >> 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? > > I am simply reusing an existing pattern I found elsewhere in the corpus where code that accessed a field by name with the intent to process as a String tested the type, its my practice to code with safety, while its unlikely that the type of the field will change, I think its safer to test prior to invoking a type specific API. > > If you feel strongly about this, I will remove the klass comparision. :) Again an assertion would be better to catch this unlikely scenario. Though I suspect if the type of the field were to change then the use of the field would already trigger an assertion elsewhere. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2684886074 From dholmes at openjdk.org Tue Jan 13 05:42:19 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 13 Jan 2026 05:42:19 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v2] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: <-dk0O-wXKH9LTKENWaUTda4MJFuZo2bCeM7q4FpBSgQ=.ce715b56-569f-4693-8230-772753b408d1@github.com> On Tue, 13 Jan 2026 05:26:44 GMT, David Holmes wrote: >> I would prefer to add assertion it such cases. So we can see during testing if assumption is incorrect. It also helps to find changed invariants earlier. >> The defensive code path might be fine for product to don't bother users with crashes. > > My concern with "defensive coding" like this is that it implies we do not know the answer to the question and we should know it. In this case asserting we have an InstanceKlass seems preferabled to me. But again the assertion (if present) is in place of the runtime check. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2684904444 From dholmes at openjdk.org Tue Jan 13 05:42:18 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 13 Jan 2026 05:42:18 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v2] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: <6ErYQgKSAP_FuusjmifkjeFlhqLmfnTVXtRCbg18-P4=.31f7be43-053f-42f6-889e-7265d803a435@github.com> On Fri, 9 Jan 2026 17:22:58 GMT, Larry Cable wrote: >> 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?? > > good question, but I think defensive coding is warranted, and this is not a performance sensitive code path IMO, Here the assertion should replace the runtime check. The (non-null) protection-domain object has to be an instance of `ProtectionDomain` which is an `InstanceKlass`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2684901184 From dholmes at openjdk.org Tue Jan 13 05:42:16 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 13 Jan 2026 05:42:16 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v4] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Mon, 12 Jan 2026 18:41:07 GMT, Larry Cable 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: added test for VM.classes -location as per lmesnik src/hotspot/share/oops/instanceKlass.cpp line 2359: > 2357: // initialization state > 2358: > 2359: assert(!k->is_instance_klass(), "not InstanceKlass!"); Why are you asserting this here? This code seems to expect any kind of `Klass`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2684896375 From dholmes at openjdk.org Tue Jan 13 06:16:47 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 13 Jan 2026 06:16:47 GMT Subject: RFR: 8373638: RBTree public interface does not check all input parameters for validity [v2] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 10:18:17 GMT, Casper Norrbin wrote: >> 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 LGTM. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28922#pullrequestreview-3654018181 From aboldtch at openjdk.org Tue Jan 13 07:01:35 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 13 Jan 2026 07:01:35 GMT Subject: RFR: 8372248: GTest istream.coverage depends on istream.basic [v3] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 13:12:42 GMT, Axel Boldt-Christmas wrote: >> These two GTests have a strong dependency that `istream.coverage` is ran after `istream.basic`. This goes against the intended design of GTests. (They should be independent). >> >> As such I propose we merge this into one test. >> >> I kept the two `VERBOSE` variables separate. However I am not sure I understand their purpose. >> Currently changing `VERBOSE_TEST` to `true` will cause the test to fail, (not all cases are covered). And the value have of `VERBOSE_COVERAGE` has no effect. What is observed: >> * `(VERBOSE_TEST: false, VERBOSE_COVERAGE: false) -> Success` >> * `(VERBOSE_TEST: false, VERBOSE_COVERAGE: true) -> Success` >> * `(VERBOSE_TEST: true, VERBOSE_COVERAGE: false) -> Failure` >> * `(VERBOSE_TEST: true, VERBOSE_COVERAGE: true) -> Failure` >> >> But I kept the original behaviour, just merged into one test case rather than two. > > Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'JDK-8372241' into JDK-8372248 > - Merge branch 'JDK-8372241' into JDK-8372248 > - gtest istream.coverage depends on istream.basic > Why is this PR dependent on #28409. If > the change to CheckGtestDependencies.java was removed, this PR could go in > immediately. (And then update #28409 > accordingly.) Purely to have a regression test with the fix. In hindsight it might not have been worth delaying the fix just to have a regression test. I do not think there is a way to retarget a dependent pull request other than closing and reopening a new one. If #28409 is not making in the near future I will do so. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28418#issuecomment-3742340809 From aboldtch at openjdk.org Tue Jan 13 07:02:41 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 13 Jan 2026 07:02:41 GMT Subject: RFR: 8372245: GTest globalDefinitions.format_specifiers cannot run without VM [v3] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 13:13:19 GMT, Axel Boldt-Christmas wrote: >> globalDefinitions.format_specifiers uses `ResourceMark` which requires a created VM. >> Either we stop using resource allocations, or we run the test in VM. >> >> I propose we let this test simply use `stringStream::base` rather than `stringStream::as_string` which is an already managed string and the stream is in scope for as long as the string is used. The string is guaranteed to be valid as long as we do not write to the stream. > > Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'JDK-8372241' into JDK-8372245 > - Merge branch 'JDK-8372241' into JDK-8372245 > - gtest globalDefinitions.format_specifiers cannot run without VM > Why is this PR dependent on #28409. If the change to CheckGtestDependencies.java was removed, this PR could go in immediately. (And then update #28409 accordingly.) I would approve this PR now if that dependency was removed. See: https://github.com/openjdk/jdk/pull/28418#issuecomment-3742340809 ------------- PR Comment: https://git.openjdk.org/jdk/pull/28415#issuecomment-3742344324 From fyang at openjdk.org Tue Jan 13 07:03:37 2026 From: fyang at openjdk.org (Fei Yang) Date: Tue, 13 Jan 2026 07:03:37 GMT Subject: RFR: 8375094: RISC-V: Fix client builds after JDK-8368732 In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 04:54:39 GMT, Dingli Zhang wrote: > Hi, > Can you help to review this patch? Thanks! > > [JDK-8368732](https://bugs.openjdk.org/browse/JDK-8368732) broke RISC-V client builds because `AlignVector` is a C2-only option. > This pr is to put `AlignVector` under COMPILER2 macro protection. > > Builds tested w/ and w/o `--with-jvm-variants=client`. Thanks for find this! Looks good. ------------- Marked as reviewed by fyang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29182#pullrequestreview-3654157610 From wenanjian at openjdk.org Tue Jan 13 07:05:54 2026 From: wenanjian at openjdk.org (Anjian Wen) Date: Tue, 13 Jan 2026 07:05:54 GMT Subject: RFR: 8375094: RISC-V: Fix client builds after JDK-8368732 In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 04:54:39 GMT, Dingli Zhang wrote: > Hi, > Can you help to review this patch? Thanks! > > [JDK-8368732](https://bugs.openjdk.org/browse/JDK-8368732) broke RISC-V client builds because `AlignVector` is a C2-only option. > This pr is to put `AlignVector` under COMPILER2 macro protection. > > Builds tested w/ and w/o `--with-jvm-variants=client`. Looks good, Thanks! ------------- Marked as reviewed by wenanjian (Committer). PR Review: https://git.openjdk.org/jdk/pull/29182#pullrequestreview-3654169545 From fjiang at openjdk.org Tue Jan 13 07:23:05 2026 From: fjiang at openjdk.org (Feilong Jiang) Date: Tue, 13 Jan 2026 07:23:05 GMT Subject: RFR: 8375094: RISC-V: Fix client builds after JDK-8368732 In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 04:54:39 GMT, Dingli Zhang wrote: > Hi, > Can you help to review this patch? Thanks! > > [JDK-8368732](https://bugs.openjdk.org/browse/JDK-8368732) broke RISC-V client builds because `AlignVector` is a C2-only option. > This pr is to put `AlignVector` under COMPILER2 macro protection. > > Builds tested w/ and w/o `--with-jvm-variants=client`. Thanks! ------------- Marked as reviewed by fjiang (Committer). PR Review: https://git.openjdk.org/jdk/pull/29182#pullrequestreview-3654232765 From aboldtch at openjdk.org Tue Jan 13 08:16:39 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 13 Jan 2026 08:16:39 GMT Subject: RFR: 8375040: Clearer names for non-metadata oop iterators in ObjArrayKlass [v2] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 15:38:08 GMT, Stefan Karlsson wrote: >> During the review of [JDK-8374780](https://bugs.openjdk.org/browse/JDK-8374780) it was clear that the naming of the various oop iterators, and also their comments, were somewhat misleading about if they visited the metadata or not. >> >> I propose that we make a clear separation and have it so that all iterators that only visit the array elements are named to contain the word "elements" to make it slightly clearer that these iterators only visits the elements. >> >> So, we know how the following ObjArrayKlass oop iterators: >> >> Iterators that also visit the metadata: >> >> oop_oop_iterate >> oop_oop_iterate_reverse >> oop_oop_iterate_bounded >> >> >> Iterators that are not visiting the metadata: >> >> oop_oop_iterate_elements >> oop_oop_iterate_elements_range >> oop_oop_iterate_elements_bounded >> >> >> The objArrayOopDesc class also exposes an oop iterator and that function has been renamed to mimic the above scheme to add the `_elements` to functions that does not visit the metadata: >> >> oop_iterate_elements_range >> >> >> Two extra things to check in the patch: >> >> 1) I did some slight tweaks to the code so that `oop_oop_iterate_elements` is implemented with `oop_oop_iterate_elements_range`. >> >> 2) I moved the objArrayOopDesc function back to the oopArrayOop.inline.hpp. The reason is that we have now solved the problems with circular dependencies between .inline.hpp files, so this workaround isn't needed anymore. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/share/oops/objArrayOop.hpp > > Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com> lgtm. ------------- Marked as reviewed by aboldtch (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29170#pullrequestreview-3654436558 From ghan at openjdk.org Tue Jan 13 08:51:18 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Tue, 13 Jan 2026 08:51:18 GMT Subject: RFR: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) Message-ID: Please review this change. Thanks! **Description:** When -XX:+PrintDeoptimizationDetails is enabled, vframeArray.cpp prints interpreted frames under ttyLocker. https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/runtime/vframeArray.cpp#L493-L503 In the WizardMode && Verbose branch it calls Method::print_codes() / print_codes_on(). The bytecode printing path may acquire MDOExtraData_lock (rank nosafepoint-1). https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/interpreter/bytecodeTracer.cpp#L597-L602 Calling it while holding tty_lock violates the global lock ranking order and triggers a lock rank inversion assertion. **Fix:** Generate the bytecode dump before taking tty_lock, and print it afterwards under ttyLocker to keep the output coherent while preserving correct lock acquisition order. To avoid double buffering when the target stream is already a thread-local stringStream, extend BytecodeTracer::print_method_codes with a buffered flag . The new call site uses buffered=false when dumping into the temporary stringStream. **Test:** GHA ------------- Commit messages: - fix a compile error - fix 8374862 Changes: https://git.openjdk.org/jdk/pull/29186/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29186&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374862 Stats: 71 lines in 6 files changed: 54 ins; 2 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/29186.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29186/head:pull/29186 PR: https://git.openjdk.org/jdk/pull/29186 From thartmann at openjdk.org Tue Jan 13 09:05:01 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 13 Jan 2026 09:05:01 GMT Subject: RFR: 8374570: Assertion failure in ClearArray.java with -XX:+EnableX86EcoreOpts [v6] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 15:39:11 GMT, Volodymyr Paprotski wrote: >> Allow for a larger jump distance > > Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision: > > copyright Looks good. Ship it! ------------- Marked as reviewed by thartmann (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29070#pullrequestreview-3654677943 From duke at openjdk.org Tue Jan 13 09:36:46 2026 From: duke at openjdk.org (Harshit470250) Date: Tue, 13 Jan 2026 09:36:46 GMT Subject: RFR: 8347396: Efficient TypeFunc creations [v3] In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 21:28:05 GMT, Dean Long wrote: >> Harshit470250 has updated the pull request incrementally with five additional commits since the last revision: >> >> - add guard to the include >> - add load_reference_barrier_Type >> - add clone_barrier_Type >> - add write_barrier_pre_Type >> - revert shenandoah changes > > Why are you trying to #include a .cpp file? Just let the linker handle it. You didn't need that for shenandoahBarrierSetC2.cpp, so what makes barrierSetC2.cpp special? @dean-long I have moved make_clone_type to barrierSetC2.cpp. Can you take a look? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27279#issuecomment-3743180187 From jbhateja at openjdk.org Tue Jan 13 09:48:46 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 13 Jan 2026 09:48:46 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v10] In-Reply-To: References: Message-ID: > 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. > > image > > 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 26 commits: - Review comments resolutions - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 - Fix incorrect argument passed to smokeTest - 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 - ... and 16 more: https://git.openjdk.org/jdk/compare/7e18de13...14861d5e ------------- Changes: https://git.openjdk.org/jdk/pull/28002/files Webrev: Webrev is not available because diff is too large Stats: 515469 lines in 232 files changed: 284458 ins; 229216 del; 1795 mod Patch: https://git.openjdk.org/jdk/pull/28002.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002 PR: https://git.openjdk.org/jdk/pull/28002 From jbhateja at openjdk.org Tue Jan 13 09:48:50 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 13 Jan 2026 09:48:50 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v9] In-Reply-To: <3PzPbEnPapV-B3OenjmG6paXsyLFayh33S-f0IBI-LY=.773757f6-c9e0-48ac-b89d-aa81fd6b47f8@github.com> References: <3PzPbEnPapV-B3OenjmG6paXsyLFayh33S-f0IBI-LY=.773757f6-c9e0-48ac-b89d-aa81fd6b47f8@github.com> Message-ID: <212JnoGQ5FDIEHJMmZ2zFLxmM4BCjqrnFyuZ6CqeZ-c=.cfa4503a-e6da-401b-95b4-f3c384d12e3f@github.com> On Wed, 7 Jan 2026 19:29:03 GMT, Paul Sandoz 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 > > 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.) Done > 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. Addressed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2685649510 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2685649160 From jbhateja at openjdk.org Tue Jan 13 09:58:29 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 13 Jan 2026 09:58:29 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v11] In-Reply-To: References: Message-ID: > 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. > > image > > 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 incrementally with one additional commit since the last revision: Adding testpoint for JDK-8373574 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28002/files - new: https://git.openjdk.org/jdk/pull/28002/files/14861d5e..d1043144 Webrevs: - full: Webrev is not available because diff is too large - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=09-10 Stats: 113 lines in 1 file changed: 113 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28002.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002 PR: https://git.openjdk.org/jdk/pull/28002 From aph at openjdk.org Tue Jan 13 09:59:16 2026 From: aph at openjdk.org (Andrew Haley) Date: Tue, 13 Jan 2026 09:59:16 GMT Subject: RFR: 8365991: AArch64: Ignore BlockZeroingLowLimit when UseBlockZeroing is false [v10] In-Reply-To: References: Message-ID: On Mon, 15 Dec 2025 10:26:54 GMT, Patrick Zhang wrote: >> Issue: >> In AArch64 port, `UseBlockZeroing` is by default set to true and `BlockZeroingLowLimit` is initialized to 256. If `DC ZVA` is supported, `BlockZeroingLowLimit` is later updated to `4 * VM_Version::zva_length()`. When `UseBlockZeroing` is set to false, all related conditional checks should ignore `BlockZeroingLowLimit`. However, the function `MacroAssembler::zero_words(Register base, uint64_t cnt)` still evaluates the lower limit and bases its code generation logic on it, which seems to be an incomplete conditional check. >> >> This PR: >> 1. Reset `BlockZeroingLowLimit` to `4 * VM_Version::zva_length()` or 256 with a warning message if it was manually configured from the default while `UseBlockZeroing` is disabled. >> 2. Added necessary comments in `MacroAssembler::zero_words(Register base, uint64_t cnt)` and `MacroAssembler::zero_words(Register ptr, Register cnt)` to explain why we do not check `UseBlockZeroing` in the outer part of these functions. Instead, the decision is delegated to the stub function `zero_blocks`, which encapsulates the DC ZVA instructions and serves as the inner implementation of `zero_words`. This approach helps better control the increase in code cache size during array or object instance initialization. >> 3. Added more testing sizes to `test/micro/org/openjdk/bench/vm/gc/RawAllocationRate.java` to better cover scenarios involving smaller arrays and objects.. >> >> Tests: >> 1. Performance tests on the bundled JMH `vm.compiler.ClearMemory`, and `vm.gc.RawAllocationRate` (including `arrayTest` and `instanceTest`) showed no obvious regression. Negative tests with `jdk/bin/java -jar images/test/micro/benchmarks.jar RawAllocationRate.arrayTest_C1 -bm thrpt -gc false -wi 0 -w 30 -i 1 -r 30 -t 1 -f 1 -tu s -jvmArgs "-XX:-UseBlockZeroing -XX:BlockZeroingLowLimit=8" -p size=32` demonstrated good wall times on `zero_words_reg_imm` calls, as expected. >> 2. Jtreg ter1 test on Ampere Altra, AmpereOne, Graviton2 and 3, tier2 on Altra. No new issues found. Passed tests of GHA Sanity Checks. > > Patrick Zhang has updated the pull request incrementally with one additional commit since the last revision: > > Renamed the vars to unroll_words > > Signed-off-by: Patrick Zhang src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 6264: > 6262: // There is no need to check UseBlockZeroing here because that is > 6263: // delegated to the zero_blocks stub. The code here is inlined, so > 6264: // it is important to keep it small. Suggestion: // The code here is inlined, so it is important to keep it small. I find this "There is no need..." comment more confusing than helpful. src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 6277: > 6275: #endif > 6276: // Use 16 words (128 bytes) as the block size to unroll. > 6277: const int unroll_words = 2 * MacroAssembler::zero_words_block_size; const int unroll_words = 2 * MacroAssembler::zero_words_block_size; I do not believe this makes the code easier to understand. It's explicitly two DC ZVA blocks. Maybe `two_blocks` or somesuch would be clearer to the reader. The "replace literal constants with named constants" advice helps when the named constant is informative, which `unroll_words` is not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26917#discussion_r2685676711 PR Review Comment: https://git.openjdk.org/jdk/pull/26917#discussion_r2685668103 From fyang at openjdk.org Tue Jan 13 10:14:33 2026 From: fyang at openjdk.org (Fei Yang) Date: Tue, 13 Jan 2026 10:14:33 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v9] In-Reply-To: References: Message-ID: <8tmcHaaICcnQ5AjwdCe334bxoA3cIJ3IhqWexblRgkM=.6ffed558-f343-4072-a38b-ee7f5d292373@github.com> On Wed, 7 Jan 2026 09:03:03 GMT, Jatin Bhateja wrote: >> test/jdk/jdk/incubator/vector/Float16Vector64Tests.java line 1893: >> >>> 1891: VectorMask 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. Thanks for confirming this. And I see similar occurrences in Float / Double varients of the tests. Maybe we should fix them as well? test/jdk/jdk/incubator/vector/FloatVector256Tests.java test/jdk/jdk/incubator/vector/FloatVector128Tests.java test/jdk/jdk/incubator/vector/FloatVector64Tests.java test/jdk/jdk/incubator/vector/FloatVector512Tests.java test/jdk/jdk/incubator/vector/FloatVectorMaxTests.java test/jdk/jdk/incubator/vector/DoubleVector128Tests.java test/jdk/jdk/incubator/vector/DoubleVector64Tests.java test/jdk/jdk/incubator/vector/DoubleVector256Tests.java test/jdk/jdk/incubator/vector/DoubleVector512Tests.java test/jdk/jdk/incubator/vector/DoubleVectorMaxTests.java ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2685722818 From fyang at openjdk.org Tue Jan 13 10:18:46 2026 From: fyang at openjdk.org (Fei Yang) Date: Tue, 13 Jan 2026 10:18:46 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v9] In-Reply-To: <8tmcHaaICcnQ5AjwdCe334bxoA3cIJ3IhqWexblRgkM=.6ffed558-f343-4072-a38b-ee7f5d292373@github.com> References: <8tmcHaaICcnQ5AjwdCe334bxoA3cIJ3IhqWexblRgkM=.6ffed558-f343-4072-a38b-ee7f5d292373@github.com> Message-ID: On Tue, 13 Jan 2026 10:10:40 GMT, Fei Yang wrote: >> 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. > > Thanks for confirming this. And I see similar occurrences in Float / Double varients of the tests. > Maybe we should fix them as well? > > > test/jdk/jdk/incubator/vector/FloatVector256Tests.java > test/jdk/jdk/incubator/vector/FloatVector128Tests.java > test/jdk/jdk/incubator/vector/FloatVector64Tests.java > test/jdk/jdk/incubator/vector/FloatVector512Tests.java > test/jdk/jdk/incubator/vector/FloatVectorMaxTests.java > > test/jdk/jdk/incubator/vector/DoubleVector128Tests.java > test/jdk/jdk/incubator/vector/DoubleVector64Tests.java > test/jdk/jdk/incubator/vector/DoubleVector256Tests.java > test/jdk/jdk/incubator/vector/DoubleVector512Tests.java > test/jdk/jdk/incubator/vector/DoubleVectorMaxTests.java Ah, that doesn't seem necessary after another look. Float16 is special here. So please ignore my comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2685745615 From fyang at openjdk.org Tue Jan 13 10:27:39 2026 From: fyang at openjdk.org (Fei Yang) Date: Tue, 13 Jan 2026 10:27:39 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v11] In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 09:58:29 GMT, Jatin Bhateja 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. >> >> image >> >> 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 incrementally with one additional commit since the last revision: > > Adding testpoint for JDK-8373574 src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16Vector.java line 1653: > 1651: * > 1652: * @param e the input scalar > 1653: * @return the result of multiplying this vector by the given scalar The code comment mentions "multiplying", which doesn't seem correct to me. Are we doing any multiplication for min/max? src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16Vector.java line 1694: > 1692: * > 1693: * @param e the input scalar > 1694: * @return the result of multiplying this vector by the given scalar Similar question here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2685766276 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2685767490 From duke at openjdk.org Tue Jan 13 11:20:29 2026 From: duke at openjdk.org (Ruben) Date: Tue, 13 Jan 2026 11:20:29 GMT Subject: RFR: 8373697: AArch64: Remove deoptimization stub code for nmethods with small stack frames In-Reply-To: <9Sl4H6Pm4KY36QZZCGcKD1I2f86oAxULIl0lVUuGazY=.955e8db5-3bc3-4f34-a500-d76758abe909@github.com> References: <9Sl4H6Pm4KY36QZZCGcKD1I2f86oAxULIl0lVUuGazY=.955e8db5-3bc3-4f34-a500-d76758abe909@github.com> Message-ID: On Sat, 20 Dec 2025 21:53:48 GMT, Dean Long wrote: >> Removal of deoptimization stub codes improves density of compiled code. >> It is possible at least for methods with relatively small stack frames. > > That's a good idea. But instead of storing the nmethod* into r8, how about storing the original PC? Then we don't need to reserve that stack slot in the frame anymore. However, I'm not sure this trick will work for all compiled frames. Do we always save r8 on compiled --> compiled calls, or only for compiled --> runtime calls? Hi @dean-long, @theRealAph, > Here's another possible idea: if the call return is a PostCallNop, we can change the return address so we return into the middle of the NOP. On RISC that might be enough to cause an unaligned address trap. On x64 or other architectures, we might need an actual embedded trap instruction. I initially chose to not take this path because of latency concerns. For example, in a scenario when a set of hot methods is being executed by many threads/cores and gets deoptimized, a lot of nearly simultaneous traps might occur - potentially resulting in delays due to contention inside the kernel. If we accept a higher cost of deoptimization events, this approach seems to be the simplest option. > Surely we don't need any of this complication. When we patch the CodeBlob frame's return address with the PC of the deopt handler, we could also store nmethod* into the slot for r8 in the same CodeBlob frame. When that CodeBlob returns, the nmethod* is in r8, and the deopt handler can read it there. As far as I understand, there is no dedicated slot for x8 register with fixed offset within the compiled frames There can be a few adjacent compiled frames - all of which can be patched for deoptimization - so we don't necessarily have a non-compiled frame available for storing the nmethod*. The original PC slot currently contains a similar value: the original return address within the nmethod. However, the offset to the original PC slot depends on the nmethod - so we need to identify the nmethod before locating the slot. In my understanding, any spill slot would have an offset depending on the nmethod, because the first N slots in each frame are reserved for arguments. Example compiled stack frame layout: #r020 c_rarg1:c_rarg1 : parm 0: rawptr:BotPTR # -- Old r31_sp -- Framesize: 112 -- #r223 r31_sp+108: in_preserve #r222 r31_sp+104: return address (to the caller) #r221 r31_sp+100: in_preserve #r220 r31_sp+96: saved fp register #r219 r31_sp+92: in_preserve #r218 r31_sp+88: in_preserve #r217 r31_sp+84: Fixed slot 1 #r216 r31_sp+80: Fixed slot 0 (original PC slot) #r243 r31_sp+76: spill #r242 r31_sp+72: spill ? #r225 r31_sp+ 8: spill #r225 r31_sp+ 4: spill #r224 r31_sp+ 0: outgoing argument ---------------------------- r31_sp- 8: return address (to the current method) - the patched item, with the original value stored in the fixed slot above ------------- PR Comment: https://git.openjdk.org/jdk/pull/28857#issuecomment-3743781438 From duke at openjdk.org Tue Jan 13 11:39:13 2026 From: duke at openjdk.org (Ruben) Date: Tue, 13 Jan 2026 11:39:13 GMT Subject: RFR: 8373696: AArch64: Refine post-call NOPs In-Reply-To: <9G7UQDZGLfV0nhrQSv-a9EMvhIAkCdTB3hA9Pf6hRIo=.59b380be-e009-420e-8f76-7771e205467b@github.com> References: <9G7UQDZGLfV0nhrQSv-a9EMvhIAkCdTB3hA9Pf6hRIo=.59b380be-e009-420e-8f76-7771e205467b@github.com> Message-ID: On Thu, 18 Dec 2025 13:52:44 GMT, Andrew Haley wrote: >> Extend MOVK-based scheme to MOVK/MOVZ allowing to store 19 bits of metadata. >> >> Choose number of metadata slots in post-call NOP sequence between 1 and 2 depending on the offset from the CodeBlob header. >> >> Additionally, implement ADR/ADRP-based metadata storage - that provides 22 bits instead of 16 bits to store metadata. This can be enabled via UsePostCallSequenceWithADRP option. >> >> >> Renaissance 0.15.0 benchmark results (MOVK-based scheme) >> Neoverse V1. >> The runs were limited to 16 cores. >> >> Number of runs: >> 6 for baseline, 6 for the changes - interleaved pairs. >> >> Command line: >> java -jar renaissance-jmh-0.15.0.jar \ >> -bm avgt -gc true -v extra \ >> -jvmArgsAppend '-Xbatch -XX:-UseDynamicNumberOfCompilerThreads \ >> -XX:-CICompilerCountPerCPU -XX:ActiveProcessorCount=16 \ >> -XX:CICompilerCount=2 -Xms8g -Xmx8g -XX:+AlwaysPreTouch \ >> -XX:+UseG1GC' >> >> The change is geometric mean of ratios across 6 the pairs of runs. >> >> | Benchmark | Change | 90% CI for the change | >> | ----------------------------------------------------- | -------- | --------------------- | >> | org.renaissance.actors.JmhAkkaUct.run | -0.215% | -2.652% to 1.357% | >> | org.renaissance.actors.JmhReactors.run | -0.166% | -1.974% to 1.775% | >> | org.renaissance.jdk.concurrent.JmhFjKmeans.run | 0.222% | -0.492% to 0.933% | >> | org.renaissance.jdk.concurrent.JmhFutureGenetic.run | -1.880% | -2.438% to -1.343% | >> | org.renaissance.jdk.streams.JmhMnemonics.run | -0.500% | -1.032% to 0.089% | >> | org.renaissance.jdk.streams.JmhParMnemonics.run | -0.740% | -2.092% to 0.639% | >> | org.renaissance.jdk.streams.JmhScrabble.run | -0.031% | -0.353% to 0.310% | >> | org.renaissance.neo4j.JmhNeo4jAnalytics.run | -0.873% | -2.323% to 0.427% | >> | org.renaissance.rx.JmhRxScrabble.run | -0.512% | -1.121% to 0.049% | >> | org.renaissance.scala.dotty.JmhDotty.run | -0.219% | -1.108% to 0.708% | >> | org.renaissance.scala.sat.JmhScalaDoku.run | -2.750% | -6.426% to -0.827% | >> | org.renaissance.scala.stdlib.JmhScalaKmeans.run | 0.046% | -0.383% to 0.408% | >> | org.renaissance.scala.stm.JmhPhilosophers.run | 1.497% | -0.955% to 3.923% | >> | org.renaissance.scala.stm.JmhScalaStmBench7.run ... > > On 18/12/2025 13:28, Ruben wrote: >> The |B.nv| might not be suitable in this case - I believe the branch >> will be "always taken". > > Ah, so it is. That's a shame. > >> However, I had considered using |CBNZ XZR, <#imm>|. So far, I avoided >> implementing it because it is unclear what performance effects this >> might have. > > I've tried it, and it's definitely a lot slower than a NOP or a MOVZ. > It would be nice if we could persuade the architecture people to give as > a NOP with payload, perhaps because "Intel has it." > > But if we choose the split between CB offset and oopmap index wisely, we > can avoid using a second instruction most of the time. Hi @theRealAph, > But if we choose the split between CB offset and oopmap index wisely, we can avoid using a second instruction most of the time. > Something else to bear in mind is that we don't always have to succeed placing a post-call NOP. They are not used as frequently as they were in the past, in particular because we found a way to save and restore virtual thread stacks without usually having to trace them. In practice this means that we only have to copy the stack memory, so we don't need the post-call NOPs so often. I believe we can avoid the second instruction with the following approach: - where possible, fully store cb_offset and oopmap_index and use MOVZ/MOVK - where not possible, use MOVN and store partial cb_offset and oopmap_index. The partial cb_offset and oopmap_index values will make search for the respective metadata faster, compared to searching just based on the PC value. >From an initial experiment, is appears oopmap_index increments about every 8 instructions on average - though this observation might be specific to a certain workload. However, if that's the case, current implementation allows us to encode post-call NOPs metadata for offsets up to 8K. The above approach would be an improvement in this case: the MOVK/MOVZ-based chunks would allow us to encode the metadata for offsets up to 16K, while MOVN-based chunks would improve search for the rest of the cases. What do you think about this option? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28855#issuecomment-3743848408 From eastigeevich at openjdk.org Tue Jan 13 12:36:16 2026 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Tue, 13 Jan 2026 12:36:16 GMT Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact on GCs and JIT performance [v23] In-Reply-To: References: Message-ID: > Arm Neoverse N1 erratum 1542419: "The core might fetch a stale instruction from memory which violates the ordering of instruction fetches". It is fixed in Neoverse N1 r4p1. > > Neoverse-N1 implementations mitigate erratum 1542419 with a workaround: > - Disable coherent icache. > - Trap IC IVAU instructions. > - Execute: > - `tlbi vae3is, xzr` > - `dsb sy` > > `tlbi vae3is, xzr` invalidates translations for all address spaces (global for address). It waits for all memory accesses using in-scope old translation information to complete before it is considered complete. > > As this workaround has significant overhead, Arm Neoverse N1 (MP050) Software Developer Errata Notice version 29.0 suggests: > > "Since one TLB inner-shareable invalidation is enough to avoid this erratum, the number of injected TLB invalidations should be minimized in the trap handler to mitigate the performance impact due to this workaround." > > This PR introduces a mechanism to defer instruction cache (ICache) invalidation for AArch64 to address the Arm Neoverse N1 erratum 1542419, which causes significant performance overhead if ICache invalidation is performed too frequently. The implementation includes detection of affected Neoverse N1 CPUs and automatic enabling of the workaround for relevant Neoverse N1 revisions. > > Changes include: > > * Added a new diagnostic AArch64 JVM flag `NeoverseN1Errata1542419` to enable or disable the workaround for the erratum. The flag is automatically enabled for Neoverse N1 CPUs prior to r4p1, as detected during VM initialization. > * Added a new diagnostic JVM flag `UseDeferredICacheInvalidation` to enable or disable defered icache invalidation. The flag is automatically enabled for AArch64 if CPU supports hardware cache coherence. > * Introduced the `ICacheInvalidationContext` class to manage deferred ICache invalidation, with platform-specific logic for AArch64. This context is used to batch ICache invalidations, reducing performance impact. > * Provided a default (no-op) implementation for `DefaultICacheInvalidationContext` on platforms where the workaround is not needed, ensuring portability and minimal impact on other architectures. > > Testing results: linux fastdebug build > - Neoverse-N1 (Graviton 2) > - [x] tier1: passed > - [x] tier2: passed > - [x] tier3: passed > - [x] tier4: 3 failures > - `containers/docker/TestJcmdWithSideCar.java`: JDK-8341518 > - `com/sun/nio/sctp/SctpChannel/CloseDescriptors.java`: JDK-8298466 > - `java/awt/print/PrinterJob/Prin... Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: Fix macos and windows aarch64 debug builds ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28328/files - new: https://git.openjdk.org/jdk/pull/28328/files/7153eb5c..3abb6de4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28328&range=22 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28328&range=21-22 Stats: 10 lines in 3 files changed: 6 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28328.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28328/head:pull/28328 PR: https://git.openjdk.org/jdk/pull/28328 From cnorrbin at openjdk.org Tue Jan 13 13:01:50 2026 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Tue, 13 Jan 2026 13:01:50 GMT Subject: RFR: 8366457: Add ResourceArea and Arena allocators for the RBTree In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 09:37:50 GMT, Johan Sj?len wrote: > This PR adds Arena and ResourceArea allocators to the RBTree. The test checks that we can make RBTrees from these allocators and that a basic upsert works. LGTM ------------- Marked as reviewed by cnorrbin (Committer). PR Review: https://git.openjdk.org/jdk/pull/29082#pullrequestreview-3655657011 From cnorrbin at openjdk.org Tue Jan 13 13:01:53 2026 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Tue, 13 Jan 2026 13:01:53 GMT Subject: RFR: 8366457: Add ResourceArea and Arena allocators for the RBTree In-Reply-To: References: <3Twy5bKqGLnCGzPgNHEGq5L9i1Qh1LM7WU-erWO-VDU=.935320d9-3b28-45d9-9135-b79de40f027d@github.com> Message-ID: On Mon, 12 Jan 2026 14:34:23 GMT, Johan Sj?len wrote: >> src/hotspot/share/utilities/rbTree.hpp line 35: >> >>> 33: #include "nmt/memTag.hpp" >>> 34: #include "runtime/os.hpp" >>> 35: #include "runtime/thread.hpp" >> >> Do we need to include `allocation.hpp` and `thread.hpp`? I can't find what's using these and it builds fine for me with those includes removed. > > We need `allocation.hpp` as that provides AllocFailStrategy, etc. `thread.hpp` isn't needed, that was unfortunate left overs from my first draft. Ah ok! Interesting that it worked before as `RBTreeCHeap` also uses `AllocFailStrategy`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29082#discussion_r2686309353 From duke at openjdk.org Tue Jan 13 13:27:08 2026 From: duke at openjdk.org (Vishal Chand) Date: Tue, 13 Jan 2026 13:27:08 GMT Subject: RFR: 8372652: Re-enable LocalRandom clinit after monitor pinning improvements In-Reply-To: <0BI-aekYlNzNe8szo_NjO14MRbrV_NjjQN6IYB_AT40=.5c548a70-d6fa-4eb9-b7cc-3c44f84ea833@github.com> References: <0BI-aekYlNzNe8szo_NjO14MRbrV_NjjQN6IYB_AT40=.5c548a70-d6fa-4eb9-b7cc-3c44f84ea833@github.com> Message-ID: On Mon, 1 Dec 2025 22:38:29 GMT, Leonid Mesnik wrote: >>> Unfortunately, there are might be failure of execution `vmTestbase/`with `JTREG_TEST_THREAD_FACTORY=Virtual`. So it enough ensure the your fix doesn't create new failures and timeouts >> >> I am trying to parse this :) So, if `make test TEST=vmTestbase/ JTREG=TEST_THREAD_FACTORY=Virtual` passes, we are good to go, correct? > >> > Unfortunately, there are might be failure of execution `vmTestbase/`with `JTREG_TEST_THREAD_FACTORY=Virtual`. So it enough ensure the your fix doesn't create new failures and timeouts >> >> I am trying to parse this :) So, if `make test TEST=vmTestbase/ JTREG=TEST_THREAD_FACTORY=Virtual` passes, we are good to go, correct? > > Sure. > I meant that we don't run whole vmTestbase with TEST_THREAD_FACTORY=Virtual, so I am unsure if there are some failures exist now. @lmesnik @AlanBateman Can I get feedback on this please? Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28547#issuecomment-3744330617 From duke at openjdk.org Tue Jan 13 14:24:53 2026 From: duke at openjdk.org (Ruben) Date: Tue, 13 Jan 2026 14:24:53 GMT Subject: RFR: 8372942: AArch64: Set JVM flags for Neoverse V3AE core In-Reply-To: References: Message-ID: On Thu, 1 Jan 2026 10:02:02 GMT, Andrew Haley 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. Thank you for review, @theRealAph, > 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. While switch-case might not be easily applicable because we have two variables, both of which have to be compared with the values, perhaps an interface like `bool is_model_any_of(std::initializer_list list)` can simplify the code. Would this approach be suitable? Would you like this to be changed within this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28607#issuecomment-3744603433 From kbarrett at openjdk.org Tue Jan 13 14:25:58 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 13 Jan 2026 14:25:58 GMT Subject: RFR: 8347396: Efficient TypeFunc creations [v4] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 04:46:41 GMT, Harshit470250 wrote: >> 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 src/hotspot/share/opto/type.cpp line 33: > 31: #if INCLUDE_SHENANDOAHGC > 32: #include "gc/shenandoah/c2/shenandoahBarrierSetC2.hpp" > 33: #endif // INCLUDE_SHENANDOAHGC Conditional includes go at the end: https://github.com/openjdk/jdk/blame/49f7265894652ea243f3a531cf3f9d0b06e53565/doc/hotspot-style.md#L159-L161 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27279#discussion_r2686645613 From duke at openjdk.org Tue Jan 13 14:53:17 2026 From: duke at openjdk.org (Ruben) Date: Tue, 13 Jan 2026 14:53:17 GMT Subject: RFR: 8365147: AArch64: Replace DMB + LD + DMB with LDAR for C1 volatile field loads [v4] In-Reply-To: <3a_1QZxP59TuI3FewXHDcR_xWH616tlSpcCf1f4BbP0=.c7570d0a-56a6-424d-a5ea-489318734d99@github.com> References: <3a_1QZxP59TuI3FewXHDcR_xWH616tlSpcCf1f4BbP0=.c7570d0a-56a6-424d-a5ea-489318734d99@github.com> Message-ID: On Wed, 7 Jan 2026 12:00:19 GMT, Andrew Haley wrote: >> 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? Hi @theRealAph, Sorry if I caused any confusion. This PR's branch contains the latest version and I believed it is ready for review: the AlwaysAtomicAccesses check was removed, `mem2reg_volatile` was refactored, `load_generic` was renamed to `load_relaxed`; also `jcstress` test suite had been run. Could you let me know if there are any remaining changes you would like before approval? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26748#issuecomment-3744771565 From vpaprotski at openjdk.org Tue Jan 13 15:18:20 2026 From: vpaprotski at openjdk.org (Volodymyr Paprotski) Date: Tue, 13 Jan 2026 15:18:20 GMT Subject: Integrated: 8374570: Assertion failure in ClearArray.java with -XX:+EnableX86EcoreOpts In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 21:27:21 GMT, Volodymyr Paprotski wrote: > Allow for a larger jump distance This pull request has now been integrated. Changeset: 45990d79 Author: Volodymyr Paprotski URL: https://git.openjdk.org/jdk/commit/45990d796ffafc228c6e843049c80aefedb0f12b Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod 8374570: Assertion failure in ClearArray.java with -XX:+EnableX86EcoreOpts Reviewed-by: thartmann, epeter, qamai ------------- PR: https://git.openjdk.org/jdk/pull/29070 From duke at openjdk.org Tue Jan 13 15:54:23 2026 From: duke at openjdk.org (Ruben) Date: Tue, 13 Jan 2026 15:54:23 GMT Subject: RFR: 8371711: AArch64: SVE intrinsics for Arrays.sort methods (int, float) In-Reply-To: References: <8i4snpt_829luK8hB9U6qgJ833kiNK1hPe7IckfaoJ8=.5cd666c6-b4c9-4ff5-bb39-d1243afd61f0@github.com> Message-ID: On Tue, 9 Dec 2025 00:01:26 GMT, Vladimir Ivanov wrote: >> This patch adds an SVE implementation of primitive array sorting (Arrays.sort()) on AArch64 systems that support SVE. On non-SVE machines, we fall back to the existing Java implementation. >> >> For smaller arrays (length <= 64), we use insertion sort; for larger arrays we use an SVE-vectorized quicksort partitioner followed by an odd-even transposition cleanup pass. >> >> The SVE path is enabled by default for int type. For float type, it is available through the experimental flag : >> >> `-XX:+UnlockExperimentalVMOptions -XX:+UseSVELibSimdSortForFP >> ` >> Without this flag being enabled, the default Java implementation would be executed for floats (the flag is disabled by default). >> >> Float is gated due to observed regressions on some small/medium sizes. On larger arrays, the SVE float path shows upto 1.47x speedup on Neoverse V2 and 2.12x on Neoverse V1. >> >> Following are the performance numbers for **ArraysSort JMH benchmark** - >> >> **Case A:** Ratio between the scores of master branch and `UseSVELibSimdSortForFP` flag disabled (which is the default). >> **Case B:** Ratio between the scores of master branch and `UseSVELibSimdSortForFP` flag enabled (the int numbers will be the same but this now enables SVE vectorized sorting for floats). >> **We would want the ratios to be >= 1 to be at par or better than the default Java implementation (master branch).** >> >> On Neoverse V1: >> >> >> Benchmark (size) Mode Cnt A B >> ArraysSort.floatParallelSort 10 avgt 3 0.98 0.98 >> ArraysSort.floatParallelSort 25 avgt 3 1.01 0.83 >> ArraysSort.floatParallelSort 50 avgt 3 0.99 0.55 >> ArraysSort.floatParallelSort 75 avgt 3 0.99 0.66 >> ArraysSort.floatParallelSort 100 avgt 3 0.98 0.66 >> ArraysSort.floatParallelSort 1000 avgt 3 1.00 0.84 >> ArraysSort.floatParallelSort 10000 avgt 3 1.03 1.52 >> ArraysSort.floatParallelSort 100000 avgt 3 1.03 1.46 >> ArraysSort.floatParallelSort 1000000 avgt 3 0.98 1.81 >> ArraysSort.floatSort 10 avgt 3 1.00 0.98 >> ArraysSort.floatSort 25 avgt 3 1.00 0.81 >> ArraysSort.floatSort 50 avgt 3 0.99 0.56 >> ArraysSort.floatSort 75 avgt 3 0.99 0.65 >> ArraysSort.floatSort 100 avgt 3 0.98 0.70 >> ArraysSort.floatSort ... > > Good work, Bhavana! > > I reminds me of an effort I started a year ago to migrate native libraries to FFM. > `vectormath` got integrated, but `libsimdsort` is still a draft: > https://github.com/iwanowww/jdk/tree/libsimdsort.1 > > Since you do profound refactorings in the libsimdsort library code, I suggest to introduce SVE variant on top of FFM from the beginning. Let me finalize the PR and post it for review. What do you think? Hi @iwanowww, Bhavana will be unavailable for some time, so I am coordinating the next steps and someone from our team will be taking over this PR. Thanks again for offering to finalize the libsimdsort FFM PR and post it for review. Do you have an estimate for when you expect to open it? We would like to plan the next update of the SVE Arrays.sort PR on top of it, so knowing an approximate timeline (and whether there is anything you would suggest we prepare in the meantime) would help. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28675#issuecomment-3745085496 From aph at openjdk.org Tue Jan 13 17:48:49 2026 From: aph at openjdk.org (Andrew Haley) Date: Tue, 13 Jan 2026 17:48:49 GMT Subject: RFR: 8373697: AArch64: Remove deoptimization stub code for nmethods with small stack frames In-Reply-To: References: Message-ID: <8FaLmy9kgJv6oeBoKl7V1NPYMXPx4GDXwEgvioBSK0I=.b4353d6d-4d13-4644-bfe7-4d0b929b2af9@github.com> On Tue, 16 Dec 2025 23:15:12 GMT, Ruben wrote: > Removal of deoptimization stub codes improves density of compiled code. > It is possible at least for methods with relatively small stack frames. Try this: diff --git a/src/hotspot/share/runtime/frame.cpp b/src/hotspot/share/runtime/frame.cpp index 9fdffa053c4..3c816ee8aad 100644 --- a/src/hotspot/share/runtime/frame.cpp +++ b/src/hotspot/share/runtime/frame.cpp @@ -359,6 +359,25 @@ void frame::deoptimize(JavaThread* thread) { NativePostCallNop* inst = nativePostCallNop_at(pc()); + const ImmutableOopMap* blob_map = thread->last_frame().get_oop_map(); + blob_map->print(); + + VMReg r7_VMReg = r7->as_VMReg(); + intptr_t* r8_location = nullptr; + for (OopMapStream oms(blob_map); !oms.is_done(); oms.next()) { + OopMapValue omv = oms.current(); + if (omv.type() == OopMapValue::callee_saved_value) { + VMReg reg = omv.content_reg(); + if (reg == r7_VMReg) { + r8_location = thread->last_frame().sp() + + omv.stack_offset() / VMRegImpl::slots_per_word + + 1; + tty->print_cr("offset = %d\n", omv.stack_offset() * VMRegImpl::stack_slot_size); + break; + } + } + } + *r8_location = 0xcafebeefcafebabe; // Save the original pc before we patch in the new one nm->set_original_pc(this, pc()); patch_pc(thread, deopt); You will find that when you arrive at the deopt handler entry, r8 contains 0xcafebeefcafebabe. You can pass anything you want in the slots for r8 and r9. This is a bit of a kludge in that we don't have an oopmap entry for r8 so I assume it's in the next entry after r7, but all registers are saved on the stack, and they're saved in their natural order. If needs be we can add an oop map entry for r8. That may be a good idea. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28857#issuecomment-3745612971 From mgronlun at openjdk.org Tue Jan 13 18:06:39 2026 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 13 Jan 2026 18:06:39 GMT Subject: RFR: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is incorrectly implemented In-Reply-To: References: <8LD4JmIZnVSwmhLeVZROok-0h-nCD1TxlaSRHe586-E=.99a49bfa-444f-4ddf-b206-0a75fe1dad23@github.com> Message-ID: On Thu, 8 Jan 2026 01:32:44 GMT, Yasumasa Suenaga wrote: >>> 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. Thanks for your review @YaSuenag. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29094#issuecomment-3745680784 From mgronlun at openjdk.org Tue Jan 13 18:08:33 2026 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 13 Jan 2026 18:08:33 GMT Subject: Integrated: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is incorrectly implemented In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 14:14:19 GMT, Markus Gr?nlund 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 This pull request has now been integrated. Changeset: f23752a7 Author: Markus Gr?nlund URL: https://git.openjdk.org/jdk/commit/f23752a75ee3d3af0853eff9c678d2496bb1cf58 Stats: 292 lines in 15 files changed: 219 ins; 18 del; 55 mod 8371014: Dump JFR recording on CrashOnOutOfMemoryError is incorrectly implemented Reviewed-by: ysuenaga ------------- PR: https://git.openjdk.org/jdk/pull/29094 From mgronlun at openjdk.org Tue Jan 13 18:25:08 2026 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 13 Jan 2026 18:25:08 GMT Subject: [jdk26] RFR: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is incorrectly implemented Message-ID: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is incorrectly implemented ------------- Commit messages: - Backport f23752a75ee3d3af0853eff9c678d2496bb1cf58 Changes: https://git.openjdk.org/jdk/pull/29203/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29203&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/29203.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29203/head:pull/29203 PR: https://git.openjdk.org/jdk/pull/29203 From duke at openjdk.org Tue Jan 13 20:44:37 2026 From: duke at openjdk.org (Larry Cable) Date: Tue, 13 Jan 2026 20:44:37 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v5] In-Reply-To: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: > 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: changes as per @dholmes and @kwalls ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29048/files - new: https://git.openjdk.org/jdk/pull/29048/files/c4d914ea..55d270dc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=03-04 Stats: 13 lines in 1 file changed: 0 ins; 2 del; 11 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 13 23:18:44 2026 From: duke at openjdk.org (Roger Calnan) Date: Tue, 13 Jan 2026 23:18:44 GMT Subject: RFR: 8373836: add anchors to the java options in the java man page [v2] In-Reply-To: References: Message-ID: > adjust each of the command line options to include an html anchor so that one can give a link that goes directly to the section in the man page that covers a specific option Roger Calnan has updated the pull request incrementally with one additional commit since the last revision: Update full name ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28954/files - new: https://git.openjdk.org/jdk/pull/28954/files/e259d698..5cfbc2c7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28954&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28954&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28954.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28954/head:pull/28954 PR: https://git.openjdk.org/jdk/pull/28954 From duke at openjdk.org Tue Jan 13 23:18:45 2026 From: duke at openjdk.org (duke) Date: Tue, 13 Jan 2026 23:18:45 GMT Subject: RFR: 8373836: add anchors to the java options in the java man page In-Reply-To: References: Message-ID: On Mon, 22 Dec 2025 13:31:54 GMT, Roger Calnan wrote: > adjust each of the command line options to include an html anchor so that one can give a link that goes directly to the section in the man page that covers a specific option @calnan Your change (at version 5cfbc2c7e15bed6394595ad389452058eeb9e685) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28954#issuecomment-3746975759 From dholmes at openjdk.org Wed Jan 14 00:09:44 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 14 Jan 2026 00:09:44 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v5] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: <360N0pFKAVnWO5eHeAi3XCvBEIesJCTAIWcooPYP_uw=.faa035f6-0380-4707-b21b-86ed97fe6d80@github.com> On Tue, 13 Jan 2026 20:44:37 GMT, Larry Cable 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: changes as per @dholmes and @kwalls src/hotspot/share/oops/instanceKlass.cpp line 2389: > 2387: > 2388: if (pd != nullptr) { > 2389: Suggestion: if (pd != nullptr) { assert(pd->klass()->is_instance_klass(), "pd klass is not InstanceKlass"); Nit: the asserts can be simplified by moving inside the null-checked regions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2688502321 From ghan at openjdk.org Wed Jan 14 00:13:31 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Wed, 14 Jan 2026 00:13:31 GMT Subject: RFR: 8375125: assert(false) failed: "Attempting to acquire lock NativeHeapTrimmer_lock/nosafepoint out of order with lock ConcurrentHashTableResize_lock/nosafepoint-2 -- possible deadlock" when using native heap trimmer Message-ID: <74tKCadP3u64jwjKEvh0bZfCXYWoinhqVP1xJlneUf4=.54771fef-7e33-4781-a650-4f55ceaaf3e2@github.com> Please review this change. Thanks! **Description:** When -XX:TrimNativeHeapInterval=non-zero is enabled, running Test6892265 can trigger a VM abort due to a detected deadlock (or lock-order issue) during SymbolTable cleanup. SymbolTable::clean_dead_entries() calls BulkDeleteTask::prepare(), which may take ConcurrentHashTableResize_lock (nosafepoint-2). https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/classfile/symbolTable.cpp#L765-L769 https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/utilities/concurrentHashTableTasks.inline.hpp#L159-L160 https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/utilities/concurrentHashTable.inline.hpp#L307-L310 It then constructs a NativeHeapTrimmer::SuspendMark, which may take NativeHeapTrimmer_lock (nosafepoint). This can invert the lock order with the trimmer thread. https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/classfile/symbolTable.cpp#L773 https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/runtime/trimNativeHeap.hpp#L56-L59 https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/runtime/trimNativeHeap.cpp#L177-L181 **Fix:** Move NativeHeapTrimmer::SuspendMark to the beginning of SymbolTable::clean_dead_entries() before BulkDeleteTask::prepare() to enforce a consistent lock order **Test:** GHA ------------- Commit messages: - fix 8375125 Changes: https://git.openjdk.org/jdk/pull/29212/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29212&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375125 Stats: 9 lines in 2 files changed: 5 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29212.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29212/head:pull/29212 PR: https://git.openjdk.org/jdk/pull/29212 From dzhang at openjdk.org Wed Jan 14 01:05:54 2026 From: dzhang at openjdk.org (Dingli Zhang) Date: Wed, 14 Jan 2026 01:05:54 GMT Subject: RFR: 8375094: RISC-V: Fix client builds after JDK-8368732 In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 04:54:39 GMT, Dingli Zhang wrote: > Hi, > Can you help to review this patch? Thanks! > > [JDK-8368732](https://bugs.openjdk.org/browse/JDK-8368732) broke RISC-V client builds because `AlignVector` is a C2-only option. > This pr is to put `AlignVector` under COMPILER2 macro protection. > > Builds tested w/ and w/o `--with-jvm-variants=client`. Thanks all for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29182#issuecomment-3747203730 From dzhang at openjdk.org Wed Jan 14 01:05:55 2026 From: dzhang at openjdk.org (Dingli Zhang) Date: Wed, 14 Jan 2026 01:05:55 GMT Subject: Integrated: 8375094: RISC-V: Fix client builds after JDK-8368732 In-Reply-To: References: Message-ID: <3bDx5rDx-vqKIeppVDQv_PJSh24a3c0CANO9j5CHqN8=.77313d2f-6946-4e0f-8844-369fb0e6fe8d@github.com> On Tue, 13 Jan 2026 04:54:39 GMT, Dingli Zhang wrote: > Hi, > Can you help to review this patch? Thanks! > > [JDK-8368732](https://bugs.openjdk.org/browse/JDK-8368732) broke RISC-V client builds because `AlignVector` is a C2-only option. > This pr is to put `AlignVector` under COMPILER2 macro protection. > > Builds tested w/ and w/o `--with-jvm-variants=client`. This pull request has now been integrated. Changeset: de6f35ef Author: Dingli Zhang URL: https://git.openjdk.org/jdk/commit/de6f35eff988e737496d5e99e991868e97d72db4 Stats: 10 lines in 1 file changed: 5 ins; 5 del; 0 mod 8375094: RISC-V: Fix client builds after JDK-8368732 Reviewed-by: fyang, wenanjian, fjiang ------------- PR: https://git.openjdk.org/jdk/pull/29182 From dholmes at openjdk.org Wed Jan 14 01:15:47 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 14 Jan 2026 01:15:47 GMT Subject: RFR: 8375125: assert(false) failed: "Attempting to acquire lock NativeHeapTrimmer_lock/nosafepoint out of order with lock ConcurrentHashTableResize_lock/nosafepoint-2 -- possible deadlock" when using native heap trimmer In-Reply-To: <74tKCadP3u64jwjKEvh0bZfCXYWoinhqVP1xJlneUf4=.54771fef-7e33-4781-a650-4f55ceaaf3e2@github.com> References: <74tKCadP3u64jwjKEvh0bZfCXYWoinhqVP1xJlneUf4=.54771fef-7e33-4781-a650-4f55ceaaf3e2@github.com> Message-ID: <35x9AM0-Feqwu4W7YtvWX2cZnBgysD6kAFQb7BTf7cw=.cd5768d1-86f8-4cfb-8f66-b6bdfce8d0d3@github.com> On Wed, 14 Jan 2026 00:08:47 GMT, Guanqiang Han wrote: > Please review this change. Thanks! > > **Description:** > > When -XX:TrimNativeHeapInterval=non-zero is enabled, running Test6892265 can trigger a VM abort due to a detected deadlock (or lock-order issue) during SymbolTable cleanup. > SymbolTable::clean_dead_entries() calls BulkDeleteTask::prepare(), which may take ConcurrentHashTableResize_lock (nosafepoint-2). > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/classfile/symbolTable.cpp#L765-L769 > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/utilities/concurrentHashTableTasks.inline.hpp#L159-L160 > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/utilities/concurrentHashTable.inline.hpp#L307-L310 > > > It then constructs a NativeHeapTrimmer::SuspendMark, which may take NativeHeapTrimmer_lock (nosafepoint). This can invert the lock order with the trimmer thread. > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/classfile/symbolTable.cpp#L773 > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/runtime/trimNativeHeap.hpp#L56-L59 > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/runtime/trimNativeHeap.cpp#L177-L181 > > **Fix:** > > Move NativeHeapTrimmer::SuspendMark to the beginning of SymbolTable::clean_dead_entries() before BulkDeleteTask::prepare() to enforce a consistent lock order > > **Test:** > > GHA @hgqxjj thanks for taking this on. It appears the same problem exists with the `StringTable`. I think this may need its own regression test though, rather than modifying the test that exposed the issue. Also we may need more testing done with the flag activated. @tstuefe do you do regular general testing with native heap trimming enabled? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29212#issuecomment-3747233707 From dholmes at openjdk.org Wed Jan 14 02:08:59 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 14 Jan 2026 02:08:59 GMT Subject: RFR: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 08:42:07 GMT, Guanqiang Han wrote: > Please review this change. Thanks! > > **Description:** > > When -XX:+PrintDeoptimizationDetails is enabled, vframeArray.cpp prints interpreted frames under ttyLocker. > https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/runtime/vframeArray.cpp#L493-L503 > In the WizardMode && Verbose branch it calls Method::print_codes() / print_codes_on(). The bytecode printing path may acquire MDOExtraData_lock (rank nosafepoint-1). > https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/interpreter/bytecodeTracer.cpp#L597-L602 > Calling it while holding tty_lock violates the global lock ranking order and triggers a lock rank inversion assertion. > > **Fix:** > > Generate the bytecode dump before taking tty_lock, and print it afterwards under ttyLocker to keep the output coherent while preserving correct lock acquisition order. > To avoid double buffering when the target stream is already a thread-local stringStream, extend BytecodeTracer::print_method_codes with a buffered flag . The new call site uses buffered=false when dumping into the temporary stringStream. > > **Test:** > > GHA I think this looks like a good solution. I flagged the compiler folk as I'm unsure about the test location - but I see it is where the only other test that uses `PrintDeoptimizationDetails` exists. One small change requested (while you await the second review). Thanks src/hotspot/share/runtime/vframeArray.cpp line 494: > 492: #ifndef PRODUCT > 493: if (PrintDeoptimizationDetails) { > 494: const bool dump_codes = WizardMode && Verbose; Suggestion: const bool print_codes = WizardMode && Verbose; src/hotspot/share/runtime/vframeArray.cpp line 497: > 495: ResourceMark rm(thread); > 496: stringStream codes_ss; > 497: if (dump_codes) { Suggestion: if (print_codes) { src/hotspot/share/runtime/vframeArray.cpp line 511: > 509: vframe* f = vframe::new_vframe(iframe(), &map, thread); > 510: f->print(); > 511: if (dump_codes) { Suggestion: if (print_codes) { ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29186#pullrequestreview-3658551282 PR Review Comment: https://git.openjdk.org/jdk/pull/29186#discussion_r2688674709 PR Review Comment: https://git.openjdk.org/jdk/pull/29186#discussion_r2688680012 PR Review Comment: https://git.openjdk.org/jdk/pull/29186#discussion_r2688680468 From ghan at openjdk.org Wed Jan 14 02:32:59 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Wed, 14 Jan 2026 02:32:59 GMT Subject: RFR: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) [v2] In-Reply-To: References: Message-ID: > Please review this change. Thanks! > > **Description:** > > When -XX:+PrintDeoptimizationDetails is enabled, vframeArray.cpp prints interpreted frames under ttyLocker. > https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/runtime/vframeArray.cpp#L493-L503 > In the WizardMode && Verbose branch it calls Method::print_codes() / print_codes_on(). The bytecode printing path may acquire MDOExtraData_lock (rank nosafepoint-1). > https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/interpreter/bytecodeTracer.cpp#L597-L602 > Calling it while holding tty_lock violates the global lock ranking order and triggers a lock rank inversion assertion. > > **Fix:** > > Generate the bytecode dump before taking tty_lock, and print it afterwards under ttyLocker to keep the output coherent while preserving correct lock acquisition order. > To avoid double buffering when the target stream is already a thread-local stringStream, extend BytecodeTracer::print_method_codes with a buffered flag . The new call site uses buffered=false when dumping into the temporary stringStream. > > **Test:** > > GHA Guanqiang Han 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 four additional commits since the last revision: - change variable name - Merge remote-tracking branch 'upstream/master' into 8374862 - fix a compile error - fix 8374862 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29186/files - new: https://git.openjdk.org/jdk/pull/29186/files/56f513d3..d584c0e5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29186&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29186&range=00-01 Stats: 2610 lines in 100 files changed: 1488 ins; 667 del; 455 mod Patch: https://git.openjdk.org/jdk/pull/29186.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29186/head:pull/29186 PR: https://git.openjdk.org/jdk/pull/29186 From dlong at openjdk.org Wed Jan 14 02:57:33 2026 From: dlong at openjdk.org (Dean Long) Date: Wed, 14 Jan 2026 02:57:33 GMT Subject: RFR: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) [v2] In-Reply-To: References: Message-ID: <3dWsNCY4TW22aUx9We8p35GiVX7JCgGs0j_Z7PUM1vQ=.043adab6-1667-4599-988a-c6b3ea1a79dc@github.com> On Wed, 14 Jan 2026 02:32:59 GMT, Guanqiang Han wrote: >> Please review this change. Thanks! >> >> **Description:** >> >> When -XX:+PrintDeoptimizationDetails is enabled, vframeArray.cpp prints interpreted frames under ttyLocker. >> https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/runtime/vframeArray.cpp#L493-L503 >> In the WizardMode && Verbose branch it calls Method::print_codes() / print_codes_on(). The bytecode printing path may acquire MDOExtraData_lock (rank nosafepoint-1). >> https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/interpreter/bytecodeTracer.cpp#L597-L602 >> Calling it while holding tty_lock violates the global lock ranking order and triggers a lock rank inversion assertion. >> >> **Fix:** >> >> Generate the bytecode dump before taking tty_lock, and print it afterwards under ttyLocker to keep the output coherent while preserving correct lock acquisition order. >> To avoid double buffering when the target stream is already a thread-local stringStream, extend BytecodeTracer::print_method_codes with a buffered flag . The new call site uses buffered=false when dumping into the temporary stringStream. >> >> **Test:** >> >> GHA > > Guanqiang Han 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 four additional commits since the last revision: > > - change variable name > - Merge remote-tracking branch 'upstream/master' into 8374862 > - fix a compile error > - fix 8374862 I think adding `virtual bool is_buffered() `to outputStream might be a cleaner solution. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29186#issuecomment-3747452892 From vpetko at openjdk.org Wed Jan 14 03:58:25 2026 From: vpetko at openjdk.org (Vladimir Petko) Date: Wed, 14 Jan 2026 03:58:25 GMT Subject: RFR: 8352567: [s390x] ProblemList JFR tests requiring JFR stubs [v2] In-Reply-To: References: Message-ID: > JFR stubs are not [implemented](https://github.com/openjdk/jdk/blame/06ba6cf3a137a6cdf572a876a46d18e51c248451/src/hotspot/cpu/s390/sharedRuntime_s390.cpp#L3412). > Problemlist affected tests until https://bugs.openjdk.org/browse/JDK-8286300 is implemented. > > Testing: > - s390x: > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR SKIP > jtreg:test/hotspot/jtreg/applications/ctw/modules/jdk_jfr.java > 0 0 0 0 0 > jtreg:test/hotspot/jtreg/compiler/intrinsics/TestReturnOopSetForJFRWriteCheckpoint.java > 0 0 0 0 0 > jtreg:test/jdk/jdk/jfr 640 583 0 0 57 > ============================== > TEST SUCCESS > > > > - amd64: > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR SKIP > jtreg:test/hotspot/jtreg/applications/ctw/modules/jdk_jfr.java > 1 1 0 0 0 > jtreg:test/hotspot/jtreg/compiler/intrinsics/TestReturnOopSetForJFRWriteCheckpoint.java > 1 1 0 0 0 > jtreg:test/jdk/jdk/jfr 639 630 0 0 9 > ============================== > TEST SUCCESS Vladimir Petko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8352567: [s390x] disable JFR tests requiring JFR stubs ------------- Changes: https://git.openjdk.org/jdk/pull/28444/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28444&range=01 Stats: 20 lines in 2 files changed: 20 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28444.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28444/head:pull/28444 PR: https://git.openjdk.org/jdk/pull/28444 From dholmes at openjdk.org Wed Jan 14 04:26:52 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 14 Jan 2026 04:26:52 GMT Subject: RFR: 8374926: EnableX86ECoreOpts was not enabled on some hybrid CPU [v3] In-Reply-To: References: Message-ID: On Sun, 11 Jan 2026 07:46:33 GMT, Yasumasa Suenaga wrote: >> `EnableX86ECoreOpts` has been introduced in [JDK-8319429](https://bugs.openjdk.org/browse/JDK-8319429), however model numbers which should be enabled are hard-coded, so the flag would not be enabled by default on some models like Arrow Lake. >> >> I ran a [benchmark](https://github.com/YaSuenag/garakuta/tree/master/randminmax) to check for effectiveness of `-XX:+EnableX86ECoreOpts` with JDK 25.0.1 on Windows 11 25H2, I saw performance improvement a bit on Intel Core 5 Ultra 225U as following: >> >> Disabled (default) >> >> Benchmark Mode Cnt Score Error Units >> RandMinVal.getMax thrpt 3 9707774.405 ? 27082629.015 ops/s >> RandMinVal.getMin thrpt 3 7510319.839 ? 10923547.382 ops/s >> >> >> Enabled >> >> Benchmark Mode Cnt Score Error Units >> RandMinVal.getMax thrpt 3 10127809.127 ? 45404142.338 ops/s >> RandMinVal.getMin thrpt 3 8467677.056 ? 1211998.200 ops/s >> >> >> So I think it is better to enable this flag by default on all of hybrid CPUs. >> >> >> To check what processor would be enabled E-core optimization, I made a [commit](https://github.com/openjdk/jdk/commit/f363ea1436b8100021fdac87b48ec43bcf6820af) to add comments for CPU models at first. I couldn't find out all of models (some models has not listed in SDM vol.4 so far), but most of models (excepts Sierra Forest) could be treated as hybrid CPU. Fortunately HotSpot identify hybrid flag from `CPUID`, so we can leverage it for this purpose. > > Yasumasa Suenaga 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 four additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into ecoreopt-hybrid > - Merge remote-tracking branch 'origin/master' into ecoreopt-hybrid > - Use supports_hybrid() to check for EnableX86ECoreOpts > - Add comments for CPU models src/hotspot/cpu/x86/vm_version_x86.cpp line 924: > 922: // Check if processor has Intel Ecore > 923: if (FLAG_IS_DEFAULT(EnableX86ECoreOpts) && is_intel() && is_intel_server_family() && > 924: (supports_hybrid() || It is not easy to determine if a listed model number will report as "hybrid". But from what I can find 0xDD is: #define INTEL_ATOM_DARKMONT_X IFM(6, 0xDD) /* Clearwater Forest */ which is E-Core architecture, like Sierra Forest, not a hybrid. Is there something else in CPUID we can read to determine the presence of E-Core and so avoid still needing hard-coded lists that need to be maintained? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29149#discussion_r2688889270 From iklam at openjdk.org Wed Jan 14 04:50:14 2026 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 14 Jan 2026 04:50:14 GMT Subject: RFR: 8374549: Extend MetaspaceClosure to cover non-MetaspaceObj types Message-ID: Previously, `MetaspaceClosure` could iterate only `MetaspaceObject`, using its four member functions: - `is_read_only_by_default()` - `metaspace_pointers_do()` - `size()` - `type()` `PackageEntry`, `ModuleEntry` and `GrowableArray` cannot be subclasses from `MetaspaceObject` due to various constraints. As a result, they were copied with ad-hoc code. This PR updates the templates in `MetaspaceClosure` so that it can iterate any classes that have the above four functions. This allows new types of data to be uniformly copied into the AOT cache (aka CDS archive) without ad-hoc copiers. This PR is necessary for future evolution of AOT as more types of data will be copied into the AOT cache. For example, in Valhalla we have a `GrowableArray` that needs to be copied along with `AdapterHandleEntry`. ------------- Commit messages: - More clean up -- MetaspaceObj::Type -> MetaspaceClosureType - clean up - Remove test code inside HotSpot for OtherCArrayRef and MSOCArrayRef - Added OtherCArrayRef and MSOCArrayRef - Removed old code that explicitly convert between GrowableArray and Array - Finished copying and clean up of PackageEntry, ModuleEntry and their growable arrays. These are not actually used by the production run yet - clean up - rename size() to size_in_heapwords() for types that are not MetaspaceObj - Add MetaspaceClosure support functions back to AOTGrowableArray - New AOTGrowableArray class - ... and 7 more: https://git.openjdk.org/jdk/compare/6b3c1e0f...331fe165 Changes: https://git.openjdk.org/jdk/pull/29049/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29049&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374549 Stats: 1166 lines in 30 files changed: 651 ins; 306 del; 209 mod Patch: https://git.openjdk.org/jdk/pull/29049.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29049/head:pull/29049 PR: https://git.openjdk.org/jdk/pull/29049 From ysuenaga at openjdk.org Wed Jan 14 05:31:46 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Wed, 14 Jan 2026 05:31:46 GMT Subject: RFR: 8374926: EnableX86ECoreOpts was not enabled on some hybrid CPU [v3] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 04:23:19 GMT, David Holmes wrote: >> Yasumasa Suenaga 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 four additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/master' into ecoreopt-hybrid >> - Merge remote-tracking branch 'origin/master' into ecoreopt-hybrid >> - Use supports_hybrid() to check for EnableX86ECoreOpts >> - Add comments for CPU models > > src/hotspot/cpu/x86/vm_version_x86.cpp line 924: > >> 922: // Check if processor has Intel Ecore >> 923: if (FLAG_IS_DEFAULT(EnableX86ECoreOpts) && is_intel() && is_intel_server_family() && >> 924: (supports_hybrid() || > > It is not easy to determine if a listed model number will report as "hybrid". But from what I can find 0xDD is: > > #define INTEL_ATOM_DARKMONT_X IFM(6, 0xDD) /* Clearwater Forest */ > > which is E-Core architecture, like Sierra Forest, not a hybrid. > > Is there something else in CPUID we can read to determine the presence of E-Core and so avoid still needing hard-coded lists that need to be maintained? I checked Chapter 21 in [SDM vol.1](https://cdrdv2.intel.com/v1/dl/getContent/671436), but I couldn't find out the flag which can be used for checking E-Core. However I think we can use CORE_TYPE from CPUID Leaf 1Ah (Native Model ID Enumeration). CORE_TYPE reports tye type of logical processor issued `CPUID` instruction. If it runs on all E-Core architecture like Sierra Forest, CORE_TYPE should report 20h (Atom), and then we can determine we can set `EnableX86ECoreOpts`. I've made an example to check CORE_TYPE, and I think similar logic can be implemented on HotSpot. Is it reasonable? I can add it if it sounds good. https://github.com/YaSuenag/garakuta/blob/master/check-hybrid-cores/hy-core-check.c#L97-L128 asm volatile( "movl $0x1A, %%eax\n" "xorl %%ecx, %%ecx\n" "cpuid" : "=a"(core_info) : : "ebx", "ecx", "edx" ); int core_type = core_info >> 24; printf("logical processor domain = %d, core domain = %d, type = 0x%x, native model id = 0x%x\n", logical_processors, cores, core_type, native_model_id); On hybrid CPU, we don't know where `CPUID` is issued (without pinning), it means we can see "Core" (P-Core) in some case, but we can use hybrid flag which is already introduced in HotSpot to determine E-Core exists. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29149#discussion_r2689015303 From cjplummer at openjdk.org Wed Jan 14 05:38:09 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 14 Jan 2026 05:38:09 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v16] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: On Sat, 10 Jan 2026 03:23:52 GMT, SendaoYan wrote: >> Hi all, >> >> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. >> >> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. >> >> Additional testing: >> >> - [x] All jtreg tests by fastdebug build > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Fix several typos Looks good now. Thanks! ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28891#pullrequestreview-3658953058 From thartmann at openjdk.org Wed Jan 14 06:10:23 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 14 Jan 2026 06:10:23 GMT Subject: [jdk26] RFR: 8374570: Assertion failure in ClearArray.java with -XX:+EnableX86EcoreOpts Message-ID: Hi all, This pull request contains a backport of commit [45990d79](https://github.com/openjdk/jdk/commit/45990d796ffafc228c6e843049c80aefedb0f12b) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Volodymyr Paprotski on 13 Jan 2026 and was reviewed by Tobias Hartmann, Emanuel Peter and Quan Anh Mai. Thanks! ------------- Commit messages: - Backport 45990d796ffafc228c6e843049c80aefedb0f12b Changes: https://git.openjdk.org/jdk/pull/29216/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29216&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374570 Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29216.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29216/head:pull/29216 PR: https://git.openjdk.org/jdk/pull/29216 From lmesnik at openjdk.org Wed Jan 14 06:34:00 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 14 Jan 2026 06:34:00 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v5] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: <7kgAC4XAKsAf5OWtcoKHzLWZ9-X-7gkrSqZWlGfaswo=.60598d6d-f3a0-440d-a953-bf82de55a268@github.com> On Wed, 24 Dec 2025 07:28:14 GMT, SendaoYan wrote: >>> There are references to `nsk.share.gc.GCClassUnloader` in some of the test descriptions that need updating. There are also comments like "Next, debugger forces debuggee to unload class, using memory stressing techique" that need updating. I think you need to review all the test description comments. >>> >>> I think someone from the GC team should review the GC test changes since WB.fullGC() is a very different approach to ClassUnloader. >> >> The two kinds of incorrect commets has been updated. I think i need some more time the check all the comments for the touched tests. Thanks for your reviews. > >> The two kinds of incorrect commets has been updated. I think i need some more time the check all the comments for the touched tests. Thanks for your reviews. > > All the comments in touched tests has been checked. @sendaoYan Can you please update the summary of this PR and Bug and reflect the whole scope of changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28891#issuecomment-3748009565 From chagedorn at openjdk.org Wed Jan 14 06:36:00 2026 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Wed, 14 Jan 2026 06:36:00 GMT Subject: [jdk26] RFR: 8374570: Assertion failure in ClearArray.java with -XX:+EnableX86EcoreOpts In-Reply-To: References: Message-ID: <-dU_N-sc4fZ_6DYxyfNPPR41r3UGcFilpRLtZ4AU8co=.684e3a7f-4ef5-4a78-b23d-660d627eb673@github.com> On Wed, 14 Jan 2026 06:04:37 GMT, Tobias Hartmann wrote: > Hi all, > > This pull request contains a backport of commit [45990d79](https://github.com/openjdk/jdk/commit/45990d796ffafc228c6e843049c80aefedb0f12b) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Volodymyr Paprotski on 13 Jan 2026 and was reviewed by Tobias Hartmann, Emanuel Peter and Quan Anh Mai. > > Thanks! Looks good! ------------- Marked as reviewed by chagedorn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29216#pullrequestreview-3659084649 From thartmann at openjdk.org Wed Jan 14 06:36:00 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 14 Jan 2026 06:36:00 GMT Subject: [jdk26] RFR: 8374570: Assertion failure in ClearArray.java with -XX:+EnableX86EcoreOpts In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 06:04:37 GMT, Tobias Hartmann wrote: > Hi all, > > This pull request contains a backport of commit [45990d79](https://github.com/openjdk/jdk/commit/45990d796ffafc228c6e843049c80aefedb0f12b) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Volodymyr Paprotski on 13 Jan 2026 and was reviewed by Tobias Hartmann, Emanuel Peter and Quan Anh Mai. > > Thanks! Thanks Christian. Since we enter RDP 2 tomorrow and this applies cleanly, I'll integrate as soon as internal testing passed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29216#issuecomment-3748016702 From shade at openjdk.org Wed Jan 14 07:21:33 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 14 Jan 2026 07:21:33 GMT Subject: [jdk26] RFR: 8374570: Assertion failure in ClearArray.java with -XX:+EnableX86EcoreOpts In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 06:04:37 GMT, Tobias Hartmann wrote: > Hi all, > > This pull request contains a backport of commit [45990d79](https://github.com/openjdk/jdk/commit/45990d796ffafc228c6e843049c80aefedb0f12b) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Volodymyr Paprotski on 13 Jan 2026 and was reviewed by Tobias Hartmann, Emanuel Peter and Quan Anh Mai. > > Thanks! Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29216#pullrequestreview-3659214805 From thartmann at openjdk.org Wed Jan 14 07:30:31 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 14 Jan 2026 07:30:31 GMT Subject: [jdk26] RFR: 8374570: Assertion failure in ClearArray.java with -XX:+EnableX86EcoreOpts In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 06:04:37 GMT, Tobias Hartmann wrote: > Hi all, > > This pull request contains a backport of commit [45990d79](https://github.com/openjdk/jdk/commit/45990d796ffafc228c6e843049c80aefedb0f12b) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Volodymyr Paprotski on 13 Jan 2026 and was reviewed by Tobias Hartmann, Emanuel Peter and Quan Anh Mai. > > Thanks! Thanks Aleksey! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29216#issuecomment-3748183292 From aboldtch at openjdk.org Wed Jan 14 07:47:18 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 14 Jan 2026 07:47:18 GMT Subject: RFR: 8372241: Add GTestCheckers [v8] In-Reply-To: References: Message-ID: > 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 10 additional commits since the last revision: - Remove fixed test from filter - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8372241 - Update copyright years - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8372241 - 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/990f4f58..412fccf1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28409&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28409&range=06-07 Stats: 1290 lines in 41 files changed: 1099 ins; 71 del; 120 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 syan at openjdk.org Wed Jan 14 07:57:59 2026 From: syan at openjdk.org (SendaoYan) Date: Wed, 14 Jan 2026 07:57:59 GMT Subject: RFR: 8373945: Use WB.fullGC() in ClassUnloader.unloadClass to force GC for vmTestbase tests [v5] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: <08JqY0tXW8Zh0cZ3NYDT4UqZMNIeVoiSLQWxX584aXk=.b3eccb34-5764-4c8b-adb0-ccdf3c778f25@github.com> On Wed, 24 Dec 2025 07:28:14 GMT, SendaoYan wrote: >>> There are references to `nsk.share.gc.GCClassUnloader` in some of the test descriptions that need updating. There are also comments like "Next, debugger forces debuggee to unload class, using memory stressing techique" that need updating. I think you need to review all the test description comments. >>> >>> I think someone from the GC team should review the GC test changes since WB.fullGC() is a very different approach to ClassUnloader. >> >> The two kinds of incorrect commets has been updated. I think i need some more time the check all the comments for the touched tests. Thanks for your reviews. > >> The two kinds of incorrect commets has been updated. I think i need some more time the check all the comments for the touched tests. Thanks for your reviews. > > All the comments in touched tests has been checked. > @sendaoYan Can you please update the summary of this PR and Bug and reflect the whole scope of changes. I have updated to title of this PR and JBS as "Use WB.fullGC() in ClassUnloader.unloadClass to force GC for vmTestbase tests". If you have better concise summary, please let me known. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28891#issuecomment-3748276900 From ghan at openjdk.org Wed Jan 14 08:12:41 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Wed, 14 Jan 2026 08:12:41 GMT Subject: RFR: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 02:04:26 GMT, David Holmes wrote: >> Guanqiang Han 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 four additional commits since the last revision: >> >> - change variable name >> - Merge remote-tracking branch 'upstream/master' into 8374862 >> - fix a compile error >> - fix 8374862 > > src/hotspot/share/runtime/vframeArray.cpp line 511: > >> 509: vframe* f = vframe::new_vframe(iframe(), &map, thread); >> 510: f->print(); >> 511: if (dump_codes) { > > Suggestion: > > if (print_codes) { All fixed, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29186#discussion_r2689404668 From aph at openjdk.org Wed Jan 14 09:01:29 2026 From: aph at openjdk.org (Andrew Haley) Date: Wed, 14 Jan 2026 09:01:29 GMT Subject: RFR: 8373696: AArch64: Refine post-call NOPs In-Reply-To: References: <9G7UQDZGLfV0nhrQSv-a9EMvhIAkCdTB3hA9Pf6hRIo=.59b380be-e009-420e-8f76-7771e205467b@github.com> Message-ID: On Tue, 13 Jan 2026 11:35:17 GMT, Ruben wrote: > From an initial experiment, is appears oopmap_index increments about every 8 instructions on average - though this observation might be specific to a certain workload. However, if that's the case, current implementation allows us to encode post-call NOPs metadata for offsets up to 8K. The above approach would be an improvement in this case: the MOVK/MOVZ-based chunks would allow us to encode the metadata for offsets up to 16K, while MOVN-based chunks would improve search for the rest of the cases. > > What do you think about this option? It sounds rather complicated. It's important that the performance work we do doesn't over complexify the implementation. Whatever we do should be proportionate to the scale of the problem. Post-call NOPs are not a huge deal. Why not use MOVN, and put the data into a stub at the end of the nmethod? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28855#issuecomment-3748496614 From mgronlun at openjdk.org Wed Jan 14 09:04:48 2026 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 14 Jan 2026 09:04:48 GMT Subject: [jdk26] RFR: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is incorrectly implemented In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 18:14:09 GMT, Markus Gr?nlund wrote: > 8371014: Dump JFR recording on CrashOnOutOfMemoryError is incorrectly implemented Can you please also review the backport to 26 @YaSuenag ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29203#issuecomment-3748504204 From aph at openjdk.org Wed Jan 14 09:05:04 2026 From: aph at openjdk.org (Andrew Haley) Date: Wed, 14 Jan 2026 09:05:04 GMT Subject: RFR: 8372942: AArch64: Set JVM flags for Neoverse V3AE core In-Reply-To: References: Message-ID: <8eI5E6cyFbIzKfiWurr2ovAUQEML2LDiJIW11BFX27w=.962bede5-2cc2-4e90-97f9-4953750f4b11@github.com> On Thu, 1 Jan 2026 10:02:02 GMT, Andrew Haley 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. > Thank you for review, @theRealAph, > > > 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. > > While switch-case might not be easily applicable because we have two variables, both of which have to be compared with the values, I only see one here, the `model_is`. > perhaps an interface like `bool is_model_any_of(std::initializer_list list)` can simplify the code. Would this approach be suitable? Maybe, if it's made as simple as possible. > Would you like this to be changed within this PR? I think so. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28607#issuecomment-3748509238 From thartmann at openjdk.org Wed Jan 14 09:10:47 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 14 Jan 2026 09:10:47 GMT Subject: [jdk26] Integrated: 8374570: Assertion failure in ClearArray.java with -XX:+EnableX86EcoreOpts In-Reply-To: References: Message-ID: <1J3egVn2RViJynWxUEn7b8BXkMySbKQQ0-uzhJKXhT0=.88b6711a-520f-4c3f-aa7a-a7b612d20d4a@github.com> On Wed, 14 Jan 2026 06:04:37 GMT, Tobias Hartmann wrote: > Hi all, > > This pull request contains a backport of commit [45990d79](https://github.com/openjdk/jdk/commit/45990d796ffafc228c6e843049c80aefedb0f12b) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Volodymyr Paprotski on 13 Jan 2026 and was reviewed by Tobias Hartmann, Emanuel Peter and Quan Anh Mai. > > Thanks! This pull request has now been integrated. Changeset: ee30afae Author: Tobias Hartmann URL: https://git.openjdk.org/jdk/commit/ee30afae7420acbd250a17df89288643adab7a33 Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod 8374570: Assertion failure in ClearArray.java with -XX:+EnableX86EcoreOpts Reviewed-by: chagedorn, shade Backport-of: 45990d796ffafc228c6e843049c80aefedb0f12b ------------- PR: https://git.openjdk.org/jdk/pull/29216 From ghan at openjdk.org Wed Jan 14 09:39:02 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Wed, 14 Jan 2026 09:39:02 GMT Subject: RFR: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) [v3] In-Reply-To: References: Message-ID: > Please review this change. Thanks! > > **Description:** > > When -XX:+PrintDeoptimizationDetails is enabled, vframeArray.cpp prints interpreted frames under ttyLocker. > https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/runtime/vframeArray.cpp#L493-L503 > In the WizardMode && Verbose branch it calls Method::print_codes() / print_codes_on(). The bytecode printing path may acquire MDOExtraData_lock (rank nosafepoint-1). > https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/interpreter/bytecodeTracer.cpp#L597-L602 > Calling it while holding tty_lock violates the global lock ranking order and triggers a lock rank inversion assertion. > > **Fix:** > > Generate the bytecode dump before taking tty_lock, and print it afterwards under ttyLocker to keep the output coherent while preserving correct lock acquisition order. > To avoid double buffering when the target stream is already a thread-local stringStream, extend BytecodeTracer::print_method_codes with a buffered flag . The new call site uses buffered=false when dumping into the temporary stringStream. > > **Test:** > > GHA Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: Add outputStream::is_buffered() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29186/files - new: https://git.openjdk.org/jdk/pull/29186/files/d584c0e5..52c9594e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29186&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29186&range=01-02 Stats: 15 lines in 6 files changed: 3 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/29186.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29186/head:pull/29186 PR: https://git.openjdk.org/jdk/pull/29186 From ghan at openjdk.org Wed Jan 14 09:46:02 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Wed, 14 Jan 2026 09:46:02 GMT Subject: RFR: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) [v4] In-Reply-To: References: Message-ID: > Please review this change. Thanks! > > **Description:** > > When -XX:+PrintDeoptimizationDetails is enabled, vframeArray.cpp prints interpreted frames under ttyLocker. > https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/runtime/vframeArray.cpp#L493-L503 > In the WizardMode && Verbose branch it calls Method::print_codes() / print_codes_on(). The bytecode printing path may acquire MDOExtraData_lock (rank nosafepoint-1). > https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/interpreter/bytecodeTracer.cpp#L597-L602 > Calling it while holding tty_lock violates the global lock ranking order and triggers a lock rank inversion assertion. > > **Fix:** > > Generate the bytecode dump before taking tty_lock, and print it afterwards under ttyLocker to keep the output coherent while preserving correct lock acquisition order. > To avoid double buffering when the target stream is already a thread-local stringStream, extend BytecodeTracer::print_method_codes with a buffered flag . The new call site uses buffered=false when dumping into the temporary stringStream. > > **Test:** > > GHA Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: correct copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29186/files - new: https://git.openjdk.org/jdk/pull/29186/files/52c9594e..d015bb50 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29186&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29186&range=02-03 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29186.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29186/head:pull/29186 PR: https://git.openjdk.org/jdk/pull/29186 From ghan at openjdk.org Wed Jan 14 09:53:23 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Wed, 14 Jan 2026 09:53:23 GMT Subject: RFR: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) [v5] In-Reply-To: References: Message-ID: > Please review this change. Thanks! > > **Description:** > > When -XX:+PrintDeoptimizationDetails is enabled, vframeArray.cpp prints interpreted frames under ttyLocker. > https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/runtime/vframeArray.cpp#L493-L503 > In the WizardMode && Verbose branch it calls Method::print_codes() / print_codes_on(). The bytecode printing path may acquire MDOExtraData_lock (rank nosafepoint-1). > https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/interpreter/bytecodeTracer.cpp#L597-L602 > Calling it while holding tty_lock violates the global lock ranking order and triggers a lock rank inversion assertion. > > **Fix:** > > Generate the bytecode dump before taking tty_lock, and print it afterwards under ttyLocker to keep the output coherent while preserving correct lock acquisition order. > To avoid double buffering when the target stream is already a thread-local stringStream, extend BytecodeTracer::print_method_codes with a buffered flag . The new call site uses buffered=false when dumping into the temporary stringStream. > > **Test:** > > GHA Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: remove unnecessary blank line ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29186/files - new: https://git.openjdk.org/jdk/pull/29186/files/d015bb50..9dc71b7d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29186&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29186&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29186.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29186/head:pull/29186 PR: https://git.openjdk.org/jdk/pull/29186 From ysuenaga at openjdk.org Wed Jan 14 09:53:31 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Wed, 14 Jan 2026 09:53:31 GMT Subject: [jdk26] RFR: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is incorrectly implemented In-Reply-To: References: Message-ID: <4cVV_QKVhvDsK5TIJ6xmux4INP9msOEl0W4MyQU8SV4=.68ccb9b0-5968-467b-a5f4-9c902cdd3fb0@github.com> On Tue, 13 Jan 2026 18:14:09 GMT, Markus Gr?nlund wrote: > 8371014: Dump JFR recording on CrashOnOutOfMemoryError is incorrectly implemented Marked as reviewed by ysuenaga (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29203#pullrequestreview-3659821661 From shade at openjdk.org Wed Jan 14 10:22:37 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 14 Jan 2026 10:22:37 GMT Subject: RFR: 8375209: Strengthen Xcheck:jni for JNI critical regions [v2] In-Reply-To: References: Message-ID: <9J23vzOj_QalT_MgSo4KXdWZg2g4F82ojnGUndc6V-w=.767a9a88-3873-4dca-b1d8-90e9a9e9f2c7@github.com> On Tue, 13 Jan 2026 19:44:23 GMT, Aleksey Shipilev wrote: >> [JDK-8375188](https://bugs.openjdk.org/browse/JDK-8375188) shows that misuse for JNI critical is able to deadlock the GC. Therefore, I think we really want to have `-Xcheck:jni` to preempt these cases and allow us to diagnose the issues in the field. >> >> G1 and Shenandoah are not exactly affected by this deadlock. ZGC never had this check, AFAICS, and is affected by the deadlock. We used to have some capability in Serial/Parallel prior to [JDK-8192647](https://bugs.openjdk.org/browse/JDK-8192647), AFAICS: https://github.com/openjdk/jdk/commit/a9c9f7f0cbb2f2395fef08348bf867ffa8875d73#diff-d27fc793db1bf9314b322d494cd1c3269629fe27a605b4441de08d543d020fc3L341-L344 >> >> Additional testing: >> - [x] New test, 100x repetitions >> - [ ] Linux x86_64 server fastdebug, `all` with `-XX:+UseParallelGC -Xcheck:jni` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Terminology Yes, it looks to me that there are "normal" native->VM transitions here and there. We can be more precise and check for JNI Critical state at the end of the actual JNI transition in interpreted/compiled adapters and native->Java transitions on VM side. This unfortunately means some checks are in platform-specific code. See the new PR version for a stab at how that might look like. I'll run more tests to see if anything in JDK depends on current (broken) behavior. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29206#issuecomment-3748810279 From shade at openjdk.org Wed Jan 14 10:22:35 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 14 Jan 2026 10:22:35 GMT Subject: RFR: 8375209: Strengthen Xcheck:jni for JNI critical regions [v3] In-Reply-To: References: Message-ID: > [JDK-8375188](https://bugs.openjdk.org/browse/JDK-8375188) shows that misuse for JNI critical is able to deadlock the GC. Therefore, I think we really want to have `-Xcheck:jni` to preempt these cases and allow us to diagnose the issues in the field. > > G1 and Shenandoah are not exactly affected by this deadlock. ZGC never had this check, AFAICS, and is affected by the deadlock. We used to have some capability in Serial/Parallel prior to [JDK-8192647](https://bugs.openjdk.org/browse/JDK-8192647), AFAICS: https://github.com/openjdk/jdk/commit/a9c9f7f0cbb2f2395fef08348bf867ffa8875d73#diff-d27fc793db1bf9314b322d494cd1c3269629fe27a605b4441de08d543d020fc3L341-L344 > > Additional testing: > - [x] New test, 100x repetitions > - [ ] Linux x86_64 server fastdebug, `all` with `-XX:+UseParallelGC -Xcheck:jni` Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Capture bad state at the end of JNI transition, check criticality on JNI function enters Move the check to native->Java transition ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29206/files - new: https://git.openjdk.org/jdk/pull/29206/files/4eeb4a04..765ef9d0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29206&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29206&range=01-02 Stats: 46 lines in 8 files changed: 26 ins; 9 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/29206.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29206/head:pull/29206 PR: https://git.openjdk.org/jdk/pull/29206 From cnorrbin at openjdk.org Wed Jan 14 10:44:25 2026 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Wed, 14 Jan 2026 10:44:25 GMT Subject: RFR: 8367319: Add os interfaces to get machine and container values separately [v7] In-Reply-To: References: Message-ID: > Hi everyone, > > The current `os::` layer on Linux hides whether the JVM is running inside a container or not. When running inside a container, we replace machine values with container values where applicable, without telling the user of these methods. For most use cases, this is fine, users only care about the returned value. But for other use cases, where the value originated is important. Two examples: > > - A user might need the physical cpu count of the machine, but `os::active_processor_count()` only returns the limited container value, which also represents something slightly different. > - A user might want the container memory limit and the physical RAM size, but `os::physical_memory()` only gives one number. > > To solve this, every function that mixed container/machine values now has to explicit variants, prefixed with `machine_` and `container_`. These use the bool return + out-parameter interface, with the container functions only working on Linux. The original methods remain and continue to return the same mixed values. > > In addition, container-specific accessors for the memory soft limit and the memory throttle limit have been added, as these values matter when running in a containerized environment. > > `OSContainer::active_processor_count()` has also been changed to return `double` instead of `int`. The previous implementation rounded the quota/period ratio up to produce an integer for `os::active_processor_count()`. Now, when the value is requested directly from the new container API it makes more sense to preserve this fraction rather than rounding it up. We can thus keep the exact value for those that want it, then round it up to keep the same behavior in `os::active_processor_count()`. > > Testing: > - Oracle tiers 1-5 > - Container tests on cgroup v1 and v2 hosts. Casper Norrbin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - bump copyright headers - remove duplicate comments + double type printing - Merge branch 'master' into separate-container-machine-values - feedback updates - return false when no limit + removed unneeded asserts - Merge branch 'master' into separate-container-machine-values - Merge branch 'master' into separate-container-machine-values - Merge branch 'master' into separate-container-machine-values - Move methods to Machine/Container inner classes + clarifying documentation - Merge branch 'master' into separate-container-machine-values - ... and 2 more: https://git.openjdk.org/jdk/compare/578204f8...e2ad48d4 ------------- Changes: https://git.openjdk.org/jdk/pull/27646/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27646&range=06 Stats: 411 lines in 20 files changed: 253 ins; 54 del; 104 mod Patch: https://git.openjdk.org/jdk/pull/27646.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27646/head:pull/27646 PR: https://git.openjdk.org/jdk/pull/27646 From aph at openjdk.org Wed Jan 14 11:02:24 2026 From: aph at openjdk.org (Andrew Haley) Date: Wed, 14 Jan 2026 11:02:24 GMT Subject: RFR: 8365147: AArch64: Replace DMB + LD + DMB with LDAR for C1 volatile field loads [v4] In-Reply-To: References: <3a_1QZxP59TuI3FewXHDcR_xWH616tlSpcCf1f4BbP0=.c7570d0a-56a6-424d-a5ea-489318734d99@github.com> Message-ID: <9y5nQuh1S81hB6VgiwdGdHt2LS3pVzLl_D45PX5ni0M=.238114a7-5e70-4d5c-b4e7-571fb65b2be7@github.com> On Tue, 13 Jan 2026 14:49:42 GMT, Ruben wrote: > also `jcstress` test suite had been run. What options did you use to run jcstress? Did you use `-XX:TieredStopAtLevel=1`? Otherwise it won't use tier1. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26748#issuecomment-3748973791 From jbhateja at openjdk.org Wed Jan 14 11:02:26 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 14 Jan 2026 11:02:26 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v11] In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 10:22:25 GMT, Fei Yang wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Adding testpoint for JDK-8373574 > > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16Vector.java line 1653: > >> 1651: * >> 1652: * @param e the input scalar >> 1653: * @return the result of multiplying this vector by the given scalar > > The code comment mentions "multiplying", which doesn't seem correct to me. Are we doing any multiplication for min/max? This is the problem in JDK-mainline code also, we should address it separately. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2689974123 From mgronlun at openjdk.org Wed Jan 14 11:02:56 2026 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 14 Jan 2026 11:02:56 GMT Subject: [jdk26] RFR: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is incorrectly implemented In-Reply-To: <4cVV_QKVhvDsK5TIJ6xmux4INP9msOEl0W4MyQU8SV4=.68ccb9b0-5968-467b-a5f4-9c902cdd3fb0@github.com> References: <4cVV_QKVhvDsK5TIJ6xmux4INP9msOEl0W4MyQU8SV4=.68ccb9b0-5968-467b-a5f4-9c902cdd3fb0@github.com> Message-ID: <5Fl8Ynrvx4YIKLdJs85xf-6qk42Fkwt5XWsZXhF4caU=.e17f5327-6df9-4072-9d70-325aa5ef2249@github.com> On Wed, 14 Jan 2026 09:51:04 GMT, Yasumasa Suenaga wrote: >> 8371014: Dump JFR recording on CrashOnOutOfMemoryError is incorrectly implemented > > Marked as reviewed by ysuenaga (Reviewer). Thanks for your review @YaSuenag! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29203#issuecomment-3748984614 From mgronlun at openjdk.org Wed Jan 14 11:07:20 2026 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 14 Jan 2026 11:07:20 GMT Subject: [jdk26] Integrated: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is incorrectly implemented In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 18:14:09 GMT, Markus Gr?nlund wrote: > 8371014: Dump JFR recording on CrashOnOutOfMemoryError is incorrectly implemented This pull request has now been integrated. Changeset: f3bdee89 Author: Markus Gr?nlund URL: https://git.openjdk.org/jdk/commit/f3bdee89ed1acd8a61989dd580f11ff184166520 Stats: 292 lines in 15 files changed: 219 ins; 18 del; 55 mod 8371014: Dump JFR recording on CrashOnOutOfMemoryError is incorrectly implemented Reviewed-by: ysuenaga Backport-of: f23752a75ee3d3af0853eff9c678d2496bb1cf58 ------------- PR: https://git.openjdk.org/jdk/pull/29203 From fyang at openjdk.org Wed Jan 14 11:14:06 2026 From: fyang at openjdk.org (Fei Yang) Date: Wed, 14 Jan 2026 11:14:06 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v11] In-Reply-To: References: Message-ID: <53ngdNhoWJy4Cacq2Xs1bC0ulSPPVcUdz6WoSb3Pp6U=.699dfca7-3a7c-4f6b-addb-3c26b8f4c357@github.com> On Wed, 14 Jan 2026 10:58:44 GMT, Jatin Bhateja wrote: >> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16Vector.java line 1653: >> >>> 1651: * >>> 1652: * @param e the input scalar >>> 1653: * @return the result of multiplying this vector by the given scalar >> >> The code comment mentions "multiplying", which doesn't seem correct to me. Are we doing any multiplication for min/max? > > This is the problem in JDK-mainline code also, we should address it separately. Sure. I just realized that it is there for Float / Double varients as well in mainline. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2690008963 From kevinw at openjdk.org Wed Jan 14 11:24:58 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 14 Jan 2026 11:24:58 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v5] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: <1UIQCA4KZxbcVPvePdiXUYmBBdxOhmnK779XX85qIPo=.ea87b867-ee1d-4385-935b-a656591d9f5e@github.com> On Tue, 13 Jan 2026 20:44:37 GMT, Larry Cable 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: changes as per @dholmes and @kwalls Marked as reviewed by kevinw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29048#pullrequestreview-3660231150 From tschatzl at openjdk.org Wed Jan 14 11:43:47 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 14 Jan 2026 11:43:47 GMT Subject: RFR: 8375040: Clearer names for non-metadata oop iterators in ObjArrayKlass [v2] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 15:38:08 GMT, Stefan Karlsson wrote: >> During the review of [JDK-8374780](https://bugs.openjdk.org/browse/JDK-8374780) it was clear that the naming of the various oop iterators, and also their comments, were somewhat misleading about if they visited the metadata or not. >> >> I propose that we make a clear separation and have it so that all iterators that only visit the array elements are named to contain the word "elements" to make it slightly clearer that these iterators only visits the elements. >> >> So, we know how the following ObjArrayKlass oop iterators: >> >> Iterators that also visit the metadata: >> >> oop_oop_iterate >> oop_oop_iterate_reverse >> oop_oop_iterate_bounded >> >> >> Iterators that are not visiting the metadata: >> >> oop_oop_iterate_elements >> oop_oop_iterate_elements_range >> oop_oop_iterate_elements_bounded >> >> >> The objArrayOopDesc class also exposes an oop iterator and that function has been renamed to mimic the above scheme to add the `_elements` to functions that does not visit the metadata: >> >> oop_iterate_elements_range >> >> >> Two extra things to check in the patch: >> >> 1) I did some slight tweaks to the code so that `oop_oop_iterate_elements` is implemented with `oop_oop_iterate_elements_range`. >> >> 2) I moved the objArrayOopDesc function back to the oopArrayOop.inline.hpp. The reason is that we have now solved the problems with circular dependencies between .inline.hpp files, so this workaround isn't needed anymore. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/share/oops/objArrayOop.hpp > > Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com> Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29170#pullrequestreview-3660302101 From alanb at openjdk.org Wed Jan 14 12:02:29 2026 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 14 Jan 2026 12:02:29 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v6] In-Reply-To: <10YcFooDOHT6M4PWRHBAUzYNhQW1X1nnaLPGIcDrgFE=.1e66f22a-8643-4ee1-bd88-e854fd4d48f7@github.com> References: <10YcFooDOHT6M4PWRHBAUzYNhQW1X1nnaLPGIcDrgFE=.1e66f22a-8643-4ee1-bd88-e854fd4d48f7@github.com> Message-ID: On Fri, 9 Jan 2026 18:38:53 GMT, Kieran Farrell 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: > > sperate VM.sec_props command I think the latest proposal with `jcmd VM.security_properties` looks reasonable. My guess is that many developers don't know about security properties, or might think they are system properties that do something magic with security. So I think expand the current help/description from "Print security properties" to include "java.security.Security" in the text so there is somewhere to go and learn what this is. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3749232175 From mdoerr at openjdk.org Wed Jan 14 12:07:27 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 14 Jan 2026 12:07:27 GMT Subject: RFR: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is incorrectly implemented In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 14:14:19 GMT, Markus Gr?nlund 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 Thanks for fixing and backporting it! I had taken a quick look and think it is good, but not a full review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29094#issuecomment-3749247796 From ysuenaga at openjdk.org Wed Jan 14 12:46:34 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Wed, 14 Jan 2026 12:46:34 GMT Subject: RFR: 8374926: EnableX86ECoreOpts was not enabled on some hybrid CPU [v3] In-Reply-To: References: Message-ID: On Sun, 11 Jan 2026 07:46:33 GMT, Yasumasa Suenaga wrote: >> `EnableX86ECoreOpts` has been introduced in [JDK-8319429](https://bugs.openjdk.org/browse/JDK-8319429), however model numbers which should be enabled are hard-coded, so the flag would not be enabled by default on some models like Arrow Lake. >> >> I ran a [benchmark](https://github.com/YaSuenag/garakuta/tree/master/randminmax) to check for effectiveness of `-XX:+EnableX86ECoreOpts` with JDK 25.0.1 on Windows 11 25H2, I saw performance improvement a bit on Intel Core 5 Ultra 225U as following: >> >> Disabled (default) >> >> Benchmark Mode Cnt Score Error Units >> RandMinVal.getMax thrpt 3 9707774.405 ? 27082629.015 ops/s >> RandMinVal.getMin thrpt 3 7510319.839 ? 10923547.382 ops/s >> >> >> Enabled >> >> Benchmark Mode Cnt Score Error Units >> RandMinVal.getMax thrpt 3 10127809.127 ? 45404142.338 ops/s >> RandMinVal.getMin thrpt 3 8467677.056 ? 1211998.200 ops/s >> >> >> So I think it is better to enable this flag by default on all of hybrid CPUs. >> >> >> To check what processor would be enabled E-core optimization, I made a [commit](https://github.com/openjdk/jdk/commit/f363ea1436b8100021fdac87b48ec43bcf6820af) to add comments for CPU models at first. I couldn't find out all of models (some models has not listed in SDM vol.4 so far), but most of models (excepts Sierra Forest) could be treated as hybrid CPU. Fortunately HotSpot identify hybrid flag from `CPUID`, so we can leverage it for this purpose. > > Yasumasa Suenaga 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 four additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into ecoreopt-hybrid > - Merge remote-tracking branch 'origin/master' into ecoreopt-hybrid > - Use supports_hybrid() to check for EnableX86ECoreOpts > - Add comments for CPU models > I've made an example to check CORE_TYPE, and I think similar logic can be implemented on HotSpot. Is it reasonable? I can add it if it sounds good. I made a commit in another branch to check E-Core with leaf 1Ah. I think it works, but I cannot check on all E-Core processors like Xeon 6. I'm concerned SDM vol.1 says leaf 1Ah may not be present in some processors. https://github.com/YaSuenag/jdk/compare/ecoreopt-hybrid...YaSuenag:jdk:check-ecore ------------- PR Comment: https://git.openjdk.org/jdk/pull/29149#issuecomment-3749392291 From ghan at openjdk.org Wed Jan 14 13:56:46 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Wed, 14 Jan 2026 13:56:46 GMT Subject: RFR: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) [v6] In-Reply-To: References: Message-ID: > Please review this change. Thanks! > > **Description:** > > When -XX:+PrintDeoptimizationDetails is enabled, vframeArray.cpp prints interpreted frames under ttyLocker. > https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/runtime/vframeArray.cpp#L493-L503 > In the WizardMode && Verbose branch it calls Method::print_codes() / print_codes_on(). The bytecode printing path may acquire MDOExtraData_lock (rank nosafepoint-1). > https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/interpreter/bytecodeTracer.cpp#L597-L602 > Calling it while holding tty_lock violates the global lock ranking order and triggers a lock rank inversion assertion. > > **Fix:** > > Generate the bytecode dump before taking tty_lock, and print it afterwards under ttyLocker to keep the output coherent while preserving correct lock acquisition order. > To avoid double buffering when the target stream is already a thread-local stringStream, extend BytecodeTracer::print_method_codes with a buffered flag . The new call site uses buffered=false when dumping into the temporary stringStream. > > **Test:** > > GHA Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: fix a compile error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29186/files - new: https://git.openjdk.org/jdk/pull/29186/files/9dc71b7d..ea011598 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29186&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29186&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29186.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29186/head:pull/29186 PR: https://git.openjdk.org/jdk/pull/29186 From jvernee at openjdk.org Wed Jan 14 14:08:08 2026 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 14 Jan 2026 14:08:08 GMT Subject: RFR: 8375209: Strengthen Xcheck:jni for JNI critical regions [v3] In-Reply-To: References: Message-ID: <3MXcawHFhCVI0hAqC2d4w83fiHfTJkhzkGHTKdD6P_Y=.ad9be4d9-b639-455a-bac4-1e213c890bce@github.com> On Wed, 14 Jan 2026 10:22:35 GMT, Aleksey Shipilev wrote: >> [JDK-8375188](https://bugs.openjdk.org/browse/JDK-8375188) shows that misuse for JNI critical is able to deadlock the GC. Therefore, I think we really want to have `-Xcheck:jni` to preempt these cases and allow us to diagnose the issues in the field. >> >> G1 and Shenandoah are not exactly affected by this deadlock. ZGC never had this check, AFAICS, and is affected by the deadlock. We used to have some capability in Serial/Parallel prior to [JDK-8192647](https://bugs.openjdk.org/browse/JDK-8192647), AFAICS: https://github.com/openjdk/jdk/commit/a9c9f7f0cbb2f2395fef08348bf867ffa8875d73#diff-d27fc793db1bf9314b322d494cd1c3269629fe27a605b4441de08d543d020fc3L341-L344 >> >> Additional testing: >> - [x] New test, 100x repetitions >> - [ ] Linux x86_64 server fastdebug, `all` with `-XX:+UseParallelGC -Xcheck:jni` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Capture bad state at the end of JNI transition, check criticality on JNI function enters > Move the check to native->Java transition Thanks for taking a stab at this. Yes, unfortunately not everything uses the nice helper functions to do thread state transitions. Particularly, Java -> native calls do this in platform specific assembly code. One place you've missed is in `TemplateInterpreterGenerator::generate_native_entry`. The code is similar to the compiled native wrapper, with an `if (CheckJNICalls) { ... }`, so I think you can just add the same change there. There are also Java -> native -> Java transitions in the downcall stub we generate for FFM calls, but we don't expect native code at the other end of a downcall to interact with JNI, so it's not really important to check there (we also don't check for pending exceptions). AFAIK we need to do a safepoint poll any time we go from a safe state (native or blocked) to an unsafe sate (java or vm), since a safepoint might be in progress during the transition. The fact that `Get*Critical` and `Release*Critical` transition to the vm state seems like an issue to me, since that transition also includes a safepoint poll. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29206#issuecomment-3749714795 From duke at openjdk.org Wed Jan 14 14:12:21 2026 From: duke at openjdk.org (Roger Calnan) Date: Wed, 14 Jan 2026 14:12:21 GMT Subject: Integrated: 8373836: add anchors to the java options in the java man page In-Reply-To: References: Message-ID: <9QDCTo1YDdU4RuJOU3mbU98ZbVFqaRc_zCU4lc8YVKE=.3d6bcb99-356f-4522-8fe1-955c2a05419e@github.com> On Mon, 22 Dec 2025 13:31:54 GMT, Roger Calnan wrote: > adjust each of the command line options to include an html anchor so that one can give a link that goes directly to the section in the man page that covers a specific option This pull request has now been integrated. Changeset: 20bd178b Author: Roger Calnan Committer: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/20bd178b997b8bbf895877774d55d1a9e87c3038 Stats: 247 lines in 1 file changed: 0 ins; 0 del; 247 mod 8373836: add anchors to the java options in the java man page Reviewed-by: jwilhelm, iris ------------- PR: https://git.openjdk.org/jdk/pull/28954 From jvernee at openjdk.org Wed Jan 14 14:15:25 2026 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 14 Jan 2026 14:15:25 GMT Subject: RFR: 8375209: Strengthen Xcheck:jni for JNI critical regions [v3] In-Reply-To: <3MXcawHFhCVI0hAqC2d4w83fiHfTJkhzkGHTKdD6P_Y=.ad9be4d9-b639-455a-bac4-1e213c890bce@github.com> References: <3MXcawHFhCVI0hAqC2d4w83fiHfTJkhzkGHTKdD6P_Y=.ad9be4d9-b639-455a-bac4-1e213c890bce@github.com> Message-ID: On Wed, 14 Jan 2026 14:04:36 GMT, Jorn Vernee wrote: > One place you've missed is in `TemplateInterpreterGenerator::generate_native_entry`. The code is similar to the compiled native wrapper, with an `if (CheckJNICalls) { ... }`, so I think you can just add the same change there. Sorry, I'm blind, you already did that ------------- PR Comment: https://git.openjdk.org/jdk/pull/29206#issuecomment-3749747588 From jnorlinder at openjdk.org Wed Jan 14 14:35:51 2026 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Wed, 14 Jan 2026 14:35:51 GMT Subject: RFR: 8375297: ZGC: Remove obsolete O_CLOEXEC definition Message-ID: With [JDK-8375006](https://bugs.openjdk.org/browse/JDK-8375006) integrated we are no longer supporting building with on a system with kernel headers < 2.6.23 and glibc < 2.7. ------------- Commit messages: - Remove explicit define for O_CLOEXEC Changes: https://git.openjdk.org/jdk/pull/29230/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29230&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375297 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29230.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29230/head:pull/29230 PR: https://git.openjdk.org/jdk/pull/29230 From tschatzl at openjdk.org Wed Jan 14 14:35:51 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 14 Jan 2026 14:35:51 GMT Subject: RFR: 8375297: ZGC: Remove obsolete O_CLOEXEC definition In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 12:14:06 GMT, Jonas Norlinder wrote: > With [JDK-8375006](https://bugs.openjdk.org/browse/JDK-8375006) integrated we are no longer supporting building with on a system with kernel headers < 2.6.23 and glibc < 2.7. Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29230#pullrequestreview-3660732321 From roland at openjdk.org Wed Jan 14 15:02:59 2026 From: roland at openjdk.org (Roland Westrelin) Date: Wed, 14 Jan 2026 15:02:59 GMT Subject: RFR: 8373343: C2: verify AddP base input only set for heap addresses [v4] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 11:48:13 GMT, Christian Hagedorn 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 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/90d0a72d...b20f41db > > Update looks good! Let me this another spin in our testing. @chhagedorn do you have an update regarding the testing you started last week? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28769#issuecomment-3749970175 From eosterlund at openjdk.org Wed Jan 14 15:11:35 2026 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 14 Jan 2026 15:11:35 GMT Subject: RFR: 8375297: ZGC: Remove obsolete O_CLOEXEC definition In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 12:14:06 GMT, Jonas Norlinder wrote: > With [JDK-8375006](https://bugs.openjdk.org/browse/JDK-8375006) integrated we are no longer supporting building with on a system with kernel headers < 2.6.23 and glibc < 2.7. Marked as reviewed by eosterlund (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29230#pullrequestreview-3661218087 From duke at openjdk.org Wed Jan 14 15:11:36 2026 From: duke at openjdk.org (duke) Date: Wed, 14 Jan 2026 15:11:36 GMT Subject: RFR: 8375297: ZGC: Remove obsolete O_CLOEXEC definition In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 12:14:06 GMT, Jonas Norlinder wrote: > With [JDK-8375006](https://bugs.openjdk.org/browse/JDK-8375006) integrated we are no longer supporting building with on a system with kernel headers < 2.6.23 and glibc < 2.7. @JonasNorlinder Your change (at version cab7cc476fe558c086ae5e16b0ed9616b52fc801) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29230#issuecomment-3750003824 From eosterlund at openjdk.org Wed Jan 14 15:30:39 2026 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 14 Jan 2026 15:30:39 GMT Subject: RFR: 8367319: Add os interfaces to get machine and container values separately [v7] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 10:44:25 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> The current `os::` layer on Linux hides whether the JVM is running inside a container or not. When running inside a container, we replace machine values with container values where applicable, without telling the user of these methods. For most use cases, this is fine, users only care about the returned value. But for other use cases, where the value originated is important. Two examples: >> >> - A user might need the physical cpu count of the machine, but `os::active_processor_count()` only returns the limited container value, which also represents something slightly different. >> - A user might want the container memory limit and the physical RAM size, but `os::physical_memory()` only gives one number. >> >> To solve this, every function that mixed container/machine values now has to explicit variants, prefixed with `machine_` and `container_`. These use the bool return + out-parameter interface, with the container functions only working on Linux. The original methods remain and continue to return the same mixed values. >> >> In addition, container-specific accessors for the memory soft limit and the memory throttle limit have been added, as these values matter when running in a containerized environment. >> >> `OSContainer::active_processor_count()` has also been changed to return `double` instead of `int`. The previous implementation rounded the quota/period ratio up to produce an integer for `os::active_processor_count()`. Now, when the value is requested directly from the new container API it makes more sense to preserve this fraction rather than rounding it up. We can thus keep the exact value for those that want it, then round it up to keep the same behavior in `os::active_processor_count()`. >> >> Testing: >> - Oracle tiers 1-5 >> - Container tests on cgroup v1 and v2 hosts. > > Casper Norrbin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - bump copyright headers > - remove duplicate comments + double type printing > - Merge branch 'master' into separate-container-machine-values > - feedback updates > - return false when no limit + removed unneeded asserts > - Merge branch 'master' into separate-container-machine-values > - Merge branch 'master' into separate-container-machine-values > - Merge branch 'master' into separate-container-machine-values > - Move methods to Machine/Container inner classes + clarifying documentation > - Merge branch 'master' into separate-container-machine-values > - ... and 2 more: https://git.openjdk.org/jdk/compare/578204f8...e2ad48d4 Marked as reviewed by eosterlund (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27646#pullrequestreview-3661323490 From kfarrell at openjdk.org Wed Jan 14 15:31:21 2026 From: kfarrell at openjdk.org (Kieran Farrell) Date: Wed, 14 Jan 2026 15:31:21 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v7] In-Reply-To: References: Message-ID: > 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: update to print java.security.Security properties ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29124/files - new: https://git.openjdk.org/jdk/pull/29124/files/db9e0e97..bb3b243c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 mbaesken at openjdk.org Wed Jan 14 15:40:21 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 14 Jan 2026 15:40:21 GMT Subject: RFR: 8375311: Some builds are missing debug helpers Message-ID: [JDK-8318834](https://bugs.openjdk.org/browse/JDK-8318834) pointed out that on linux s390x, debug builds were missing debug helpers . This happened because we enabled some time ago linktime gc (-Wl,--gc-sections in the linker flags, plus -ffunction-sections -fdata-sections in compile flags) for linux x390x by default. But potentially ltgc or similar size-optimizing options could be enabled on other platforms too, and not only debug builds could lose the debug helpers (however in non-debug builds they might be not that important). On Windows we already export the debug helper symbols, so it might be good to do this on other platforms, especially Linux, too. ------------- Commit messages: - JDK-8375311 Changes: https://git.openjdk.org/jdk/pull/29232/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29232&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375311 Stats: 6 lines in 1 file changed: 2 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29232.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29232/head:pull/29232 PR: https://git.openjdk.org/jdk/pull/29232 From mbaesken at openjdk.org Wed Jan 14 15:40:21 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 14 Jan 2026 15:40:21 GMT Subject: RFR: 8375311: Some builds are missing debug helpers In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 15:32:28 GMT, Matthias Baesken wrote: > [JDK-8318834](https://bugs.openjdk.org/browse/JDK-8318834) pointed out that on linux s390x, debug builds were missing debug helpers . > This happened because we enabled some time ago linktime gc (-Wl,--gc-sections in the linker flags, plus -ffunction-sections -fdata-sections in compile flags) for linux x390x by default. > But potentially ltgc or similar size-optimizing options could be enabled on other platforms too, and not only debug builds could lose the debug helpers (however in non-debug builds they might be not that important). > > On Windows we already export the debug helper symbols, so it might be good to do this on other platforms, especially Linux, too. Additionally I found help output for `pm(int pc)` but the coding seems to be not there so we should delete the help output. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29232#issuecomment-3750121897 From mdoerr at openjdk.org Wed Jan 14 15:51:23 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 14 Jan 2026 15:51:23 GMT Subject: RFR: 8375311: Some builds are missing debug helpers In-Reply-To: References: Message-ID: <1tg-rtNag_orVa155w0VGv3TXdRcJ9-goSWka9qdKc4=.c9665d21-6dd2-4003-9a0f-0f0e166d2797@github.com> On Wed, 14 Jan 2026 15:32:28 GMT, Matthias Baesken wrote: > [JDK-8318834](https://bugs.openjdk.org/browse/JDK-8318834) pointed out that on linux s390x, debug builds were missing debug helpers . > This happened because we enabled some time ago linktime gc (-Wl,--gc-sections in the linker flags, plus -ffunction-sections -fdata-sections in compile flags) for linux x390x by default. > But potentially ltgc or similar size-optimizing options could be enabled on other platforms too, and not only debug builds could lose the debug helpers (however in non-debug builds they might be not that important). > > On Windows we already export the debug helper symbols, so it might be good to do this on other platforms, especially Linux, too. LGTM. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29232#pullrequestreview-3661444917 From lmesnik at openjdk.org Wed Jan 14 15:56:08 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 14 Jan 2026 15:56:08 GMT Subject: RFR: 8373945: Use WB.fullGC() in ClassUnloader.unloadClass to force GC for vmTestbase tests [v5] In-Reply-To: <08JqY0tXW8Zh0cZ3NYDT4UqZMNIeVoiSLQWxX584aXk=.b3eccb34-5764-4c8b-adb0-ccdf3c778f25@github.com> References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> <08JqY0tXW8Zh0cZ3NYDT4UqZMNIeVoiSLQWxX584aXk=.b3eccb34-5764-4c8b-adb0-ccdf3c778f25@github.com> Message-ID: On Wed, 14 Jan 2026 07:55:31 GMT, SendaoYan wrote: >>> The two kinds of incorrect commets has been updated. I think i need some more time the check all the comments for the touched tests. Thanks for your reviews. >> >> All the comments in touched tests has been checked. > >> @sendaoYan Can you please update the summary of this PR and Bug and reflect the whole scope of changes. > > I have updated to title of this PR and JBS as "Use WB.fullGC() in ClassUnloader.unloadClass to force GC for vmTestbase tests". If you have better concise summary, please let me known. @sendaoYan Thank you! Waiting for integration! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28891#issuecomment-3750225072 From jnorlinder at openjdk.org Wed Jan 14 16:58:22 2026 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Wed, 14 Jan 2026 16:58:22 GMT Subject: Integrated: 8375297: ZGC: Remove obsolete O_CLOEXEC definition In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 12:14:06 GMT, Jonas Norlinder wrote: > With [JDK-8375006](https://bugs.openjdk.org/browse/JDK-8375006) integrated we are no longer supporting building with on a system with kernel headers < 2.6.23 and glibc < 2.7. This pull request has now been integrated. Changeset: 56545328 Author: Jonas Norlinder Committer: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/56545328f849c3ebf062e3ff601224084fa3b46e Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod 8375297: ZGC: Remove obsolete O_CLOEXEC definition Reviewed-by: tschatzl, eosterlund ------------- PR: https://git.openjdk.org/jdk/pull/29230 From aph at openjdk.org Wed Jan 14 18:05:16 2026 From: aph at openjdk.org (Andrew Haley) Date: Wed, 14 Jan 2026 18:05:16 GMT Subject: RFR: 8375311: Some builds are missing debug helpers In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 15:32:28 GMT, Matthias Baesken wrote: > [JDK-8318834](https://bugs.openjdk.org/browse/JDK-8318834) pointed out that on linux s390x, debug builds were missing debug helpers . > This happened because we enabled some time ago linktime gc (-Wl,--gc-sections in the linker flags, plus -ffunction-sections -fdata-sections in compile flags) for linux x390x by default. > But potentially ltgc or similar size-optimizing options could be enabled on other platforms too, and not only debug builds could lose the debug helpers (however in non-debug builds they might be not that important). > > On Windows we already export the debug helper symbols, so it might be good to do this on other platforms, especially Linux, too. Thanks. ------------- Marked as reviewed by aph (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29232#pullrequestreview-3662068417 From aph at openjdk.org Wed Jan 14 18:08:54 2026 From: aph at openjdk.org (Andrew Haley) Date: Wed, 14 Jan 2026 18:08:54 GMT Subject: RFR: 8375311: Some builds are missing debug helpers In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 15:32:28 GMT, Matthias Baesken wrote: > But potentially ltgc or similar size-optimizing options could be enabled on other platforms too, and not only debug builds could lose the debug helpers (however in non-debug builds they might be not that important). I've had to debug non-debug builds before. It's hard, but not impossible. We should think pretty carefully about losing things useful to debugging for the sake of somewhat smaller binaries. In particular, `dump()` and `print()` virtual functions are often used. We might still decide to use LTO in some way, but any decision needs a full discussion among HotSpot maintainers. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29232#issuecomment-3750919941 From aph at openjdk.org Wed Jan 14 19:12:11 2026 From: aph at openjdk.org (Andrew Haley) Date: Wed, 14 Jan 2026 19:12:11 GMT Subject: RFR: 8375311: Some builds are missing debug helpers In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 15:32:28 GMT, Matthias Baesken wrote: > [JDK-8318834](https://bugs.openjdk.org/browse/JDK-8318834) pointed out that on linux s390x, debug builds were missing debug helpers . > This happened because we enabled some time ago linktime gc (-Wl,--gc-sections in the linker flags, plus -ffunction-sections -fdata-sections in compile flags) for linux x390x by default. > But potentially ltgc or similar size-optimizing options could be enabled on other platforms too, and not only debug builds could lose the debug helpers (however in non-debug builds they might be not that important). > > On Windows we already export the debug helper symbols, so it might be good to do this on other platforms, especially Linux, too. This is a string of volatile stores. It'd be nice to get it fixed too. 2.94% ? ? ?????? 0x0000ffff35382988: movz w0, #0, lsl #16 1.26% ? ? ??? 0x0000ffff3538298c: dmb ish 4.04% ? ? ??? 0x0000ffff35382990: str w0, [x1, #0xc] ? ? ??? 0x0000ffff35382994: dmb ish ;*putfield intField1 {reexecute=0 rethrow=0 return_oop=0} ? ? ??? ; - org.openjdk.bench.vm.compiler.PostAllocationStores$TestWithNullVolatileStores::<init>@21 (line 120) 4.41% ? ? ??? 0x0000ffff35382998: movz w0, #0, lsl #16 ? ? ??? 0x0000ffff3538299c: dmb ish 3.14% ? ? ??? 0x0000ffff353829a0: str w0, [x1, #0x18] ? ? ??? 0x0000ffff353829a4: dmb ish ;*putfield intField2 {reexecute=0 rethrow=0 return_oop=0} ? ? ??? ; - org.openjdk.bench.vm.compiler.PostAllocationStores$TestWithNullVolatileStores::<init>@26 (line 121) 2.91% ? ? ??? 0x0000ffff353829a8: mov x0, #0 ? ? ??? 0x0000ffff353829ac: dmb ish 1.75% ? ? ??? 0x0000ffff353829b0: str x0, [x1, #0x10] ? ? ??? 0x0000ffff353829b4: dmb ish ;*putfield longField1 {reexecute=0 rethrow=0 return_oop=0} ? ? ??? ; - org.openjdk.bench.vm.compiler.PostAllocationStores$TestWithNullVolatileStores::<in ------------- PR Comment: https://git.openjdk.org/jdk/pull/29232#issuecomment-3751164654 From shade at openjdk.org Wed Jan 14 19:18:10 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 14 Jan 2026 19:18:10 GMT Subject: RFR: 8375046: C2: Assertion failed in GrowableArray::remove_till(0) [v4] In-Reply-To: <_tSvASngm2bL0X2wavXI63kJZoypsY5S-dus_KGhs18=.ace489be-48bf-4254-a88e-b4fe456edf02@github.com> References: <_tSvASngm2bL0X2wavXI63kJZoypsY5S-dus_KGhs18=.ace489be-48bf-4254-a88e-b4fe456edf02@github.com> Message-ID: > Seen this assert in stress CTW runs: > > > # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/utilities/growableArray.hpp:498), pid=2972347, tid=2973775 > # assert(start < end && end <= this->_len) failed: erase called with invalid range (0, 0) for length 0 > > Stack: [0x00007fd660bea000,0x00007fd660cea000], sp=0x00007fd660ce4fc0, free space=1003k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0xc00a41] Compile::inline_incrementally_one()+0x801 (growableArray.hpp:498) > V [libjvm.so+0xc01650] Compile::inline_incrementally(PhaseIterGVN&)+0x2f0 (compile.cpp:2212) > V [libjvm.so+0xc04581] Compile::Optimize()+0x7d1 (compile.cpp:2357) > > > It looks innocuous, as `GrowableArray::remove_range` does nothing real on `[0, 0)`. It is still IMO a bug to call it with `[0, 0)`, as it is not clear whether to trust inclusive or exclusive boundary. But for `remove_till`, it looks plausible that `remove_till(0)` should work and be a no-op. Looks like it readily happens in C2 CTW when `_late_inlines` is empty. > > Additional testing: > - [x] Linux x86_64 server fastdebug, additional new gtest to verify `remove_range` works > - [x] Linux x86_64 server fastdebug, `all` Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Leave only the C2 fix - Merge branch 'master' into JDK-8375046-growable-array-till-zero - Only clear pos when needed - Handle the C2 side by removing/inlining remove_till - No trailing comma - Fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29171/files - new: https://git.openjdk.org/jdk/pull/29171/files/3f687702..d08cb656 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29171&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29171&range=02-03 Stats: 18314 lines in 192 files changed: 10247 ins; 4621 del; 3446 mod Patch: https://git.openjdk.org/jdk/pull/29171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29171/head:pull/29171 PR: https://git.openjdk.org/jdk/pull/29171 From iveresov at openjdk.org Wed Jan 14 19:26:04 2026 From: iveresov at openjdk.org (Igor Veresov) Date: Wed, 14 Jan 2026 19:26:04 GMT Subject: RFR: 8373114: Redundant MethodCounters in the preimage generated by training run [v3] In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 02:39:41 GMT, Ashutosh Mehra wrote: >> Details are mentioned in the bug report and this mail thread https://mail.openjdk.org/pipermail/leyden-dev/2025-December/002843.html >> After this patch the number of MethodCounters in the preimage are much less than before this patch. Also the number of MethodCounters in the preimage is the same as in the final AOTCache (these numbers are obtained using -Xlog:aot=trace). >> >> Before this patch for the training run: >> >> [18.610s][debug ][aot ] ro_cnt ro_bytes % | rw_cnt rw_bytes % | all_cnt all_bytes % >> [18.610s][debug ][aot ] MethodCounters : 0 0 0.0 | 22471 1438144 6.2 | 22471 1438144 2.6 >> >> Before this patch for the assembly phase: >> >> [6.680s][debug][aot ] ro_cnt ro_bytes % | rw_cnt rw_bytes % | all_cnt all_bytes % >> [6.680s][debug][aot ] MethodCounters : 0 0 0.0 | 8588 549632 2.5 | 8588 549632 1.0 >> >> >> After this patch for the training run: >> >> [49.371s][debug ][aot ] ro_cnt ro_bytes % | rw_cnt rw_bytes % | all_cnt all_bytes % >> [49.371s][debug ][aot ] MethodTrainingData : 0 0 0.0 | 4658 521696 2.1 | 4658 521696 0.9 >> >> >> After this patch for the assembly phase: >> >> [12.580s][debug][aot ] ro_cnt ro_bytes % | rw_cnt rw_bytes % | all_cnt all_bytes % >> [12.580s][debug][aot ] MethodTrainingData : 0 0 0.0 | 4658 521696 2.1 | 4658 521696 0.9 > > Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: > > Remove blank line > > Signed-off-by: Ashutosh Mehra Looks good. ------------- Marked as reviewed by iveresov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28670#pullrequestreview-3662388661 From kvn at openjdk.org Wed Jan 14 19:58:19 2026 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 14 Jan 2026 19:58:19 GMT Subject: RFR: 8373114: Redundant MethodCounters in the preimage generated by training run [v3] In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 02:39:41 GMT, Ashutosh Mehra wrote: >> Details are mentioned in the bug report and this mail thread https://mail.openjdk.org/pipermail/leyden-dev/2025-December/002843.html >> After this patch the number of MethodCounters in the preimage are much less than before this patch. Also the number of MethodCounters in the preimage is the same as in the final AOTCache (these numbers are obtained using -Xlog:aot=trace). >> >> Before this patch for the training run: >> >> [18.610s][debug ][aot ] ro_cnt ro_bytes % | rw_cnt rw_bytes % | all_cnt all_bytes % >> [18.610s][debug ][aot ] MethodCounters : 0 0 0.0 | 22471 1438144 6.2 | 22471 1438144 2.6 >> >> Before this patch for the assembly phase: >> >> [6.680s][debug][aot ] ro_cnt ro_bytes % | rw_cnt rw_bytes % | all_cnt all_bytes % >> [6.680s][debug][aot ] MethodCounters : 0 0 0.0 | 8588 549632 2.5 | 8588 549632 1.0 >> >> >> After this patch for the training run: >> >> [49.371s][debug ][aot ] ro_cnt ro_bytes % | rw_cnt rw_bytes % | all_cnt all_bytes % >> [49.371s][debug ][aot ] MethodTrainingData : 0 0 0.0 | 4658 521696 2.1 | 4658 521696 0.9 >> >> >> After this patch for the assembly phase: >> >> [12.580s][debug][aot ] ro_cnt ro_bytes % | rw_cnt rw_bytes % | all_cnt all_bytes % >> [12.580s][debug][aot ] MethodTrainingData : 0 0 0.0 | 4658 521696 2.1 | 4658 521696 0.9 > > Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: > > Remove blank line > > Signed-off-by: Ashutosh Mehra src/hotspot/share/oops/trainingData.cpp line 122: > 120: MethodTrainingData* MethodTrainingData::make(const methodHandle& method, bool null_if_not_found, bool use_cache) { > 121: MethodTrainingData* mtd = nullptr; > 122: if ((!have_data() && !need_data()) || (assembling_data() && !CDSConfig::is_at_aot_safepoint())) { @ashu-mehra and @veresov from what I see `MethodTrainingData::make()` should be called only during training run when CTD is set: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/compileBroker.cpp#L356C21-L356C30 Am I missing path where it is called in assembly phase or production? `need_data()` is true only during training: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/oops/trainingData.hpp#L290 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28670#discussion_r2691838019 From kvn at openjdk.org Wed Jan 14 20:07:13 2026 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 14 Jan 2026 20:07:13 GMT Subject: RFR: 8374926: EnableX86ECoreOpts was not enabled on some hybrid CPU [v3] In-Reply-To: References: Message-ID: On Sun, 11 Jan 2026 07:46:33 GMT, Yasumasa Suenaga wrote: >> `EnableX86ECoreOpts` has been introduced in [JDK-8319429](https://bugs.openjdk.org/browse/JDK-8319429), however model numbers which should be enabled are hard-coded, so the flag would not be enabled by default on some models like Arrow Lake. >> >> I ran a [benchmark](https://github.com/YaSuenag/garakuta/tree/master/randminmax) to check for effectiveness of `-XX:+EnableX86ECoreOpts` with JDK 25.0.1 on Windows 11 25H2, I saw performance improvement a bit on Intel Core 5 Ultra 225U as following: >> >> Disabled (default) >> >> Benchmark Mode Cnt Score Error Units >> RandMinVal.getMax thrpt 3 9707774.405 ? 27082629.015 ops/s >> RandMinVal.getMin thrpt 3 7510319.839 ? 10923547.382 ops/s >> >> >> Enabled >> >> Benchmark Mode Cnt Score Error Units >> RandMinVal.getMax thrpt 3 10127809.127 ? 45404142.338 ops/s >> RandMinVal.getMin thrpt 3 8467677.056 ? 1211998.200 ops/s >> >> >> So I think it is better to enable this flag by default on all of hybrid CPUs. >> >> >> To check what processor would be enabled E-core optimization, I made a [commit](https://github.com/openjdk/jdk/commit/f363ea1436b8100021fdac87b48ec43bcf6820af) to add comments for CPU models at first. I couldn't find out all of models (some models has not listed in SDM vol.4 so far), but most of models (excepts Sierra Forest) could be treated as hybrid CPU. Fortunately HotSpot identify hybrid flag from `CPUID`, so we can leverage it for this purpose. > > Yasumasa Suenaga 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 four additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into ecoreopt-hybrid > - Merge remote-tracking branch 'origin/master' into ecoreopt-hybrid > - Use supports_hybrid() to check for EnableX86ECoreOpts > - Add comments for CPU models @vpaprotsk, as author of [JDK-8319429](https://bugs.openjdk.org/browse/JDK-8319429) please look on this change. May be you can give suggestion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29149#issuecomment-3751493564 From iveresov at openjdk.org Wed Jan 14 21:00:17 2026 From: iveresov at openjdk.org (Igor Veresov) Date: Wed, 14 Jan 2026 21:00:17 GMT Subject: RFR: 8373114: Redundant MethodCounters in the preimage generated by training run [v3] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 19:54:59 GMT, Vladimir Kozlov wrote: >> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove blank line >> >> Signed-off-by: Ashutosh Mehra > > src/hotspot/share/oops/trainingData.cpp line 122: > >> 120: MethodTrainingData* MethodTrainingData::make(const methodHandle& method, bool null_if_not_found, bool use_cache) { >> 121: MethodTrainingData* mtd = nullptr; >> 122: if ((!have_data() && !need_data()) || (assembling_data() && !CDSConfig::is_at_aot_safepoint())) { > > @ashu-mehra and @veresov from what I see `MethodTrainingData::make()` should be called only during training run when CTD is set: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/compileBroker.cpp#L356C21-L356C30 > > Am I missing path where it is called in assembly phase or production? > > `need_data()` is true only during training: > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/oops/trainingData.hpp#L290 During assembly we have `have_data()` return true, and since we're running some java code this will make us cache MTDs in MCs. That's what I think this code is trying to avoid. But I have a question though. Why do we treat the presence of the cache MTD value in MC as a proof that MTD refers to a MC? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28670#discussion_r2692024222 From vlivanov at openjdk.org Wed Jan 14 21:02:28 2026 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 14 Jan 2026 21:02:28 GMT Subject: RFR: 8375046: C2: Assertion failed in GrowableArray::remove_till(0) [v4] In-Reply-To: References: <_tSvASngm2bL0X2wavXI63kJZoypsY5S-dus_KGhs18=.ace489be-48bf-4254-a88e-b4fe456edf02@github.com> Message-ID: On Wed, 14 Jan 2026 19:18:10 GMT, Aleksey Shipilev wrote: >> Seen this assert in stress CTW runs: >> >> >> # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/utilities/growableArray.hpp:498), pid=2972347, tid=2973775 >> # assert(start < end && end <= this->_len) failed: erase called with invalid range (0, 0) for length 0 >> >> Stack: [0x00007fd660bea000,0x00007fd660cea000], sp=0x00007fd660ce4fc0, free space=1003k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0xc00a41] Compile::inline_incrementally_one()+0x801 (growableArray.hpp:498) >> V [libjvm.so+0xc01650] Compile::inline_incrementally(PhaseIterGVN&)+0x2f0 (compile.cpp:2212) >> V [libjvm.so+0xc04581] Compile::Optimize()+0x7d1 (compile.cpp:2357) >> >> >> It looks innocuous, as `GrowableArray::remove_range` does nothing real on `[0, 0)`. It is still IMO a bug to call it with `[0, 0)`, as it is not clear whether to trust inclusive or exclusive boundary. But for `remove_till`, it looks plausible that `remove_till(0)` should work and be a no-op. Looks like it readily happens in C2 CTW when `_late_inlines` is empty. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, additional new gtest to verify `remove_range` works >> - [x] Linux x86_64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Leave only the C2 fix > - Merge branch 'master' into JDK-8375046-growable-array-till-zero > - Only clear pos when needed > - Handle the C2 side by removing/inlining remove_till > - No trailing comma > - Fix The code implicitly assumes that `_late_inlines` is not empty and it's a reasonable assumption. Any particular reason to handle empty case instead of finishing early? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29171#issuecomment-3751692289 From kvn at openjdk.org Wed Jan 14 21:44:29 2026 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 14 Jan 2026 21:44:29 GMT Subject: RFR: 8373114: Redundant MethodCounters in the preimage generated by training run [v3] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 20:56:55 GMT, Igor Veresov wrote: >> src/hotspot/share/oops/trainingData.cpp line 122: >> >>> 120: MethodTrainingData* MethodTrainingData::make(const methodHandle& method, bool null_if_not_found, bool use_cache) { >>> 121: MethodTrainingData* mtd = nullptr; >>> 122: if ((!have_data() && !need_data()) || (assembling_data() && !CDSConfig::is_at_aot_safepoint())) { >> >> @ashu-mehra and @veresov from what I see `MethodTrainingData::make()` should be called only during training run when CTD is set: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/compileBroker.cpp#L356C21-L356C30 >> >> Am I missing path where it is called in assembly phase or production? >> >> `need_data()` is true only during training: >> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/oops/trainingData.hpp#L290 > > During assembly we have `have_data()` return true, and since we're running some java code this will make us cache MTDs in MCs. That's what I think this code is trying to avoid. > > But I have a question though. Why do we treat the presence of the cache MTD value in MC as a proof that MTD refers to a MC? I am referencing `need_data()` in `compileBroker.cpp` code which set CTD: if (TrainingData::need_data() && !CDSConfig::is_dumping_final_static_archive()) { CompileTrainingData* ctd = CompileTrainingData::make(task); if (ctd != nullptr) { task->set_training_data(ctd); I see we check CTD in places where we call `MethodTrainingData::make()`. That is why I assumed that it is called only during training run. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28670#discussion_r2692151846 From kbarrett at openjdk.org Wed Jan 14 22:41:25 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 14 Jan 2026 22:41:25 GMT Subject: RFR: 8375046: C2: Assertion failed in GrowableArray::remove_till(0) [v4] In-Reply-To: References: <_tSvASngm2bL0X2wavXI63kJZoypsY5S-dus_KGhs18=.ace489be-48bf-4254-a88e-b4fe456edf02@github.com> Message-ID: On Wed, 14 Jan 2026 19:18:10 GMT, Aleksey Shipilev wrote: >> Seen this assert in stress CTW runs: >> >> >> # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/utilities/growableArray.hpp:498), pid=2972347, tid=2973775 >> # assert(start < end && end <= this->_len) failed: erase called with invalid range (0, 0) for length 0 >> >> Stack: [0x00007fd660bea000,0x00007fd660cea000], sp=0x00007fd660ce4fc0, free space=1003k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0xc00a41] Compile::inline_incrementally_one()+0x801 (growableArray.hpp:498) >> V [libjvm.so+0xc01650] Compile::inline_incrementally(PhaseIterGVN&)+0x2f0 (compile.cpp:2212) >> V [libjvm.so+0xc04581] Compile::Optimize()+0x7d1 (compile.cpp:2357) >> >> >> It looks innocuous, as `GrowableArray::remove_range` does nothing real on `[0, 0)`. It is still IMO a bug to call it with `[0, 0)`, as it is not clear whether to trust inclusive or exclusive boundary. But for `remove_till`, it looks plausible that `remove_till(0)` should work and be a no-op. Looks like it readily happens in C2 CTW when `_late_inlines` is empty. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, additional new gtest to verify `remove_range` works >> - [x] Linux x86_64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Leave only the C2 fix > - Merge branch 'master' into JDK-8375046-growable-array-till-zero > - Only clear pos when needed > - Handle the C2 side by removing/inlining remove_till > - No trailing comma > - Fix Changes requested by kbarrett (Reviewer). src/hotspot/share/opto/compile.cpp line 2148: > 2146: _late_inlines_pos = 0; > 2147: } > 2148: assert(_late_inlines_pos == 0, "sanity"); The bug is the assert in `GrowableArray::remove_range`. The argument to `remove_till` is explicitly documented as exclusive. And the arguments for `remove_range` are explicitly documented as being the range "[start, end)". And that's how it's implemented. Except for the assert. So I think that assert should be fixed, and the original code here is correct and shouldn't be modified. ------------- PR Review: https://git.openjdk.org/jdk/pull/29171#pullrequestreview-3663142508 PR Review Comment: https://git.openjdk.org/jdk/pull/29171#discussion_r2692314092 From iveresov at openjdk.org Wed Jan 14 23:04:21 2026 From: iveresov at openjdk.org (Igor Veresov) Date: Wed, 14 Jan 2026 23:04:21 GMT Subject: RFR: 8373114: Redundant MethodCounters in the preimage generated by training run [v3] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 21:40:49 GMT, Vladimir Kozlov wrote: >> During assembly we have `have_data()` return true, and since we're running some java code this will make us cache MTDs in MCs. That's what I think this code is trying to avoid. >> >> But I have a question though. Why do we treat the presence of the cache MTD value in MC as a proof that MTD refers to a MC? > > I am referencing `need_data()` in `compileBroker.cpp` code which set CTD: > > if (TrainingData::need_data() && !CDSConfig::is_dumping_final_static_archive()) { > CompileTrainingData* ctd = CompileTrainingData::make(task); > if (ctd != nullptr) { > task->set_training_data(ctd); > > > I see we check CTD in places where we call `MethodTrainingData::make()`. That is why I assumed that it is called only during training run. The main user of the cached lookups is `MethodTrainingData* mtd = MethodTrainingData::find_fast(mh);` in `compilationPolicy.cpp:1024`. It's going to be called on every tiered event if `have_data() == true`. That's likely the main source of the MC pollution he's trying to avoid. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28670#discussion_r2692370659 From kvn at openjdk.org Thu Jan 15 00:36:01 2026 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 15 Jan 2026 00:36:01 GMT Subject: RFR: 8373114: Redundant MethodCounters in the preimage generated by training run [v3] In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 02:39:41 GMT, Ashutosh Mehra wrote: >> Details are mentioned in the bug report and this mail thread https://mail.openjdk.org/pipermail/leyden-dev/2025-December/002843.html >> After this patch the number of MethodCounters in the preimage are much less than before this patch. Also the number of MethodCounters in the preimage is the same as in the final AOTCache (these numbers are obtained using -Xlog:aot=trace). >> >> Before this patch for the training run: >> >> [18.610s][debug ][aot ] ro_cnt ro_bytes % | rw_cnt rw_bytes % | all_cnt all_bytes % >> [18.610s][debug ][aot ] MethodCounters : 0 0 0.0 | 22471 1438144 6.2 | 22471 1438144 2.6 >> >> Before this patch for the assembly phase: >> >> [6.680s][debug][aot ] ro_cnt ro_bytes % | rw_cnt rw_bytes % | all_cnt all_bytes % >> [6.680s][debug][aot ] MethodCounters : 0 0 0.0 | 8588 549632 2.5 | 8588 549632 1.0 >> >> >> After this patch for the training run: >> >> [49.371s][debug ][aot ] ro_cnt ro_bytes % | rw_cnt rw_bytes % | all_cnt all_bytes % >> [49.371s][debug ][aot ] MethodTrainingData : 0 0 0.0 | 4658 521696 2.1 | 4658 521696 0.9 >> >> >> After this patch for the assembly phase: >> >> [12.580s][debug][aot ] ro_cnt ro_bytes % | rw_cnt rw_bytes % | all_cnt all_bytes % >> [12.580s][debug][aot ] MethodTrainingData : 0 0 0.0 | 4658 521696 2.1 | 4658 521696 0.9 > > Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: > > Remove blank line > > Signed-off-by: Ashutosh Mehra Marked as reviewed by kvn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28670#pullrequestreview-3663407195 From kvn at openjdk.org Thu Jan 15 00:36:03 2026 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 15 Jan 2026 00:36:03 GMT Subject: RFR: 8373114: Redundant MethodCounters in the preimage generated by training run [v3] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 23:00:29 GMT, Igor Veresov wrote: >> I am referencing `need_data()` in `compileBroker.cpp` code which set CTD: >> >> if (TrainingData::need_data() && !CDSConfig::is_dumping_final_static_archive()) { >> CompileTrainingData* ctd = CompileTrainingData::make(task); >> if (ctd != nullptr) { >> task->set_training_data(ctd); >> >> >> I see we check CTD in places where we call `MethodTrainingData::make()`. That is why I assumed that it is called only during training run. > > The main user of the cached lookups is `MethodTrainingData* mtd = MethodTrainingData::find_fast(mh);` in `compilationPolicy.cpp:1024`. It's going to be called on every tiered event if `have_data() == true`. That's likely the main source of the MC pollution he's trying to avoid. Thank you, that is what I missed. `find()` and find_fast()` call `make()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28670#discussion_r2692535655 From ghan at openjdk.org Thu Jan 15 00:42:21 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 15 Jan 2026 00:42:21 GMT Subject: RFR: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) [v6] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 02:04:51 GMT, David Holmes wrote: >> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: >> >> fix a compile error > > I think this looks like a good solution. I flagged the compiler folk as I'm unsure about the test location - but I see it is where the only other test that uses `PrintDeoptimizationDetails` exists. > > One small change requested (while you await the second review). > > Thanks Hi @dholmes-ora @dean-long, thanks for the suggestion. I?ve made the changes,could you please take another look? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29186#issuecomment-3752341939 From duke at openjdk.org Thu Jan 15 02:24:35 2026 From: duke at openjdk.org (duke) Date: Thu, 15 Jan 2026 02:24:35 GMT Subject: Withdrawn: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching In-Reply-To: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: On Wed, 30 Jul 2025 17:34:48 GMT, Andrew Haley wrote: > In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. > > Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. > > This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. > > The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. > > We mark all sites that we know will write to code memory with > `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. > > We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. > > It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. > > One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude, and it's better to be able to ... This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/26562 From syan at openjdk.org Thu Jan 15 02:47:18 2026 From: syan at openjdk.org (SendaoYan) Date: Thu, 15 Jan 2026 02:47:18 GMT Subject: RFR: 8373945: Use WB.fullGC() in ClassUnloader.unloadClass to force GC for vmTestbase tests [v11] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: On Tue, 23 Dec 2025 15:45:42 GMT, Chris Plummer wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> Update commnets for ClassUnloader > > Something strange is going on with this PR. I just got 3 separate emails for each of the following commits that were done in the past day: > > - [Fix the copy-n-paste error](https://github.com/openjdk/jdk/pull/28891/changes/349ae833fb600ab9136ab4f43749d1e5f2c84ca0) > - [Update commnets for ClassUnloader](https://github.com/openjdk/jdk/pull/28891/changes/6c144309a091038aaed1d698bd12323f3672c7b9) > - [Remove unnecessary catch OOME in gc/gctests/LargeObjects/large001/large001.java](https://github.com/openjdk/jdk/pull/28891/changes/e8d128e666ee0a8cbbf6d9dc273636b62bd3fb96) > > However, the PR claims that these commits were all done on Nov 22, not Dec. Thanks for the suggestions and reviews @plummercj @lmesnik. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28891#issuecomment-3752622327 From syan at openjdk.org Thu Jan 15 02:50:03 2026 From: syan at openjdk.org (SendaoYan) Date: Thu, 15 Jan 2026 02:50:03 GMT Subject: Integrated: 8373945: Use WB.fullGC() in ClassUnloader.unloadClass to force GC for vmTestbase tests In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: On Thu, 18 Dec 2025 08:26:44 GMT, SendaoYan wrote: > Hi all, > > This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. > > Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. > > Additional testing: > > - [x] All jtreg tests by fastdebug build This pull request has now been integrated. Changeset: ce5e0d8a Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/ce5e0d8a48296b51c9c2eff4867e2a9a70194091 Stats: 421 lines in 62 files changed: 206 ins; 97 del; 118 mod 8373945: Use WB.fullGC() in ClassUnloader.unloadClass to force GC for vmTestbase tests Reviewed-by: cjplummer, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/28891 From dholmes at openjdk.org Thu Jan 15 05:37:27 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 Jan 2026 05:37:27 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v5] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Tue, 13 Jan 2026 20:44:37 GMT, Larry Cable 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: changes as per @dholmes and @kwalls Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29048#pullrequestreview-3664017313 From syan at openjdk.org Thu Jan 15 05:52:36 2026 From: syan at openjdk.org (SendaoYan) Date: Thu, 15 Jan 2026 05:52:36 GMT Subject: RFR: 8374807: Crash in MethodData::extra_data_lock()+0x0 when running -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp -version In-Reply-To: References: Message-ID: <8c8QLPcy701RGF_uMOjert2_G9bYg6c6EDrWhe3rFcA=.a1add9ea-7189-4002-b913-a343f4752841@github.com> On Sat, 10 Jan 2026 00:08:12 GMT, Guanqiang Han wrote: > Please review this change. Thanks! > > Description: > > This change fixes a crash in Deoptimization::uncommon_trap_inner when running with -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp. > > With -XX:-ProfileTraps, create_if_missing is set to false. > https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L2121-L2122 > > When create_if_missing is false, new mdo can not be created when m()->method_data() return null, so get_method_data() may return null . > https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L1911-L1912 > > and trap_mdo can be null as a result > https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L2134-L2136 > > The crash happens here because trap_mdo is null > https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L2157 > > Fix: > > The fix makes acquisition of extra_data_lock conditional on trap_mdo being non-null, preserving the required lock ordering (extra_data_lock before ttyLocker) when an MDO exists. > > Test: > > GHA test/hotspot/jtreg/compiler/uncommontrap/TestPrintDiagnosticsWithoutProfileTraps.java line 29: > 27: * @summary Regression test for -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp crash > 28: * @requires vm.debug > 29: * @run main/othervm -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp compiler.uncommontrap.TestPrintDiagnosticsWithoutProfileTraps Should we split this line to two or three lines. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29147#discussion_r2693077929 From dholmes at openjdk.org Thu Jan 15 06:40:39 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 Jan 2026 06:40:39 GMT Subject: RFR: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) [v6] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 13:56:46 GMT, Guanqiang Han wrote: >> Please review this change. Thanks! >> >> **Description:** >> >> When -XX:+PrintDeoptimizationDetails is enabled, vframeArray.cpp prints interpreted frames under ttyLocker. >> https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/runtime/vframeArray.cpp#L493-L503 >> In the WizardMode && Verbose branch it calls Method::print_codes() / print_codes_on(). The bytecode printing path may acquire MDOExtraData_lock (rank nosafepoint-1). >> https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/interpreter/bytecodeTracer.cpp#L597-L602 >> Calling it while holding tty_lock violates the global lock ranking order and triggers a lock rank inversion assertion. >> >> **Fix:** >> >> Generate the bytecode dump before taking tty_lock, and print it afterwards under ttyLocker to keep the output coherent while preserving correct lock acquisition order. >> To avoid double buffering when the target stream is already a thread-local stringStream, extend BytecodeTracer::print_method_codes with a buffered flag . The new call site uses buffered=false when dumping into the temporary stringStream. >> >> **Test:** >> >> GHA > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > fix a compile error src/hotspot/share/utilities/ostream.hpp line 289: > 287: char* as_string(bool c_heap = false) const; > 288: char* as_string(Arena* arena) const; > 289: bool is_buffered() const { return true; } Suggestion: bool is_buffered() const override { return true; } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29186#discussion_r2693164755 From dholmes at openjdk.org Thu Jan 15 06:53:23 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 Jan 2026 06:53:23 GMT Subject: RFR: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) [v6] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 13:56:46 GMT, Guanqiang Han wrote: >> Please review this change. Thanks! >> >> **Description:** >> >> When -XX:+PrintDeoptimizationDetails is enabled, vframeArray.cpp prints interpreted frames under ttyLocker. >> https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/runtime/vframeArray.cpp#L493-L503 >> In the WizardMode && Verbose branch it calls Method::print_codes() / print_codes_on(). The bytecode printing path may acquire MDOExtraData_lock (rank nosafepoint-1). >> https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/interpreter/bytecodeTracer.cpp#L597-L602 >> Calling it while holding tty_lock violates the global lock ranking order and triggers a lock rank inversion assertion. >> >> **Fix:** >> >> Generate the bytecode dump before taking tty_lock, and print it afterwards under ttyLocker to keep the output coherent while preserving correct lock acquisition order. >> To avoid double buffering when the target stream is already a thread-local stringStream, extend BytecodeTracer::print_method_codes with a buffered flag . The new call site uses buffered=false when dumping into the temporary stringStream. >> >> **Test:** >> >> GHA > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > fix a compile error src/hotspot/share/utilities/ostream.hpp line 162: > 160: virtual ~outputStream() {} // close properly on deletion > 161: // Return true if this stream buffers/accumulates output in memory (e.g., stringStream) > 162: virtual bool is_buffered() const { return false; } Really you are using this as a proxy for "do I have a stringStream?" and it doesn't quite work because we also have a `bufferedStream` class that you have not marked as buffered - though I'm not sure the "buffering" in the two cases is actually the same thing. @dean-long you made this suggestion so how do you see `is_buffered` fitting in to the whole stream hierarchy? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29186#discussion_r2693188249 From ghan at openjdk.org Thu Jan 15 06:57:53 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 15 Jan 2026 06:57:53 GMT Subject: RFR: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) [v6] In-Reply-To: References: Message-ID: <4S_zPFzylTWkeSFvL5g3It1MQbcGfPYYzL-_lhWf87Y=.67f070b4-f3f1-4709-904d-a933a74f9372@github.com> On Thu, 15 Jan 2026 06:37:34 GMT, David Holmes wrote: >> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: >> >> fix a compile error > > src/hotspot/share/utilities/ostream.hpp line 289: > >> 287: char* as_string(bool c_heap = false) const; >> 288: char* as_string(Arena* arena) const; >> 289: bool is_buffered() const { return true; } > > Suggestion: > > bool is_buffered() const override { return true; } I originally added override to is_buffered(), but on macOS the build fails with -Werror -Winconsistent-missing-override. In ostream.hpp, the existing implementations of virtual functions also do not use override, so adding override only to is_buffered() makes the class inconsistent and triggers the warning. I removed it to keep consistency with the current style and avoid the macOS build break. Do you still want me to add override back (and then update the other overridden methods in this class accordingly) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29186#discussion_r2693199895 From ghan at openjdk.org Thu Jan 15 07:23:44 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 15 Jan 2026 07:23:44 GMT Subject: RFR: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) [v6] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 06:49:55 GMT, David Holmes wrote: >> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: >> >> fix a compile error > > src/hotspot/share/utilities/ostream.hpp line 162: > >> 160: virtual ~outputStream() {} // close properly on deletion >> 161: // Return true if this stream buffers/accumulates output in memory (e.g., stringStream) >> 162: virtual bool is_buffered() const { return false; } > > Really you are using this as a proxy for "do I have a stringStream?" and it doesn't quite work because we also have a `bufferedStream` class that you have not marked as buffered - though I'm not sure the "buffering" in the two cases is actually the same thing. > > @dean-long you made this suggestion so how do you see `is_buffered` fitting in to the whole stream hierarchy? I agree with the concern here. The buffering we need is local to this call site to keep the output coherent (collect everything and print once). Whether we need to buffer/accumulate output for coherence is scenario-dependent, rather than a property that should permanently classify a stream type as ?buffered? vs. ?unbuffered?. @dean-long what?s your view on this? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29186#discussion_r2693255744 From jbhateja at openjdk.org Thu Jan 15 08:56:21 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 15 Jan 2026 08:56:21 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v12] In-Reply-To: References: Message-ID: > 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. > > image > > 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 28 commits: - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 - Adding testpoint for JDK-8373574 - Review comments resolutions - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 - Fix incorrect argument passed to smokeTest - 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 - ... and 18 more: https://git.openjdk.org/jdk/compare/499b5882...273b219e ------------- Changes: https://git.openjdk.org/jdk/pull/28002/files Webrev: Webrev is not available because diff is too large Stats: 519849 lines in 228 files changed: 285040 ins; 233032 del; 1777 mod Patch: https://git.openjdk.org/jdk/pull/28002.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002 PR: https://git.openjdk.org/jdk/pull/28002 From dholmes at openjdk.org Thu Jan 15 09:20:00 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 Jan 2026 09:20:00 GMT Subject: RFR: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) [v6] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 07:21:41 GMT, Guanqiang Han wrote: >> src/hotspot/share/utilities/ostream.hpp line 162: >> >>> 160: virtual ~outputStream() {} // close properly on deletion >>> 161: // Return true if this stream buffers/accumulates output in memory (e.g., stringStream) >>> 162: virtual bool is_buffered() const { return false; } >> >> Really you are using this as a proxy for "do I have a stringStream?" and it doesn't quite work because we also have a `bufferedStream` class that you have not marked as buffered - though I'm not sure the "buffering" in the two cases is actually the same thing. >> >> @dean-long you made this suggestion so how do you see `is_buffered` fitting in to the whole stream hierarchy? > > I agree with the concern here. The buffering we need is local to this call site to keep the output coherent (collect everything and print once). > Whether we need to buffer/accumulate output for coherence is scenario-dependent, rather than a property that should permanently classify a stream type as ?buffered? vs. ?unbuffered?. > @dean-long what?s your view on this? No - sorry I forgot that you have to add override to all methods. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29186#discussion_r2693585193 From stefank at openjdk.org Thu Jan 15 09:23:07 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 15 Jan 2026 09:23:07 GMT Subject: RFR: 8375040: Clearer names for non-metadata oop iterators in ObjArrayKlass [v2] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 15:38:08 GMT, Stefan Karlsson wrote: >> During the review of [JDK-8374780](https://bugs.openjdk.org/browse/JDK-8374780) it was clear that the naming of the various oop iterators, and also their comments, were somewhat misleading about if they visited the metadata or not. >> >> I propose that we make a clear separation and have it so that all iterators that only visit the array elements are named to contain the word "elements" to make it slightly clearer that these iterators only visits the elements. >> >> So, we know how the following ObjArrayKlass oop iterators: >> >> Iterators that also visit the metadata: >> >> oop_oop_iterate >> oop_oop_iterate_reverse >> oop_oop_iterate_bounded >> >> >> Iterators that are not visiting the metadata: >> >> oop_oop_iterate_elements >> oop_oop_iterate_elements_range >> oop_oop_iterate_elements_bounded >> >> >> The objArrayOopDesc class also exposes an oop iterator and that function has been renamed to mimic the above scheme to add the `_elements` to functions that does not visit the metadata: >> >> oop_iterate_elements_range >> >> >> Two extra things to check in the patch: >> >> 1) I did some slight tweaks to the code so that `oop_oop_iterate_elements` is implemented with `oop_oop_iterate_elements_range`. >> >> 2) I moved the objArrayOopDesc function back to the oopArrayOop.inline.hpp. The reason is that we have now solved the problems with circular dependencies between .inline.hpp files, so this workaround isn't needed anymore. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/share/oops/objArrayOop.hpp > > Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com> Thanks for reviewing! I ran this through our tier1 testing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29170#issuecomment-3753717107 From stefank at openjdk.org Thu Jan 15 09:27:03 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 15 Jan 2026 09:27:03 GMT Subject: Integrated: 8375040: Clearer names for non-metadata oop iterators in ObjArrayKlass In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 14:15:57 GMT, Stefan Karlsson wrote: > During the review of [JDK-8374780](https://bugs.openjdk.org/browse/JDK-8374780) it was clear that the naming of the various oop iterators, and also their comments, were somewhat misleading about if they visited the metadata or not. > > I propose that we make a clear separation and have it so that all iterators that only visit the array elements are named to contain the word "elements" to make it slightly clearer that these iterators only visits the elements. > > So, we know how the following ObjArrayKlass oop iterators: > > Iterators that also visit the metadata: > > oop_oop_iterate > oop_oop_iterate_reverse > oop_oop_iterate_bounded > > > Iterators that are not visiting the metadata: > > oop_oop_iterate_elements > oop_oop_iterate_elements_range > oop_oop_iterate_elements_bounded > > > The objArrayOopDesc class also exposes an oop iterator and that function has been renamed to mimic the above scheme to add the `_elements` to functions that does not visit the metadata: > > oop_iterate_elements_range > > > Two extra things to check in the patch: > > 1) I did some slight tweaks to the code so that `oop_oop_iterate_elements` is implemented with `oop_oop_iterate_elements_range`. > > 2) I moved the objArrayOopDesc function back to the oopArrayOop.inline.hpp. The reason is that we have now solved the problems with circular dependencies between .inline.hpp files, so this workaround isn't needed anymore. This pull request has now been integrated. Changeset: bf0da3dd Author: Stefan Karlsson URL: https://git.openjdk.org/jdk/commit/bf0da3dd5c20410aceab8e6f7a7a31432d17b96d Stats: 62 lines in 11 files changed: 18 ins; 21 del; 23 mod 8375040: Clearer names for non-metadata oop iterators in ObjArrayKlass Reviewed-by: tschatzl, kbarrett, aboldtch ------------- PR: https://git.openjdk.org/jdk/pull/29170 From mbaesken at openjdk.org Thu Jan 15 09:31:30 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 15 Jan 2026 09:31:30 GMT Subject: RFR: 8375311: Some builds are missing debug helpers In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 19:10:08 GMT, Andrew Haley wrote: > This is a string of volatile stores. It'd be nice to get it fixed too. Wondering - is this an info for this issue !? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29232#issuecomment-3753733844 From aph at openjdk.org Thu Jan 15 09:31:32 2026 From: aph at openjdk.org (Andrew Haley) Date: Thu, 15 Jan 2026 09:31:32 GMT Subject: RFR: 8375311: Some builds are missing debug helpers In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 09:24:45 GMT, Matthias Baesken wrote: > > This is a string of volatile stores. It'd be nice to get it fixed too. > > Wondering - is this an info for this issue !? I guess it could be another issue, but to me it seems that it would make more sense to fix it here. What is to be gained by not fixing it now? It seems like the same issue to me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29232#issuecomment-3753744618 From aph at openjdk.org Thu Jan 15 09:40:25 2026 From: aph at openjdk.org (Andrew Haley) Date: Thu, 15 Jan 2026 09:40:25 GMT Subject: RFR: 8375311: Some builds are missing debug helpers In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 09:24:45 GMT, Matthias Baesken wrote: > > This is a string of volatile stores. It'd be nice to get it fixed too. > > Wondering - is this an info for this issue !? Oops. Deleted/ ------------- PR Comment: https://git.openjdk.org/jdk/pull/29232#issuecomment-3753783809 From aph at openjdk.org Thu Jan 15 09:43:07 2026 From: aph at openjdk.org (Andrew Haley) Date: Thu, 15 Jan 2026 09:43:07 GMT Subject: RFR: 8365147: AArch64: Replace DMB + LD + DMB with LDAR for C1 volatile field loads [v4] In-Reply-To: References: Message-ID: On Wed, 19 Nov 2025 12:47:18 GMT, Samuel Chee 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 This is a string of volatile stores. It'd be nice to get it fixed too. 2.94% ? ? ?????? 0x0000ffff35382988: movz w0, #0, lsl #16 1.26% ? ? ??? 0x0000ffff3538298c: dmb ish 4.04% ? ? ??? 0x0000ffff35382990: str w0, [x1, #0xc] ? ? ??? 0x0000ffff35382994: dmb ish ;*putfield intField1 {reexecute=0 rethrow=0 return_oop=0} ? ? ??? ; - org.openjdk.bench.vm.compiler.PostAllocationStores$TestWithNullVolatileStores::<init>@21 (line 120) 4.41% ? ? ??? 0x0000ffff35382998: movz w0, #0, lsl #16 ? ? ??? 0x0000ffff3538299c: dmb ish 3.14% ? ? ??? 0x0000ffff353829a0: str w0, [x1, #0x18] ? ? ??? 0x0000ffff353829a4: dmb ish ;*putfield intField2 {reexecute=0 rethrow=0 return_oop=0} ? ? ??? ; - org.openjdk.bench.vm.compiler.PostAllocationStores$TestWithNullVolatileStores::<init>@26 (line 121) 2.91% ? ? ??? 0x0000ffff353829a8: mov x0, #0 ? ? ??? 0x0000ffff353829ac: dmb ish 1.75% ? ? ??? 0x0000ffff353829b0: str x0, [x1, #0x10] ? ? ??? 0x0000ffff353829b4: dmb ish ;*putfield longField1 {reexecute=0 rethrow=0 return_oop=0} ? ? ??? ; - org.openjdk.bench.vm.compiler.PostAllocationStores$TestWithNullVolatileStores::<in ------------- PR Comment: https://git.openjdk.org/jdk/pull/26748#issuecomment-3753791741 From ghan at openjdk.org Thu Jan 15 09:55:13 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 15 Jan 2026 09:55:13 GMT Subject: RFR: 8374807: Crash in MethodData::extra_data_lock()+0x0 when running -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp -version [v2] In-Reply-To: References: Message-ID: > Please review this change. Thanks! > > Description: > > This change fixes a crash in Deoptimization::uncommon_trap_inner when running with -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp. > > With -XX:-ProfileTraps, create_if_missing is set to false. > https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L2121-L2122 > > When create_if_missing is false, new mdo can not be created when m()->method_data() return null, so get_method_data() may return null . > https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L1911-L1912 > > and trap_mdo can be null as a result > https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L2134-L2136 > > The crash happens here because trap_mdo is null > https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L2157 > > Fix: > > The fix makes acquisition of extra_data_lock conditional on trap_mdo being non-null, preserving the required lock ordering (extra_data_lock before ttyLocker) when an MDO exists. > > Test: > > GHA Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - split long line - Merge remote-tracking branch 'upstream/master' into 8374807 - fix 8374807 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29147/files - new: https://git.openjdk.org/jdk/pull/29147/files/e22b4098..9445014e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29147&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29147&range=00-01 Stats: 32340 lines in 473 files changed: 20787 ins; 6752 del; 4801 mod Patch: https://git.openjdk.org/jdk/pull/29147.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29147/head:pull/29147 PR: https://git.openjdk.org/jdk/pull/29147 From ghan at openjdk.org Thu Jan 15 11:03:47 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 15 Jan 2026 11:03:47 GMT Subject: RFR: 8374807: Crash in MethodData::extra_data_lock()+0x0 when running -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp -version [v2] In-Reply-To: <8c8QLPcy701RGF_uMOjert2_G9bYg6c6EDrWhe3rFcA=.a1add9ea-7189-4002-b913-a343f4752841@github.com> References: <8c8QLPcy701RGF_uMOjert2_G9bYg6c6EDrWhe3rFcA=.a1add9ea-7189-4002-b913-a343f4752841@github.com> Message-ID: <2WaIFRMuY26N0hgdMe4TdZho_WIyDt8_yooXIt1FWQk=.91f24456-35fd-4732-b39b-5540b1493227@github.com> On Thu, 15 Jan 2026 05:48:59 GMT, SendaoYan wrote: >> Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - split long line >> - Merge remote-tracking branch 'upstream/master' into 8374807 >> - fix 8374807 > > test/hotspot/jtreg/compiler/uncommontrap/TestPrintDiagnosticsWithoutProfileTraps.java line 29: > >> 27: * @summary Regression test for -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp crash >> 28: * @requires vm.debug >> 29: * @run main/othervm -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp compiler.uncommontrap.TestPrintDiagnosticsWithoutProfileTraps > > Should we split this line to two or three lines. Fixed?thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29147#discussion_r2693937392 From tschatzl at openjdk.org Thu Jan 15 11:51:37 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 15 Jan 2026 11:51:37 GMT Subject: Withdrawn: 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: On Thu, 8 Jan 2026 13:54:59 GMT, Thomas Schatzl 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 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/29116 From dholmes at openjdk.org Thu Jan 15 11:53:58 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 Jan 2026 11:53:58 GMT Subject: RFR: 8375209: Strengthen Xcheck:jni for JNI critical regions [v3] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 10:22:35 GMT, Aleksey Shipilev wrote: >> [JDK-8375188](https://bugs.openjdk.org/browse/JDK-8375188) shows that misuse for JNI critical is able to deadlock the GC. Therefore, I think we really want to have `-Xcheck:jni` to preempt these cases and allow us to diagnose the issues in the field. >> >> G1 and Shenandoah are not exactly affected by this deadlock. ZGC never had this check, AFAICS, and is affected by the deadlock. We used to have some capability in Serial/Parallel prior to [JDK-8192647](https://bugs.openjdk.org/browse/JDK-8192647), AFAICS: https://github.com/openjdk/jdk/commit/a9c9f7f0cbb2f2395fef08348bf867ffa8875d73#diff-d27fc793db1bf9314b322d494cd1c3269629fe27a605b4441de08d543d020fc3L341-L344 >> >> Additional testing: >> - [x] New test, 100x repetitions >> - [ ] Linux x86_64 server fastdebug, `all` with `-XX:+UseParallelGC -Xcheck:jni` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Capture bad state at the end of JNI transition, check criticality on JNI function enters > Move the check to native->Java transition Somehow I missed this PR before now so need to take a look. src/hotspot/share/prims/jniCheck.cpp line 218: > 216: tty->print_cr("%s", fatal_other_function_in_critical); > 217: // Ideally the following, but at least AWT code triggers this (ouch!): > 218: // NativeReportJNIFatalError(thr, fatal_other_function_in_critical); So it isn't fatal it is still just a warning. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29206#issuecomment-3754338824 PR Review Comment: https://git.openjdk.org/jdk/pull/29206#discussion_r2694082591 From shade at openjdk.org Thu Jan 15 12:05:14 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 15 Jan 2026 12:05:14 GMT Subject: RFR: 8375209: Strengthen Xcheck:jni for JNI critical regions [v3] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 11:50:40 GMT, David Holmes wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Capture bad state at the end of JNI transition, check criticality on JNI function enters >> Move the check to native->Java transition > > src/hotspot/share/prims/jniCheck.cpp line 218: > >> 216: tty->print_cr("%s", fatal_other_function_in_critical); >> 217: // Ideally the following, but at least AWT code triggers this (ouch!): >> 218: // NativeReportJNIFatalError(thr, fatal_other_function_in_critical); > > So it isn't fatal it is still just a warning. Yeah, so I am undecided if we want to make it a part this PR: should we turn these warnings into fatal? We can do it separately, since it likely requires fixing the JDK code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29206#discussion_r2694115296 From shade at openjdk.org Thu Jan 15 12:16:15 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 15 Jan 2026 12:16:15 GMT Subject: RFR: 8375209: Strengthen Xcheck:jni for JNI critical regions [v3] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 11:46:32 GMT, David Holmes wrote: > Somehow I missed this PR before now so need to take a look. Thanks! I think we are in exploration mode now; we also need to complete other architectures. So, high-level question: does adding such a check makes sense to you? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29206#issuecomment-3754429926 From aph at openjdk.org Thu Jan 15 12:48:01 2026 From: aph at openjdk.org (Andrew Haley) Date: Thu, 15 Jan 2026 12:48:01 GMT Subject: RFR: 8372701: Randomized profile counters [v6] In-Reply-To: References: Message-ID: > Please use [this link](https://github.com/openjdk/jdk/pull/28541/files?w=1) to view the files changed. > > Profile counters scale very badly. > > The overhead for profiled code isn't too bad with one thread, but as the thread count increases, things go wrong very quickly. > > For example, here's a benchmark from the OpenJDK test suite, run at TieredLevel 3 with one thread, then three threads: > > > Benchmark (randomized) Mode Cnt Score Error Units > InterfaceCalls.test2ndInt5Types false avgt 4 27.468 ? 2.631 ns/op > InterfaceCalls.test2ndInt5Types false avgt 4 240.010 ? 6.329 ns/op > > > This slowdown is caused by high memory contention on the profile counters. Not only is this slow, but it can also lose profile counts. > > This patch is for C1 only. It'd be easy to randomize C1 counters as well in another PR, if anyone thinks it's worth doing. > > One other thing to note is that randomized profile counters degrade very badly with small decimation ratios. For example, using a ratio of 2 with `-XX:ProfileCaptureRatio=2` with a single thread results in > > > Benchmark (randomized) Mode Cnt Score Error Units > InterfaceCalls.test2ndInt5Types false avgt 4 80.147 ? 9.991 ns/op > > > The problem is that the branch prediction rate drops away very badly, leading to many mispredictions. It only really makes sense to use higher decimation ratios, e.g. 64. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Merge from 3f5b827d36a6615ddb99a1d1daff8bc954c52438 (origin/8372701-exp, 8372701-exp) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28541/files - new: https://git.openjdk.org/jdk/pull/28541/files/96db42e2..7d124fd2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28541&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28541&range=04-05 Stats: 558 lines in 21 files changed: 433 ins; 45 del; 80 mod Patch: https://git.openjdk.org/jdk/pull/28541.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28541/head:pull/28541 PR: https://git.openjdk.org/jdk/pull/28541 From eastigeevich at openjdk.org Thu Jan 15 13:48:32 2026 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Thu, 15 Jan 2026 13:48:32 GMT Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact on GCs and JIT performance [v24] In-Reply-To: References: Message-ID: <4hKdtUvRkeh2Y4slayxr8RXerBau9DSqjsBP6FPpWdU=.30d43b6b-e99c-4bc9-92a7-af9fef12ce01@github.com> > Arm Neoverse N1 erratum 1542419: "The core might fetch a stale instruction from memory which violates the ordering of instruction fetches". It is fixed in Neoverse N1 r4p1. > > Neoverse-N1 implementations mitigate erratum 1542419 with a workaround: > - Disable coherent icache. > - Trap IC IVAU instructions. > - Execute: > - `tlbi vae3is, xzr` > - `dsb sy` > > `tlbi vae3is, xzr` invalidates translations for all address spaces (global for address). It waits for all memory accesses using in-scope old translation information to complete before it is considered complete. > > As this workaround has significant overhead, Arm Neoverse N1 (MP050) Software Developer Errata Notice version 29.0 suggests: > > "Since one TLB inner-shareable invalidation is enough to avoid this erratum, the number of injected TLB invalidations should be minimized in the trap handler to mitigate the performance impact due to this workaround." > > This PR introduces a mechanism to defer instruction cache (ICache) invalidation for AArch64 to address the Arm Neoverse N1 erratum 1542419, which causes significant performance overhead if ICache invalidation is performed too frequently. The implementation includes detection of affected Neoverse N1 CPUs and automatic enabling of the workaround for relevant Neoverse N1 revisions. > > Changes include: > > * Added a new diagnostic AArch64 JVM flag `NeoverseN1Errata1542419` to enable or disable the workaround for the erratum. The flag is automatically enabled for Neoverse N1 CPUs prior to r4p1, as detected during VM initialization. > * Added a new diagnostic JVM flag `UseDeferredICacheInvalidation` to enable or disable defered icache invalidation. The flag is automatically enabled for AArch64 if CPU supports hardware cache coherence. > * Introduced the `ICacheInvalidationContext` class to manage deferred ICache invalidation, with platform-specific logic for AArch64. This context is used to batch ICache invalidations, reducing performance impact. > * Provided a default (no-op) implementation for `DefaultICacheInvalidationContext` on platforms where the workaround is not needed, ensuring portability and minimal impact on other architectures. > > **Testing results: linux fastdebug build** > - Neoverse-N1 (Graviton 2) > - [x] tier1: passed > - [x] tier2: passed > - [x] tier3: passed > - [x] tier4: 3 failures > - `containers/docker/TestJcmdWithSideCar.java`: JDK-8341518 > - `com/sun/nio/sctp/SctpChannel/CloseDescriptors.java`: JDK-8298466 > - `java/awt/print/PrinterJob/... Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: Use SingleShotTime mode with multiple iterations for GCPatchingNmethodCost ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28328/files - new: https://git.openjdk.org/jdk/pull/28328/files/3abb6de4..086b1bf4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28328&range=23 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28328&range=22-23 Stats: 16 lines in 1 file changed: 7 ins; 6 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28328.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28328/head:pull/28328 PR: https://git.openjdk.org/jdk/pull/28328 From eastigeevich at openjdk.org Thu Jan 15 13:51:04 2026 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Thu, 15 Jan 2026 13:51:04 GMT Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact on GCs and JIT performance [v13] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 18:50:44 GMT, Aleksey Shipilev wrote: >> The current algorithm: >> - Create an object used in Java methods. >> - Run the methods in the interpreter. >> - Compile the methods. >> - Make the object garbage collectable. >> - Run GC (we measure this). >> >> There are not many things to warm-up. And setting up everything for multiple iterations of GC runs might be expensive. Instead we use forks. >> >> IMO, Yes it is `@BenchmarkMode(OneShot)`. > > Yeah, but first GC would likely be slower, because it would have more real work to do. So you probably want OneShot with the default number of iterations. It will warmup by doing a few GCs, and then do a few other GCs for measurement. @shipilev I updated the microbenchmark to use `Mode.SingleShotTime` and to have multiple iterations. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28328#discussion_r2694464012 From duke at openjdk.org Thu Jan 15 13:54:08 2026 From: duke at openjdk.org (Roger Calnan) Date: Thu, 15 Jan 2026 13:54:08 GMT Subject: RFR: 8375342: jdk/javadoc/doccheck/checks/jdkCheckHtml.java failed with duplicate anchors Message-ID: <43PmNX7rB80uIxoJbleBPXm4ocKVNwxoXtYg9GFK1Sc=.967145ca-8468-44e7-8919-676379600dbb@github.com> removed duplicate -Xlog anchor ------------- Commit messages: - Update full name - removed duplicate -Xlog anchor Changes: https://git.openjdk.org/jdk/pull/29252/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29252&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375342 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29252.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29252/head:pull/29252 PR: https://git.openjdk.org/jdk/pull/29252 From eastigeevich at openjdk.org Thu Jan 15 13:54:01 2026 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Thu, 15 Jan 2026 13:54:01 GMT Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact on GCs and JIT performance [v25] In-Reply-To: References: Message-ID: > Arm Neoverse N1 erratum 1542419: "The core might fetch a stale instruction from memory which violates the ordering of instruction fetches". It is fixed in Neoverse N1 r4p1. > > Neoverse-N1 implementations mitigate erratum 1542419 with a workaround: > - Disable coherent icache. > - Trap IC IVAU instructions. > - Execute: > - `tlbi vae3is, xzr` > - `dsb sy` > > `tlbi vae3is, xzr` invalidates translations for all address spaces (global for address). It waits for all memory accesses using in-scope old translation information to complete before it is considered complete. > > As this workaround has significant overhead, Arm Neoverse N1 (MP050) Software Developer Errata Notice version 29.0 suggests: > > "Since one TLB inner-shareable invalidation is enough to avoid this erratum, the number of injected TLB invalidations should be minimized in the trap handler to mitigate the performance impact due to this workaround." > > This PR introduces a mechanism to defer instruction cache (ICache) invalidation for AArch64 to address the Arm Neoverse N1 erratum 1542419, which causes significant performance overhead if ICache invalidation is performed too frequently. The implementation includes detection of affected Neoverse N1 CPUs and automatic enabling of the workaround for relevant Neoverse N1 revisions. > > Changes include: > > * Added a new diagnostic AArch64 JVM flag `NeoverseN1Errata1542419` to enable or disable the workaround for the erratum. The flag is automatically enabled for Neoverse N1 CPUs prior to r4p1, as detected during VM initialization. > * Added a new diagnostic JVM flag `UseDeferredICacheInvalidation` to enable or disable defered icache invalidation. The flag is automatically enabled for AArch64 if CPU supports hardware cache coherence. > * Introduced the `ICacheInvalidationContext` class to manage deferred ICache invalidation, with platform-specific logic for AArch64. This context is used to batch ICache invalidations, reducing performance impact. > * Provided a default (no-op) implementation for `DefaultICacheInvalidationContext` on platforms where the workaround is not needed, ensuring portability and minimal impact on other architectures. > > **Testing results: linux fastdebug build** > - Neoverse-N1 (Graviton 2) > - [x] tier1: passed > - [x] tier2: passed > - [x] tier3: passed > - [x] tier4: 3 failures > - `containers/docker/TestJcmdWithSideCar.java`: JDK-8341518 > - `com/sun/nio/sctp/SctpChannel/CloseDescriptors.java`: JDK-8298466 > - `java/awt/print/PrinterJob/... Evgeny Astigeevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits: - Merge branch 'master' into JDK-8370947 - Use SingleShotTime mode with multiple iterations for GCPatchingNmethodCost - Fix macos and windows aarch64 debug builds - Remove redundant code - Merge branch 'master' into JDK-8370947 - Fix linux-cross-compile riscv64 build - Restore deleted comment - Remove redundant blank line - Remove redundant include - Merge branch 'master' into JDK-8370947 - ... and 26 more: https://git.openjdk.org/jdk/compare/78a106ff...b0ede0a8 ------------- Changes: https://git.openjdk.org/jdk/pull/28328/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28328&range=24 Stats: 826 lines in 32 files changed: 762 ins; 22 del; 42 mod Patch: https://git.openjdk.org/jdk/pull/28328.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28328/head:pull/28328 PR: https://git.openjdk.org/jdk/pull/28328 From eastigeevich at openjdk.org Thu Jan 15 13:57:47 2026 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Thu, 15 Jan 2026 13:57:47 GMT Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact on GCs and JIT performance [v13] In-Reply-To: References: Message-ID: <4x96d2l_emyQYWXaRWJq5lKPo5-fa1i9Ps1RysUmVDM=.7999c815-7452-4e3e-aa89-7195fe3c060f@github.com> On Wed, 3 Dec 2025 16:11:14 GMT, Aleksey Shipilev wrote: >> Evgeny Astigeevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: >> >> - Fix linux-cross-compile build aarch64 >> - Merge branch 'master' into JDK-8370947 >> - Remove trailing whitespaces >> - Add support of deferred icache invalidation to other GCs and JIT >> - Add UseDeferredICacheInvalidation to defer invalidation on CPU with hardware cache coherence >> - Add jtreg test >> - Fix linux-cross-compile aarch64 build >> - Fix regressions for Java methods without field accesses >> - Fix code style >> - Correct ifdef; Add dsb after ic >> - ... and 9 more: https://git.openjdk.org/jdk/compare/3d54a802...4b04496f > > Interesting work! I was able to look through it very briefly: @shipilev @theRealAph @fisk Could you please review the PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28328#issuecomment-3755001247 From alanb at openjdk.org Thu Jan 15 14:24:53 2026 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 15 Jan 2026 14:24:53 GMT Subject: RFR: 8375342: jdk/javadoc/doccheck/checks/jdkCheckHtml.java failed with duplicate anchors In-Reply-To: <43PmNX7rB80uIxoJbleBPXm4ocKVNwxoXtYg9GFK1Sc=.967145ca-8468-44e7-8919-676379600dbb@github.com> References: <43PmNX7rB80uIxoJbleBPXm4ocKVNwxoXtYg9GFK1Sc=.967145ca-8468-44e7-8919-676379600dbb@github.com> Message-ID: On Thu, 15 Jan 2026 13:40:30 GMT, Roger Calnan wrote: > removed duplicate -Xlog anchor Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29252#pullrequestreview-3665884308 From iris at openjdk.org Thu Jan 15 14:29:33 2026 From: iris at openjdk.org (Iris Clark) Date: Thu, 15 Jan 2026 14:29:33 GMT Subject: RFR: 8375342: jdk/javadoc/doccheck/checks/jdkCheckHtml.java failed with duplicate anchors In-Reply-To: <43PmNX7rB80uIxoJbleBPXm4ocKVNwxoXtYg9GFK1Sc=.967145ca-8468-44e7-8919-676379600dbb@github.com> References: <43PmNX7rB80uIxoJbleBPXm4ocKVNwxoXtYg9GFK1Sc=.967145ca-8468-44e7-8919-676379600dbb@github.com> Message-ID: On Thu, 15 Jan 2026 13:40:30 GMT, Roger Calnan wrote: > removed duplicate -Xlog anchor Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29252#pullrequestreview-3665903400 From ghan at openjdk.org Thu Jan 15 15:03:57 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 15 Jan 2026 15:03:57 GMT Subject: RFR: 8375125: assert(false) failed: "Attempting to acquire lock NativeHeapTrimmer_lock/nosafepoint out of order with lock ConcurrentHashTableResize_lock/nosafepoint-2 -- possible deadlock" when using native heap trimmer [v2] In-Reply-To: <74tKCadP3u64jwjKEvh0bZfCXYWoinhqVP1xJlneUf4=.54771fef-7e33-4781-a650-4f55ceaaf3e2@github.com> References: <74tKCadP3u64jwjKEvh0bZfCXYWoinhqVP1xJlneUf4=.54771fef-7e33-4781-a650-4f55ceaaf3e2@github.com> Message-ID: <6DIor17o1y6HVUY5NTBg6UAv4-DyJ9igNoG3QTfxD14=.f7799c03-bd03-4d73-aeed-5d73482e695c@github.com> > Please review this change. Thanks! > > **Description:** > > When -XX:TrimNativeHeapInterval=non-zero is enabled, running Test6892265 can trigger a VM abort due to a detected deadlock (or lock-order issue) during SymbolTable cleanup. > SymbolTable::clean_dead_entries() calls BulkDeleteTask::prepare(), which may take ConcurrentHashTableResize_lock (nosafepoint-2). > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/classfile/symbolTable.cpp#L765-L769 > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/utilities/concurrentHashTableTasks.inline.hpp#L159-L160 > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/utilities/concurrentHashTable.inline.hpp#L307-L310 > > > It then constructs a NativeHeapTrimmer::SuspendMark, which may take NativeHeapTrimmer_lock (nosafepoint). This can invert the lock order with the trimmer thread. > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/classfile/symbolTable.cpp#L773 > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/runtime/trimNativeHeap.hpp#L56-L59 > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/runtime/trimNativeHeap.cpp#L177-L181 > > **Fix:** > > Move NativeHeapTrimmer::SuspendMark to the beginning of SymbolTable::clean_dead_entries() before BulkDeleteTask::prepare() to enforce a consistent lock order > > **Test:** > > GHA Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - add regression test and fix an error in stringTable - Merge remote-tracking branch 'upstream/master' into 8375125 - fix 8375125 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29212/files - new: https://git.openjdk.org/jdk/pull/29212/files/001b381a..19749332 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29212&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29212&range=00-01 Stats: 19292 lines in 299 files changed: 10526 ins; 4682 del; 4084 mod Patch: https://git.openjdk.org/jdk/pull/29212.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29212/head:pull/29212 PR: https://git.openjdk.org/jdk/pull/29212 From ghan at openjdk.org Thu Jan 15 15:07:35 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 15 Jan 2026 15:07:35 GMT Subject: RFR: 8375125: assert(false) failed: "Attempting to acquire lock NativeHeapTrimmer_lock/nosafepoint out of order with lock ConcurrentHashTableResize_lock/nosafepoint-2 -- possible deadlock" when using native heap trimmer [v3] In-Reply-To: <74tKCadP3u64jwjKEvh0bZfCXYWoinhqVP1xJlneUf4=.54771fef-7e33-4781-a650-4f55ceaaf3e2@github.com> References: <74tKCadP3u64jwjKEvh0bZfCXYWoinhqVP1xJlneUf4=.54771fef-7e33-4781-a650-4f55ceaaf3e2@github.com> Message-ID: <9j6enaEfAv_0nvlmBHfYkk-E6KU97g710YH_x-T1Nm4=.555cca96-9d59-440f-83b7-7565694a6288@github.com> > Please review this change. Thanks! > > **Description:** > > When -XX:TrimNativeHeapInterval=non-zero is enabled, running Test6892265 can trigger a VM abort due to a detected deadlock (or lock-order issue) during SymbolTable cleanup. > SymbolTable::clean_dead_entries() calls BulkDeleteTask::prepare(), which may take ConcurrentHashTableResize_lock (nosafepoint-2). > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/classfile/symbolTable.cpp#L765-L769 > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/utilities/concurrentHashTableTasks.inline.hpp#L159-L160 > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/utilities/concurrentHashTable.inline.hpp#L307-L310 > > > It then constructs a NativeHeapTrimmer::SuspendMark, which may take NativeHeapTrimmer_lock (nosafepoint). This can invert the lock order with the trimmer thread. > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/classfile/symbolTable.cpp#L773 > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/runtime/trimNativeHeap.hpp#L56-L59 > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/runtime/trimNativeHeap.cpp#L177-L181 > > **Fix:** > > Move NativeHeapTrimmer::SuspendMark to the beginning of SymbolTable::clean_dead_entries() before BulkDeleteTask::prepare() to enforce a consistent lock order > > **Test:** > > GHA Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: correct copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29212/files - new: https://git.openjdk.org/jdk/pull/29212/files/19749332..e0662eac Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29212&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29212&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29212.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29212/head:pull/29212 PR: https://git.openjdk.org/jdk/pull/29212 From ghan at openjdk.org Thu Jan 15 15:13:46 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 15 Jan 2026 15:13:46 GMT Subject: RFR: 8375125: assert(false) failed: "Attempting to acquire lock NativeHeapTrimmer_lock/nosafepoint out of order with lock ConcurrentHashTableResize_lock/nosafepoint-2 -- possible deadlock" when using native heap trimmer [v4] In-Reply-To: <74tKCadP3u64jwjKEvh0bZfCXYWoinhqVP1xJlneUf4=.54771fef-7e33-4781-a650-4f55ceaaf3e2@github.com> References: <74tKCadP3u64jwjKEvh0bZfCXYWoinhqVP1xJlneUf4=.54771fef-7e33-4781-a650-4f55ceaaf3e2@github.com> Message-ID: > Please review this change. Thanks! > > **Description:** > > When -XX:TrimNativeHeapInterval=non-zero is enabled, running Test6892265 can trigger a VM abort due to a detected deadlock (or lock-order issue) during SymbolTable cleanup. > SymbolTable::clean_dead_entries() calls BulkDeleteTask::prepare(), which may take ConcurrentHashTableResize_lock (nosafepoint-2). > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/classfile/symbolTable.cpp#L765-L769 > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/utilities/concurrentHashTableTasks.inline.hpp#L159-L160 > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/utilities/concurrentHashTable.inline.hpp#L307-L310 > > > It then constructs a NativeHeapTrimmer::SuspendMark, which may take NativeHeapTrimmer_lock (nosafepoint). This can invert the lock order with the trimmer thread. > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/classfile/symbolTable.cpp#L773 > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/runtime/trimNativeHeap.hpp#L56-L59 > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/runtime/trimNativeHeap.cpp#L177-L181 > > **Fix:** > > Move NativeHeapTrimmer::SuspendMark to the beginning of SymbolTable::clean_dead_entries() before BulkDeleteTask::prepare() to enforce a consistent lock order > > **Test:** > > GHA Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: remove Whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29212/files - new: https://git.openjdk.org/jdk/pull/29212/files/e0662eac..83d58fb4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29212&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29212&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29212.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29212/head:pull/29212 PR: https://git.openjdk.org/jdk/pull/29212 From asmehra at openjdk.org Thu Jan 15 15:25:47 2026 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Thu, 15 Jan 2026 15:25:47 GMT Subject: RFR: 8373114: Redundant MethodCounters in the preimage generated by training run [v3] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 00:32:31 GMT, Vladimir Kozlov wrote: >> The main user of the cached lookups is `MethodTrainingData* mtd = MethodTrainingData::find_fast(mh);` in `compilationPolicy.cpp:1024`. It's going to be called on every tiered event if `have_data() == true`. That's likely the main source of the MC pollution he's trying to avoid. > > Thank you, that is what I missed. `find()` and find_fast()` call `make()`. > But I have a question though. Why do we treat the presence of the cache MTD value in MC as a proof that MTD refers to a MC? That's a valid point. Ideally we should do the alternate approach mentioned [here](https://github.com/openjdk/jdk/pull/28670#issuecomment-3629940217). But the CDS code has limitations in implementing it (see [comment](https://github.com/openjdk/jdk/pull/28670#issuecomment-3640384909)). The current approach is more of a workaround. If this is not acceptable, we can wait until we modify the CDS code to remember follow-mode for each reference rather than the referenced object. @veresov what do you suggest? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28670#discussion_r2694826816 From stuefe at openjdk.org Thu Jan 15 16:04:05 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 15 Jan 2026 16:04:05 GMT Subject: RFR: 8375125: assert(false) failed: "Attempting to acquire lock NativeHeapTrimmer_lock/nosafepoint out of order with lock ConcurrentHashTableResize_lock/nosafepoint-2 -- possible deadlock" when using native heap trimmer [v4] In-Reply-To: References: <74tKCadP3u64jwjKEvh0bZfCXYWoinhqVP1xJlneUf4=.54771fef-7e33-4781-a650-4f55ceaaf3e2@github.com> Message-ID: On Thu, 15 Jan 2026 15:13:46 GMT, Guanqiang Han wrote: >> Please review this change. Thanks! >> >> **Description:** >> >> When -XX:TrimNativeHeapInterval=non-zero is enabled, running Test6892265 can trigger a VM abort due to a detected deadlock (or lock-order issue) during SymbolTable cleanup. >> SymbolTable::clean_dead_entries() calls BulkDeleteTask::prepare(), which may take ConcurrentHashTableResize_lock (nosafepoint-2). >> https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/classfile/symbolTable.cpp#L765-L769 >> https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/utilities/concurrentHashTableTasks.inline.hpp#L159-L160 >> https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/utilities/concurrentHashTable.inline.hpp#L307-L310 >> >> >> It then constructs a NativeHeapTrimmer::SuspendMark, which may take NativeHeapTrimmer_lock (nosafepoint). This can invert the lock order with the trimmer thread. >> https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/classfile/symbolTable.cpp#L773 >> https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/runtime/trimNativeHeap.hpp#L56-L59 >> https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/runtime/trimNativeHeap.cpp#L177-L181 >> >> **Fix:** >> >> Move NativeHeapTrimmer::SuspendMark to the beginning of SymbolTable::clean_dead_entries() before BulkDeleteTask::prepare() to enforce a consistent lock order >> >> **Test:** >> >> GHA > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > remove Whitespace Thank you for fixing this. Small remarks, otherwise this looks okay. Thanks for the repro case. Does it fire reliably with the bug preset, or is it intermittent? test/hotspot/jtreg/runtime/nativeheaptrimmer/TestTrimNativeHeapIntervalTablesCleanup.java line 40: > 38: */ > 39: > 40: package runtime.nativeheaptrimmer; This looks odd. Other tests don't use packages. Also, the trimnative tests lives in runtime/os, maybe this should too. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29212#pullrequestreview-3666360370 PR Review Comment: https://git.openjdk.org/jdk/pull/29212#discussion_r2694980674 From stuefe at openjdk.org Thu Jan 15 16:04:06 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 15 Jan 2026 16:04:06 GMT Subject: RFR: 8375125: assert(false) failed: "Attempting to acquire lock NativeHeapTrimmer_lock/nosafepoint out of order with lock ConcurrentHashTableResize_lock/nosafepoint-2 -- possible deadlock" when using native heap trimmer In-Reply-To: <35x9AM0-Feqwu4W7YtvWX2cZnBgysD6kAFQb7BTf7cw=.cd5768d1-86f8-4cfb-8f66-b6bdfce8d0d3@github.com> References: <74tKCadP3u64jwjKEvh0bZfCXYWoinhqVP1xJlneUf4=.54771fef-7e33-4781-a650-4f55ceaaf3e2@github.com> <35x9AM0-Feqwu4W7YtvWX2cZnBgysD6kAFQb7BTf7cw=.cd5768d1-86f8-4cfb-8f66-b6bdfce8d0d3@github.com> Message-ID: On Wed, 14 Jan 2026 01:12:50 GMT, David Holmes wrote: > @hgqxjj thanks for taking this on. It appears the same problem exists with the `StringTable`. > > I think this may need its own regression test though, rather than modifying the test that exposed the issue. Also we may need more testing done with the flag activated. @tstuefe do you do regular general testing with native heap trimming enabled? Nothing automated, no. runtime/os/TestTrimNative.java tests the native trimmer functionality, beyond that no automated tests exist. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29212#issuecomment-3755572510 From duke at openjdk.org Thu Jan 15 16:22:10 2026 From: duke at openjdk.org (duke) Date: Thu, 15 Jan 2026 16:22:10 GMT Subject: RFR: 8375342: jdk/javadoc/doccheck/checks/jdkCheckHtml.java failed with duplicate anchors In-Reply-To: <43PmNX7rB80uIxoJbleBPXm4ocKVNwxoXtYg9GFK1Sc=.967145ca-8468-44e7-8919-676379600dbb@github.com> References: <43PmNX7rB80uIxoJbleBPXm4ocKVNwxoXtYg9GFK1Sc=.967145ca-8468-44e7-8919-676379600dbb@github.com> Message-ID: On Thu, 15 Jan 2026 13:40:30 GMT, Roger Calnan wrote: > removed duplicate -Xlog anchor @calnan Your change (at version 970d38fc13e13b76ac78592475ba073c4233f89e) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29252#issuecomment-3755667838 From mullan at openjdk.org Thu Jan 15 16:30:56 2026 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 15 Jan 2026 16:30:56 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v7] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 15:31:21 GMT, Kieran Farrell 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: > > update to print java.security.Security properties Please wait until someone from the Security Group reviews this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3755710214 From aph at openjdk.org Thu Jan 15 16:39:51 2026 From: aph at openjdk.org (Andrew Haley) Date: Thu, 15 Jan 2026 16:39:51 GMT Subject: RFR: 8372701: Randomized profile counters [v7] In-Reply-To: References: Message-ID: > Please use [this link](https://github.com/openjdk/jdk/pull/28541/files?w=1) to view the files changed. > > Profile counters scale very badly. > > The overhead for profiled code isn't too bad with one thread, but as the thread count increases, things go wrong very quickly. > > For example, here's a benchmark from the OpenJDK test suite, run at TieredLevel 3 with one thread, then three threads: > > > Benchmark (randomized) Mode Cnt Score Error Units > InterfaceCalls.test2ndInt5Types false avgt 4 27.468 ? 2.631 ns/op > InterfaceCalls.test2ndInt5Types false avgt 4 240.010 ? 6.329 ns/op > > > This slowdown is caused by high memory contention on the profile counters. Not only is this slow, but it can also lose profile counts. > > This patch is for C1 only. It'd be easy to randomize C1 counters as well in another PR, if anyone thinks it's worth doing. > > One other thing to note is that randomized profile counters degrade very badly with small decimation ratios. For example, using a ratio of 2 with `-XX:ProfileCaptureRatio=2` with a single thread results in > > > Benchmark (randomized) Mode Cnt Score Error Units > InterfaceCalls.test2ndInt5Types false avgt 4 80.147 ? 9.991 ns/op > > > The problem is that the branch prediction rate drops away very badly, leading to many mispredictions. It only really makes sense to use higher decimation ratios, e.g. 64. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28541/files - new: https://git.openjdk.org/jdk/pull/28541/files/7d124fd2..a1ed4b80 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28541&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28541&range=05-06 Stats: 9 lines in 3 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/28541.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28541/head:pull/28541 PR: https://git.openjdk.org/jdk/pull/28541 From shade at openjdk.org Thu Jan 15 16:51:17 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 15 Jan 2026 16:51:17 GMT Subject: RFR: 8375359: Improve GC serviceability init staging Message-ID: As per docs, `CollectedHeap::post_initialize` is for doing inits that should be done before general allocations are accepted. Currently, serviceability layer initialized there via the call to `CollectedHeap::initialize_serviceability`. This bug shows that after `CollectedHeap::post_initialize` returns, the rest of the serviceability layer had not been fully initialized yet. But GC code might assume general allocation path works at that point! So if that allocation path reports anything to the serviceability layer, it could encounter not yet fully initialized serviceability support and fail. This readily manifests in improved Epsilon stress test. Improved test fails pretty consistently on my machines, and serves as a good regression test. So the fix is to peel off serviceability initialization from post-init stage, and do it separately, before going (and finishing) `post_initialize`. Conveniently, we are nearly there, and "just" need to touch up a few things in `universe_post_init()`. Additional testing: - [x] Linux x86_64 server fastdebug, `gc/epsilon/TestInitAllocs.java`, 10x - [ ] Linux x86_64 server fastdebug, `hotspot_gc` ------------- Commit messages: - Fix - Stress test Changes: https://git.openjdk.org/jdk/pull/29254/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29254&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375359 Stats: 94 lines in 6 files changed: 42 ins; 5 del; 47 mod Patch: https://git.openjdk.org/jdk/pull/29254.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29254/head:pull/29254 PR: https://git.openjdk.org/jdk/pull/29254 From duke at openjdk.org Thu Jan 15 17:13:57 2026 From: duke at openjdk.org (Roger Calnan) Date: Thu, 15 Jan 2026 17:13:57 GMT Subject: Integrated: 8375342: jdk/javadoc/doccheck/checks/jdkCheckHtml.java failed with duplicate anchors In-Reply-To: <43PmNX7rB80uIxoJbleBPXm4ocKVNwxoXtYg9GFK1Sc=.967145ca-8468-44e7-8919-676379600dbb@github.com> References: <43PmNX7rB80uIxoJbleBPXm4ocKVNwxoXtYg9GFK1Sc=.967145ca-8468-44e7-8919-676379600dbb@github.com> Message-ID: On Thu, 15 Jan 2026 13:40:30 GMT, Roger Calnan wrote: > removed duplicate -Xlog anchor This pull request has now been integrated. Changeset: ee0387be Author: Roger Calnan Committer: Roger Riggs URL: https://git.openjdk.org/jdk/commit/ee0387be4c562c7f7ad5240f412d4d5363358855 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8375342: jdk/javadoc/doccheck/checks/jdkCheckHtml.java failed with duplicate anchors Reviewed-by: alanb, iris ------------- PR: https://git.openjdk.org/jdk/pull/29252 From iklam at openjdk.org Thu Jan 15 17:55:15 2026 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 15 Jan 2026 17:55:15 GMT Subject: RFR: 8373114: Redundant MethodCounters in the preimage generated by training run [v3] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 15:23:21 GMT, Ashutosh Mehra wrote: >> Thank you, that is what I missed. `find()` and find_fast()` call `make()`. > >> But I have a question though. Why do we treat the presence of the cache MTD value in MC as a proof that MTD refers to a MC? > > That's a valid point. Ideally we should do the alternate approach mentioned [here](https://github.com/openjdk/jdk/pull/28670#issuecomment-3629940217). But the CDS code has limitations in implementing it (see [comment](https://github.com/openjdk/jdk/pull/28670#issuecomment-3640384909)). The current approach is more of a workaround. If this is not acceptable, we can wait until we modify the CDS code to remember follow-mode for each reference rather than the referenced object. @veresov what do you suggest? I have an idea to implement the alternative approach: Change the meaning of `set_to_null` from: - the pointer is set to null. The pointee is excluded from the archive to: - do no follow the pointee. The pointer is set to null. The pointee may still be included if another reference returns `make_a_copy`. We need to have a new hashtable that remembers all the cases of `set_to_null`. Then, in `RelocateEmbeddedPointers::doit`: address* ptr_loc = (address*)(_buffered_obj + field_offset); + address* src_ptr_loc = (address*)(_source_obj + field_offset); address old_p_with_tags = *ptr_loc; assert(old_p_with_tags != nullptr, "null ptrs shouldn't have been marked"); address old_p = MetaspaceClosure::strip_tags(old_p_with_tags); uintx tags = MetaspaceClosure::decode_tags(old_p_with_tags); - address new_p = _builder->get_buffered_addr(old_p); + address new_p; + if (should_point_to_null(src_ptr_loc)) { + new_p = nullptr; + } else { + new_p = _builder->get_buffered_addr(old_p); + } bool nulled; if (new_p == nullptr) { // old_p had a FollowMode of set_to_null nulled = true; } else { new_p = MetaspaceClosure::add_tags(new_p, tags); nulled = false; } the `_source_obj` can be added to the constructor of `RelocateEmbeddedPointers`. I am not sure if we still have a need for the old semantic of `set_to_null`. If so, we may add a new `FollowMode`. If not, maybe `set_to_null` should be changed to `point_to_null`, which I think would be a better name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28670#discussion_r2695388041 From duke at openjdk.org Thu Jan 15 18:01:51 2026 From: duke at openjdk.org (duke) Date: Thu, 15 Jan 2026 18:01:51 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v5] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Tue, 13 Jan 2026 20:44:37 GMT, Larry Cable 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: changes as per @dholmes and @kwalls @larry-cable Your change (at version 55d270dcc3e8f18806699449fc243942844ff8d4) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29048#issuecomment-3756167021 From pchilanomate at openjdk.org Thu Jan 15 18:29:04 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 15 Jan 2026 18:29:04 GMT Subject: RFR: 8373120: Virtual thread stuck in BLOCKED state Message-ID: Please review the following patch. This fixes a bug in how we handle state changes for the timed `Object.wait` case in `afterYield`, which can leave a virtual thread stuck in the `BLOCKED` state. It can be triggered by two consecutive calls to timed `Object.wait`, if the first call receives a notification and the second call relies on the timeout task to wake up the thread. I added the full sequence of events that leads to the vthread getting stuck in JBS. The fix is to check for `notified` and attempt to change the state to `BLOCKED` inside the synchronized block. This guarantees that we don't change the state of an already new timed `Object.wait` call. The PR includes a new test which reproduces the issue when run several times in mach5. It's a hybrid of my original repro test and another one created by @AlanBateman. Thanks, Patricio ------------- Commit messages: - v1 Changes: https://git.openjdk.org/jdk/pull/29255/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29255&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373120 Stats: 147 lines in 2 files changed: 136 ins; 8 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29255.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29255/head:pull/29255 PR: https://git.openjdk.org/jdk/pull/29255 From vlivanov at openjdk.org Thu Jan 15 18:35:53 2026 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 15 Jan 2026 18:35:53 GMT Subject: RFR: 8374807: Crash in MethodData::extra_data_lock()+0x0 when running -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp -version [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 09:55:13 GMT, Guanqiang Han wrote: >> Please review this change. Thanks! >> >> Description: >> >> This change fixes a crash in Deoptimization::uncommon_trap_inner when running with -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp. >> >> With -XX:-ProfileTraps, create_if_missing is set to false. >> https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L2121-L2122 >> >> When create_if_missing is false, new mdo can not be created when m()->method_data() return null, so get_method_data() may return null . >> https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L1911-L1912 >> >> and trap_mdo can be null as a result >> https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L2134-L2136 >> >> The crash happens here because trap_mdo is null >> https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L2157 >> >> Fix: >> >> The fix makes acquisition of extra_data_lock conditional on trap_mdo being non-null, preserving the required lock ordering (extra_data_lock before ttyLocker) when an MDO exists. >> >> Test: >> >> GHA > > Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - split long line > - Merge remote-tracking branch 'upstream/master' into 8374807 > - fix 8374807 src/hotspot/share/runtime/deoptimization.cpp line 2161: > 2159: Mutex::_no_safepoint_check_flag); > 2160: > 2161: ttyLocker ttyl; Does the code still need `ttyLocker`? There's only one usage of `tty` and it prints all accumulated info all at once. `xtty` already annotates output with thread info. So, I'd assume that moving `trap_mdo->extra_data_lock()` locker to `trap_mdo` accesses should solve the problem as well. (I'm not sure whether a `ttyLocker` is needed or not to avoid interleaving during `tty->print_raw(st.freeze());`, but `ttyLocker` can be placed right before it.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29147#discussion_r2695517458 From duke at openjdk.org Thu Jan 15 18:56:14 2026 From: duke at openjdk.org (Larry Cable) Date: Thu, 15 Jan 2026 18:56:14 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v5] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Tue, 6 Jan 2026 21:31:06 GMT, Larry Cable wrote: >> 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.... done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2695573695 From amenkov at openjdk.org Thu Jan 15 19:49:10 2026 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 15 Jan 2026 19:49:10 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v5] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: <5THP-X2kZyt8lDj1tEPloBnzo3pG5hpHbzJewqcVNzQ=.3b8b92c8-dcd5-48a3-911c-ddf9d97f44f9@github.com> On Tue, 13 Jan 2026 20:44:37 GMT, Larry Cable 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: changes as per @dholmes and @kwalls build fails on windows. you need to fix it first ------------- Changes requested by amenkov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29048#pullrequestreview-3667286292 From kbarrett at openjdk.org Thu Jan 15 19:53:27 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 15 Jan 2026 19:53:27 GMT Subject: RFR: 8375093: Convert GlobalCounter to use Atomic Message-ID: <4HQF7pmcR9csgDnzbEg4NadMMwpQhNYEorH4ur2PgBE=.cd557e7e-183d-4789-bf54-567c9e816c0a@github.com> Please review this change to make GlobalCounter use Atomic instead of AtomicAccess. Testing: mach5 tier1 ------------- Commit messages: - fix Changes: https://git.openjdk.org/jdk/pull/29256/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29256&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375093 Stats: 24 lines in 5 files changed: 3 ins; 1 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/29256.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29256/head:pull/29256 PR: https://git.openjdk.org/jdk/pull/29256 From duke at openjdk.org Thu Jan 15 19:58:03 2026 From: duke at openjdk.org (Larry Cable) Date: Thu, 15 Jan 2026 19:58:03 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v6] In-Reply-To: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: > 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: fixed Windows build issue and moved asserts as per @dholmes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29048/files - new: https://git.openjdk.org/jdk/pull/29048/files/55d270dc..22f27bee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=04-05 Stats: 9 lines in 1 file changed: 4 ins; 4 del; 1 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 lmesnik at openjdk.org Thu Jan 15 20:34:40 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 15 Jan 2026 20:34:40 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v6] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Thu, 15 Jan 2026 19:58:03 GMT, Larry Cable 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: fixed Windows build issue and moved asserts as per @dholmes Thanks for adding test. It looks good. ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29048#pullrequestreview-3667455032 From dholmes at openjdk.org Thu Jan 15 22:00:34 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 Jan 2026 22:00:34 GMT Subject: RFR: 8375209: Strengthen Xcheck:jni for JNI critical regions [v3] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 12:02:05 GMT, Aleksey Shipilev wrote: >> src/hotspot/share/prims/jniCheck.cpp line 218: >> >>> 216: tty->print_cr("%s", fatal_other_function_in_critical); >>> 217: // Ideally the following, but at least AWT code triggers this (ouch!): >>> 218: // NativeReportJNIFatalError(thr, fatal_other_function_in_critical); >> >> So it isn't fatal it is still just a warning. > > Yeah, so I am undecided if we want to make it a part this PR: should we turn these warnings into fatal? We can do it separately, since it likely requires fixing the JDK code. I think warnings are okay here. The JDK code may still need fixing regardless. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29206#discussion_r2696099539 From dholmes at openjdk.org Thu Jan 15 22:04:40 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 Jan 2026 22:04:40 GMT Subject: RFR: 8375209: Strengthen Xcheck:jni for JNI critical regions [v3] In-Reply-To: References: Message-ID: <_Vx4ouwlnOXEmj-eQUgrdrrMF4vYwhC14G-2kwEH7Wc=.5c795ed1-97ac-4902-8555-b5deaf276e3a@github.com> On Wed, 14 Jan 2026 10:22:35 GMT, Aleksey Shipilev wrote: >> [JDK-8375188](https://bugs.openjdk.org/browse/JDK-8375188) shows that misuse for JNI critical is able to deadlock the GC. Therefore, I think we really want to have `-Xcheck:jni` to preempt these cases and allow us to diagnose the issues in the field. >> >> G1 and Shenandoah are not exactly affected by this deadlock. ZGC never had this check, AFAICS, and is affected by the deadlock. We used to have some capability in Serial/Parallel prior to [JDK-8192647](https://bugs.openjdk.org/browse/JDK-8192647), AFAICS: https://github.com/openjdk/jdk/commit/a9c9f7f0cbb2f2395fef08348bf867ffa8875d73#diff-d27fc793db1bf9314b322d494cd1c3269629fe27a605b4441de08d543d020fc3L341-L344 >> >> Additional testing: >> - [x] New test, 100x repetitions >> - [ ] Linux x86_64 server fastdebug, `all` with `-XX:+UseParallelGC -Xcheck:jni` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Capture bad state at the end of JNI transition, check criticality on JNI function enters > Move the check to native->Java transition I think warning that the native code that has started a critical region either returns (to Java) whilst the critical region is still active, or calls another JNI function, is a good thing. The return part has to be handled by the native call wrapper mechanics unfortunately. The JNI calls can be handled by augmenting the JNI entry macros. I would look at doing that rather than making this GC-centric or trying to handle it at the thread-state-transitions (assuming we can issue a JNI warning whilst still _thread_in_native). ------------- PR Comment: https://git.openjdk.org/jdk/pull/29206#issuecomment-3757087207 From lmesnik at openjdk.org Thu Jan 15 23:02:23 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 15 Jan 2026 23:02:23 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v7] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 15:31:21 GMT, Kieran Farrell 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: > > update to print java.security.Security properties This fix requires test for new added functionality. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3757287652 From duke at openjdk.org Thu Jan 15 23:10:30 2026 From: duke at openjdk.org (duke) Date: Thu, 15 Jan 2026 23:10:30 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v6] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Thu, 15 Jan 2026 19:58:03 GMT, Larry Cable 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: fixed Windows build issue and moved asserts as per @dholmes @larry-cable Your change (at version 22f27bee7c78997638ff53cd9d67e7f351576448) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29048#issuecomment-3757310468 From dholmes at openjdk.org Thu Jan 15 23:23:43 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 Jan 2026 23:23:43 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v6] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Thu, 15 Jan 2026 19:58:03 GMT, Larry Cable 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: fixed Windows build issue and moved asserts as per @dholmes Changes requested by dholmes (Reviewer). test/hotspot/jtreg/runtime/CommandLine/PrintClasses.java line 65: > 63: pb.command(new PidJcmdExecutor().getCommandLine("VM.classes", "-location")); > 64: output = new OutputAnalyzer(pb.start()); > 65: output.stdoutContains(".*(file:/|jar:).*"); This won't report any failures - it is a boolean function. You need to use `stdoutShouldContain`. ------------- PR Review: https://git.openjdk.org/jdk/pull/29048#pullrequestreview-3668061308 PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2696311622 From duke at openjdk.org Thu Jan 15 23:55:53 2026 From: duke at openjdk.org (Larry Cable) Date: Thu, 15 Jan 2026 23:55:53 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v7] In-Reply-To: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: > 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: fixed test issue as identified by @dholmes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29048/files - new: https://git.openjdk.org/jdk/pull/29048/files/22f27bee..032897f0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 sviswanathan at openjdk.org Fri Jan 16 00:24:02 2026 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Fri, 16 Jan 2026 00:24:02 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v4] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 22:59:16 GMT, Mohamed Issa wrote: >> Intel® 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: > > Remove extra jump instruction in signum floating point and unify three-way floating point comparison logic in x86.ad src/hotspot/cpu/x86/x86.ad line 1706: > 1704: Label done; > 1705: __ setcc(Assembler::above, dst); > 1706: __ jcc(Assembler::aboveEqual, done); It would be better to keep the original sequence with optimization: __ movl(dst, -1); __ jcc(Assembler::below, done); __ setcc(Assembler::notEqual, dst); This would work for both AVX10_2 and prior as the Assembler::below covers both unordered and less. src/hotspot/cpu/x86/x86.ad line 9186: > 9184: %} > 9185: > 9186: instruct cmovI_regUCFE(cmpOpUCFE cop, rFlagsRegUCFE cr, rRegI dst, rRegI src) %{ The following instructs could be removed and only the ndd version need to be kept: cmovI_regUCFE cmovI_memUCFE cmovN_regUCFE cmovP_regUCFE cmovL_regUCFE cmovL_memUCFE cmpOpUCFE/rFlagsRegUCFE should only match when both AVX10_2 and APX is available otherwise fallback to cmpOpUCF/cmpOfUCF2/rFlagsRegUCF. We can then remove the predicates from cmovI_reg/cmovI_regUCFE_ndd etc. This is to avoid explosion of ad file instructs for various combination of APX and AVX10_2. src/hotspot/cpu/x86/x86.ad line 14609: > 14607: ins_encode %{ > 14608: __ ucomxss($src1$$XMMRegister, $src2$$XMMRegister); > 14609: emit_cmpfp3(masm, $dst$$Register); It looks to me that the only difference between cmpF_reg and cmpF_regE is ucomxss vs ucomiss. In which case it is better to keep only the original cmpF_reg and remove cmpF_regE. Likewise for cmpF_memE, cmpF_immE, cmpD_regE, cmpD_memE, cmpD_immE. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2696383810 PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2696362925 PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2684261529 From ghan at openjdk.org Fri Jan 16 00:44:46 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Fri, 16 Jan 2026 00:44:46 GMT Subject: RFR: 8375125: assert(false) failed: "Attempting to acquire lock NativeHeapTrimmer_lock/nosafepoint out of order with lock ConcurrentHashTableResize_lock/nosafepoint-2 -- possible deadlock" when using native heap trimmer [v4] In-Reply-To: References: <74tKCadP3u64jwjKEvh0bZfCXYWoinhqVP1xJlneUf4=.54771fef-7e33-4781-a650-4f55ceaaf3e2@github.com> Message-ID: On Thu, 15 Jan 2026 16:00:27 GMT, Thomas Stuefe wrote: > Thank you for fixing this. Small remarks, otherwise this looks okay. Thanks for the repro case. Does it fire reliably with the bug preset, or is it intermittent? Hi @tstuefe, yes, it reproduces reliably for me with the bug preset. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29212#issuecomment-3757539479 From wkemper at openjdk.org Fri Jan 16 00:50:45 2026 From: wkemper at openjdk.org (William Kemper) Date: Fri, 16 Jan 2026 00:50:45 GMT Subject: RFR: 8373203: Genshen: Non-strong reference leak in old gen [v8] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 21:37:32 GMT, Y. Srinivas Ramakrishna wrote: > It should find the old referent to be in the old generation and leave it alone? It cannot though. Once the reference is encountered it must either be _discovered_ (i.e., added to a discovered list for later processing), or it must be marked strongly. > Is there an example of that from an application/service where we see this? The [original bug report](https://mail.openjdk.org/pipermail/shenandoah-dev/2025-December/028724.html) referenced an issue with the [Undertow](https://undertow.io/) web server. Not being able to clear these weak references prevents the finalizers from running and resulted in a memory leak. This prevented them from evaluating generational Shenandoah. The change here does add some complexity, but it's not egregious and I feel it does address a real world problem. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28810#issuecomment-3757550024 From ghan at openjdk.org Fri Jan 16 01:02:52 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Fri, 16 Jan 2026 01:02:52 GMT Subject: RFR: 8375125: assert(false) failed: "Attempting to acquire lock NativeHeapTrimmer_lock/nosafepoint out of order with lock ConcurrentHashTableResize_lock/nosafepoint-2 -- possible deadlock" when using native heap trimmer [v5] In-Reply-To: <74tKCadP3u64jwjKEvh0bZfCXYWoinhqVP1xJlneUf4=.54771fef-7e33-4781-a650-4f55ceaaf3e2@github.com> References: <74tKCadP3u64jwjKEvh0bZfCXYWoinhqVP1xJlneUf4=.54771fef-7e33-4781-a650-4f55ceaaf3e2@github.com> Message-ID: > Please review this change. Thanks! > > **Description:** > > When -XX:TrimNativeHeapInterval=non-zero is enabled, running Test6892265 can trigger a VM abort due to a detected deadlock (or lock-order issue) during SymbolTable cleanup. > SymbolTable::clean_dead_entries() calls BulkDeleteTask::prepare(), which may take ConcurrentHashTableResize_lock (nosafepoint-2). > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/classfile/symbolTable.cpp#L765-L769 > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/utilities/concurrentHashTableTasks.inline.hpp#L159-L160 > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/utilities/concurrentHashTable.inline.hpp#L307-L310 > > > It then constructs a NativeHeapTrimmer::SuspendMark, which may take NativeHeapTrimmer_lock (nosafepoint). This can invert the lock order with the trimmer thread. > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/classfile/symbolTable.cpp#L773 > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/runtime/trimNativeHeap.hpp#L56-L59 > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/runtime/trimNativeHeap.cpp#L177-L181 > > **Fix:** > > Move NativeHeapTrimmer::SuspendMark to the beginning of SymbolTable::clean_dead_entries() before BulkDeleteTask::prepare() to enforce a consistent lock order > > **Test:** > > GHA Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: Polish regression test and move it to runtime/os ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29212/files - new: https://git.openjdk.org/jdk/pull/29212/files/83d58fb4..c821a55d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29212&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29212&range=03-04 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29212.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29212/head:pull/29212 PR: https://git.openjdk.org/jdk/pull/29212 From vpaprotski at openjdk.org Fri Jan 16 01:15:16 2026 From: vpaprotski at openjdk.org (Volodymyr Paprotski) Date: Fri, 16 Jan 2026 01:15:16 GMT Subject: RFR: 8374926: EnableX86ECoreOpts was not enabled on some hybrid CPU [v3] In-Reply-To: References: Message-ID: <3wEINJR2IDU6Hi772So8ZqytuF775R-76c4ngkfWuqw=.aa820856-05d8-4fe6-a260-1c6b98bb2921@github.com> On Sun, 11 Jan 2026 07:46:33 GMT, Yasumasa Suenaga wrote: >> `EnableX86ECoreOpts` has been introduced in [JDK-8319429](https://bugs.openjdk.org/browse/JDK-8319429), however model numbers which should be enabled are hard-coded, so the flag would not be enabled by default on some models like Arrow Lake. >> >> I ran a [benchmark](https://github.com/YaSuenag/garakuta/tree/master/randminmax) to check for effectiveness of `-XX:+EnableX86ECoreOpts` with JDK 25.0.1 on Windows 11 25H2, I saw performance improvement a bit on Intel Core 5 Ultra 225U as following: >> >> Disabled (default) >> >> Benchmark Mode Cnt Score Error Units >> RandMinVal.getMax thrpt 3 9707774.405 ? 27082629.015 ops/s >> RandMinVal.getMin thrpt 3 7510319.839 ? 10923547.382 ops/s >> >> >> Enabled >> >> Benchmark Mode Cnt Score Error Units >> RandMinVal.getMax thrpt 3 10127809.127 ? 45404142.338 ops/s >> RandMinVal.getMin thrpt 3 8467677.056 ? 1211998.200 ops/s >> >> >> So I think it is better to enable this flag by default on all of hybrid CPUs. >> >> >> To check what processor would be enabled E-core optimization, I made a [commit](https://github.com/openjdk/jdk/commit/f363ea1436b8100021fdac87b48ec43bcf6820af) to add comments for CPU models at first. I couldn't find out all of models (some models has not listed in SDM vol.4 so far), but most of models (excepts Sierra Forest) could be treated as hybrid CPU. Fortunately HotSpot identify hybrid flag from `CPUID`, so we can leverage it for this purpose. > > Yasumasa Suenaga 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 four additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into ecoreopt-hybrid > - Merge remote-tracking branch 'origin/master' into ecoreopt-hybrid > - Use supports_hybrid() to check for EnableX86ECoreOpts > - Add comments for CPU models For CWF (model `0xDD`), `hy-core-check.c` prints: Hybrid: 0 HT: 1 Max leaf: 0x28 and for SRF (model `0XAF`): Hybrid: 0 HT: 1 Max leaf: 0x23 When I added EnableX86ECoreOpts , I remember thinking that I need to 'make it more generic or there will be a lot of models to add manually'. Here we are :( I need to do more research (and perhaps find some people to talk to..); specifically for client-part numbers. Some reasons why I hadn't made it (yet?) more generic.. `EnableX86ECoreOpts` is supposed to be 'temporary' (the definition of which, for processors, is 'years'..). It currently enables 'emulation' type of (de)optimizations.. places where Atom cores have some catching up to do, but hopefully should be fixed: - MXCSR signaling flags - `vblendvp{sd}` emulation - pcmpestri 'emulation' in String.indexof - generate_fill (which perhaps could go under UseAVX=2 with more work/testing) In other words: we will at some point need to _disable_ `EnableX86ECoreOpts` on future hybrid cores and will again need another cpuid/flag to detect? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29149#issuecomment-3757611722 From dholmes at openjdk.org Fri Jan 16 01:18:54 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 16 Jan 2026 01:18:54 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v7] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Thu, 15 Jan 2026 23:55:53 GMT, Larry Cable 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: fixed test issue as identified by @dholmes Seems okay now. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29048#pullrequestreview-3668310458 From missa at openjdk.org Fri Jan 16 01:22:39 2026 From: missa at openjdk.org (Mohamed Issa) Date: Fri, 16 Jan 2026 01:22:39 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v5] In-Reply-To: References: Message-ID: > Intel® 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: Remove unnecessary CMOV blocks and adjust predicates involving APX and AVX10.2 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28337/files - new: https://git.openjdk.org/jdk/pull/28337/files/cd7acad7..2aa782c2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28337&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28337&range=03-04 Stats: 223 lines in 1 file changed: 2 ins; 204 del; 17 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 Fri Jan 16 01:22:44 2026 From: missa at openjdk.org (Mohamed Issa) Date: Fri, 16 Jan 2026 01:22:44 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v4] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 23:57:58 GMT, Sandhya Viswanathan wrote: >> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove extra jump instruction in signum floating point and unify three-way floating point comparison logic in x86.ad > > src/hotspot/cpu/x86/x86.ad line 1706: > >> 1704: Label done; >> 1705: __ setcc(Assembler::above, dst); >> 1706: __ jcc(Assembler::aboveEqual, done); > > It would be better to keep the original sequence with optimization: > __ movl(dst, -1); > __ jcc(Assembler::below, done); > __ setcc(Assembler::notEqual, dst); > This would work for both AVX10_2 and prior as the Assembler::below covers both unordered and less. Updated. > src/hotspot/cpu/x86/x86.ad line 9186: > >> 9184: %} >> 9185: >> 9186: instruct cmovI_regUCFE(cmpOpUCFE cop, rFlagsRegUCFE cr, rRegI dst, rRegI src) %{ > > The following instructs could be removed and only the ndd version need to be kept: > cmovI_regUCFE > cmovI_memUCFE > cmovN_regUCFE > cmovP_regUCFE > cmovL_regUCFE > cmovL_memUCFE > cmpOpUCFE/rFlagsRegUCFE should only match when both AVX10_2 and APX is available otherwise fallback to cmpOpUCF/cmpOfUCF2/rFlagsRegUCF. > We can then remove the predicates from cmovI_reg/cmovI_regUCFE_ndd etc. > This is to avoid explosion of ad file instructs for various combination of APX and AVX10_2. Updated > src/hotspot/cpu/x86/x86.ad line 14609: > >> 14607: ins_encode %{ >> 14608: __ ucomxss($src1$$XMMRegister, $src2$$XMMRegister); >> 14609: emit_cmpfp3(masm, $dst$$Register); > > It looks to me that the only difference between cmpF_reg and cmpF_regE is ucomxss vs ucomiss. In which case it is better to keep only the original cmpF_reg and remove cmpF_regE. Likewise for cmpF_memE, cmpF_immE, cmpD_regE, cmpD_memE, cmpD_immE. Updated ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2696513365 PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2696513175 PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2696512969 From dholmes at openjdk.org Fri Jan 16 01:54:55 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 16 Jan 2026 01:54:55 GMT Subject: RFR: 8373120: Virtual thread stuck in BLOCKED state In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 17:42:33 GMT, Patricio Chilano Mateo wrote: > Please review the following patch. This fixes a bug in how we handle state changes for the timed `Object.wait` case in `afterYield`, which can leave a virtual thread stuck in the `BLOCKED` state. It can be triggered by two consecutive calls to timed `Object.wait`, if the first call receives a notification and the second call relies on the timeout task to wake up the thread. I added the full sequence of events that leads to the vthread getting stuck in JBS. > > The fix is to check for `notified` and attempt to change the state to `BLOCKED` inside the synchronized block. This guarantees that we don't change the state of an already new timed `Object.wait` call. > > The PR includes a new test which reproduces the issue when run several times in mach5. It's a hybrid of my original repro test and another one created by @AlanBateman. > > Thanks, > Patricio @pchilano I took a look at this out of interest but there is nothing Hotspot related to review. The state machine for VTs is too complex for me to comment on the actual fix - though I understand how the timedWaitLock forces the calls to be serialized. It did make we wonder why the timed-park doesn't need any locking. Can't it have a similar problem if the virtual thread is unparked before the carrier can set the state to TIMED_PARK? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29255#issuecomment-3757721807 From ysuenaga at openjdk.org Fri Jan 16 02:13:56 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Fri, 16 Jan 2026 02:13:56 GMT Subject: RFR: 8374926: EnableX86ECoreOpts was not enabled on some hybrid CPU [v3] In-Reply-To: References: Message-ID: <9rlU8cTf34HH57_8-auHISNLYDg8DcoakecgwZ13L2A=.74348de7-dcf6-4c2c-877f-1a6cb18d8152@github.com> On Sun, 11 Jan 2026 07:46:33 GMT, Yasumasa Suenaga wrote: >> `EnableX86ECoreOpts` has been introduced in [JDK-8319429](https://bugs.openjdk.org/browse/JDK-8319429), however model numbers which should be enabled are hard-coded, so the flag would not be enabled by default on some models like Arrow Lake. >> >> I ran a [benchmark](https://github.com/YaSuenag/garakuta/tree/master/randminmax) to check for effectiveness of `-XX:+EnableX86ECoreOpts` with JDK 25.0.1 on Windows 11 25H2, I saw performance improvement a bit on Intel Core 5 Ultra 225U as following: >> >> Disabled (default) >> >> Benchmark Mode Cnt Score Error Units >> RandMinVal.getMax thrpt 3 9707774.405 ? 27082629.015 ops/s >> RandMinVal.getMin thrpt 3 7510319.839 ? 10923547.382 ops/s >> >> >> Enabled >> >> Benchmark Mode Cnt Score Error Units >> RandMinVal.getMax thrpt 3 10127809.127 ? 45404142.338 ops/s >> RandMinVal.getMin thrpt 3 8467677.056 ? 1211998.200 ops/s >> >> >> So I think it is better to enable this flag by default on all of hybrid CPUs. >> >> >> To check what processor would be enabled E-core optimization, I made a [commit](https://github.com/openjdk/jdk/commit/f363ea1436b8100021fdac87b48ec43bcf6820af) to add comments for CPU models at first. I couldn't find out all of models (some models has not listed in SDM vol.4 so far), but most of models (excepts Sierra Forest) could be treated as hybrid CPU. Fortunately HotSpot identify hybrid flag from `CPUID`, so we can leverage it for this purpose. > > Yasumasa Suenaga 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 four additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into ecoreopt-hybrid > - Merge remote-tracking branch 'origin/master' into ecoreopt-hybrid > - Use supports_hybrid() to check for EnableX86ECoreOpts > - Add comments for CPU models I'm not an Intel employee, so I do not know about product strategies / implementation plans, but... > will again need another cpuid/flag to detect? I hope we can detect it from native model ID in leaf 1Ah... ------------- PR Comment: https://git.openjdk.org/jdk/pull/29149#issuecomment-3757769465 From ghan at openjdk.org Fri Jan 16 02:21:16 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Fri, 16 Jan 2026 02:21:16 GMT Subject: RFR: 8375125: assert(false) failed: "Attempting to acquire lock NativeHeapTrimmer_lock/nosafepoint out of order with lock ConcurrentHashTableResize_lock/nosafepoint-2 -- possible deadlock" when using native heap trimmer [v4] In-Reply-To: References: <74tKCadP3u64jwjKEvh0bZfCXYWoinhqVP1xJlneUf4=.54771fef-7e33-4781-a650-4f55ceaaf3e2@github.com> Message-ID: <4dPBYbxW4KqHIG7ibzHtAZkgw62YtMNxwhpb8P1SWjE=.d354bc65-24c1-45a5-a849-22cff1fabd01@github.com> On Thu, 15 Jan 2026 15:58:58 GMT, Thomas Stuefe wrote: >> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: >> >> remove Whitespace > > test/hotspot/jtreg/runtime/nativeheaptrimmer/TestTrimNativeHeapIntervalTablesCleanup.java line 40: > >> 38: */ >> 39: >> 40: package runtime.nativeheaptrimmer; > > This looks odd. Other tests don't use packages. > > Also, the trimnative tests lives in runtime/os, maybe this should too. Fixed. Could you please take another look? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29212#discussion_r2696618644 From ghan at openjdk.org Fri Jan 16 02:32:06 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Fri, 16 Jan 2026 02:32:06 GMT Subject: RFR: 8374807: Crash in MethodData::extra_data_lock()+0x0 when running -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp -version [v3] In-Reply-To: References: Message-ID: > Please review this change. Thanks! > > Description: > > This change fixes a crash in Deoptimization::uncommon_trap_inner when running with -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp. > > With -XX:-ProfileTraps, create_if_missing is set to false. > https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L2121-L2122 > > When create_if_missing is false, new mdo can not be created when m()->method_data() return null, so get_method_data() may return null . > https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L1911-L1912 > > and trap_mdo can be null as a result > https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L2134-L2136 > > The crash happens here because trap_mdo is null > https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L2157 > > Fix: > > The fix makes acquisition of extra_data_lock conditional on trap_mdo being non-null, preserving the required lock ordering (extra_data_lock before ttyLocker) when an MDO exists. > > Test: > > GHA Guanqiang Han 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: - narrow lock scope - Merge remote-tracking branch 'upstream/master' into 8374807 - split long line - Merge remote-tracking branch 'upstream/master' into 8374807 - fix 8374807 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29147/files - new: https://git.openjdk.org/jdk/pull/29147/files/9445014e..cdc88af1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29147&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29147&range=01-02 Stats: 931 lines in 36 files changed: 487 ins; 116 del; 328 mod Patch: https://git.openjdk.org/jdk/pull/29147.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29147/head:pull/29147 PR: https://git.openjdk.org/jdk/pull/29147 From dholmes at openjdk.org Fri Jan 16 02:37:32 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 16 Jan 2026 02:37:32 GMT Subject: RFR: 8375125: assert(false) failed: "Attempting to acquire lock NativeHeapTrimmer_lock/nosafepoint out of order with lock ConcurrentHashTableResize_lock/nosafepoint-2 -- possible deadlock" when using native heap trimmer [v5] In-Reply-To: References: <74tKCadP3u64jwjKEvh0bZfCXYWoinhqVP1xJlneUf4=.54771fef-7e33-4781-a650-4f55ceaaf3e2@github.com> Message-ID: On Fri, 16 Jan 2026 01:02:52 GMT, Guanqiang Han wrote: >> Please review this change. Thanks! >> >> **Description:** >> >> When -XX:TrimNativeHeapInterval=non-zero is enabled, running Test6892265 can trigger a VM abort due to a detected deadlock (or lock-order issue) during SymbolTable cleanup. >> SymbolTable::clean_dead_entries() calls BulkDeleteTask::prepare(), which may take ConcurrentHashTableResize_lock (nosafepoint-2). >> https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/classfile/symbolTable.cpp#L765-L769 >> https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/utilities/concurrentHashTableTasks.inline.hpp#L159-L160 >> https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/utilities/concurrentHashTable.inline.hpp#L307-L310 >> >> >> It then constructs a NativeHeapTrimmer::SuspendMark, which may take NativeHeapTrimmer_lock (nosafepoint). This can invert the lock order with the trimmer thread. >> https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/classfile/symbolTable.cpp#L773 >> https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/runtime/trimNativeHeap.hpp#L56-L59 >> https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/runtime/trimNativeHeap.cpp#L177-L181 >> >> **Fix:** >> >> Move NativeHeapTrimmer::SuspendMark to the beginning of SymbolTable::clean_dead_entries() before BulkDeleteTask::prepare() to enforce a consistent lock order >> >> **Test:** >> >> GHA > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > Polish regression test and move it to runtime/os Functional fix looks good. A query on the test. Thanks test/hotspot/jtreg/runtime/os/TestTrimNativeHeapIntervalTablesCleanup.java line 32: > 30: * @library /test/lib > 31: * @modules java.compiler > 32: * @run main/othervm -XX:+UseG1GC -Xms128m -Xmx128m If the test needs G1 then it should have an appropriate `@requires` clause. No point running this test when we are testing ZGC for example. But does it really require G1? I admit I have no idea how this test is causing the StringTable or SymbolTable cleanup to be triggered. ------------- PR Review: https://git.openjdk.org/jdk/pull/29212#pullrequestreview-3668482304 PR Review Comment: https://git.openjdk.org/jdk/pull/29212#discussion_r2696641793 From dholmes at openjdk.org Fri Jan 16 02:53:55 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 16 Jan 2026 02:53:55 GMT Subject: RFR: 8375125: assert(false) failed: "Attempting to acquire lock NativeHeapTrimmer_lock/nosafepoint out of order with lock ConcurrentHashTableResize_lock/nosafepoint-2 -- possible deadlock" when using native heap trimmer [v5] In-Reply-To: References: <74tKCadP3u64jwjKEvh0bZfCXYWoinhqVP1xJlneUf4=.54771fef-7e33-4781-a650-4f55ceaaf3e2@github.com> Message-ID: On Fri, 16 Jan 2026 02:33:14 GMT, David Holmes wrote: >> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: >> >> Polish regression test and move it to runtime/os > > test/hotspot/jtreg/runtime/os/TestTrimNativeHeapIntervalTablesCleanup.java line 32: > >> 30: * @library /test/lib >> 31: * @modules java.compiler >> 32: * @run main/othervm -XX:+UseG1GC -Xms128m -Xmx128m > > If the test needs G1 then it should have an appropriate `@requires` clause. No point running this test when we are testing ZGC for example. > > But does it really require G1? I admit I have no idea how this test is causing the StringTable or SymbolTable cleanup to be triggered. I tested with ZGC, Serial, and Parallel and the test crashed as expected without the fix. So I think you can just remove the UseG1GC. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29212#discussion_r2696667501 From ghan at openjdk.org Fri Jan 16 03:33:19 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Fri, 16 Jan 2026 03:33:19 GMT Subject: RFR: 8375125: assert(false) failed: "Attempting to acquire lock NativeHeapTrimmer_lock/nosafepoint out of order with lock ConcurrentHashTableResize_lock/nosafepoint-2 -- possible deadlock" when using native heap trimmer [v6] In-Reply-To: <74tKCadP3u64jwjKEvh0bZfCXYWoinhqVP1xJlneUf4=.54771fef-7e33-4781-a650-4f55ceaaf3e2@github.com> References: <74tKCadP3u64jwjKEvh0bZfCXYWoinhqVP1xJlneUf4=.54771fef-7e33-4781-a650-4f55ceaaf3e2@github.com> Message-ID: > Please review this change. Thanks! > > **Description:** > > When -XX:TrimNativeHeapInterval=non-zero is enabled, running Test6892265 can trigger a VM abort due to a detected deadlock (or lock-order issue) during SymbolTable cleanup. > SymbolTable::clean_dead_entries() calls BulkDeleteTask::prepare(), which may take ConcurrentHashTableResize_lock (nosafepoint-2). > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/classfile/symbolTable.cpp#L765-L769 > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/utilities/concurrentHashTableTasks.inline.hpp#L159-L160 > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/utilities/concurrentHashTable.inline.hpp#L307-L310 > > > It then constructs a NativeHeapTrimmer::SuspendMark, which may take NativeHeapTrimmer_lock (nosafepoint). This can invert the lock order with the trimmer thread. > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/classfile/symbolTable.cpp#L773 > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/runtime/trimNativeHeap.hpp#L56-L59 > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/runtime/trimNativeHeap.cpp#L177-L181 > > **Fix:** > > Move NativeHeapTrimmer::SuspendMark to the beginning of SymbolTable::clean_dead_entries() before BulkDeleteTask::prepare() to enforce a consistent lock order > > **Test:** > > GHA Guanqiang Han 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: - adjust gc parameter - Merge remote-tracking branch 'upstream/master' into 8375125 - Polish regression test and move it to runtime/os - remove Whitespace - correct copyright year - add regression test and fix an error in stringTable - Merge remote-tracking branch 'upstream/master' into 8375125 - fix 8375125 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29212/files - new: https://git.openjdk.org/jdk/pull/29212/files/c821a55d..e52efe59 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29212&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29212&range=04-05 Stats: 884 lines in 34 files changed: 483 ins; 88 del; 313 mod Patch: https://git.openjdk.org/jdk/pull/29212.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29212/head:pull/29212 PR: https://git.openjdk.org/jdk/pull/29212 From ghan at openjdk.org Fri Jan 16 03:35:31 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Fri, 16 Jan 2026 03:35:31 GMT Subject: RFR: 8375125: assert(false) failed: "Attempting to acquire lock NativeHeapTrimmer_lock/nosafepoint out of order with lock ConcurrentHashTableResize_lock/nosafepoint-2 -- possible deadlock" when using native heap trimmer [v5] In-Reply-To: References: <74tKCadP3u64jwjKEvh0bZfCXYWoinhqVP1xJlneUf4=.54771fef-7e33-4781-a650-4f55ceaaf3e2@github.com> Message-ID: On Fri, 16 Jan 2026 02:50:39 GMT, David Holmes wrote: >> test/hotspot/jtreg/runtime/os/TestTrimNativeHeapIntervalTablesCleanup.java line 32: >> >>> 30: * @library /test/lib >>> 31: * @modules java.compiler >>> 32: * @run main/othervm -XX:+UseG1GC -Xms128m -Xmx128m >> >> If the test needs G1 then it should have an appropriate `@requires` clause. No point running this test when we are testing ZGC for example. >> >> But does it really require G1? I admit I have no idea how this test is causing the StringTable or SymbolTable cleanup to be triggered. > > I tested with ZGC, Serial, and Parallel and the test crashed as expected without the fix. So I think you can just remove the UseG1GC. I originally forced G1 only to keep the repro deterministic, but the test doesn?t depend on G1. I?ll drop -XX:+UseG1GC and just exclude Epsilon. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29212#discussion_r2696732584 From dlong at openjdk.org Fri Jan 16 04:01:20 2026 From: dlong at openjdk.org (Dean Long) Date: Fri, 16 Jan 2026 04:01:20 GMT Subject: RFR: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) [v6] In-Reply-To: References: Message-ID: <_jevSayhH-Khj6mA5jxNQKSzYwEctDg0dDgFTHltHUg=.8e8356c9-7781-4845-bd1a-d9fc3b6f107d@github.com> On Thu, 15 Jan 2026 09:17:55 GMT, David Holmes wrote: >> I agree with the concern here. The buffering we need is local to this call site to keep the output coherent (collect everything and print once). >> Whether we need to buffer/accumulate output for coherence is scenario-dependent, rather than a property that should permanently classify a stream type as ?buffered? vs. ?unbuffered?. >> @dean-long what?s your view on this? > > No - sorry I forgot that you have to add override to all methods. My understanding is that we need at least one stringStream, and the code is trying to avoid having two stacked stringStreams, which would mean extra memory footprint and copying. So I agree the proposed is_buffered() is really a proxy for "do I have a stringStream?" because bufferedStream does not guarantee coherent output by itself. What if we just live with the inefficiency of having two stringStreams for now? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29186#discussion_r2696784127 From dholmes at openjdk.org Fri Jan 16 04:36:56 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 16 Jan 2026 04:36:56 GMT Subject: RFR: 8375093: Convert GlobalCounter to use Atomic In-Reply-To: <4HQF7pmcR9csgDnzbEg4NadMMwpQhNYEorH4ur2PgBE=.cd557e7e-183d-4789-bf54-567c9e816c0a@github.com> References: <4HQF7pmcR9csgDnzbEg4NadMMwpQhNYEorH4ur2PgBE=.cd557e7e-183d-4789-bf54-567c9e816c0a@github.com> Message-ID: On Thu, 15 Jan 2026 19:46:39 GMT, Kim Barrett wrote: > Please review this change to make GlobalCounter use Atomic instead of > AtomicAccess. > > Testing: mach5 tier1 This all seems fine. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29256#pullrequestreview-3668795526 From dholmes at openjdk.org Fri Jan 16 04:44:30 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 16 Jan 2026 04:44:30 GMT Subject: RFR: 8375125: assert(false) failed: "Attempting to acquire lock NativeHeapTrimmer_lock/nosafepoint out of order with lock ConcurrentHashTableResize_lock/nosafepoint-2 -- possible deadlock" when using native heap trimmer [v6] In-Reply-To: References: <74tKCadP3u64jwjKEvh0bZfCXYWoinhqVP1xJlneUf4=.54771fef-7e33-4781-a650-4f55ceaaf3e2@github.com> Message-ID: On Fri, 16 Jan 2026 03:33:19 GMT, Guanqiang Han wrote: >> Please review this change. Thanks! >> >> **Description:** >> >> When -XX:TrimNativeHeapInterval=non-zero is enabled, running Test6892265 can trigger a VM abort due to a detected deadlock (or lock-order issue) during SymbolTable cleanup. >> SymbolTable::clean_dead_entries() calls BulkDeleteTask::prepare(), which may take ConcurrentHashTableResize_lock (nosafepoint-2). >> https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/classfile/symbolTable.cpp#L765-L769 >> https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/utilities/concurrentHashTableTasks.inline.hpp#L159-L160 >> https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/utilities/concurrentHashTable.inline.hpp#L307-L310 >> >> >> It then constructs a NativeHeapTrimmer::SuspendMark, which may take NativeHeapTrimmer_lock (nosafepoint). This can invert the lock order with the trimmer thread. >> https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/classfile/symbolTable.cpp#L773 >> https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/runtime/trimNativeHeap.hpp#L56-L59 >> https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/runtime/trimNativeHeap.cpp#L177-L181 >> >> **Fix:** >> >> Move NativeHeapTrimmer::SuspendMark to the beginning of SymbolTable::clean_dead_entries() before BulkDeleteTask::prepare() to enforce a consistent lock order >> >> **Test:** >> >> GHA > > Guanqiang Han 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: > > - adjust gc parameter > - Merge remote-tracking branch 'upstream/master' into 8375125 > - Polish regression test and move it to runtime/os > - remove Whitespace > - correct copyright year > - add regression test and fix an error in stringTable > - Merge remote-tracking branch 'upstream/master' into 8375125 > - fix 8375125 Nothing further from me. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29212#pullrequestreview-3668815023 From ghan at openjdk.org Fri Jan 16 05:45:41 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Fri, 16 Jan 2026 05:45:41 GMT Subject: RFR: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) [v6] In-Reply-To: <_jevSayhH-Khj6mA5jxNQKSzYwEctDg0dDgFTHltHUg=.8e8356c9-7781-4845-bd1a-d9fc3b6f107d@github.com> References: <_jevSayhH-Khj6mA5jxNQKSzYwEctDg0dDgFTHltHUg=.8e8356c9-7781-4845-bd1a-d9fc3b6f107d@github.com> Message-ID: <4jqYbz9oL1Klo7KdXSdWPdNT9cD0LrpHPf6u4NfKlDg=.26a204e9-8f6f-4ff5-af92-671974b1a9c9@github.com> On Fri, 16 Jan 2026 03:57:52 GMT, Dean Long wrote: >> No - sorry I forgot that you have to add override to all methods. > > My understanding is that we need at least one stringStream, and the code is trying to avoid having two stacked stringStreams, which would mean extra memory footprint and copying. So I agree the proposed is_buffered() is really a proxy for "do I have a stringStream?" because bufferedStream does not guarantee coherent output by itself. What if we just live with the inefficiency of having two stringStreams for now? Thanks, ok, I?ll drop the is_buffered() change. Would it be acceptable to go back to my earlier proposal: pass an explicit ?buffering/coherent-output? parameter at the call site so we can use an existing stringStream and avoid double buffering? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29186#discussion_r2697031873 From alanb at openjdk.org Fri Jan 16 07:09:46 2026 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 16 Jan 2026 07:09:46 GMT Subject: RFR: 8373120: Virtual thread stuck in BLOCKED state In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 01:50:50 GMT, David Holmes wrote: > It did make we wonder why the timed-park doesn't need any locking. Can't it have a similar problem if the virtual thread is unparked before the carrier can set the state to TIMED_PARK? Parking (including timed-parking) is much simpler, and okay to be unparked during transition. We have a lot of tests for this. Timed-Object.wait is more complex due to the two block states (the equivalent of Thread.State TIMED_WAITING and BLOCKED), and timed and unblocking working asynchronously. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29255#issuecomment-3758486123 From iwalulya at openjdk.org Fri Jan 16 07:11:27 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Fri, 16 Jan 2026 07:11:27 GMT Subject: RFR: 8375093: Convert GlobalCounter to use Atomic In-Reply-To: <4HQF7pmcR9csgDnzbEg4NadMMwpQhNYEorH4ur2PgBE=.cd557e7e-183d-4789-bf54-567c9e816c0a@github.com> References: <4HQF7pmcR9csgDnzbEg4NadMMwpQhNYEorH4ur2PgBE=.cd557e7e-183d-4789-bf54-567c9e816c0a@github.com> Message-ID: On Thu, 15 Jan 2026 19:46:39 GMT, Kim Barrett wrote: > Please review this change to make GlobalCounter use Atomic instead of > AtomicAccess. > > Testing: mach5 tier1 Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29256#pullrequestreview-3669268727 From alanb at openjdk.org Fri Jan 16 07:17:43 2026 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 16 Jan 2026 07:17:43 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v7] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Thu, 15 Jan 2026 23:55:53 GMT, Larry Cable 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: fixed test issue as identified by @dholmes Does the jcmd man page need to be updated? That is, I assume the intention is that it be a documented/supported option, which means it should have a CSR too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29048#issuecomment-3758508980 From ysuenaga at openjdk.org Fri Jan 16 07:55:44 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Fri, 16 Jan 2026 07:55:44 GMT Subject: RFR: 8374926: EnableX86ECoreOpts was not enabled on some hybrid CPU [v3] In-Reply-To: <3wEINJR2IDU6Hi772So8ZqytuF775R-76c4ngkfWuqw=.aa820856-05d8-4fe6-a260-1c6b98bb2921@github.com> References: <3wEINJR2IDU6Hi772So8ZqytuF775R-76c4ngkfWuqw=.aa820856-05d8-4fe6-a260-1c6b98bb2921@github.com> Message-ID: <7i6B1qLZaNkHsC_u522EIZ0t9cHqFebveMYi1NxDSEo=.f611e780-a6dc-49a5-a3e6-a578ccc2cbbf@github.com> On Fri, 16 Jan 2026 01:12:33 GMT, Volodymyr Paprotski wrote: >> Yasumasa Suenaga 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 four additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/master' into ecoreopt-hybrid >> - Merge remote-tracking branch 'origin/master' into ecoreopt-hybrid >> - Use supports_hybrid() to check for EnableX86ECoreOpts >> - Add comments for CPU models > > For CWF (model `0xDD`), `hy-core-check.c` prints: > > Hybrid: 0 > HT: 1 > Max leaf: 0x28 > > and for SRF (model `0XAF`): > > Hybrid: 0 > HT: 1 > Max leaf: 0x23 > > > When I added EnableX86ECoreOpts , I remember thinking that I need to 'make it more generic or there will be a lot of models to add manually'. Here we are :( > > I need to do more research (and perhaps find some people to talk to..); specifically for client-part numbers. > > Some reasons why I hadn't made it (yet?) more generic.. `EnableX86ECoreOpts` is supposed to be 'temporary' (the definition of which, for processors, is 'years'..). It currently enables 'emulation' type of (de)optimizations.. places where Atom cores have some catching up to do, but hopefully should be fixed: > - MXCSR signaling flags > - `vblendvp{sd}` emulation > - pcmpestri 'emulation' in String.indexof > - generate_fill (which perhaps could go under UseAVX=2 with more work/testing) > > In other words: we will at some point need to _disable_ `EnableX86ECoreOpts` on future hybrid cores and will again need another cpuid/flag to detect? @vpaprotsk Can you try hy-core-check.c again on both SRF and CWF? I updated it to show leaf 1Ah information even if hybrid flag is not set. https://github.com/YaSuenag/garakuta/blob/master/check-hybrid-cores/hy-core-check.c If we can see core type and native model ID on both SRF and CWF (AFAIK they are all of all-E-cores processor), we can refer leaf 1Ah to set `EnableX86ECoreOpts` so far. I will update this PR to merge [this branch](https://github.com/YaSuenag/jdk/compare/ecoreopt-hybrid...YaSuenag:jdk:check-ecore) to check leaf 1Ah. I think it is "generalized" so far. If we need to update the logic to determine to configure the flag for newer processors in future, then we would think another solution with its CPUID (maybe) - we can add model ID in worst case. What do you think? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29149#issuecomment-3758628021 From rrich at openjdk.org Fri Jan 16 08:02:23 2026 From: rrich at openjdk.org (Richard Reingruber) Date: Fri, 16 Jan 2026 08:02:23 GMT Subject: RFR: 8374769: PPC: MASM::pop_cont_fastpath() should reset _cont_fastpath if SP == _cont_fastpath In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 08:17:53 GMT, Richard Reingruber 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. s390x built failure has to be unrelated as this pr only changes ppc files. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29133#issuecomment-3753587762 From rrich at openjdk.org Fri Jan 16 08:05:14 2026 From: rrich at openjdk.org (Richard Reingruber) Date: Fri, 16 Jan 2026 08:05:14 GMT Subject: Integrated: 8374769: PPC: MASM::pop_cont_fastpath() should reset _cont_fastpath if SP == _cont_fastpath In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 08:17:53 GMT, Richard Reingruber 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. This pull request has now been integrated. Changeset: 5664d914 Author: Richard Reingruber URL: https://git.openjdk.org/jdk/commit/5664d9148401934cd26308dc4493f4a5656e89bd Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8374769: PPC: MASM::pop_cont_fastpath() should reset _cont_fastpath if SP == _cont_fastpath Reviewed-by: mdoerr ------------- PR: https://git.openjdk.org/jdk/pull/29133 From mbaesken at openjdk.org Fri Jan 16 08:05:59 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 16 Jan 2026 08:05:59 GMT Subject: RFR: 8375311: Some builds are missing debug helpers In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 15:32:28 GMT, Matthias Baesken wrote: > [JDK-8318834](https://bugs.openjdk.org/browse/JDK-8318834) pointed out that on linux s390x, debug builds were missing debug helpers . > This happened because we enabled some time ago linktime gc (-Wl,--gc-sections in the linker flags, plus -ffunction-sections -fdata-sections in compile flags) for linux x390x by default. > But potentially ltgc or similar size-optimizing options could be enabled on other platforms too, and not only debug builds could lose the debug helpers (however in non-debug builds they might be not that important). > > On Windows we already export the debug helper symbols, so it might be good to do this on other platforms, especially Linux, too. Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29232#issuecomment-3758653628 From mbaesken at openjdk.org Fri Jan 16 08:08:17 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 16 Jan 2026 08:08:17 GMT Subject: Integrated: 8375311: Some builds are missing debug helpers In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 15:32:28 GMT, Matthias Baesken wrote: > [JDK-8318834](https://bugs.openjdk.org/browse/JDK-8318834) pointed out that on linux s390x, debug builds were missing debug helpers . > This happened because we enabled some time ago linktime gc (-Wl,--gc-sections in the linker flags, plus -ffunction-sections -fdata-sections in compile flags) for linux x390x by default. > But potentially ltgc or similar size-optimizing options could be enabled on other platforms too, and not only debug builds could lose the debug helpers (however in non-debug builds they might be not that important). > > On Windows we already export the debug helper symbols, so it might be good to do this on other platforms, especially Linux, too. This pull request has now been integrated. Changeset: b7346c30 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/b7346c307fc1aba01c10fc6dc745e5e520b1d7b9 Stats: 6 lines in 1 file changed: 2 ins; 1 del; 3 mod 8375311: Some builds are missing debug helpers Reviewed-by: mdoerr, aph ------------- PR: https://git.openjdk.org/jdk/pull/29232 From rsunderbabu at openjdk.org Fri Jan 16 08:49:20 2026 From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu) Date: Fri, 16 Jan 2026 08:49:20 GMT Subject: RFR: 8375443: AVX-512: Disabling through UseSHA doesn't affect UseSHA3Intrinsics Message-ID: UseSHA flag is not respected while enabling/disabling UseSHA3Intrinsics flag in x86 builds. Added UseSHA in the mix. Testing: Only Basic testing done. I will run more compiler related testing. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/29266/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29266&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375443 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29266.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29266/head:pull/29266 PR: https://git.openjdk.org/jdk/pull/29266 From duke at openjdk.org Fri Jan 16 09:40:20 2026 From: duke at openjdk.org (duke) Date: Fri, 16 Jan 2026 09:40:20 GMT Subject: RFR: 8375125: assert(false) failed: "Attempting to acquire lock NativeHeapTrimmer_lock/nosafepoint out of order with lock ConcurrentHashTableResize_lock/nosafepoint-2 -- possible deadlock" when using native heap trimmer [v6] In-Reply-To: References: <74tKCadP3u64jwjKEvh0bZfCXYWoinhqVP1xJlneUf4=.54771fef-7e33-4781-a650-4f55ceaaf3e2@github.com> Message-ID: On Fri, 16 Jan 2026 03:33:19 GMT, Guanqiang Han wrote: >> Please review this change. Thanks! >> >> **Description:** >> >> When -XX:TrimNativeHeapInterval=non-zero is enabled, running Test6892265 can trigger a VM abort due to a detected deadlock (or lock-order issue) during SymbolTable cleanup. >> SymbolTable::clean_dead_entries() calls BulkDeleteTask::prepare(), which may take ConcurrentHashTableResize_lock (nosafepoint-2). >> https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/classfile/symbolTable.cpp#L765-L769 >> https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/utilities/concurrentHashTableTasks.inline.hpp#L159-L160 >> https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/utilities/concurrentHashTable.inline.hpp#L307-L310 >> >> >> It then constructs a NativeHeapTrimmer::SuspendMark, which may take NativeHeapTrimmer_lock (nosafepoint). This can invert the lock order with the trimmer thread. >> https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/classfile/symbolTable.cpp#L773 >> https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/runtime/trimNativeHeap.hpp#L56-L59 >> https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/runtime/trimNativeHeap.cpp#L177-L181 >> >> **Fix:** >> >> Move NativeHeapTrimmer::SuspendMark to the beginning of SymbolTable::clean_dead_entries() before BulkDeleteTask::prepare() to enforce a consistent lock order >> >> **Test:** >> >> GHA > > Guanqiang Han 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: > > - adjust gc parameter > - Merge remote-tracking branch 'upstream/master' into 8375125 > - Polish regression test and move it to runtime/os > - remove Whitespace > - correct copyright year > - add regression test and fix an error in stringTable > - Merge remote-tracking branch 'upstream/master' into 8375125 > - fix 8375125 @hgqxjj Your change (at version e52efe59926341635eb6686ceb0ff89b66a68942) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29212#issuecomment-3759015826 From mhaessig at openjdk.org Fri Jan 16 09:48:21 2026 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Fri, 16 Jan 2026 09:48:21 GMT Subject: RFR: 8375443: AVX-512: Disabling through UseSHA doesn't affect UseSHA3Intrinsics In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 08:41:20 GMT, Ramkumar Sunderbabu wrote: > UseSHA flag is not respected while enabling/disabling UseSHA3Intrinsics flag in x86 builds. > Added UseSHA in the mix. > > Testing: Only Basic testing done. I will run more compiler related testing. Thank you for fixing this bug, @rsunderbabu! Your code changes look good. I only have cosmetic suggestions. However, since this is a bug, please add a regression test. [`compiler/arguments/TestUseCountTrailingZerosInstructionOnSupportedCPU.java`](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/arguments/TestUseCountTrailingZerosInstructionOnSupportedCPU.java) should be a good inspiration. src/hotspot/cpu/x86/vm_version_x86.cpp line 2: > 1: /* > 2: * Copyright (c) 1997, 2027, Oracle and/or its affiliates. All rights reserved. Suggestion: * Copyright (c) 1997, 2026, Oracle and/or its affiliates. All rights reserved. Not so fast ;) src/hotspot/cpu/x86/vm_version_x86.cpp line 1349: > 1347: } > 1348: } else if (UseSHA3Intrinsics) { > 1349: warning("Intrinsics for SHA3-224, SHA3-256, SHA3-384 and SHA3-512 crypto hash functions not available on this CPU."); This warning might be a bit misleading when `-XX:-UseSHA -XX:+UseSHA3Intrinsics` is passed on a machine that supports the instructions. src/hotspot/cpu/x86/vm_version_x86.cpp line 1351: > 1349: warning("Intrinsics for SHA3-224, SHA3-256, SHA3-384 and SHA3-512 crypto hash functions not available on this CPU."); > 1350: FLAG_SET_DEFAULT(UseSHA3Intrinsics, false); > 1351: } Suggestion: if (UseSHA && supports_evex() && supports_avx512bw()) { if (FLAG_IS_DEFAULT(UseSHA3Intrinsics)) { FLAG_SET_DEFAULT(UseSHA3Intrinsics, true); UseSHA3Intrinsics = true; } } else if (UseSHA3Intrinsics) { warning("Intrinsics for SHA3-224, SHA3-256, SHA3-384 and SHA3-512 crypto hash functions not available on this CPU."); FLAG_SET_DEFAULT(UseSHA3Intrinsics, false); } Please fix the indentation to two spaces. ------------- Changes requested by mhaessig (Committer). PR Review: https://git.openjdk.org/jdk/pull/29266#pullrequestreview-3669825317 PR Review Comment: https://git.openjdk.org/jdk/pull/29266#discussion_r2697706053 PR Review Comment: https://git.openjdk.org/jdk/pull/29266#discussion_r2697735783 PR Review Comment: https://git.openjdk.org/jdk/pull/29266#discussion_r2697719691 From rsunderbabu at openjdk.org Fri Jan 16 10:16:40 2026 From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu) Date: Fri, 16 Jan 2026 10:16:40 GMT Subject: RFR: 8375443: AVX-512: Disabling through UseSHA doesn't affect UseSHA3Intrinsics In-Reply-To: References: Message-ID: <-JGEACGo2GAnuuUDuyauSMmYBRwakNoTmSz37eCwm6E=.74d37192-c8a1-466f-a763-554a36f52378@github.com> On Fri, 16 Jan 2026 09:43:10 GMT, Manuel H?ssig wrote: >> UseSHA flag is not respected while enabling/disabling UseSHA3Intrinsics flag in x86 builds. >> Added UseSHA in the mix. >> >> Testing: Only Basic testing done. I will run more compiler related testing. > > src/hotspot/cpu/x86/vm_version_x86.cpp line 1349: > >> 1347: } >> 1348: } else if (UseSHA3Intrinsics) { >> 1349: warning("Intrinsics for SHA3-224, SHA3-256, SHA3-384 and SHA3-512 crypto hash functions not available on this CPU."); > > This warning might be a bit misleading when `-XX:-UseSHA -XX:+UseSHA3Intrinsics` is passed on a machine that supports the instructions. This warning is consistent across platforms. I will probably create another bug and fix this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29266#discussion_r2697862564 From dlong at openjdk.org Fri Jan 16 10:17:41 2026 From: dlong at openjdk.org (Dean Long) Date: Fri, 16 Jan 2026 10:17:41 GMT Subject: RFR: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) [v6] In-Reply-To: <4jqYbz9oL1Klo7KdXSdWPdNT9cD0LrpHPf6u4NfKlDg=.26a204e9-8f6f-4ff5-af92-671974b1a9c9@github.com> References: <_jevSayhH-Khj6mA5jxNQKSzYwEctDg0dDgFTHltHUg=.8e8356c9-7781-4845-bd1a-d9fc3b6f107d@github.com> <4jqYbz9oL1Klo7KdXSdWPdNT9cD0LrpHPf6u4NfKlDg=.26a204e9-8f6f-4ff5-af92-671974b1a9c9@github.com> Message-ID: On Fri, 16 Jan 2026 05:43:40 GMT, Guanqiang Han wrote: >> My understanding is that we need at least one stringStream, and the code is trying to avoid having two stacked stringStreams, which would mean extra memory footprint and copying. So I agree the proposed is_buffered() is really a proxy for "do I have a stringStream?" because bufferedStream does not guarantee coherent output by itself. What if we just live with the inefficiency of having two stringStreams for now? > > Thanks, ok, I?ll drop the is_buffered() change. Would it be acceptable to go back to my earlier proposal: pass an explicit ?buffering/coherent-output? parameter at the call site so we can use an existing stringStream and avoid double buffering? I would be OK with that, since we failed to come up with a better solution, but I suspect that we will run into this same issue again, and having to pass an extra flag through multiple layers every time does not feel elegant. Trying to hide the extra flag using something like a THREAD_LOCAL seems hacky as well. I think using a lambda expression would work but may be overkill. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29186#discussion_r2697862305 From dholmes at openjdk.org Fri Jan 16 11:48:43 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 16 Jan 2026 11:48:43 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v7] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Thu, 15 Jan 2026 23:55:53 GMT, Larry Cable 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: fixed test issue as identified by @dholmes Alan - jcmds are considered diagnostics and don't require CSR requests. But yes this needs documenting. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29048#issuecomment-3759672504 From alanb at openjdk.org Fri Jan 16 12:12:52 2026 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 16 Jan 2026 12:12:52 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v7] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Fri, 16 Jan 2026 11:45:25 GMT, David Holmes wrote: > Alan - jcmds are considered diagnostics and don't require CSR requests. But yes this needs documenting. They are diagnostic commands but we have been using CSRs to track additions as they are a documented interface, e.g. [JDK-8370204](https://bugs.openjdk.org/browse/JDK-8370204) and [JDK-833942](https://bugs.openjdk.org/browse/JDK-8339420). I may have it wrong as I thought we wanted a CSR for additions/changes to the CLI. (The output of a command is a different topic of course. Most commands yield unstructured/plain text that is not intended to be parsed, no CSR if the output changes. However there are a few commands that produce binary files or structured output that are intended to be parsed, and so are a supported interface for the CSR to track.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/29048#issuecomment-3759757569 From thartmann at openjdk.org Fri Jan 16 13:43:47 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 16 Jan 2026 13:43:47 GMT Subject: RFR: 8375534: Debug method 'pp' should support compressed oops Message-ID: The debug method `pp` is currently not able to handle compressed oops. This should fix it. The code is similar to `BlockLocationPrinter::print_location`. **Before:** (rr) call (void*) pp(0x6b9c08fc8) "Executing pp" java.lang.Runtime$Version {0x00000006b9c08fc8} - klass: 'java/lang/Runtime$Version' - flags: - ---- fields (total size 4 words): - private final value 'version' 'Ljava/util/List;' @12 a 'java/util/ImmutableCollections$List12'{0x00000006b9c2cbb8} (0xd7385977) - private final value 'pre' 'Ljava/util/Optional;' @16 a 'java/util/Optional'{0x00000006b9c2cbd0} (0xd738597a) - private final value 'build' 'Ljava/util/Optional;' @20 a 'java/util/Optional'{0x00000006b9c0a118} (0xd7381423) - private final value 'optional' 'Ljava/util/Optional;' @24 a 'java/util/Optional'{0x00000006b9c2cbe8} (0xd738597d) $1 = (void *) 0x0 (rr) call (void*) pp(0xd7381423) "Executing pp" The program being debugged received signal SIGSEGV, Segmentation fault while in a function called from GDB. GDB has restored the context to what it was before the call. To change this behavior use "set unwind-on-signal off". Evaluation of the expression containing the function (pp(long)) will be abandoned. **After:** ```(rr) call (void*) pp(0x6b9c08fc8) "Executing pp" java.lang.Runtime$Version {0x00000006b9c08fc8} - klass: 'java/lang/Runtime$Version' - flags: - ---- fields (total size 4 words): - private final value 'version' 'Ljava/util/List;' @12 a 'java/util/ImmutableCollections$List12'{0x00000006b9c2cbb8} (0xd7385977) - private final value 'pre' 'Ljava/util/Optional;' @16 a 'java/util/Optional'{0x00000006b9c2cbd0} (0xd738597a) - private final value 'build' 'Ljava/util/Optional;' @20 a 'java/util/Optional'{0x00000006b9c0a118} (0xd7381423) - private final value 'optional' 'Ljava/util/Optional;' @24 a 'java/util/Optional'{0x00000006b9c2cbe8} (0xd738597d) $1 = (void *) 0x0 (rr) call (void*) pp(0xd7381423) "Executing pp" 3610776611 is a compressed pointer to object: java.util.Optional {0x00000006b9c0a118} - klass: 'java/util/Optional' - flags: - ---- fields (total size 3 words): - private final value 'value' 'Ljava/lang/Object;' @16 null (0x00000000) $2 = (void *) 0x0 Thanks, Tobias ------------- Commit messages: - JDK-8375534 Changes: https://git.openjdk.org/jdk/pull/29280/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29280&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375534 Stats: 14 lines in 1 file changed: 14 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29280.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29280/head:pull/29280 PR: https://git.openjdk.org/jdk/pull/29280 From alanb at openjdk.org Fri Jan 16 13:49:46 2026 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 16 Jan 2026 13:49:46 GMT Subject: RFR: 8373120: Virtual thread stuck in BLOCKED state In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 17:42:33 GMT, Patricio Chilano Mateo wrote: > Please review the following patch. This fixes a bug in how we handle state changes for the timed `Object.wait` case in `afterYield`, which can leave a virtual thread stuck in the `BLOCKED` state. It can be triggered by two consecutive calls to timed `Object.wait`, if the first call receives a notification and the second call relies on the timeout task to wake up the thread. I added the full sequence of events that leads to the vthread getting stuck in JBS. > > The fix is to check for `notified` and attempt to change the state to `BLOCKED` inside the synchronized block. This guarantees that we don't change the state of an already new timed `Object.wait` call. > > The PR includes a new test which reproduces the issue when run several times in mach5. It's a hybrid of my original repro test and another one created by @AlanBateman. > > Thanks, > Patricio Great sleuthing, this was a really hard one to diagnose. src/java.base/share/classes/java/lang/VirtualThread.java line 644: > 642: setState(newState = TIMED_WAIT); > 643: // May have been notified while in transition. This must be done while > 644: // holding the monitor to avoid changing the state of a new timed wait call. "to avoid changing the state of a new timed wait call". It might be clearer to say move to the blocked state before the timeout task can execute. src/java.base/share/classes/java/lang/VirtualThread.java line 652: > 650: // may have been unblocked already > 651: if (blockPermit && compareAndSetState(BLOCKED, UNBLOCKED)) { > 652: lazySubmitRunContinuation(); Moving to lazySubmit is good here, this helps improve the chance of continuing with the current platform thread as the carrier when notified and unblocked during the transition. test/jdk/java/lang/Thread/virtual/stress/NotifiedThenTimedOutWait.java line 77: > 75: } > 76: }); > 77: var pthread = Thread.ofPlatform().start(() -> { A future maintainer may wonder why the notify is done in a platform thread in race1, and a virtual thread in race2. We should probably add a comment. ------------- PR Review: https://git.openjdk.org/jdk/pull/29255#pullrequestreview-3670903428 PR Review Comment: https://git.openjdk.org/jdk/pull/29255#discussion_r2698546064 PR Review Comment: https://git.openjdk.org/jdk/pull/29255#discussion_r2698550733 PR Review Comment: https://git.openjdk.org/jdk/pull/29255#discussion_r2698564280 From mbaesken at openjdk.org Fri Jan 16 14:23:51 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 16 Jan 2026 14:23:51 GMT Subject: RFR: 8369187: Add wrapper for that forbids use of global allocation and deallocation functions [v3] In-Reply-To: References: Message-ID: On Sun, 16 Nov 2025 01:10:40 GMT, Kim Barrett wrote: >> 8369187: Add wrapper for that forbids use of global allocation and deallocation functions >> >> Please review this change that adds `cppstdlib/new.hpp` as a wrapper for >> including ``. All existing inclusions of `` are changed to include >> the new wrapper. >> >> In additional to including ``, this wrapper also provides deprecation >> declarations to prevent the use of some facilities by HotSpot code. >> >> However, those deprecations need to be conditionalized to not apply to gtests, >> so this change also adds a macro definition provided by the build system for >> use in detecting that a header is being included by a gtest. >> >> Testing: mach5 tier1 > > Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Merge branch 'master' into wrap-stdlib-new > - poison implicit alloc/dealloc in globalDefinitions > - Merge branch 'master' into wrap-stdlib-new > - further conditionalize deprecation of hardare interference sizes > - add wrapper for When experimenting with the link time gc OpenJDK configure option , I notice that the 2 symbols hardware_destructive_interference_size / fgrep hardware_constructive_interference_size are eliminated more then 2000 (!) times from the objects of libjvm (I enabled verbose priting to see what is eliminated) fgrep hardware_destructive_interference_size build.log | wc -l 2681 fgrep hardware_constructive_interference_size build.log | wc -l 2681 With default settings (no linktime gc) I see the symbol now in HS (fortunately only 2 times , not 2000+) strings /linuxx86_64/jdk-opt/images/jdk/lib/server/libjvm.so | grep hardware_constructive_interference_size _ZSt39hardware_constructive_interference_size _ZSt39hardware_constructive_interference_size Was this intended to got into libjvm.so ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28250#issuecomment-3760241677 From lmesnik at openjdk.org Fri Jan 16 16:21:20 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 16 Jan 2026 16:21:20 GMT Subject: RFR: 8375443: AVX-512: Disabling through UseSHA doesn't affect UseSHA3Intrinsics In-Reply-To: References: Message-ID: <-Ik5Xn15O1Oney_cGHqrknm1bPJur7FfiDjSlV3nWJU=.22e1d342-ef2c-4665-9eed-8a88b322c052@github.com> On Fri, 16 Jan 2026 08:41:20 GMT, Ramkumar Sunderbabu wrote: > UseSHA flag is not respected while enabling/disabling UseSHA3Intrinsics flag in x86 builds. > Added UseSHA in the mix. > > Testing: Only Basic testing done. I will run more compiler related testing. Changes requested by lmesnik (Reviewer). src/hotspot/cpu/x86/vm_version_x86.cpp line 1343: > 1341: } > 1342: > 1343: if (UseSHA && supports_evex() && supports_avx512bw()) { Please add the regression test or add 'noreg-*' label if think it is not required. Grep for CommandLineOptionTest to find examples. ------------- PR Review: https://git.openjdk.org/jdk/pull/29266#pullrequestreview-3671660988 PR Review Comment: https://git.openjdk.org/jdk/pull/29266#discussion_r2699142943 From pchilanomate at openjdk.org Fri Jan 16 17:07:34 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 16 Jan 2026 17:07:34 GMT Subject: RFR: 8373120: Virtual thread stuck in BLOCKED state [v2] In-Reply-To: References: Message-ID: > Please review the following patch. This fixes a bug in how we handle state changes for the timed `Object.wait` case in `afterYield`, which can leave a virtual thread stuck in the `BLOCKED` state. It can be triggered by two consecutive calls to timed `Object.wait`, if the first call receives a notification and the second call relies on the timeout task to wake up the thread. I added the full sequence of events that leads to the vthread getting stuck in JBS. > > The fix is to check for `notified` and attempt to change the state to `BLOCKED` inside the synchronized block. This guarantees that we don't change the state of an already new timed `Object.wait` call. > > The PR includes a new test which reproduces the issue when run several times in mach5. It's a hybrid of my original repro test and another one created by @AlanBateman. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: add comment in test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29255/files - new: https://git.openjdk.org/jdk/pull/29255/files/39d7ac79..b69a40f1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29255&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29255&range=00-01 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29255.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29255/head:pull/29255 PR: https://git.openjdk.org/jdk/pull/29255 From pchilanomate at openjdk.org Fri Jan 16 17:12:21 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 16 Jan 2026 17:12:21 GMT Subject: RFR: 8373120: Virtual thread stuck in BLOCKED state [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 13:37:49 GMT, Alan Bateman wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> add comment in test > > src/java.base/share/classes/java/lang/VirtualThread.java line 644: > >> 642: setState(newState = TIMED_WAIT); >> 643: // May have been notified while in transition. This must be done while >> 644: // holding the monitor to avoid changing the state of a new timed wait call. > > "to avoid changing the state of a new timed wait call". It might be clearer to say move to the blocked state before the timeout task can execute. I wanted to keep it more general because the thread can also run again due to notification+unblock or interruption. > test/jdk/java/lang/Thread/virtual/stress/NotifiedThenTimedOutWait.java line 77: > >> 75: } >> 76: }); >> 77: var pthread = Thread.ofPlatform().start(() -> { > > A future maintainer may wonder why the notify is done in a platform thread in race1, and a virtual thread in race2. We should probably add a comment. Added a comment. Maybe we should use `ThreadLocalRandom` in both cases to decide whether the notifier should be a platform or virtual thread? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29255#discussion_r2699306583 PR Review Comment: https://git.openjdk.org/jdk/pull/29255#discussion_r2699307350 From pchilanomate at openjdk.org Fri Jan 16 17:12:15 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 16 Jan 2026 17:12:15 GMT Subject: RFR: 8373120: Virtual thread stuck in BLOCKED state In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 01:50:50 GMT, David Holmes wrote: > @pchilano I took a look at this out of interest but there is nothing Hotspot related to review. The state machine for VTs is too complex for me to comment on the actual fix - though I understand how the timedWaitLock forces the calls to be serialized. > > It did make we wonder why the timed-park doesn't need any locking. Can't it have a similar problem if the virtual thread is unparked before the carrier can set the state to TIMED_PARK? > Thanks for looking at this anyway David. Yes, that case is fine. Just to add to Alan's answer, the unparker can set `parkPermit` but it won't be able to change the state and submit the vthread to run again while in `TIMED_PARKING` state. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29255#issuecomment-3760993471 From sviswanathan at openjdk.org Fri Jan 16 18:27:31 2026 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Fri, 16 Jan 2026 18:27:31 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v5] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 01:22:39 GMT, Mohamed Issa wrote: >> Intel® 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: > > Remove unnecessary CMOV blocks and adjust predicates involving APX and AVX10.2 src/hotspot/cpu/x86/assembler_x86.cpp line 7357: > 7355: } > 7356: > 7357: void Assembler::ucomxss(XMMRegister dst, Address src) { ucomxss should be named as vucomxss. ucomxsd should be named as vucomxsd. src/hotspot/cpu/x86/x86.ad line 1703: > 1701: static void emit_cmpfp3(MacroAssembler* masm, Register dst) { > 1702: // If any floating point comparison instruction is used, unordered case always triggers jump > 1703: // For below condition, CF=1 is true when at least one input is NaN // for lowercase f in for. test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java line 64: > 62: @IR(counts = {IRNode.X86_CMOVEL_IMM01UCFE, "1"}, > 63: applyIfPlatform = {"x64", "true"}, > 64: applyIfCPUFeature = {"apx_f", "true"}, Need to include avx10_2 check here as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2699354660 PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2699427353 PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2699527070 From duke at openjdk.org Fri Jan 16 18:52:11 2026 From: duke at openjdk.org (Larry Cable) Date: Fri, 16 Jan 2026 18:52:11 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v8] In-Reply-To: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: > 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 jcmd.md to document -location flag ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29048/files - new: https://git.openjdk.org/jdk/pull/29048/files/032897f0..d29848e8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=06-07 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 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 vlivanov at openjdk.org Fri Jan 16 19:52:41 2026 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 16 Jan 2026 19:52:41 GMT Subject: RFR: 8375534: Debug method 'pp' should support compressed oops In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 13:34:59 GMT, Tobias Hartmann wrote: > The debug method `pp` is currently not able to handle compressed oops. This should fix it. The code is similar to `BlockLocationPrinter::print_location`. > > **Before:** > > > (rr) call (void*) pp(0x6b9c08fc8) > > "Executing pp" > java.lang.Runtime$Version > {0x00000006b9c08fc8} - klass: 'java/lang/Runtime$Version' - flags: > > - ---- fields (total size 4 words): > - private final value 'version' 'Ljava/util/List;' @12 a 'java/util/ImmutableCollections$List12'{0x00000006b9c2cbb8} (0xd7385977) > - private final value 'pre' 'Ljava/util/Optional;' @16 a 'java/util/Optional'{0x00000006b9c2cbd0} (0xd738597a) > - private final value 'build' 'Ljava/util/Optional;' @20 a 'java/util/Optional'{0x00000006b9c0a118} (0xd7381423) > - private final value 'optional' 'Ljava/util/Optional;' @24 a 'java/util/Optional'{0x00000006b9c2cbe8} (0xd738597d) > $1 = (void *) 0x0 > (rr) call (void*) pp(0xd7381423) > > "Executing pp" > The program being debugged received signal SIGSEGV, Segmentation fault > while in a function called from GDB. GDB has restored the context > to what it was before the call. To change this behavior use > "set unwind-on-signal off". Evaluation of the expression containing > the function (pp(long)) will be abandoned. > > > **After:** > ```(rr) call (void*) pp(0x6b9c08fc8) > > "Executing pp" > java.lang.Runtime$Version > {0x00000006b9c08fc8} - klass: 'java/lang/Runtime$Version' - flags: > > - ---- fields (total size 4 words): > - private final value 'version' 'Ljava/util/List;' @12 a 'java/util/ImmutableCollections$List12'{0x00000006b9c2cbb8} (0xd7385977) > - private final value 'pre' 'Ljava/util/Optional;' @16 a 'java/util/Optional'{0x00000006b9c2cbd0} (0xd738597a) > - private final value 'build' 'Ljava/util/Optional;' @20 a 'java/util/Optional'{0x00000006b9c0a118} (0xd7381423) > - private final value 'optional' 'Ljava/util/Optional;' @24 a 'java/util/Optional'{0x00000006b9c2cbe8} (0xd738597d) > $1 = (void *) 0x0 > (rr) call (void*) pp(0xd7381423) > > "Executing pp" > 3610776611 is a compressed pointer to object: java.util.Optional > {0x00000006b9c0a118} - klass: 'java/util/Optional' - flags: > > - ---- fields (total size 3 words): > - private final value 'value' 'Ljava/lang/Object;' @16 null (0x00000000) > $2 = (void *) 0x0 > > > Thanks, > Tobias Overall, looks good. `BlockLocationPrinter::print_location()` has very similar code, but uses a more elaborate check in place of `Universe::heap()->is_in(o)`. Any particular reason `LocationPrinter::is_valid_obj()` doesn't fit `pp()`? Otherwise, it makes sense to unify the code. ------------- PR Review: https://git.openjdk.org/jdk/pull/29280#pullrequestreview-3672476297 From sparasa at openjdk.org Fri Jan 16 20:05:00 2026 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Fri, 16 Jan 2026 20:05:00 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v12] In-Reply-To: References: Message-ID: <5TOCDJo87eQTeAT-DRPgoAsEza_1fgaEApMW7OfObqQ=.263ac729-d5d8-4236-980d-d4613a8a7e84@github.com> > 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: Update the ArraysFill JMH benchmark ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28442/files - new: https://git.openjdk.org/jdk/pull/28442/files/1b401dcf..5edff7f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28442&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28442&range=10-11 Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28442.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28442/head:pull/28442 PR: https://git.openjdk.org/jdk/pull/28442 From dholmes at openjdk.org Fri Jan 16 20:09:35 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 16 Jan 2026 20:09:35 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v7] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Fri, 16 Jan 2026 12:10:44 GMT, Alan Bateman wrote: > They are diagnostic commands but we have been using CSRs to track additions as they are a documented interface, e.g. [JDK-8370204](https://bugs.openjdk.org/browse/JDK-8370204) and [JDK-833942](https://bugs.openjdk.org/browse/JDK-8339420). I may have it wrong as I thought we wanted a CSR for additions/changes to the CLI. I guess it depends on who is involved with adding/modifying the command. There was no CSR request for [JDK-8344009](https://bugs.openjdk.org/browse/JDK-8344009), but there was for [JDK-8336401](https://bugs.openjdk.org/browse/JDK-8336401). I originally requested [JDK-8316922](https://bugs.openjdk.org/browse/JDK-8316922) but was then reminded that we don't need CSR requests in this area. So it is all a bit ad-hoc. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29048#issuecomment-3761610159 From sparasa at openjdk.org Fri Jan 16 20:14:31 2026 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Fri, 16 Jan 2026 20:14:31 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v13] In-Reply-To: References: Message-ID: > 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: Update ALL of ArraysFill JMH micro ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28442/files - new: https://git.openjdk.org/jdk/pull/28442/files/5edff7f7..620ae44e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28442&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28442&range=11-12 Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28442.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28442/head:pull/28442 PR: https://git.openjdk.org/jdk/pull/28442 From dholmes at openjdk.org Fri Jan 16 20:23:53 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 16 Jan 2026 20:23:53 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v8] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Fri, 16 Jan 2026 18:52:11 GMT, Larry Cable 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 jcmd.md to document -location flag Changes requested by dholmes (Reviewer). src/jdk.jcmd/share/man/jcmd.md line 807: > 805: `R` = has been redefined, `S` = is shared class (BOOLEAN, false) > 806: > 807: - `-location`: (Optional) Print the location of the class file from which the class is loaded (if available) Suggestion: - `-location`: (Optional) Print the location from which the class was loaded (if available). src/jdk.jcmd/share/man/jcmd.md line 808: > 806: > 807: - `-location`: (Optional) Print the location of the class file from which the class is loaded (if available) > 808: If provided by its defining ClassLoader, this option will print a URL specifying the location of the I don't think this is an accurate description. The location comes from the `CodeSource` which comes from the `ProtectionDomain`, which is supplied to the `ClassLoader` when defining the Class. If we want to be specific here then I would suggest: If available from the Class (through its ProtectionDomain's CodeSource), this option will print ... ------------- PR Review: https://git.openjdk.org/jdk/pull/29048#pullrequestreview-3672561766 PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2699840495 PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2699855216 From sparasa at openjdk.org Fri Jan 16 20:26:42 2026 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Fri, 16 Jan 2026 20:26:42 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v11] In-Reply-To: References: <07NHyGU8bmzafUXXdLP3X81f7OZrqP6JcXZmtPh78J4=.5551605a-ade3-4190-9cf8-ae2a68857694@github.com> Message-ID: On Tue, 6 Jan 2026 08:47:56 GMT, Emanuel Peter wrote: >> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: >> >> cleanup code related to labels > > 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? Hi Emanuel (@eme64), Please see the updated data as you suggested. This PR (ArrayFill intrinsic with unmasked stores) only applies for: - Arrays of data type `byte`, `short` and `int` only - size <= 128 bytes for `MaxVectorSize=32` or `AVX3Threshold > 0` - size <=192 bytes for `MaxVectorSize=64` or `AVX3Threshold = 0` Thus, the performance data using your vector bulk operations JMH micro was obtained for sizes upto 200. Below are the plots for array fill with a variable value starting from a variable offset for `MaxVectorSize=32` @Benchmark @OperationsPerInvocation(REPETITIONS) public void fill_var_byte_arrays_fill() { for (int r = 0; r < REPETITIONS; r++) { int offset_store = offsetStore(r) + REGION_SIZE + REGION_2_BYTE_OFFSET; Arrays.fill(aB, offset_store, offset_store + NUM_ACCESS_ELEMENTS, varB); } } image image image [continued below with more data] ------------- PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3761659799 From sparasa at openjdk.org Fri Jan 16 20:34:00 2026 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Fri, 16 Jan 2026 20:34:00 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v13] In-Reply-To: References: Message-ID: <_9OkAqddCk8CbA-51qgdecI23f03MBsZE9kiES5cU0I=.d1adead1-45ff-40be-b139-2f9fa32c7d42@github.com> On Fri, 16 Jan 2026 20:14:31 GMT, Srinivas Vamsi Parasa 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: > > Update ALL of ArraysFill JMH micro Also, we can see the benefit of using unmasked stores (this PR) instead of masked vector stores (existing implementation) when we update the ArraysFill.java JMH micro-benchmark to perform fill (write) followed by read of the filled data as shown below using short array fill as an example: @Benchmark public short testShortFill() { Arrays.fill(testShortArray, (short) -1); return (short) (testShortArray[0] + testShortArray[size - 1]); } **(Higher is better)** Benchmark (ops/ms) MaxVectorSize = 32 | SIZE | +OptimizeFill (Masked Store) | +OptimizeFill (Unmasked Store - This PR) | Delta -- | -- | -- | -- | -- ArraysFill.testByteFill | 1 | 175381 | 342456 | 95% ArraysFill.testByteFill | 10 | 175421 | 264607 | 51% ArraysFill.testByteFill | 20 | 175447 | 271111 | 55% ArraysFill.testByteFill | 30 | 175454 | 253351 | 44% ArraysFill.testByteFill | 40 | 162429 | 273043 | 68% ArraysFill.testByteFill | 50 | 162443 | 251734 | 55% ArraysFill.testByteFill | 60 | 162454 | 248156 | 53% ArraysFill.testByteFill | 70 | 156659 | 236497 | 51% ArraysFill.testByteFill | 80 | 175403 | 269433 | 54% ArraysFill.testByteFill | 90 | 175422 | 230276 | 31% ArraysFill.testByteFill | 100 | 168662 | 252394 | 50% ArraysFill.testByteFill | 110 | 146182 | 217917 | 49% ArraysFill.testByteFill | 120 | 168693 | 239126 | 42% ArraysFill.testByteFill | 130 | 162378 | 166159 | 2% ArraysFill.testByteFill | 140 | 156569 | 168296 | 7% ArraysFill.testByteFill | 150 | 151214 | 167388 | 11% ArraysFill.testByteFill | 160 | 156594 | 173529 | 11% ArraysFill.testByteFill | 170 | 156590 | 167976 | 7% ArraysFill.testByteFill | 180 | 156561 | 173015 | 11% ArraysFill.testByteFill | 190 | 156601 | 173073 | 11% ArraysFill.testByteFill | 200 | 168277 | 174293 | 4% ArraysFill.testIntFill | 1 | 175403 | 334460 | 91% ArraysFill.testIntFill | 10 | 162437 | 273799 | 69% ArraysFill.testIntFill | 20 | 156636 | 273483 | 75% ArraysFill.testIntFill | 30 | 162440 | 243303 | 50% ArraysFill.testIntFill | 40 | 156592 | 175162 | 12% ArraysFill.testIntFill | 50 | 156585 | 168433 | 8% ArraysFill.testIntFill | 60 | 151193 | 195235 | 29% ArraysFill.testIntFill | 70 | 141406 | 167060 | 18% ArraysFill.testIntFill | 80 | 141406 | 167119 | 18% ArraysFill.testIntFill | 90 | 141437 | 166976 | 18% ArraysFill.testIntFill | 100 | 168349 | 173943 | 3% ArraysFill.testIntFill | 110 | 132864 | 173096 | 30% ArraysFill.testIntFill | 120 | 128972 | 173722 | 35% ArraysFill.testIntFill | 130 | 128958 | 149835 | 16% ArraysFill.testIntFill | 140 | 167934 | 165903 | -1% ArraysFill.testIntFill | 150 | 121799 | 133351 | 9% ArraysFill.testIntFill | 160 | 121824 | 154654 | 27% ArraysFill.testIntFill | 170 | 121800 | 163515 | 34% ArraysFill.testIntFill | 180 | 121770 | 150235 | 23% ArraysFill.testIntFill | 190 | 121808 | 145138 | 19% ArraysFill.testIntFill | 200 | 112433 | 142084 | 26% ArraysFill.testShortFill | 1 | 99696 | 309697 | 211% ArraysFill.testShortFill | 10 | 175433 | 290773 | 66% ArraysFill.testShortFill | 20 | 175417 | 270345 | 54% ArraysFill.testShortFill | 30 | 162459 | 257180 | 58% ArraysFill.testShortFill | 40 | 175438 | 273348 | 56% ArraysFill.testShortFill | 50 | 162445 | 272307 | 68% ArraysFill.testShortFill | 60 | 168669 | 241798 | 43% ArraysFill.testShortFill | 70 | 156509 | 174347 | 11% ArraysFill.testShortFill | 80 | 151207 | 168424 | 11% ArraysFill.testShortFill | 90 | 162332 | 197780 | 22% ArraysFill.testShortFill | 100 | 156583 | 174738 | 12% ArraysFill.testShortFill | 110 | 151147 | 175170 | 16% ArraysFill.testShortFill | 120 | 167078 | 191352 | 15% ArraysFill.testShortFill | 130 | 146102 | 171682 | 18% ArraysFill.testShortFill | 140 | 151206 | 203786 | 35% ArraysFill.testShortFill | 150 | 146133 | 167027 | 14% ArraysFill.testShortFill | 160 | 141426 | 167047 | 18% ArraysFill.testShortFill | 170 | 136974 | 167049 | 22% ArraysFill.testShortFill | 180 | 141420 | 173568 | 23% ArraysFill.testShortFill | 190 | 136164 | 172806 | 27% ArraysFill.testShortFill | 200 | 141464 | 167048 | 18% ------------- PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3761712841 From vlivanov at openjdk.org Fri Jan 16 20:36:18 2026 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 16 Jan 2026 20:36:18 GMT Subject: RFR: 8374807: Crash in MethodData::extra_data_lock()+0x0 when running -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp -version [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 18:33:29 GMT, Vladimir Ivanov wrote: >> Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - split long line >> - Merge remote-tracking branch 'upstream/master' into 8374807 >> - fix 8374807 > > src/hotspot/share/runtime/deoptimization.cpp line 2161: > >> 2159: Mutex::_no_safepoint_check_flag); >> 2160: >> 2161: ttyLocker ttyl; > > Does the code still need `ttyLocker`? > > There's only one usage of `tty` and it prints all accumulated info all at once. `xtty` already annotates output with thread info. So, I'd assume that moving `trap_mdo->extra_data_lock()` locker to `trap_mdo` accesses should solve the problem as well. > > (I'm not sure whether a `ttyLocker` is needed or not to avoid interleaving during `tty->print_raw(st.freeze());`, but `ttyLocker` can be placed right before it.) I take my suggestion back. Sorry for the confusion. The code in question populates complex XML structure, so locking is needed to ensure the resulting XML is well-formed. Your previous version looks fine to me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29147#discussion_r2699884865 From dholmes at openjdk.org Fri Jan 16 20:58:22 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 16 Jan 2026 20:58:22 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v8] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: <3q7rDoxI_sOR7g90yvCKG8MFl8SyS1J3Nd8r9wfezgo=.2abaa58e-196d-44f2-b5a5-0a72153614de@github.com> On Fri, 16 Jan 2026 20:20:56 GMT, David Holmes wrote: >> Larry Cable has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8327246: updated jcmd.md to document -location flag > > src/jdk.jcmd/share/man/jcmd.md line 808: > >> 806: >> 807: - `-location`: (Optional) Print the location of the class file from which the class is loaded (if available) >> 808: If provided by its defining ClassLoader, this option will print a URL specifying the location of the > > I don't think this is an accurate description. The location comes from the `CodeSource` which comes from the `ProtectionDomain`, which is supplied to the `ClassLoader` when defining the Class. > > If we want to be specific here then I would suggest: > > If available from the Class (through its ProtectionDomain's CodeSource), this option will print ... And if we don't want to be specific then: If available, this option will print ... Though user's may wonder what makes it available, and how to make it available. I'm also wondering now whether this will show the "original" location, or the actual runtime location e.g CDS archive? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2699938273 From duke at openjdk.org Fri Jan 16 21:42:26 2026 From: duke at openjdk.org (duke) Date: Fri, 16 Jan 2026 21:42:26 GMT Subject: Withdrawn: 8347248: Fingerprinter::size_of_parameters() should not be used for getting number of parameters In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 20:12:20 GMT, Matias Saavedra Silva wrote: > The method size_of_parameters() is sometimes used as if it represents the number of arguments rather than the size in bytes of the arguments. This patch changes some of these instances to the correct result or renames some of the variables to the desired result. Verified with tier 1-5 tests. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/28380 From vlivanov at openjdk.org Fri Jan 16 23:24:20 2026 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 16 Jan 2026 23:24:20 GMT Subject: RFR: 8371711: AArch64: SVE intrinsics for Arrays.sort methods (int, float) In-Reply-To: <8i4snpt_829luK8hB9U6qgJ833kiNK1hPe7IckfaoJ8=.5cd666c6-b4c9-4ff5-bb39-d1243afd61f0@github.com> References: <8i4snpt_829luK8hB9U6qgJ833kiNK1hPe7IckfaoJ8=.5cd666c6-b4c9-4ff5-bb39-d1243afd61f0@github.com> Message-ID: On Fri, 5 Dec 2025 09:44:16 GMT, Bhavana Kilambi wrote: > This patch adds an SVE implementation of primitive array sorting (Arrays.sort()) on AArch64 systems that support SVE. On non-SVE machines, we fall back to the existing Java implementation. > > For smaller arrays (length <= 64), we use insertion sort; for larger arrays we use an SVE-vectorized quicksort partitioner followed by an odd-even transposition cleanup pass. > > The SVE path is enabled by default for int type. For float type, it is available through the experimental flag : > > `-XX:+UnlockExperimentalVMOptions -XX:+UseSVELibSimdSortForFP > ` > Without this flag being enabled, the default Java implementation would be executed for floats (the flag is disabled by default). > > Float is gated due to observed regressions on some small/medium sizes. On larger arrays, the SVE float path shows upto 1.47x speedup on Neoverse V2 and 2.12x on Neoverse V1. > > Following are the performance numbers for **ArraysSort JMH benchmark** - > > **Case A:** Ratio between the scores of master branch and `UseSVELibSimdSortForFP` flag disabled (which is the default). > **Case B:** Ratio between the scores of master branch and `UseSVELibSimdSortForFP` flag enabled (the int numbers will be the same but this now enables SVE vectorized sorting for floats). > **We would want the ratios to be >= 1 to be at par or better than the default Java implementation (master branch).** > > On Neoverse V1: > > > Benchmark (size) Mode Cnt A B > ArraysSort.floatParallelSort 10 avgt 3 0.98 0.98 > ArraysSort.floatParallelSort 25 avgt 3 1.01 0.83 > ArraysSort.floatParallelSort 50 avgt 3 0.99 0.55 > ArraysSort.floatParallelSort 75 avgt 3 0.99 0.66 > ArraysSort.floatParallelSort 100 avgt 3 0.98 0.66 > ArraysSort.floatParallelSort 1000 avgt 3 1.00 0.84 > ArraysSort.floatParallelSort 10000 avgt 3 1.03 1.52 > ArraysSort.floatParallelSort 100000 avgt 3 1.03 1.46 > ArraysSort.floatParallelSort 1000000 avgt 3 0.98 1.81 > ArraysSort.floatSort 10 avgt 3 1.00 0.98 > ArraysSort.floatSort 25 avgt 3 1.00 0.81 > ArraysSort.floatSort 50 avgt 3 0.99 0.56 > ArraysSort.floatSort 75 avgt 3 0.99 0.65 > ArraysSort.floatSort 100 avgt 3 0.98 0.70 > ArraysSort.floatSort 1000 avgt 3 0.99 0.84 > ArraysSort.floatSort ... Currently, I'm in process of conducting performance testing. I plan to finish it in a week and post for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28675#issuecomment-3762195958 From duke at openjdk.org Sat Jan 17 04:37:51 2026 From: duke at openjdk.org (Ruben) Date: Sat, 17 Jan 2026 04:37:51 GMT Subject: RFR: 8360654: AArch64: Remove redundant dmb from C1 compareAndSet Message-ID: This is duplicate of the PR #26000 which was originally created by @spchee. =========== AtomicLong.CompareAndSet has the following assembly dump snippet which gets emitted from the intermediary LIRGenerator::atomic_cmpxchg: ;; cmpxchg { 0x0000e708d144cf60: mov x8, x2 0x0000e708d144cf64: casal x8, x3, [x0] 0x0000e708d144cf68: cmp x8, x2 ;; 0x1F1F1F1F1F1F1F1F 0x0000e708d144cf6c: mov x8, #0x1f1f1f1f1f1f1f1f ;; } cmpxchg 0x0000e708d144cf70: cset x8, ne // ne = any 0x0000e708d144cf74: dmb ish According to the Oracle Java Specification, AtomicLong.CompareAndSet [1] has the same memory effects as specified by VarHandle.compareAndSet which has the following effects: [2] > Atomically sets the value of a variable to the > newValue with the memory semantics of setVolatile if > the variable's current value, referred to as the witness > value, == the expectedValue, as accessed with the memory > semantics of getVolatile. Hence the release on the store due to setVolatile only occurs if the compare is successful. Since casal already satisfies these requirements, the dmb does not need to occur to ensure memory ordering in case the compare fails and a release does not happen. Hence we remove the dmb from both casl and casw (same logic applies to the non-long variant) This is also reflected by C2 not having a dmb for the same respective method. [1] https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/concurrent/atomic/AtomicLong.html#compareAndSet(long,long) [2] https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/invoke/VarHandle.html#compareAndSet(java.lang.Object...) ------------- Commit messages: - Add "/*with_barrier*/" comments - Address review comments. Refine. - Merge from the main branch - Add cmpxchg_barrier helper - Add comment - Add back in dmb membar for non-LSE - 8360654: AArch64: Remove redundant dmb from C1 compareAndSet Changes: https://git.openjdk.org/jdk/pull/29287/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29287&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360654 Stats: 90 lines in 3 files changed: 60 ins; 5 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/29287.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29287/head:pull/29287 PR: https://git.openjdk.org/jdk/pull/29287 From dlong at openjdk.org Sat Jan 17 05:00:21 2026 From: dlong at openjdk.org (Dean Long) Date: Sat, 17 Jan 2026 05:00:21 GMT Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v6] In-Reply-To: References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com> Message-ID: On Mon, 8 Dec 2025 14:01:48 GMT, Fei Gao wrote: >> In the existing implementation, the static call stub typically emits a sequence like: >> `isb; movk; movz; movz; movk; movz; movz; br`. >> >> This patch reimplements it using a more compact and patch-friendly sequence: >> >> ldr x12, Label_data >> ldr x8, Label_entry >> br x8 >> Label_data: >> 0x00000000 >> 0x00000000 >> Label_entry: >> 0x00000000 >> 0x00000000 >> >> The new approach places the target addresses adjacent to the code and loads them dynamically. This allows us to update the call target by modifying only the data in memory, without changing any instructions. This avoids the need for I-cache flushes or issuing an `isb`[1], which are both relatively expensive operations. >> >> While emitting direct branches in static stubs for small code caches can save 2 instructions compared to the new implementation, modifying those branches still requires I-cache flushes or an `isb`. This patch unifies the code generation by emitting the same static stubs for both small and large code caches. >> >> A microbenchmark (StaticCallStub.java) demonstrates a performance uplift of approximately 43%. >> >> >> Benchmark (length) Mode Cnt Master Patch Units >> StaticCallStubFar.callCompiled 1000 avgt 5 39.346 22.474 us/op >> StaticCallStubFar.callCompiled 10000 avgt 5 390.05 218.478 us/op >> StaticCallStubFar.callCompiled 100000 avgt 5 3869.264 2174.001 us/op >> StaticCallStubNear.callCompiled 1000 avgt 5 39.093 22.582 us/op >> StaticCallStubNear.callCompiled 10000 avgt 5 387.319 217.398 us/op >> StaticCallStubNear.callCompiled 100000 avgt 5 3855.825 2206.923 us/op >> >> >> All tests in Tier1 to Tier3, under both release and debug builds, have passed. >> >> [1] https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-working-with-threads > > Fei Gao 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 11 additional commits since the last revision: > > - Add a newline at the end of test file > - Merge branch 'master' into reimplement-static-call-stub > - Update comments based on Aph's suggestion > - The patch is contributed by @theRealAph > - Merge branch 'master' into reimplement-static-call-stub > - Update comments and fix benchmarks > - The patch is contributed by @theRealAph > - Merge branch 'master' into reimplement-static-call-stub > - Patch 'isb' to 'nop' > - Merge branch 'master' into reimplement-static-call-stub > - ... and 1 more: https://git.openjdk.org/jdk/compare/fa24325c...415495da I'm probably missing something, but even if we assume class redefinition happens at a safepoint, I don't see how that saves us. I think we have an existing problem even without the changes in this PR. Consider: void test() { foo.bar(); // static or opt_virtual call site MyRedefinerHelper.redefineClass("foo", "bar", ....); foo.bar(); } Thread 1 calls foo.bar() for the first time, which redirects to the resolve stub and eventually calls set_to_interpreted with the original Method*. Next, we redefine foo.bar(), and then call foo.bar() again. This is the first time we have hit this call site, so we resolve it, but this time we call set_to_interpreted() on the shares stub with the new redefined Method*. Note that the two call sites use the same stub, because x86 and aarch64 share static stubs. Now, add a second thread calling the same test() method. The second thread can be executing in the static stub at the same time that the first thread is in the middle of writing a different Method* to the stub. The ISB doesn't save us either. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3762665644 From duke at openjdk.org Sat Jan 17 05:24:53 2026 From: duke at openjdk.org (Ruben) Date: Sat, 17 Jan 2026 05:24:53 GMT Subject: RFR: 8365147: AArch64: Replace DMB + LD + DMB with LDAR for C1 volatile field loads [v4] In-Reply-To: <9y5nQuh1S81hB6VgiwdGdHt2LS3pVzLl_D45PX5ni0M=.238114a7-5e70-4d5c-b4e7-571fb65b2be7@github.com> References: <3a_1QZxP59TuI3FewXHDcR_xWH616tlSpcCf1f4BbP0=.c7570d0a-56a6-424d-a5ea-489318734d99@github.com> <9y5nQuh1S81hB6VgiwdGdHt2LS3pVzLl_D45PX5ni0M=.238114a7-5e70-4d5c-b4e7-571fb65b2be7@github.com> Message-ID: On Wed, 14 Jan 2026 10:58:27 GMT, Andrew Haley wrote: >> also jcstress test suite had been run. > What options did you use to run jcstress? Did you use -XX:TieredStopAtLevel=1? Otherwise it won't use tier1. I only specified the UseLSE option - one run with `-XX:+UseLSE` and one with `-XX:-UseLSE`. The jcstress output indicates that `-XX:TieredStopAtLevel=1` case is already included among other configurations: actor1: C1 actor2: C1 actor1: package group 0, core group 0 actor2: package group 0, core group 1 [-XX:+UseLSE] OK 41395658 187549799 1461353 749003 60477358 split actor1: C1 actor2: C1 actor1: package group 0, core group 0 actor2: package group 0, core group 1 [-XX:+UseLSE, -XX:TieredStopAtLevel=1] OK 338967 525065 6631 3038 95052590 I can re-run the `jcstress` with `-XX:TieredStopAtLevel=1` option added manually, starting it later in January. > This is a string of volatile stores. It'd be nice to get it fixed too. I agree. I have this in my backlog - though might not be able to schedule the work on fixing the stores before April. If you prefer, I would extend this PR once the change for the stores is complete - though initially I was intending to open a separate PR for that. I'm going to be away for a week - returning on the 26th of January. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26748#issuecomment-3762684700 From duke at openjdk.org Sat Jan 17 05:44:00 2026 From: duke at openjdk.org (Ruben) Date: Sat, 17 Jan 2026 05:44:00 GMT Subject: RFR: 8372942: AArch64: Set JVM flags for Neoverse V3AE core In-Reply-To: <8eI5E6cyFbIzKfiWurr2ovAUQEML2LDiJIW11BFX27w=.962bede5-2cc2-4e90-97f9-4953750f4b11@github.com> References: <8eI5E6cyFbIzKfiWurr2ovAUQEML2LDiJIW11BFX27w=.962bede5-2cc2-4e90-97f9-4953750f4b11@github.com> Message-ID: On Wed, 14 Jan 2026 09:02:33 GMT, Andrew Haley wrote: > I only see one here, the model_is. The `model_is` checks two values: `_model` and `_model2` - https://github.com/openjdk/jdk/blob/0dd5b59194f32f54c2ec6572833f45e1402515ba/src/hotspot/cpu/aarch64/vm_version_aarch64.hpp#L181 The switch statement would have to happen for both of these. > Maybe, if it's made as simple as possible. I'm thinking of `bool is_model_any_of(std::initializer_list list)` which would iterate over the list and call `model_is` for each candidate; and also adding names for the model identifiers similarly to this list - https://github.com/openjdk/jdk/blob/0dd5b59194f32f54c2ec6572833f45e1402515ba/src/hotspot/cpu/aarch64/vm_version_aarch64.hpp#L115 >> Would you like this to be changed within this PR? > I think so. I'm going to be away for a week - returning on the 26th of January. I am planning to update this PR during the week I return. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28607#issuecomment-3762702084 From duke at openjdk.org Sat Jan 17 06:24:47 2026 From: duke at openjdk.org (Ruben) Date: Sat, 17 Jan 2026 06:24:47 GMT Subject: RFR: 8373696: AArch64: Refine post-call NOPs In-Reply-To: References: <9G7UQDZGLfV0nhrQSv-a9EMvhIAkCdTB3hA9Pf6hRIo=.59b380be-e009-420e-8f76-7771e205467b@github.com> Message-ID: On Wed, 14 Jan 2026 08:59:14 GMT, Andrew Haley wrote: > It sounds rather complicated. It's important that the performance work we do doesn't over complexify the implementation. Whatever we do should be proportionate to the scale of the problem. Post-call NOPs are not a huge deal. > Why not use MOVN, and put the data into a stub at the end of the nmethod? If the data is stored in the stub code, the method size depends on whether `cb_offset`/`oopmap_index` fit in the respective post-call NOP - if I understand correctly, that would require calculating values of `cb_offset`/`oopmap_index` during the code generation because stub code size should be known prior to allocation in the code cache. It can't be postponed until `NativePostCallNop::patch`. Avoiding the estimation step would simplify the change. Also, referencing the stub code via MOVN - which can be used to store up to 18 bits of metadata - would limit the method size by approximately 1MB (`4 * (1 << 18)`). It might be a reasonable limit for a compiled method, however as far as I understand, right now the limit is `branch_range` (128MB). Would the 1MB limit be acceptable? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28855#issuecomment-3762774275 From jbhateja at openjdk.org Sat Jan 17 11:42:32 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Sat, 17 Jan 2026 11:42:32 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v12] In-Reply-To: <8Z84JAkAC6yVFA_1j82FXuoqn1Gu5qQLBlgbcVDAuLQ=.ec5f98c0-42de-4395-a46e-bb2b0be3c12a@github.com> References: <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com> <8Z84JAkAC6yVFA_1j82FXuoqn1Gu5qQLBlgbcVDAuLQ=.ec5f98c0-42de-4395-a46e-bb2b0be3c12a@github.com> Message-ID: On Fri, 19 Dec 2025 22:48:50 GMT, Paul Sandoz wrote: >> Hi @PaulSandoz , your comments have been addressed. Please let us know if there are other comments. >> Hi @eme64 , Kindly share your comments. > >> @jatin-bhateja Thanks for the ping! I'll put this on the list for review early in 2026 :) > > Same here! Hi @PaulSandoz , your comments have been addressed ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3763199964 From ghan at openjdk.org Sat Jan 17 13:31:43 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Sat, 17 Jan 2026 13:31:43 GMT Subject: RFR: 8374807: Crash in MethodData::extra_data_lock()+0x0 when running -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp -version [v4] In-Reply-To: References: Message-ID: > Please review this change. Thanks! > > Description: > > This change fixes a crash in Deoptimization::uncommon_trap_inner when running with -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp. > > With -XX:-ProfileTraps, create_if_missing is set to false. > https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L2121-L2122 > > When create_if_missing is false, new mdo can not be created when m()->method_data() return null, so get_method_data() may return null . > https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L1911-L1912 > > and trap_mdo can be null as a result > https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L2134-L2136 > > The crash happens here because trap_mdo is null > https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L2157 > > Fix: > > The fix makes acquisition of extra_data_lock conditional on trap_mdo being non-null, preserving the required lock ordering (extra_data_lock before ttyLocker) when an MDO exists. > > Test: > > GHA Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - revert - Merge remote-tracking branch 'upstream/master' into 8374807 - narrow lock scope - Merge remote-tracking branch 'upstream/master' into 8374807 - split long line - Merge remote-tracking branch 'upstream/master' into 8374807 - fix 8374807 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29147/files - new: https://git.openjdk.org/jdk/pull/29147/files/cdc88af1..e065ae56 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29147&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29147&range=02-03 Stats: 4227 lines in 70 files changed: 2638 ins; 859 del; 730 mod Patch: https://git.openjdk.org/jdk/pull/29147.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29147/head:pull/29147 PR: https://git.openjdk.org/jdk/pull/29147 From vklang at openjdk.org Sat Jan 17 16:14:11 2026 From: vklang at openjdk.org (Viktor Klang) Date: Sat, 17 Jan 2026 16:14:11 GMT Subject: RFR: 8373120: Virtual thread stuck in BLOCKED state [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 17:07:34 GMT, Patricio Chilano Mateo wrote: >> Please review the following patch. This fixes a bug in how we handle state changes for the timed `Object.wait` case in `afterYield`, which can leave a virtual thread stuck in the `BLOCKED` state. It can be triggered by two consecutive calls to timed `Object.wait`, if the first call receives a notification and the second call relies on the timeout task to wake up the thread. I added the full sequence of events that leads to the vthread getting stuck in JBS. >> >> The fix is to check for `notified` and attempt to change the state to `BLOCKED` inside the synchronized block. This guarantees that we don't change the state of an already new timed `Object.wait` call. >> >> The PR includes a new test which reproduces the issue when run several times in mach5. It's a hybrid of my original repro test and another one created by @AlanBateman. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > add comment in test src/java.base/share/classes/java/lang/VirtualThread.java line 641: > 639: synchronized (timedWaitLock()) { > 640: byte seqNo = ++timedWaitSeqNo; > 641: timeoutTask = schedule(() -> waitTimeoutExpired(seqNo), timeout, MILLISECONDS); Just a sidenote, I think it would be nice to see if we could eliminate the need for the seqNo if we were able to allocate the timeoutTask before submitting it, then using getAndSet or compareAndExchange to install it in the timeoutTask-field, and on cancellation we can CAS out it to null and only if we succeed we have successfully uninstalled it and can cancel it. Not high priority, but I find it valuable to always have an idea of how to do it differently. This might also make it possible to avoid having to use the timedWaitLock. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29255#discussion_r2701250823 From alanb at openjdk.org Sat Jan 17 19:53:31 2026 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 17 Jan 2026 19:53:31 GMT Subject: RFR: 8373120: Virtual thread stuck in BLOCKED state [v2] In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 16:11:35 GMT, Viktor Klang wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> add comment in test > > src/java.base/share/classes/java/lang/VirtualThread.java line 641: > >> 639: synchronized (timedWaitLock()) { >> 640: byte seqNo = ++timedWaitSeqNo; >> 641: timeoutTask = schedule(() -> waitTimeoutExpired(seqNo), timeout, MILLISECONDS); > > Just a sidenote, I think it would be nice to see if we could eliminate the need for the seqNo if we were able to allocate the timeoutTask before submitting it, then using getAndSet or compareAndExchange to install it in the timeoutTask-field, and on cancellation we can CAS out it to null and only if we succeed we have successfully uninstalled it and can cancel it. Not high priority, but I find it valuable to always have an idea of how to do it differently. This might also make it possible to avoid having to use the timedWaitLock. The seqNo is because the timeout task executes asynchronously, and can be executing when cancelled. It reduces the potential for interference and spurious wakeups when there is tight sequence of waits. There may be better designs, we went through when the changes were baking in the loom repo. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29255#discussion_r2701418098 From alanb at openjdk.org Sat Jan 17 19:53:31 2026 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 17 Jan 2026 19:53:31 GMT Subject: RFR: 8373120: Virtual thread stuck in BLOCKED state [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 17:09:21 GMT, Patricio Chilano Mateo wrote: >> test/jdk/java/lang/Thread/virtual/stress/NotifiedThenTimedOutWait.java line 77: >> >>> 75: } >>> 76: }); >>> 77: var pthread = Thread.ofPlatform().start(() -> { >> >> A future maintainer may wonder why the notify is done in a platform thread in race1, and a virtual thread in race2. We should probably add a comment. > > Added a comment. Maybe we should use `ThreadLocalRandom` in both cases to decide whether the notifier should be a platform or virtual thread? Good idea, could be TLR or just different runs of test but the effective would be adding more timing scenarios to the testing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29255#discussion_r2701419978 From ghan at openjdk.org Sun Jan 18 01:47:26 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Sun, 18 Jan 2026 01:47:26 GMT Subject: RFR: 8374807: Crash in MethodData::extra_data_lock()+0x0 when running -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp -version [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 20:32:34 GMT, Vladimir Ivanov wrote: >> src/hotspot/share/runtime/deoptimization.cpp line 2161: >> >>> 2159: Mutex::_no_safepoint_check_flag); >>> 2160: >>> 2161: ttyLocker ttyl; >> >> Does the code still need `ttyLocker`? >> >> There's only one usage of `tty` and it prints all accumulated info all at once. `xtty` already annotates output with thread info. So, I'd assume that moving `trap_mdo->extra_data_lock()` locker to `trap_mdo` accesses should solve the problem as well. >> >> (I'm not sure whether a `ttyLocker` is needed or not to avoid interleaving during `tty->print_raw(st.freeze());`, but `ttyLocker` can be placed right before it.) > > I take my suggestion back. Sorry for the confusion. > > The code in question populates complex XML structure, so locking is needed to ensure the resulting XML is well-formed. > > Your previous version looks fine to me. Hi @iwanowww, I have restored the previous version. Could you please review it again? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29147#discussion_r2701935133 From ghan at openjdk.org Sun Jan 18 02:41:58 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Sun, 18 Jan 2026 02:41:58 GMT Subject: RFR: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) [v7] In-Reply-To: References: Message-ID: > Please review this change. Thanks! > > **Description:** > > When -XX:+PrintDeoptimizationDetails is enabled, vframeArray.cpp prints interpreted frames under ttyLocker. > https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/runtime/vframeArray.cpp#L493-L503 > In the WizardMode && Verbose branch it calls Method::print_codes() / print_codes_on(). The bytecode printing path may acquire MDOExtraData_lock (rank nosafepoint-1). > https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/interpreter/bytecodeTracer.cpp#L597-L602 > Calling it while holding tty_lock violates the global lock ranking order and triggers a lock rank inversion assertion. > > **Fix:** > > Generate the bytecode dump before taking tty_lock, and print it afterwards under ttyLocker to keep the output coherent while preserving correct lock acquisition order. > To avoid double buffering when the target stream is already a thread-local stringStream, extend BytecodeTracer::print_method_codes with a buffered flag . The new call site uses buffered=false when dumping into the temporary stringStream. > > **Test:** > > GHA Guanqiang Han 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 10 additional commits since the last revision: - revert - Merge remote-tracking branch 'upstream/master' into 8374862 - fix a compile error - remove unnecessary blank line - correct copyright year - Add outputStream::is_buffered() - change variable name - Merge remote-tracking branch 'upstream/master' into 8374862 - fix a compile error - fix 8374862 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29186/files - new: https://git.openjdk.org/jdk/pull/29186/files/ea011598..35cb8b9f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29186&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29186&range=05-06 Stats: 22847 lines in 338 files changed: 12751 ins; 5268 del; 4828 mod Patch: https://git.openjdk.org/jdk/pull/29186.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29186/head:pull/29186 PR: https://git.openjdk.org/jdk/pull/29186 From ghan at openjdk.org Sun Jan 18 02:47:08 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Sun, 18 Jan 2026 02:47:08 GMT Subject: RFR: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) [v8] In-Reply-To: References: Message-ID: > Please review this change. Thanks! > > **Description:** > > When -XX:+PrintDeoptimizationDetails is enabled, vframeArray.cpp prints interpreted frames under ttyLocker. > https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/runtime/vframeArray.cpp#L493-L503 > In the WizardMode && Verbose branch it calls Method::print_codes() / print_codes_on(). The bytecode printing path may acquire MDOExtraData_lock (rank nosafepoint-1). > https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/interpreter/bytecodeTracer.cpp#L597-L602 > Calling it while holding tty_lock violates the global lock ranking order and triggers a lock rank inversion assertion. > > **Fix:** > > Generate the bytecode dump before taking tty_lock, and print it afterwards under ttyLocker to keep the output coherent while preserving correct lock acquisition order. > To avoid double buffering when the target stream is already a thread-local stringStream, extend BytecodeTracer::print_method_codes with a buffered flag . The new call site uses buffered=false when dumping into the temporary stringStream. > > **Test:** > > GHA Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: remove unused code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29186/files - new: https://git.openjdk.org/jdk/pull/29186/files/35cb8b9f..601ff0da Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29186&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29186&range=06-07 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29186.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29186/head:pull/29186 PR: https://git.openjdk.org/jdk/pull/29186 From rsunderbabu at openjdk.org Sun Jan 18 16:01:10 2026 From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu) Date: Sun, 18 Jan 2026 16:01:10 GMT Subject: RFR: 8375443: AVX-512: Disabling through UseSHA doesn't affect UseSHA3Intrinsics [v2] In-Reply-To: References: Message-ID: > UseSHA flag is not respected while enabling/disabling UseSHA3Intrinsics flag in x86 builds. > Added UseSHA in the mix. > > Testing: Only Basic testing done. I will run more compiler related testing. Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision: added test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29266/files - new: https://git.openjdk.org/jdk/pull/29266/files/647d4c09..a7da4fde Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29266&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29266&range=00-01 Stats: 152 lines in 2 files changed: 145 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/29266.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29266/head:pull/29266 PR: https://git.openjdk.org/jdk/pull/29266 From rsunderbabu at openjdk.org Sun Jan 18 16:18:55 2026 From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu) Date: Sun, 18 Jan 2026 16:18:55 GMT Subject: RFR: 8375443: AVX-512: Disabling through UseSHA doesn't affect UseSHA3Intrinsics [v3] In-Reply-To: References: Message-ID: <3HBeP2xyEtLB_aYoetNP-qZ_WSJod0ZLWuky9gU6mKs=.77d6b1f0-69d8-4f42-a373-5d15e2d211bd@github.com> > UseSHA flag is not respected while enabling/disabling UseSHA3Intrinsics flag in x86 builds. > Added UseSHA in the mix. > > Testing: Only Basic testing done. I will run more compiler related testing. Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision: whitespace issue fixed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29266/files - new: https://git.openjdk.org/jdk/pull/29266/files/a7da4fde..84acd692 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29266&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29266&range=01-02 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/29266.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29266/head:pull/29266 PR: https://git.openjdk.org/jdk/pull/29266 From ghan at openjdk.org Mon Jan 19 00:46:34 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Mon, 19 Jan 2026 00:46:34 GMT Subject: RFR: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) [v6] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 09:17:55 GMT, David Holmes wrote: >> I agree with the concern here. The buffering we need is local to this call site to keep the output coherent (collect everything and print once). >> Whether we need to buffer/accumulate output for coherence is scenario-dependent, rather than a property that should permanently classify a stream type as ?buffered? vs. ?unbuffered?. >> @dean-long what?s your view on this? > > No - sorry I forgot that you have to add override to all methods. Hi @dholmes-ora @dean-long, I have restored the previous version. Could you please review it again? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29186#discussion_r2702915180 From ghan at openjdk.org Mon Jan 19 00:51:45 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Mon, 19 Jan 2026 00:51:45 GMT Subject: RFR: 8375125: assert(false) failed: "Attempting to acquire lock NativeHeapTrimmer_lock/nosafepoint out of order with lock ConcurrentHashTableResize_lock/nosafepoint-2 -- possible deadlock" when using native heap trimmer In-Reply-To: <35x9AM0-Feqwu4W7YtvWX2cZnBgysD6kAFQb7BTf7cw=.cd5768d1-86f8-4cfb-8f66-b6bdfce8d0d3@github.com> References: <74tKCadP3u64jwjKEvh0bZfCXYWoinhqVP1xJlneUf4=.54771fef-7e33-4781-a650-4f55ceaaf3e2@github.com> <35x9AM0-Feqwu4W7YtvWX2cZnBgysD6kAFQb7BTf7cw=.cd5768d1-86f8-4cfb-8f66-b6bdfce8d0d3@github.com> Message-ID: On Wed, 14 Jan 2026 01:12:50 GMT, David Holmes wrote: >> Please review this change. Thanks! >> >> **Description:** >> >> When -XX:TrimNativeHeapInterval=non-zero is enabled, running Test6892265 can trigger a VM abort due to a detected deadlock (or lock-order issue) during SymbolTable cleanup. >> SymbolTable::clean_dead_entries() calls BulkDeleteTask::prepare(), which may take ConcurrentHashTableResize_lock (nosafepoint-2). >> https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/classfile/symbolTable.cpp#L765-L769 >> https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/utilities/concurrentHashTableTasks.inline.hpp#L159-L160 >> https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/utilities/concurrentHashTable.inline.hpp#L307-L310 >> >> >> It then constructs a NativeHeapTrimmer::SuspendMark, which may take NativeHeapTrimmer_lock (nosafepoint). This can invert the lock order with the trimmer thread. >> https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/classfile/symbolTable.cpp#L773 >> https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/runtime/trimNativeHeap.hpp#L56-L59 >> https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/runtime/trimNativeHeap.cpp#L177-L181 >> >> **Fix:** >> >> Move NativeHeapTrimmer::SuspendMark to the beginning of SymbolTable::clean_dead_entries() before BulkDeleteTask::prepare() to enforce a consistent lock order >> >> **Test:** >> >> GHA > > @hgqxjj thanks for taking this on. It appears the same problem exists with the `StringTable`. > > I think this may need its own regression test though, rather than modifying the test that exposed the issue. Also we may need more testing done with the flag activated. @tstuefe do you do regular general testing with native heap trimming enabled? Hi @dholmes-ora @tstuefe , I?ve integrated this change. Could one of you please sponsor it? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29212#issuecomment-3765971086 From dholmes at openjdk.org Mon Jan 19 02:21:08 2026 From: dholmes at openjdk.org (David Holmes) Date: Mon, 19 Jan 2026 02:21:08 GMT Subject: RFR: 8374744: Enable dumping of APX EGPRs =?UTF-8?B?KFIxNuKAk1IzMSk=?= in JVM fatal error logs In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 20:28:14 GMT, Srinivas Vamsi Parasa wrote: > 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. Why is this only implemented for Linux? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29098#issuecomment-3766105969 From dholmes at openjdk.org Mon Jan 19 02:33:17 2026 From: dholmes at openjdk.org (David Holmes) Date: Mon, 19 Jan 2026 02:33:17 GMT Subject: RFR: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) [v8] In-Reply-To: References: Message-ID: On Sun, 18 Jan 2026 02:47:08 GMT, Guanqiang Han wrote: >> Please review this change. Thanks! >> >> **Description:** >> >> When -XX:+PrintDeoptimizationDetails is enabled, vframeArray.cpp prints interpreted frames under ttyLocker. >> https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/runtime/vframeArray.cpp#L493-L503 >> In the WizardMode && Verbose branch it calls Method::print_codes() / print_codes_on(). The bytecode printing path may acquire MDOExtraData_lock (rank nosafepoint-1). >> https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/interpreter/bytecodeTracer.cpp#L597-L602 >> Calling it while holding tty_lock violates the global lock ranking order and triggers a lock rank inversion assertion. >> >> **Fix:** >> >> Generate the bytecode dump before taking tty_lock, and print it afterwards under ttyLocker to keep the output coherent while preserving correct lock acquisition order. >> To avoid double buffering when the target stream is already a thread-local stringStream, extend BytecodeTracer::print_method_codes with a buffered flag . The new call site uses buffered=false when dumping into the temporary stringStream. >> >> **Test:** >> >> GHA > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > remove unused code Changes requested by dholmes (Reviewer). src/hotspot/share/interpreter/bytecodeTracer.cpp line 195: > 193: #endif > 194: > 195: void BytecodeTracer::print_method_codes(const methodHandle& method, int from, int to, outputStream* st, int flags, bool coherent_output) { I don't like the new `coherent_output` name sorry. The output will always be "coherent" - either via the passed in stringStream, or the internal StringStream. ------------- PR Review: https://git.openjdk.org/jdk/pull/29186#pullrequestreview-3676046573 PR Review Comment: https://git.openjdk.org/jdk/pull/29186#discussion_r2703023849 From ghan at openjdk.org Mon Jan 19 02:36:30 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Mon, 19 Jan 2026 02:36:30 GMT Subject: Integrated: 8375125: assert(false) failed: "Attempting to acquire lock NativeHeapTrimmer_lock/nosafepoint out of order with lock ConcurrentHashTableResize_lock/nosafepoint-2 -- possible deadlock" when using native heap trimmer In-Reply-To: <74tKCadP3u64jwjKEvh0bZfCXYWoinhqVP1xJlneUf4=.54771fef-7e33-4781-a650-4f55ceaaf3e2@github.com> References: <74tKCadP3u64jwjKEvh0bZfCXYWoinhqVP1xJlneUf4=.54771fef-7e33-4781-a650-4f55ceaaf3e2@github.com> Message-ID: On Wed, 14 Jan 2026 00:08:47 GMT, Guanqiang Han wrote: > Please review this change. Thanks! > > **Description:** > > When -XX:TrimNativeHeapInterval=non-zero is enabled, running Test6892265 can trigger a VM abort due to a detected deadlock (or lock-order issue) during SymbolTable cleanup. > SymbolTable::clean_dead_entries() calls BulkDeleteTask::prepare(), which may take ConcurrentHashTableResize_lock (nosafepoint-2). > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/classfile/symbolTable.cpp#L765-L769 > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/utilities/concurrentHashTableTasks.inline.hpp#L159-L160 > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/utilities/concurrentHashTable.inline.hpp#L307-L310 > > > It then constructs a NativeHeapTrimmer::SuspendMark, which may take NativeHeapTrimmer_lock (nosafepoint). This can invert the lock order with the trimmer thread. > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/classfile/symbolTable.cpp#L773 > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/runtime/trimNativeHeap.hpp#L56-L59 > https://github.com/openjdk/jdk/blob/0d19d91b44e5232dbd99d34dcdf6500f892e3048/src/hotspot/share/runtime/trimNativeHeap.cpp#L177-L181 > > **Fix:** > > Move NativeHeapTrimmer::SuspendMark to the beginning of SymbolTable::clean_dead_entries() before BulkDeleteTask::prepare() to enforce a consistent lock order > > **Test:** > > GHA This pull request has now been integrated. Changeset: a67979c4 Author: Guanqiang Han Committer: David Holmes URL: https://git.openjdk.org/jdk/commit/a67979c4e6dcea70e63cc79a105be12a9306c660 Stats: 119 lines in 3 files changed: 115 ins; 2 del; 2 mod 8375125: assert(false) failed: "Attempting to acquire lock NativeHeapTrimmer_lock/nosafepoint out of order with lock ConcurrentHashTableResize_lock/nosafepoint-2 -- possible deadlock" when using native heap trimmer Reviewed-by: dholmes, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/29212 From ghan at openjdk.org Mon Jan 19 03:17:30 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Mon, 19 Jan 2026 03:17:30 GMT Subject: RFR: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) [v8] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 02:29:24 GMT, David Holmes wrote: >> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: >> >> remove unused code > > src/hotspot/share/interpreter/bytecodeTracer.cpp line 195: > >> 193: #endif >> 194: >> 195: void BytecodeTracer::print_method_codes(const methodHandle& method, int from, int to, outputStream* st, int flags, bool coherent_output) { > > I don't like the new `coherent_output` name sorry. The output will always be "coherent" - either via the passed in stringStream, or the internal StringStream. How about use_local_buffer? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29186#discussion_r2703083278 From dholmes at openjdk.org Mon Jan 19 04:48:28 2026 From: dholmes at openjdk.org (David Holmes) Date: Mon, 19 Jan 2026 04:48:28 GMT Subject: RFR: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) [v8] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 03:14:01 GMT, Guanqiang Han wrote: >> src/hotspot/share/interpreter/bytecodeTracer.cpp line 195: >> >>> 193: #endif >>> 194: >>> 195: void BytecodeTracer::print_method_codes(const methodHandle& method, int from, int to, outputStream* st, int flags, bool coherent_output) { >> >> I don't like the new `coherent_output` name sorry. The output will always be "coherent" - either via the passed in stringStream, or the internal StringStream. > > How about use_local_buffer? That's workable I suppose - but your original was also workable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29186#discussion_r2703197288 From ghan at openjdk.org Mon Jan 19 05:49:22 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Mon, 19 Jan 2026 05:49:22 GMT Subject: RFR: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) [v9] In-Reply-To: References: Message-ID: > Please review this change. Thanks! > > **Description:** > > When -XX:+PrintDeoptimizationDetails is enabled, vframeArray.cpp prints interpreted frames under ttyLocker. > https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/runtime/vframeArray.cpp#L493-L503 > In the WizardMode && Verbose branch it calls Method::print_codes() / print_codes_on(). The bytecode printing path may acquire MDOExtraData_lock (rank nosafepoint-1). > https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/interpreter/bytecodeTracer.cpp#L597-L602 > Calling it while holding tty_lock violates the global lock ranking order and triggers a lock rank inversion assertion. > > **Fix:** > > Generate the bytecode dump before taking tty_lock, and print it afterwards under ttyLocker to keep the output coherent while preserving correct lock acquisition order. > To avoid double buffering when the target stream is already a thread-local stringStream, extend BytecodeTracer::print_method_codes with a buffered flag . The new call site uses buffered=false when dumping into the temporary stringStream. > > **Test:** > > GHA Guanqiang Han 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: - change variable name - Merge remote-tracking branch 'upstream/master' into 8374862 - remove unused code - revert - Merge remote-tracking branch 'upstream/master' into 8374862 - fix a compile error - remove unnecessary blank line - correct copyright year - Add outputStream::is_buffered() - change variable name - ... and 3 more: https://git.openjdk.org/jdk/compare/76d3f6a3...a63c4613 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29186/files - new: https://git.openjdk.org/jdk/pull/29186/files/601ff0da..a63c4613 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29186&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29186&range=07-08 Stats: 132 lines in 9 files changed: 117 ins; 2 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/29186.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29186/head:pull/29186 PR: https://git.openjdk.org/jdk/pull/29186 From dholmes at openjdk.org Mon Jan 19 07:44:34 2026 From: dholmes at openjdk.org (David Holmes) Date: Mon, 19 Jan 2026 07:44:34 GMT Subject: RFR: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) [v9] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 05:49:22 GMT, Guanqiang Han wrote: >> Please review this change. Thanks! >> >> **Description:** >> >> When -XX:+PrintDeoptimizationDetails is enabled, vframeArray.cpp prints interpreted frames under ttyLocker. >> https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/runtime/vframeArray.cpp#L493-L503 >> In the WizardMode && Verbose branch it calls Method::print_codes() / print_codes_on(). The bytecode printing path may acquire MDOExtraData_lock (rank nosafepoint-1). >> https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/interpreter/bytecodeTracer.cpp#L597-L602 >> Calling it while holding tty_lock violates the global lock ranking order and triggers a lock rank inversion assertion. >> >> **Fix:** >> >> Generate the bytecode dump before taking tty_lock, and print it afterwards under ttyLocker to keep the output coherent while preserving correct lock acquisition order. >> To avoid double buffering when the target stream is already a thread-local stringStream, extend BytecodeTracer::print_method_codes with a buffered flag . The new call site uses buffered=false when dumping into the temporary stringStream. >> >> **Test:** >> >> GHA > > Guanqiang Han 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: > > - change variable name > - Merge remote-tracking branch 'upstream/master' into 8374862 > - remove unused code > - revert > - Merge remote-tracking branch 'upstream/master' into 8374862 > - fix a compile error > - remove unnecessary blank line > - correct copyright year > - Add outputStream::is_buffered() > - change variable name > - ... and 3 more: https://git.openjdk.org/jdk/compare/3729b79b...a63c4613 LGTM. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29186#pullrequestreview-3676699878 From thartmann at openjdk.org Mon Jan 19 08:11:00 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 19 Jan 2026 08:11:00 GMT Subject: RFR: 8375534: Debug method 'pp' should support compressed oops [v2] In-Reply-To: References: Message-ID: <8WMvLeZIKT01h3gYFaeUJhQqNmZirdoiwvqbdejYQok=.bbe3b14b-0923-4528-bb0a-2355bbe53e8f@github.com> > The debug method `pp` is currently not able to handle compressed oops. This should fix it. The code is similar to `BlockLocationPrinter::print_location`. > > **Before:** > > > (rr) call (void*) pp(0x6b9c08fc8) > > "Executing pp" > java.lang.Runtime$Version > {0x00000006b9c08fc8} - klass: 'java/lang/Runtime$Version' - flags: > > - ---- fields (total size 4 words): > - private final value 'version' 'Ljava/util/List;' @12 a 'java/util/ImmutableCollections$List12'{0x00000006b9c2cbb8} (0xd7385977) > - private final value 'pre' 'Ljava/util/Optional;' @16 a 'java/util/Optional'{0x00000006b9c2cbd0} (0xd738597a) > - private final value 'build' 'Ljava/util/Optional;' @20 a 'java/util/Optional'{0x00000006b9c0a118} (0xd7381423) > - private final value 'optional' 'Ljava/util/Optional;' @24 a 'java/util/Optional'{0x00000006b9c2cbe8} (0xd738597d) > $1 = (void *) 0x0 > (rr) call (void*) pp(0xd7381423) > > "Executing pp" > The program being debugged received signal SIGSEGV, Segmentation fault > while in a function called from GDB. GDB has restored the context > to what it was before the call. To change this behavior use > "set unwind-on-signal off". Evaluation of the expression containing > the function (pp(long)) will be abandoned. > > > **After:** > ```(rr) call (void*) pp(0x6b9c08fc8) > > "Executing pp" > java.lang.Runtime$Version > {0x00000006b9c08fc8} - klass: 'java/lang/Runtime$Version' - flags: > > - ---- fields (total size 4 words): > - private final value 'version' 'Ljava/util/List;' @12 a 'java/util/ImmutableCollections$List12'{0x00000006b9c2cbb8} (0xd7385977) > - private final value 'pre' 'Ljava/util/Optional;' @16 a 'java/util/Optional'{0x00000006b9c2cbd0} (0xd738597a) > - private final value 'build' 'Ljava/util/Optional;' @20 a 'java/util/Optional'{0x00000006b9c0a118} (0xd7381423) > - private final value 'optional' 'Ljava/util/Optional;' @24 a 'java/util/Optional'{0x00000006b9c2cbe8} (0xd738597d) > $1 = (void *) 0x0 > (rr) call (void*) pp(0xd7381423) > > "Executing pp" > 3610776611 is a compressed pointer to object: java.util.Optional > {0x00000006b9c0a118} - klass: 'java/util/Optional' - flags: > > - ---- fields (total size 3 words): > - private final value 'value' 'Ljava/lang/Object;' @16 null (0x00000000) > $2 = (void *) 0x0 > > > Thanks, > Tobias Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision: Let's just use print_location instead ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29280/files - new: https://git.openjdk.org/jdk/pull/29280/files/d09f09ca..c4b67195 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29280&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29280&range=00-01 Stats: 18 lines in 1 file changed: 1 ins; 17 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29280.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29280/head:pull/29280 PR: https://git.openjdk.org/jdk/pull/29280 From thartmann at openjdk.org Mon Jan 19 08:14:38 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 19 Jan 2026 08:14:38 GMT Subject: RFR: 8375534: Debug method 'pp' should support compressed oops [v2] In-Reply-To: <8WMvLeZIKT01h3gYFaeUJhQqNmZirdoiwvqbdejYQok=.bbe3b14b-0923-4528-bb0a-2355bbe53e8f@github.com> References: <8WMvLeZIKT01h3gYFaeUJhQqNmZirdoiwvqbdejYQok=.bbe3b14b-0923-4528-bb0a-2355bbe53e8f@github.com> Message-ID: On Mon, 19 Jan 2026 08:11:00 GMT, Tobias Hartmann wrote: >> The debug method `pp` is currently not able to handle compressed oops. This should fix it. The code is similar to `BlockLocationPrinter::print_location`. >> >> **Before:** >> >> >> (rr) call (void*) pp(0x6b9c08fc8) >> >> "Executing pp" >> java.lang.Runtime$Version >> {0x00000006b9c08fc8} - klass: 'java/lang/Runtime$Version' - flags: >> >> - ---- fields (total size 4 words): >> - private final value 'version' 'Ljava/util/List;' @12 a 'java/util/ImmutableCollections$List12'{0x00000006b9c2cbb8} (0xd7385977) >> - private final value 'pre' 'Ljava/util/Optional;' @16 a 'java/util/Optional'{0x00000006b9c2cbd0} (0xd738597a) >> - private final value 'build' 'Ljava/util/Optional;' @20 a 'java/util/Optional'{0x00000006b9c0a118} (0xd7381423) >> - private final value 'optional' 'Ljava/util/Optional;' @24 a 'java/util/Optional'{0x00000006b9c2cbe8} (0xd738597d) >> $1 = (void *) 0x0 >> (rr) call (void*) pp(0xd7381423) >> >> "Executing pp" >> The program being debugged received signal SIGSEGV, Segmentation fault >> while in a function called from GDB. GDB has restored the context >> to what it was before the call. To change this behavior use >> "set unwind-on-signal off". Evaluation of the expression containing >> the function (pp(long)) will be abandoned. >> >> >> **After:** >> ```(rr) call (void*) pp(0x6b9c08fc8) >> >> "Executing pp" >> java.lang.Runtime$Version >> {0x00000006b9c08fc8} - klass: 'java/lang/Runtime$Version' - flags: >> >> - ---- fields (total size 4 words): >> - private final value 'version' 'Ljava/util/List;' @12 a 'java/util/ImmutableCollections$List12'{0x00000006b9c2cbb8} (0xd7385977) >> - private final value 'pre' 'Ljava/util/Optional;' @16 a 'java/util/Optional'{0x00000006b9c2cbd0} (0xd738597a) >> - private final value 'build' 'Ljava/util/Optional;' @20 a 'java/util/Optional'{0x00000006b9c0a118} (0xd7381423) >> - private final value 'optional' 'Ljava/util/Optional;' @24 a 'java/util/Optional'{0x00000006b9c2cbe8} (0xd738597d) >> $1 = (void *) 0x0 >> (rr) call (void*) pp(0xd7381423) >> >> "Executing pp" >> 3610776611 is a compressed pointer to object: java.util.Optional >> {0x00000006b9c0a118} - klass: 'java/util/Optional' - flags: >> >> - ---- fields (total size 3 words): >> - private final value 'value' 'Ljava/lang/Object;' @16 null (0x00000000) >> $2 = (void *) 0x0 >> >> >> Thanks, >> Tobias > > Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision: > > Let's just use print_location instead Thanks for the review, Vladimir. You are right and when looking at the code again, I noticed that we can just call `Universe::heap()->print_location` from `pp`. I'm not so sure anymore how valuable `pp` really is, given that there is `find` which entails the functionality of `pp`. But let's fix it for now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29280#issuecomment-3767003649 From epeter at openjdk.org Mon Jan 19 08:14:41 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 19 Jan 2026 08:14:41 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v13] In-Reply-To: <_9OkAqddCk8CbA-51qgdecI23f03MBsZE9kiES5cU0I=.d1adead1-45ff-40be-b139-2f9fa32c7d42@github.com> References: <_9OkAqddCk8CbA-51qgdecI23f03MBsZE9kiES5cU0I=.d1adead1-45ff-40be-b139-2f9fa32c7d42@github.com> Message-ID: On Fri, 16 Jan 2026 20:31:28 GMT, Srinivas Vamsi Parasa wrote: >> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: >> >> Update ALL of ArraysFill JMH micro > > Also, we can see the benefit of using unmasked stores (this PR) instead of masked vector stores (existing implementation) when we update the ArraysFill.java JMH micro-benchmark to perform fill (write) followed by read of the filled data as shown below using short array fill as an example: > > > @Benchmark > public short testShortFill() { > Arrays.fill(testShortArray, (short) -1); > return (short) (testShortArray[0] + testShortArray[size - 1]); > } > > > > > > ### Table shows throughput (ops/ms); **(Higher is better)** > Benchmark (ops/ms) MaxVectorSize = 32 | SIZE | +OptimizeFill (Masked Store) | +OptimizeFill (Unmasked Store - This PR) | Delta > -- | -- | -- | -- | -- > ArraysFill.testByteFill | 1 | 175381 | 342456 | 95% > ArraysFill.testByteFill | 10 | 175421 | 264607 | 51% > ArraysFill.testByteFill | 20 | 175447 | 271111 | 55% > ArraysFill.testByteFill | 30 | 175454 | 253351 | 44% > ArraysFill.testByteFill | 40 | 162429 | 273043 | 68% > ArraysFill.testByteFill | 50 | 162443 | 251734 | 55% > ArraysFill.testByteFill | 60 | 162454 | 248156 | 53% > ArraysFill.testByteFill | 70 | 156659 | 236497 | 51% > ArraysFill.testByteFill | 80 | 175403 | 269433 | 54% > ArraysFill.testByteFill | 90 | 175422 | 230276 | 31% > ArraysFill.testByteFill | 100 | 168662 | 252394 | 50% > ArraysFill.testByteFill | 110 | 146182 | 217917 | 49% > ArraysFill.testByteFill | 120 | 168693 | 239126 | 42% > ArraysFill.testByteFill | 130 | 162378 | 166159 | 2% > ArraysFill.testByteFill | 140 | 156569 | 168296 | 7% > ArraysFill.testByteFill | 150 | 151214 | 167388 | 11% > ArraysFill.testByteFill | 160 | 156594 | 173529 | 11% > ArraysFill.testByteFill | 170 | 156590 | 167976 | 7% > ArraysFill.testByteFill | 180 | 156561 | 173015 | 11% > ArraysFill.testByteFill | 190 | 156601 | 173073 | 11% > ArraysFill.testByteFill | 200 | 168277 | 174293 | 4% > ArraysFill.testIntFill | 1 | 175403 | 334460 | 91% > ArraysFill.testIntFill | 10 | 162437 | 273799 | 69% > ArraysFill.testIntFill | 20 | 156636 | 273483 | 75% > ArraysFill.testIntFill | 30 | 162440 | 243303 | 50% > ArraysFill.testIntFill | 40 | 156592 | 175162 | 12% > ArraysFill.testIntFill | 50 | 156585 | 168433 | 8% > ArraysFill.testIntFill | 60 | 151193 | 195235 | 29% > ArraysFill.testIntFill | 70 | 141406 | 167060 | 18% > ArraysFill.testIntFill | 80 | 141406 | 167119 | 18% > ArraysFill.testIntFill | 90 | 141437 | 166976 | 18% > ArraysFill.testIntFill | 100 | 168349 | 173943 | 3% > ArraysFill.testIntFill | 110 | 132864 | 173096 | 30% > ArraysFill.testIntFill | 120 | 128972 | 173722 | 35% > ArraysFill.... @vamsi-parasa Thanks for the extra data! Do I see this right? In the plots [here](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761659799), the masked performance lies lower/better than unmasked performance (here we measure ns/ops). But in your tables [here](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761712841) you are measuring ops/ms, and are getting the opposite trend: masked is slower than unmasked. Can you explain the difference between the two results? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3767004043 From ghan at openjdk.org Mon Jan 19 08:42:12 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Mon, 19 Jan 2026 08:42:12 GMT Subject: RFR: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) [v9] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 07:41:05 GMT, David Holmes wrote: >> Guanqiang Han 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: >> >> - change variable name >> - Merge remote-tracking branch 'upstream/master' into 8374862 >> - remove unused code >> - revert >> - Merge remote-tracking branch 'upstream/master' into 8374862 >> - fix a compile error >> - remove unnecessary blank line >> - correct copyright year >> - Add outputStream::is_buffered() >> - change variable name >> - ... and 3 more: https://git.openjdk.org/jdk/compare/da37c031...a63c4613 > > LGTM. Thanks Hi @dholmes-ora, Thank you for reviewing! I?ve integrated the change ? could you please sponsor it? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29186#issuecomment-3767104159 From duke at openjdk.org Mon Jan 19 08:42:14 2026 From: duke at openjdk.org (duke) Date: Mon, 19 Jan 2026 08:42:14 GMT Subject: RFR: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) [v9] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 05:49:22 GMT, Guanqiang Han wrote: >> Please review this change. Thanks! >> >> **Description:** >> >> When -XX:+PrintDeoptimizationDetails is enabled, vframeArray.cpp prints interpreted frames under ttyLocker. >> https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/runtime/vframeArray.cpp#L493-L503 >> In the WizardMode && Verbose branch it calls Method::print_codes() / print_codes_on(). The bytecode printing path may acquire MDOExtraData_lock (rank nosafepoint-1). >> https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/interpreter/bytecodeTracer.cpp#L597-L602 >> Calling it while holding tty_lock violates the global lock ranking order and triggers a lock rank inversion assertion. >> >> **Fix:** >> >> Generate the bytecode dump before taking tty_lock, and print it afterwards under ttyLocker to keep the output coherent while preserving correct lock acquisition order. >> To avoid double buffering when the target stream is already a thread-local stringStream, extend BytecodeTracer::print_method_codes with a buffered flag . The new call site uses buffered=false when dumping into the temporary stringStream. >> >> **Test:** >> >> GHA > > Guanqiang Han 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: > > - change variable name > - Merge remote-tracking branch 'upstream/master' into 8374862 > - remove unused code > - revert > - Merge remote-tracking branch 'upstream/master' into 8374862 > - fix a compile error > - remove unnecessary blank line > - correct copyright year > - Add outputStream::is_buffered() > - change variable name > - ... and 3 more: https://git.openjdk.org/jdk/compare/da37c031...a63c4613 @hgqxjj Your change (at version a63c46131b6329de2df80600995c3ea1492dcd98) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29186#issuecomment-3767107046 From jbhateja at openjdk.org Mon Jan 19 09:04:26 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 19 Jan 2026 09:04:26 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v9] In-Reply-To: References: Message-ID: > Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction. > It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails. > > Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java). > > Vector API jtreg tests pass at AVX level 2, remaining validation in progress. > > Performance numbers: > > > System : 13th Gen Intel(R) Core(TM) i3-1315U > > Baseline: > Benchmark (size) Mode Cnt Score Error Units > VectorSliceBenchmark.byteVectorSliceWithConstantIndex1 1024 thrpt 2 9444.444 ops/ms > VectorSliceBenchmark.byteVectorSliceWithConstantIndex2 1024 thrpt 2 10009.319 ops/ms > VectorSliceBenchmark.byteVectorSliceWithVariableIndex 1024 thrpt 2 9081.926 ops/ms > VectorSliceBenchmark.intVectorSliceWithConstantIndex1 1024 thrpt 2 6085.825 ops/ms > VectorSliceBenchmark.intVectorSliceWithConstantIndex2 1024 thrpt 2 6505.378 ops/ms > VectorSliceBenchmark.intVectorSliceWithVariableIndex 1024 thrpt 2 6204.489 ops/ms > VectorSliceBenchmark.longVectorSliceWithConstantIndex1 1024 thrpt 2 1651.334 ops/ms > VectorSliceBenchmark.longVectorSliceWithConstantIndex2 1024 thrpt 2 1642.784 ops/ms > VectorSliceBenchmark.longVectorSliceWithVariableIndex 1024 thrpt 2 1474.808 ops/ms > VectorSliceBenchmark.shortVectorSliceWithConstantIndex1 1024 thrpt 2 10399.394 ops/ms > VectorSliceBenchmark.shortVectorSliceWithConstantIndex2 1024 thrpt 2 10502.894 ops/ms > VectorSliceBenchmark.shortVectorSliceWithVariableIndex 1024 ... Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - Review comments resolutions - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762 - Update callGenerator.hpp copyright year - Review comments resolution - Cleanups - Review comments resolutions - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762 - Updating predicate checks - Fixes for failing regressions - Optimizing AVX2 backend and some re-factoring - ... and 3 more: https://git.openjdk.org/jdk/compare/b7346c30...9da1f862 ------------- Changes: https://git.openjdk.org/jdk/pull/24104/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=08 Stats: 1347 lines in 29 files changed: 1243 ins; 1 del; 103 mod Patch: https://git.openjdk.org/jdk/pull/24104.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24104/head:pull/24104 PR: https://git.openjdk.org/jdk/pull/24104 From jbhateja at openjdk.org Mon Jan 19 09:04:30 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 19 Jan 2026 09:04:30 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v8] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 06:03:15 GMT, Jatin Bhateja wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Update callGenerator.hpp copyright year > > Hi @erifan , Thanks for your comments. I will address them soon, please keep reviewing in the meantime :-) > @jatin-bhateja I have no further comments, great work. After this PR is merged, I will complete the backend optimization of the aarch64 part based on it. Thanks! Thanks @erifan , I think partial case is specific for AARCH64 backend and tests should accompany relevant AARCH64 changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3767179812 From jbhateja at openjdk.org Mon Jan 19 09:04:34 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 19 Jan 2026 09:04:34 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v8] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 03:24:32 GMT, Eric Fang wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Update callGenerator.hpp copyright year > > test/hotspot/jtreg/compiler/vectorapi/TestSliceOptValueTransforms.java line 101: > >> 99: .slice(0, ByteVector.fromArray(BSP, bsrc2, i)) >> 100: .intoArray(bdst, i); >> 101: } > > Would you mind adding a correctness check for these tests, for byte type, like: > > @DontInline > static void verifyVectorSliceByte(int origin) { > for (int i = 0; i < BSP.loopBound(SIZE); i += BSP.length()) { > int index = i; > for (int j = i + origin; j < i + BSP.length(); j++) { > Asserts.assertEquals(bsrc1[j], bdst[index++]); > } > for (int j = i; j < i + origin; j++) { > Asserts.assertEquals(bsrc2[j], bdst[index++]); > } > } > } There are enough number of functional correctness tests in existing VectorAPI JTREG suite, this test specifically checks for newly added VectorSlice IR node and associated ideal transformations. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2703827513 From shade at openjdk.org Mon Jan 19 10:31:35 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 19 Jan 2026 10:31:35 GMT Subject: RFR: 8375046: C2: Assertion failed in GrowableArray::remove_till(0) [v5] In-Reply-To: <_tSvASngm2bL0X2wavXI63kJZoypsY5S-dus_KGhs18=.ace489be-48bf-4254-a88e-b4fe456edf02@github.com> References: <_tSvASngm2bL0X2wavXI63kJZoypsY5S-dus_KGhs18=.ace489be-48bf-4254-a88e-b4fe456edf02@github.com> Message-ID: > Seen this assert in stress CTW runs: > > > # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/utilities/growableArray.hpp:498), pid=2972347, tid=2973775 > # assert(start < end && end <= this->_len) failed: erase called with invalid range (0, 0) for length 0 > > Stack: [0x00007fd660bea000,0x00007fd660cea000], sp=0x00007fd660ce4fc0, free space=1003k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0xc00a41] Compile::inline_incrementally_one()+0x801 (growableArray.hpp:498) > V [libjvm.so+0xc01650] Compile::inline_incrementally(PhaseIterGVN&)+0x2f0 (compile.cpp:2212) > V [libjvm.so+0xc04581] Compile::Optimize()+0x7d1 (compile.cpp:2357) > > > It looks innocuous, as `GrowableArray::remove_range` does nothing real on `[0, 0)`. It is still IMO a bug to call it with `[0, 0)`, as it is not clear whether to trust inclusive or exclusive boundary. But for `remove_till`, it looks plausible that `remove_till(0)` should work and be a no-op. Looks like it readily happens in C2 CTW when `_late_inlines` is empty. > > Additional testing: > - [x] Linux x86_64 server fastdebug, additional new gtest to verify `remove_range` works > - [x] Linux x86_64 server fastdebug, `all` Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - Missing case - More tests - Merge branch 'master' into JDK-8375046-growable-array-till-zero - Revert - Leave only the C2 fix - Merge branch 'master' into JDK-8375046-growable-array-till-zero - Only clear pos when needed - Handle the C2 side by removing/inlining remove_till - No trailing comma - Fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29171/files - new: https://git.openjdk.org/jdk/pull/29171/files/d08cb656..bbcc37ea Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29171&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29171&range=03-04 Stats: 8210 lines in 283 files changed: 4805 ins; 1429 del; 1976 mod Patch: https://git.openjdk.org/jdk/pull/29171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29171/head:pull/29171 PR: https://git.openjdk.org/jdk/pull/29171 From shade at openjdk.org Mon Jan 19 10:31:36 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 19 Jan 2026 10:31:36 GMT Subject: RFR: 8375046: C2: Assertion failed in GrowableArray::remove_till(0) [v4] In-Reply-To: References: <_tSvASngm2bL0X2wavXI63kJZoypsY5S-dus_KGhs18=.ace489be-48bf-4254-a88e-b4fe456edf02@github.com> Message-ID: On Wed, 14 Jan 2026 20:59:18 GMT, Vladimir Ivanov wrote: > The code implicitly assumes that `_late_inlines` is not empty and it's a reasonable assumption. Any particular reason to handle empty case instead of finishing early? The case shows up in CTW -- and fairly rarely at that -- so I think there is no reason for us to care all that much about that corner case, as long as it does not break correctness. Current code just creates the noise in testing, so we are fixing that noise. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29171#issuecomment-3767576733 From shade at openjdk.org Mon Jan 19 10:31:40 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 19 Jan 2026 10:31:40 GMT Subject: RFR: 8375046: C2: Assertion failed in GrowableArray::remove_till(0) [v4] In-Reply-To: References: <_tSvASngm2bL0X2wavXI63kJZoypsY5S-dus_KGhs18=.ace489be-48bf-4254-a88e-b4fe456edf02@github.com> Message-ID: On Wed, 14 Jan 2026 22:38:04 GMT, Kim Barrett wrote: >> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Leave only the C2 fix >> - Merge branch 'master' into JDK-8375046-growable-array-till-zero >> - Only clear pos when needed >> - Handle the C2 side by removing/inlining remove_till >> - No trailing comma >> - Fix > > src/hotspot/share/opto/compile.cpp line 2148: > >> 2146: _late_inlines_pos = 0; >> 2147: } >> 2148: assert(_late_inlines_pos == 0, "sanity"); > > The bug is the assert in `GrowableArray::remove_range`. The argument to > `remove_till` is explicitly documented as exclusive. And the arguments for > `remove_range` are explicitly documented as being the range "[start, end)". And > that's how it's implemented. Except for the assert. > > So I think that assert should be fixed, and the original code here is correct and > shouldn't be modified. All right, we can indeed say `[x; x)` is an empty range and accept it. `[0; 0)` is a special case of that special case. I made a few gtests to see that the whole thing still works as intended. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29171#discussion_r2704146350 From cnorrbin at openjdk.org Mon Jan 19 11:21:14 2026 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Mon, 19 Jan 2026 11:21:14 GMT Subject: RFR: 8375621: Move RBTree implementation to inline file to minimize included headers Message-ID: Hi everyone, The red-black tree implementation is split across `rbTree.hpp` and `rbTree.inline.hpp`. Some small `AbstractRBTree` functions are kept in `rbTree.hpp`, and also all of `RBTree`'s implementation. This makes the file less readable and requires extra header inclusions, notably the `os` class, which in turn includes additional unnecessary dependancies. In this PR I have moved all implementation code `rbTree.inline.hpp` instead. As a result, `rbTree.hpp` now only contains declarations, making it cleaner and limiting header inclusions to what is strictly necessary. Implementation-specific headers are now only included in the inline file. Additionally, I changed `RBTreeCHeapAllocator` to use `AllocateHeap`/`FreeHeap` from `allocation` instead of `os::malloc`/`os::free`, which allows us to get rid of the `os` dependancy altogether. Note: This PR is dependant on #29082, which adds arena-style tree allocators, which this PR then moves to the inline file. Testing: - Oracle tiers 1-5 ------------- Depends on: https://git.openjdk.org/jdk/pull/29082 Commit messages: - Updated copyright headers - move to rbtree.inline Changes: https://git.openjdk.org/jdk/pull/29295/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29295&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375621 Stats: 648 lines in 2 files changed: 388 ins; 181 del; 79 mod Patch: https://git.openjdk.org/jdk/pull/29295.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29295/head:pull/29295 PR: https://git.openjdk.org/jdk/pull/29295 From kfarrell at openjdk.org Mon Jan 19 11:25:41 2026 From: kfarrell at openjdk.org (Kieran Farrell) Date: Mon, 19 Jan 2026 11:25:41 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v8] In-Reply-To: References: Message-ID: > 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: add test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29124/files - new: https://git.openjdk.org/jdk/pull/29124/files/bb3b243c..2b1de0f0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=06-07 Stats: 57 lines in 1 file changed: 57 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 dholmes at openjdk.org Mon Jan 19 11:47:31 2026 From: dholmes at openjdk.org (David Holmes) Date: Mon, 19 Jan 2026 11:47:31 GMT Subject: RFR: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) [v9] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 08:37:59 GMT, Guanqiang Han wrote: >> LGTM. Thanks > > Hi @dholmes-ora, Thank you for reviewing! > I?ve integrated the change ? could you please sponsor it? Thanks! @hgqxjj hotspot changes require two reviews, so we will need to wait for @dean-long to have another look. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29186#issuecomment-3767918796 From jsjolen at openjdk.org Mon Jan 19 12:26:46 2026 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 19 Jan 2026 12:26:46 GMT Subject: RFR: 8375621: Move RBTree implementation to inline file to minimize included headers In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 11:14:18 GMT, Casper Norrbin wrote: > Hi everyone, > > The red-black tree implementation is split across `rbTree.hpp` and `rbTree.inline.hpp`. Some small `AbstractRBTree` functions are kept in `rbTree.hpp`, and also all of `RBTree`'s implementation. This makes the file less readable and requires extra header inclusions, notably the `os` class, which in turn includes additional unnecessary dependancies. > > In this PR I have moved all implementation code `rbTree.inline.hpp` instead. As a result, `rbTree.hpp` now only contains declarations, making it cleaner and limiting header inclusions to what is strictly necessary. Implementation-specific headers are now only included in the inline file. > > Additionally, I changed `RBTreeCHeapAllocator` to use `AllocateHeap`/`FreeHeap` from `allocation` instead of `os::malloc`/`os::free`, which allows us to get rid of the `os` dependancy altogether. > > Note: This PR is dependant on #29082, which adds arena-style tree allocators, which this PR then moves to the inline file. > > Testing: > - Oracle tiers 1-5 Marked as reviewed by jsjolen (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29295#pullrequestreview-3677843412 From stefank at openjdk.org Mon Jan 19 12:46:16 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 19 Jan 2026 12:46:16 GMT Subject: RFR: 8375621: Move RBTree implementation to inline file to minimize included headers In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 11:14:18 GMT, Casper Norrbin wrote: > Hi everyone, > > The red-black tree implementation is split across `rbTree.hpp` and `rbTree.inline.hpp`. Some small `AbstractRBTree` functions are kept in `rbTree.hpp`, and also all of `RBTree`'s implementation. This makes the file less readable and requires extra header inclusions, notably the `os` class, which in turn includes additional unnecessary dependancies. > > In this PR I have moved all implementation code `rbTree.inline.hpp` instead. As a result, `rbTree.hpp` now only contains declarations, making it cleaner and limiting header inclusions to what is strictly necessary. Implementation-specific headers are now only included in the inline file. > > Additionally, I changed `RBTreeCHeapAllocator` to use `AllocateHeap`/`FreeHeap` from `allocation` instead of `os::malloc`/`os::free`, which allows us to get rid of the `os` dependancy altogether. > > Note: This PR is dependant on #29082, which adds arena-style tree allocators, which this PR then moves to the inline file. > > Testing: > - Oracle tiers 1-5 Thanks for doing this cleanup. I've left a few nits below. src/hotspot/share/utilities/rbTree.hpp line 68: > 66: class outputStream; > 67: class Arena; > 68: class ResourceArea; Brownie points if you also sort the forward declarations. src/hotspot/share/utilities/rbTree.inline.hpp line 236: > 234: > 235: template > 236: inline const RBNode* RBNode::next() const { return static_cast*>(IntrusiveRBNode::next()); } Not a strong request, but I would like to suggest that you skip writing one-liners for all these functions in the inline.hpp file: Suggestion: template inline const RBNode* RBNode::next() const { return static_cast*>(IntrusiveRBNode::next()); } src/hotspot/share/utilities/rbTree.inline.hpp line 1159: > 1157: template > 1158: inline void* RBTreeCHeapAllocator::allocate(size_t sz) { > 1159: return static_cast(AllocateHeap(sz, mem_tag, strategy)); Do you really need the cast here? src/hotspot/share/utilities/rbTree.inline.hpp line 1178: > 1176: inline void RBTreeArenaAllocator::free(void* ptr) { /* NOP */ } > 1177: > 1178: Suggestion: ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29295#pullrequestreview-3677888893 PR Review Comment: https://git.openjdk.org/jdk/pull/29295#discussion_r2704604313 PR Review Comment: https://git.openjdk.org/jdk/pull/29295#discussion_r2704592351 PR Review Comment: https://git.openjdk.org/jdk/pull/29295#discussion_r2704627054 PR Review Comment: https://git.openjdk.org/jdk/pull/29295#discussion_r2704596060 From tschatzl at openjdk.org Mon Jan 19 13:40:51 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 19 Jan 2026 13:40:51 GMT Subject: RFR: 8375438: G1: Convert G1HeapRegion related classes to use Atomic Message-ID: Hi all, please review conversion of G1HeapRegion related classes to use Atomic. Testing: tier1, tier4, tier5 (The PipelineLeaksFD failure in gha is a known issue) Thanks, Thomas ------------- Commit messages: - 8375438 Changes: https://git.openjdk.org/jdk/pull/29301/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29301&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375438 Stats: 55 lines in 8 files changed: 17 ins; 1 del; 37 mod Patch: https://git.openjdk.org/jdk/pull/29301.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29301/head:pull/29301 PR: https://git.openjdk.org/jdk/pull/29301 From roland at openjdk.org Mon Jan 19 13:59:55 2026 From: roland at openjdk.org (Roland Westrelin) Date: Mon, 19 Jan 2026 13:59:55 GMT Subject: RFR: 8370519: C2: Hit MemLimit when running with +VerifyLoopOptimizations [v6] In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 10:21:29 GMT, Beno?t Maillard wrote: >> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision: >> >> package declaration > > I think we should use the following test, which is quite concise and only takes a few seconds to execute thanks to setting `memlimit` to `100M`. > > ```c++ > /** > * @test > * @key stress randomness > * @bug 8370519 > * @summary C2: Hit MemLimit when running with +VerifyLoopOptimizations > * @run main/othervm -XX:CompileCommand=compileonly,${test.main.class}::* -XX:-TieredCompilation -Xbatch > * -XX:+UnlockDiagnosticVMOptions -XX:+IgnoreUnrecognizedVMOptions > * -XX:+StressLoopPeeling -XX:+VerifyLoopOptimizations > * -XX:CompileCommand=memlimit,${test.main.class}::*,100M~crash > * -XX:StressSeed=3106998670 ${test.main.class} > * @run main ${test.main.class} > */ > > package compiler.c2; > > public class TestVerifyLoopOptimizationsHighMemUsage { > > static int b = 400; > static long c; > static boolean d; > > static long lMeth(int e) { > int f, g, h, k[] = new int[b]; > long l[] = new long[b]; > boolean m[] = new boolean[b]; > for (f = 5; f < 330; ++f) > for (g = 1; g < 5; ++g) > for (h = 2; h > 1; h -= 3) > switch (f * 5 + 54) { > case 156: > case 354: > case 98: > case 173: > case 120: > case 374: > case 140: > case 57: > case 106: > case 306: > case 87: > case 399: > k[1] = (int)c; > case 51: > case 287: > case 148: > case 70: > case 74: > case 59: > m[h] = d; > } > long n = p(l); > return n; > } > > public static long p(long[] a) { > long o = 0; > for (int j = 0; j < a.length; j++) > o += j; > return o; > } > > public static void main(String[] args) { > for (int i = 0; i < 10; i++) > lMeth(9); > } > } @benoitmaillard how feasible/time consuming would it be to find a more robust test case? Do you agree with my concern above? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28581#issuecomment-3768463138 From adinn at openjdk.org Mon Jan 19 14:28:13 2026 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 19 Jan 2026 14:28:13 GMT Subject: RFR: 8372617: Save and restore stubgen stubs when using an AOT code cache [v2] In-Reply-To: References: Message-ID: > This PR adds save and restore of all generated stubs to the AOT code cache on x86 and aarch64. Other arches are modified to deal with the related generic PAI changes. > > Small changes were required to the aarch64 and x86_64 generator code in order to meet two key constraints: > 1. the first declared entry of every stub starts at the first instruction in the stub code range > 2. all data/code cross-references from one stub to another target a declared stub entry Andrew Dinn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits: - fix AOT externals after merge with main branch - Merge branch 'master' into save-stubgen-stubs - fix header declarations - move AOT address init impl into arch tree below StubRoutines - put AOT address table init code under INCLUDE_CDS - fix extras count to match number of unsafe handler regions - merge - more whitespace - rmeove whitespace - remove redundant comment - ... and 23 more: https://git.openjdk.org/jdk/compare/e0edc656...6e221ac6 ------------- Changes: https://git.openjdk.org/jdk/pull/28433/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28433&range=01 Stats: 5388 lines in 59 files changed: 4467 ins; 443 del; 478 mod Patch: https://git.openjdk.org/jdk/pull/28433.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28433/head:pull/28433 PR: https://git.openjdk.org/jdk/pull/28433 From cnorrbin at openjdk.org Mon Jan 19 14:48:53 2026 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Mon, 19 Jan 2026 14:48:53 GMT Subject: RFR: 8367319: Add os interfaces to get machine and container values separately [v7] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 10:44:25 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> The current `os::` layer on Linux hides whether the JVM is running inside a container or not. When running inside a container, we replace machine values with container values where applicable, without telling the user of these methods. For most use cases, this is fine, users only care about the returned value. But for other use cases, where the value originated is important. Two examples: >> >> - A user might need the physical cpu count of the machine, but `os::active_processor_count()` only returns the limited container value, which also represents something slightly different. >> - A user might want the container memory limit and the physical RAM size, but `os::physical_memory()` only gives one number. >> >> To solve this, every function that mixed container/machine values now has to explicit variants, prefixed with `machine_` and `container_`. These use the bool return + out-parameter interface, with the container functions only working on Linux. The original methods remain and continue to return the same mixed values. >> >> In addition, container-specific accessors for the memory soft limit and the memory throttle limit have been added, as these values matter when running in a containerized environment. >> >> `OSContainer::active_processor_count()` has also been changed to return `double` instead of `int`. The previous implementation rounded the quota/period ratio up to produce an integer for `os::active_processor_count()`. Now, when the value is requested directly from the new container API it makes more sense to preserve this fraction rather than rounding it up. We can thus keep the exact value for those that want it, then round it up to keep the same behavior in `os::active_processor_count()`. >> >> Testing: >> - Oracle tiers 1-5 >> - Container tests on cgroup v1 and v2 hosts. > > Casper Norrbin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - bump copyright headers > - remove duplicate comments + double type printing > - Merge branch 'master' into separate-container-machine-values > - feedback updates > - return false when no limit + removed unneeded asserts > - Merge branch 'master' into separate-container-machine-values > - Merge branch 'master' into separate-container-machine-values > - Merge branch 'master' into separate-container-machine-values > - Move methods to Machine/Container inner classes + clarifying documentation > - Merge branch 'master' into separate-container-machine-values > - ... and 2 more: https://git.openjdk.org/jdk/compare/578204f8...e2ad48d4 Thank you everyone for reviewing and helping shape this. I think the change has reached a good state, and seeing no more feedback, I am happy moving ahead with integrating. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27646#issuecomment-3768675016 From cnorrbin at openjdk.org Mon Jan 19 14:48:54 2026 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Mon, 19 Jan 2026 14:48:54 GMT Subject: Integrated: 8367319: Add os interfaces to get machine and container values separately In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 12:51:22 GMT, Casper Norrbin wrote: > Hi everyone, > > The current `os::` layer on Linux hides whether the JVM is running inside a container or not. When running inside a container, we replace machine values with container values where applicable, without telling the user of these methods. For most use cases, this is fine, users only care about the returned value. But for other use cases, where the value originated is important. Two examples: > > - A user might need the physical cpu count of the machine, but `os::active_processor_count()` only returns the limited container value, which also represents something slightly different. > - A user might want the container memory limit and the physical RAM size, but `os::physical_memory()` only gives one number. > > To solve this, every function that mixed container/machine values now has to explicit variants, prefixed with `machine_` and `container_`. These use the bool return + out-parameter interface, with the container functions only working on Linux. The original methods remain and continue to return the same mixed values. > > In addition, container-specific accessors for the memory soft limit and the memory throttle limit have been added, as these values matter when running in a containerized environment. > > `OSContainer::active_processor_count()` has also been changed to return `double` instead of `int`. The previous implementation rounded the quota/period ratio up to produce an integer for `os::active_processor_count()`. Now, when the value is requested directly from the new container API it makes more sense to preserve this fraction rather than rounding it up. We can thus keep the exact value for those that want it, then round it up to keep the same behavior in `os::active_processor_count()`. > > Testing: > - Oracle tiers 1-5 > - Container tests on cgroup v1 and v2 hosts. This pull request has now been integrated. Changeset: f2d5290c Author: Casper Norrbin URL: https://git.openjdk.org/jdk/commit/f2d5290c29b0b832e64ab2b4dc04cd892a627ca2 Stats: 410 lines in 20 files changed: 253 ins; 54 del; 103 mod 8367319: Add os interfaces to get machine and container values separately Reviewed-by: eosterlund, sgehwolf ------------- PR: https://git.openjdk.org/jdk/pull/27646 From cnorrbin at openjdk.org Mon Jan 19 14:54:32 2026 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Mon, 19 Jan 2026 14:54:32 GMT Subject: RFR: 8375621: Move RBTree implementation to inline file to minimize included headers [v2] In-Reply-To: References: Message-ID: <4hLWUjpXJ-fYlsn466_sFodxOd2TKENSid4qSI66eJU=.b9b0d3fb-1c5c-4d72-836f-ec7d71c66d11@github.com> > Hi everyone, > > The red-black tree implementation is split across `rbTree.hpp` and `rbTree.inline.hpp`. Some small `AbstractRBTree` functions are kept in `rbTree.hpp`, and also all of `RBTree`'s implementation. This makes the file less readable and requires extra header inclusions, notably the `os` class, which in turn includes additional unnecessary dependancies. > > In this PR I have moved all implementation code `rbTree.inline.hpp` instead. As a result, `rbTree.hpp` now only contains declarations, making it cleaner and limiting header inclusions to what is strictly necessary. Implementation-specific headers are now only included in the inline file. > > Additionally, I changed `RBTreeCHeapAllocator` to use `AllocateHeap`/`FreeHeap` from `allocation` instead of `os::malloc`/`os::free`, which allows us to get rid of the `os` dependancy altogether. > > Note: This PR is dependant on #29082, which adds arena-style tree allocators, which this PR then moves to the inline file. > > Testing: > - Oracle tiers 1-5 Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: feedback fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29295/files - new: https://git.openjdk.org/jdk/pull/29295/files/80897eec..89521527 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29295&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29295&range=00-01 Stats: 58 lines in 1 file changed: 38 ins; 1 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/29295.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29295/head:pull/29295 PR: https://git.openjdk.org/jdk/pull/29295 From cnorrbin at openjdk.org Mon Jan 19 14:54:35 2026 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Mon, 19 Jan 2026 14:54:35 GMT Subject: RFR: 8375621: Move RBTree implementation to inline file to minimize included headers [v2] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 12:33:05 GMT, Stefan Karlsson wrote: >> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: >> >> feedback fixes > > src/hotspot/share/utilities/rbTree.inline.hpp line 236: > >> 234: >> 235: template >> 236: inline const RBNode* RBNode::next() const { return static_cast*>(IntrusiveRBNode::next()); } > > Not a strong request, but I would like to suggest that you skip writing one-liners for all these functions in the inline.hpp file: > Suggestion: > > template > inline const RBNode* RBNode::next() const { > return static_cast*>(IntrusiveRBNode::next()); > } I have changed all the one-liners to "normal" functions. > src/hotspot/share/utilities/rbTree.inline.hpp line 1159: > >> 1157: template >> 1158: inline void* RBTreeCHeapAllocator::allocate(size_t sz) { >> 1159: return static_cast(AllocateHeap(sz, mem_tag, strategy)); > > Do you really need the cast here? We don't. I removed it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29295#discussion_r2705079730 PR Review Comment: https://git.openjdk.org/jdk/pull/29295#discussion_r2705083815 From chagedorn at openjdk.org Mon Jan 19 14:57:56 2026 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Mon, 19 Jan 2026 14:57:56 GMT Subject: RFR: 8373343: C2: verify AddP base input only set for heap addresses [v5] In-Reply-To: <_qZm_vXhwEf_OcRMb72w4t7vk1XKxjxwc_8eO1SmJsk=.d5ed1803-78b5-403a-baea-bbc5567facc7@github.com> References: <_qZm_vXhwEf_OcRMb72w4t7vk1XKxjxwc_8eO1SmJsk=.d5ed1803-78b5-403a-baea-bbc5567facc7@github.com> Message-ID: On Mon, 12 Jan 2026 12:11:51 GMT, Roland Westrelin 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 incrementally with one additional commit since the last revision: > > Update src/hotspot/share/opto/macroArrayCopy.cpp > > Co-authored-by: Dean Long <17332032+dean-long at users.noreply.github.com> Sorry for the delay, testing looked good! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28769#issuecomment-3768723325 From aph at openjdk.org Mon Jan 19 15:01:04 2026 From: aph at openjdk.org (Andrew Haley) Date: Mon, 19 Jan 2026 15:01:04 GMT Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v6] In-Reply-To: References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com> Message-ID: On Sat, 17 Jan 2026 04:57:53 GMT, Dean Long wrote: > I'm probably missing something, but even if we assume class redefinition happens at a safepoint, I don't see how that saves us. I think we have an existing problem even without the changes in this PR. Consider: > > ``` > void test() { > foo.bar(); // static or opt_virtual call site > MyRedefinerHelper.redefineClass("foo", "bar", ....); > foo.bar(); > } > ``` > > Thread 1 calls foo.bar() for the first time, which redirects to the resolve stub and eventually calls set_to_interpreted with the original Method*. Next, we redefine foo.bar(), and then call foo.bar() again. This is the first time we have hit this call site, so we resolve it, but this time we call set_to_interpreted() on the shares stub with the new redefined Method*. Note that the two call sites use the same stub, because x86 and aarch64 share static stubs. Now, add a second thread calling the same test() method. The second thread can be executing in the static stub at the same time that the first thread is in the middle of writing a different Method* to the stub. Which means it's being rewritten outside of a safepoint. > The ISB doesn't save us either. Hmm, maybe. I think we need a test case that does exactly this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3768741895 From aph at openjdk.org Mon Jan 19 14:59:30 2026 From: aph at openjdk.org (Andrew Haley) Date: Mon, 19 Jan 2026 14:59:30 GMT Subject: RFR: 8373696: AArch64: Refine post-call NOPs In-Reply-To: References: <9G7UQDZGLfV0nhrQSv-a9EMvhIAkCdTB3hA9Pf6hRIo=.59b380be-e009-420e-8f76-7771e205467b@github.com> Message-ID: On Sat, 17 Jan 2026 06:21:27 GMT, Ruben wrote: > > It sounds rather complicated. It's important that the performance work we do doesn't over complexify the implementation. Whatever we do should be proportionate to the scale of the problem. Post-call NOPs are not a huge deal. > > > Why not use MOVN, and put the data into a stub at the end of the nmethod? > > If the data is stored in the stub code, the method size depends on whether `cb_offset`/`oopmap_index` fit in the respective post-call NOP - if I understand correctly, that would require calculating values of `cb_offset`/`oopmap_index` during the code generation because stub code size should be known prior to allocation in the code cache. It can't be postponed until `NativePostCallNop::patch`. Avoiding the estimation step would simplify the change. It doesn't have to be hard. We can just guess. In the odd instance that the guess is wrong, emit zeroes. > Also, referencing the stub code via MOVN - which can be used to store up to 18 bits of metadata - would limit the method size by approximately 1MB (`4 * (1 << 18)`). It might be a reasonable limit for a compiled method, however as far as I understand, right now the limit is `branch_range` (128MB). Would the 1MB limit be acceptable? Yes, 1M is plenty. Andrew. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28855#issuecomment-3768728964 From cnorrbin at openjdk.org Mon Jan 19 15:03:35 2026 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Mon, 19 Jan 2026 15:03:35 GMT Subject: RFR: 8375621: Move RBTree implementation to inline file to minimize included headers [v2] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 12:36:08 GMT, Stefan Karlsson wrote: >> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: >> >> feedback fixes > > src/hotspot/share/utilities/rbTree.hpp line 68: > >> 66: class outputStream; >> 67: class Arena; >> 68: class ResourceArea; > > Brownie points if you also sort the forward declarations. The forward declarations are required by the Arena/ResourceArea allocator classes, so they would need to stay as it is currently. Since all definitions are in `rbTree.hpp`, we need to keep them for now. We could perhaps split up the various tree variants into a separate file, but I feel that would be out of scope here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29295#discussion_r2705114757 From roland at openjdk.org Mon Jan 19 15:32:07 2026 From: roland at openjdk.org (Roland Westrelin) Date: Mon, 19 Jan 2026 15:32:07 GMT Subject: RFR: 8373343: C2: verify AddP base input only set for heap addresses [v6] In-Reply-To: References: Message-ID: > 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 15 additional commits since the last revision: - Merge branch 'master' into JDK-8373343 - Update src/hotspot/share/opto/macroArrayCopy.cpp Co-authored-by: Dean Long <17332032+dean-long at users.noreply.github.com> - more - more - review - Merge branch 'master' into JDK-8373343 - review - review - review - merge - ... and 5 more: https://git.openjdk.org/jdk/compare/370d2034...2f618436 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28769/files - new: https://git.openjdk.org/jdk/pull/28769/files/507b8f45..2f618436 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28769&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28769&range=04-05 Stats: 61075 lines in 1252 files changed: 30953 ins; 11926 del; 18196 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 roland at openjdk.org Mon Jan 19 15:32:09 2026 From: roland at openjdk.org (Roland Westrelin) Date: Mon, 19 Jan 2026 15:32:09 GMT Subject: RFR: 8373343: C2: verify AddP base input only set for heap addresses [v3] In-Reply-To: <-GY9oBe-WRSh16Yi90rp79Xxi784nRtvdqBlMh4TiMs=.ba972df0-9298-4f94-8699-597601bd39ba@github.com> References: <-GY9oBe-WRSh16Yi90rp79Xxi784nRtvdqBlMh4TiMs=.ba972df0-9298-4f94-8699-597601bd39ba@github.com> Message-ID: On Sat, 20 Dec 2025 03:31:13 GMT, Dean Long wrote: >> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision: >> >> review > > Tests passed. I merged with latest. Can one of you @dean-long @chhagedorn @merykitty , re-approve? Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28769#issuecomment-3768888493 From epeter at openjdk.org Mon Jan 19 16:10:04 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 19 Jan 2026 16:10:04 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v12] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 08:56:21 GMT, Jatin Bhateja 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. >> >> image >> >> 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 28 commits: > > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Adding testpoint for JDK-8373574 > - Review comments resolutions > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Fix incorrect argument passed to smokeTest > - 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 > - ... and 18 more: https://git.openjdk.org/jdk/compare/499b5882...273b219e @jatin-bhateja I had a quick look at some of the changes. The patch is HUGE (80k+ lines), so it will take me a bit more time to review. I also realized that quite some changes are not directly related. For example, you are renaming lots of existing files. I would prefer if those changes were done separately. The issue is that at some point GitHub chokes, and it is no fun doing the review :/ src/hotspot/share/opto/vectorIntrinsics.cpp line 2895: > 2893: opd1 = gvn().transform(VectorNode::make(Op_AndV, opd1, wrap_mask_vec, opd1->bottom_type()->is_vect())); > 2894: operation = gvn().transform(VectorNode::make(Op_SelectFromTwoVector, opd1, opd2, opd3, vt)); > 2895: VectorNode::trace_new_vector(operation, "VectorAPI"); I thought you wanted to add that in a separate RFE? src/hotspot/share/prims/vectorSupport.cpp line 206: > 204: } > 205: > 206: int VectorSupport::vop2ideal(jint id, int lane_type) { I think it would be nice if there was a name for `LaneType`. It's just nicer to have types named. After all, the code here used to use `BasicType`, and it helps the user know what is expected here. src/hotspot/share/prims/vectorSupport.cpp line 244: > 242: case T_FLOAT: return Op_MulF; > 243: case T_DOUBLE: return Op_MulD; > 244: default: fatal("MUL: %s", lanetype2name(lane_type)); You should fix the indentation here as well, since you are already doing it everywhere else ;) src/hotspot/share/utilities/globalDefinitions.hpp line 719: > 717: > 718: inline bool is_java_primitive(BasicType t) { > 719: return (t != T_FLOAT16 && T_BOOLEAN <= t && t <= T_LONG); This change seems unnecessary, right? `T_FLOAT16` is outside the range, as far as I can see. src/hotspot/share/utilities/globalDefinitions.hpp line 741: > 739: inline bool is_custom_basic_type(BasicType t) { > 740: return (t == T_FLOAT16); > 741: } What exactly is the definition of a "custom" basic type? Is it defined somewhere? If not, it would be useful to define it here. I assume you chose the name because we expect more such "custom" basic types in the future? ------------- Changes requested by epeter (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28002#pullrequestreview-3678699226 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2705309070 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2705323981 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2705316085 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2705333596 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2705291064 From epeter at openjdk.org Mon Jan 19 16:19:02 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 19 Jan 2026 16:19:02 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v12] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 08:56:21 GMT, Jatin Bhateja 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. >> >> image >> >> 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 28 commits: > > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Adding testpoint for JDK-8373574 > - Review comments resolutions > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Fix incorrect argument passed to smokeTest > - 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 > - ... and 18 more: https://git.openjdk.org/jdk/compare/499b5882...273b219e test/jdk/jdk/incubator/vector/IntVectorMaxTests.java line 68: > 66: static IntVector bcast_vec = IntVector.broadcast(SPECIES, (int)10); > 67: > 68: static void AssertEquals(int actual, int expected) { There are lots of changes in this file that do not seem to have anything to do with Float16. Please file them separately. It will make review much easier. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2705376899 From kbarrett at openjdk.org Mon Jan 19 17:04:22 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 19 Jan 2026 17:04:22 GMT Subject: RFR: 8375046: C2: Assertion failed in GrowableArray::remove_till(0) [v5] In-Reply-To: References: <_tSvASngm2bL0X2wavXI63kJZoypsY5S-dus_KGhs18=.ace489be-48bf-4254-a88e-b4fe456edf02@github.com> Message-ID: <0u-ijj37dOJVvhhx439dzyuRXkiDsqsVR86x8IabyLE=.7c82841b-8e83-4999-8fc0-5f01ef129a6a@github.com> On Mon, 19 Jan 2026 10:31:35 GMT, Aleksey Shipilev wrote: >> Seen this assert in stress CTW runs: >> >> >> # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/utilities/growableArray.hpp:498), pid=2972347, tid=2973775 >> # assert(start < end && end <= this->_len) failed: erase called with invalid range (0, 0) for length 0 >> >> Stack: [0x00007fd660bea000,0x00007fd660cea000], sp=0x00007fd660ce4fc0, free space=1003k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0xc00a41] Compile::inline_incrementally_one()+0x801 (growableArray.hpp:498) >> V [libjvm.so+0xc01650] Compile::inline_incrementally(PhaseIterGVN&)+0x2f0 (compile.cpp:2212) >> V [libjvm.so+0xc04581] Compile::Optimize()+0x7d1 (compile.cpp:2357) >> >> >> It looks innocuous, as `GrowableArray::remove_range` does nothing real on `[0, 0)`. It is still IMO a bug to call it with `[0, 0)`, as it is not clear whether to trust inclusive or exclusive boundary. But for `remove_till`, it looks plausible that `remove_till(0)` should work and be a no-op. Looks like it readily happens in C2 CTW when `_late_inlines` is empty. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, additional new gtest to verify `remove_range` works >> - [x] Linux x86_64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - Missing case > - More tests > - Merge branch 'master' into JDK-8375046-growable-array-till-zero > - Revert > - Leave only the C2 fix > - Merge branch 'master' into JDK-8375046-growable-array-till-zero > - Only clear pos when needed > - Handle the C2 side by removing/inlining remove_till > - No trailing comma > - Fix Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29171#pullrequestreview-3679014527 From kevinw at openjdk.org Mon Jan 19 17:34:34 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 19 Jan 2026 17:34:34 GMT Subject: RFR: 8359706: Add file descriptor count and maximum limit to VM.info [v6] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 19:19:37 GMT, Kieran Farrell wrote: >> 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 Hi - Could you include an example of what this looks like in context, an excerpt from the whole output showing the new info in context? It's between "printing heap information" and "printing GC information", which might be a bit odd as those things should stay grouped together for humans to read? Would it be a better fit in the "OS:" section which is where we show e.g. limit information. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27971#issuecomment-3769485949 From duke at openjdk.org Mon Jan 19 17:50:35 2026 From: duke at openjdk.org (duke) Date: Mon, 19 Jan 2026 17:50:35 GMT Subject: Withdrawn: 8368621: In ASAN builds, attached non-main threads should have meaningful native names In-Reply-To: <4zmlXlIDkEzmmAPyxid7-9tU1QZPMNA9xcfNdj_vviE=.6797c163-f500-4076-a5df-e384b9b79251@github.com> References: <4zmlXlIDkEzmmAPyxid7-9tU1QZPMNA9xcfNdj_vviE=.6797c163-f500-4076-a5df-e384b9b79251@github.com> Message-ID: On Sat, 27 Sep 2025 08:04:51 GMT, Thomas Stuefe wrote: > See issue description and discussion. We set the thread name at the OS level, but only for ASAN builds, since outside of that narrow use case we consider attached threads to be owned by the application, not us, so we don't interfere with it. > > Tested manually with an ASAN build and a custom java launcher that attaches some native threads. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27535 From kbarrett at openjdk.org Mon Jan 19 18:08:34 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 19 Jan 2026 18:08:34 GMT Subject: RFR: 8375093: Convert GlobalCounter to use Atomic In-Reply-To: References: <4HQF7pmcR9csgDnzbEg4NadMMwpQhNYEorH4ur2PgBE=.cd557e7e-183d-4789-bf54-567c9e816c0a@github.com> Message-ID: On Fri, 16 Jan 2026 04:34:37 GMT, David Holmes wrote: >> Please review this change to make GlobalCounter use Atomic instead of >> AtomicAccess. >> >> Testing: mach5 tier1 > > This all seems fine. Thanks. Thanks for reviews @dholmes-ora and @walulyai ------------- PR Comment: https://git.openjdk.org/jdk/pull/29256#issuecomment-3769581821 From kbarrett at openjdk.org Mon Jan 19 18:08:36 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 19 Jan 2026 18:08:36 GMT Subject: Integrated: 8375093: Convert GlobalCounter to use Atomic In-Reply-To: <4HQF7pmcR9csgDnzbEg4NadMMwpQhNYEorH4ur2PgBE=.cd557e7e-183d-4789-bf54-567c9e816c0a@github.com> References: <4HQF7pmcR9csgDnzbEg4NadMMwpQhNYEorH4ur2PgBE=.cd557e7e-183d-4789-bf54-567c9e816c0a@github.com> Message-ID: On Thu, 15 Jan 2026 19:46:39 GMT, Kim Barrett wrote: > Please review this change to make GlobalCounter use Atomic instead of > AtomicAccess. > > Testing: mach5 tier1 This pull request has now been integrated. Changeset: 496af3cf Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/496af3cf4769b78fa0928450a87928d259511c51 Stats: 24 lines in 5 files changed: 3 ins; 1 del; 20 mod 8375093: Convert GlobalCounter to use Atomic Reviewed-by: dholmes, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/29256 From duke at openjdk.org Mon Jan 19 21:10:11 2026 From: duke at openjdk.org (Chad Rakoczy) Date: Mon, 19 Jan 2026 21:10:11 GMT Subject: RFR: 8374513: AArch64: Improve receiver type profiling reliability Message-ID: [JDK-8374513](https://bugs.openjdk.org/browse/JDK-8374513) is the AArch64 port of [JDK-8357258](https://bugs.openjdk.org/browse/JDK-8357258). See the bug report for more detailed information. This PR executes the plan outlined in the bug: - Common the receiver type profiling code in interpreter and C1 - Rewrite receiver type profiling code to only do atomic receiver slot installations - 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. Functional Testing: Linux AArch64 fastdebug Tier1-4 Performance Testing (to show there is no performance regression): # Baseline Benchmark (randomized) Mode Cnt Score Error Units InterfaceCalls.test1stInt2Types false avgt 12 1.940 ? 0.002 ns/op InterfaceCalls.test1stInt2Types true avgt 12 7.714 ? 0.011 ns/op InterfaceCalls.test1stInt3Types false avgt 12 6.747 ? 0.066 ns/op InterfaceCalls.test1stInt3Types true avgt 12 18.733 ? 0.175 ns/op InterfaceCalls.test1stInt5Types false avgt 12 6.690 ? 0.083 ns/op InterfaceCalls.test1stInt5Types true avgt 12 21.299 ? 0.016 ns/op InterfaceCalls.test2ndInt2Types false avgt 12 1.997 ? 0.004 ns/op InterfaceCalls.test2ndInt2Types true avgt 12 8.027 ? 0.016 ns/op InterfaceCalls.test2ndInt3Types false avgt 12 7.915 ? 0.114 ns/op InterfaceCalls.test2ndInt3Types true avgt 12 16.988 ? 0.065 ns/op InterfaceCalls.test2ndInt5Types false avgt 12 9.422 ? 0.017 ns/op InterfaceCalls.test2ndInt5Types true avgt 12 22.736 ? 0.022 ns/op InterfaceCalls.testIfaceCall false avgt 12 5.860 ? 0.046 ns/op InterfaceCalls.testIfaceCall true avgt 12 5.794 ? 0.026 ns/op InterfaceCalls.testIfaceExtCall false avgt 12 6.310 ? 0.067 ns/op InterfaceCalls.testIfaceExtCall true avgt 12 6.239 ? 0.017 ns/op InterfaceCalls.testMonomorphic false avgt 12 1.146 ? 0.034 ns/op InterfaceCalls.testMonomorphic true avgt 12 1.131 ? 0.012 ns/op # With PR Benchmark (randomized) Mode Cnt Score Error Units InterfaceCalls.test1stInt2Types false avgt 12 1.941 ? 0.004 ns/op InterfaceCalls.test1stInt2Types true avgt 12 7.707 ? 0.020 ns/op InterfaceCalls.test1stInt3Types false avgt 12 6.676 ? 0.068 ns/op InterfaceCalls.test1stInt3Types true avgt 12 18.624 ? 0.067 ns/op InterfaceCalls.test1stInt5Types false avgt 12 6.717 ? 0.071 ns/op InterfaceCalls.test1stInt5Types true avgt 12 21.304 ? 0.040 ns/op InterfaceCalls.test2ndInt2Types false avgt 12 1.993 ? 0.010 ns/op InterfaceCalls.test2ndInt2Types true avgt 12 8.048 ? 0.052 ns/op InterfaceCalls.test2ndInt3Types false avgt 12 7.914 ? 0.097 ns/op InterfaceCalls.test2ndInt3Types true avgt 12 17.217 ? 0.548 ns/op InterfaceCalls.test2ndInt5Types false avgt 12 9.453 ? 0.067 ns/op InterfaceCalls.test2ndInt5Types true avgt 12 22.868 ? 0.279 ns/op InterfaceCalls.testIfaceCall false avgt 12 5.772 ? 0.005 ns/op InterfaceCalls.testIfaceCall true avgt 12 5.838 ? 0.070 ns/op InterfaceCalls.testIfaceExtCall false avgt 12 6.249 ? 0.008 ns/op InterfaceCalls.testIfaceExtCall true avgt 12 6.299 ? 0.141 ns/op InterfaceCalls.testMonomorphic false avgt 12 1.128 ? 0.021 ns/op InterfaceCalls.testMonomorphic true avgt 12 1.124 ? 0.018 ns/op ------------- Commit messages: - Fix CAS and improve branch check - Merge remote-tracking branch 'origin/master' into receiver-type-8374513 - Fix bug - Remove pointer size scaling - Initial aarch64 implementation Changes: https://git.openjdk.org/jdk/pull/29283/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29283&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374513 Stats: 390 lines in 7 files changed: 161 ins; 207 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/29283.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29283/head:pull/29283 PR: https://git.openjdk.org/jdk/pull/29283 From aph at openjdk.org Mon Jan 19 21:10:13 2026 From: aph at openjdk.org (Andrew Haley) Date: Mon, 19 Jan 2026 21:10:13 GMT Subject: RFR: 8374513: AArch64: Improve receiver type profiling reliability In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 01:28:40 GMT, Chad Rakoczy wrote: > [JDK-8374513](https://bugs.openjdk.org/browse/JDK-8374513) is the AArch64 port of [JDK-8357258](https://bugs.openjdk.org/browse/JDK-8357258). See the bug report for more detailed information. > > This PR executes the plan outlined in the bug: > - Common the receiver type profiling code in interpreter and C1 > - Rewrite receiver type profiling code to only do atomic receiver slot installations > - 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. > > Functional Testing: Linux AArch64 fastdebug Tier1-4 > > Performance Testing (to show there is no performance regression): > > # Baseline > Benchmark (randomized) Mode Cnt Score Error Units > InterfaceCalls.test1stInt2Types false avgt 12 1.940 ? 0.002 ns/op > InterfaceCalls.test1stInt2Types true avgt 12 7.714 ? 0.011 ns/op > InterfaceCalls.test1stInt3Types false avgt 12 6.747 ? 0.066 ns/op > InterfaceCalls.test1stInt3Types true avgt 12 18.733 ? 0.175 ns/op > InterfaceCalls.test1stInt5Types false avgt 12 6.690 ? 0.083 ns/op > InterfaceCalls.test1stInt5Types true avgt 12 21.299 ? 0.016 ns/op > InterfaceCalls.test2ndInt2Types false avgt 12 1.997 ? 0.004 ns/op > InterfaceCalls.test2ndInt2Types true avgt 12 8.027 ? 0.016 ns/op > InterfaceCalls.test2ndInt3Types false avgt 12 7.915 ? 0.114 ns/op > InterfaceCalls.test2ndInt3Types true avgt 12 16.988 ? 0.065 ns/op > InterfaceCalls.test2ndInt5Types false avgt 12 9.422 ? 0.017 ns/op > InterfaceCalls.test2ndInt5Types true avgt 12 22.736 ? 0.022 ns/op > InterfaceCalls.testIfaceCall false avgt 12 5.860 ? 0.046 ns/op > InterfaceCalls.testIfaceCall true avgt 12 5.794 ? 0.026 ns/op > InterfaceCalls.testIfaceExtCall false avgt 12 6.310 ? 0.067 ns/op > InterfaceCalls.testIfaceExtCall true avgt 12 6.239 ? 0.017 ns/op > InterfaceCalls.testMonomorphic false avgt 12 1.146 ? 0.034 ns/op > InterfaceCalls.testMonomorphic true avgt 12 1.131 ? 0.012 ns/op > > # With PR > Benchmark (randomized) Mode Cnt Score Error Units > InterfaceCalls.test1stInt2Types false avgt 12 1.941 ? 0.004 ns/op > InterfaceCalls.test1stIn... src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 2232: > 2230: mov(rscratch2, end_receiver_offset); > 2231: cmp(offset, rscratch2); > 2232: br(Assembler::NE, L_loop_search_receiver); Suggestion: sub(rscratch2, offset, end_receiver_offset); cbz(rscratch2, L_loop_search_receiver); src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 2239: > 2237: ldr(rscratch2, Address(mdp, offset)); > 2238: cmp(rscratch2, (u1)NULL_WORD); > 2239: br(Assembler::EQ, L_found_empty); Suggestion: cbz(rscratch2, L_found_empty); src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 2256: > 2254: lea(rscratch2, Address(mdp, offset)); > 2255: cmpxchg(/*addr*/ rscratch2, /*expected*/ zr, /*new*/ recv, Assembler::xword, > 2256: /*acquire*/ true, /*release*/ false, /*weak*/ false, noreg); /*acquire*/ true, /*release*/ false, /*weak*/ false, noreg); I'm curious about the acquire. For it to make sense here, I would have thought it must be linked with an earlier release in another thread. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29283#discussion_r2701847302 PR Review Comment: https://git.openjdk.org/jdk/pull/29283#discussion_r2701800282 PR Review Comment: https://git.openjdk.org/jdk/pull/29283#discussion_r2701839882 From shade at openjdk.org Mon Jan 19 21:10:15 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 19 Jan 2026 21:10:15 GMT Subject: RFR: 8374513: AArch64: Improve receiver type profiling reliability In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 23:40:45 GMT, Andrew Haley wrote: >> [JDK-8374513](https://bugs.openjdk.org/browse/JDK-8374513) is the AArch64 port of [JDK-8357258](https://bugs.openjdk.org/browse/JDK-8357258). See the bug report for more detailed information. >> >> This PR executes the plan outlined in the bug: >> - Common the receiver type profiling code in interpreter and C1 >> - Rewrite receiver type profiling code to only do atomic receiver slot installations >> - 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. >> >> Functional Testing: Linux AArch64 fastdebug Tier1-4 >> >> Performance Testing (to show there is no performance regression): >> >> # Baseline >> Benchmark (randomized) Mode Cnt Score Error Units >> InterfaceCalls.test1stInt2Types false avgt 12 1.940 ? 0.002 ns/op >> InterfaceCalls.test1stInt2Types true avgt 12 7.714 ? 0.011 ns/op >> InterfaceCalls.test1stInt3Types false avgt 12 6.747 ? 0.066 ns/op >> InterfaceCalls.test1stInt3Types true avgt 12 18.733 ? 0.175 ns/op >> InterfaceCalls.test1stInt5Types false avgt 12 6.690 ? 0.083 ns/op >> InterfaceCalls.test1stInt5Types true avgt 12 21.299 ? 0.016 ns/op >> InterfaceCalls.test2ndInt2Types false avgt 12 1.997 ? 0.004 ns/op >> InterfaceCalls.test2ndInt2Types true avgt 12 8.027 ? 0.016 ns/op >> InterfaceCalls.test2ndInt3Types false avgt 12 7.915 ? 0.114 ns/op >> InterfaceCalls.test2ndInt3Types true avgt 12 16.988 ? 0.065 ns/op >> InterfaceCalls.test2ndInt5Types false avgt 12 9.422 ? 0.017 ns/op >> InterfaceCalls.test2ndInt5Types true avgt 12 22.736 ? 0.022 ns/op >> InterfaceCalls.testIfaceCall false avgt 12 5.860 ? 0.046 ns/op >> InterfaceCalls.testIfaceCall true avgt 12 5.794 ? 0.026 ns/op >> InterfaceCalls.testIfaceExtCall false avgt 12 6.310 ? 0.067 ns/op >> InterfaceCalls.testIfaceExtCall true avgt 12 6.239 ? 0.017 ns/op >> InterfaceCalls.testMonomorphic false avgt 12 1.146 ? 0.034 ns/op >> InterfaceCalls.testMonomorphic true avgt 12 1.131 ? 0.012 ns/op >> >> # With PR >> Benchmark (randomized) Mode Cnt Score Error Units >> InterfaceCalls.test1stInt2Type... > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 2256: > >> 2254: lea(rscratch2, Address(mdp, offset)); >> 2255: cmpxchg(/*addr*/ rscratch2, /*expected*/ zr, /*new*/ recv, Assembler::xword, >> 2256: /*acquire*/ true, /*release*/ false, /*weak*/ false, noreg); > > /*acquire*/ true, /*release*/ false, /*weak*/ false, noreg); > > I'm curious about the acquire. For it to make sense here, I would have thought it must be linked with an earlier release in another thread. We can use `acquire = false`, `release = false` here. This CAS only claims the empty slot for the new receiver type. There is nothing else riding on memory effects of this. So this CAS needs atomicity only, and additional memory effects are superfluous. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29283#discussion_r2703640346 From kfarrell at openjdk.org Mon Jan 19 21:10:35 2026 From: kfarrell at openjdk.org (Kieran Farrell) Date: Mon, 19 Jan 2026 21:10:35 GMT Subject: RFR: 8359706: Add file descriptor count and maximum limit to VM.info [v6] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 17:31:10 GMT, Kevin Walls wrote: >> 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 > > Hi - Could you include an example of what this looks like in context, an excerpt from the whole output showing the new info in context? > > It's between "printing heap information" and "printing GC information", which might be a bit odd as those things should stay grouped together for humans to read? > > Would it be a better fit in the "OS:" section which is where we show e.g. limit information. Hi @kevinjwalls, here is a snippit from the current position under "PROCESS". I added it here since the count is process related but I agree it might be nice to have it closer to the NOFILE count int the "OS" section under "SYSTEM". --------------- P R O C E S S --------------- Heap address: 0x0000000320000000, size: 9216 MB, Compressed Oops mode: Zero based, Oop shift amount: 3 CDS archive(s) not mapped Compressed class space mapped at: 0x00000fc000000000-0x00000fc040000000, reserved size: 1073741824 UseCompressedClassPointers 1, UseCompactObjectHeaders 0 Narrow klass pointer bits 32, Max shift 3 Narrow klass base: 0x00000fc000000000, Narrow klass shift: 0 Encoding Range: [0x00000fc000000000 - 0x00000fc100000000), (4294967296 bytes) Klass Range: [0x00000fc000000000 - 0x00000fc040000000), (1073741824 bytes) Klass ID Range: [8 - 1073741817) (1073741809) Protection zone: [0x00000fc000000000 - 0x00000fc000010000), (65536 bytes) OpenFileDescriptorCount = 5 GC Precious Log: CardTable entry size: 512 Card Set container configuration: InlinePtr #cards 4 size 8 Array Of Cards #cards 64 size 144 Howl #buckets 8 coarsen threshold 14745 Howl Bitmap #cards 2048 size 272 coarsen threshold 1843 Card regions per heap region 1 cards per card region 16384 CPUs: 11 total, 11 available Memory: 36864M Large Page Support: Disabled NUMA Support: Disabled Compressed Oops: Enabled (Zero based) Heap Region Size: 8M Heap Min Capacity: 8M Heap Initial Capacity: 8M Heap Max Capacity: 9G Pre-touch: Disabled Parallel Workers: 9 Concurrent Workers: 2 Concurrent Refinement Workers: 9 Periodic GC: Disabled Heap: garbage-first heap total reserved 9437184K, committed 8192K, used 4545K [0x0000000320000000, 0x0000000560000000) region size 8M, 1 eden (8M), 0 survivor (0M), 0 old (0M), 0 humongous (0M), 0 free (0M) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27971#issuecomment-3770120194 From missa at openjdk.org Mon Jan 19 23:08:40 2026 From: missa at openjdk.org (Mohamed Issa) Date: Mon, 19 Jan 2026 23:08:40 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v6] In-Reply-To: References: Message-ID: > Intel® 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 with a new target base due to a merge or a rebase. The pull request now contains 23 commits: - Change function names and extend IR encoding rules for CMove tests - Merge remote-tracking branch 'origin/master' into user/missa-prime/avx10_2 - Remove unnecessary CMOV blocks and adjust predicates involving APX and AVX10.2 - Remove extra jump instruction in signum floating point and unify three-way floating point comparison logic in x86.ad - Also update copyright year in IREncodingPrinter.java - Include apx_f in list of verified CPU features for IR encoding - 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 - ... and 13 more: https://git.openjdk.org/jdk/compare/e7432d57...2fecf9f5 ------------- Changes: https://git.openjdk.org/jdk/pull/28337/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28337&range=05 Stats: 863 lines in 10 files changed: 663 ins; 105 del; 95 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 Mon Jan 19 23:15:06 2026 From: missa at openjdk.org (Mohamed Issa) Date: Mon, 19 Jan 2026 23:15:06 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v5] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 17:25:08 GMT, Sandhya Viswanathan wrote: >> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unnecessary CMOV blocks and adjust predicates involving APX and AVX10.2 > > src/hotspot/cpu/x86/assembler_x86.cpp line 7357: > >> 7355: } >> 7356: >> 7357: void Assembler::ucomxss(XMMRegister dst, Address src) { > > ucomxss should be named as vucomxss. > ucomxsd should be named as vucomxsd. I re-named them. > src/hotspot/cpu/x86/x86.ad line 1703: > >> 1701: static void emit_cmpfp3(MacroAssembler* masm, Register dst) { >> 1702: // If any floating point comparison instruction is used, unordered case always triggers jump >> 1703: // For below condition, CF=1 is true when at least one input is NaN > > // for > lowercase f in for. This is modified now. > test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java line 64: > >> 62: @IR(counts = {IRNode.X86_CMOVEL_IMM01UCFE, "1"}, >> 63: applyIfPlatform = {"x64", "true"}, >> 64: applyIfCPUFeature = {"apx_f", "true"}, > > Need to include avx10_2 check here as well. I added the avx10_2 checks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2706285643 PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2706285351 PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2706286308 From erfang at openjdk.org Tue Jan 20 01:33:36 2026 From: erfang at openjdk.org (Eric Fang) Date: Tue, 20 Jan 2026 01:33:36 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v8] In-Reply-To: References: Message-ID: <6_ZqCg4GNfBg0NonFKzf24z0NCkuRKRZQ9T2VVXUg0E=.745f107f-985f-4e7a-ac51-63c86ac7034f@github.com> On Mon, 19 Jan 2026 08:57:23 GMT, Jatin Bhateja wrote: > > @jatin-bhateja I have no further comments, great work. After this PR is merged, I will complete the backend optimization of the aarch64 part based on it. Thanks! > > Thanks @erifan , I think partial case is specific for AARCH64 backend and tests should accompany relevant AARCH64 changes. Thanks, @jatin-bhateja. Make sense. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3770638063 From missa at openjdk.org Tue Jan 20 01:48:53 2026 From: missa at openjdk.org (Mohamed Issa) Date: Tue, 20 Jan 2026 01:48:53 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v7] In-Reply-To: References: Message-ID: <4r0vCH4670oyysJREP_VTToXt8DLQh6uuvrWyANuzXg=.5d7073b2-988f-41fd-8efc-f84af358c9f5@github.com> > Intel® 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 with a new target base due to a merge or a rebase. The pull request now contains 24 commits: - Merge branch 'master' into user/missa-prime/avx10_2 - Change function names and extend IR encoding rules for CMove tests - Merge remote-tracking branch 'origin/master' into user/missa-prime/avx10_2 - Remove unnecessary CMOV blocks and adjust predicates involving APX and AVX10.2 - Remove extra jump instruction in signum floating point and unify three-way floating point comparison logic in x86.ad - Also update copyright year in IREncodingPrinter.java - Include apx_f in list of verified CPU features for IR encoding - 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! - ... and 14 more: https://git.openjdk.org/jdk/compare/496af3cf...6a02cab7 ------------- Changes: https://git.openjdk.org/jdk/pull/28337/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28337&range=06 Stats: 862 lines in 10 files changed: 663 ins; 105 del; 94 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 duke at openjdk.org Tue Jan 20 07:33:39 2026 From: duke at openjdk.org (Harshit470250) Date: Tue, 20 Jan 2026 07:33:39 GMT Subject: RFR: 8347396: Efficient TypeFunc creations [v5] In-Reply-To: References: Message-ID: > 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 one additional commit since the last revision: move include shenandoah to bottom ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27279/files - new: https://git.openjdk.org/jdk/pull/27279/files/630e4be0..6a02f24e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27279&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27279&range=03-04 Stats: 7 lines in 1 file changed: 4 ins; 3 del; 0 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 duke at openjdk.org Tue Jan 20 08:57:52 2026 From: duke at openjdk.org (Ivan Bereziuk) Date: Tue, 20 Jan 2026 08:57:52 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: References: Message-ID: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> > `jcmd` provides great diagnostics but many commands lack a timestamp in their output. > Adding a timestamp to the output of some would add value for those debugging JVM data. > > Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. > > With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-T": > > jcmd [pid | main-class] [-T] command... | PerfCounter.print | -f filename > ^^^^ > > * The choice for time format is "yyyy-MM-dd HH:mm:ss" as it is already used in `Thread.print`. > * `Thread.print` prints timestamp irrespectively from "-T" flag presence to preserve backwards compatibility. > > I haven't added a timestamp to the following diagnostic command: > * `VM.uptime` - command run with `-date` argument will also print a timestamp; > * `VM.system_properties` - as the output already lists a timestamp. Not sure if we need more timestamps here. > * `Thread.dump_to_file` - the content dumped to a file already has a timestamp; Ivan Bereziuk 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 15 additional commits since the last revision: - remove TimeStamp::No as it's not used. virtual should be flipped to override in bulk (afressed clang warning) - Merge branch 'master' into 8357828_add_timestamp_to_jcmd - changes to jcmd.md - undo changes to reorder_help_cmd() - cleanup - add timestamp to VM.version. Add test - updated jcmd usage text - undo the changes to the modified earlier tests as timestamp presence is fully backwards compatible - introduce -T as a commong flag - Merge branch 'master' into 8357828_add_timestamp_to_jcmd - ... and 5 more: https://git.openjdk.org/jdk/compare/d1597314...5f1cefe0 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27368/files - new: https://git.openjdk.org/jdk/pull/27368/files/bfa2a927..5f1cefe0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27368&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27368&range=00-01 Stats: 648983 lines in 8151 files changed: 439394 ins; 124768 del; 84821 mod Patch: https://git.openjdk.org/jdk/pull/27368.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27368/head:pull/27368 PR: https://git.openjdk.org/jdk/pull/27368 From shade at openjdk.org Tue Jan 20 09:39:12 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 20 Jan 2026 09:39:12 GMT Subject: RFR: 8374513: AArch64: Improve receiver type profiling reliability In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 01:28:40 GMT, Chad Rakoczy wrote: > [JDK-8374513](https://bugs.openjdk.org/browse/JDK-8374513) is the AArch64 port of [JDK-8357258](https://bugs.openjdk.org/browse/JDK-8357258). See the bug report for more detailed information. > > This PR executes the plan outlined in the bug: > - Common the receiver type profiling code in interpreter and C1 > - Rewrite receiver type profiling code to only do atomic receiver slot installations > - 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. > > Functional Testing: Linux AArch64 fastdebug Tier1-4 > > Performance Testing (to show there is no performance regression): > > # Baseline > Benchmark (randomized) Mode Cnt Score Error Units > InterfaceCalls.test1stInt2Types false avgt 12 1.940 ? 0.002 ns/op > InterfaceCalls.test1stInt2Types true avgt 12 7.714 ? 0.011 ns/op > InterfaceCalls.test1stInt3Types false avgt 12 6.747 ? 0.066 ns/op > InterfaceCalls.test1stInt3Types true avgt 12 18.733 ? 0.175 ns/op > InterfaceCalls.test1stInt5Types false avgt 12 6.690 ? 0.083 ns/op > InterfaceCalls.test1stInt5Types true avgt 12 21.299 ? 0.016 ns/op > InterfaceCalls.test2ndInt2Types false avgt 12 1.997 ? 0.004 ns/op > InterfaceCalls.test2ndInt2Types true avgt 12 8.027 ? 0.016 ns/op > InterfaceCalls.test2ndInt3Types false avgt 12 7.915 ? 0.114 ns/op > InterfaceCalls.test2ndInt3Types true avgt 12 16.988 ? 0.065 ns/op > InterfaceCalls.test2ndInt5Types false avgt 12 9.422 ? 0.017 ns/op > InterfaceCalls.test2ndInt5Types true avgt 12 22.736 ? 0.022 ns/op > InterfaceCalls.testIfaceCall false avgt 12 5.860 ? 0.046 ns/op > InterfaceCalls.testIfaceCall true avgt 12 5.794 ? 0.026 ns/op > InterfaceCalls.testIfaceExtCall false avgt 12 6.310 ? 0.067 ns/op > InterfaceCalls.testIfaceExtCall true avgt 12 6.239 ? 0.017 ns/op > InterfaceCalls.testMonomorphic false avgt 12 1.146 ? 0.034 ns/op > InterfaceCalls.testMonomorphic true avgt 12 1.131 ? 0.012 ns/op > > # With PR > Benchmark (randomized) Mode Cnt Score Error Units > InterfaceCalls.test1stInt2Types false avgt 12 1.941 ? 0.004 ns/op > InterfaceCalls.test1stIn... Looks like a faithful port of x86 code, with aarch64 specific adjustments. @theRealAph should also take a close look. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29283#pullrequestreview-3681230006 From aph at openjdk.org Tue Jan 20 09:52:45 2026 From: aph at openjdk.org (Andrew Haley) Date: Tue, 20 Jan 2026 09:52:45 GMT Subject: RFR: 8374513: AArch64: Improve receiver type profiling reliability In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 01:28:40 GMT, Chad Rakoczy wrote: > [JDK-8374513](https://bugs.openjdk.org/browse/JDK-8374513) is the AArch64 port of [JDK-8357258](https://bugs.openjdk.org/browse/JDK-8357258). See the bug report for more detailed information. > > This PR executes the plan outlined in the bug: > - Common the receiver type profiling code in interpreter and C1 > - Rewrite receiver type profiling code to only do atomic receiver slot installations > - 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. > > Functional Testing: Linux AArch64 fastdebug Tier1-4 > > Performance Testing (to show there is no performance regression): > > # Baseline > Benchmark (randomized) Mode Cnt Score Error Units > InterfaceCalls.test1stInt2Types false avgt 12 1.940 ? 0.002 ns/op > InterfaceCalls.test1stInt2Types true avgt 12 7.714 ? 0.011 ns/op > InterfaceCalls.test1stInt3Types false avgt 12 6.747 ? 0.066 ns/op > InterfaceCalls.test1stInt3Types true avgt 12 18.733 ? 0.175 ns/op > InterfaceCalls.test1stInt5Types false avgt 12 6.690 ? 0.083 ns/op > InterfaceCalls.test1stInt5Types true avgt 12 21.299 ? 0.016 ns/op > InterfaceCalls.test2ndInt2Types false avgt 12 1.997 ? 0.004 ns/op > InterfaceCalls.test2ndInt2Types true avgt 12 8.027 ? 0.016 ns/op > InterfaceCalls.test2ndInt3Types false avgt 12 7.915 ? 0.114 ns/op > InterfaceCalls.test2ndInt3Types true avgt 12 16.988 ? 0.065 ns/op > InterfaceCalls.test2ndInt5Types false avgt 12 9.422 ? 0.017 ns/op > InterfaceCalls.test2ndInt5Types true avgt 12 22.736 ? 0.022 ns/op > InterfaceCalls.testIfaceCall false avgt 12 5.860 ? 0.046 ns/op > InterfaceCalls.testIfaceCall true avgt 12 5.794 ? 0.026 ns/op > InterfaceCalls.testIfaceExtCall false avgt 12 6.310 ? 0.067 ns/op > InterfaceCalls.testIfaceExtCall true avgt 12 6.239 ? 0.017 ns/op > InterfaceCalls.testMonomorphic false avgt 12 1.146 ? 0.034 ns/op > InterfaceCalls.testMonomorphic true avgt 12 1.131 ? 0.012 ns/op > > # With PR > Benchmark (randomized) Mode Cnt Score Error Units > InterfaceCalls.test1stInt2Types false avgt 12 1.941 ? 0.004 ns/op > InterfaceCalls.test1stIn... src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 2253: > 2251: lea(rscratch2, Address(mdp, offset)); > 2252: cmpxchg(/*addr*/ rscratch2, /*expected*/ zr, /*new*/ recv, Assembler::xword, > 2253: /*acquire*/ false, /*release*/ false, /*weak*/ false, noreg); Suggestion: /*acquire*/ false, /*release*/ false, /*weak*/ true, noreg); If we fail a weak CAS here we should retry the whole loop: it probably means someone else has claimed the slot. src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 2275: > 2273: ldr(rscratch2, Address(mdp, offset)); > 2274: add(rscratch2, rscratch2, DataLayout::counter_increment); > 2275: str(rscratch2, Address(mdp, offset)); Suggestion: increment(Address(mdp, offset), DataLayout::counter_increment); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29283#discussion_r2707587231 PR Review Comment: https://git.openjdk.org/jdk/pull/29283#discussion_r2707576268 From aph at openjdk.org Tue Jan 20 09:52:47 2026 From: aph at openjdk.org (Andrew Haley) Date: Tue, 20 Jan 2026 09:52:47 GMT Subject: RFR: 8374513: AArch64: Improve receiver type profiling reliability In-Reply-To: References: Message-ID: <5PYC9r4vV6IGhaXfhDFyBmpXds1v6dcAyFYv5SXs0g4=.f8632c92-44fe-4431-80ee-bbc816453145@github.com> On Tue, 20 Jan 2026 09:47:54 GMT, Andrew Haley wrote: >> [JDK-8374513](https://bugs.openjdk.org/browse/JDK-8374513) is the AArch64 port of [JDK-8357258](https://bugs.openjdk.org/browse/JDK-8357258). See the bug report for more detailed information. >> >> This PR executes the plan outlined in the bug: >> - Common the receiver type profiling code in interpreter and C1 >> - Rewrite receiver type profiling code to only do atomic receiver slot installations >> - 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. >> >> Functional Testing: Linux AArch64 fastdebug Tier1-4 >> >> Performance Testing (to show there is no performance regression): >> >> # Baseline >> Benchmark (randomized) Mode Cnt Score Error Units >> InterfaceCalls.test1stInt2Types false avgt 12 1.940 ? 0.002 ns/op >> InterfaceCalls.test1stInt2Types true avgt 12 7.714 ? 0.011 ns/op >> InterfaceCalls.test1stInt3Types false avgt 12 6.747 ? 0.066 ns/op >> InterfaceCalls.test1stInt3Types true avgt 12 18.733 ? 0.175 ns/op >> InterfaceCalls.test1stInt5Types false avgt 12 6.690 ? 0.083 ns/op >> InterfaceCalls.test1stInt5Types true avgt 12 21.299 ? 0.016 ns/op >> InterfaceCalls.test2ndInt2Types false avgt 12 1.997 ? 0.004 ns/op >> InterfaceCalls.test2ndInt2Types true avgt 12 8.027 ? 0.016 ns/op >> InterfaceCalls.test2ndInt3Types false avgt 12 7.915 ? 0.114 ns/op >> InterfaceCalls.test2ndInt3Types true avgt 12 16.988 ? 0.065 ns/op >> InterfaceCalls.test2ndInt5Types false avgt 12 9.422 ? 0.017 ns/op >> InterfaceCalls.test2ndInt5Types true avgt 12 22.736 ? 0.022 ns/op >> InterfaceCalls.testIfaceCall false avgt 12 5.860 ? 0.046 ns/op >> InterfaceCalls.testIfaceCall true avgt 12 5.794 ? 0.026 ns/op >> InterfaceCalls.testIfaceExtCall false avgt 12 6.310 ? 0.067 ns/op >> InterfaceCalls.testIfaceExtCall true avgt 12 6.239 ? 0.017 ns/op >> InterfaceCalls.testMonomorphic false avgt 12 1.146 ? 0.034 ns/op >> InterfaceCalls.testMonomorphic true avgt 12 1.131 ? 0.012 ns/op >> >> # With PR >> Benchmark (randomized) Mode Cnt Score Error Units >> InterfaceCalls.test1stInt2Type... > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 2275: > >> 2273: ldr(rscratch2, Address(mdp, offset)); >> 2274: add(rscratch2, rscratch2, DataLayout::counter_increment); >> 2275: str(rscratch2, Address(mdp, offset)); > > Suggestion: > > increment(Address(mdp, offset), DataLayout::counter_increment); ... then we're good to go. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29283#discussion_r2707581640 From adinn at openjdk.org Tue Jan 20 10:01:00 2026 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 20 Jan 2026 10:01:00 GMT Subject: RFR: 8372617: Save and restore stubgen stubs when using an AOT code cache [v2] In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 20:56:18 GMT, Ashutosh Mehra wrote: >> Andrew Dinn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits: >> >> - fix AOT externals after merge with main branch >> - Merge branch 'master' into save-stubgen-stubs >> - fix header declarations >> - move AOT address init impl into arch tree below StubRoutines >> - put AOT address table init code under INCLUDE_CDS >> - fix extras count to match number of unsafe handler regions >> - merge >> - more whitespace >> - rmeove whitespace >> - remove redundant comment >> - ... and 23 more: https://git.openjdk.org/jdk/compare/e0edc656...6e221ac6 > > src/hotspot/share/code/aotCodeCache.cpp line 191: > >> 189: >> 190: // Disable stubs caching until JDK-8357398 is fixed. >> 191: // FLAG_SET_ERGO(AOTStubCaching, false); > > I can't seem to access JDK-8357398. I am not sure if that bug is fixed or not. But if it is not fixed yet, I think we should keep this un-commented. I guess this was commented out for testing purpose. That's a private bug (I believe it related to some internal testing which cannot be made public). Yu are right that this change is there to ensure the test checks stub save and restore. I also tweaked the AOTCodeFlags test for the same purpose. This change cannot go in as is without checking that it avoids the issue in JDK-8357398. If it does not then we would need to reset the above edit and the test. However, that means tier1 testing could fail to catch stub changes that correctly update runtime generation but fail to cache (the most likely error is failing to register an external address with the AOT cache). So, I'd prefer it if we could recheck the problem in JDK-8357398 and leave these changes as is. Perhaps @vnkozlov could help here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28433#discussion_r2707614833 From duke at openjdk.org Tue Jan 20 10:07:19 2026 From: duke at openjdk.org (Ivan Bereziuk) Date: Tue, 20 Jan 2026 10:07:19 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> References: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> Message-ID: On Tue, 20 Jan 2026 08:57:52 GMT, Ivan Bereziuk wrote: >> `jcmd` provides great diagnostics but many commands lack a timestamp in their output. >> Adding a timestamp to the output of some would add value for those debugging JVM data. >> >> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. >> >> With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-T": >> >> jcmd [pid | main-class] [-T] command... | PerfCounter.print | -f filename >> ^^^^ >> >> * The choice for time format is "yyyy-MM-dd HH:mm:ss" as it is already used in `Thread.print`. >> * `Thread.print` prints timestamp irrespectively from "-T" flag presence to preserve backwards compatibility. >> >> I haven't added a timestamp to the following diagnostic command: >> * `VM.uptime` - command run with `-date` argument will also print a timestamp; >> * `VM.system_properties` - as the output already lists a timestamp. Not sure if we need more timestamps here. >> * `Thread.dump_to_file` - the content dumped to a file already has a timestamp; > > Ivan Bereziuk 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 15 additional commits since the last revision: > > - remove TimeStamp::No as it's not used. virtual should be flipped to override in bulk (afressed clang warning) > - Merge branch 'master' into 8357828_add_timestamp_to_jcmd > - changes to jcmd.md > - undo changes to reorder_help_cmd() > - cleanup > - add timestamp to VM.version. Add test > - updated jcmd usage text > - undo the changes to the modified earlier tests as timestamp presence is fully backwards compatible > - introduce -T as a commong flag > - Merge branch 'master' into 8357828_add_timestamp_to_jcmd > - ... and 5 more: https://git.openjdk.org/jdk/compare/e1bc2481...5f1cefe0 I've made timestamping optional with "-T" flag. The flag is part of the command sent to the target JVM. jcmd [pid | main-class] [-T] command... | PerfCounter.print | -f filename ^^^^ The target diagnostic command handler can decide how to act on it. @dholmes-ora > ... what form should this timestamp take? Shouldn't it be configurable to allow matching with what may be presented by Unified Logging e.g. VM uptime rather than wall-clock time? > And rather than add timestamp printing code to each dcmd it would make more sense to me to have a global dcmd flag that says "print a timestamp" (with a given format). `Thread.print` already prints a timestamp, hence explicit "-T" has no effect for this particular command. This also affected my choice for using format "yyyy-MM-dd HH:mm:ss". At least as a default. Do you think we need to be able changing the timestamp format (say "-T=UTC")? Should we add time-stamping to STDOUT from commands that are of "action" type? E.g. "GC.run". ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3772022851 From shade at openjdk.org Tue Jan 20 10:10:24 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 20 Jan 2026 10:10:24 GMT Subject: RFR: 8375438: G1: Convert G1HeapRegion related classes to use Atomic In-Reply-To: References: Message-ID: <6Zh622lkxXP3Sck23m9ZJo106Ng-smlA2isx32x5gRg=.26b26cf6-71bf-4fb5-ad49-d2d6d08c2422@github.com> On Mon, 19 Jan 2026 13:32:46 GMT, Thomas Schatzl wrote: > Hi all, > > please review conversion of G1HeapRegion related classes to use Atomic. > > Testing: tier1, tier4, tier5 > > (The PipelineLeaksFD failure in gha is a known issue) > > Thanks, > Thomas Can go a bit further: src/hotspot/share/gc/g1/g1HeapRegion.inline.hpp line 196: > 194: if (want_to_allocate >= min_word_size) { > 195: HeapWord* new_top = obj + want_to_allocate; > 196: HeapWord* result = _top.compare_exchange(obj, new_top); Since you are not using `result` beyond checking for CAS completion, you can probably do `if (_top.compare_set(obj_top)) { ... ` directly. This would also obviate the need for the comment on what CAE return value is supposed to signify. src/hotspot/share/gc/g1/g1HeapRegionManager.cpp line 740: > 738: bool G1HeapRegionClaimer::claim_region(uint region_index) { > 739: assert(region_index < _n_regions, "Invalid index."); > 740: uint old_val = _claims[region_index].compare_exchange(Unclaimed, Claimed); Same thing here, it could be just `return _claims[region_index].compare_set(Unclaimed, Claimed)`. ------------- PR Review: https://git.openjdk.org/jdk/pull/29301#pullrequestreview-3681362712 PR Review Comment: https://git.openjdk.org/jdk/pull/29301#discussion_r2707640538 PR Review Comment: https://git.openjdk.org/jdk/pull/29301#discussion_r2707646539 From adinn at openjdk.org Tue Jan 20 10:11:41 2026 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 20 Jan 2026 10:11:41 GMT Subject: RFR: 8372617: Save and restore stubgen stubs when using an AOT code cache [v3] In-Reply-To: References: Message-ID: <-qwoS6zv9_nT5ajzytJ_uybXPJs2KQOMlhoql3VXn0Q=.1b460019-b3c3-4d83-9e86-07151a4ee390@github.com> > This PR adds save and restore of all generated stubs to the AOT code cache on x86 and aarch64. Other arches are modified to deal with the related generic PAI changes. > > Small changes were required to the aarch64 and x86_64 generator code in order to meet two key constraints: > 1. the first declared entry of every stub starts at the first instruction in the stub code range > 2. all data/code cross-references from one stub to another target a declared stub entry Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: asmehra feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28433/files - new: https://git.openjdk.org/jdk/pull/28433/files/6e221ac6..ed8d2455 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28433&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28433&range=01-02 Stats: 37 lines in 4 files changed: 11 ins; 12 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/28433.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28433/head:pull/28433 PR: https://git.openjdk.org/jdk/pull/28433 From adinn at openjdk.org Tue Jan 20 10:11:43 2026 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 20 Jan 2026 10:11:43 GMT Subject: RFR: 8372617: Save and restore stubgen stubs when using an AOT code cache [v3] In-Reply-To: References: Message-ID: <5KjAUeWgN0IYP2TzFmbRT6OdkqW3vIHxxhTCw9xjB-8=.a9f074b1-c7ea-44ab-9033-ca83ac49b6a8@github.com> On Tue, 2 Dec 2025 16:43:19 GMT, Ashutosh Mehra wrote: >> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: >> >> asmehra feedback > > src/hotspot/share/runtime/stubCodeGenerator.cpp line 118: > >> 116: // default_handler. >> 117: >> 118: void StubCodeGenerator::register_unsafe_access_handlers(GrowableArray

&entries, int begin, int count) { > > Is there a case or is it possible that `begin` is non -zero? I think it is same to assume we need to register all the values in `entries` in the `UnsafeMemoryAccess::_table`, right? I think at present begin is always 0 but I'm not sure we can assume that for all future stubs all extra addresses will be unsafe ranges. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28433#discussion_r2707634118 From shade at openjdk.org Tue Jan 20 10:14:33 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 20 Jan 2026 10:14:33 GMT Subject: RFR: 8374513: AArch64: Improve receiver type profiling reliability In-Reply-To: <5PYC9r4vV6IGhaXfhDFyBmpXds1v6dcAyFYv5SXs0g4=.f8632c92-44fe-4431-80ee-bbc816453145@github.com> References: <5PYC9r4vV6IGhaXfhDFyBmpXds1v6dcAyFYv5SXs0g4=.f8632c92-44fe-4431-80ee-bbc816453145@github.com> Message-ID: On Tue, 20 Jan 2026 09:49:13 GMT, Andrew Haley wrote: >> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 2275: >> >>> 2273: ldr(rscratch2, Address(mdp, offset)); >>> 2274: add(rscratch2, rscratch2, DataLayout::counter_increment); >>> 2275: str(rscratch2, Address(mdp, offset)); >> >> Suggestion: >> >> increment(Address(mdp, offset), DataLayout::counter_increment); > > ... then we're good to go. Oh, there is `increment`, nice. There is another counter-update shortcut near `// Corner case: no profile table. Increment poly counter and exit.`, update that one too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29283#discussion_r2707657832 From shade at openjdk.org Tue Jan 20 10:14:31 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 20 Jan 2026 10:14:31 GMT Subject: RFR: 8374513: AArch64: Improve receiver type profiling reliability In-Reply-To: References: Message-ID: <-Xw2rhy-emzlu-2-QCX7fgzgr-kWVGDpIsqQpjhzs7Y=.089655e6-964e-4f06-8c56-5cb1e30d371c@github.com> On Tue, 20 Jan 2026 09:50:40 GMT, Andrew Haley wrote: >> [JDK-8374513](https://bugs.openjdk.org/browse/JDK-8374513) is the AArch64 port of [JDK-8357258](https://bugs.openjdk.org/browse/JDK-8357258). See the bug report for more detailed information. >> >> This PR executes the plan outlined in the bug: >> - Common the receiver type profiling code in interpreter and C1 >> - Rewrite receiver type profiling code to only do atomic receiver slot installations >> - 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. >> >> Functional Testing: Linux AArch64 fastdebug Tier1-4 >> >> Performance Testing (to show there is no performance regression): >> >> # Baseline >> Benchmark (randomized) Mode Cnt Score Error Units >> InterfaceCalls.test1stInt2Types false avgt 12 1.940 ? 0.002 ns/op >> InterfaceCalls.test1stInt2Types true avgt 12 7.714 ? 0.011 ns/op >> InterfaceCalls.test1stInt3Types false avgt 12 6.747 ? 0.066 ns/op >> InterfaceCalls.test1stInt3Types true avgt 12 18.733 ? 0.175 ns/op >> InterfaceCalls.test1stInt5Types false avgt 12 6.690 ? 0.083 ns/op >> InterfaceCalls.test1stInt5Types true avgt 12 21.299 ? 0.016 ns/op >> InterfaceCalls.test2ndInt2Types false avgt 12 1.997 ? 0.004 ns/op >> InterfaceCalls.test2ndInt2Types true avgt 12 8.027 ? 0.016 ns/op >> InterfaceCalls.test2ndInt3Types false avgt 12 7.915 ? 0.114 ns/op >> InterfaceCalls.test2ndInt3Types true avgt 12 16.988 ? 0.065 ns/op >> InterfaceCalls.test2ndInt5Types false avgt 12 9.422 ? 0.017 ns/op >> InterfaceCalls.test2ndInt5Types true avgt 12 22.736 ? 0.022 ns/op >> InterfaceCalls.testIfaceCall false avgt 12 5.860 ? 0.046 ns/op >> InterfaceCalls.testIfaceCall true avgt 12 5.794 ? 0.026 ns/op >> InterfaceCalls.testIfaceExtCall false avgt 12 6.310 ? 0.067 ns/op >> InterfaceCalls.testIfaceExtCall true avgt 12 6.239 ? 0.017 ns/op >> InterfaceCalls.testMonomorphic false avgt 12 1.146 ? 0.034 ns/op >> InterfaceCalls.testMonomorphic true avgt 12 1.131 ? 0.012 ns/op >> >> # With PR >> Benchmark (randomized) Mode Cnt Score Error Units >> InterfaceCalls.test1stInt2Type... > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 2253: > >> 2251: lea(rscratch2, Address(mdp, offset)); >> 2252: cmpxchg(/*addr*/ rscratch2, /*expected*/ zr, /*new*/ recv, Assembler::xword, >> 2253: /*acquire*/ false, /*release*/ false, /*weak*/ false, noreg); > > Suggestion: > > /*acquire*/ false, /*release*/ false, /*weak*/ true, noreg); > > If we fail a weak CAS here we should retry the whole loop: it probably means someone else has claimed the slot. True. Given that we restart the scan from the beginning anyway, there is no point in potentially looping in the strongified CAS implementation behind this macro. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29283#discussion_r2707666285 From tschatzl at openjdk.org Tue Jan 20 10:48:16 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 20 Jan 2026 10:48:16 GMT Subject: RFR: 8375438: G1: Convert G1HeapRegion related classes to use Atomic In-Reply-To: <6Zh622lkxXP3Sck23m9ZJo106Ng-smlA2isx32x5gRg=.26b26cf6-71bf-4fb5-ad49-d2d6d08c2422@github.com> References: <6Zh622lkxXP3Sck23m9ZJo106Ng-smlA2isx32x5gRg=.26b26cf6-71bf-4fb5-ad49-d2d6d08c2422@github.com> Message-ID: On Tue, 20 Jan 2026 10:04:46 GMT, Aleksey Shipilev wrote: >> Hi all, >> >> please review conversion of G1HeapRegion related classes to use Atomic. >> >> Testing: tier1, tier4, tier5 >> >> (The PipelineLeaksFD failure in gha is a known issue) >> >> Thanks, >> Thomas > > src/hotspot/share/gc/g1/g1HeapRegion.inline.hpp line 196: > >> 194: if (want_to_allocate >= min_word_size) { >> 195: HeapWord* new_top = obj + want_to_allocate; >> 196: HeapWord* result = _top.compare_exchange(obj, new_top); > > Since you are not using `result` beyond checking for CAS completion, you can probably do `if (_top.compare_set(obj_top)) { ... ` directly. This would also obviate the need for the comment on what CAE return value is supposed to signify. I rewrote the loop to avoid the reload of `top()`, using the result of the `compare_exchange`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29301#discussion_r2707795071 From shade at openjdk.org Tue Jan 20 11:29:10 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 20 Jan 2026 11:29:10 GMT Subject: RFR: 8360557: CTW: Inline cold methods to reach more code [v11] In-Reply-To: References: Message-ID: > We use CTW testing for making sure compilers behave well. But we compile the code that is not executed at all, and since our inlining heuristics often looks back at profiles, we end up not actually inlining all too much! This means CTW testing likely misses lots of bugs that normal code is exposed to, especially e.g. in loop optimizations. > > There is an intrinsic tradeoff with accepting more inilned methods in CTW: the compilation time gets significantly worse. With just accepting the cold methods we have reasonable CTW times, eating the improvements we have committed in mainline recently. And it still finds bugs. See the RFE for sample data. > > After this lands and CTW starts to compile cold methods, one can greatly expand the scope of the CTW testing by overriding the static inlining limits. Doing e.g. `TEST_VM_OPTS="-XX:MaxInlineSize=70 -XX:C1MaxInlineSize=70"` finds even more bugs. Unfortunately, the compilation times suffer so much, they are impractical to run in standard configurations, see data in RFE. We will enable some of that testing in special testing pipelines. > > Pre-empting the question: "Well, why not use -Xcomp then, and make sure it inlines well?" The answer is in RFE as well: Xcomp causes _a lot_ of stray compilations for JDK and CTW infra itself. For small JARs in large corpus this eats precious testing time that we would instead like to spend on deeper inlining in the actual JAR code. This also does not force us to look into how CTW works in Xcomp at all; I expect some surprises there. Feather-touching the inlining heuristic paths to just accept methods without looking at profiles looks better. > > Tobias had an idea to implement the stress randomized inlining that would expand the scope of inlining. This improvement stacks well with it. This improvement provides the base case of inlining most reasonable methods, and then allow stress infra to inline some more on top of that. > > Additional testing: > - [x] GHA > - [x] Linux x86_64 server fastdebug, `applications/ctw/modules` > - [x] Linux x86_64 server fastdebug, large CTW corpus (now failing in interesting ways) 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 seven additional commits since the last revision: - Merge branch 'master' into JDK-8360557-ctw-inlining - JDK-8375046 fix - JDK-8375694 POC fix - Merge branch 'master' into JDK-8360557-ctw-inlining - Debug - Merge branch 'master' into JDK-8360557-ctw-inlining - Fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26068/files - new: https://git.openjdk.org/jdk/pull/26068/files/fd0f506e..6513fc52 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26068&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26068&range=09-10 Stats: 9823 lines in 371 files changed: 5558 ins; 1784 del; 2481 mod Patch: https://git.openjdk.org/jdk/pull/26068.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26068/head:pull/26068 PR: https://git.openjdk.org/jdk/pull/26068 From tschatzl at openjdk.org Tue Jan 20 11:32:13 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 20 Jan 2026 11:32:13 GMT Subject: RFR: 8375438: G1: Convert G1HeapRegion related classes to use Atomic [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review conversion of G1HeapRegion related classes to use Atomic. > > Testing: tier1, tier4, tier5 > > (The PipelineLeaksFD failure in gha is a known issue) > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * shade review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29301/files - new: https://git.openjdk.org/jdk/pull/29301/files/636c7a7b..2a18c2eb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29301&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29301&range=00-01 Stats: 8 lines in 2 files changed: 3 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29301.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29301/head:pull/29301 PR: https://git.openjdk.org/jdk/pull/29301 From adinn at openjdk.org Tue Jan 20 11:49:27 2026 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 20 Jan 2026 11:49:27 GMT Subject: RFR: 8372617: Save and restore stubgen stubs when using an AOT code cache [v3] In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 16:46:41 GMT, Ashutosh Mehra wrote: >> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: >> >> asmehra feedback > > src/hotspot/share/code/aotCodeCache.cpp line 1742: > >> 1740: // id as an index >> 1741: >> 1742: #define SET_ENTRY_ADDRESS(type, addr, entry_id) \ > > This macro seems to be unused. Removed > src/hotspot/share/code/aotCodeCache.cpp line 1975: > >> 1973: SET_ADDRESS(_extrs, addresses.at(i)); >> 1974: } >> 1975: log_debug(aot, codecache, init)("External addresses recorded"); > > This log message is not very helpful. Following the code I now know it refers to the step where arch specific external address are added. So it does seem relevant, however the current message does not convey the context. But I don't know how to improve it either :). Changed to say "recorded N additional external addresses" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28433#discussion_r2708007200 PR Review Comment: https://git.openjdk.org/jdk/pull/28433#discussion_r2707994166 From jbhateja at openjdk.org Tue Jan 20 11:56:16 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 20 Jan 2026 11:56:16 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v13] In-Reply-To: References: Message-ID: > 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. > > image > > 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 incrementally with one additional commit since the last revision: Review comments resolutions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28002/files - new: https://git.openjdk.org/jdk/pull/28002/files/273b219e..fe7075ee Webrevs: - full: Webrev is not available because diff is too large - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=11-12 Stats: 85 lines in 4 files changed: 0 ins; 3 del; 82 mod Patch: https://git.openjdk.org/jdk/pull/28002.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002 PR: https://git.openjdk.org/jdk/pull/28002 From jbhateja at openjdk.org Tue Jan 20 11:56:19 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 20 Jan 2026 11:56:19 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v12] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 15:49:49 GMT, Emanuel Peter 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 28 commits: >> >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 >> - Adding testpoint for JDK-8373574 >> - Review comments resolutions >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 >> - Fix incorrect argument passed to smokeTest >> - 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 >> - ... and 18 more: https://git.openjdk.org/jdk/compare/499b5882...273b219e > > src/hotspot/share/utilities/globalDefinitions.hpp line 741: > >> 739: inline bool is_custom_basic_type(BasicType t) { >> 740: return (t == T_FLOAT16); >> 741: } > > What exactly is the definition of a "custom" basic type? Is it defined somewhere? > If not, it would be useful to define it here. > > I assume you chose the name because we expect more such "custom" basic types in the future? You are right, primarily basic types are driven by JVM language specification...in this case T_FLOAT16 is a non standard basic type. > test/jdk/jdk/incubator/vector/IntVectorMaxTests.java line 68: > >> 66: static IntVector bcast_vec = IntVector.broadcast(SPECIES, (int)10); >> 67: >> 68: static void AssertEquals(int actual, int expected) { > > There are lots of changes in this file that do not seem to have anything to do with Float16. Please file them separately. It will make review much easier. I have added an assertion wrapper so that float16 values (short) can be converted to float before calling actual Assert.* routines to handle all possible NaN bit patterns. Since the tests are generate from common template hence these changes appear. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2708024220 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2708023788 From adinn at openjdk.org Tue Jan 20 11:58:14 2026 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 20 Jan 2026 11:58:14 GMT Subject: RFR: 8372617: Save and restore stubgen stubs when using an AOT code cache [v3] In-Reply-To: References: Message-ID: <3iYG_aV_yuDkU4LqXVWWVoYjZ0J87U9YIC0hLhgTLBM=.7a428ff9-6837-4321-9792-e597c41df334@github.com> On Tue, 2 Dec 2025 17:00:49 GMT, Ashutosh Mehra wrote: >> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: >> >> asmehra feedback > > src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 2184: > >> 2182: // the normal stub provides a 2nd entry which omits the frame push >> 2183: // for use when bailing out from a disjoint copy >> 2184: // We need to protect memory accesses in certain cases > > This comment doesn't seem to be applicable here. I don't see an `UnsafeMemoryAccessMark`. Removed > src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 2452: > >> 2450: __ b(RuntimeAddress(long_copy_entry)); >> 2451: >> 2452: // record the stub entry and end plus any no_push entry > > Comment refers to "no_push entry", but there is none here. I guess a result of copy-paste. Removed > src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 2739: > >> 2737: __ ret(lr); >> 2738: >> 2739: // record the stub entry and end plus any no_push entry > > Same as before, comments refers to "no_push entry". Removed > src/hotspot/cpu/x86/macroAssembler_x86_sha.cpp line 799: > >> 797: >> 798: vmovdqu(BYTE_FLIP_MASK, ExternalAddress(pshuffle_byte_flip_mask_addr + 0)); // [PSHUFFLE_BYTE_FLIP_MASK wrt rip] >> 799: vmovdqu(SHUF_00BA, ExternalAddress(pshuffle_byte_flip_mask_addr + 32)); // [_SHUF_00BA wrt rip] > > Now that we have `StubRoutines::x86::pshuffle_byte_flip_mask_00ba_addr()`, I think it should replace `pshuffle_byte_flip_mask_addr + 32`. Makes the usage of these addresses explicit. In all cases I got rid of the local var (pshuffle_byte_flip_mask) and passed the relevant arch-specific stub entry addresses direct to the asserts and to the assembler methods. > src/hotspot/cpu/x86/macroAssembler_x86_sha.cpp line 1358: > >> 1356: assert(pshuffle_byte_flip_mask_addr + 32 == StubRoutines::x86::pshuffle_byte_flip_mask_ymm_lo_addr_sha512(), "sanity"); >> 1357: >> 1358: vmovdqu(BYTE_FLIP_MASK, ExternalAddress(pshuffle_byte_flip_mask_addr + 0)); // PSHUFFLE_BYTE_FLIP_MASK wrt rip > > Indentation is off Fixed > src/hotspot/cpu/zero/stubRoutines_zero.cpp line 35: > >> 33: >> 34: #if INCLUDE_CDS >> 35: // nothing to do for xero > > xero->zero Fixed > src/hotspot/share/code/aotCodeCache.cpp line 1998: > >> 1996: void AOTCodeAddressTable::set_c1_stubs_complete() { >> 1997: assert(!_c1_stubs_complete, "repeated close for c1 stubs!"); >> 1998: _c2_stubs_complete = true; > > should be setting `_c1_stubs_complete` Fixed > src/hotspot/share/code/aotCodeCache.hpp line 245: > >> 243: ~AOTStubData() CDS_ONLY({FREE_C_HEAP_ARRAY(StubAddrRange, _ranges);}) NOT_CDS({}) >> 244: >> 245: bool is_open() CDS_ONLY({ return (_flags & OPEN) != 0; }) NOT_CDS_RETURN_(false); > > extra indentation Fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28433#discussion_r2708021231 PR Review Comment: https://git.openjdk.org/jdk/pull/28433#discussion_r2708022354 PR Review Comment: https://git.openjdk.org/jdk/pull/28433#discussion_r2708023702 PR Review Comment: https://git.openjdk.org/jdk/pull/28433#discussion_r2708032933 PR Review Comment: https://git.openjdk.org/jdk/pull/28433#discussion_r2708027599 PR Review Comment: https://git.openjdk.org/jdk/pull/28433#discussion_r2708028805 PR Review Comment: https://git.openjdk.org/jdk/pull/28433#discussion_r2708026402 PR Review Comment: https://git.openjdk.org/jdk/pull/28433#discussion_r2708025864 From kevinw at openjdk.org Tue Jan 20 12:05:13 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 20 Jan 2026 12:05:13 GMT Subject: RFR: 8359706: Add file descriptor count and maximum limit to VM.info [v6] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 17:31:10 GMT, Kevin Walls wrote: >> 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 > > Hi - Could you include an example of what this looks like in context, an excerpt from the whole output showing the new info in context? > > It's between "printing heap information" and "printing GC information", which might be a bit odd as those things should stay grouped together for humans to read? > > Would it be a better fit in the "OS:" section which is where we show e.g. limit information. > Hi @kevinjwalls, here is a snippit from the current position under "PROCESS". I added it here since the count is process related but I agree it might be nice to have it closer to the NOFILE count int the "OS" section under "SYSTEM". Thanks - yes, if we can group it more logically then I think more humans should discover it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27971#issuecomment-3772524229 From bmaillard at openjdk.org Tue Jan 20 12:32:18 2026 From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard) Date: Tue, 20 Jan 2026 12:32:18 GMT Subject: RFR: 8370519: C2: Hit MemLimit when running with +VerifyLoopOptimizations [v6] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 13:55:53 GMT, Roland Westrelin wrote: >> I think we should use the following test, which is quite concise and only takes a few seconds to execute thanks to setting `memlimit` to `100M`. >> >> ```c++ >> /** >> * @test >> * @key stress randomness >> * @bug 8370519 >> * @summary C2: Hit MemLimit when running with +VerifyLoopOptimizations >> * @run main/othervm -XX:CompileCommand=compileonly,${test.main.class}::* -XX:-TieredCompilation -Xbatch >> * -XX:+UnlockDiagnosticVMOptions -XX:+IgnoreUnrecognizedVMOptions >> * -XX:+StressLoopPeeling -XX:+VerifyLoopOptimizations >> * -XX:CompileCommand=memlimit,${test.main.class}::*,100M~crash >> * -XX:StressSeed=3106998670 ${test.main.class} >> * @run main ${test.main.class} >> */ >> >> package compiler.c2; >> >> public class TestVerifyLoopOptimizationsHighMemUsage { >> >> static int b = 400; >> static long c; >> static boolean d; >> >> static long lMeth(int e) { >> int f, g, h, k[] = new int[b]; >> long l[] = new long[b]; >> boolean m[] = new boolean[b]; >> for (f = 5; f < 330; ++f) >> for (g = 1; g < 5; ++g) >> for (h = 2; h > 1; h -= 3) >> switch (f * 5 + 54) { >> case 156: >> case 354: >> case 98: >> case 173: >> case 120: >> case 374: >> case 140: >> case 57: >> case 106: >> case 306: >> case 87: >> case 399: >> k[1] = (int)c; >> case 51: >> case 287: >> case 148: >> case 70: >> case 74: >> case 59: >> m[h] = d; >> } >> long n = p(l); >> return n; >> } >> >> public static long p(long[] a) { >> long o = 0; >> for (int j = 0; j < a.length; j++) >> o += j; >> return o; >> } >> >> public static void main(String[] args) { >> for (int i = 0; i < 10; i++) >> lMeth(9); >> } >> } > > @benoitmaillard how feasible/time consuming would it be to find a more robust test case? Do you agree with my concern above? Apologies for the delay @rwestrel, this somehow got under the radar after Christmas. I agree 100% with your concerns. I think it's worth it to give it a try, I will launch another run of creduce and come back to you with the results (this should go a bit faster this time). ------------- PR Comment: https://git.openjdk.org/jdk/pull/28581#issuecomment-3772652281 From chagedorn at openjdk.org Tue Jan 20 12:40:26 2026 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Tue, 20 Jan 2026 12:40:26 GMT Subject: RFR: 8373343: C2: verify AddP base input only set for heap addresses [v6] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 15:32:07 GMT, Roland Westrelin 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 15 additional commits since the last revision: > > - Merge branch 'master' into JDK-8373343 > - Update src/hotspot/share/opto/macroArrayCopy.cpp > > Co-authored-by: Dean Long <17332032+dean-long at users.noreply.github.com> > - more > - more > - review > - Merge branch 'master' into JDK-8373343 > - review > - review > - review > - merge > - ... and 5 more: https://git.openjdk.org/jdk/compare/40060a1b...2f618436 Marked as reviewed by chagedorn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28769#pullrequestreview-3681978641 From roland at openjdk.org Tue Jan 20 12:46:29 2026 From: roland at openjdk.org (Roland Westrelin) Date: Tue, 20 Jan 2026 12:46:29 GMT Subject: RFR: 8373343: C2: verify AddP base input only set for heap addresses [v3] In-Reply-To: <-GY9oBe-WRSh16Yi90rp79Xxi784nRtvdqBlMh4TiMs=.ba972df0-9298-4f94-8699-597601bd39ba@github.com> References: <-GY9oBe-WRSh16Yi90rp79Xxi784nRtvdqBlMh4TiMs=.ba972df0-9298-4f94-8699-597601bd39ba@github.com> Message-ID: <-QGYQkvP71rFI0oQB-6GS7kyfmOTBp882G16GXXRuWs=.b608c29b-ee05-4a1f-9143-99df5a31238f@github.com> On Sat, 20 Dec 2025 03:31:13 GMT, Dean Long wrote: >> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision: >> >> review > > Tests passed. @dean-long @chhagedorn @merykitty thanks for the reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/28769#issuecomment-3772706108 From phubner at openjdk.org Tue Jan 20 12:56:44 2026 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Tue, 20 Jan 2026 12:56:44 GMT Subject: RFR: 8371777: Clean up preferred address of G1's archive region Message-ID: <7eIqYfnErWOUoWNEYH1R0GJjKNBQLIzi4biECVggAR0=.341543f8-53a1-4a08-b852-c5f12d13b82c@github.com> Hi all, There exists infrastructure in G1 to map the archived region at a certain address, `preferred_addr`. This was however never implemented and abandoned in favour of JEP 516. This is a small cleanup that removes the unused parameter. Note: the `requested_start` address is still necessary to compute pointer deltas and to perform patching if necessary. If folks feel like `requested` is a misleading name I'm happy to address that as part of a separate RFE. Testing: tiers 1-5 Linux (x64, AArch64), macOS (x64, AArch64), Windows x64. ------------- Commit messages: - Remove preferred_addr parameter. Changes: https://git.openjdk.org/jdk/pull/29317/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29317&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371777 Stats: 6 lines in 3 files changed: 0 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29317/head:pull/29317 PR: https://git.openjdk.org/jdk/pull/29317 From shade at openjdk.org Tue Jan 20 13:10:35 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 20 Jan 2026 13:10:35 GMT Subject: RFR: 8375438: G1: Convert G1HeapRegion related classes to use Atomic [v2] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 11:32:13 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review conversion of G1HeapRegion related classes to use Atomic. >> >> Testing: tier1, tier4, tier5 >> >> (The PipelineLeaksFD failure in gha is a known issue) >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * shade review Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29301#pullrequestreview-3682104816 From amitkumar at openjdk.org Tue Jan 20 13:37:34 2026 From: amitkumar at openjdk.org (Amit Kumar) Date: Tue, 20 Jan 2026 13:37:34 GMT Subject: RFR: 8352567: [s390x] ProblemList JFR tests requiring JFR stubs [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 03:58:25 GMT, Vladimir Petko wrote: >> JFR stubs are not [implemented](https://github.com/openjdk/jdk/blame/06ba6cf3a137a6cdf572a876a46d18e51c248451/src/hotspot/cpu/s390/sharedRuntime_s390.cpp#L3412). >> Problemlist affected tests until https://bugs.openjdk.org/browse/JDK-8286300 is implemented. >> >> Testing: >> - s390x: >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR SKIP >> jtreg:test/hotspot/jtreg/applications/ctw/modules/jdk_jfr.java >> 0 0 0 0 0 >> jtreg:test/hotspot/jtreg/compiler/intrinsics/TestReturnOopSetForJFRWriteCheckpoint.java >> 0 0 0 0 0 >> jtreg:test/jdk/jdk/jfr 640 583 0 0 57 >> ============================== >> TEST SUCCESS >> >> >> >> - amd64: >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR SKIP >> jtreg:test/hotspot/jtreg/applications/ctw/modules/jdk_jfr.java >> 1 1 0 0 0 >> jtreg:test/hotspot/jtreg/compiler/intrinsics/TestReturnOopSetForJFRWriteCheckpoint.java >> 1 1 0 0 0 >> jtreg:test/jdk/jdk/jfr 639 630 0 0 9 >> ============================== >> TEST SUCCESS > > Vladimir Petko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8352567: [s390x] disable JFR tests requiring JFR stubs Looks Good to me and test will be enabled again with the Loom port. ------------- Marked as reviewed by amitkumar (Committer). PR Review: https://git.openjdk.org/jdk/pull/28444#pullrequestreview-3682222375 From stefank at openjdk.org Tue Jan 20 13:55:20 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 20 Jan 2026 13:55:20 GMT Subject: RFR: 8371777: Clean up preferred address of G1's archive region In-Reply-To: <7eIqYfnErWOUoWNEYH1R0GJjKNBQLIzi4biECVggAR0=.341543f8-53a1-4a08-b852-c5f12d13b82c@github.com> References: <7eIqYfnErWOUoWNEYH1R0GJjKNBQLIzi4biECVggAR0=.341543f8-53a1-4a08-b852-c5f12d13b82c@github.com> Message-ID: <9MclQmLsvfTigDAK8ewPp-79Y8V9DV-9ttdSkztUCp8=.e26284b4-c576-4138-9113-2c5350990d99@github.com> On Tue, 20 Jan 2026 12:49:05 GMT, Paul H?bner wrote: > Hi all, > > There exists infrastructure in G1 to map the archived region at a certain address, `preferred_addr`. This was however never implemented and abandoned in favour of JEP 516. This is a small cleanup that removes the unused parameter. > > Note: the `requested_start` address is still necessary to compute pointer deltas and to perform patching if necessary. If folks feel like `requested` is a misleading name I'm happy to address that as part of a separate RFE. > > Testing: tiers 1-5 Linux (x64, AArch64), macOS (x64, AArch64), Windows x64. Looks good to me. Fixing the nomenclature in a follow-up RFE sounds good to me too. ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29317#pullrequestreview-3682305984 From kevinw at openjdk.org Tue Jan 20 14:55:39 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 20 Jan 2026 14:55:39 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> References: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> Message-ID: On Tue, 20 Jan 2026 08:57:52 GMT, Ivan Bereziuk wrote: >> `jcmd` provides great diagnostics but many commands lack a timestamp in their output. >> Adding a timestamp to the output of some would add value for those debugging JVM data. >> >> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. >> >> With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-T": >> >> jcmd [pid | main-class] [-T] command... | PerfCounter.print | -f filename >> ^^^^ >> >> * The choice for time format is "yyyy-MM-dd HH:mm:ss" as it is already used in `Thread.print`. >> * `Thread.print` prints timestamp irrespectively from "-T" flag presence to preserve backwards compatibility. >> >> I haven't added a timestamp to the following diagnostic command: >> * `VM.uptime` - command run with `-date` argument will also print a timestamp; >> * `VM.system_properties` - as the output already lists a timestamp. Not sure if we need more timestamps here. >> * `Thread.dump_to_file` - the content dumped to a file already has a timestamp; > > Ivan Bereziuk 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 15 additional commits since the last revision: > > - remove TimeStamp::No as it's not used. virtual should be flipped to override in bulk (afressed clang warning) > - Merge branch 'master' into 8357828_add_timestamp_to_jcmd > - changes to jcmd.md > - undo changes to reorder_help_cmd() > - cleanup > - add timestamp to VM.version. Add test > - updated jcmd usage text > - undo the changes to the modified earlier tests as timestamp presence is fully backwards compatible > - introduce -T as a commong flag > - Merge branch 'master' into 8357828_add_timestamp_to_jcmd > - ... and 5 more: https://git.openjdk.org/jdk/compare/df6de4c1...5f1cefe0 Lots of duplication in the execute methods, of the same common condition around calling print_local_time... That's a reason in favour of the jcmd driver printing the timestamp itself so it can be done in one place, if required. (The local attach API is not slow enough to cause a problematic latency in when the timestamp was printed, and when the command was actually run. Certainly not compared to the current workaround of running: "date; jcmd ...") To deal with commands that already show a timestamp, if JCmd.java is where the timestamp is printed: if jcmd can send a parameter over the new attach api to the diagnostic command, then it can send a boolean "i have already printed a timestamp". Then only an existing command which already prints a timestamp would need to check. Or separately in David's note earlier: "And rather than add timestamp printing code to each dcmd it would make more sense to me to have a global dcmd flag that says "print a timestamp" (with a given format). That way users opt-in and we don't have to remember to add this for new Dcmds." This relates to if the printing is done in the native code, and as I read it this was about having a flag checked before the individual execute methods, so it can be done in one place (not sure but maybe this would be DCmd::Executor::parse_and_execute()). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3773270519 From phubner at openjdk.org Tue Jan 20 15:48:19 2026 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Tue, 20 Jan 2026 15:48:19 GMT Subject: RFR: 8375534: Debug method 'pp' should support compressed oops [v2] In-Reply-To: <8WMvLeZIKT01h3gYFaeUJhQqNmZirdoiwvqbdejYQok=.bbe3b14b-0923-4528-bb0a-2355bbe53e8f@github.com> References: <8WMvLeZIKT01h3gYFaeUJhQqNmZirdoiwvqbdejYQok=.bbe3b14b-0923-4528-bb0a-2355bbe53e8f@github.com> Message-ID: On Mon, 19 Jan 2026 08:11:00 GMT, Tobias Hartmann wrote: >> The debug method `pp` is currently not able to handle compressed oops. This should fix it. The code is similar to `BlockLocationPrinter::print_location`. >> >> **Before:** >> >> >> (rr) call (void*) pp(0x6b9c08fc8) >> >> "Executing pp" >> java.lang.Runtime$Version >> {0x00000006b9c08fc8} - klass: 'java/lang/Runtime$Version' - flags: >> >> - ---- fields (total size 4 words): >> - private final value 'version' 'Ljava/util/List;' @12 a 'java/util/ImmutableCollections$List12'{0x00000006b9c2cbb8} (0xd7385977) >> - private final value 'pre' 'Ljava/util/Optional;' @16 a 'java/util/Optional'{0x00000006b9c2cbd0} (0xd738597a) >> - private final value 'build' 'Ljava/util/Optional;' @20 a 'java/util/Optional'{0x00000006b9c0a118} (0xd7381423) >> - private final value 'optional' 'Ljava/util/Optional;' @24 a 'java/util/Optional'{0x00000006b9c2cbe8} (0xd738597d) >> $1 = (void *) 0x0 >> (rr) call (void*) pp(0xd7381423) >> >> "Executing pp" >> The program being debugged received signal SIGSEGV, Segmentation fault >> while in a function called from GDB. GDB has restored the context >> to what it was before the call. To change this behavior use >> "set unwind-on-signal off". Evaluation of the expression containing >> the function (pp(long)) will be abandoned. >> >> >> **After:** >> ```(rr) call (void*) pp(0x6b9c08fc8) >> >> "Executing pp" >> java.lang.Runtime$Version >> {0x00000006b9c08fc8} - klass: 'java/lang/Runtime$Version' - flags: >> >> - ---- fields (total size 4 words): >> - private final value 'version' 'Ljava/util/List;' @12 a 'java/util/ImmutableCollections$List12'{0x00000006b9c2cbb8} (0xd7385977) >> - private final value 'pre' 'Ljava/util/Optional;' @16 a 'java/util/Optional'{0x00000006b9c2cbd0} (0xd738597a) >> - private final value 'build' 'Ljava/util/Optional;' @20 a 'java/util/Optional'{0x00000006b9c0a118} (0xd7381423) >> - private final value 'optional' 'Ljava/util/Optional;' @24 a 'java/util/Optional'{0x00000006b9c2cbe8} (0xd738597d) >> $1 = (void *) 0x0 >> (rr) call (void*) pp(0xd7381423) >> >> "Executing pp" >> 3610776611 is a compressed pointer to object: java.util.Optional >> {0x00000006b9c0a118} - klass: 'java/util/Optional' - flags: >> >> - ---- fields (total size 3 words): >> - private final value 'value' 'Ljava/lang/Object;' @16 null (0x00000000) >> $2 = (void *) 0x0 >> >> >> Thanks, >> Tobias > > Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision: > > Let's just use print_location instead This is a super useful change, thanks for doing it. One small comment. src/hotspot/share/utilities/debug.cpp line 426: > 424: } > 425: > 426: if (!Universe::heap()->print_location(tty, p)) { FYI, we also have `os::print_location` which adds a few extra goodies (nullcheck + code blob check). Its documentation mentions > // moved from debug.cpp (used to be find()) but still called from there I'm happy with the current code and I'd also be okay with using the `os` version, I just wanted to point it out in case you think one is more appropriate than the other. ------------- PR Review: https://git.openjdk.org/jdk/pull/29280#pullrequestreview-3682888141 PR Review Comment: https://git.openjdk.org/jdk/pull/29280#discussion_r2708939042 From duke at openjdk.org Tue Jan 20 15:58:46 2026 From: duke at openjdk.org (Ivan Bereziuk) Date: Tue, 20 Jan 2026 15:58:46 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: References: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> Message-ID: On Tue, 20 Jan 2026 14:51:27 GMT, Kevin Walls wrote: >> Ivan Bereziuk 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 15 additional commits since the last revision: >> >> - remove TimeStamp::No as it's not used. virtual should be flipped to override in bulk (afressed clang warning) >> - Merge branch 'master' into 8357828_add_timestamp_to_jcmd >> - changes to jcmd.md >> - undo changes to reorder_help_cmd() >> - cleanup >> - add timestamp to VM.version. Add test >> - updated jcmd usage text >> - undo the changes to the modified earlier tests as timestamp presence is fully backwards compatible >> - introduce -T as a commong flag >> - Merge branch 'master' into 8357828_add_timestamp_to_jcmd >> - ... and 5 more: https://git.openjdk.org/jdk/compare/438fc675...5f1cefe0 > > Lots of duplication in the execute methods, of the same common condition around calling print_local_time... > That's a reason in favour of the jcmd driver printing the timestamp itself so it can be done in one place, if required. > (The local attach API is not slow enough to cause a problematic latency in when the timestamp was printed, and when the command was actually run. Certainly not compared to the current workaround of running: "date; jcmd ...") > > > To deal with commands that already show a timestamp, if JCmd.java is where the timestamp is printed: if jcmd can send a parameter over the new attach api to the diagnostic command, then it can send a boolean "i have already printed a timestamp". Then only an existing command which already prints a timestamp would need to check. > > > Or separately in David's note earlier: > "And rather than add timestamp printing code to each dcmd it would make more sense to me to have a global dcmd flag that says "print a timestamp" (with a given format). That way users opt-in and we don't have to remember to add this for new Dcmds." > This relates to if the printing is done in the native code, and as I read it this was about having a flag checked before the individual execute methods, so it can be done in one place (not sure but maybe this would be DCmd::Executor::parse_and_execute()). @kevinjwalls I have created a v2 MR that handles timestamp in `DCmd::Executor::parse_and_execute` and doesn't change the executors. https://github.com/openjdk/jdk/pull/29325 The drawback is that timestamp can be printed twice in case of `Thread.print` diagnostic command. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3773628920 From aph at openjdk.org Tue Jan 20 16:25:51 2026 From: aph at openjdk.org (Andrew Haley) Date: Tue, 20 Jan 2026 16:25:51 GMT Subject: RFR: 8372701: Randomized profile counters [v8] In-Reply-To: References: Message-ID: > Please use [this link](https://github.com/openjdk/jdk/pull/28541/changes?w=1) to view the files changed. > > Profile counters scale very badly. > > The overhead for profiled code isn't too bad with one thread, but as the thread count increases, things go wrong very quickly. > > For example, here's a benchmark from the OpenJDK test suite, run at TieredLevel 3 with one thread, then three threads: > > > Benchmark (randomized) Mode Cnt Score Error Units > InterfaceCalls.test2ndInt5Types false avgt 4 27.468 ? 2.631 ns/op > InterfaceCalls.test2ndInt5Types false avgt 4 240.010 ? 6.329 ns/op > > > This slowdown is caused by high memory contention on the profile counters. Not only is this slow, but it can also lose profile counts. > > This patch is for C1 only. It'd be easy to randomize C1 counters as well in another PR, if anyone thinks it's worth doing. > > One other thing to note is that randomized profile counters degrade very badly with small decimation ratios. For example, using a ratio of 2 with `-XX:ProfileCaptureRatio=2` with a single thread results in > > > Benchmark (randomized) Mode Cnt Score Error Units > InterfaceCalls.test2ndInt5Types false avgt 4 80.147 ? 9.991 ns/op > > > The problem is that the branch prediction rate drops away very badly, leading to many mispredictions. It only really makes sense to use higher decimation ratios, e.g. 64. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Save and restore Profile RNG. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28541/files - new: https://git.openjdk.org/jdk/pull/28541/files/a1ed4b80..2a0cb808 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28541&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28541&range=06-07 Stats: 6 lines in 2 files changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28541.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28541/head:pull/28541 PR: https://git.openjdk.org/jdk/pull/28541 From kfarrell at openjdk.org Tue Jan 20 16:56:11 2026 From: kfarrell at openjdk.org (Kieran Farrell) Date: Tue, 20 Jan 2026 16:56:11 GMT Subject: RFR: 8359706: Add file descriptor count and maximum limit to VM.info [v7] In-Reply-To: References: Message-ID: > 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 incrementally with one additional commit since the last revision: relocate print out to SYSTEM section and remove AIX impl ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27971/files - new: https://git.openjdk.org/jdk/pull/27971/files/1f34d255..14ca2e29 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27971&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27971&range=05-06 Stats: 60 lines in 4 files changed: 5 ins; 46 del; 9 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 adinn at openjdk.org Tue Jan 20 17:16:15 2026 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 20 Jan 2026 17:16:15 GMT Subject: RFR: 8372617: Save and restore stubgen stubs when using an AOT code cache [v4] In-Reply-To: References: Message-ID: > This PR adds save and restore of all generated stubs to the AOT code cache on x86 and aarch64. Other arches are modified to deal with the related generic PAI changes. > > Small changes were required to the aarch64 and x86_64 generator code in order to meet two key constraints: > 1. the first declared entry of every stub starts at the first instruction in the stub code range > 2. all data/code cross-references from one stub to another target a declared stub entry Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision: - fix whitespace issue - remaining asmehra feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28433/files - new: https://git.openjdk.org/jdk/pull/28433/files/ed8d2455..83855bef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28433&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28433&range=02-03 Stats: 30 lines in 7 files changed: 10 ins; 10 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/28433.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28433/head:pull/28433 PR: https://git.openjdk.org/jdk/pull/28433 From adinn at openjdk.org Tue Jan 20 17:16:18 2026 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 20 Jan 2026 17:16:18 GMT Subject: RFR: 8372617: Save and restore stubgen stubs when using an AOT code cache [v4] In-Reply-To: References: Message-ID: <6IVHPwyEh1AquC0w4yS7pEaXlmbDu8bAExh9C6MT0y0=.a2bdd0d3-1c60-4b8e-834e-b7d09702ae6e@github.com> On Tue, 2 Dec 2025 16:43:26 GMT, Ashutosh Mehra wrote: >> Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision: >> >> - fix whitespace issue >> - remaining asmehra feedback > > src/hotspot/share/code/aotCodeCache.hpp line 403: > >> 401: int store_strings(); >> 402: >> 403: static void set_shared_stubs_complete() NOT_CDS_RETURN; > > I don't see `set_shared_stubs_complete`, `set_c1_stubs_complete` and `set_c2_stubs_complete` called from anywhere. Added calls at appropriate points. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28433#discussion_r2709281443 From kevinw at openjdk.org Tue Jan 20 17:18:17 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 20 Jan 2026 17:18:17 GMT Subject: RFR: 8359706: Add file descriptor count and maximum limit to VM.info [v7] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 16:56:11 GMT, Kieran Farrell wrote: >> 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 incrementally with one additional commit since the last revision: > > relocate print out to SYSTEM section and remove AIX impl src/hotspot/os/linux/os_linux.cpp line 2098: > 2096: > 2097: os::print_open_file_descriptors(st); > 2098: st->cr(); Remove? I think the implementation uses print_cr and you didn't want to add a blank line between this and load average? Also as not all OSs implement it, it will just put space between limits and load average. src/hotspot/os/linux/os_linux.cpp line 5419: > 5417: closedir(dirp); > 5418: if (timed_out) { > 5419: st->print_cr("Open File Descriptors > %d", fds - 1); // minus the opendir fd itself Open File Descriptors: > %d (with the colon like everywhere else?) src/hotspot/os/windows/os_windows.cpp line 6262: > 6260: > 6261: void os::print_open_file_descriptors(outputStream* st) { > 6262: // File descriptor counting not supported on Windows. If you said "not implemented" here and in the other comment, it might be clearer that somebody could implement these if they build and test it. Not supported sounds to me more like a reason we cannot do it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27971#discussion_r2709296759 PR Review Comment: https://git.openjdk.org/jdk/pull/27971#discussion_r2709300052 PR Review Comment: https://git.openjdk.org/jdk/pull/27971#discussion_r2709305132 From adinn at openjdk.org Tue Jan 20 17:23:54 2026 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 20 Jan 2026 17:23:54 GMT Subject: RFR: 8372617: Save and restore stubgen stubs when using an AOT code cache In-Reply-To: References: Message-ID: On Fri, 21 Nov 2025 00:34:14 GMT, Vladimir Kozlov wrote: >> This PR adds save and restore of all generated stubs to the AOT code cache on x86 and aarch64. Other arches are modified to deal with the related generic PAI changes. >> >> Small changes were required to the aarch64 and x86_64 generator code in order to meet two key constraints: >> 1. the first declared entry of every stub starts at the first instruction in the stub code range >> 2. all data/code cross-references from one stub to another target a declared stub entry > > I noticed that we have to add a lot of local data tables addresses for stubs (math intrinsics). > May be we should consider to have platform specific AOT address tables for such address (and platform specific stubs). To avoid search in one big table. @vnkozlov > I noticed that we have to add a lot of local data tables addresses for stubs (math intrinsics). > May be we should consider to have platform specific AOT address tables for such address (and platform specific stubs). To avoid search in one big table. I think we only need to search the the _extrs address list when we are saving stub or nmethod blobs and need to translate a target address to a table index. When loading code we simply use an index to lookup the corresponding address. So, performance is only an issue for the assembly phase. I don't think splitting the externals tables is going to be much help. If we flag stubs as arch-specific or generic then, sure, we can bypass the local externals table if we are saving a generic stub. But that does not avoid what is essentially an o(n^2) lookup, it merely reduces it by a constant factor (ratio of generic external references to all external references) that is not that much less than 1. I suggest instead that during stub save we populate a hash table of whenever we insert a new external address into the table. That way we can do the lookup in constant time. How does that sound? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28433#issuecomment-3774066187 From thartmann at openjdk.org Tue Jan 20 17:58:30 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 20 Jan 2026 17:58:30 GMT Subject: RFR: 8375534: Debug method 'pp' should support compressed oops [v2] In-Reply-To: References: <8WMvLeZIKT01h3gYFaeUJhQqNmZirdoiwvqbdejYQok=.bbe3b14b-0923-4528-bb0a-2355bbe53e8f@github.com> Message-ID: On Tue, 20 Jan 2026 15:45:03 GMT, Paul H?bner wrote: >> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision: >> >> Let's just use print_location instead > > src/hotspot/share/utilities/debug.cpp line 426: > >> 424: } >> 425: >> 426: if (!Universe::heap()->print_location(tty, p)) { > > FYI, we also have `os::print_location` which adds a few extra goodies (nullcheck + code blob check). Its documentation mentions >> // moved from debug.cpp (used to be find()) but still called from there > > I'm happy with the current code and I'd also be okay with using the `os` version, I just wanted to point it out in case you think one is more appropriate than the other. Thanks for taking a look at this. Yes, I've seen that and it's already used by `find` and `findpc`. I think the intention of `pp` is that we already know/expect that the argument is a pointer into the Java heap and therefore want to limit the amount of checks (maybe for performance or stability reasons?) during debugging. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29280#discussion_r2709467784 From kbarrett at openjdk.org Tue Jan 20 18:35:06 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 20 Jan 2026 18:35:06 GMT Subject: RFR: 8375737: Fix -Wzero-as-null-pointer-constant warnings in arm32 code Message-ID: Please review this trivial change to arm32 code to avoid using literal zero as a null pointer constant, instead using nullptr. Testing: GHA build for arm32 ------------- Commit messages: - fix arm32 -Wzero-as-null-pointer-constant warnings Changes: https://git.openjdk.org/jdk/pull/29328/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29328&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375737 Stats: 8 lines in 3 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/29328.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29328/head:pull/29328 PR: https://git.openjdk.org/jdk/pull/29328 From dfenacci at openjdk.org Tue Jan 20 18:54:04 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Tue, 20 Jan 2026 18:54:04 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics Message-ID: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> ## Issue This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. ## Causes The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. ## Fix A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. # Testing * Tier 1-3+ * 2 JTReg tests added * `TestRangeCheck.java` as regression test for the reported issue * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion ------------- Commit messages: - JDK-8374852: revert unchanged tests - JDK-8374852: shorten line lenght in test - JDK-8374852: revert comment change - JDK-8374852: correct comment and make more concise - Update test/hotspot/jtreg/compiler/intrinsics/string/TestRangeCheck.java - JDK-8374852: fix generate_limit_guard opaque handling and remove unneeded positive flag - JDK-8374852: remove compileonly - JDK-8374852: remove VerifyIntrinsicChecks and refactor opaque flag - JDK-8374852: add forgotten opaque guard node handling in clone_iff - JDK-8374852: 120 max char for comment - ... and 8 more: https://git.openjdk.org/jdk/compare/6d1bfdf7...ff228576 Changes: https://git.openjdk.org/jdk/pull/29164/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374582 Stats: 435 lines in 28 files changed: 328 ins; 20 del; 87 mod Patch: https://git.openjdk.org/jdk/pull/29164.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29164/head:pull/29164 PR: https://git.openjdk.org/jdk/pull/29164 From vyazici at openjdk.org Tue Jan 20 18:54:09 2026 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 20 Jan 2026 18:54:09 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com> On Mon, 12 Jan 2026 10:29:39 GMT, Damon Fenacci wrote: > ## Issue > > This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. > > This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. > > ## Causes > > The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. > > ## Fix > > A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: > https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 > This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. > > # Testing > > * Tier 1-3+ > * 2 JTReg tests added > * `TestRangeCheck.java` as regression test for the reported issue > * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion Marked as reviewed by vyazici (Committer). Verified that 3c466d372b7 is a clean revert of 7e18de137c3 delivered in [JDK-8374210]. [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210 src/hotspot/share/opto/c2_globals.hpp line 680: > 678: develop(bool, VerifyIntrinsicChecks, false, \ > 679: "Verify in intrinsic that Java level checks work as expected") \ > 680: \ I suggest removing the `VerifyIntrinsicChecks` flag. Given `OpaqueGuard` already verifies the value when `#ifdef ASSERT`, does `VerifyIntrinsicChecks` serve any purpose anymore? src/hotspot/share/opto/library_call.hpp line 170: > 168: Node* length, bool char_count, > 169: bool halt_on_oob = false, > 170: bool is_opaque = false); Do we really need to introduce two new toggles: `halt_on_oob` and `is_opaque`? At all call-sites either one of the following is used: 1. `halt_on_oob=true, is_opaque=!VerifyIntrinsicChecks` 2. defaults (i.e., `halt_on_oob=is_opaque=false`) Can we instead only settle one, e.g., `halt_on_oob=VerifyIntrinsicChecks`? src/hotspot/share/opto/loopopts.cpp line 1: > 1: /* What is the reason that the new `OpaqueGuard` is not taken into account in `PhaseIdealLoop::clone_iff`? src/hotspot/share/opto/macro.cpp line 2565: > 2563: // Tests with OpaqueGuard nodes are implicitly known to be true or false. Replace the node with appropriate value. In debug builds, > 2564: // we leave the test in the graph to have an additional sanity check at runtime. If the test fails (i.e. a bug), > 2565: // we will execute a Halt node. *Nit:* Can we adhere to the max. 120 (or even better, 80!) characters per line limit of the file? src/hotspot/share/opto/macro.cpp line 2569: > 2567: _igvn.replace_node(n, n->in(1)); > 2568: #else > 2569: _igvn.replace_node(n, _igvn.intcon(0)); Curious: why do we invoke `intcon(0)` for `OpaqueGuard`, whereas it was `intcon(1)` for `OpaqueNotNull` slightly above? src/hotspot/share/opto/opaquenode.hpp line 160: > 158: // we keep the actual checks as additional verification code (i.e. removing OpaqueGuardNode and use the BoolNode > 159: // inputs instead). > 160: class OpaqueGuardNode : public Node { With the `OpaqueGuardNode::is_positive` flag gone, `OpaqueGuardNode` looks pretty much identical to `OpaqueNotNullNode`. Is there a code reuse opportunity we can take advantage of? test/hotspot/jtreg/compiler/intrinsics/TestVerifyIntrinsicChecks.java line 1: > 1: /* Since the `VerifyIntrinsicChecks` flag is gone, AFAICT, all following changes can be reverted: git rm test/hotspot/jtreg/compiler/intrinsics/TestVerifyIntrinsicChecks.java git checkout upstream/HEAD -- \ test/hotspot/jtreg/compiler/intrinsics/string/TestCountPositives.java \ test/hotspot/jtreg/compiler/intrinsics/string/TestEncodeIntrinsics.java \ test/hotspot/jtreg/compiler/intrinsics/string/TestHasNegatives.java \ test/hotspot/jtreg/compiler/patches/java.base/java/lang/Helper.java test/hotspot/jtreg/compiler/intrinsics/string/TestRangeCheck.java line 32: > 30: * -XX:CompileCommand=inline,java.lang.StringCoding::* > 31: * -XX:CompileCommand=exclude,jdk.internal.util.Preconditions::checkFromIndexSize > 32: * -XX:CompileCommand=compileonly,compiler.intrinsics.string.TestRangeCheck::test Is this necessary? (This wasn't used in `TestStringConstruction`.) test/hotspot/jtreg/compiler/intrinsics/string/TestRangeCheck.java line 58: > 56: // cut off the dead code. As a result, -1 is fed as input into the > 57: // StringCoding::countPositives0 intrinsic which is replaced by TOP and causes a > 58: // failure in the matcher. I'd appreciate it if we can be more elaborate for less C2-illiterate people like myself. ? Suggestion: // Calling `StringCoding::countPositives`, which is a "front door" // to the `StringCoding::countPositives0` intrinsic. // `countPositives` validates its input using // `Preconditions::checkFromIndexSize`, which also maps to an // intrinsic. When `checkFromIndexSize` is not inlined, C2 does not // know about the explicit range checks, and does not cut off the // dead code. As a result, an invalid value (e.g., `-1`) can be fed // as input into the `countPositives0` intrinsic, got replaced // by TOP, and cause a failure in the matcher. ------------- PR Review: https://git.openjdk.org/jdk/pull/29164#pullrequestreview-3681112226 PR Comment: https://git.openjdk.org/jdk/pull/29164#issuecomment-3738455817 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2689568427 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2687948444 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2685859575 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2685838328 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2705884654 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2705885810 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2704760982 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2689735070 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2689780537 From dfenacci at openjdk.org Tue Jan 20 18:54:10 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Tue, 20 Jan 2026 18:54:10 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com> References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com> Message-ID: On Mon, 12 Jan 2026 13:03:58 GMT, Volkan Yazici wrote: >> ## Issue >> >> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. >> >> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. >> >> ## Causes >> >> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. >> >> ## Fix >> >> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: >> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 >> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. >> >> # Testing >> >> * Tier 1-3+ >> * 2 JTReg tests added >> * `TestRangeCheck.java` as regression test for the reported issue >> * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion > > Verified that 3c466d372b7 is a clean revert of 7e18de137c3 delivered in [JDK-8374210]. > > [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210 Thanks for your review @vy. In addition to the changes you suggested I also fixed the opaque node value in `LibraryCallKit::generate_limit_guard` which was wrong (I then removed the `is_positive` flag altogether since it was `false` in both cases) and added `TestOpaqueGuardNodes.java` to test that the opaque nodes are added and later removed. > src/hotspot/share/opto/c2_globals.hpp line 680: > >> 678: develop(bool, VerifyIntrinsicChecks, false, \ >> 679: "Verify in intrinsic that Java level checks work as expected") \ >> 680: \ > > I suggest removing the `VerifyIntrinsicChecks` flag. Given `OpaqueGuard` already verifies the value when `#ifdef ASSERT`, does `VerifyIntrinsicChecks` serve any purpose anymore? Done. > src/hotspot/share/opto/loopopts.cpp line 1: > >> 1: /* > > What is the reason that the new `OpaqueGuard` is not taken into account in `PhaseIdealLoop::clone_iff`? Oversight ? Thanks! Fixed. > src/hotspot/share/opto/macro.cpp line 2565: > >> 2563: // Tests with OpaqueGuard nodes are implicitly known to be true or false. Replace the node with appropriate value. In debug builds, >> 2564: // we leave the test in the graph to have an additional sanity check at runtime. If the test fails (i.e. a bug), >> 2565: // we will execute a Halt node. > > *Nit:* Can we adhere to the max. 120 (or even better, 80!) characters per line limit of the file? Fair enough (good to know: I wasn't aware of such limit). > src/hotspot/share/opto/macro.cpp line 2569: > >> 2567: _igvn.replace_node(n, n->in(1)); >> 2568: #else >> 2569: _igvn.replace_node(n, _igvn.intcon(0)); > > Curious: why do we invoke `intcon(0)` for `OpaqueGuard`, whereas it was `intcon(1)` for `OpaqueNotNull` slightly above? In `OpaqueGuard`'s case we know that the input is always "false" (so, we set 0 as its input). For `OpaqueNotNull` we know that the input is always "true" (so, we set 1 as its input). > src/hotspot/share/opto/opaquenode.hpp line 160: > >> 158: // we keep the actual checks as additional verification code (i.e. removing OpaqueGuardNode and use the BoolNode >> 159: // inputs instead). >> 160: class OpaqueGuardNode : public Node { > > With the `OpaqueGuardNode::is_positive` flag gone, `OpaqueGuardNode` looks pretty much identical to `OpaqueNotNullNode`. Is there a code reuse opportunity we can take advantage of? It is true that they do pretty much the same thing ("avoid" C2 optimisations for checks) but I'd argue they are semantically slightly different: one prevents optimisations where we know the value cannot be null, the other where we know the value is in range. We could actually have only one class (e.g. with a `positive` flag like before) but I'm not sure it would be a cleaner/nicer solution. ? > test/hotspot/jtreg/compiler/intrinsics/TestVerifyIntrinsicChecks.java line 1: > >> 1: /* > > Since the `VerifyIntrinsicChecks` flag is gone, AFAICT, all following changes can be reverted: > > > git rm test/hotspot/jtreg/compiler/intrinsics/TestVerifyIntrinsicChecks.java > git checkout upstream/HEAD -- \ > test/hotspot/jtreg/compiler/intrinsics/string/TestCountPositives.java \ > test/hotspot/jtreg/compiler/intrinsics/string/TestEncodeIntrinsics.java \ > test/hotspot/jtreg/compiler/intrinsics/string/TestHasNegatives.java \ > test/hotspot/jtreg/compiler/patches/java.base/java/lang/Helper.java Totally. Done. > test/hotspot/jtreg/compiler/intrinsics/string/TestRangeCheck.java line 32: > >> 30: * -XX:CompileCommand=inline,java.lang.StringCoding::* >> 31: * -XX:CompileCommand=exclude,jdk.internal.util.Preconditions::checkFromIndexSize >> 32: * -XX:CompileCommand=compileonly,compiler.intrinsics.string.TestRangeCheck::test > > Is this necessary? (This wasn't used in `TestStringConstruction`.) Nope (leftover from debugging). Removed ------------- PR Comment: https://git.openjdk.org/jdk/pull/29164#issuecomment-3755585217 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2694787876 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2694785777 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2694785429 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2707280040 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2707283139 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2707272331 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2694788432 From vyazici at openjdk.org Tue Jan 20 18:54:11 2026 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 20 Jan 2026 18:54:11 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com> References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com> Message-ID: On Tue, 13 Jan 2026 20:01:31 GMT, Volkan Yazici wrote: >> ## Issue >> >> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. >> >> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. >> >> ## Causes >> >> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. >> >> ## Fix >> >> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: >> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 >> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. >> >> # Testing >> >> * Tier 1-3+ >> * 2 JTReg tests added >> * `TestRangeCheck.java` as regression test for the reported issue >> * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion > > src/hotspot/share/opto/library_call.hpp line 170: > >> 168: Node* length, bool char_count, >> 169: bool halt_on_oob = false, >> 170: bool is_opaque = false); > > Do we really need to introduce two new toggles: `halt_on_oob` and `is_opaque`? At all call-sites either one of the following is used: > > 1. `halt_on_oob=true, is_opaque=!VerifyIntrinsicChecks` > 2. defaults (i.e., `halt_on_oob=is_opaque=false`) > > Can we instead only settle one, e.g., `halt_on_oob=VerifyIntrinsicChecks`? Giving this a second thought, do we need these two flags anyway? That is, 1. We can remove `if (is_opaque)` add the `OpaqueGuard` anyway, since it is ineffective for `!ASSERT`. (This is what `must_be_not_null` does too.) 2. We can replace `if (halt_on_oob) { ... } else { ... }` with `#ifdef ASSERT ...`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2689690430 From dfenacci at openjdk.org Tue Jan 20 18:54:12 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Tue, 20 Jan 2026 18:54:12 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com> Message-ID: On Wed, 14 Jan 2026 09:38:40 GMT, Volkan Yazici wrote: >> src/hotspot/share/opto/library_call.hpp line 170: >> >>> 168: Node* length, bool char_count, >>> 169: bool halt_on_oob = false, >>> 170: bool is_opaque = false); >> >> Do we really need to introduce two new toggles: `halt_on_oob` and `is_opaque`? At all call-sites either one of the following is used: >> >> 1. `halt_on_oob=true, is_opaque=!VerifyIntrinsicChecks` >> 2. defaults (i.e., `halt_on_oob=is_opaque=false`) >> >> Can we instead only settle one, e.g., `halt_on_oob=VerifyIntrinsicChecks`? > > Giving this a second thought, do we need these two flags anyway? That is, > > 1. We can remove `if (is_opaque)` add the `OpaqueGuard` anyway, since it is ineffective for `!ASSERT`. (This is what `must_be_not_null` does too.) > 2. We can replace `if (halt_on_oob) { ... } else { ... }` with `#ifdef ASSERT ...`. 1. I'm not sure we can always do that: `LibraryCallKit::generate_string_range_check` is called from places that don't yet have Java range checks and we must not add an opaque node in those cases (or we end up without checks in prod builds). 2. For a similar reason I'd leave `if (halt_on_oob)` condition: for calls to `LibraryCallKit::generate_string_range_check` that don't yet have Java range checks the method behaves like it did before. For "new" calls it adds the `Halt` node (which will then be removed together with the guard in prod builds). So, on the one hand we can keep `halt_on_oob` alone as discriminant between "new" and "old" call sites. On the other we can get rid of `VerifyIntrinsicChecks` because we implicitly add the additional range check in debug builds (always). I've modified the code accordingly. What do you think? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2694787303 From vyazici at openjdk.org Tue Jan 20 18:54:12 2026 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 20 Jan 2026 18:54:12 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com> Message-ID: On Tue, 20 Jan 2026 08:27:59 GMT, Damon Fenacci wrote: >> src/hotspot/share/opto/opaquenode.hpp line 160: >> >>> 158: // we keep the actual checks as additional verification code (i.e. removing OpaqueGuardNode and use the BoolNode >>> 159: // inputs instead). >>> 160: class OpaqueGuardNode : public Node { >> >> With the `OpaqueGuardNode::is_positive` flag gone, `OpaqueGuardNode` looks pretty much identical to `OpaqueNotNullNode`. Is there a code reuse opportunity we can take advantage of? > > It is true that they do pretty much the same thing ("avoid" C2 optimisations for checks) but I'd argue they are semantically slightly different: one prevents optimisations where we know the value cannot be null, the other where we know the value is in range. We could actually have only one class (e.g. with a `positive` flag like before) but I'm not sure it would be a cleaner/nicer solution. ? Fair enough ? I was just curious. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2707418513 From duke at openjdk.org Tue Jan 20 18:54:14 2026 From: duke at openjdk.org (ExE Boss) Date: Tue, 20 Jan 2026 18:54:14 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com> References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com> Message-ID: On Wed, 14 Jan 2026 10:05:23 GMT, Volkan Yazici wrote: >> ## Issue >> >> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. >> >> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. >> >> ## Causes >> >> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. >> >> ## Fix >> >> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: >> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 >> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. >> >> # Testing >> >> * Tier 1-3+ >> * 2 JTReg tests added >> * `TestRangeCheck.java` as regression test for the reported issue >> * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion > > test/hotspot/jtreg/compiler/intrinsics/string/TestRangeCheck.java line 58: > >> 56: // cut off the dead code. As a result, -1 is fed as input into the >> 57: // StringCoding::countPositives0 intrinsic which is replaced by TOP and causes a >> 58: // failure in the matcher. > > I'd appreciate it if we can be more elaborate for less C2-illiterate people like myself. ? > > Suggestion: > > // Calling `StringCoding::countPositives`, which is a "front door" > // to the `StringCoding::countPositives0` intrinsic. > // `countPositives` validates its input using > // `Preconditions::checkFromIndexSize`, which also maps to an > // intrinsic. When `checkFromIndexSize` is not inlined, C2 does not > // know about the explicit range checks, and does not cut off the > // dead code. As a result, an invalid value (e.g., `-1`) can be fed > // as input into the `countPositives0` intrinsic, got replaced > // by TOP, and cause a failure in the matcher. **Nit:** Using??get??here is?grammatically?better: // intrinsic. When `checkFromIndexSize` is not inlined, C2 does not // know about the explicit range checks, and does not cut off the - // as input into the `countPositives0` intrinsic, got replaced + // as input into the `countPositives0` intrinsic, get replaced // by TOP, and cause a failure in the matcher. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2690260434 From dfenacci at openjdk.org Tue Jan 20 18:54:14 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Tue, 20 Jan 2026 18:54:14 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com> Message-ID: On Wed, 14 Jan 2026 12:34:51 GMT, ExE Boss wrote: >> test/hotspot/jtreg/compiler/intrinsics/string/TestRangeCheck.java line 58: >> >>> 56: // cut off the dead code. As a result, -1 is fed as input into the >>> 57: // StringCoding::countPositives0 intrinsic which is replaced by TOP and causes a >>> 58: // failure in the matcher. >> >> I'd appreciate it if we can be more elaborate for less C2-illiterate people like myself. ? >> >> Suggestion: >> >> // Calling `StringCoding::countPositives`, which is a "front door" >> // to the `StringCoding::countPositives0` intrinsic. >> // `countPositives` validates its input using >> // `Preconditions::checkFromIndexSize`, which also maps to an >> // intrinsic. When `checkFromIndexSize` is not inlined, C2 does not >> // know about the explicit range checks, and does not cut off the >> // dead code. As a result, an invalid value (e.g., `-1`) can be fed >> // as input into the `countPositives0` intrinsic, got replaced >> // by TOP, and cause a failure in the matcher. > > **Nit:** Using??get??here is?grammatically?better: > > // intrinsic. When `checkFromIndexSize` is not inlined, C2 does not > // know about the explicit range checks, and does not cut off the > - // as input into the `countPositives0` intrinsic, got replaced > + // as input into the `countPositives0` intrinsic, get replaced > // by TOP, and cause a failure in the matcher. Done. Thanks for the suggestion! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2694948915 From vlivanov at openjdk.org Tue Jan 20 19:42:47 2026 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 20 Jan 2026 19:42:47 GMT Subject: RFR: 8375046: C2: Assertion failed in GrowableArray::remove_till(0) [v4] In-Reply-To: References: <_tSvASngm2bL0X2wavXI63kJZoypsY5S-dus_KGhs18=.ace489be-48bf-4254-a88e-b4fe456edf02@github.com> Message-ID: On Mon, 19 Jan 2026 10:25:43 GMT, Aleksey Shipilev wrote: > The case shows up in CTW -- and fairly rarely at that -- so I think there is no reason for us to care all that much about that corner case, as long as it does not break correctness. Current code just creates the noise in testing, so we are fixing that noise. The point I'm trying to make is `Compile::inline_incrementally_one()` assumes `_late_inlines` is not empty. Both callers (`Compile::inline_incrementally()` and `Compile::process_late_inline_calls_no_inline()`) do have `_late_inlines.length() > 0` guards, but it seems it doesn't hold when `PhaseIdealLoop` removes remaining elements from `_late_inlines`. The behavior is counter-intuitive and can cause other surprises later. Instead, I suggest to add ` if (_late_inlines.length() == 0) return;` in `Compile::inline_incrementally()` before calling into `inline_incrementally_one()`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29171#issuecomment-3774617706 From vlivanov at openjdk.org Tue Jan 20 19:43:23 2026 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 20 Jan 2026 19:43:23 GMT Subject: RFR: 8374807: Crash in MethodData::extra_data_lock()+0x0 when running -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp -version [v4] In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 13:31:43 GMT, Guanqiang Han wrote: >> Please review this change. Thanks! >> >> Description: >> >> This change fixes a crash in Deoptimization::uncommon_trap_inner when running with -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp. >> >> With -XX:-ProfileTraps, create_if_missing is set to false. >> https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L2121-L2122 >> >> When create_if_missing is false, new mdo can not be created when m()->method_data() return null, so get_method_data() may return null . >> https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L1911-L1912 >> >> and trap_mdo can be null as a result >> https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L2134-L2136 >> >> The crash happens here because trap_mdo is null >> https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L2157 >> >> Fix: >> >> The fix makes acquisition of extra_data_lock conditional on trap_mdo being non-null, preserving the required lock ordering (extra_data_lock before ttyLocker) when an MDO exists. >> >> Test: >> >> GHA > > Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - revert > - Merge remote-tracking branch 'upstream/master' into 8374807 > - narrow lock scope > - Merge remote-tracking branch 'upstream/master' into 8374807 > - split long line > - Merge remote-tracking branch 'upstream/master' into 8374807 > - fix 8374807 Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29147#pullrequestreview-3683976061 From kfarrell at openjdk.org Tue Jan 20 19:51:09 2026 From: kfarrell at openjdk.org (Kieran Farrell) Date: Tue, 20 Jan 2026 19:51:09 GMT Subject: RFR: 8359706: Add file descriptor count and maximum limit to VM.info [v7] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 17:14:43 GMT, Kevin Walls wrote: >> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: >> >> relocate print out to SYSTEM section and remove AIX impl > > src/hotspot/os/windows/os_windows.cpp line 6262: > >> 6260: >> 6261: void os::print_open_file_descriptors(outputStream* st) { >> 6262: // File descriptor counting not supported on Windows. > > If you said "not implemented" here and in the other comment, it might be clearer that somebody could implement these if they build and test it. Not supported sounds to me more like a reason we cannot do it. Windows doesn't support UNIX-style file descriptors hence using the word 'supported', I've updated the AIX stub to say 'not implemented' however. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27971#discussion_r2709837631 From vlivanov at openjdk.org Tue Jan 20 19:52:14 2026 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 20 Jan 2026 19:52:14 GMT Subject: RFR: 8375534: Debug method 'pp' should support compressed oops [v2] In-Reply-To: <8WMvLeZIKT01h3gYFaeUJhQqNmZirdoiwvqbdejYQok=.bbe3b14b-0923-4528-bb0a-2355bbe53e8f@github.com> References: <8WMvLeZIKT01h3gYFaeUJhQqNmZirdoiwvqbdejYQok=.bbe3b14b-0923-4528-bb0a-2355bbe53e8f@github.com> Message-ID: <9wpo6Gn4c1T-82rhG86u9LPzzxOr7lB4ST3AGFYGrKU=.0d8d9baa-a1cf-4ac9-8b8d-b7b968dbfdf3@github.com> On Mon, 19 Jan 2026 08:11:00 GMT, Tobias Hartmann wrote: >> The debug method `pp` is currently not able to handle compressed oops. This should fix it. The code is similar to `BlockLocationPrinter::print_location`. >> >> **Before:** >> >> >> (rr) call (void*) pp(0x6b9c08fc8) >> >> "Executing pp" >> java.lang.Runtime$Version >> {0x00000006b9c08fc8} - klass: 'java/lang/Runtime$Version' - flags: >> >> - ---- fields (total size 4 words): >> - private final value 'version' 'Ljava/util/List;' @12 a 'java/util/ImmutableCollections$List12'{0x00000006b9c2cbb8} (0xd7385977) >> - private final value 'pre' 'Ljava/util/Optional;' @16 a 'java/util/Optional'{0x00000006b9c2cbd0} (0xd738597a) >> - private final value 'build' 'Ljava/util/Optional;' @20 a 'java/util/Optional'{0x00000006b9c0a118} (0xd7381423) >> - private final value 'optional' 'Ljava/util/Optional;' @24 a 'java/util/Optional'{0x00000006b9c2cbe8} (0xd738597d) >> $1 = (void *) 0x0 >> (rr) call (void*) pp(0xd7381423) >> >> "Executing pp" >> The program being debugged received signal SIGSEGV, Segmentation fault >> while in a function called from GDB. GDB has restored the context >> to what it was before the call. To change this behavior use >> "set unwind-on-signal off". Evaluation of the expression containing >> the function (pp(long)) will be abandoned. >> >> >> **After:** >> ```(rr) call (void*) pp(0x6b9c08fc8) >> >> "Executing pp" >> java.lang.Runtime$Version >> {0x00000006b9c08fc8} - klass: 'java/lang/Runtime$Version' - flags: >> >> - ---- fields (total size 4 words): >> - private final value 'version' 'Ljava/util/List;' @12 a 'java/util/ImmutableCollections$List12'{0x00000006b9c2cbb8} (0xd7385977) >> - private final value 'pre' 'Ljava/util/Optional;' @16 a 'java/util/Optional'{0x00000006b9c2cbd0} (0xd738597a) >> - private final value 'build' 'Ljava/util/Optional;' @20 a 'java/util/Optional'{0x00000006b9c0a118} (0xd7381423) >> - private final value 'optional' 'Ljava/util/Optional;' @24 a 'java/util/Optional'{0x00000006b9c2cbe8} (0xd738597d) >> $1 = (void *) 0x0 >> (rr) call (void*) pp(0xd7381423) >> >> "Executing pp" >> 3610776611 is a compressed pointer to object: java.util.Optional >> {0x00000006b9c0a118} - klass: 'java/util/Optional' - flags: >> >> - ---- fields (total size 3 words): >> - private final value 'value' 'Ljava/lang/Object;' @16 null (0x00000000) >> $2 = (void *) 0x0 >> >> >> Thanks, >> Tobias > > Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision: > > Let's just use print_location instead Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29280#pullrequestreview-3684009658 From kfarrell at openjdk.org Tue Jan 20 19:53:41 2026 From: kfarrell at openjdk.org (Kieran Farrell) Date: Tue, 20 Jan 2026 19:53:41 GMT Subject: RFR: 8359706: Add file descriptor count and maximum limit to VM.info [v8] In-Reply-To: References: Message-ID: > 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 incrementally with one additional commit since the last revision: minor updates ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27971/files - new: https://git.openjdk.org/jdk/pull/27971/files/14ca2e29..926fc920 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27971&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27971&range=06-07 Stats: 4 lines in 3 files changed: 0 ins; 1 del; 3 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 pchilanomate at openjdk.org Tue Jan 20 20:46:04 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 20 Jan 2026 20:46:04 GMT Subject: RFR: 8373120: Virtual thread stuck in BLOCKED state [v3] In-Reply-To: References: Message-ID: > Please review the following patch. This fixes a bug in how we handle state changes for the timed `Object.wait` case in `afterYield`, which can leave a virtual thread stuck in the `BLOCKED` state. It can be triggered by two consecutive calls to timed `Object.wait`, if the first call receives a notification and the second call relies on the timeout task to wake up the thread. I added the full sequence of events that leads to the vthread getting stuck in JBS. > > The fix is to check for `notified` and attempt to change the state to `BLOCKED` inside the synchronized block. This guarantees that we don't change the state of an already new timed `Object.wait` call. > > The PR includes a new test which reproduces the issue when run several times in mach5. It's a hybrid of my original repro test and another one created by @AlanBateman. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: Randomly choose platform or virtual notifier ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29255/files - new: https://git.openjdk.org/jdk/pull/29255/files/b69a40f1..c31f41fa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29255&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29255&range=01-02 Stats: 15 lines in 1 file changed: 7 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/29255.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29255/head:pull/29255 PR: https://git.openjdk.org/jdk/pull/29255 From pchilanomate at openjdk.org Tue Jan 20 20:50:22 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 20 Jan 2026 20:50:22 GMT Subject: RFR: 8373120: Virtual thread stuck in BLOCKED state [v3] In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 19:49:55 GMT, Alan Bateman wrote: >> Added a comment. Maybe we should use `ThreadLocalRandom` in both cases to decide whether the notifier should be a platform or virtual thread? > > Good idea, could be TLR or just different runs of test but the effect would be adding more timing scenarios to the testing. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29255#discussion_r2710015709 From duke at openjdk.org Tue Jan 20 23:14:19 2026 From: duke at openjdk.org (Larry Cable) Date: Tue, 20 Jan 2026 23:14:19 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v9] In-Reply-To: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: > 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: added support to summarize AOT cache sharing usage ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29048/files - new: https://git.openjdk.org/jdk/pull/29048/files/d29848e8..3efe6afc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=07-08 Stats: 38 lines in 4 files changed: 31 ins; 0 del; 7 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 ghan at openjdk.org Wed Jan 21 00:00:50 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Wed, 21 Jan 2026 00:00:50 GMT Subject: RFR: 8374807: Crash in MethodData::extra_data_lock()+0x0 when running -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp -version [v4] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 19:40:09 GMT, Vladimir Ivanov wrote: >> Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: >> >> - revert >> - Merge remote-tracking branch 'upstream/master' into 8374807 >> - narrow lock scope >> - Merge remote-tracking branch 'upstream/master' into 8374807 >> - split long line >> - Merge remote-tracking branch 'upstream/master' into 8374807 >> - fix 8374807 > > Looks good. Hi @iwanowww Thanks for the review! Does it need a second reviewer? If not, I?ll integrate it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29147#issuecomment-3775498647 From sparasa at openjdk.org Wed Jan 21 00:04:30 2026 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Wed, 21 Jan 2026 00:04:30 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v13] In-Reply-To: References: <_9OkAqddCk8CbA-51qgdecI23f03MBsZE9kiES5cU0I=.d1adead1-45ff-40be-b139-2f9fa32c7d42@github.com> Message-ID: On Mon, 19 Jan 2026 08:11:19 GMT, Emanuel Peter wrote: > Can you explain the difference between the two results? > Hi Emanuel (@eme64), Yes, the conclusions you mentioned are correct. The store only benchmark shows that masked store is slightly better than the unmasked store. However, the store followed by load benchmarks shows that the unmasked store is better than masked vector store as masked vector stores have very limited store forwarding support in the hardware. This is because the load operation following the masked vector store is blocked until the data is written into the cache. This is also mentioned in the [Intel Software optimization manual](https://www.intel.com/content/www/us/en/content-details/671488/intel-64-and-ia-32-architectures-optimization-reference-manual-volume-1.html) (Chapter 18, section 18.4, page 578). Pasting the relevant text below for reference: 18.4 FORWARDING AND MEMORY MASKING When using masked store and load, consider the following: ? When the mask is not all-ones or all-zeroes, the load operation, following the masked store operation from the same address is blocked, until the data is written to the cache. ? Unlike GPR forwarding rules, vector loads whether or not they are masked, do not forward unless load and store addresses are exactly the same. ? st_mask = 10101010, ld_mask = 01010101, can forward: no, should block: yes ? st_mask = 00001111, ld_mask = 00000011, can forward: no, should block: yes ? When the mask is all-ones, blocking does not occur, because the data may be forwarded to the load operation. ? st_mask = 11111111, ld_mask = don?t care, can forward: yes, should block: no ? When mask is all-zeroes, blocking does not occur, though neither does forwarding. ? st_mask = 00000000, ld_mask = don?t care, can forward: no, should block: no In summary, a masked store should be used carefully, for example, if the remainder size is known at compile time to be 1, and there is a load operation from the same cache line after it (or there is an overlap in addresses + vector lengths), it may be better to use scalar remainder processing, rather than a masked remainder block. Thanks, Vamsi ------------- PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3775508253 From kbarrett at openjdk.org Wed Jan 21 00:36:50 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 21 Jan 2026 00:36:50 GMT Subject: RFR: 8358957: [ubsan]: The assert in layout_helper_boolean_diffbit() in klass.hpp needs UB to fail [v8] In-Reply-To: <_zOzryyrcX3PRWGo7osHOKa9hHfWTsKUi_Sj_bhUMLo=.9c7313b8-268e-41b9-8567-325449c24784@github.com> References: <_zOzryyrcX3PRWGo7osHOKa9hHfWTsKUi_Sj_bhUMLo=.9c7313b8-268e-41b9-8567-325449c24784@github.com> Message-ID: On Mon, 15 Sep 2025 10:27:41 GMT, Kim Barrett wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> disabling the msvc warning remoeved > > src/hotspot/share/oops/klass.hpp line 526: > >> 524: // So use alternate form of negation to avoid warning. >> 525: uint result = candidates & (~candidates + 1); >> 526: return static_cast(result); > > Since this is the implementation I suggested in JBS, I'm going to leave it to others to approve or not. > Maybe there should be a post-condition check that the result meets the requirements. That's simpler > than adding a gtest or anything like that. The asserts that were added since my comment look satisfactory. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27288#discussion_r2710541760 From ghan at openjdk.org Wed Jan 21 02:39:32 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Wed, 21 Jan 2026 02:39:32 GMT Subject: RFR: 8374519: assert((!inside_attrs()) || VMError::is_error_reported()) failed: cannot print tag inside attrs with "-XX:+LogCompilation -XX:-SerializeVMOutput" Message-ID: Please review this change. Thanks! **Description:** The compilation logging is written as structured XML through the global xtty. With SerializeVMOutput turned off, multiple threads can write to the same xmlStream concurrently. This allows XML fragments (especially the tag/attribute header state) to interleave, corrupting the xmlStream markup state machine and triggering the inside_attrs() assertion. **Fix:** Ensure xtty remains serialized even when -XX:-SerializeVMOutput is specified. **Test:** GHA ------------- Commit messages: - fix 8374519 Changes: https://git.openjdk.org/jdk/pull/29337/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29337&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374519 Stats: 43 lines in 2 files changed: 40 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29337.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29337/head:pull/29337 PR: https://git.openjdk.org/jdk/pull/29337 From duke at openjdk.org Wed Jan 21 03:02:33 2026 From: duke at openjdk.org (He-Pin (kerr)) Date: Wed, 21 Jan 2026 03:02:33 GMT Subject: RFR: 8369238: Allow virtual thread preemption on some common class initialization paths [v15] In-Reply-To: References: Message-ID: <4hRNhuxziLbGiy8BIhN7Be3NlQ6cOckUF_earAzDDnU=.f00c5720-557f-4b34-b643-b9313cdf7afc@github.com> On Tue, 4 Nov 2025 21:28:14 GMT, Patricio Chilano Mateo wrote: >> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized. >> >> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too. >> >> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`. >> >> ### Summary of implementation >> >> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too. >> >> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). >> >> ### Notes >> >> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon... > > Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: > > - Add check for SingleStep events > - Merge branch 'master' into JDK-8369238 > - fix to JvmtiHideSingleStepping > - Suggested fix in macroAssembler_ppc.cpp > - Improve comment and assert msg > - More fixes from David's comments > - Merge branch 'master' into JDK-8369238 > - add const to references > - Improve comment in anchor_mark_set_pd > - More comments from Coleen > - ... and 12 more: https://git.openjdk.org/jdk/compare/2f455ed1...06f85198 Will this be backported to Java 25 LTS? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27802#issuecomment-3775903843 From dholmes at openjdk.org Wed Jan 21 03:12:20 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Jan 2026 03:12:20 GMT Subject: RFR: 8374519: assert((!inside_attrs()) || VMError::is_error_reported()) failed: cannot print tag inside attrs with "-XX:+LogCompilation -XX:-SerializeVMOutput" In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 02:32:29 GMT, Guanqiang Han wrote: > Please review this change. Thanks! > > **Description:** > > The compilation logging is written as structured XML through the global xtty. With SerializeVMOutput turned off, multiple threads can write to the same xmlStream concurrently. This allows XML fragments (especially the tag/attribute header state) to interleave, corrupting the xmlStream markup state machine and triggering the inside_attrs() assertion. > > **Fix:** > > Ensure xtty remains serialized even when -XX:-SerializeVMOutput is specified. > > **Test:** > > GHA I do not think this is an issue. There is no guarantee that every combination of flags is valid and useful and won't trip any assertions. If it crashed a product release that would be different - but I tested it and it seemed to work okay. There is almost zero reason to ever disable serialized VM output - and arguably we should look at dropping that flag. Is xtty only used with LogCompilation, or do we use it for other things? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29337#issuecomment-3775924888 From dholmes at openjdk.org Wed Jan 21 05:14:51 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Jan 2026 05:14:51 GMT Subject: RFR: 8375737: Fix -Wzero-as-null-pointer-constant warnings in arm32 code In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 18:27:26 GMT, Kim Barrett wrote: > Please review this trivial change to arm32 code to avoid using literal zero as a null > pointer constant, instead using nullptr. > > Testing: GHA build for arm32 Good and trivial. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29328#pullrequestreview-3685373003 From dholmes at openjdk.org Wed Jan 21 05:46:17 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Jan 2026 05:46:17 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: References: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> Message-ID: On Tue, 20 Jan 2026 10:03:15 GMT, Ivan Bereziuk wrote: > Do you think we need to be able changing the timestamp format (say "-T=UTC")? The main use of the time-stamp is to be able to correlate the time the diagnostic command was run, with the time of other events captured in other logs. So for that you would want compatible/comparable timestamps. As I mentioned previously UL has different timestamp formats, so be able to match those may be of benefit. Though I could also see that as being a future enhancement once we see how the basic wall-clock timestamp is received. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3776296670 From dholmes at openjdk.org Wed Jan 21 06:02:40 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Jan 2026 06:02:40 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> References: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> Message-ID: On Tue, 20 Jan 2026 08:57:52 GMT, Ivan Bereziuk wrote: >> `jcmd` provides great diagnostics but many commands lack a timestamp in their output. >> Adding a timestamp to the output of some would add value for those debugging JVM data. >> >> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. >> >> With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-T": >> >> jcmd [pid | main-class] [-T] command... | PerfCounter.print | -f filename >> ^^^^ >> >> * The choice for time format is "yyyy-MM-dd HH:mm:ss" as it is already used in `Thread.print`. >> * `Thread.print` prints timestamp irrespectively from "-T" flag presence to preserve backwards compatibility. >> >> I haven't added a timestamp to the following diagnostic command: >> * `VM.uptime` - command run with `-date` argument will also print a timestamp; >> * `VM.system_properties` - as the output already lists a timestamp. Not sure if we need more timestamps here. >> * `Thread.dump_to_file` - the content dumped to a file already has a timestamp; > > Ivan Bereziuk 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 15 additional commits since the last revision: > > - remove TimeStamp::No as it's not used. virtual should be flipped to override in bulk (afressed clang warning) > - Merge branch 'master' into 8357828_add_timestamp_to_jcmd > - changes to jcmd.md > - undo changes to reorder_help_cmd() > - cleanup > - add timestamp to VM.version. Add test > - updated jcmd usage text > - undo the changes to the modified earlier tests as timestamp presence is fully backwards compatible > - introduce -T as a commong flag > - Merge branch 'master' into 8357828_add_timestamp_to_jcmd > - ... and 5 more: https://git.openjdk.org/jdk/compare/d32dc5c4...5f1cefe0 > The choice for time format is "yyyy-MM-dd HH:mm:ss" as it is already used in Thread.print. That could be seen as a poor choice by `Thread.print`. The `VMUptimeDCmd` uses `OutputStream::date_stamp()` which in turn uses `os::iso8601_time`, which is also what the `time` decorator for UL uses. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3776344918 From kbarrett at openjdk.org Wed Jan 21 05:59:36 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 21 Jan 2026 05:59:36 GMT Subject: RFR: 8375737: Fix -Wzero-as-null-pointer-constant warnings in arm32 code In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 05:11:53 GMT, David Holmes wrote: >> Please review this trivial change to arm32 code to avoid using literal zero as a null >> pointer constant, instead using nullptr. >> >> Testing: GHA build for arm32 > > Good and trivial. Thanks Thanks for reviewing @dholmes-ora ------------- PR Comment: https://git.openjdk.org/jdk/pull/29328#issuecomment-3776324337 From kbarrett at openjdk.org Wed Jan 21 05:59:37 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 21 Jan 2026 05:59:37 GMT Subject: Integrated: 8375737: Fix -Wzero-as-null-pointer-constant warnings in arm32 code In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 18:27:26 GMT, Kim Barrett wrote: > Please review this trivial change to arm32 code to avoid using literal zero as a null > pointer constant, instead using nullptr. > > Testing: GHA build for arm32 This pull request has now been integrated. Changeset: 34d6e5e0 Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/34d6e5e07b8ee43ee7f913dd47fa7c897f52e6c0 Stats: 8 lines in 3 files changed: 0 ins; 0 del; 8 mod 8375737: Fix -Wzero-as-null-pointer-constant warnings in arm32 code Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/29328 From jbhateja at openjdk.org Wed Jan 21 07:04:04 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 21 Jan 2026 07:04:04 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v13] In-Reply-To: <1ElN5XvEXAYGINpCIB2smhDrzekGyiXmG6o8-jnxDxk=.83a69a64-2894-40af-a2ee-9c35448c88b2@github.com> References: <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com> <1ElN5XvEXAYGINpCIB2smhDrzekGyiXmG6o8-jnxDxk=.83a69a64-2894-40af-a2ee-9c35448c88b2@github.com> Message-ID: On Fri, 19 Dec 2025 07:01:31 GMT, Emanuel Peter wrote: >> Hi @PaulSandoz , your comments have been addressed. Please let us know if there are other comments. >> Hi @eme64 , Kindly share your comments. > > @jatin-bhateja Thanks for the ping! I'll put this on the list for review early in 2026 :) Hi @eme64 , Your comments have been addressed ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3776496085 From alanb at openjdk.org Wed Jan 21 07:25:57 2026 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 21 Jan 2026 07:25:57 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: References: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> Message-ID: <63zZ3oyXzNCOjLubKLhsa63UwZGSh1-3o-YLX3YbjF0=.2e2ca1cd-a933-4a59-9c5f-bc9806a5ff14@github.com> On Wed, 21 Jan 2026 06:00:18 GMT, David Holmes wrote: > > The choice for time format is "yyyy-MM-dd HH:mm:ss" as it is already used in Thread.print. > > That could be seen as a poor choice by `Thread.print`. The `VMUptimeDCmd` uses `OutputStream::date_stamp()` which in turn uses `os::iso8601_time`, which is also what the `time` decorator for UL uses. For anything new then we should try to use ISO 8601 unless there is a good reason to do otherwise. The "yyyy-MM-dd HH:mm:ss" format, seen in the jstack and jcmd Thread.print output, seems to go back a long way. I wonder how risky it would be change that now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3776554080 From thartmann at openjdk.org Wed Jan 21 07:45:58 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 21 Jan 2026 07:45:58 GMT Subject: RFR: 8375534: Debug method 'pp' should support compressed oops [v2] In-Reply-To: <8WMvLeZIKT01h3gYFaeUJhQqNmZirdoiwvqbdejYQok=.bbe3b14b-0923-4528-bb0a-2355bbe53e8f@github.com> References: <8WMvLeZIKT01h3gYFaeUJhQqNmZirdoiwvqbdejYQok=.bbe3b14b-0923-4528-bb0a-2355bbe53e8f@github.com> Message-ID: On Mon, 19 Jan 2026 08:11:00 GMT, Tobias Hartmann wrote: >> The debug method `pp` is currently not able to handle compressed oops. This should fix it. The code is similar to `BlockLocationPrinter::print_location`. >> >> **Before:** >> >> >> (rr) call (void*) pp(0x6b9c08fc8) >> >> "Executing pp" >> java.lang.Runtime$Version >> {0x00000006b9c08fc8} - klass: 'java/lang/Runtime$Version' - flags: >> >> - ---- fields (total size 4 words): >> - private final value 'version' 'Ljava/util/List;' @12 a 'java/util/ImmutableCollections$List12'{0x00000006b9c2cbb8} (0xd7385977) >> - private final value 'pre' 'Ljava/util/Optional;' @16 a 'java/util/Optional'{0x00000006b9c2cbd0} (0xd738597a) >> - private final value 'build' 'Ljava/util/Optional;' @20 a 'java/util/Optional'{0x00000006b9c0a118} (0xd7381423) >> - private final value 'optional' 'Ljava/util/Optional;' @24 a 'java/util/Optional'{0x00000006b9c2cbe8} (0xd738597d) >> $1 = (void *) 0x0 >> (rr) call (void*) pp(0xd7381423) >> >> "Executing pp" >> The program being debugged received signal SIGSEGV, Segmentation fault >> while in a function called from GDB. GDB has restored the context >> to what it was before the call. To change this behavior use >> "set unwind-on-signal off". Evaluation of the expression containing >> the function (pp(long)) will be abandoned. >> >> >> **After:** >> ```(rr) call (void*) pp(0x6b9c08fc8) >> >> "Executing pp" >> java.lang.Runtime$Version >> {0x00000006b9c08fc8} - klass: 'java/lang/Runtime$Version' - flags: >> >> - ---- fields (total size 4 words): >> - private final value 'version' 'Ljava/util/List;' @12 a 'java/util/ImmutableCollections$List12'{0x00000006b9c2cbb8} (0xd7385977) >> - private final value 'pre' 'Ljava/util/Optional;' @16 a 'java/util/Optional'{0x00000006b9c2cbd0} (0xd738597a) >> - private final value 'build' 'Ljava/util/Optional;' @20 a 'java/util/Optional'{0x00000006b9c0a118} (0xd7381423) >> - private final value 'optional' 'Ljava/util/Optional;' @24 a 'java/util/Optional'{0x00000006b9c2cbe8} (0xd738597d) >> $1 = (void *) 0x0 >> (rr) call (void*) pp(0xd7381423) >> >> "Executing pp" >> 3610776611 is a compressed pointer to object: java.util.Optional >> {0x00000006b9c0a118} - klass: 'java/util/Optional' - flags: >> >> - ---- fields (total size 3 words): >> - private final value 'value' 'Ljava/lang/Object;' @16 null (0x00000000) >> $2 = (void *) 0x0 >> >> >> Thanks, >> Tobias > > Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision: > > Let's just use print_location instead Thanks Vladimir! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29280#issuecomment-3776618905 From epeter at openjdk.org Wed Jan 21 08:19:11 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 21 Jan 2026 08:19:11 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v13] In-Reply-To: References: <_9OkAqddCk8CbA-51qgdecI23f03MBsZE9kiES5cU0I=.d1adead1-45ff-40be-b139-2f9fa32c7d42@github.com> Message-ID: <2lC9m4MZczFpH42mQwumfMaj4Btkl5vgE4kGq4353Qk=.afdf8f74-7491-4b3a-b7e9-4b9904eeb1fd@github.com> On Wed, 21 Jan 2026 00:01:39 GMT, Srinivas Vamsi Parasa wrote: >> @vamsi-parasa Thanks for the extra data! >> >> Do I see this right? In the plots [here](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761659799), the masked performance lies lower/better than unmasked performance (here we measure ns/ops). But in your tables [here](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761712841) you are measuring ops/ms, and are getting the opposite trend: masked is slower than unmasked. >> >> Can you explain the difference between the two results? > >> Can you explain the difference between the two results? >> > Hi Emanuel (@eme64), > Yes, the conclusions you mentioned are correct. The store only benchmark shows that masked store is slightly better than the unmasked store. However, the store followed by load benchmarks shows that the unmasked store is better than masked vector store as masked vector stores have very limited store forwarding support in the hardware. > > This is because the load operation following the masked vector store is blocked until the data is written into the cache. This is also mentioned in the [Intel Software optimization manual](https://www.intel.com/content/www/us/en/content-details/671488/intel-64-and-ia-32-architectures-optimization-reference-manual-volume-1.html) (Chapter 18, section 18.4, page 578). > > Pasting the relevant text below for reference: > > > 18.4 FORWARDING AND MEMORY MASKING > When using masked store and load, consider the following: > ? When the mask is not all-ones or all-zeroes, the load operation, following the masked store operation > from the same address is blocked, until the data is written to the cache. > ? Unlike GPR forwarding rules, vector loads whether or not they are masked, do not forward unless > load and store addresses are exactly the same. > ? st_mask = 10101010, ld_mask = 01010101, can forward: no, should block: yes > ? st_mask = 00001111, ld_mask = 00000011, can forward: no, should block: yes > ? When the mask is all-ones, blocking does not occur, because the data may be forwarded to the load > operation. > ? st_mask = 11111111, ld_mask = don?t care, can forward: yes, should block: no > ? When mask is all-zeroes, blocking does not occur, though neither does forwarding. > ? st_mask = 00000000, ld_mask = don?t care, can forward: no, should block: no > In summary, a masked store should be used carefully, for example, if the remainder size is known at > compile time to be 1, and there is a load operation from the same cache line after it (or there is an > overlap in addresses + vector lengths), it may be better to use scalar remainder processing, rather than > a masked remainder block. > > > Thanks, > Vamsi @vamsi-parasa Ok, so now we have one benchmark that shows a speedup and one that shows a regression. How are we to proceed? It seems that without loads https://github.com/openjdk/jdk/pull/28442#issuecomment-3761659799, this patch leads to a regression. Only if there is a load from one of the last elements that the `Arrays.fill` stored to with a masked operation do we get a slowdown. Because of missing load-to-store forwarding. If we instead started loading from the first elements, those would probably already be in cache, and we would not have any latency issues, right? But is it not rather an edge-case that we load from the last elements immediately after the `Arrays.fill`? At least for longer arrays, it seems an edge case. For short arrays it is probably more likely that we access the last element soon after the fill. It does not seem like a trivial decision to me if this patch is an improvement or not. What do you think @vamsi-parasa ? @sviswa7 @dwhite-intel You already approved this PR. What are your thoughts here? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3776741440 From ghan at openjdk.org Wed Jan 21 08:28:06 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Wed, 21 Jan 2026 08:28:06 GMT Subject: RFR: 8374519: assert((!inside_attrs()) || VMError::is_error_reported()) failed: cannot print tag inside attrs with "-XX:+LogCompilation -XX:-SerializeVMOutput" In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 03:09:04 GMT, David Holmes wrote: > I do not think this is an issue. There is no guarantee that every combination of flags is valid and useful and won't trip any assertions. If it crashed a product release that would be different - but I tested it and it seemed to work okay. > > There is almost zero reason to ever disable serialized VM output - and arguably we should look at dropping that flag. > > Is xtty only used with LogCompilation, or do we use it for other things? I agree that -XX:+LogCompilation + -XX:-SerializeVMOutput isn?t a useful combination. xtty is primarily the xmlStream used for the compilation/CompileLog XML output (i.e., -XX:+LogCompilation). It also has other emission sites in related code paths, and appears to be used by other diagnostics (e.g., TraceDeoptimization, PrintNativeNMethods) as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29337#issuecomment-3776773090 From ghan at openjdk.org Wed Jan 21 08:39:52 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Wed, 21 Jan 2026 08:39:52 GMT Subject: RFR: 8374516: -version asserts with "-XX:+UseAESCTRIntrinsics -XX:-UseAES": "need AES instructions and misaligned SSE support" in generate_counterMode_AESCrypt_Parallel() Message-ID: Please review this change. Thanks! **Description:** VM crashes during startup on x86 when running with -XX:+UseAESCTRIntrinsics -XX:-UseAES. In this configuration, UseAESCTRIntrinsics may remain enabled while UseAES is explicitly disabled, and the VM generates AES-CTR stubs, hitting an assert(UseAES) in generate_counterMode_AESCrypt_Parallel(). **Fix:** Update x86 flag initialization to enforce the dependency between UseAESCTRIntrinsics and UseAES. When UseAES is disabled, explicitly disable UseAESCTRIntrinsics (with a warning when it was set on the command line), aligning behavior with the existing UseAES/UseAESIntrinsics gating and avoiding stub generation with inconsistent flag states. **Test:** GHA ------------- Commit messages: - fix 8374516 Changes: https://git.openjdk.org/jdk/pull/29338/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29338&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374516 Stats: 44 lines in 2 files changed: 43 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29338.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29338/head:pull/29338 PR: https://git.openjdk.org/jdk/pull/29338 From phubner at openjdk.org Wed Jan 21 08:43:14 2026 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Wed, 21 Jan 2026 08:43:14 GMT Subject: RFR: 8375534: Debug method 'pp' should support compressed oops [v2] In-Reply-To: <8WMvLeZIKT01h3gYFaeUJhQqNmZirdoiwvqbdejYQok=.bbe3b14b-0923-4528-bb0a-2355bbe53e8f@github.com> References: <8WMvLeZIKT01h3gYFaeUJhQqNmZirdoiwvqbdejYQok=.bbe3b14b-0923-4528-bb0a-2355bbe53e8f@github.com> Message-ID: On Mon, 19 Jan 2026 08:11:00 GMT, Tobias Hartmann wrote: >> The debug method `pp` is currently not able to handle compressed oops. This should fix it. The code is similar to `BlockLocationPrinter::print_location`. >> >> **Before:** >> >> >> (rr) call (void*) pp(0x6b9c08fc8) >> >> "Executing pp" >> java.lang.Runtime$Version >> {0x00000006b9c08fc8} - klass: 'java/lang/Runtime$Version' - flags: >> >> - ---- fields (total size 4 words): >> - private final value 'version' 'Ljava/util/List;' @12 a 'java/util/ImmutableCollections$List12'{0x00000006b9c2cbb8} (0xd7385977) >> - private final value 'pre' 'Ljava/util/Optional;' @16 a 'java/util/Optional'{0x00000006b9c2cbd0} (0xd738597a) >> - private final value 'build' 'Ljava/util/Optional;' @20 a 'java/util/Optional'{0x00000006b9c0a118} (0xd7381423) >> - private final value 'optional' 'Ljava/util/Optional;' @24 a 'java/util/Optional'{0x00000006b9c2cbe8} (0xd738597d) >> $1 = (void *) 0x0 >> (rr) call (void*) pp(0xd7381423) >> >> "Executing pp" >> The program being debugged received signal SIGSEGV, Segmentation fault >> while in a function called from GDB. GDB has restored the context >> to what it was before the call. To change this behavior use >> "set unwind-on-signal off". Evaluation of the expression containing >> the function (pp(long)) will be abandoned. >> >> >> **After:** >> ```(rr) call (void*) pp(0x6b9c08fc8) >> >> "Executing pp" >> java.lang.Runtime$Version >> {0x00000006b9c08fc8} - klass: 'java/lang/Runtime$Version' - flags: >> >> - ---- fields (total size 4 words): >> - private final value 'version' 'Ljava/util/List;' @12 a 'java/util/ImmutableCollections$List12'{0x00000006b9c2cbb8} (0xd7385977) >> - private final value 'pre' 'Ljava/util/Optional;' @16 a 'java/util/Optional'{0x00000006b9c2cbd0} (0xd738597a) >> - private final value 'build' 'Ljava/util/Optional;' @20 a 'java/util/Optional'{0x00000006b9c0a118} (0xd7381423) >> - private final value 'optional' 'Ljava/util/Optional;' @24 a 'java/util/Optional'{0x00000006b9c2cbe8} (0xd738597d) >> $1 = (void *) 0x0 >> (rr) call (void*) pp(0xd7381423) >> >> "Executing pp" >> 3610776611 is a compressed pointer to object: java.util.Optional >> {0x00000006b9c0a118} - klass: 'java/util/Optional' - flags: >> >> - ---- fields (total size 3 words): >> - private final value 'value' 'Ljava/lang/Object;' @16 null (0x00000000) >> $2 = (void *) 0x0 >> >> >> Thanks, >> Tobias > > Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision: > > Let's just use print_location instead Marked as reviewed by phubner (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/29280#pullrequestreview-3685960019 From epeter at openjdk.org Wed Jan 21 09:17:41 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 21 Jan 2026 09:17:41 GMT Subject: RFR: 8374807: Crash in MethodData::extra_data_lock()+0x0 when running -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp -version [v4] In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 13:31:43 GMT, Guanqiang Han wrote: >> Please review this change. Thanks! >> >> Description: >> >> This change fixes a crash in Deoptimization::uncommon_trap_inner when running with -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp. >> >> With -XX:-ProfileTraps, create_if_missing is set to false. >> https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L2121-L2122 >> >> When create_if_missing is false, new mdo can not be created when m()->method_data() return null, so get_method_data() may return null . >> https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L1911-L1912 >> >> and trap_mdo can be null as a result >> https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L2134-L2136 >> >> The crash happens here because trap_mdo is null >> https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L2157 >> >> Fix: >> >> The fix makes acquisition of extra_data_lock conditional on trap_mdo being non-null, preserving the required lock ordering (extra_data_lock before ttyLocker) when an MDO exists. >> >> Test: >> >> GHA > > Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - revert > - Merge remote-tracking branch 'upstream/master' into 8374807 > - narrow lock scope > - Merge remote-tracking branch 'upstream/master' into 8374807 > - split long line > - Merge remote-tracking branch 'upstream/master' into 8374807 > - fix 8374807 @hgqxjj Thanks for working on this! We generally require 2 reviews for hotspot changes, unless both the author and single reviewer say it is "trivial". This here is not trivial, I think ;) I have some comments in the test, otherwise the fix looks reasonable. test/hotspot/jtreg/compiler/uncommontrap/TestPrintDiagnosticsWithoutProfileTraps.java line 32: > 30: * @run main/othervm -XX:+TraceDeoptimization -XX:-ProfileTraps > 31: * -XX:-TieredCompilation -Xcomp > 32: * compiler.uncommontrap.TestPrintDiagnosticsWithoutProfileTraps `TraceDeoptimization` is a diagnostic flag. This test will cause issues without `-XX:+UnlockDiagnosticVMOptions`, right? And `ProfileTraps` is debug. So won't this need `-XX:+IgnoreUnrecognizedVMOptions`? @iwanowww Did you already run testing on this patch or should I run some? ------------- Changes requested by epeter (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29147#pullrequestreview-3686113323 PR Review Comment: https://git.openjdk.org/jdk/pull/29147#discussion_r2711636953 From epeter at openjdk.org Wed Jan 21 09:27:09 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 21 Jan 2026 09:27:09 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v13] In-Reply-To: References: <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com> <1ElN5XvEXAYGINpCIB2smhDrzekGyiXmG6o8-jnxDxk=.83a69a64-2894-40af-a2ee-9c35448c88b2@github.com> Message-ID: On Wed, 21 Jan 2026 07:01:39 GMT, Jatin Bhateja wrote: >> @jatin-bhateja Thanks for the ping! I'll put this on the list for review early in 2026 :) > > Hi @eme64 , Your comments have been addressed @jatin-bhateja This patch is really really large. There are lots of renamings that could be done in a separate patch first (as a subtask). It would make reviewing easier, allowing focus on the substantial work. See discussion here: https://github.com/openjdk/jdk/pull/28002#discussion_r2705376899 ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3777034545 From epeter at openjdk.org Wed Jan 21 09:27:12 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 21 Jan 2026 09:27:12 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v12] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 11:51:20 GMT, Jatin Bhateja wrote: >> test/jdk/jdk/incubator/vector/IntVectorMaxTests.java line 68: >> >>> 66: static IntVector bcast_vec = IntVector.broadcast(SPECIES, (int)10); >>> 67: >>> 68: static void AssertEquals(int actual, int expected) { >> >> There are lots of changes in this file that do not seem to have anything to do with Float16. Please file them separately. It will make review much easier. > > I have added an assertion wrapper so that float16 values (short) can be converted to float before calling actual Assert.* routines to handle all possible NaN bit patterns. Since the tests are generate from common template hence these changes appear. Can we not do those changes in a separate change, please? It will make it easier to review the rest of the PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2711675095 From mhaessig at openjdk.org Wed Jan 21 09:45:32 2026 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Wed, 21 Jan 2026 09:45:32 GMT Subject: RFR: 8375443: AVX-512: Disabling through UseSHA doesn't affect UseSHA3Intrinsics [v3] In-Reply-To: <3HBeP2xyEtLB_aYoetNP-qZ_WSJod0ZLWuky9gU6mKs=.77d6b1f0-69d8-4f42-a373-5d15e2d211bd@github.com> References: <3HBeP2xyEtLB_aYoetNP-qZ_WSJod0ZLWuky9gU6mKs=.77d6b1f0-69d8-4f42-a373-5d15e2d211bd@github.com> Message-ID: <_T3jGzGv9t1_E_CCKBXSuul1aUFYMVdAC_S45aEIIXE=.e89ba472-da8e-486a-962b-1717ac93be31@github.com> On Sun, 18 Jan 2026 16:18:55 GMT, Ramkumar Sunderbabu wrote: >> UseSHA flag is not respected while enabling/disabling UseSHA3Intrinsics flag in x86 builds. >> Added UseSHA in the mix. >> >> Testing: Only Basic testing done. I will run more compiler related testing. > > Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision: > > whitespace issue fixed Thank you for addressing my comments and adding a test. I have another suggestion regarding the test. test/hotspot/jtreg/compiler/arguments/TestUseSHA3IntrinsicsWithUseSHADisabled.java line 31: > 29: * @library /test/lib / > 30: * @requires vm.flagless > 31: * @requires os.arch == "amd64" | os.arch == "x86_64" Suggestion: * @requires os.simpleArch == "x64" IIRC, this is the more reliable way to detect x86_64. test/hotspot/jtreg/compiler/arguments/TestUseSHA3IntrinsicsWithUseSHADisabled.java line 32: > 30: * @requires vm.flagless > 31: * @requires os.arch == "amd64" | os.arch == "x86_64" > 32: * @requires vm.cpu.features ~= ".*avx512f.*" & vm.cpu.features ~= ".*avx512bw.*" It would be great to also test that the warning is emitted when `-XX:+UseSHA3Intrinsics` is passed, but is not supported by the CPU. You could remove this line and detect the features using `WHITE_BOX.getCPUFeatures()`. ------------- Changes requested by mhaessig (Committer). PR Review: https://git.openjdk.org/jdk/pull/29266#pullrequestreview-3683477539 PR Review Comment: https://git.openjdk.org/jdk/pull/29266#discussion_r2709416526 PR Review Comment: https://git.openjdk.org/jdk/pull/29266#discussion_r2709484685 From alanb at openjdk.org Wed Jan 21 09:46:03 2026 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 21 Jan 2026 09:46:03 GMT Subject: RFR: 8373120: Virtual thread stuck in BLOCKED state [v3] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:46:04 GMT, Patricio Chilano Mateo wrote: >> Please review the following patch. This fixes a bug in how we handle state changes for the timed `Object.wait` case in `afterYield`, which can leave a virtual thread stuck in the `BLOCKED` state. It can be triggered by two consecutive calls to timed `Object.wait`, if the first call receives a notification and the second call relies on the timeout task to wake up the thread. I added the full sequence of events that leads to the vthread getting stuck in JBS. >> >> The fix is to check for `notified` and attempt to change the state to `BLOCKED` inside the synchronized block. This guarantees that we don't change the state of an already new timed `Object.wait` call. >> >> The PR includes a new test which reproduces the issue when run several times in mach5. It's a hybrid of my original repro test and another one created by @AlanBateman. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Randomly choose platform or virtual notifier Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29255#pullrequestreview-3686247862 From rsunderbabu at openjdk.org Wed Jan 21 12:35:23 2026 From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu) Date: Wed, 21 Jan 2026 12:35:23 GMT Subject: RFR: 8375443: AVX-512: Disabling through UseSHA doesn't affect UseSHA3Intrinsics [v3] In-Reply-To: <_T3jGzGv9t1_E_CCKBXSuul1aUFYMVdAC_S45aEIIXE=.e89ba472-da8e-486a-962b-1717ac93be31@github.com> References: <3HBeP2xyEtLB_aYoetNP-qZ_WSJod0ZLWuky9gU6mKs=.77d6b1f0-69d8-4f42-a373-5d15e2d211bd@github.com> <_T3jGzGv9t1_E_CCKBXSuul1aUFYMVdAC_S45aEIIXE=.e89ba472-da8e-486a-962b-1717ac93be31@github.com> Message-ID: On Tue, 20 Jan 2026 17:59:48 GMT, Manuel H?ssig wrote: >> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision: >> >> whitespace issue fixed > > test/hotspot/jtreg/compiler/arguments/TestUseSHA3IntrinsicsWithUseSHADisabled.java line 32: > >> 30: * @requires vm.flagless >> 31: * @requires os.arch == "amd64" | os.arch == "x86_64" >> 32: * @requires vm.cpu.features ~= ".*avx512f.*" & vm.cpu.features ~= ".*avx512bw.*" > > It would be great to also test that the warning is emitted when `-XX:+UseSHA3Intrinsics` is passed, but is not supported by the CPU. You could remove this line and detect the features using `WHITE_BOX.getCPUFeatures()`. the properties are set already using WhiteBox.getCPUFeatures() https://github.com/openjdk/jdk/blob/983ae96f60c935aa52f482d21ae6a0d947679541/test/lib/jdk/test/whitebox/cpuinfo/CPUInfo.java#L53C39-L53C53 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29266#discussion_r2712373828 From mhaessig at openjdk.org Wed Jan 21 12:54:30 2026 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Wed, 21 Jan 2026 12:54:30 GMT Subject: RFR: 8375443: AVX-512: Disabling through UseSHA doesn't affect UseSHA3Intrinsics [v3] In-Reply-To: References: <3HBeP2xyEtLB_aYoetNP-qZ_WSJod0ZLWuky9gU6mKs=.77d6b1f0-69d8-4f42-a373-5d15e2d211bd@github.com> <_T3jGzGv9t1_E_CCKBXSuul1aUFYMVdAC_S45aEIIXE=.e89ba472-da8e-486a-962b-1717ac93be31@github.com> Message-ID: <6NVp9KhZgbSXRPeKeLfUHwtqHhQ14b1Q2xZtfcZBbKs=.c6923286-7ac2-42fb-925c-2a3119206032@github.com> On Wed, 21 Jan 2026 12:32:12 GMT, Ramkumar Sunderbabu wrote: >> test/hotspot/jtreg/compiler/arguments/TestUseSHA3IntrinsicsWithUseSHADisabled.java line 32: >> >>> 30: * @requires vm.flagless >>> 31: * @requires os.arch == "amd64" | os.arch == "x86_64" >>> 32: * @requires vm.cpu.features ~= ".*avx512f.*" & vm.cpu.features ~= ".*avx512bw.*" >> >> It would be great to also test that the warning is emitted when `-XX:+UseSHA3Intrinsics` is passed, but is not supported by the CPU. You could remove this line and detect the features using `WHITE_BOX.getCPUFeatures()`. > > the properties are set already using WhiteBox.getCPUFeatures() > https://github.com/openjdk/jdk/blob/983ae96f60c935aa52f482d21ae6a0d947679541/test/lib/jdk/test/whitebox/cpuinfo/CPUInfo.java#L53C39-L53C53 Right. But ideally, the test would not only run on machines where AVX512 is supported and check the warning on unsupported machines for complete coverage of the flag handling. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29266#discussion_r2712429391 From mhaessig at openjdk.org Wed Jan 21 12:54:30 2026 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Wed, 21 Jan 2026 12:54:30 GMT Subject: RFR: 8375443: AVX-512: Disabling through UseSHA doesn't affect UseSHA3Intrinsics [v3] In-Reply-To: <6NVp9KhZgbSXRPeKeLfUHwtqHhQ14b1Q2xZtfcZBbKs=.c6923286-7ac2-42fb-925c-2a3119206032@github.com> References: <3HBeP2xyEtLB_aYoetNP-qZ_WSJod0ZLWuky9gU6mKs=.77d6b1f0-69d8-4f42-a373-5d15e2d211bd@github.com> <_T3jGzGv9t1_E_CCKBXSuul1aUFYMVdAC_S45aEIIXE=.e89ba472-da8e-486a-962b-1717ac93be31@github.com> <6NVp9KhZgbSXRPeKeLfUHwtqHhQ14b1Q2xZtfcZBbKs=.c6923286-7ac2-42fb-925c-2a3119206032@github.com> Message-ID: On Wed, 21 Jan 2026 12:47:28 GMT, Manuel H?ssig wrote: >> the properties are set already using WhiteBox.getCPUFeatures() >> https://github.com/openjdk/jdk/blob/983ae96f60c935aa52f482d21ae6a0d947679541/test/lib/jdk/test/whitebox/cpuinfo/CPUInfo.java#L53C39-L53C53 > > Right. But ideally, the test would not only run on machines where AVX512 is supported and check the warning on unsupported machines for complete coverage of the flag handling. So, if you remove the `@requires` you can then use `CPUInfo` to check if the machine the test is running on has the required CPU features and add a new test case for when a machine does not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29266#discussion_r2712441716 From tschatzl at openjdk.org Wed Jan 21 13:33:13 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 21 Jan 2026 13:33:13 GMT Subject: RFR: 8373266: Strengthen constant CardTable base accesses [v2] In-Reply-To: References: Message-ID: <2QXqO9Zb2qShuQP-r33WBSkM65HLMQsi5M3x_B0ELJc=.856e0673-41aa-4c45-95d4-c43b7993e488@github.com> On Wed, 7 Jan 2026 19:06:02 GMT, Aleksey Shipilev 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 > > 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 Looks good apart from minor nits (extra spaces). Sorry for taking so long. src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp line 114: > 112: __ subptr(end, addr); // end --> cards count > 113: > 114: __ mov64(tmp, (intptr_t) ctbs->card_table_base_const()); Suggestion: __ mov64(tmp, (intptr_t)ctbs->card_table_base_const()); src/hotspot/os_cpu/linux_arm/javaThread_linux_arm.cpp line 47: > 45: if (bs->is_a(BarrierSet::CardTableBarrierSet)) { > 46: CardTableBarrierSet* ctbs = CardTableBarrierSet::barrier_set(); > 47: _card_table_base = (address) ctbs->card_table_base_const(); Suggestion: _card_table_base = (address)ctbs->card_table_base_const(); For consistency ------------- Changes requested by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28703#pullrequestreview-3687245667 PR Review Comment: https://git.openjdk.org/jdk/pull/28703#discussion_r2712571786 PR Review Comment: https://git.openjdk.org/jdk/pull/28703#discussion_r2712573615 From tschatzl at openjdk.org Wed Jan 21 13:33:14 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 21 Jan 2026 13:33:14 GMT Subject: RFR: 8373266: Strengthen constant CardTable base accesses [v2] In-Reply-To: <2QXqO9Zb2qShuQP-r33WBSkM65HLMQsi5M3x_B0ELJc=.856e0673-41aa-4c45-95d4-c43b7993e488@github.com> References: <2QXqO9Zb2qShuQP-r33WBSkM65HLMQsi5M3x_B0ELJc=.856e0673-41aa-4c45-95d4-c43b7993e488@github.com> Message-ID: On Wed, 21 Jan 2026 13:26:10 GMT, Thomas Schatzl wrote: >> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 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 > > src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp line 114: > >> 112: __ subptr(end, addr); // end --> cards count >> 113: >> 114: __ mov64(tmp, (intptr_t) ctbs->card_table_base_const()); > > Suggestion: > > __ mov64(tmp, (intptr_t)ctbs->card_table_base_const()); For consistency ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28703#discussion_r2712572480 From ghan at openjdk.org Wed Jan 21 13:55:52 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Wed, 21 Jan 2026 13:55:52 GMT Subject: RFR: 8374807: Crash in MethodData::extra_data_lock()+0x0 when running -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp -version [v4] In-Reply-To: References: Message-ID: <17qmKHGiPNSNpHn2By-gtJjPpwFFDj98wiY-bQG16nY=.4df59ed3-8120-496b-9a1e-06b80c9149ae@github.com> On Wed, 21 Jan 2026 09:11:54 GMT, Emanuel Peter wrote: >> Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: >> >> - revert >> - Merge remote-tracking branch 'upstream/master' into 8374807 >> - narrow lock scope >> - Merge remote-tracking branch 'upstream/master' into 8374807 >> - split long line >> - Merge remote-tracking branch 'upstream/master' into 8374807 >> - fix 8374807 > > test/hotspot/jtreg/compiler/uncommontrap/TestPrintDiagnosticsWithoutProfileTraps.java line 32: > >> 30: * @run main/othervm -XX:+TraceDeoptimization -XX:-ProfileTraps >> 31: * -XX:-TieredCompilation -Xcomp >> 32: * compiler.uncommontrap.TestPrintDiagnosticsWithoutProfileTraps > > `TraceDeoptimization` is a diagnostic flag. This test will cause issues without `-XX:+UnlockDiagnosticVMOptions`, right? And `ProfileTraps` is debug. So won't this need `-XX:+IgnoreUnrecognizedVMOptions`? > > @iwanowww Did you already run testing on this patch or should I run some? Hi @eme64 , thanks for the comments. I think we don?t need to add -XX:+UnlockDiagnosticVMOptions or -XX:+IgnoreUnrecognizedVMOptions here, because the test is guarded by @requires vm.debug. In debug builds, UnlockDiagnosticVMOptions is enabled by default (trueInDebug), so diagnostic flags like TraceDeoptimization are already unlocked, and ProfileTraps (a develop flag) is also available/recognized. https://github.com/openjdk/jdk/blob/983ae96f60c935aa52f482d21ae6a0d947679541/src/hotspot/share/runtime/globals.hpp#L172-L173 https://github.com/openjdk/jdk/blob/983ae96f60c935aa52f482d21ae6a0d947679541/src/hotspot/share/runtime/globals.hpp#L1188-L1189 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29147#discussion_r2712675296 From duke at openjdk.org Wed Jan 21 15:13:22 2026 From: duke at openjdk.org (Robert Toyonaga) Date: Wed, 21 Jan 2026 15:13:22 GMT Subject: RFR: 8353564: Fail fatally if os::release_memory or os::uncommit_memory fails Message-ID: This PR is a follow up to JDK-8341491. See original discussion: https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700 This PR makes `os::release_memory`, `os::uncommit_memory`, `os::release_memory_special`, and `os::unmap_memory` fail fatally if they encounter an error. These methods require obtaining the NMT lock. Fatally failing in these places would potentially allow for the tightening of NMT virtual memory locking scopes (future work, if this PR is accepted). Already in most cases, the callers fail fatally or assert(false) when these os:: methods fail. Another reason to fatally fail is that if the OS memory operation fails, it can be difficult to know for sure what state the OS left the memory in and recover. `release_memory`/`uncommit_memory`/`release_memory_special`/`unmap_memory` can fail due to ? Bad arguments, or ? The OS encountered an issue out of control of the JVM. ? If there is a JVM bug, it's probably reasonable to fatally fail here. Or the caller could be intentionally passing arguments that may or may not be valid. I don't think there is any code like that currently, and this is probably a bad pattern to be following anyway. ? In platform dependent code: With regard to mmap/munmap, the only errors that aren't due to bad arguments are ENOMEM and ones related to file descriptors (which are not applicable to uncommit or release). On Windows, VirtualFree only fails due to bad arguments. On AIX, shmdt and disclaim64 only fail due to bad arguments. msync could spontaneously fail with EIO: "An I/O error occurred while reading from or writing to the file system." On BSD, it seems like mprotect and madvise fail only due to bad arguments or invalid privileges. In the [original discussion](https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700), the main question was whether ENOMEM upon os::uncommit_memory was recoverable. This may be possible if we uncommit the middle of a region - splitting it in two. This could exceed the limit of the number of mappings resulting in ENOMEM. If none of the scenarios in ? are recoverable, then perhaps fatally failing is OK. Testing: - Tier 1. - Manual testing to make sure we fatally fail and the correct messages are printed. ------------- Commit messages: - fail fatally if OS memory ops fail Changes: https://git.openjdk.org/jdk/pull/29240/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29240&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353564 Stats: 99 lines in 16 files changed: 18 ins; 41 del; 40 mod Patch: https://git.openjdk.org/jdk/pull/29240.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29240/head:pull/29240 PR: https://git.openjdk.org/jdk/pull/29240 From duke at openjdk.org Wed Jan 21 15:13:23 2026 From: duke at openjdk.org (Robert Toyonaga) Date: Wed, 21 Jan 2026 15:13:23 GMT Subject: RFR: 8353564: Fail fatally if os::release_memory or os::uncommit_memory fails In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 23:30:14 GMT, Robert Toyonaga wrote: > This PR is a follow up to JDK-8341491. See original discussion: https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700 > > This PR makes `os::release_memory`, `os::uncommit_memory`, `os::release_memory_special`, and `os::unmap_memory` fail fatally if they encounter an error. These methods require obtaining the NMT lock. Fatally failing in these places would potentially allow for the tightening of NMT virtual memory locking scopes (future work, if this PR is accepted). Already in most cases, the callers fail fatally or assert(false) when these os:: methods fail. Another reason to fatally fail is that if the OS memory operation fails, it can be difficult to know for sure what state the OS left the memory in and recover. > > `release_memory`/`uncommit_memory`/`release_memory_special`/`unmap_memory` can fail due to ? Bad arguments, or ? The OS encountered an issue out of control of the JVM. > > ? > If there is a JVM bug, it's probably reasonable to fatally fail here. Or the caller could be intentionally passing arguments that may or may not be valid. I don't think there is any code like that currently, and this is probably a bad pattern to be following anyway. > > ? > In platform dependent code: > With regard to mmap/munmap, the only errors that aren't due to bad arguments are ENOMEM and ones related to file descriptors (which are not applicable to uncommit or release). > On Windows, VirtualFree only fails due to bad arguments. > On AIX, shmdt and disclaim64 only fail due to bad arguments. msync could spontaneously fail with EIO: "An I/O error occurred while reading from or writing to the file system." > On BSD, it seems like mprotect and madvise fail only due to bad arguments or invalid privileges. > > In the [original discussion](https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700), the main question was whether ENOMEM upon os::uncommit_memory was recoverable. This may be possible if we uncommit the middle of a region - splitting it in two. This could exceed the limit of the number of mappings resulting in ENOMEM. > > If none of the scenarios in ? are recoverable, then perhaps fatally failing is OK. > > Testing: > - Tier 1. > - Manual testing to make sure we fatally fail and the correct messages are printed. The Windows x64 Github CI test is fatally failing due to unsuccessful `os::uncommit` in ZForwardingTest. I believe that this is not the fault of the changes in this PR. Instead, the reason it fails is because the initial `os::commit` in `ZForwardingTest::SetUp()` was unable to commit the memory in the first place. I've opened [JDK-8375747](https://bugs.openjdk.org/browse/JDK-8375747) with more details. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29240#issuecomment-3778594714 From kevinw at openjdk.org Wed Jan 21 15:26:35 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 21 Jan 2026 15:26:35 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> References: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> Message-ID: On Tue, 20 Jan 2026 08:57:52 GMT, Ivan Bereziuk wrote: >> `jcmd` provides great diagnostics but many commands lack a timestamp in their output. >> Adding a timestamp to the output of some would add value for those debugging JVM data. >> >> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. >> >> With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-T": >> >> jcmd [pid | main-class] [-T] command... | PerfCounter.print | -f filename >> ^^^^ >> >> * The choice for time format is "yyyy-MM-dd HH:mm:ss" as it is already used in `Thread.print`. >> * `Thread.print` prints timestamp irrespectively from "-T" flag presence to preserve backwards compatibility. >> >> I haven't added a timestamp to the following diagnostic command: >> * `VM.uptime` - command run with `-date` argument will also print a timestamp; >> * `VM.system_properties` - as the output already lists a timestamp. Not sure if we need more timestamps here. >> * `Thread.dump_to_file` - the content dumped to a file already has a timestamp; > > Ivan Bereziuk 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 15 additional commits since the last revision: > > - remove TimeStamp::No as it's not used. virtual should be flipped to override in bulk (afressed clang warning) > - Merge branch 'master' into 8357828_add_timestamp_to_jcmd > - changes to jcmd.md > - undo changes to reorder_help_cmd() > - cleanup > - add timestamp to VM.version. Add test > - updated jcmd usage text > - undo the changes to the modified earlier tests as timestamp presence is fully backwards compatible > - introduce -T as a commong flag > - Merge branch 'master' into 8357828_add_timestamp_to_jcmd > - ... and 5 more: https://git.openjdk.org/jdk/compare/1e69e598...5f1cefe0 OK thanks, yes not changing all the dcmds in https://github.com/openjdk/jdk/pull/29325/files is nice. 8-) Regarding whether JCmd.java could do the timestamp, or we need to change the native side: Yes a problem there is the timestamp duplication issue: if JCmd can optionally print a timestamp as a header before running the command, that timestamp info is duplicated in Thread.print. But is it really that bad, and is it worth the extra argument processing? (In diagnosticFramework, we need to introduce parse_common options just for this one flag.) If JCmd.java does the timestamp: if you opt-in to JCmd with a timestamp, you would get the new timestamp in the new format, followed by the old Thread.print timestamp in its format... This avoids the new complexity in the native code, and keeps the new timestamp handling in the simple JCmd.java wrapper. It sidesteps the problem that Thread.print uses an arguably "wrong" format. (An in time, maybe Thread.print would migrate to not printing a timestamp.) (JCmd could optionally print a duration at the end as was hinted somewhere earlier. Heap dumping prints its own time taken, but few other commands consider it interesting.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3778803463 From kevinw at openjdk.org Wed Jan 21 15:30:14 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 21 Jan 2026 15:30:14 GMT Subject: RFR: 8359706: Add file descriptor count and maximum limit to VM.info [v7] In-Reply-To: References: Message-ID: <4K9-nveG7r0_S8x5ebJdAruuq6dCWa_VWDInEPn-36w=.b4cbb9e7-fe62-4156-953b-478b0f927d15@github.com> On Tue, 20 Jan 2026 19:47:24 GMT, Kieran Farrell wrote: >> src/hotspot/os/windows/os_windows.cpp line 6262: >> >>> 6260: >>> 6261: void os::print_open_file_descriptors(outputStream* st) { >>> 6262: // File descriptor counting not supported on Windows. >> >> If you said "not implemented" here and in the other comment, it might be clearer that somebody could implement these if they build and test it. Not supported sounds to me more like a reason we cannot do it. > > Windows doesn't support UNIX-style file descriptors hence using the word 'supported', I've updated the AIX stub to say 'not implemented' however. ah yes thanks. Not heard of a suggestion of printing a Windows HANDLE count so far. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27971#discussion_r2713088966 From kevinw at openjdk.org Wed Jan 21 15:39:39 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 21 Jan 2026 15:39:39 GMT Subject: RFR: 8359706: Add file descriptor count and maximum limit to VM.info [v8] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 19:53:41 GMT, Kieran Farrell wrote: >> 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 incrementally with one additional commit since the last revision: > > minor updates Looks good I think. We should update issue title and PR title to remove mention of maximum limit. ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27971#pullrequestreview-3687902195 From duke at openjdk.org Wed Jan 21 16:28:15 2026 From: duke at openjdk.org (Ivan Bereziuk) Date: Wed, 21 Jan 2026 16:28:15 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v3] In-Reply-To: References: Message-ID: > `jcmd` provides great diagnostics but many commands lack a timestamp in their output. > Adding a timestamp to the output of some would add value for those debugging JVM data. > > Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. > > With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-T": > > jcmd [pid | main-class] [-T] command... | PerfCounter.print | -f filename > ^^^^ > > * The choice for time format is "yyyy-MM-dd HH:mm:ss" as it is already used in `Thread.print`. > * `Thread.print` prints timestamp irrespectively from "-T" flag presence to preserve backwards compatibility. > > I haven't added a timestamp to the following diagnostic command: > * `VM.uptime` - command run with `-date` argument will also print a timestamp; > * `VM.system_properties` - as the output already lists a timestamp. Not sure if we need more timestamps here. > * `Thread.dump_to_file` - the content dumped to a file already has a timestamp; Ivan Bereziuk has updated the pull request incrementally with two additional commits since the last revision: - improve test. Assert new ISO 8601 format - handle timestamp in parse_and_execute(). Thread.print is exceptional. Add default initialation to JcmdOptions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27368/files - new: https://git.openjdk.org/jdk/pull/27368/files/5f1cefe0..c702901d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27368&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27368&range=01-02 Stats: 133 lines in 4 files changed: 19 ins; 101 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/27368.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27368/head:pull/27368 PR: https://git.openjdk.org/jdk/pull/27368 From shade at openjdk.org Wed Jan 21 16:41:39 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 21 Jan 2026 16:41:39 GMT Subject: RFR: 8373266: Strengthen constant CardTable base accesses [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 19:06:02 GMT, Aleksey Shipilev 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 > > 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 Egad. Merge brings lots of commits, let me fix that... ------------- PR Comment: https://git.openjdk.org/jdk/pull/28703#issuecomment-3779501971 From shade at openjdk.org Wed Jan 21 16:41:35 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 21 Jan 2026 16:41:35 GMT Subject: RFR: 8373266: Strengthen constant CardTable base accesses [v3] In-Reply-To: References: Message-ID: > 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 223 additional commits since the last revision: - Merge branch 'master' into JDK-8373266-cardtable-asserts - Some polishing - 8375544: JfrSet::clear should not use memset Reviewed-by: mgronlun - 8374998: Failing os::write - remove bad file Reviewed-by: mdoerr, lucy - 8375498: [VectorAPI] Dump primary vector IR details with -XX:+TraceNewVectors Reviewed-by: epeter - 8375717: Outdated link in jdk.jfr.internal.JVM javadoc Reviewed-by: egahlin - 8238686: G1 may waste lots of space or fail to uncommit when observing MinHeapFreeRatio during sizing after full gc Reviewed-by: tschatzl, sjohanss - 8375622: G1: Convert G1CodeRootSet to use Atomic Reviewed-by: shade, sjohanss - 8375787: compiler/vectorapi/TestCastShapeBadOpc.java fails with release VMs Reviewed-by: syan, lmesnik, fyang, epeter - 8375738: Fix -Wzero-as-null-pointer-constant warnings in MacOSX/bsd code Reviewed-by: erikj, dholmes - ... and 213 more: https://git.openjdk.org/jdk/compare/98c1f2a9...79dca36a ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28703/files - new: https://git.openjdk.org/jdk/pull/28703/files/040a84d7..79dca36a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28703&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28703&range=01-02 Stats: 65746 lines in 1352 files changed: 34023 ins; 12037 del; 19686 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 21 16:41:40 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 21 Jan 2026 16:41:40 GMT Subject: RFR: 8373266: Strengthen constant CardTable base accesses [v2] In-Reply-To: References: <2QXqO9Zb2qShuQP-r33WBSkM65HLMQsi5M3x_B0ELJc=.856e0673-41aa-4c45-95d4-c43b7993e488@github.com> Message-ID: On Wed, 21 Jan 2026 13:26:21 GMT, Thomas Schatzl wrote: >> src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp line 114: >> >>> 112: __ subptr(end, addr); // end --> cards count >>> 113: >>> 114: __ mov64(tmp, (intptr_t) ctbs->card_table_base_const()); >> >> Suggestion: >> >> __ mov64(tmp, (intptr_t)ctbs->card_table_base_const()); > > For consistency Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28703#discussion_r2713395841 From shade at openjdk.org Wed Jan 21 16:41:42 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 21 Jan 2026 16:41:42 GMT Subject: RFR: 8373266: Strengthen constant CardTable base accesses [v2] In-Reply-To: <2QXqO9Zb2qShuQP-r33WBSkM65HLMQsi5M3x_B0ELJc=.856e0673-41aa-4c45-95d4-c43b7993e488@github.com> References: <2QXqO9Zb2qShuQP-r33WBSkM65HLMQsi5M3x_B0ELJc=.856e0673-41aa-4c45-95d4-c43b7993e488@github.com> Message-ID: On Wed, 21 Jan 2026 13:26:39 GMT, Thomas Schatzl wrote: >> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 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 > > src/hotspot/os_cpu/linux_arm/javaThread_linux_arm.cpp line 47: > >> 45: if (bs->is_a(BarrierSet::CardTableBarrierSet)) { >> 46: CardTableBarrierSet* ctbs = CardTableBarrierSet::barrier_set(); >> 47: _card_table_base = (address) ctbs->card_table_base_const(); > > Suggestion: > > _card_table_base = (address)ctbs->card_table_base_const(); > > For consistency Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28703#discussion_r2713396310 From shade at openjdk.org Wed Jan 21 16:44:36 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 21 Jan 2026 16:44:36 GMT Subject: RFR: 8373266: Strengthen constant CardTable base accesses [v4] In-Reply-To: References: Message-ID: > 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 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 11 new commits since the last revision: - Some polishing - 8341496: Improve JMX connections Co-authored-by: Daniel Fuchs Reviewed-by: skoivu, rhalade, coffeys, dfuchs, kevinw, jnimeh - 8375342: jdk/javadoc/doccheck/checks/jdkCheckHtml.java failed with duplicate anchors Reviewed-by: alanb, iris - 8373836: add anchors to the java options in the java man page Reviewed-by: jwilhelm, iris - 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 - ... and 1 more: https://git.openjdk.org/jdk/compare/79dca36a...5c2206b9 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28703/files - new: https://git.openjdk.org/jdk/pull/28703/files/79dca36a..5c2206b9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28703&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28703&range=02-03 Stats: 23 lines in 1 file changed: 23 ins; 0 del; 0 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 21 16:47:43 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 21 Jan 2026 16:47:43 GMT Subject: RFR: 8373266: Strengthen constant CardTable base accesses [v5] In-Reply-To: References: Message-ID: > 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 refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Some polishing ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28703/files - new: https://git.openjdk.org/jdk/pull/28703/files/5c2206b9..db78bed3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28703&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28703&range=03-04 Stats: 23 lines in 1 file changed: 0 ins; 23 del; 0 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 epeter at openjdk.org Wed Jan 21 16:54:50 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 21 Jan 2026 16:54:50 GMT Subject: RFR: 8374807: Crash in MethodData::extra_data_lock()+0x0 when running -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp -version [v4] In-Reply-To: <17qmKHGiPNSNpHn2By-gtJjPpwFFDj98wiY-bQG16nY=.4df59ed3-8120-496b-9a1e-06b80c9149ae@github.com> References: <17qmKHGiPNSNpHn2By-gtJjPpwFFDj98wiY-bQG16nY=.4df59ed3-8120-496b-9a1e-06b80c9149ae@github.com> Message-ID: On Wed, 21 Jan 2026 13:52:52 GMT, Guanqiang Han wrote: >> test/hotspot/jtreg/compiler/uncommontrap/TestPrintDiagnosticsWithoutProfileTraps.java line 32: >> >>> 30: * @run main/othervm -XX:+TraceDeoptimization -XX:-ProfileTraps >>> 31: * -XX:-TieredCompilation -Xcomp >>> 32: * compiler.uncommontrap.TestPrintDiagnosticsWithoutProfileTraps >> >> `TraceDeoptimization` is a diagnostic flag. This test will cause issues without `-XX:+UnlockDiagnosticVMOptions`, right? And `ProfileTraps` is debug. So won't this need `-XX:+IgnoreUnrecognizedVMOptions`? >> >> @iwanowww Did you already run testing on this patch or should I run some? > > Hi @eme64 , thanks for the comments. > > I think we don?t need to add -XX:+UnlockDiagnosticVMOptions or -XX:+IgnoreUnrecognizedVMOptions here, because the test is guarded by @requires vm.debug. In debug builds, UnlockDiagnosticVMOptions is enabled by default (trueInDebug), so diagnostic flags like TraceDeoptimization are already unlocked, and ProfileTraps (a develop flag) is also available/recognized. > > https://github.com/openjdk/jdk/blob/983ae96f60c935aa52f482d21ae6a0d947679541/src/hotspot/share/runtime/globals.hpp#L172-L173 > > https://github.com/openjdk/jdk/blob/983ae96f60c935aa52f482d21ae6a0d947679541/src/hotspot/share/runtime/globals.hpp#L1188-L1189 @hgqxjj Hmm I see. I'm not a fan of using `@requires vm.debug`, because it means that your test is not run in product, and sometimes bugs only show up in product. It's also not great that we have to run a whole JVM startup with `-Xcomp`, compiling EVERYTHING, and blocking for every compilation. We should only use `-Xcomp` in combination with a fairly restricted `compileonly`. Otherwise, we just waste a lot of compute resources. @iwanowww What is your opinion on this? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29147#discussion_r2713463904 From duke at openjdk.org Wed Jan 21 16:54:57 2026 From: duke at openjdk.org (Ivan Bereziuk) Date: Wed, 21 Jan 2026 16:54:57 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: References: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> Message-ID: On Wed, 21 Jan 2026 15:24:15 GMT, Kevin Walls wrote: >> Ivan Bereziuk 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 15 additional commits since the last revision: >> >> - remove TimeStamp::No as it's not used. virtual should be flipped to override in bulk (afressed clang warning) >> - Merge branch 'master' into 8357828_add_timestamp_to_jcmd >> - changes to jcmd.md >> - undo changes to reorder_help_cmd() >> - cleanup >> - add timestamp to VM.version. Add test >> - updated jcmd usage text >> - undo the changes to the modified earlier tests as timestamp presence is fully backwards compatible >> - introduce -T as a commong flag >> - Merge branch 'master' into 8357828_add_timestamp_to_jcmd >> - ... and 5 more: https://git.openjdk.org/jdk/compare/e81dffc4...5f1cefe0 > > OK thanks, yes not changing all the dcmds in https://github.com/openjdk/jdk/pull/29325/files is nice. 8-) > > > Regarding whether JCmd.java could do the timestamp, or we need to change the native side: > Yes a problem there is the timestamp duplication issue: if JCmd can optionally print a timestamp as a header before running the command, that timestamp info is duplicated in Thread.print. > > But is it really that bad, and is it worth the extra argument processing? > (In diagnosticFramework, we need to introduce parse_common options just for this one flag.) > > If JCmd.java does the timestamp: if you opt-in to JCmd with a timestamp, you would get the new timestamp in the new format, followed by the old Thread.print timestamp in its format... > This avoids the new complexity in the native code, and keeps the new timestamp handling in the simple JCmd.java wrapper. > It sidesteps the problem that Thread.print uses an arguably "wrong" format. > (An in time, maybe Thread.print would migrate to not printing a timestamp.) > > > (JCmd could optionally print a duration at the end as was hinted somewhere earlier. > Heap dumping prints its own time taken, but few other commands consider it interesting.) @kevinjwalls > not changing all the dcmds in https://github.com/openjdk/jdk/pull/29325/files is nice. 8-) Yes. That is indeed an option to consider. In here * I've removed "print timestamp" handling from `DCmd::execute()`. Now it's handled in `DCmd::Executor::parse_and_execute()`. The additional parameter passed to `DCmd::execute` serves the only purpose - let `Thread.print` dcmd be backwards compatible and print a "timestamp" of old format when "-T" flag was passed. * I have also embraced an ISO 8601 format. Example `2026-01-21T16:58:49.518+0100`; Alan, David, thank you. It might be fine to keep framework of "common jcmd flags" in place. Executors would need to know about "-format=json" if that becomes a common flag in the future. Other than that, it might be fine to let "Thread.print" print two timestamps which will make the implementation simpler: https://github.com/openjdk/jdk/pull/29325 Q: what would be best name for the flag. Currently it's "-T". Should we use a different name? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3779616328 From shade at openjdk.org Wed Jan 21 17:35:58 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 21 Jan 2026 17:35:58 GMT Subject: RFR: 8373266: Strengthen constant CardTable base accesses [v2] In-Reply-To: <2QXqO9Zb2qShuQP-r33WBSkM65HLMQsi5M3x_B0ELJc=.856e0673-41aa-4c45-95d4-c43b7993e488@github.com> References: <2QXqO9Zb2qShuQP-r33WBSkM65HLMQsi5M3x_B0ELJc=.856e0673-41aa-4c45-95d4-c43b7993e488@github.com> Message-ID: On Wed, 21 Jan 2026 13:28:39 GMT, Thomas Schatzl wrote: > Looks good apart from minor nits (extra spaces). Sorry for taking so long. No problem, thanks for looking! This is not urgent, one of those "safety in depth" fixes, really. Refixed the PR after borked merge. Re-ran `hotspot_gc` without issues. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28703#issuecomment-3779958493 From duke at openjdk.org Wed Jan 21 18:48:45 2026 From: duke at openjdk.org (Larry Cable) Date: Wed, 21 Jan 2026 18:48:45 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v10] In-Reply-To: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: > 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: fixed initialization bug in AOT cache sharing summary code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29048/files - new: https://git.openjdk.org/jdk/pull/29048/files/3efe6afc..341643a2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=08-09 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 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 drwhite at openjdk.org Wed Jan 21 22:10:13 2026 From: drwhite at openjdk.org (Derek White) Date: Wed, 21 Jan 2026 22:10:13 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v13] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 20:14:31 GMT, Srinivas Vamsi Parasa 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: > > Update ALL of ArraysFill JMH micro I'm expecting to see a small regression in a write-only fill, and a larger improvement in write+read fill, but we didn't present the data in a way that makes it easy to compare those two tests. So we should present the graphed data as a table as well. Then we can discuss how common the write+read fill case is. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3781378167 From duke at openjdk.org Thu Jan 22 00:56:42 2026 From: duke at openjdk.org (Chad Rakoczy) Date: Thu, 22 Jan 2026 00:56:42 GMT Subject: RFR: 8374513: AArch64: Improve receiver type profiling reliability [v2] In-Reply-To: References: Message-ID: > [JDK-8374513](https://bugs.openjdk.org/browse/JDK-8374513) is the AArch64 port of [JDK-8357258](https://bugs.openjdk.org/browse/JDK-8357258). See the bug report for more detailed information. > > This PR executes the plan outlined in the bug: > - Common the receiver type profiling code in interpreter and C1 > - Rewrite receiver type profiling code to only do atomic receiver slot installations > - 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. > > Functional Testing: Linux AArch64 fastdebug Tier1-4 > > Performance Testing (to show there is no performance regression): > > # Baseline > Benchmark (randomized) Mode Cnt Score Error Units > InterfaceCalls.test1stInt2Types false avgt 12 1.940 ? 0.002 ns/op > InterfaceCalls.test1stInt2Types true avgt 12 7.714 ? 0.011 ns/op > InterfaceCalls.test1stInt3Types false avgt 12 6.747 ? 0.066 ns/op > InterfaceCalls.test1stInt3Types true avgt 12 18.733 ? 0.175 ns/op > InterfaceCalls.test1stInt5Types false avgt 12 6.690 ? 0.083 ns/op > InterfaceCalls.test1stInt5Types true avgt 12 21.299 ? 0.016 ns/op > InterfaceCalls.test2ndInt2Types false avgt 12 1.997 ? 0.004 ns/op > InterfaceCalls.test2ndInt2Types true avgt 12 8.027 ? 0.016 ns/op > InterfaceCalls.test2ndInt3Types false avgt 12 7.915 ? 0.114 ns/op > InterfaceCalls.test2ndInt3Types true avgt 12 16.988 ? 0.065 ns/op > InterfaceCalls.test2ndInt5Types false avgt 12 9.422 ? 0.017 ns/op > InterfaceCalls.test2ndInt5Types true avgt 12 22.736 ? 0.022 ns/op > InterfaceCalls.testIfaceCall false avgt 12 5.860 ? 0.046 ns/op > InterfaceCalls.testIfaceCall true avgt 12 5.794 ? 0.026 ns/op > InterfaceCalls.testIfaceExtCall false avgt 12 6.310 ? 0.067 ns/op > InterfaceCalls.testIfaceExtCall true avgt 12 6.239 ? 0.017 ns/op > InterfaceCalls.testMonomorphic false avgt 12 1.146 ? 0.034 ns/op > InterfaceCalls.testMonomorphic true avgt 12 1.131 ? 0.012 ns/op > > # With PR > Benchmark (randomized) Mode Cnt Score Error Units > InterfaceCalls.test1stInt2Types false avgt 12 1.941 ? 0.004 ns/op > InterfaceCalls.test1stIn... Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision: Use increment macro ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29283/files - new: https://git.openjdk.org/jdk/pull/29283/files/ba4f4222..555e0afa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29283&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29283&range=00-01 Stats: 19 lines in 1 file changed: 1 ins; 4 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/29283.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29283/head:pull/29283 PR: https://git.openjdk.org/jdk/pull/29283 From duke at openjdk.org Thu Jan 22 00:56:42 2026 From: duke at openjdk.org (Chad Rakoczy) Date: Thu, 22 Jan 2026 00:56:42 GMT Subject: RFR: 8374513: AArch64: Improve receiver type profiling reliability [v2] In-Reply-To: References: <5PYC9r4vV6IGhaXfhDFyBmpXds1v6dcAyFYv5SXs0g4=.f8632c92-44fe-4431-80ee-bbc816453145@github.com> Message-ID: On Tue, 20 Jan 2026 10:09:31 GMT, Aleksey Shipilev wrote: >> ... then we're good to go. > > Oh, there is `increment`, nice. There is another counter-update shortcut near `// Corner case: no profile table. Increment poly counter and exit.`, update that one too. `increment` uses `rscratch1` so I had to update the offset register to be `rscratch2` instead. `rscratch2` still needs to be used to hold the destination address for the CAS (since it also uses `rscratch1`) so I updated the comment accordingly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29283#discussion_r2714906967 From pchilanomate at openjdk.org Thu Jan 22 01:17:28 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 22 Jan 2026 01:17:28 GMT Subject: RFR: 8369238: Allow virtual thread preemption on some common class initialization paths [v15] In-Reply-To: <4hRNhuxziLbGiy8BIhN7Be3NlQ6cOckUF_earAzDDnU=.f00c5720-557f-4b34-b643-b9313cdf7afc@github.com> References: <4hRNhuxziLbGiy8BIhN7Be3NlQ6cOckUF_earAzDDnU=.f00c5720-557f-4b34-b643-b9313cdf7afc@github.com> Message-ID: On Wed, 21 Jan 2026 02:58:33 GMT, He-Pin(kerr) wrote: > Will this be backported to Java 25 LTS? > No plans to backport it. Feel free to follow up on the loom-dev mailing list instead (see https://mail.openjdk.org/pipermail/loom-dev/2025-November/008039.html). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27802#issuecomment-3781955460 From dholmes at openjdk.org Thu Jan 22 01:44:04 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 22 Jan 2026 01:44:04 GMT Subject: RFR: 8353564: Fail fatally if os::release_memory or os::uncommit_memory fails In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 23:30:14 GMT, Robert Toyonaga wrote: > This PR is a follow up to JDK-8341491. See original discussion: https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700 > > This PR makes `os::release_memory`, `os::uncommit_memory`, `os::release_memory_special`, and `os::unmap_memory` fail fatally if they encounter an error. These methods require obtaining the NMT lock. Fatally failing in these places would potentially allow for the tightening of NMT virtual memory locking scopes (future work, if this PR is accepted). Already in most cases, the callers fail fatally or assert(false) when these os:: methods fail. Another reason to fatally fail is that if the OS memory operation fails, it can be difficult to know for sure what state the OS left the memory in and recover. > > `release_memory`/`uncommit_memory`/`release_memory_special`/`unmap_memory` can fail due to ? Bad arguments, or ? The OS encountered an issue out of control of the JVM. > > ? > If there is a JVM bug, it's probably reasonable to fatally fail here. Or the caller could be intentionally passing arguments that may or may not be valid. I don't think there is any code like that currently, and this is probably a bad pattern to be following anyway. > > ? > In platform dependent code: > With regard to mmap/munmap, the only errors that aren't due to bad arguments are ENOMEM and ones related to file descriptors (which are not applicable to uncommit or release). > On Windows, VirtualFree only fails due to bad arguments. > On AIX, shmdt and disclaim64 only fail due to bad arguments. msync could spontaneously fail with EIO: "An I/O error occurred while reading from or writing to the file system." > On BSD, it seems like mprotect and madvise fail only due to bad arguments or invalid privileges. > > In the [original discussion](https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700), the main question was whether ENOMEM upon os::uncommit_memory was recoverable. This may be possible if we uncommit the middle of a region - splitting it in two. This could exceed the limit of the number of mappings resulting in ENOMEM. > > If none of the scenarios in ? are recoverable, then perhaps fatally failing is OK. > > Testing: > - Tier 1. > - Manual testing to make sure we fatally fail and the correct messages are printed. I don't have an opinion on whether these methods failing are recoverable or not in general but I don't think failing to remove stack guard pages is a fatal error. And changing the API so that the callers can prepare (if necessary) and pass in an error message, does make me cringe somewhat. >From an API perspective I don't think the leaf methods should be making the call on what is and what is not recoverable. That should be handled at the level where there is more context. ------------- PR Review: https://git.openjdk.org/jdk/pull/29240#pullrequestreview-3690200251 From dholmes at openjdk.org Thu Jan 22 01:51:17 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 22 Jan 2026 01:51:17 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: References: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> Message-ID: On Wed, 21 Jan 2026 16:51:17 GMT, Ivan Bereziuk wrote: > Q: what would be best name for the flag. Currently it's "-T". Should we use a different name? Lowercase `-t` seems more consistent with other options ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3782041944 From ghan at openjdk.org Thu Jan 22 01:56:52 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 22 Jan 2026 01:56:52 GMT Subject: RFR: 8374807: Crash in MethodData::extra_data_lock()+0x0 when running -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp -version [v4] In-Reply-To: References: <17qmKHGiPNSNpHn2By-gtJjPpwFFDj98wiY-bQG16nY=.4df59ed3-8120-496b-9a1e-06b80c9149ae@github.com> Message-ID: <5YSsP2h52Kp9WWb4YrthjtYSziRKM5FM3s5NHThrPTg=.8be8a6fc-e841-4e7b-b9d5-e3910c9bc2e6@github.com> On Wed, 21 Jan 2026 16:51:48 GMT, Emanuel Peter wrote: >> Hi @eme64 , thanks for the comments. >> >> I think we don?t need to add -XX:+UnlockDiagnosticVMOptions or -XX:+IgnoreUnrecognizedVMOptions here, because the test is guarded by @requires vm.debug. In debug builds, UnlockDiagnosticVMOptions is enabled by default (trueInDebug), so diagnostic flags like TraceDeoptimization are already unlocked, and ProfileTraps (a develop flag) is also available/recognized. >> >> https://github.com/openjdk/jdk/blob/983ae96f60c935aa52f482d21ae6a0d947679541/src/hotspot/share/runtime/globals.hpp#L172-L173 >> >> https://github.com/openjdk/jdk/blob/983ae96f60c935aa52f482d21ae6a0d947679541/src/hotspot/share/runtime/globals.hpp#L1188-L1189 > > @hgqxjj Hmm I see. I'm not a fan of using `@requires vm.debug`, because it means that your test is not run in product, and sometimes bugs only show up in product. > > It's also not great that we have to run a whole JVM startup with `-Xcomp`, compiling EVERYTHING, and blocking for every compilation. We should only use `-Xcomp` in combination with a fairly restricted `compileonly`. Otherwise, we just waste a lot of compute resources. > > @iwanowww What is your opinion on this? @eme64 Thanks for the feedback. On @requires vm.debug: I?d like to keep it for this reproducer. ProfileTraps is the key knob here: the failure requires ProfileTraps=false (create_if_missing = ProfileTraps, so get_method_data(..., false) may return NULL). Since ProfileTraps is a develop_pd flag and not settable on product builds, this reproducer has to run on a non-product VM (i.e., a debug VM). On -Xcomp: agreed. I?ll keep it but restrict it with -XX:CompileCommand=compileonly,... so we only compile the relevant method(s). If that sounds reasonable, I?ll proceed with just the compileonly tightening. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29147#discussion_r2715016925 From duke at openjdk.org Thu Jan 22 06:27:46 2026 From: duke at openjdk.org (duke) Date: Thu, 22 Jan 2026 06:27:46 GMT Subject: Withdrawn: 8308776: [AArch64] Math.log is 10% slower than StrictMath.log on aarch64 In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 20:41:56 GMT, Dhamoder Nalla wrote: > This PR Introduces an optimized AArch64 intrinsic for Math.log using reciprocal refinement and a table-driven polynomial. > Improves throughput for double logarithms while preserving IEEE-754 corner case behavior (?0, subnormals, negatives, NaN). > > > > The micro-benchmark results from MathBench and StrictMathBench below show the performance improvement of Math.log: > > > **Before change** > xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" > xmlns="http://www.w3.org/TR/REC-html40"> > > > > > > > > > > >
> >
> >
> >
> > Benchmark | Mode | Cnt | Score | Error | Units > -- | -- | -- | -- | -- | -- > MathBench.logDouble | thrpt | 10 | **15549.705** | ?357.439 | ops/ms > StrictMathBench.logDouble | thrpt | 10 | 219408.158 | ?16484.680 | ops/ms > >
> >
> >
> >
> > > > > > > > > **After adding Math.log intrinsic** > > xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" > xmlns="http://www.w3.org/TR/REC-html40"> > > > > > > > > > > >
> >
> >
> >
> > Benchmark | Mode | Cnt | Score | Error | Units > -- | -- | -- | -- | -- | -- > MathBench.logDouble | thrpt | 10 | **300086.773** | ?6675.936 | ops/ms > StrictMathBench.logDouble | thrpt | 10 | 226521.817 | ?4038.975 | ops/ms > > >
> >
> >
> >
> > > > > This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/28306 From jbhateja at openjdk.org Thu Jan 22 08:17:55 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 22 Jan 2026 08:17:55 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v10] In-Reply-To: References: Message-ID: > Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction. > It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails. > > Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java). > > Vector API jtreg tests pass at AVX level 2, remaining validation in progress. > > Performance numbers: > > > System : 13th Gen Intel(R) Core(TM) i3-1315U > > Baseline: > Benchmark (size) Mode Cnt Score Error Units > VectorSliceBenchmark.byteVectorSliceWithConstantIndex1 1024 thrpt 2 9444.444 ops/ms > VectorSliceBenchmark.byteVectorSliceWithConstantIndex2 1024 thrpt 2 10009.319 ops/ms > VectorSliceBenchmark.byteVectorSliceWithVariableIndex 1024 thrpt 2 9081.926 ops/ms > VectorSliceBenchmark.intVectorSliceWithConstantIndex1 1024 thrpt 2 6085.825 ops/ms > VectorSliceBenchmark.intVectorSliceWithConstantIndex2 1024 thrpt 2 6505.378 ops/ms > VectorSliceBenchmark.intVectorSliceWithVariableIndex 1024 thrpt 2 6204.489 ops/ms > VectorSliceBenchmark.longVectorSliceWithConstantIndex1 1024 thrpt 2 1651.334 ops/ms > VectorSliceBenchmark.longVectorSliceWithConstantIndex2 1024 thrpt 2 1642.784 ops/ms > VectorSliceBenchmark.longVectorSliceWithVariableIndex 1024 thrpt 2 1474.808 ops/ms > VectorSliceBenchmark.shortVectorSliceWithConstantIndex1 1024 thrpt 2 10399.394 ops/ms > VectorSliceBenchmark.shortVectorSliceWithConstantIndex2 1024 thrpt 2 10502.894 ops/ms > VectorSliceBenchmark.shortVectorSliceWithVariableIndex 1024 ... Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762 - Review comments resolutions - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762 - Update callGenerator.hpp copyright year - Review comments resolution - Cleanups - Review comments resolutions - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762 - Updating predicate checks - Fixes for failing regressions - ... and 4 more: https://git.openjdk.org/jdk/compare/0f4d7750...4b807102 ------------- Changes: https://git.openjdk.org/jdk/pull/24104/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=09 Stats: 1350 lines in 29 files changed: 1247 ins; 2 del; 101 mod Patch: https://git.openjdk.org/jdk/pull/24104.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24104/head:pull/24104 PR: https://git.openjdk.org/jdk/pull/24104 From jbhateja at openjdk.org Thu Jan 22 08:17:57 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 22 Jan 2026 08:17:57 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v2] In-Reply-To: <1Vs8Ud-yh7FtFJN9sddNXDVM6Mc0ue9oi_oa0w5pRzU=.022172f3-1622-4d05-888b-c7afc66a5254@github.com> References: <1Vs8Ud-yh7FtFJN9sddNXDVM6Mc0ue9oi_oa0w5pRzU=.022172f3-1622-4d05-888b-c7afc66a5254@github.com> Message-ID: On Mon, 11 Aug 2025 03:07:13 GMT, Xiaohong Gong wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Updating predicate checks > > Thanks for your work @jatin-bhateja! This PR also provides help on AArch64 that we also have plan to do the same intrinsifaction in our side. Hi @XiaohongGong , @eme64 , Let me know if you have comments / suggestions here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3783097561 From jbhateja at openjdk.org Thu Jan 22 08:31:30 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 22 Jan 2026 08:31:30 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v11] In-Reply-To: References: Message-ID: > Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction. > It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails. > > Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java). > > Vector API jtreg tests pass at AVX level 2, remaining validation in progress. > > Performance numbers: > > > System : 13th Gen Intel(R) Core(TM) i3-1315U > > Baseline: > Benchmark (size) Mode Cnt Score Error Units > VectorSliceBenchmark.byteVectorSliceWithConstantIndex1 1024 thrpt 2 9444.444 ops/ms > VectorSliceBenchmark.byteVectorSliceWithConstantIndex2 1024 thrpt 2 10009.319 ops/ms > VectorSliceBenchmark.byteVectorSliceWithVariableIndex 1024 thrpt 2 9081.926 ops/ms > VectorSliceBenchmark.intVectorSliceWithConstantIndex1 1024 thrpt 2 6085.825 ops/ms > VectorSliceBenchmark.intVectorSliceWithConstantIndex2 1024 thrpt 2 6505.378 ops/ms > VectorSliceBenchmark.intVectorSliceWithVariableIndex 1024 thrpt 2 6204.489 ops/ms > VectorSliceBenchmark.longVectorSliceWithConstantIndex1 1024 thrpt 2 1651.334 ops/ms > VectorSliceBenchmark.longVectorSliceWithConstantIndex2 1024 thrpt 2 1642.784 ops/ms > VectorSliceBenchmark.longVectorSliceWithVariableIndex 1024 thrpt 2 1474.808 ops/ms > VectorSliceBenchmark.shortVectorSliceWithConstantIndex1 1024 thrpt 2 10399.394 ops/ms > VectorSliceBenchmark.shortVectorSliceWithConstantIndex2 1024 thrpt 2 10502.894 ops/ms > VectorSliceBenchmark.shortVectorSliceWithVariableIndex 1024 ... Jatin Bhateja has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24104/files - new: https://git.openjdk.org/jdk/pull/24104/files/4b807102..2c7eb96d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=09-10 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24104.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24104/head:pull/24104 PR: https://git.openjdk.org/jdk/pull/24104 From shade at openjdk.org Thu Jan 22 08:44:59 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 22 Jan 2026 08:44:59 GMT Subject: RFR: 8374513: AArch64: Improve receiver type profiling reliability [v2] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 00:56:42 GMT, Chad Rakoczy wrote: >> [JDK-8374513](https://bugs.openjdk.org/browse/JDK-8374513) is the AArch64 port of [JDK-8357258](https://bugs.openjdk.org/browse/JDK-8357258). See the bug report for more detailed information. >> >> This PR executes the plan outlined in the bug: >> - Common the receiver type profiling code in interpreter and C1 >> - Rewrite receiver type profiling code to only do atomic receiver slot installations >> - 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. >> >> Functional Testing: Linux AArch64 fastdebug Tier1-4 >> >> Performance Testing (to show there is no performance regression): >> >> # Baseline >> Benchmark (randomized) Mode Cnt Score Error Units >> InterfaceCalls.test1stInt2Types false avgt 12 1.940 ? 0.002 ns/op >> InterfaceCalls.test1stInt2Types true avgt 12 7.714 ? 0.011 ns/op >> InterfaceCalls.test1stInt3Types false avgt 12 6.747 ? 0.066 ns/op >> InterfaceCalls.test1stInt3Types true avgt 12 18.733 ? 0.175 ns/op >> InterfaceCalls.test1stInt5Types false avgt 12 6.690 ? 0.083 ns/op >> InterfaceCalls.test1stInt5Types true avgt 12 21.299 ? 0.016 ns/op >> InterfaceCalls.test2ndInt2Types false avgt 12 1.997 ? 0.004 ns/op >> InterfaceCalls.test2ndInt2Types true avgt 12 8.027 ? 0.016 ns/op >> InterfaceCalls.test2ndInt3Types false avgt 12 7.915 ? 0.114 ns/op >> InterfaceCalls.test2ndInt3Types true avgt 12 16.988 ? 0.065 ns/op >> InterfaceCalls.test2ndInt5Types false avgt 12 9.422 ? 0.017 ns/op >> InterfaceCalls.test2ndInt5Types true avgt 12 22.736 ? 0.022 ns/op >> InterfaceCalls.testIfaceCall false avgt 12 5.860 ? 0.046 ns/op >> InterfaceCalls.testIfaceCall true avgt 12 5.794 ? 0.026 ns/op >> InterfaceCalls.testIfaceExtCall false avgt 12 6.310 ? 0.067 ns/op >> InterfaceCalls.testIfaceExtCall true avgt 12 6.239 ? 0.017 ns/op >> InterfaceCalls.testMonomorphic false avgt 12 1.146 ? 0.034 ns/op >> InterfaceCalls.testMonomorphic true avgt 12 1.131 ? 0.012 ns/op >> >> # With PR >> Benchmark (randomized) Mode Cnt Score Error Units >> InterfaceCalls.test1stInt2Type... > > Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision: > > Use increment macro Still looks reasonable. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29283#pullrequestreview-3691248807 From jsjolen at openjdk.org Thu Jan 22 08:55:20 2026 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 22 Jan 2026 08:55:20 GMT Subject: RFR: 8375621: Move RBTree implementation to inline file to minimize included headers [v2] In-Reply-To: <4hLWUjpXJ-fYlsn466_sFodxOd2TKENSid4qSI66eJU=.b9b0d3fb-1c5c-4d72-836f-ec7d71c66d11@github.com> References: <4hLWUjpXJ-fYlsn466_sFodxOd2TKENSid4qSI66eJU=.b9b0d3fb-1c5c-4d72-836f-ec7d71c66d11@github.com> Message-ID: <3VLdCznCpFuNh7G_FraHTJPZY-5doiG7KUYm_oMEiKE=.597a0062-37ce-480c-859b-305d08adc1aa@github.com> On Mon, 19 Jan 2026 14:54:32 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> The red-black tree implementation is split across `rbTree.hpp` and `rbTree.inline.hpp`. Some small `AbstractRBTree` functions are kept in `rbTree.hpp`, and also all of `RBTree`'s implementation. This makes the file less readable and requires extra header inclusions, notably the `os` class, which in turn includes additional unnecessary dependancies. >> >> In this PR I have moved all implementation code `rbTree.inline.hpp` instead. As a result, `rbTree.hpp` now only contains declarations, making it cleaner and limiting header inclusions to what is strictly necessary. Implementation-specific headers are now only included in the inline file. >> >> Additionally, I changed `RBTreeCHeapAllocator` to use `AllocateHeap`/`FreeHeap` from `allocation` instead of `os::malloc`/`os::free`, which allows us to get rid of the `os` dependancy altogether. >> >> Note: This PR is dependant on #29082, which adds arena-style tree allocators, which this PR then moves to the inline file. >> >> Testing: >> - Oracle tiers 1-5 > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > feedback fixes Marked as reviewed by jsjolen (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29295#pullrequestreview-3691288585 From jsjolen at openjdk.org Thu Jan 22 08:55:23 2026 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 22 Jan 2026 08:55:23 GMT Subject: RFR: 8375621: Move RBTree implementation to inline file to minimize included headers [v2] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 14:59:37 GMT, Casper Norrbin wrote: >> src/hotspot/share/utilities/rbTree.hpp line 68: >> >>> 66: class outputStream; >>> 67: class Arena; >>> 68: class ResourceArea; >> >> Brownie points if you also sort the forward declarations. > > The forward declarations are required by the Arena/ResourceArea allocator classes, so they would need to stay as it is currently. Since all definitions are in `rbTree.hpp`, we need to keep them for now. We could perhaps split up the various tree variants into a separate file, but I feel that would be out of scope here. Sort as in outputStream should go after Arena because A < O in the alphabet, is what I reckon Stefan meant. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29295#discussion_r2715908545 From cnorrbin at openjdk.org Thu Jan 22 09:06:06 2026 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 22 Jan 2026 09:06:06 GMT Subject: RFR: 8375621: Move RBTree implementation to inline file to minimize included headers [v3] In-Reply-To: References: Message-ID: > Hi everyone, > > The red-black tree implementation is split across `rbTree.hpp` and `rbTree.inline.hpp`. Some small `AbstractRBTree` functions are kept in `rbTree.hpp`, and also all of `RBTree`'s implementation. This makes the file less readable and requires extra header inclusions, notably the `os` class, which in turn includes additional unnecessary dependancies. > > In this PR I have moved all implementation code `rbTree.inline.hpp` instead. As a result, `rbTree.hpp` now only contains declarations, making it cleaner and limiting header inclusions to what is strictly necessary. Implementation-specific headers are now only included in the inline file. > > Additionally, I changed `RBTreeCHeapAllocator` to use `AllocateHeap`/`FreeHeap` from `allocation` instead of `os::malloc`/`os::free`, which allows us to get rid of the `os` dependancy altogether. > > Note: This PR is dependant on #29082, which adds arena-style tree allocators, which this PR then moves to the inline file. > > Testing: > - Oracle tiers 1-5 Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: sort forward declarations ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29295/files - new: https://git.openjdk.org/jdk/pull/29295/files/89521527..1d6f28bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29295&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29295&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29295.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29295/head:pull/29295 PR: https://git.openjdk.org/jdk/pull/29295 From cnorrbin at openjdk.org Thu Jan 22 09:06:08 2026 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 22 Jan 2026 09:06:08 GMT Subject: RFR: 8375621: Move RBTree implementation to inline file to minimize included headers [v3] In-Reply-To: References: Message-ID: <8yPTCbHN0yfh3glKoZv3thJLVcxG75yrKKFlbWfZnB8=.57f38206-4e50-4786-b9af-2092ca48c597@github.com> On Thu, 22 Jan 2026 08:52:58 GMT, Johan Sj?len wrote: >> The forward declarations are required by the Arena/ResourceArea allocator classes, so they would need to stay as it is currently. Since all definitions are in `rbTree.hpp`, we need to keep them for now. We could perhaps split up the various tree variants into a separate file, but I feel that would be out of scope here. > > Sort as in outputStream should go after Arena because A < O in the alphabet, is what I reckon Stefan meant. That makes more sense. Fixed now :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29295#discussion_r2715937107 From dlong at openjdk.org Thu Jan 22 09:07:09 2026 From: dlong at openjdk.org (Dean Long) Date: Thu, 22 Jan 2026 09:07:09 GMT Subject: RFR: 8373343: C2: verify AddP base input only set for heap addresses [v6] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 15:32:07 GMT, Roland Westrelin 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 15 additional commits since the last revision: > > - Merge branch 'master' into JDK-8373343 > - Update src/hotspot/share/opto/macroArrayCopy.cpp > > Co-authored-by: Dean Long <17332032+dean-long at users.noreply.github.com> > - more > - more > - review > - Merge branch 'master' into JDK-8373343 > - review > - review > - review > - merge > - ... and 5 more: https://git.openjdk.org/jdk/compare/1343aafa...2f618436 Marked as reviewed by dlong (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28769#pullrequestreview-3691365766 From xgong at openjdk.org Thu Jan 22 09:45:30 2026 From: xgong at openjdk.org (Xiaohong Gong) Date: Thu, 22 Jan 2026 09:45:30 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v11] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 08:31:30 GMT, Jatin Bhateja wrote: >> Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction. >> It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails. >> >> Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java). >> >> Vector API jtreg tests pass at AVX level 2, remaining validation in progress. >> >> Performance numbers: >> >> >> System : 13th Gen Intel(R) Core(TM) i3-1315U >> >> Baseline: >> Benchmark (size) Mode Cnt Score Error Units >> VectorSliceBenchmark.byteVectorSliceWithConstantIndex1 1024 thrpt 2 9444.444 ops/ms >> VectorSliceBenchmark.byteVectorSliceWithConstantIndex2 1024 thrpt 2 10009.319 ops/ms >> VectorSliceBenchmark.byteVectorSliceWithVariableIndex 1024 thrpt 2 9081.926 ops/ms >> VectorSliceBenchmark.intVectorSliceWithConstantIndex1 1024 thrpt 2 6085.825 ops/ms >> VectorSliceBenchmark.intVectorSliceWithConstantIndex2 1024 thrpt 2 6505.378 ops/ms >> VectorSliceBenchmark.intVectorSliceWithVariableIndex 1024 thrpt 2 6204.489 ops/ms >> VectorSliceBenchmark.longVectorSliceWithConstantIndex1 1024 thrpt 2 1651.334 ops/ms >> VectorSliceBenchmark.longVectorSliceWithConstantIndex2 1024 thrpt 2 1642.784 ops/ms >> VectorSliceBenchmark.longVectorSliceWithVariableIndex 1024 thrpt 2 1474.808 ops/ms >> VectorSliceBenchmark.shortVectorSliceWithConstantIndex1 1024 thrpt 2 10399.394 ops/ms >> VectorSliceBenchmark.shortVectorSliceWithConstantIndex2 1024 thrpt 2 10502.894 ops/ms >> VectorSliceB... > > Jatin Bhateja has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762 Overall, looks good to me; I?ve just left a few minor comments. src/hotspot/share/opto/vectorIntrinsics.cpp line 1712: > 1710: log_if_needed(" ** vector slice from non-constant index not supported"); > 1711: return false; > 1712: } Is it better floating this check up to an earlier line? Maybe followed line-1704 or merged into line-1689. src/hotspot/share/opto/vectornode.cpp line 2440: > 2438: > 2439: Node* VectorSliceNode::Identity(PhaseGVN* phase) { > 2440: if (origin()->is_Con()) { `origin` must be a constant now? src/hotspot/share/opto/vectornode.cpp line 2443: > 2441: jint index = origin()->get_int(); > 2442: uint vlen = vect_type()->length_in_bytes(); > 2443: if (vlen == (uint)index) { Suggestion: if (vlen == (uint) index) { src/hotspot/share/opto/vectornode.hpp line 1697: > 1695: class VectorSliceNode : public VectorNode { > 1696: public: > 1697: VectorSliceNode(Node* vec1, Node* vec2, Node* origin, const TypeVect* vt) Do we need an assertion for `origin` which is always a constant ? src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatVector.java line 2173: > 2171: FloatVector slice(int origin, Vector v1); > 2172: > 2173: Revert this new added blank line? ------------- PR Review: https://git.openjdk.org/jdk/pull/24104#pullrequestreview-3691494636 PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2716077178 PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2716083174 PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2716080787 PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2716090510 PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2716094647 From stefank at openjdk.org Thu Jan 22 09:51:49 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 22 Jan 2026 09:51:49 GMT Subject: RFR: 8375621: Move RBTree implementation to inline file to minimize included headers [v3] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 09:06:06 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> The red-black tree implementation is split across `rbTree.hpp` and `rbTree.inline.hpp`. Some small `AbstractRBTree` functions are kept in `rbTree.hpp`, and also all of `RBTree`'s implementation. This makes the file less readable and requires extra header inclusions, notably the `os` class, which in turn includes additional unnecessary dependancies. >> >> In this PR I have moved all implementation code `rbTree.inline.hpp` instead. As a result, `rbTree.hpp` now only contains declarations, making it cleaner and limiting header inclusions to what is strictly necessary. Implementation-specific headers are now only included in the inline file. >> >> Additionally, I changed `RBTreeCHeapAllocator` to use `AllocateHeap`/`FreeHeap` from `allocation` instead of `os::malloc`/`os::free`, which allows us to get rid of the `os` dependancy altogether. >> >> Note: This PR is dependant on #29082, which adds arena-style tree allocators, which this PR then moves to the inline file. >> >> Testing: >> - Oracle tiers 1-5 > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > sort forward declarations Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29295#pullrequestreview-3691558514 From stefank at openjdk.org Thu Jan 22 10:07:41 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 22 Jan 2026 10:07:41 GMT Subject: RFR: 8353564: Fail fatally if os::release_memory or os::uncommit_memory fails In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 23:30:14 GMT, Robert Toyonaga wrote: > This PR is a follow up to JDK-8341491. See original discussion: https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700 > > This PR makes `os::release_memory`, `os::uncommit_memory`, `os::release_memory_special`, and `os::unmap_memory` fail fatally if they encounter an error. These methods require obtaining the NMT lock. Fatally failing in these places would potentially allow for the tightening of NMT virtual memory locking scopes (future work, if this PR is accepted). Already in most cases, the callers fail fatally or assert(false) when these os:: methods fail. Another reason to fatally fail is that if the OS memory operation fails, it can be difficult to know for sure what state the OS left the memory in and recover. > > `release_memory`/`uncommit_memory`/`release_memory_special`/`unmap_memory` can fail due to ? Bad arguments, or ? The OS encountered an issue out of control of the JVM. > > ? > If there is a JVM bug, it's probably reasonable to fatally fail here. Or the caller could be intentionally passing arguments that may or may not be valid. I don't think there is any code like that currently, and this is probably a bad pattern to be following anyway. > > ? > In platform dependent code: > With regard to mmap/munmap, the only errors that aren't due to bad arguments are ENOMEM and ones related to file descriptors (which are not applicable to uncommit or release). > On Windows, VirtualFree only fails due to bad arguments. > On AIX, shmdt and disclaim64 only fail due to bad arguments. msync could spontaneously fail with EIO: "An I/O error occurred while reading from or writing to the file system." > On BSD, it seems like mprotect and madvise fail only due to bad arguments or invalid privileges. > > In the [original discussion](https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700), the main question was whether ENOMEM upon os::uncommit_memory was recoverable. This may be possible if we uncommit the middle of a region - splitting it in two. This could exceed the limit of the number of mappings resulting in ENOMEM. > > If none of the scenarios in ? are recoverable, then perhaps fatally failing is OK. > > Testing: > - Tier 1. > - Manual testing to make sure we fatally fail and the correct messages are printed. Thanks for taking on this change. Some comments: * os::unmap_memory only returns true now. Is there a reason why the return value type of this function is not changed? * I would personally just skip all the error strings and let us figure out the error by locking at the generated stack traces instead. Not a super strong opinion, though. * David says that higher levels should figure out if the error is recoverable. I don't think that can be safely done. If the unmapping failed, we don't know if the virtual memory mappings are in a consistent state. That all depends on how the kernel handle that specific failure, and we have seen that in some cases the kernel leaves VMAs in a state that we in the JVM did not anticipate, which have lead to hard-to-diagnose follow-on crashes. ------------- PR Review: https://git.openjdk.org/jdk/pull/29240#pullrequestreview-3691625199 From epeter at openjdk.org Thu Jan 22 10:12:00 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Thu, 22 Jan 2026 10:12:00 GMT Subject: RFR: 8374807: Crash in MethodData::extra_data_lock()+0x0 when running -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp -version [v4] In-Reply-To: <5YSsP2h52Kp9WWb4YrthjtYSziRKM5FM3s5NHThrPTg=.8be8a6fc-e841-4e7b-b9d5-e3910c9bc2e6@github.com> References: <17qmKHGiPNSNpHn2By-gtJjPpwFFDj98wiY-bQG16nY=.4df59ed3-8120-496b-9a1e-06b80c9149ae@github.com> <5YSsP2h52Kp9WWb4YrthjtYSziRKM5FM3s5NHThrPTg=.8be8a6fc-e841-4e7b-b9d5-e3910c9bc2e6@github.com> Message-ID: On Thu, 22 Jan 2026 01:54:16 GMT, Guanqiang Han wrote: >> @hgqxjj Hmm I see. I'm not a fan of using `@requires vm.debug`, because it means that your test is not run in product, and sometimes bugs only show up in product. >> >> It's also not great that we have to run a whole JVM startup with `-Xcomp`, compiling EVERYTHING, and blocking for every compilation. We should only use `-Xcomp` in combination with a fairly restricted `compileonly`. Otherwise, we just waste a lot of compute resources. >> >> @iwanowww What is your opinion on this? > > @eme64 Thanks for the feedback. > > On @requires vm.debug: I?d like to keep it for this reproducer. ProfileTraps is the key knob here: the failure requires ProfileTraps=false (create_if_missing = ProfileTraps, so get_method_data(..., false) may return NULL). Since ProfileTraps is a develop_pd flag and not settable on product builds, this reproducer has to run on a non-product VM (i.e., a debug VM). > > On -Xcomp: agreed. I?ll keep it but restrict it with -XX:CompileCommand=compileonly,... so we only compile the relevant method(s). > > If that sounds reasonable, I?ll proceed with just the compileonly tightening. Generally, it would also be nicer to extract a reproducer into a `test` method, and only compile that one. That way, the code shape leading to the crash is preserved. Would that be possible? Otherwise, we risk that someone changes the code shape (maybe in the core libs), and the test would not reproduce any more. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29147#discussion_r2716206558 From roland at openjdk.org Thu Jan 22 10:40:52 2026 From: roland at openjdk.org (Roland Westrelin) Date: Thu, 22 Jan 2026 10:40:52 GMT Subject: Integrated: 8373343: C2: verify AddP base input only set for heap addresses In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 15:31:55 GMT, Roland Westrelin 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. This pull request has now been integrated. Changeset: 6e9256cb Author: Roland Westrelin URL: https://git.openjdk.org/jdk/commit/6e9256cb613c9a3594546a45975a81def2efcf46 Stats: 107 lines in 16 files changed: 29 ins; 9 del; 69 mod 8373343: C2: verify AddP base input only set for heap addresses Reviewed-by: dlong, chagedorn, qamai ------------- PR: https://git.openjdk.org/jdk/pull/28769 From duke at openjdk.org Thu Jan 22 11:11:04 2026 From: duke at openjdk.org (Ivan Bereziuk) Date: Thu, 22 Jan 2026 11:11:04 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v4] In-Reply-To: References: Message-ID: <93J0DXbDwwQDYqasv9f9lF4NofBWMLb4NTiyMCXkdsM=.bc351bf6-8408-4c4d-990d-99df03a21649@github.com> > `jcmd` provides great diagnostics but many commands lack a timestamp in their output. > Adding a timestamp to the output of some would add value for those debugging JVM data. > > Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. > > With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-T": > > jcmd [pid | main-class] [-T] command... | PerfCounter.print | -f filename > ^^^^ > > * The choice for time format is "yyyy-MM-dd HH:mm:ss" as it is already used in `Thread.print`. > * `Thread.print` prints timestamp irrespectively from "-T" flag presence to preserve backwards compatibility. > > I haven't added a timestamp to the following diagnostic command: > * `VM.uptime` - command run with `-date` argument will also print a timestamp; > * `VM.system_properties` - as the output already lists a timestamp. Not sure if we need more timestamps here. > * `Thread.dump_to_file` - the content dumped to a file already has a timestamp; Ivan Bereziuk has updated the pull request incrementally with one additional commit since the last revision: change flag name from -T to -t ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27368/files - new: https://git.openjdk.org/jdk/pull/27368/files/c702901d..f0e39a34 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27368&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27368&range=02-03 Stats: 13 lines in 6 files changed: 0 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/27368.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27368/head:pull/27368 PR: https://git.openjdk.org/jdk/pull/27368 From tschatzl at openjdk.org Thu Jan 22 12:12:26 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 22 Jan 2026 12:12:26 GMT Subject: RFR: 8373266: Strengthen constant CardTable base accesses [v5] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 16:47:43 GMT, Aleksey Shipilev 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 > > Aleksey Shipilev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > Some polishing Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28703#pullrequestreview-3692138599 From kevinw at openjdk.org Thu Jan 22 12:36:02 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 22 Jan 2026 12:36:02 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v4] In-Reply-To: <93J0DXbDwwQDYqasv9f9lF4NofBWMLb4NTiyMCXkdsM=.bc351bf6-8408-4c4d-990d-99df03a21649@github.com> References: <93J0DXbDwwQDYqasv9f9lF4NofBWMLb4NTiyMCXkdsM=.bc351bf6-8408-4c4d-990d-99df03a21649@github.com> Message-ID: On Thu, 22 Jan 2026 11:11:04 GMT, Ivan Bereziuk wrote: >> `jcmd` provides great diagnostics but many commands lack a timestamp in their output. >> Adding a timestamp to the output would add value for those debugging JVM data. >> >> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. >> >> With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-t": >> >> jcmd [pid | main-class] [-t] command... | PerfCounter.print | -f filename >> ^^^^ >> >> * The choice for time format is ISO 8601 `yyyy-MM-dd'T'HH:mm:ss.SSSZ` (example `2026-01-21T16:58:49.518+0100`) >> * if "-t" flag is not passed, `Thread.print` keeps printing "yyyy-MM-dd HH:mm:ss" timestamp to preserve backwards compatibility. > > Ivan Bereziuk has updated the pull request incrementally with one additional commit since the last revision: > > change flag name from -T to -t I am liking the much simpler alternative. I think you did a lot of exploratory work here, but there is a lot of complexity needed just because Thread.print already prints a timestamp. I do not find this ugly or unparseable: $ jcmd -t 2970459 Thread.print 2970459: 2026-01-22T12:05:50.518+0100 2026-01-22 12:05:55 Full thread dump Java HotSpot(TM) 64-Bit Server VM (27-internal-kwalls.open mixed mode, sharing) JDK version: Java(TM) SE Runtime Environment (27.0) (fastdebug build 27-internal-kwalls.open) Threads class SMR info: ... It would not seem right to add the common flags infrastructure in dcmd framework just in case it's useful in future, just add what we need right now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3784154369 From erfang at openjdk.org Thu Jan 22 12:39:48 2026 From: erfang at openjdk.org (Eric Fang) Date: Thu, 22 Jan 2026 12:39:48 GMT Subject: RFR: 8374349: [VectorAPI]: AArch64: Prefer merging mode SVE CPY instruction Message-ID: <_0ouKSVAIyzg0g9hA2jZXNH-_cCqJjNCSh7kM2dn80w=.b93145c3-c465-423a-ab68-c8d7bd7e4280@github.com> When optimizing some VectorMask related APIs , we found an optimization opportunity related to the `cpy (immediate, zeroing)` instruction [1]. Implementing the functionality of this instruction using `cpy (immediate, merging)` instruction [2] leads to better performance. Currently the `cpy (imm, zeroing)` instruction is used in code generated by `VectorStoreMaskNode` and `VectorReinterpretNode`. Doing this optimization benefits all vector APIs that generate these two IRs potentially, such as `VectorMask.intoArray()` and `VectorMask.toLong()`. Microbenchmarks show this change brings performance uplift ranging from **11%** to **33%**, depending on the specific operation and data types. The specific changes in this PR: 1. Achieve the functionality of the `cpy (imm, zeroing)` instruction with the `movi + cpy (imm, merging)` instructions in assembler: cpy z17.d, p1/z, #1 => movi v17.2d, #0 // this instruction is zero cost cpy z17.d, p1/m, #1 2. Add a new option `PreferSVEMergingModeCPY` to indicate whether to apply this optimization or not. - This option belongs to the Arch product category. - The default value is true on Neoverse-V1/V2 where the improvement has been confirmed, false on others. - When its value is true, the change is applied. 3. Add a jtreg test to verify the behavior of this option. This PR was tested on aarch64 and x86 machines with different configurations, and all tests passed. JMH benchmarks: On a Nvidia Grace (Neoverse-V2) machine with 128-bit SVE2: Benchmark Unit size Before Error After Error Uplift byteIndexInRange ops/ms 7.00 471816.15 1125.96 473237.77 1593.92 1.00 byteIndexInRange ops/ms 256.00 149654.21 416.57 149259.95 116.59 1.00 byteIndexInRange ops/ms 259.00 177850.31 991.13 179785.19 1110.07 1.01 byteIndexInRange ops/ms 512.00 133393.26 167.26 133484.61 281.83 1.00 doubleIndexInRange ops/ms 7.00 302176.39 12848.8 299813.02 37.76 0.99 doubleIndexInRange ops/ms 256.00 47831.93 56.70 46708.70 56.11 0.98 doubleIndexInRange ops/ms 259.00 11550.02 27.95 15333.50 10.40 1.33 doubleIndexInRange ops/ms 512.00 23687.76 61.65 23996.08 69.52 1.01 floatIndexInRange ops/ms 7.00 412195.79 124.71 411770.23 78.73 1.00 floatIndexInRange ops/ms 256.00 84479.98 70.69 84237.31 70.15 1.00 floatIndexInRange ops/ms 259.00 22585.65 80.07 28296.21 7.98 1.25 floatIndexInRange ops/ms 512.00 46902.99 51.60 46686.68 66.01 1.00 intIndexInRange ops/ms 7.00 413411.70 50.59 420684.66 253.55 1.02 intIndexInRange ops/ms 256.00 84652.41 191.45 86758.74 193.66 1.02 intIndexInRange ops/ms 259.00 61825.20 291.71 62037.58 2355.43 1.00 intIndexInRange ops/ms 512.00 46754.89 149.72 46972.06 40.13 1.00 longIndexInRange ops/ms 7.00 329385.10 3292.7 318538.75 11103.9 0.97 longIndexInRange ops/ms 256.00 46910.36 53.41 46927.82 138.29 1.00 longIndexInRange ops/ms 259.00 33126.45 3210.07 32245.59 1347.58 0.97 longIndexInRange ops/ms 512.00 23931.64 215.55 23805.65 312.39 0.99 shortIndexInRange ops/ms 7.00 479265.67 1055.89 468452.89 433.15 0.98 shortIndexInRange ops/ms 256.00 138657.38 317.72 138695.29 505.69 1.00 shortIndexInRange ops/ms 259.00 113353.87 913.13 108912.75 1125.60 0.96 shortIndexInRange ops/ms 512.00 84652.74 171.37 84447.01 91.99 1.00 On an AWS Graviton3 (Neoverse-V1) machine with 128-bit SVE1: Benchmark Unit size Before Error After Error Uplift byteIndexInRange ops/ms 7.00 320073.86 669.91 318557.87 1285.42 1.00 byteIndexInRange ops/ms 256.00 119246.71 43.13 120658.01 28.27 1.01 byteIndexInRange ops/ms 259.00 137664.23 12001.6 150378.59 70.41 1.09 byteIndexInRange ops/ms 512.00 97187.13 18.60 95356.43 78.60 0.98 doubleIndexInRange ops/ms 7.00 291076.68 603.08 287383.75 518.59 0.99 doubleIndexInRange ops/ms 256.00 57473.11 123.34 61559.58 687.21 1.07 doubleIndexInRange ops/ms 259.00 19396.73 40.03 22046.65 8.66 1.14 doubleIndexInRange ops/ms 512.00 33619.28 33.58 34715.40 157.72 1.03 floatIndexInRange ops/ms 7.00 317295.18 627.76 303857.78 465.78 0.96 floatIndexInRange ops/ms 256.00 91734.27 183.61 91851.31 394.35 1.00 floatIndexInRange ops/ms 259.00 38103.12 129.44 42237.38 92.17 1.11 floatIndexInRange ops/ms 512.00 57219.58 366.00 57769.07 264.71 1.01 intIndexInRange ops/ms 7.00 317063.25 830.81 304289.56 541.12 0.96 intIndexInRange ops/ms 256.00 91535.60 315.36 98143.40 142.44 1.07 intIndexInRange ops/ms 259.00 73827.89 472.28 73781.80 21.53 1.00 intIndexInRange ops/ms 512.00 57552.09 20.19 62348.87 37.45 1.08 longIndexInRange ops/ms 7.00 301886.14 381.89 301636.82 184.80 1.00 longIndexInRange ops/ms 256.00 62246.77 69.29 62093.75 88.72 1.00 longIndexInRange ops/ms 259.00 40642.36 861.47 41566.43 256.04 1.02 longIndexInRange ops/ms 512.00 34850.70 154.39 34884.42 149.17 1.00 shortIndexInRange ops/ms 7.00 318133.03 593.20 313469.12 528.73 0.99 shortIndexInRange ops/ms 256.00 105019.58 21.38 105014.90 21.81 1.00 shortIndexInRange ops/ms 259.00 116235.93 1985.27 118697.74 48.41 1.02 shortIndexInRange ops/ms 512.00 91981.84 166.84 91874.82 78.28 1.00 [1] https://developer.arm.com/documentation/ddi0602/2025-06/SVE-Instructions/CPY--immediate--zeroing---Copy-signed-integer-immediate-to-vector-elements--zeroing--?lang=en [2] https://developer.arm.com/documentation/ddi0602/2025-12/SVE-Instructions/CPY--immediate--merging---Copy-signed-integer-immediate-to-vector-elements--merging--?lang=en ------------- Commit messages: - 8374349: [VectorAPI]: AArch64: Prefer merging mode SVE CPY instruction Changes: https://git.openjdk.org/jdk/pull/29359/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29359&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374349 Stats: 193 lines in 6 files changed: 171 ins; 7 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/29359.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29359/head:pull/29359 PR: https://git.openjdk.org/jdk/pull/29359 From erfang at openjdk.org Thu Jan 22 12:46:44 2026 From: erfang at openjdk.org (Eric Fang) Date: Thu, 22 Jan 2026 12:46:44 GMT Subject: RFR: 8374349: [VectorAPI]: AArch64: Prefer merging mode SVE CPY instruction In-Reply-To: <_0ouKSVAIyzg0g9hA2jZXNH-_cCqJjNCSh7kM2dn80w=.b93145c3-c465-423a-ab68-c8d7bd7e4280@github.com> References: <_0ouKSVAIyzg0g9hA2jZXNH-_cCqJjNCSh7kM2dn80w=.b93145c3-c465-423a-ab68-c8d7bd7e4280@github.com> Message-ID: On Thu, 22 Jan 2026 12:31:19 GMT, Eric Fang wrote: > When optimizing some VectorMask related APIs , we found an optimization opportunity related to the `cpy (immediate, zeroing)` instruction [1]. Implementing the functionality of this instruction using `cpy (immediate, merging)` instruction [2] leads to better performance. > > Currently the `cpy (imm, zeroing)` instruction is used in code generated by `VectorStoreMaskNode` and `VectorReinterpretNode`. Doing this optimization benefits all vector APIs that generate these two IRs potentially, such as `VectorMask.intoArray()` and `VectorMask.toLong()`. > > Microbenchmarks show this change brings performance uplift ranging from **11%** to **33%**, depending on the specific operation and data types. > > The specific changes in this PR: > 1. Achieve the functionality of the `cpy (imm, zeroing)` instruction with the `movi + cpy (imm, merging)` instructions in assembler: > > cpy z17.d, p1/z, #1 => > > movi v17.2d, #0 // this instruction is zero cost > cpy z17.d, p1/m, #1 > > > 2. Add a new option `PreferSVEMergingModeCPY` to indicate whether to apply this optimization or not. > - This option belongs to the Arch product category. > - The default value is true on Neoverse-V1/V2 where the improvement has been confirmed, false on others. > - When its value is true, the change is applied. > > 3. Add a jtreg test to verify the behavior of this option. > > This PR was tested on aarch64 and x86 machines with different configurations, and all tests passed. > > JMH benchmarks: > > On a Nvidia Grace (Neoverse-V2) machine with 128-bit SVE2: > > Benchmark Unit size Before Error After Error Uplift > byteIndexInRange ops/ms 7.00 471816.15 1125.96 473237.77 1593.92 1.00 > byteIndexInRange ops/ms 256.00 149654.21 416.57 149259.95 116.59 1.00 > byteIndexInRange ops/ms 259.00 177850.31 991.13 179785.19 1110.07 1.01 > byteIndexInRange ops/ms 512.00 133393.26 167.26 133484.61 281.83 1.00 > doubleIndexInRange ops/ms 7.00 302176.39 12848.8 299813.02 37.76 0.99 > doubleIndexInRange ops/ms 256.00 47831.93 56.70 46708.70 56.11 0.98 > doubleIndexInRange ops/ms 259.00 11550.02 27.95 15333.50 10.40 1.33 > doubleIndexInRange ops/ms 512.00 23687.76 61.65 23996.08 69.52 1.01 > floatIndexInRange ops/ms 7.00 412195.79 124.71 411770.23 78.73 1.00 > floatIndexInRange ops/ms 256.00 84479.98 70.69 84237.31 70.15 1.00 > floatIndexInRange ops/ms 259.00 22585.65 80.07 28296.21 7.98 1.25 > floatIndexInRange ops/ms 512.00 46902.99 51.60 46686.68 66.01 1.00 > intIndexInRange ops/ms 7.00 413411.70 50.59 420684.66 253.55 1.02 > intIndexInRange ops/... Hi @fg1417, this PR optimizes the use of the `sve cpy (imm, zeroing)` instruction. I have confirmed this optimization on Neoverse-V1/V2, but I don't have any more AArch64 testing environments, so I'm not sure if this optimization can be applied to more environments. Do you have more testing environments ? If so, could you help me test and review this PR? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29359#issuecomment-3784204017 From ysuenaga at openjdk.org Thu Jan 22 14:09:41 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 22 Jan 2026 14:09:41 GMT Subject: RFR: 8374926: EnableX86ECoreOpts was not enabled on some hybrid CPU [v4] In-Reply-To: References: Message-ID: > `EnableX86ECoreOpts` has been introduced in [JDK-8319429](https://bugs.openjdk.org/browse/JDK-8319429), however model numbers which should be enabled are hard-coded, so the flag would not be enabled by default on some models like Arrow Lake. > > I ran a [benchmark](https://github.com/YaSuenag/garakuta/tree/master/randminmax) to check for effectiveness of `-XX:+EnableX86ECoreOpts` with JDK 25.0.1 on Windows 11 25H2, I saw performance improvement a bit on Intel Core 5 Ultra 225U as following: > > Disabled (default) > > Benchmark Mode Cnt Score Error Units > RandMinVal.getMax thrpt 3 9707774.405 ? 27082629.015 ops/s > RandMinVal.getMin thrpt 3 7510319.839 ? 10923547.382 ops/s > > > Enabled > > Benchmark Mode Cnt Score Error Units > RandMinVal.getMax thrpt 3 10127809.127 ? 45404142.338 ops/s > RandMinVal.getMin thrpt 3 8467677.056 ? 1211998.200 ops/s > > > So I think it is better to enable this flag by default on all of hybrid CPUs. > > > To check what processor would be enabled E-core optimization, I made a [commit](https://github.com/openjdk/jdk/commit/f363ea1436b8100021fdac87b48ec43bcf6820af) to add comments for CPU models at first. I couldn't find out all of models (some models has not listed in SDM vol.4 so far), but most of models (excepts Sierra Forest) could be treated as hybrid CPU. Fortunately HotSpot identify hybrid flag from `CPUID`, so we can leverage it for this purpose. Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Check E-Core with Leaf 1Ah ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29149/files - new: https://git.openjdk.org/jdk/pull/29149/files/92e91552..d77b4393 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29149&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29149&range=02-03 Stats: 35 lines in 2 files changed: 30 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29149.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29149/head:pull/29149 PR: https://git.openjdk.org/jdk/pull/29149 From ysuenaga at openjdk.org Thu Jan 22 14:09:43 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 22 Jan 2026 14:09:43 GMT Subject: RFR: 8374926: EnableX86ECoreOpts was not enabled on some hybrid CPU [v3] In-Reply-To: References: Message-ID: On Sun, 11 Jan 2026 07:46:33 GMT, Yasumasa Suenaga wrote: >> `EnableX86ECoreOpts` has been introduced in [JDK-8319429](https://bugs.openjdk.org/browse/JDK-8319429), however model numbers which should be enabled are hard-coded, so the flag would not be enabled by default on some models like Arrow Lake. >> >> I ran a [benchmark](https://github.com/YaSuenag/garakuta/tree/master/randminmax) to check for effectiveness of `-XX:+EnableX86ECoreOpts` with JDK 25.0.1 on Windows 11 25H2, I saw performance improvement a bit on Intel Core 5 Ultra 225U as following: >> >> Disabled (default) >> >> Benchmark Mode Cnt Score Error Units >> RandMinVal.getMax thrpt 3 9707774.405 ? 27082629.015 ops/s >> RandMinVal.getMin thrpt 3 7510319.839 ? 10923547.382 ops/s >> >> >> Enabled >> >> Benchmark Mode Cnt Score Error Units >> RandMinVal.getMax thrpt 3 10127809.127 ? 45404142.338 ops/s >> RandMinVal.getMin thrpt 3 8467677.056 ? 1211998.200 ops/s >> >> >> So I think it is better to enable this flag by default on all of hybrid CPUs. >> >> >> To check what processor would be enabled E-core optimization, I made a [commit](https://github.com/openjdk/jdk/commit/f363ea1436b8100021fdac87b48ec43bcf6820af) to add comments for CPU models at first. I couldn't find out all of models (some models has not listed in SDM vol.4 so far), but most of models (excepts Sierra Forest) could be treated as hybrid CPU. Fortunately HotSpot identify hybrid flag from `CPUID`, so we can leverage it for this purpose. > > Yasumasa Suenaga 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 four additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into ecoreopt-hybrid > - Merge remote-tracking branch 'origin/master' into ecoreopt-hybrid > - Use supports_hybrid() to check for EnableX86ECoreOpts > - Add comments for CPU models I updated this PR to check leaf 1Ah like [this branch](https://github.com/YaSuenag/jdk/compare/ecoreopt-hybrid...YaSuenag:jdk:check-ecore). @vpaprotsk Could you check this change on both SRF and CWF? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29149#issuecomment-3784600898 From tschatzl at openjdk.org Thu Jan 22 14:22:47 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 22 Jan 2026 14:22:47 GMT Subject: RFR: 8375535: G1: Convert CardTableBarrierSet and subclasses to use Atomic Message-ID: Hi all, use `Atomic` instead of `AtomicAccess` in `CardTableBarrierSet` and subclasses. Since this modifies `CardTableBarrierSet::_card_table` the change has some fan-out. Testing: gha Thanks, Thomas ------------- Commit messages: - 8375535 Changes: https://git.openjdk.org/jdk/pull/29360/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29360&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375535 Stats: 34 lines in 7 files changed: 5 ins; 0 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/29360.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29360/head:pull/29360 PR: https://git.openjdk.org/jdk/pull/29360 From pchilanomate at openjdk.org Thu Jan 22 14:55:39 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 22 Jan 2026 14:55:39 GMT Subject: RFR: 8373120: Virtual thread stuck in BLOCKED state In-Reply-To: References: Message-ID: <4drncZpNzFFT-ME7n27r4V2l_8AXgn3CGMgLvPzNjEI=.bfb662ab-541b-40d1-bd42-1cbd05eb84ce@github.com> On Fri, 16 Jan 2026 07:05:45 GMT, Alan Bateman wrote: >> @pchilano I took a look at this out of interest but there is nothing Hotspot related to review. The state machine for VTs is too complex for me to comment on the actual fix - though I understand how the timedWaitLock forces the calls to be serialized. >> >> It did make we wonder why the timed-park doesn't need any locking. Can't it have a similar problem if the virtual thread is unparked before the carrier can set the state to TIMED_PARK? > >> It did make we wonder why the timed-park doesn't need any locking. Can't it have a similar problem if the virtual thread is unparked before the carrier can set the state to TIMED_PARK? > > Parking (including timed-parking) is much simpler, and okay to be unparked during transition. We have a lot of tests for this. Timed-Object.wait is more complex due to the two block states (the equivalent of Thread.State TIMED_WAITING and BLOCKED), and timed and unblocking working asynchronously. Thanks for the reviews and comments @AlanBateman, @dholmes-ora and @viktorklang-ora! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29255#issuecomment-3784826784 From pchilanomate at openjdk.org Thu Jan 22 14:59:40 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 22 Jan 2026 14:59:40 GMT Subject: Integrated: 8373120: Virtual thread stuck in BLOCKED state In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 17:42:33 GMT, Patricio Chilano Mateo wrote: > Please review the following patch. This fixes a bug in how we handle state changes for the timed `Object.wait` case in `afterYield`, which can leave a virtual thread stuck in the `BLOCKED` state. It can be triggered by two consecutive calls to timed `Object.wait`, if the first call receives a notification and the second call relies on the timeout task to wake up the thread. I added the full sequence of events that leads to the vthread getting stuck in JBS. > > The fix is to check for `notified` and attempt to change the state to `BLOCKED` inside the synchronized block. This guarantees that we don't change the state of an already new timed `Object.wait` call. > > The PR includes a new test which reproduces the issue when run several times in mach5. It's a hybrid of my original repro test and another one created by @AlanBateman. > > Thanks, > Patricio This pull request has now been integrated. Changeset: 26aab3cc Author: Patricio Chilano Mateo URL: https://git.openjdk.org/jdk/commit/26aab3cccdbcf98c329c8d67093eb2dbf4b164e5 Stats: 156 lines in 2 files changed: 145 ins; 8 del; 3 mod 8373120: Virtual thread stuck in BLOCKED state Co-authored-by: Alan Bateman Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/29255 From stuefe at openjdk.org Thu Jan 22 15:15:21 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 22 Jan 2026 15:15:21 GMT Subject: RFR: 8353564: Fail fatally if os::release_memory or os::uncommit_memory fails In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 01:41:29 GMT, David Holmes wrote: > I don't have an opinion on whether these methods failing are recoverable or not in general but I don't think failing to remove stack guard pages is a fatal error. There was a prior discussion on this. https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700 The gist of it is, uncommit fails either for a parameter error (which would be a programmer error and should be asserted) or under very rare circumstances when we run out of mapping slots in the Linux VMA tree (since uncommitting a section inside a committed section would split the VMA in two and now you have more mappings). @stefank argued that in this case we are close to death anyway, even if we handle this particular error. The next malloc may already bring us over the line. So, an assert would be just practical > And changing the API so that the callers can prepare (if necessary) and pass in an error message, does make me cringe somewhat. Yes, I agree. I don't need those error strings. They don't really help much with error analysis, nor with recovery/prevention from the user's standpoint. If it's a programmer error, we need the hs-err file. If we hit an OS limit, it will be arbitrary where exactly it hits, so the information is not really relevant. Much more sense would be to (in a separate PR) highlight the fact in the hs-err file that this particular native OOM may have been caused by running against the mapping limit, and that increasing said limit may help. Maybe we do this already, not sure. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29240#issuecomment-3784926521 From vpaprotski at openjdk.org Thu Jan 22 16:20:12 2026 From: vpaprotski at openjdk.org (Volodymyr Paprotski) Date: Thu, 22 Jan 2026 16:20:12 GMT Subject: RFR: 8374926: EnableX86ECoreOpts was not enabled on some hybrid CPU [v3] In-Reply-To: <3wEINJR2IDU6Hi772So8ZqytuF775R-76c4ngkfWuqw=.aa820856-05d8-4fe6-a260-1c6b98bb2921@github.com> References: <3wEINJR2IDU6Hi772So8ZqytuF775R-76c4ngkfWuqw=.aa820856-05d8-4fe6-a260-1c6b98bb2921@github.com> Message-ID: On Fri, 16 Jan 2026 01:12:33 GMT, Volodymyr Paprotski wrote: >> Yasumasa Suenaga 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 four additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/master' into ecoreopt-hybrid >> - Merge remote-tracking branch 'origin/master' into ecoreopt-hybrid >> - Use supports_hybrid() to check for EnableX86ECoreOpts >> - Add comments for CPU models > > For CWF (model `0xDD`), `hy-core-check.c` prints: > > Hybrid: 0 > HT: 1 > Max leaf: 0x28 > > and for SRF (model `0XAF`): > > Hybrid: 0 > HT: 1 > Max leaf: 0x23 > > > When I added EnableX86ECoreOpts , I remember thinking that I need to 'make it more generic or there will be a lot of models to add manually'. Here we are :( > > I need to do more research (and perhaps find some people to talk to..); specifically for client-part numbers. > > Some reasons why I hadn't made it (yet?) more generic.. `EnableX86ECoreOpts` is supposed to be 'temporary' (the definition of which, for processors, is 'years'..). It currently enables 'emulation' type of (de)optimizations.. places where Atom cores have some catching up to do, but hopefully should be fixed: > - MXCSR signaling flags > - `vblendvp{sd}` emulation > - pcmpestri 'emulation' in String.indexof > - generate_fill (which perhaps could go under UseAVX=2 with more work/testing) > > In other words: we will at some point need to _disable_ `EnableX86ECoreOpts` on future hybrid cores and will again need another cpuid/flag to detect? > I updated this PR to check leaf 1Ah like [this branch](https://github.com/YaSuenag/jdk/compare/ecoreopt-hybrid...YaSuenag:jdk:check-ecore). @vpaprotsk Could you check this change on both SRF and CWF? I am waiting for some replies.. I do think adding hybrid check might be a good idea, at least for now. I still need to find a way to detect 'is ecore only'. And if I could detect only the parts that actually need this emulation. (Though maybe leave both of those to me for another PR.. I might have to start looking around 'experimentally' since I have the hardware and your program) ------------- PR Comment: https://git.openjdk.org/jdk/pull/29149#issuecomment-3785290674 From shade at openjdk.org Thu Jan 22 16:50:58 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 22 Jan 2026 16:50:58 GMT Subject: RFR: 8373266: Strengthen constant CardTable base accesses [v5] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 16:47:43 GMT, Aleksey Shipilev 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 > > Aleksey Shipilev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > Some polishing Thanks! The only GHA failure is due to (the absence of): https://github.com/openjdk/jdk/pull/29254. Looking for a second Reviewer! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28703#issuecomment-3785460384 From fgao at openjdk.org Thu Jan 22 17:04:11 2026 From: fgao at openjdk.org (Fei Gao) Date: Thu, 22 Jan 2026 17:04:11 GMT Subject: RFR: 8374349: [VectorAPI]: AArch64: Prefer merging mode SVE CPY instruction In-Reply-To: References: <_0ouKSVAIyzg0g9hA2jZXNH-_cCqJjNCSh7kM2dn80w=.b93145c3-c465-423a-ab68-c8d7bd7e4280@github.com> Message-ID: On Thu, 22 Jan 2026 12:43:58 GMT, Eric Fang wrote: > Hi @fg1417, this PR optimizes the use of the `sve cpy (imm, zeroing)` instruction. I have confirmed this optimization on Neoverse-V1/V2, but I don't have any more AArch64 testing environments, so I'm not sure if this optimization can be applied to more environments. Do you have more testing environments ? If so, could you help me test and review this PR? Thanks! Hi @erifan, thanks for your work! Sure, I?m happy to test it. I?ll get back to you once I have the results. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29359#issuecomment-3785525633 From kvn at openjdk.org Thu Jan 22 17:37:38 2026 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 22 Jan 2026 17:37:38 GMT Subject: RFR: 8374549: Extend MetaspaceClosure to cover non-MetaspaceObj types In-Reply-To: References: Message-ID: <7fCqqxJTaRd1JzzT7fqrcsTwSKpVnr7kb_SuubuMOTg=.15269a6d-6034-4335-8193-09891d63a422@github.com> On Mon, 5 Jan 2026 20:32:46 GMT, Ioi Lam wrote: > Previously, `MetaspaceClosure` could iterate only `MetaspaceObject`, using its four member functions: > > - `is_read_only_by_default()` > - `metaspace_pointers_do()` > - `size()` > - `type()` > > `PackageEntry`, `ModuleEntry` and `GrowableArray` cannot be subclasses from `MetaspaceObject` due to various constraints. As a result, they were copied with ad-hoc code. > > This PR updates the templates in `MetaspaceClosure` so that it can iterate any classes that have the above four functions. This allows new types of data to be uniformly copied into the AOT cache (aka CDS archive) without ad-hoc copiers. > > This PR is necessary for future evolution of AOT as more types of data will be copied into the AOT cache. For example, in Valhalla we have a `GrowableArray` that needs to be copied along with `AdapterHandleEntry`. src/hotspot/share/cds/cppVtables.cpp line 62: > 60: > 61: // AOTGrowableArray has a vtable only when in non-product builds (due to > 62: // the virtual printing functions in AnyObj). Can we devirtualize it? You would need to reconstruct Vpointer in non-debug build otherwise. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29049#discussion_r2717929922 From sviswanathan at openjdk.org Thu Jan 22 17:43:21 2026 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Thu, 22 Jan 2026 17:43:21 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v13] In-Reply-To: References: <_9OkAqddCk8CbA-51qgdecI23f03MBsZE9kiES5cU0I=.d1adead1-45ff-40be-b139-2f9fa32c7d42@github.com> Message-ID: On Wed, 21 Jan 2026 00:01:39 GMT, Srinivas Vamsi Parasa wrote: >> @vamsi-parasa Thanks for the extra data! >> >> Do I see this right? In the plots [here](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761659799), the masked performance lies lower/better than unmasked performance (here we measure ns/ops). But in your tables [here](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761712841) you are measuring ops/ms, and are getting the opposite trend: masked is slower than unmasked. >> >> Can you explain the difference between the two results? > >> Can you explain the difference between the two results? >> > Hi Emanuel (@eme64), > Yes, the conclusions you mentioned are correct. The store only benchmark shows that masked store is slightly better than the unmasked store. However, the store followed by load benchmarks shows that the unmasked store is better than masked vector store as masked vector stores have very limited store forwarding support in the hardware. > > This is because the load operation following the masked vector store is blocked until the data is written into the cache. This is also mentioned in the [Intel Software optimization manual](https://www.intel.com/content/www/us/en/content-details/671488/intel-64-and-ia-32-architectures-optimization-reference-manual-volume-1.html) (Chapter 18, section 18.4, page 578). > > Pasting the relevant text below for reference: > > > 18.4 FORWARDING AND MEMORY MASKING > When using masked store and load, consider the following: > ? When the mask is not all-ones or all-zeroes, the load operation, following the masked store operation > from the same address is blocked, until the data is written to the cache. > ? Unlike GPR forwarding rules, vector loads whether or not they are masked, do not forward unless > load and store addresses are exactly the same. > ? st_mask = 10101010, ld_mask = 01010101, can forward: no, should block: yes > ? st_mask = 00001111, ld_mask = 00000011, can forward: no, should block: yes > ? When the mask is all-ones, blocking does not occur, because the data may be forwarded to the load > operation. > ? st_mask = 11111111, ld_mask = don?t care, can forward: yes, should block: no > ? When mask is all-zeroes, blocking does not occur, though neither does forwarding. > ? st_mask = 00000000, ld_mask = don?t care, can forward: no, should block: no > In summary, a masked store should be used carefully, for example, if the remainder size is known at > compile time to be 1, and there is a load operation from the same cache line after it (or there is an > overlap in addresses + vector lengths), it may be better to use scalar remainder processing, rather than > a masked remainder block. > > > Thanks, > Vamsi > @vamsi-parasa Ok, so now we have one benchmark that shows a speedup and one that shows a regression. How are we to proceed? > > It seems that without loads [#28442 (comment)](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761659799), this patch leads to a regression. > > Only if there is a load from one of the last elements that the `Arrays.fill` stored to with a masked operation do we get a slowdown. Because of missing load-to-store forwarding. If we instead started loading from the first elements, those would probably already be in cache, and we would not have any latency issues, right? > > But is it not rather an edge-case that we load from the last elements immediately after the `Arrays.fill`? At least for longer arrays, it seems an edge case. For short arrays it is probably more likely that we access the last element soon after the fill. > > It does not seem like a trivial decision to me if this patch is an improvement or not. What do you think @vamsi-parasa ? > > @sviswa7 @dwhite-intel You already approved this PR. What are your thoughts here? @eme64 My thoughts are to go ahead with this PR replacing masked stores with scalar tail processing. As we have seen from https://bugs.openjdk.org/browse/JDK-8349452 masked stores can cause big regression in certain scenarios: accessing elements just written or any other adjacent data that happens to fall in the masked store range. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3785772087 From aph at openjdk.org Thu Jan 22 18:01:34 2026 From: aph at openjdk.org (Andrew Haley) Date: Thu, 22 Jan 2026 18:01:34 GMT Subject: RFR: 8374349: [VectorAPI]: AArch64: Prefer merging mode SVE CPY instruction In-Reply-To: <_0ouKSVAIyzg0g9hA2jZXNH-_cCqJjNCSh7kM2dn80w=.b93145c3-c465-423a-ab68-c8d7bd7e4280@github.com> References: <_0ouKSVAIyzg0g9hA2jZXNH-_cCqJjNCSh7kM2dn80w=.b93145c3-c465-423a-ab68-c8d7bd7e4280@github.com> Message-ID: On Thu, 22 Jan 2026 12:31:19 GMT, Eric Fang wrote: > When optimizing some VectorMask related APIs , we found an optimization opportunity related to the `cpy (immediate, zeroing)` instruction [1]. Implementing the functionality of this instruction using `cpy (immediate, merging)` instruction [2] leads to better performance. > > Currently the `cpy (imm, zeroing)` instruction is used in code generated by `VectorStoreMaskNode` and `VectorReinterpretNode`. Doing this optimization benefits all vector APIs that generate these two IRs potentially, such as `VectorMask.intoArray()` and `VectorMask.toLong()`. > > Microbenchmarks show this change brings performance uplift ranging from **11%** to **33%**, depending on the specific operation and data types. > > The specific changes in this PR: > 1. Achieve the functionality of the `cpy (imm, zeroing)` instruction with the `movi + cpy (imm, merging)` instructions in assembler: > > cpy z17.d, p1/z, #1 => > > movi v17.2d, #0 // this instruction is zero cost > cpy z17.d, p1/m, #1 > > > 2. Add a new option `PreferSVEMergingModeCPY` to indicate whether to apply this optimization or not. > - This option belongs to the Arch product category. > - The default value is true on Neoverse-V1/V2 where the improvement has been confirmed, false on others. > - When its value is true, the change is applied. > > 3. Add a jtreg test to verify the behavior of this option. > > This PR was tested on aarch64 and x86 machines with different configurations, and all tests passed. > > JMH benchmarks: > > On a Nvidia Grace (Neoverse-V2) machine with 128-bit SVE2: > > Benchmark Unit size Before Error After Error Uplift > byteIndexInRange ops/ms 7.00 471816.15 1125.96 473237.77 1593.92 1.00 > byteIndexInRange ops/ms 256.00 149654.21 416.57 149259.95 116.59 1.00 > byteIndexInRange ops/ms 259.00 177850.31 991.13 179785.19 1110.07 1.01 > byteIndexInRange ops/ms 512.00 133393.26 167.26 133484.61 281.83 1.00 > doubleIndexInRange ops/ms 7.00 302176.39 12848.8 299813.02 37.76 0.99 > doubleIndexInRange ops/ms 256.00 47831.93 56.70 46708.70 56.11 0.98 > doubleIndexInRange ops/ms 259.00 11550.02 27.95 15333.50 10.40 1.33 > doubleIndexInRange ops/ms 512.00 23687.76 61.65 23996.08 69.52 1.01 > floatIndexInRange ops/ms 7.00 412195.79 124.71 411770.23 78.73 1.00 > floatIndexInRange ops/ms 256.00 84479.98 70.69 84237.31 70.15 1.00 > floatIndexInRange ops/ms 259.00 22585.65 80.07 28296.21 7.98 1.25 > floatIndexInRange ops/ms 512.00 46902.99 51.60 46686.68 66.01 1.00 > intIndexInRange ops/ms 7.00 413411.70 50.59 420684.66 253.55 1.02 > intIndexInRange ops/... Can we do without `PreferSVEMergingModeCPY`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29359#issuecomment-3785876977 From vlivanov at openjdk.org Thu Jan 22 18:57:17 2026 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 22 Jan 2026 18:57:17 GMT Subject: RFR: 8374807: Crash in MethodData::extra_data_lock()+0x0 when running -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp -version [v4] In-Reply-To: References: <17qmKHGiPNSNpHn2By-gtJjPpwFFDj98wiY-bQG16nY=.4df59ed3-8120-496b-9a1e-06b80c9149ae@github.com> <5YSsP2h52Kp9WWb4YrthjtYSziRKM5FM3s5NHThrPTg=.8be8a6fc-e841-4e7b-b9d5-e3910c9bc2e6@github.com> Message-ID: On Thu, 22 Jan 2026 10:09:46 GMT, Emanuel Peter wrote: >> @eme64 Thanks for the feedback. >> >> On @requires vm.debug: I?d like to keep it for this reproducer. ProfileTraps is the key knob here: the failure requires ProfileTraps=false (create_if_missing = ProfileTraps, so get_method_data(..., false) may return NULL). Since ProfileTraps is a develop_pd flag and not settable on product builds, this reproducer has to run on a non-product VM (i.e., a debug VM). >> >> On -Xcomp: agreed. I?ll keep it but restrict it with -XX:CompileCommand=compileonly,... so we only compile the relevant method(s). >> >> If that sounds reasonable, I?ll proceed with just the compileonly tightening. > > Generally, it would also be nicer to extract a reproducer into a `test` method, and only compile that one. That way, the code shape leading to the crash is preserved. Would that be possible? Otherwise, we risk that someone changes the code shape (maybe in the core libs), and the test would not reproduce any more. I agree that `@requires vm.debug` is well justified here since it tests debug-only functionality. And `-XX:CompileCommand=compileonly,...` is a good improvement. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29147#discussion_r2718178197 From vlivanov at openjdk.org Thu Jan 22 18:57:18 2026 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 22 Jan 2026 18:57:18 GMT Subject: RFR: 8374807: Crash in MethodData::extra_data_lock()+0x0 when running -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp -version [v4] In-Reply-To: References: <17qmKHGiPNSNpHn2By-gtJjPpwFFDj98wiY-bQG16nY=.4df59ed3-8120-496b-9a1e-06b80c9149ae@github.com> <5YSsP2h52Kp9WWb4YrthjtYSziRKM5FM3s5NHThrPTg=.8be8a6fc-e841-4e7b-b9d5-e3910c9bc2e6@github.com> Message-ID: On Thu, 22 Jan 2026 18:53:46 GMT, Vladimir Ivanov wrote: >> Generally, it would also be nicer to extract a reproducer into a `test` method, and only compile that one. That way, the code shape leading to the crash is preserved. Would that be possible? Otherwise, we risk that someone changes the code shape (maybe in the core libs), and the test would not reproduce any more. > > I agree that `@requires vm.debug` is well justified here since it tests debug-only functionality. > > And `-XX:CompileCommand=compileonly,...` is a good improvement. > Did you already run testing on this patch or should I run some? @eme64 no, I haven't performed any testing yet. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29147#discussion_r2718179941 From cslucas at openjdk.org Thu Jan 22 19:24:04 2026 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Thu, 22 Jan 2026 19:24:04 GMT Subject: RFR: 8373021: aarch64: MacroAssembler::arrays_equals reads out of bounds Message-ID: To protect against unauthorized use of the Oracle email brand, we will be implementing a strict DMARC policy as part of our email security. DMARC (Domain-based Message Authentication, Reporting and Conformance) will help protect against phishing attacks, spam campaigns, and other malicious activities. With this implementation, emails sent on behalf of ANY Oracle owned domain will be restricted if they fail DMARC compliance. DMARC Info : Record= v=DMARC1;p=none;rua=mailto:dmarc_rua at emaildefense.proofpoint.com;ruf=mailto:dmarc_ruf at emaildefense.proofpoint.com;fo=1 Result= none Questions and more information: * You may need to take action if you're responsible for email flow from Oracle Cloud, OCI, or acquisition domains. Senders in this category are treated as external emails since they operate outside of Oracle's internal network. * If you are using the OCI Email Delivery Service, ensure you generate DKIM for your related Header From Domain - refer to https://docs.oracle.com/en-us/iaas/Content/Email/Tasks/configuredkim.htm more info can be found here https://confluence.oraclecorp.com/confluence/display/EMAIL/DMARC+for+Oracle+IT+and+Email+Delivery+Frequently+Asked+Questions * Refer to the DMARC FAQ https://confluence.oraclecorp.com/confluence/display/OITGLOBAL/DMARC+Global+FAQ to learn more about DMARC, if your emails may be affected, and actions you need to take. * If you have questions, reach out to the #oracle-owned-domains-dmarc Slack channel. Thank you in advance for your attention to this matter. Please review this PR to add back array-length comparison to AArch64 array-equals intrinsic. [JDK-8331098](https://bugs.openjdk.org/browse/JDK-8331098) removed the direct comparison of both arrays' length but doing so will cause the code to index out of bounds of the array payload. The root cause of the problem is: 1) the main comparison loops only compare the array lengths (indirectly) after reading at least 16 bytes from _both_ arrays; 2) only the length of the first array, `a1`, is checked before the main comparison loop. Consequently, we code may read past the end of the array payload if the second array is shorter than 16 bytes. The result of indexing out of the array bounds is dependent on where the array is allocated and what comes after it: the VM may crash because of segment violation if the object is at the end of the heap (or Eden?) and there is no padding after the object or it can cause the array comparison to be incorrect. Testing: - [x] tier1 (+CCP) - [x] tier1 (-CCP) - [x] tier2 (+CCP) - [x] tier2 (-CCP) ------------- Commit messages: - Add back length cmp Changes: https://git.openjdk.org/jdk/pull/29372/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29372&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373021 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29372.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29372/head:pull/29372 PR: https://git.openjdk.org/jdk/pull/29372 From aph at openjdk.org Thu Jan 22 20:29:50 2026 From: aph at openjdk.org (Andrew Haley) Date: Thu, 22 Jan 2026 20:29:50 GMT Subject: RFR: 8373021: aarch64: MacroAssembler::arrays_equals reads out of bounds In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 19:16:14 GMT, Cesar Soares Lucas wrote: > Please review this PR to add back array-length comparison to AArch64 array-equals intrinsic. > > [JDK-8331098](https://bugs.openjdk.org/browse/JDK-8331098) removed the direct comparison of both arrays' length but doing so will cause the code to index out of bounds of the array payload. The root cause of the problem is: 1) the main comparison loops only compare the array lengths (indirectly) after reading at least 16 bytes from _both_ arrays; 2) only the length of the first array, `a1`, is checked before the main comparison loop. Consequently, we code may read past the end of the array payload if the second array is shorter than 16 bytes. The result of indexing out of the array bounds is dependent on where the array is allocated and what comes after it: the VM may crash because of segment violation if the object is at the end of the heap (or Eden?) and there is no padding after the object or it can cause the array comparison to be incorrect. > > Testing: > > - [x] tier1 (+CCP) > - [x] tier1 (-CCP) > - [x] tier2 (+CCP) > - [x] tier2 (-CCP) @rkennke , can you please review this one? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29372#issuecomment-3786548636 From sparasa at openjdk.org Thu Jan 22 20:33:00 2026 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Thu, 22 Jan 2026 20:33:00 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v13] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 22:07:22 GMT, Derek White wrote: > I'm expecting to see a small regression in a write-only fill, and a larger improvement in write+read fill, but we didn't present the data in a way that makes it easy to compare those two tests. So we should present the graphed data as a table as well. Then we can discuss how common the write+read fill case is. Hi Derek, Please see the data for write-only fill operations for byte, short and intel below. Thanks, Vamsi ### Byte VectorBulkOperationsArray Fill Benchmark (ns/op) | Size | -OptimizeFill (JITed code) | +OptimizeFill (Masked store) | +OptimizeFill (Unmasked store - This PR) | Delta (masked vs. unmasked) -- | -- | -- | -- | -- | -- VectorBulkOperationsArray.fill_var_byte_arrays_fill | 0 | 0.649 | 0.65 | 0.653 | 0% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 1 | 2.372 | 2.803 | 2.588 | -8% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 2 | 2.37 | 2.596 | 2.471 | -5% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 3 | 2.813 | 2.591 | 2.495 | -4% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 4 | 3.086 | 2.598 | 2.757 | 6% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 5 | 3.343 | 2.59 | 3.644 | 41% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 6 | 3.549 | 2.589 | 3.536 | 37% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 7 | 3.716 | 2.616 | 3.695 | 41% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 8 | 4.854 | 2.59 | 3.252 | 26% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 9 | 4.771 | 2.587 | 3.591 | 39% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 10 | 4.78 | 2.595 | 3.542 | 36% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 11 | 4.532 | 2.589 | 3.669 | 42% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 12 | 4.164 | 2.592 | 3.505 | 35% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 13 | 4.348 | 2.589 | 3.655 | 41% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 14 | 4.703 | 2.594 | 3.637 | 40% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 15 | 4.973 | 2.591 | 3.754 | 45% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 16 | 5.498 | 2.593 | 3.062 | 18% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 17 | 5.305 | 2.588 | 3.611 | 40% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 18 | 5.081 | 2.59 | 3.649 | 41% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 19 | 4.782 | 2.586 | 3.642 | 41% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 20 | 4.458 | 2.588 | 3.565 | 38% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 21 | 4.66 | 2.586 | 3.741 | 45% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 22 | 5.112 | 2.591 | 3.681 | 42% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 23 | 5.522 | 2.607 | 3.742 | 44% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 24 | 6.02 | 2.589 | 3.27 | 26% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 25 | 4.84 | 2.588 | 3.691 | 43% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 26 | 4.81 | 2.589 | 3.674 | 42% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 27 | 4.695 | 2.591 | 3.761 | 45% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 28 | 4.828 | 2.589 | 3.578 | 38% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 29 | 4.531 | 2.586 | 3.762 | 45% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 30 | 5.38 | 2.59 | 3.713 | 43% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 31 | 4.948 | 2.588 | 3.887 | 50% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 32 | 5.21 | 2.589 | 2.861 | 11% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 33 | 6.258 | 2.824 | 3.377 | 20% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 34 | 4.992 | 2.829 | 3.388 | 20% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 35 | 4.918 | 2.812 | 3.577 | 27% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 36 | 4.647 | 2.814 | 3.351 | 19% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 37 | 4.762 | 2.815 | 3.775 | 34% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 38 | 4.93 | 2.819 | 3.76 | 33% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 39 | 5.137 | 2.821 | 3.954 | 40% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 40 | 5.377 | 2.815 | 3.483 | 24% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 41 | 5.373 | 2.815 | 3.777 | 34% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 42 | 5.309 | 2.815 | 3.77 | 34% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 43 | 5.157 | 2.815 | 3.835 | 36% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 44 | 4.862 | 2.82 | 3.743 | 33% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 45 | 4.957 | 2.816 | 3.882 | 38% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 46 | 5.207 | 2.814 | 3.85 | 37% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 47 | 5.526 | 2.813 | 4.023 | 43% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 48 | 5.995 | 2.813 | 3.251 | 16% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 49 | 5.923 | 2.815 | 3.775 | 34% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 50 | 5.703 | 2.813 | 3.77 | 34% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 51 | 5.424 | 2.82 | 3.874 | 37% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 52 | 5.087 | 2.625 | 3.869 | 47% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 53 | 5.226 | 2.814 | 3.993 | 42% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 54 | 5.542 | 2.814 | 3.8 | 35% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 55 | 5.931 | 2.813 | 3.971 | 41% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 56 | 6.458 | 2.63 | 3.464 | 32% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 57 | 6.408 | 2.809 | 3.881 | 38% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 58 | 6.137 | 2.822 | 3.925 | 39% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 59 | 5.794 | 2.816 | 3.972 | 41% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 60 | 5.339 | 2.815 | 3.82 | 36% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 61 | 5.512 | 2.811 | 3.966 | 41% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 62 | 5.85 | 2.812 | 4.042 | 44% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 63 | 6.304 | 2.811 | 4.119 | 47% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 64 | 6.684 | 2.809 | 3.128 | 11% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 65 | 6.699 | 2.867 | 3.695 | 29% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 66 | 6.471 | 2.883 | 3.669 | 27% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 67 | 6.046 | 2.854 | 3.7 | 30% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 68 | 5.621 | 2.871 | 3.576 | 25% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 69 | 5.788 | 2.862 | 4.064 | 42% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 70 | 5.925 | 2.853 | 4.043 | 42% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 71 | 5.711 | 2.865 | 4.17 | 46% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 72 | 5.482 | 2.872 | 3.758 | 31% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 73 | 5.79 | 2.857 | 4.097 | 43% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 74 | 6.15 | 2.864 | 4.056 | 42% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 75 | 6.543 | 2.88 | 4.149 | 44% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 76 | 6.846 | 2.868 | 3.984 | 39% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 77 | 7.223 | 2.862 | 4.164 | 45% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 78 | 7.218 | 2.869 | 4.102 | 43% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 79 | 7.726 | 2.89 | 4.253 | 47% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 80 | 7.835 | 2.856 | 3.497 | 22% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 81 | 7.132 | 2.84 | 4.096 | 44% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 82 | 7.006 | 2.861 | 4.165 | 46% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 83 | 6.804 | 2.865 | 4.154 | 45% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 84 | 6.605 | 2.869 | 4.022 | 40% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 85 | 6.428 | 2.859 | 4.154 | 45% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 86 | 6.275 | 2.88 | 4.095 | 42% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 87 | 6.129 | 2.875 | 4.28 | 49% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 88 | 6.013 | 2.867 | 3.73 | 30% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 89 | 6.367 | 2.872 | 4.13 | 44% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 90 | 6.816 | 2.863 | 4.117 | 44% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 91 | 7.147 | 2.876 | 4.189 | 46% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 92 | 7.487 | 2.87 | 4.063 | 42% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 93 | 7.723 | 2.866 | 4.211 | 47% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 94 | 7.708 | 2.893 | 4.235 | 46% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 95 | 8.122 | 2.922 | 4.367 | 49% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 96 | 8.145 | 2.872 | 3.344 | 16% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 97 | 7.961 | 3.132 | 3.956 | 26% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 98 | 7.744 | 3.106 | 3.784 | 22% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 99 | 7.252 | 3.12 | 3.878 | 24% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 100 | 7.137 | 3.135 | 3.767 | 20% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 101 | 6.872 | 3.125 | 4.374 | 40% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 102 | 6.743 | 3.108 | 4.266 | 37% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 103 | 6.607 | 3.019 | 4.432 | 47% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 104 | 6.544 | 3.108 | 3.942 | 27% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 105 | 6.986 | 3.054 | 4.368 | 43% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 106 | 7.263 | 3.12 | 4.334 | 39% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 107 | 7.612 | 3.022 | 4.387 | 45% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 108 | 7.99 | 3.088 | 4.184 | 35% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 109 | 8.268 | 3.112 | 4.391 | 41% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 110 | 8.261 | 3.406 | 4.358 | 28% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 111 | 8.378 | 3.092 | 4.489 | 45% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 112 | 8.415 | 3.089 | 3.776 | 22% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 113 | 8.3 | 3.125 | 4.482 | 43% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 114 | 8.04 | 3.084 | 4.301 | 39% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 115 | 8.38 | 3.163 | 4.342 | 37% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 116 | 7.726 | 3.077 | 4.216 | 37% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 117 | 7.274 | 3.021 | 4.387 | 45% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 118 | 7.086 | 3.065 | 4.256 | 39% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 119 | 6.948 | 3.224 | 4.456 | 38% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 120 | 6.922 | 3.102 | 3.939 | 27% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 121 | 7.33 | 3.104 | 4.37 | 41% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 122 | 7.67 | 3.114 | 4.821 | 55% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 123 | 8.106 | 3.111 | 4.47 | 44% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 124 | 8.243 | 3.102 | 4.317 | 39% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 125 | 8.507 | 3.099 | 4.469 | 44% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 126 | 8.692 | 3.114 | 4.444 | 43% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 127 | 8.658 | 3.127 | 4.589 | 47% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 128 | 8.789 | 3.102 | 3.532 | 14% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 129 | 8.516 | 4.017 | 5.637 | 40% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 130 | 8.337 | 3.998 | 5.549 | 39% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 131 | 8.197 | 4.017 | 5.669 | 41% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 132 | 7.973 | 4.031 | 5.406 | 34% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 133 | 7.76 | 4.649 | 5.774 | 24% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 134 | 7.511 | 4.648 | 5.383 | 16% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 135 | 7.276 | 4.355 | 5.413 | 24% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 136 | 7.203 | 4.33 | 5.658 | 31% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 137 | 7.548 | 4.306 | 5.621 | 31% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 138 | 7.897 | 4.518 | 5.541 | 23% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 139 | 8.324 | 4.646 | 5.319 | 14% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 140 | 8.534 | 4.305 | 5.446 | 27% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 141 | 8.697 | 4.163 | 5.364 | 29% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 142 | 8.861 | 4.392 | 5.249 | 20% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 143 | 8.91 | 4.144 | 5.671 | 37% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 144 | 8.988 | 4.048 | 5.497 | 36% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 145 | 8.756 | 4.074 | 5.571 | 37% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 146 | 8.53 | 4.361 | 5.34 | 22% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 147 | 8.375 | 4.599 | 5.379 | 17% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 148 | 8.148 | 4.41 | 5.437 | 23% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 149 | 8.665 | 4.101 | 5.394 | 32% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 150 | 8.885 | 4.127 | 5.418 | 31% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 151 | 9.023 | 4.082 | 5.578 | 37% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 152 | 9.218 | 4.052 | 5.348 | 32% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 153 | 9.454 | 4.091 | 5.5 | 34% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 154 | 9.74 | 4.259 | 5.469 | 28% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 155 | 9.993 | 4.096 | 5.427 | 32% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 156 | 10.525 | 4.186 | 5.373 | 28% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 157 | 10.607 | 4.093 | 5.43 | 33% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 158 | 10.863 | 4.068 | 5.315 | 31% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 159 | 11.333 | 4.056 | 5.463 | 35% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 160 | 11.485 | 4.081 | 5.493 | 35% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 161 | 10.983 | 4.068 | 5.196 | 28% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 162 | 10.496 | 4.164 | 5.266 | 26% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 163 | 10.312 | 4.091 | 5.274 | 29% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 164 | 10.223 | 4.254 | 5.339 | 26% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 165 | 10.034 | 4.085 | 5.408 | 32% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 166 | 9.883 | 4.171 | 5.349 | 28% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 167 | 9.825 | 4.121 | 5.335 | 29% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 168 | 9.722 | 4.063 | 5.428 | 34% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 169 | 9.578 | 4.373 | 5.405 | 24% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 170 | 10.637 | 4.207 | 5.327 | 27% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 171 | 10.223 | 4.223 | 5.407 | 28% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 172 | 9.789 | 4.23 | 5.42 | 28% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 173 | 8.874 | 4.441 | 5.406 | 22% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 174 | 8.98 | 4.373 | 5.396 | 23% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 175 | 8.503 | 4.476 | 5.51 | 23% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 176 | 9.427 | 4.356 | 5.47 | 26% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 177 | 8.081 | 4.162 | 5.524 | 33% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 178 | 8.263 | 4.54 | 5.475 | 21% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 179 | 8.566 | 4.43 | 5.537 | 25% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 180 | 8.697 | 4.268 | 5.555 | 30% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 181 | 8.929 | 4.541 | 5.59 | 23% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 182 | 9.135 | 4.208 | 5.577 | 33% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 183 | 9.338 | 4.512 | 5.586 | 24% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 184 | 9.617 | 4.514 | 5.601 | 24% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 185 | 9.74 | 4.4 | 5.429 | 23% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 186 | 10.071 | 4.539 | 5.623 | 24% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 187 | 10.36 | 4.404 | 5.474 | 24% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 188 | 10.388 | 4.41 | 5.476 | 24% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 189 | 10.653 | 4.458 | 5.653 | 27% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 190 | 10.968 | 4.5 | 5.618 | 25% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 191 | 11.156 | 4.492 | 5.626 | 25% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 192 | 11.458 | 4.536 | 5.519 | 22% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 193 | 10.922 | 4.511 | 5.256 | 17% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 194 | 10.739 | 4.232 | 5.501 | 30% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 195 | 10.594 | 4.552 | 5.62 | 23% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 196 | 10.368 | 4.568 | 5.632 | 23% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 197 | 10.264 | 4.535 | 5.678 | 25% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 198 | 10.981 | 4.602 | 5.652 | 23% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 199 | 11.254 | 4.592 | 5.72 | 25% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 200 | 11.159 | 4.611 | 5.736 | 24% `[continued]` ------------- PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3786547697 From sparasa at openjdk.org Thu Jan 22 20:33:03 2026 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Thu, 22 Jan 2026 20:33:03 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v13] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 20:14:31 GMT, Srinivas Vamsi Parasa 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: > > Update ALL of ArraysFill JMH micro ### Short VectorBulkOperationsArray Fill Benchmark (ns/op) | Size | -OptimizeFill (JITed code) | +OptimizeFill (Masked store) | +OptimizeFill (Unmasked store - This PR) | Delta (masked vs. unmasked) -- | -- | -- | -- | -- | -- VectorBulkOperationsArray.fill_var_short_arrays_fill | 0 | 0.649 | 0.65 | 0.65 | 0% VectorBulkOperationsArray.fill_var_short_arrays_fill | 1 | 2.366 | 2.806 | 3.025 | 8% VectorBulkOperationsArray.fill_var_short_arrays_fill | 2 | 2.37 | 2.587 | 2.789 | 8% VectorBulkOperationsArray.fill_var_short_arrays_fill | 3 | 2.825 | 2.587 | 3.299 | 28% VectorBulkOperationsArray.fill_var_short_arrays_fill | 4 | 3.09 | 2.59 | 3.024 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 5 | 3.336 | 2.589 | 3.338 | 29% VectorBulkOperationsArray.fill_var_short_arrays_fill | 6 | 3.544 | 2.596 | 3.189 | 23% VectorBulkOperationsArray.fill_var_short_arrays_fill | 7 | 3.712 | 2.719 | 3.449 | 27% VectorBulkOperationsArray.fill_var_short_arrays_fill | 8 | 4.883 | 2.589 | 2.86 | 10% VectorBulkOperationsArray.fill_var_short_arrays_fill | 9 | 4.817 | 2.589 | 3.355 | 30% VectorBulkOperationsArray.fill_var_short_arrays_fill | 10 | 4.774 | 2.585 | 3.16 | 22% VectorBulkOperationsArray.fill_var_short_arrays_fill | 11 | 4.514 | 2.589 | 3.431 | 33% VectorBulkOperationsArray.fill_var_short_arrays_fill | 12 | 4.097 | 2.587 | 3.111 | 20% VectorBulkOperationsArray.fill_var_short_arrays_fill | 13 | 4.351 | 2.599 | 3.393 | 31% VectorBulkOperationsArray.fill_var_short_arrays_fill | 14 | 4.674 | 2.588 | 3.319 | 28% VectorBulkOperationsArray.fill_var_short_arrays_fill | 15 | 4.981 | 2.586 | 3.542 | 37% VectorBulkOperationsArray.fill_var_short_arrays_fill | 16 | 5.406 | 2.586 | 2.833 | 10% VectorBulkOperationsArray.fill_var_short_arrays_fill | 17 | 5.307 | 2.8 | 3.202 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 18 | 5.093 | 2.811 | 3.051 | 9% VectorBulkOperationsArray.fill_var_short_arrays_fill | 19 | 4.68 | 2.817 | 3.568 | 27% VectorBulkOperationsArray.fill_var_short_arrays_fill | 20 | 4.528 | 2.81 | 3.294 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 21 | 4.633 | 2.814 | 3.589 | 28% VectorBulkOperationsArray.fill_var_short_arrays_fill | 22 | 5.102 | 2.809 | 3.495 | 24% VectorBulkOperationsArray.fill_var_short_arrays_fill | 23 | 5.521 | 2.812 | 3.717 | 32% VectorBulkOperationsArray.fill_var_short_arrays_fill | 24 | 6.205 | 2.813 | 3.094 | 10% VectorBulkOperationsArray.fill_var_short_arrays_fill | 25 | 5.92 | 2.816 | 3.58 | 27% VectorBulkOperationsArray.fill_var_short_arrays_fill | 26 | 4.805 | 2.87 | 3.495 | 22% VectorBulkOperationsArray.fill_var_short_arrays_fill | 27 | 4.744 | 2.815 | 3.712 | 32% VectorBulkOperationsArray.fill_var_short_arrays_fill | 28 | 4.45 | 2.811 | 3.361 | 20% VectorBulkOperationsArray.fill_var_short_arrays_fill | 29 | 4.59 | 2.813 | 3.734 | 33% VectorBulkOperationsArray.fill_var_short_arrays_fill | 30 | 4.781 | 2.812 | 3.589 | 28% VectorBulkOperationsArray.fill_var_short_arrays_fill | 31 | 4.992 | 2.81 | 3.817 | 36% VectorBulkOperationsArray.fill_var_short_arrays_fill | 32 | 5.249 | 2.813 | 3.143 | 12% VectorBulkOperationsArray.fill_var_short_arrays_fill | 33 | 5.205 | 3.285 | 3.323 | 1% VectorBulkOperationsArray.fill_var_short_arrays_fill | 34 | 6.086 | 2.858 | 3.104 | 9% VectorBulkOperationsArray.fill_var_short_arrays_fill | 35 | 4.977 | 2.855 | 3.756 | 32% VectorBulkOperationsArray.fill_var_short_arrays_fill | 36 | 4.71 | 2.864 | 3.39 | 18% VectorBulkOperationsArray.fill_var_short_arrays_fill | 37 | 4.822 | 2.887 | 3.815 | 32% VectorBulkOperationsArray.fill_var_short_arrays_fill | 38 | 5.007 | 2.86 | 3.602 | 26% VectorBulkOperationsArray.fill_var_short_arrays_fill | 39 | 5.197 | 2.865 | 3.806 | 33% VectorBulkOperationsArray.fill_var_short_arrays_fill | 40 | 5.5 | 2.862 | 3.267 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 41 | 5.39 | 2.891 | 3.807 | 32% VectorBulkOperationsArray.fill_var_short_arrays_fill | 42 | 5.358 | 2.864 | 3.527 | 23% VectorBulkOperationsArray.fill_var_short_arrays_fill | 43 | 5.214 | 2.871 | 3.801 | 32% VectorBulkOperationsArray.fill_var_short_arrays_fill | 44 | 4.901 | 2.87 | 3.624 | 26% VectorBulkOperationsArray.fill_var_short_arrays_fill | 45 | 5.014 | 2.861 | 3.782 | 32% VectorBulkOperationsArray.fill_var_short_arrays_fill | 46 | 5.252 | 2.849 | 3.717 | 30% VectorBulkOperationsArray.fill_var_short_arrays_fill | 47 | 5.51 | 2.85 | 3.951 | 39% VectorBulkOperationsArray.fill_var_short_arrays_fill | 48 | 5.92 | 2.848 | 3.227 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 49 | 5.896 | 3.417 | 3.558 | 4% VectorBulkOperationsArray.fill_var_short_arrays_fill | 50 | 5.793 | 3.103 | 3.41 | 10% VectorBulkOperationsArray.fill_var_short_arrays_fill | 51 | 5.485 | 3.138 | 3.979 | 27% VectorBulkOperationsArray.fill_var_short_arrays_fill | 52 | 5.137 | 3.117 | 3.652 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 53 | 5.264 | 3.107 | 4 | 29% VectorBulkOperationsArray.fill_var_short_arrays_fill | 54 | 5.563 | 3.113 | 3.835 | 23% VectorBulkOperationsArray.fill_var_short_arrays_fill | 55 | 5.945 | 3.099 | 4.045 | 31% VectorBulkOperationsArray.fill_var_short_arrays_fill | 56 | 6.402 | 3.124 | 3.537 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 57 | 6.347 | 3.175 | 4.029 | 27% VectorBulkOperationsArray.fill_var_short_arrays_fill | 58 | 6.172 | 3.155 | 3.786 | 20% VectorBulkOperationsArray.fill_var_short_arrays_fill | 59 | 5.785 | 3.129 | 4.039 | 29% VectorBulkOperationsArray.fill_var_short_arrays_fill | 60 | 5.405 | 3.124 | 3.752 | 20% VectorBulkOperationsArray.fill_var_short_arrays_fill | 61 | 5.541 | 3.12 | 4.044 | 30% VectorBulkOperationsArray.fill_var_short_arrays_fill | 62 | 5.921 | 3.132 | 3.987 | 27% VectorBulkOperationsArray.fill_var_short_arrays_fill | 63 | 6.239 | 3.105 | 4.202 | 35% VectorBulkOperationsArray.fill_var_short_arrays_fill | 64 | 6.891 | 3.146 | 3.13 | -1% VectorBulkOperationsArray.fill_var_short_arrays_fill | 65 | 6.81 | 4.559 | 5.07 | 11% VectorBulkOperationsArray.fill_var_short_arrays_fill | 66 | 6.489 | 4.523 | 5.084 | 12% VectorBulkOperationsArray.fill_var_short_arrays_fill | 67 | 6.116 | 4.413 | 5.069 | 15% VectorBulkOperationsArray.fill_var_short_arrays_fill | 68 | 5.669 | 4.462 | 5.06 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 69 | 5.838 | 4.408 | 5.084 | 15% VectorBulkOperationsArray.fill_var_short_arrays_fill | 70 | 6.618 | 4.386 | 5.037 | 15% VectorBulkOperationsArray.fill_var_short_arrays_fill | 71 | 6.249 | 4.407 | 5.054 | 15% VectorBulkOperationsArray.fill_var_short_arrays_fill | 72 | 6.183 | 4.295 | 5.055 | 18% VectorBulkOperationsArray.fill_var_short_arrays_fill | 73 | 6.289 | 4.362 | 4.885 | 12% VectorBulkOperationsArray.fill_var_short_arrays_fill | 74 | 6.678 | 4.232 | 4.958 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 75 | 6.909 | 4.219 | 4.989 | 18% VectorBulkOperationsArray.fill_var_short_arrays_fill | 76 | 7.098 | 4.207 | 4.978 | 18% VectorBulkOperationsArray.fill_var_short_arrays_fill | 77 | 7.463 | 4.152 | 4.96 | 19% VectorBulkOperationsArray.fill_var_short_arrays_fill | 78 | 7.66 | 4.113 | 4.976 | 21% VectorBulkOperationsArray.fill_var_short_arrays_fill | 79 | 8.058 | 4.079 | 4.844 | 19% VectorBulkOperationsArray.fill_var_short_arrays_fill | 80 | 7.933 | 4.167 | 4.884 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 81 | 7.713 | 4.189 | 4.895 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 82 | 7.562 | 4.171 | 4.946 | 19% VectorBulkOperationsArray.fill_var_short_arrays_fill | 83 | 7.507 | 4.241 | 4.979 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 84 | 7.252 | 4.252 | 4.958 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 85 | 7.195 | 4.277 | 5 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 86 | 6.871 | 4.293 | 5.004 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 87 | 6.884 | 4.313 | 4.996 | 16% VectorBulkOperationsArray.fill_var_short_arrays_fill | 88 | 6.754 | 4.338 | 5.029 | 16% VectorBulkOperationsArray.fill_var_short_arrays_fill | 89 | 6.711 | 4.36 | 5.017 | 15% VectorBulkOperationsArray.fill_var_short_arrays_fill | 90 | 7.157 | 4.393 | 5.058 | 15% VectorBulkOperationsArray.fill_var_short_arrays_fill | 91 | 7.299 | 4.281 | 5.062 | 18% VectorBulkOperationsArray.fill_var_short_arrays_fill | 92 | 7.467 | 4.435 | 5.017 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 93 | 7.706 | 4.426 | 5.133 | 16% VectorBulkOperationsArray.fill_var_short_arrays_fill | 94 | 7.957 | 4.491 | 5.101 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 95 | 8.253 | 4.475 | 5.139 | 15% VectorBulkOperationsArray.fill_var_short_arrays_fill | 96 | 8.396 | 4.507 | 5.128 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 97 | 8.14 | 4.522 | 5.146 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 98 | 7.935 | 4.564 | 5.172 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 99 | 7.859 | 4.575 | 5.208 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 100 | 7.769 | 4.555 | 5.223 | 15% VectorBulkOperationsArray.fill_var_short_arrays_fill | 101 | 7.533 | 4.587 | 5.212 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 102 | 7.593 | 4.606 | 5.236 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 103 | 7.363 | 4.606 | 5.264 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 104 | 7.355 | 4.639 | 5.257 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 105 | 7.645 | 4.659 | 5.191 | 11% VectorBulkOperationsArray.fill_var_short_arrays_fill | 106 | 8.041 | 4.668 | 5.302 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 107 | 7.872 | 4.682 | 5.322 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 108 | 8.339 | 4.729 | 5.303 | 12% VectorBulkOperationsArray.fill_var_short_arrays_fill | 109 | 8.609 | 4.703 | 5.313 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 110 | 8.804 | 4.74 | 5.347 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 111 | 9.058 | 4.737 | 5.377 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 112 | 9.164 | 4.767 | 5.366 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 113 | 8.673 | 4.637 | 5.455 | 18% VectorBulkOperationsArray.fill_var_short_arrays_fill | 114 | 8.537 | 4.695 | 5.479 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 115 | 8.438 | 4.694 | 5.458 | 16% VectorBulkOperationsArray.fill_var_short_arrays_fill | 116 | 8.232 | 4.706 | 5.458 | 16% VectorBulkOperationsArray.fill_var_short_arrays_fill | 117 | 8.019 | 4.689 | 5.465 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 118 | 8.089 | 4.719 | 5.483 | 16% VectorBulkOperationsArray.fill_var_short_arrays_fill | 119 | 8.155 | 4.727 | 5.544 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 120 | 7.936 | 4.747 | 5.495 | 16% VectorBulkOperationsArray.fill_var_short_arrays_fill | 121 | 7.986 | 4.764 | 5.521 | 16% VectorBulkOperationsArray.fill_var_short_arrays_fill | 122 | 8.168 | 4.845 | 5.541 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 123 | 8.551 | 4.784 | 5.546 | 16% VectorBulkOperationsArray.fill_var_short_arrays_fill | 124 | 8.753 | 4.845 | 5.522 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 125 | 9.028 | 4.822 | 5.553 | 15% VectorBulkOperationsArray.fill_var_short_arrays_fill | 126 | 9.26 | 4.864 | 5.596 | 15% VectorBulkOperationsArray.fill_var_short_arrays_fill | 127 | 9.523 | 4.817 | 5.574 | 16% VectorBulkOperationsArray.fill_var_short_arrays_fill | 128 | 9.654 | 4.8 | 5.492 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 129 | 9.299 | 4.74 | 5.464 | 15% VectorBulkOperationsArray.fill_var_short_arrays_fill | 130 | 9.143 | 4.705 | 5.479 | 16% VectorBulkOperationsArray.fill_var_short_arrays_fill | 131 | 8.721 | 4.685 | 5.451 | 16% VectorBulkOperationsArray.fill_var_short_arrays_fill | 132 | 8.761 | 4.433 | 5.409 | 22% VectorBulkOperationsArray.fill_var_short_arrays_fill | 133 | 8.424 | 4.624 | 5.412 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 134 | 8.232 | 4.599 | 5.379 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 135 | 7.991 | 4.579 | 5.364 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 136 | 7.915 | 4.555 | 5.345 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 137 | 7.843 | 4.527 | 5.319 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 138 | 7.997 | 4.477 | 5.297 | 18% VectorBulkOperationsArray.fill_var_short_arrays_fill | 139 | 8.433 | 4.476 | 5.245 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 140 | 8.673 | 4.41 | 5.21 | 18% VectorBulkOperationsArray.fill_var_short_arrays_fill | 141 | 8.918 | 4.391 | 5.186 | 18% VectorBulkOperationsArray.fill_var_short_arrays_fill | 142 | 9.272 | 4.374 | 5.183 | 18% VectorBulkOperationsArray.fill_var_short_arrays_fill | 143 | 9.421 | 4.364 | 5.05 | 16% VectorBulkOperationsArray.fill_var_short_arrays_fill | 144 | 9.629 | 4.345 | 5.087 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 145 | 9.233 | 4.453 | 5.078 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 146 | 9.039 | 4.209 | 5.172 | 23% VectorBulkOperationsArray.fill_var_short_arrays_fill | 147 | 9.008 | 4.532 | 5.175 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 148 | 8.763 | 4.505 | 5.147 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 149 | 8.992 | 4.584 | 5.258 | 15% VectorBulkOperationsArray.fill_var_short_arrays_fill | 150 | 9.294 | 4.562 | 5.221 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 151 | 9.258 | 4.582 | 5.215 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 152 | 9.516 | 4.582 | 5.213 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 153 | 9.672 | 4.632 | 5.216 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 154 | 9.997 | 4.664 | 5.265 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 155 | 10.182 | 4.673 | 5.255 | 12% VectorBulkOperationsArray.fill_var_short_arrays_fill | 156 | 10.651 | 4.671 | 5.272 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 157 | 11.081 | 4.705 | 5.293 | 12% VectorBulkOperationsArray.fill_var_short_arrays_fill | 158 | 10.959 | 4.794 | 5.315 | 11% VectorBulkOperationsArray.fill_var_short_arrays_fill | 159 | 11.202 | 4.836 | 5.308 | 10% VectorBulkOperationsArray.fill_var_short_arrays_fill | 160 | 11.309 | 4.799 | 5.356 | 12% VectorBulkOperationsArray.fill_var_short_arrays_fill | 161 | 11.023 | 4.816 | 5.352 | 11% VectorBulkOperationsArray.fill_var_short_arrays_fill | 162 | 10.758 | 4.936 | 5.358 | 9% VectorBulkOperationsArray.fill_var_short_arrays_fill | 163 | 10.594 | 4.393 | 5.37 | 22% VectorBulkOperationsArray.fill_var_short_arrays_fill | 164 | 10.48 | 4.938 | 5.417 | 10% VectorBulkOperationsArray.fill_var_short_arrays_fill | 165 | 10.375 | 4.919 | 5.433 | 10% VectorBulkOperationsArray.fill_var_short_arrays_fill | 166 | 10.345 | 4.875 | 5.42 | 11% VectorBulkOperationsArray.fill_var_short_arrays_fill | 167 | 10.514 | 4.911 | 5.454 | 11% VectorBulkOperationsArray.fill_var_short_arrays_fill | 168 | 10.633 | 4.912 | 5.472 | 11% VectorBulkOperationsArray.fill_var_short_arrays_fill | 169 | 10.114 | 4.925 | 5.48 | 11% VectorBulkOperationsArray.fill_var_short_arrays_fill | 170 | 10.069 | 4.973 | 5.51 | 11% VectorBulkOperationsArray.fill_var_short_arrays_fill | 171 | 9.514 | 5.015 | 5.485 | 9% VectorBulkOperationsArray.fill_var_short_arrays_fill | 172 | 9.408 | 5.08 | 5.499 | 8% VectorBulkOperationsArray.fill_var_short_arrays_fill | 173 | 9.071 | 5.056 | 5.534 | 9% VectorBulkOperationsArray.fill_var_short_arrays_fill | 174 | 8.896 | 5.065 | 5.531 | 9% VectorBulkOperationsArray.fill_var_short_arrays_fill | 175 | 8.56 | 5.109 | 5.532 | 8% VectorBulkOperationsArray.fill_var_short_arrays_fill | 176 | 8.453 | 5.099 | 5.533 | 9% VectorBulkOperationsArray.fill_var_short_arrays_fill | 177 | 8.525 | 4.979 | 5.606 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 178 | 8.782 | 4.98 | 5.663 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 179 | 8.944 | 5.012 | 5.619 | 12% VectorBulkOperationsArray.fill_var_short_arrays_fill | 180 | 9.08 | 5.018 | 5.646 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 181 | 9.239 | 5.037 | 5.678 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 182 | 9.36 | 5.057 | 5.686 | 12% VectorBulkOperationsArray.fill_var_short_arrays_fill | 183 | 9.658 | 5.052 | 5.667 | 12% VectorBulkOperationsArray.fill_var_short_arrays_fill | 184 | 9.994 | 5.085 | 5.669 | 11% VectorBulkOperationsArray.fill_var_short_arrays_fill | 185 | 9.996 | 5.08 | 5.703 | 12% VectorBulkOperationsArray.fill_var_short_arrays_fill | 186 | 10.3 | 5.103 | 5.735 | 12% VectorBulkOperationsArray.fill_var_short_arrays_fill | 187 | 10.674 | 5.11 | 5.717 | 12% VectorBulkOperationsArray.fill_var_short_arrays_fill | 188 | 10.753 | 5.101 | 5.723 | 12% VectorBulkOperationsArray.fill_var_short_arrays_fill | 189 | 10.936 | 5.098 | 5.776 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 190 | 11.206 | 5.101 | 5.75 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 191 | 11.383 | 5.099 | 5.788 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 192 | 11.619 | 5.084 | 5.727 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 193 | 11.266 | 5.032 | 5.702 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 194 | 11.263 | 4.976 | 5.678 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 195 | 11.172 | 4.997 | 5.658 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 196 | 10.891 | 4.962 | 5.633 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 197 | 11.311 | 4.907 | 5.588 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 198 | 11.486 | 4.887 | 5.552 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 199 | 11.348 | 4.874 | 5.623 | 15% VectorBulkOperationsArray.fill_var_short_arrays_fill | 200 | 11.102 | 4.823 | 5.511 | 14% `[Continued]` ### Int VectorBulkOperationsArray Fill Benchmark (ns/op) | Size | -OptimizeFill (JITed code) | +OptimizeFill (Masked store) | +OptimizeFill (Unmasked store - This PR) | Delta (masked vs. unmasked) -- | -- | -- | -- | -- | -- VectorBulkOperationsArray.fill_var_int_arrays_fill | 0 | 0.649 | 0.651 | 0.655 | 1% VectorBulkOperationsArray.fill_var_int_arrays_fill | 1 | 2.371 | 2.801 | 2.827 | 1% VectorBulkOperationsArray.fill_var_int_arrays_fill | 2 | 2.374 | 2.585 | 2.942 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 3 | 2.809 | 2.589 | 3.094 | 16% VectorBulkOperationsArray.fill_var_int_arrays_fill | 4 | 3.356 | 2.587 | 2.852 | 9% VectorBulkOperationsArray.fill_var_int_arrays_fill | 5 | 3.531 | 2.588 | 3.158 | 18% VectorBulkOperationsArray.fill_var_int_arrays_fill | 6 | 3.747 | 2.589 | 3.118 | 17% VectorBulkOperationsArray.fill_var_int_arrays_fill | 7 | 3.989 | 2.589 | 3.332 | 22% VectorBulkOperationsArray.fill_var_int_arrays_fill | 8 | 5.047 | 2.588 | 2.832 | 9% VectorBulkOperationsArray.fill_var_int_arrays_fill | 9 | 4.79 | 2.845 | 3.056 | 7% VectorBulkOperationsArray.fill_var_int_arrays_fill | 10 | 4.982 | 2.85 | 3.274 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 11 | 4.551 | 2.852 | 3.521 | 19% VectorBulkOperationsArray.fill_var_int_arrays_fill | 12 | 4.281 | 2.853 | 3.12 | 9% VectorBulkOperationsArray.fill_var_int_arrays_fill | 13 | 4.391 | 2.894 | 3.499 | 17% VectorBulkOperationsArray.fill_var_int_arrays_fill | 14 | 4.909 | 2.848 | 3.339 | 15% VectorBulkOperationsArray.fill_var_int_arrays_fill | 15 | 5.269 | 2.853 | 3.524 | 19% VectorBulkOperationsArray.fill_var_int_arrays_fill | 16 | 5.663 | 2.836 | 3.101 | 9% VectorBulkOperationsArray.fill_var_int_arrays_fill | 17 | 5.553 | 2.924 | 3.111 | 6% VectorBulkOperationsArray.fill_var_int_arrays_fill | 18 | 5.105 | 2.933 | 3.358 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 19 | 5.09 | 2.942 | 3.583 | 18% VectorBulkOperationsArray.fill_var_int_arrays_fill | 20 | 4.457 | 2.927 | 3.272 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 21 | 4.745 | 3.104 | 3.598 | 14% VectorBulkOperationsArray.fill_var_int_arrays_fill | 22 | 4.949 | 2.932 | 3.481 | 16% VectorBulkOperationsArray.fill_var_int_arrays_fill | 23 | 4.992 | 2.939 | 3.761 | 22% VectorBulkOperationsArray.fill_var_int_arrays_fill | 24 | 5.198 | 2.92 | 3.205 | 9% VectorBulkOperationsArray.fill_var_int_arrays_fill | 25 | 5.097 | 3.116 | 3.387 | 8% VectorBulkOperationsArray.fill_var_int_arrays_fill | 26 | 5.069 | 3.015 | 3.63 | 17% VectorBulkOperationsArray.fill_var_int_arrays_fill | 27 | 5.125 | 3.106 | 3.858 | 19% VectorBulkOperationsArray.fill_var_int_arrays_fill | 28 | 4.759 | 3.111 | 3.514 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 29 | 4.796 | 3.115 | 3.841 | 19% VectorBulkOperationsArray.fill_var_int_arrays_fill | 30 | 5.129 | 3.127 | 3.71 | 16% VectorBulkOperationsArray.fill_var_int_arrays_fill | 31 | 5.671 | 3.247 | 3.97 | 18% VectorBulkOperationsArray.fill_var_int_arrays_fill | 32 | 5.401 | 3.122 | 3.518 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 33 | 5.364 | 4.224 | 4.905 | 14% VectorBulkOperationsArray.fill_var_int_arrays_fill | 34 | 5.231 | 4.189 | 4.877 | 14% VectorBulkOperationsArray.fill_var_int_arrays_fill | 35 | 5.093 | 4.213 | 4.853 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 36 | 4.911 | 4.083 | 4.779 | 15% VectorBulkOperationsArray.fill_var_int_arrays_fill | 37 | 5.045 | 4.088 | 4.699 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 38 | 5.331 | 4.068 | 4.728 | 14% VectorBulkOperationsArray.fill_var_int_arrays_fill | 39 | 5.491 | 4.117 | 4.675 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 40 | 5.741 | 4.077 | 4.596 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 41 | 5.706 | 4.133 | 4.804 | 14% VectorBulkOperationsArray.fill_var_int_arrays_fill | 42 | 5.544 | 4.172 | 4.819 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 43 | 5.32 | 4.233 | 4.811 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 44 | 5.144 | 4.261 | 4.733 | 10% VectorBulkOperationsArray.fill_var_int_arrays_fill | 45 | 5.258 | 4.324 | 4.847 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 46 | 5.49 | 4.337 | 4.885 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 47 | 5.736 | 4.414 | 4.938 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 48 | 5.957 | 4.274 | 4.963 | 14% VectorBulkOperationsArray.fill_var_int_arrays_fill | 49 | 6.035 | 4.442 | 4.96 | 10% VectorBulkOperationsArray.fill_var_int_arrays_fill | 50 | 5.753 | 4.46 | 5.031 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 51 | 5.622 | 4.486 | 5.124 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 52 | 5.407 | 4.491 | 5.132 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 53 | 5.524 | 4.518 | 5.181 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 54 | 5.717 | 4.536 | 5.186 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 55 | 5.971 | 4.557 | 5.139 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 56 | 6.209 | 4.586 | 5.203 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 57 | 6.07 | 4.672 | 5.35 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 58 | 6.041 | 4.64 | 5.37 | 14% VectorBulkOperationsArray.fill_var_int_arrays_fill | 59 | 6.18 | 4.663 | 5.123 | 9% VectorBulkOperationsArray.fill_var_int_arrays_fill | 60 | 5.638 | 4.709 | 5.349 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 61 | 5.751 | 4.724 | 5.398 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 62 | 6.056 | 4.756 | 5.426 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 63 | 6.295 | 4.743 | 5.454 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 64 | 6.523 | 4.639 | 5.288 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 65 | 6.432 | 4.597 | 5.332 | 14% VectorBulkOperationsArray.fill_var_int_arrays_fill | 66 | 6.407 | 4.537 | 5.054 | 10% VectorBulkOperationsArray.fill_var_int_arrays_fill | 67 | 6.12 | 4.533 | 5.19 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 68 | 5.881 | 4.424 | 5.094 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 69 | 5.981 | 4.357 | 5.028 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 70 | 6.133 | 4.309 | 4.88 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 71 | 5.996 | 4.243 | 4.861 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 72 | 5.719 | 4.29 | 4.905 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 73 | 5.977 | 4.352 | 4.975 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 74 | 7.849 | 4.391 | 4.99 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 75 | 6.44 | 4.481 | 5.051 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 76 | 6.729 | 4.479 | 5.1 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 77 | 7.092 | 4.524 | 5.156 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 78 | 7.269 | 4.56 | 5.109 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 79 | 7.464 | 4.62 | 5.131 | 10% VectorBulkOperationsArray.fill_var_int_arrays_fill | 80 | 7.634 | 4.669 | 5.167 | 10% VectorBulkOperationsArray.fill_var_int_arrays_fill | 81 | 7.284 | 4.673 | 5.064 | 8% VectorBulkOperationsArray.fill_var_int_arrays_fill | 82 | 7.157 | 4.671 | 5.227 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 83 | 7.003 | 4.698 | 5.271 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 84 | 6.67 | 4.723 | 5.283 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 85 | 6.752 | 4.793 | 5.812 | 18% VectorBulkOperationsArray.fill_var_int_arrays_fill | 86 | 6.41 | 4.742 | 5.329 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 87 | 6.21 | 4.801 | 5.404 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 88 | 6.07 | 4.798 | 5.398 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 89 | 6.405 | 4.863 | 5.482 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 90 | 6.516 | 4.885 | 5.566 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 91 | 6.705 | 4.912 | 5.565 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 92 | 7.511 | 4.913 | 5.587 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 93 | 7.492 | 4.942 | 5.595 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 94 | 7.565 | 4.978 | 5.62 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 95 | 8.017 | 5.016 | 5.667 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 96 | 8.022 | 4.841 | 5.558 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 97 | 7.767 | 4.793 | 5.536 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 98 | 7.496 | 4.98 | 5.91 | 16% VectorBulkOperationsArray.fill_var_int_arrays_fill | 99 | 7.354 | 4.849 | 5.363 | 10% VectorBulkOperationsArray.fill_var_int_arrays_fill | 100 | 7.106 | 4.649 | 5.312 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 101 | 7.083 | 4.583 | 5.265 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 102 | 6.838 | 4.528 | 5.221 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 103 | 6.752 | 4.457 | 5.099 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 104 | 6.588 | 4.508 | 5.164 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 105 | 6.844 | 4.663 | 5.209 | 10% VectorBulkOperationsArray.fill_var_int_arrays_fill | 106 | 7.066 | 4.617 | 5.262 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 107 | 7.151 | 4.677 | 5.31 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 108 | 7.388 | 4.716 | 5.347 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 109 | 8.063 | 4.796 | 5.369 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 110 | 8.167 | 4.783 | 5.412 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 111 | 8.376 | 4.848 | 5.438 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 112 | 8.389 | 4.885 | 5.481 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 113 | 8.096 | 4.867 | 5.49 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 114 | 7.874 | 4.896 | 5.527 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 115 | 7.707 | 5.061 | 5.586 | 9% VectorBulkOperationsArray.fill_var_int_arrays_fill | 116 | 7.709 | 4.959 | 5.606 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 117 | 7.364 | 4.985 | 5.596 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 118 | 7.32 | 4.981 | 5.638 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 119 | 7.379 | 5.003 | 5.726 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 120 | 6.683 | 5.034 | 5.664 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 121 | 6.902 | 5.061 | 5.732 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 122 | 7.208 | 5.092 | 5.794 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 123 | 7.53 | 5.151 | 5.803 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 124 | 7.471 | 5.135 | 5.817 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 125 | 7.973 | 5.185 | 5.859 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 126 | 8.17 | 5.22 | 5.868 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 127 | 8.439 | 5.252 | 5.917 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 128 | 8.593 | 5.079 | 5.767 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 129 | 8.162 | 5.07 | 5.735 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 130 | 8.201 | 4.995 | 5.655 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 131 | 7.848 | 4.935 | 5.606 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 132 | 7.817 | 4.88 | 5.593 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 133 | 7.584 | 4.821 | 5.491 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 134 | 7.299 | 4.768 | 5.473 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 135 | 6.985 | 4.701 | 5.402 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 136 | 6.817 | 4.724 | 5.47 | 14% VectorBulkOperationsArray.fill_var_int_arrays_fill | 137 | 6.95 | 4.794 | 5.493 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 138 | 7.189 | 4.908 | 5.551 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 139 | 7.439 | 4.906 | 5.562 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 140 | 7.666 | 4.951 | 5.582 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 141 | 7.96 | 5.006 | 5.63 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 142 | 8.354 | 5.043 | 5.715 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 143 | 8.466 | 5.1 | 5.727 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 144 | 8.647 | 5.117 | 5.794 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 145 | 8.286 | 5.111 | 5.81 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 146 | 8.152 | 5.126 | 5.924 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 147 | 7.915 | 5.144 | 5.9 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 148 | 7.652 | 5.147 | 5.943 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 149 | 7.572 | 5.216 | 5.975 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 150 | 7.522 | 5.19 | 6.001 | 14% VectorBulkOperationsArray.fill_var_int_arrays_fill | 151 | 7.51 | 5.217 | 6.077 | 14% VectorBulkOperationsArray.fill_var_int_arrays_fill | 152 | 7.513 | 5.247 | 6.072 | 14% VectorBulkOperationsArray.fill_var_int_arrays_fill | 153 | 7.478 | 5.296 | 6.112 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 154 | 7.543 | 5.311 | 6.173 | 14% VectorBulkOperationsArray.fill_var_int_arrays_fill | 155 | 7.544 | 5.32 | 6.243 | 15% VectorBulkOperationsArray.fill_var_int_arrays_fill | 156 | 7.582 | 5.386 | 6.156 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 157 | 7.624 | 5.415 | 6.201 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 158 | 7.608 | 5.452 | 6.193 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 159 | 7.661 | 5.495 | 6.146 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 160 | 7.649 | 5.313 | 5.874 | 10% VectorBulkOperationsArray.fill_var_int_arrays_fill | 161 | 7.658 | 5.457 | 5.973 | 9% VectorBulkOperationsArray.fill_var_int_arrays_fill | 162 | 7.677 | 5.286 | 5.964 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 163 | 7.859 | 5.29 | 5.884 | 10% VectorBulkOperationsArray.fill_var_int_arrays_fill | 164 | 7.934 | 5.216 | 5.827 | 10% VectorBulkOperationsArray.fill_var_int_arrays_fill | 165 | 7.814 | 5.19 | 5.776 | 10% VectorBulkOperationsArray.fill_var_int_arrays_fill | 166 | 7.84 | 5.785 | 5.72 | -1% VectorBulkOperationsArray.fill_var_int_arrays_fill | 167 | 7.82 | 5.175 | 5.683 | 9% VectorBulkOperationsArray.fill_var_int_arrays_fill | 168 | 7.778 | 5.26 | 5.814 | 10% VectorBulkOperationsArray.fill_var_int_arrays_fill | 169 | 7.758 | 5.239 | 5.849 | 10% VectorBulkOperationsArray.fill_var_int_arrays_fill | 170 | 7.874 | 5.347 | 5.98 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 171 | 7.922 | 5.383 | 5.933 | 9% VectorBulkOperationsArray.fill_var_int_arrays_fill | 172 | 7.959 | 5.459 | 5.989 | 9% VectorBulkOperationsArray.fill_var_int_arrays_fill | 173 | 7.995 | 5.455 | 6.031 | 10% VectorBulkOperationsArray.fill_var_int_arrays_fill | 174 | 7.998 | 5.661 | 5.813 | 3% VectorBulkOperationsArray.fill_var_int_arrays_fill | 175 | 9.418 | 5.573 | 6.086 | 8% VectorBulkOperationsArray.fill_var_int_arrays_fill | 176 | 8.142 | 6.055 | 6.156 | 2% VectorBulkOperationsArray.fill_var_int_arrays_fill | 177 | 8.228 | 5.691 | 6.241 | 9% VectorBulkOperationsArray.fill_var_int_arrays_fill | 178 | 8.272 | 5.645 | 6.281 | 10% VectorBulkOperationsArray.fill_var_int_arrays_fill | 179 | 8.241 | 5.617 | 5.961 | 6% VectorBulkOperationsArray.fill_var_int_arrays_fill | 180 | 8.244 | 5.672 | 6.456 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 181 | 8.427 | 5.646 | 6.487 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 182 | 8.072 | 5.933 | 6.497 | 9% VectorBulkOperationsArray.fill_var_int_arrays_fill | 183 | 8.164 | 5.719 | 6.539 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 184 | 8.063 | 5.703 | 6.646 | 14% VectorBulkOperationsArray.fill_var_int_arrays_fill | 185 | 8.083 | 5.722 | 6.627 | 14% VectorBulkOperationsArray.fill_var_int_arrays_fill | 186 | 8.084 | 5.844 | 6.722 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 187 | 8.118 | 5.881 | 6.701 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 188 | 8.18 | 5.943 | 6.688 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 189 | 8 | 6.03 | 6.668 | 10% VectorBulkOperationsArray.fill_var_int_arrays_fill | 190 | 8.18 | 6.104 | 6.728 | 9% VectorBulkOperationsArray.fill_var_int_arrays_fill | 191 | 8.158 | 6.229 | 6.712 | 7% VectorBulkOperationsArray.fill_var_int_arrays_fill | 192 | 8.069 | 6.14 | 6.457 | 5% VectorBulkOperationsArray.fill_var_int_arrays_fill | 193 | 8.277 | 6.052 | 6.429 | 6% VectorBulkOperationsArray.fill_var_int_arrays_fill | 194 | 8.327 | 6.074 | 6.37 | 5% VectorBulkOperationsArray.fill_var_int_arrays_fill | 195 | 8.453 | 5.951 | 6.293 | 5% VectorBulkOperationsArray.fill_var_int_arrays_fill | 196 | 8.438 | 5.902 | 6.234 | 5% VectorBulkOperationsArray.fill_var_int_arrays_fill | 197 | 8.485 | 5.857 | 6.2 | 6% VectorBulkOperationsArray.fill_var_int_arrays_fill | 198 | 8.458 | 5.754 | 6.082 | 5% VectorBulkOperationsArray.fill_var_int_arrays_fill | 199 | 8.251 | 5.742 | 6.068 | 5% VectorBulkOperationsArray.fill_var_int_arrays_fill | 200 | 8.242 | 5.799 | 5.986 | 3% `----- END --------` ------------- PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3786553267 PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3786558614 From dlong at openjdk.org Thu Jan 22 21:05:19 2026 From: dlong at openjdk.org (Dean Long) Date: Thu, 22 Jan 2026 21:05:19 GMT Subject: RFR: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) [v9] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 05:49:22 GMT, Guanqiang Han wrote: >> Please review this change. Thanks! >> >> **Description:** >> >> When -XX:+PrintDeoptimizationDetails is enabled, vframeArray.cpp prints interpreted frames under ttyLocker. >> https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/runtime/vframeArray.cpp#L493-L503 >> In the WizardMode && Verbose branch it calls Method::print_codes() / print_codes_on(). The bytecode printing path may acquire MDOExtraData_lock (rank nosafepoint-1). >> https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/interpreter/bytecodeTracer.cpp#L597-L602 >> Calling it while holding tty_lock violates the global lock ranking order and triggers a lock rank inversion assertion. >> >> **Fix:** >> >> Generate the bytecode dump before taking tty_lock, and print it afterwards under ttyLocker to keep the output coherent while preserving correct lock acquisition order. >> To avoid double buffering when the target stream is already a thread-local stringStream, extend BytecodeTracer::print_method_codes with a buffered flag . The new call site uses buffered=false when dumping into the temporary stringStream. >> >> **Test:** >> >> GHA > > Guanqiang Han 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: > > - change variable name > - Merge remote-tracking branch 'upstream/master' into 8374862 > - remove unused code > - revert > - Merge remote-tracking branch 'upstream/master' into 8374862 > - fix a compile error > - remove unnecessary blank line > - correct copyright year > - Add outputStream::is_buffered() > - change variable name > - ... and 3 more: https://git.openjdk.org/jdk/compare/f0ffac1f...a63c4613 Looks OK, but I'm seeing some weird failures and crashes during testing. They should be unrelated, but let me look into it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29186#issuecomment-3786669654 From henryjen at openjdk.org Thu Jan 22 22:46:53 2026 From: henryjen at openjdk.org (Henry Jen) Date: Thu, 22 Jan 2026 22:46:53 GMT Subject: RFR: 8373924: Dangling pointer in ImageDecompressor::image_decompressor_close of imageDecompressor.cpp Message-ID: I don't see image_decompressor_close actually referenced in the code base, as the decompressors are static and setup from image_decompressor_init(). This PR implements proper cleanup for decompressors to be defensive. ------------- Commit messages: - 8373924: Dangling pointer in ImageDecompressor::image_decompressor_close of imageDecompressor.cpp:90 (ID: 34500) Changes: https://git.openjdk.org/jdk/pull/29371/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29371&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373924 Stats: 13 lines in 2 files changed: 9 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29371.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29371/head:pull/29371 PR: https://git.openjdk.org/jdk/pull/29371 From duke at openjdk.org Thu Jan 22 23:05:53 2026 From: duke at openjdk.org (Vishal Chand) Date: Thu, 22 Jan 2026 23:05:53 GMT Subject: RFR: 8372652: Re-enable LocalRandom clinit after monitor pinning improvements In-Reply-To: <0BI-aekYlNzNe8szo_NjO14MRbrV_NjjQN6IYB_AT40=.5c548a70-d6fa-4eb9-b7cc-3c44f84ea833@github.com> References: <0BI-aekYlNzNe8szo_NjO14MRbrV_NjjQN6IYB_AT40=.5c548a70-d6fa-4eb9-b7cc-3c44f84ea833@github.com> Message-ID: On Mon, 1 Dec 2025 22:38:29 GMT, Leonid Mesnik wrote: >>> Unfortunately, there are might be failure of execution `vmTestbase/`with `JTREG_TEST_THREAD_FACTORY=Virtual`. So it enough ensure the your fix doesn't create new failures and timeouts >> >> I am trying to parse this :) So, if `make test TEST=vmTestbase/ JTREG=TEST_THREAD_FACTORY=Virtual` passes, we are good to go, correct? > >> > Unfortunately, there are might be failure of execution `vmTestbase/`with `JTREG_TEST_THREAD_FACTORY=Virtual`. So it enough ensure the your fix doesn't create new failures and timeouts >> >> I am trying to parse this :) So, if `make test TEST=vmTestbase/ JTREG=TEST_THREAD_FACTORY=Virtual` passes, we are good to go, correct? > > Sure. > I meant that we don't run whole vmTestbase with TEST_THREAD_FACTORY=Virtual, so I am unsure if there are some failures exist now. @lmesnik @AlanBateman A gentle reminder for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28547#issuecomment-3787191303 From dlong at openjdk.org Thu Jan 22 23:12:32 2026 From: dlong at openjdk.org (Dean Long) Date: Thu, 22 Jan 2026 23:12:32 GMT Subject: RFR: 8347396: Efficient TypeFunc creations [v5] In-Reply-To: References: Message-ID: <7BzdUG6SHLFeagQKYiO4mw2alKLUqt9DtZO674GpMbs=.b7cb535e-9ff5-4fa6-b222-6228b9150493@github.com> On Tue, 20 Jan 2026 07:33:39 GMT, Harshit470250 wrote: >> 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 one additional commit since the last revision: > > move include shenandoah to bottom This looks good. Let me test it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27279#issuecomment-3787221151 From ghan at openjdk.org Fri Jan 23 01:41:11 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Fri, 23 Jan 2026 01:41:11 GMT Subject: RFR: 8374807: Crash in MethodData::extra_data_lock()+0x0 when running -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp -version [v5] In-Reply-To: References: Message-ID: > Please review this change. Thanks! > > Description: > > This change fixes a crash in Deoptimization::uncommon_trap_inner when running with -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp. > > With -XX:-ProfileTraps, create_if_missing is set to false. > https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L2121-L2122 > > When create_if_missing is false, new mdo can not be created when m()->method_data() return null, so get_method_data() may return null . > https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L1911-L1912 > > and trap_mdo can be null as a result > https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L2134-L2136 > > The crash happens here because trap_mdo is null > https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L2157 > > Fix: > > The fix makes acquisition of extra_data_lock conditional on trap_mdo being non-null, preserving the required lock ordering (extra_data_lock before ttyLocker) when an MDO exists. > > Test: > > GHA Guanqiang Han 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: - Extract a reproducer into a test method - Merge remote-tracking branch 'upstream/master' into 8374807 - revert - Merge remote-tracking branch 'upstream/master' into 8374807 - narrow lock scope - Merge remote-tracking branch 'upstream/master' into 8374807 - split long line - Merge remote-tracking branch 'upstream/master' into 8374807 - fix 8374807 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29147/files - new: https://git.openjdk.org/jdk/pull/29147/files/e065ae56..3c86ec1b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29147&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29147&range=03-04 Stats: 10756 lines in 339 files changed: 6642 ins; 1394 del; 2720 mod Patch: https://git.openjdk.org/jdk/pull/29147.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29147/head:pull/29147 PR: https://git.openjdk.org/jdk/pull/29147 From erfang at openjdk.org Fri Jan 23 02:11:31 2026 From: erfang at openjdk.org (Eric Fang) Date: Fri, 23 Jan 2026 02:11:31 GMT Subject: RFR: 8374349: [VectorAPI]: AArch64: Prefer merging mode SVE CPY instruction In-Reply-To: References: <_0ouKSVAIyzg0g9hA2jZXNH-_cCqJjNCSh7kM2dn80w=.b93145c3-c465-423a-ab68-c8d7bd7e4280@github.com> Message-ID: On Thu, 22 Jan 2026 17:59:04 GMT, Andrew Haley wrote: > Can we do without `PreferSVEMergingModeCPY`? Thanks, @theRealAph. That?s a fair question ? in general, fewer options are definitely preferable. For this change, the main reason I introduced `PreferSVEMergingModeCPY` as an Arch-level flag is that the benefit and trade-offs of using the merging-mode sequence can be quite **microarchitecture-dependent**. At the moment, I?ve only been able to systematically evaluate it on `Neoverse V1/V2`, where the optimization is consistently neutral or positive in our VectorMask-related benchmarks, so it feels safe to keep it enabled by default there. On other AArch64 SVE implementations, we don?t yet have the same level of data. Keeping this knob gives us two advantages: 1. It provides a simple, low-friction escape hatch if some future core shows an unexpected regression with the merging-mode sequence. 2. It allows us (or downstream distributions) to selectively enable/disable the optimization per platform without needing to change the generated code shape again. >From a user?s point of view, the default behaviour should still be sensible: the option is enabled by default on `Neoverse V1/V2`, where we?ve confirmed the improvement, and disabled elsewhere. If, over time, we gain enough confidence that the merging-mode sequence is strictly preferable across a wider range of hardware, I?m happy to follow up with a separate change to hard-wire the behaviour and drop the flag. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29359#issuecomment-3787782499 From ysuenaga at openjdk.org Fri Jan 23 02:41:46 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Fri, 23 Jan 2026 02:41:46 GMT Subject: RFR: 8374926: EnableX86ECoreOpts was not enabled on some hybrid CPU [v3] In-Reply-To: References: <3wEINJR2IDU6Hi772So8ZqytuF775R-76c4ngkfWuqw=.aa820856-05d8-4fe6-a260-1c6b98bb2921@github.com> Message-ID: On Thu, 22 Jan 2026 16:17:27 GMT, Volodymyr Paprotski wrote: >> For CWF (model `0xDD`), `hy-core-check.c` prints: >> >> Hybrid: 0 >> HT: 1 >> Max leaf: 0x28 >> >> and for SRF (model `0XAF`): >> >> Hybrid: 0 >> HT: 1 >> Max leaf: 0x23 >> >> >> When I added EnableX86ECoreOpts , I remember thinking that I need to 'make it more generic or there will be a lot of models to add manually'. Here we are :( >> >> I need to do more research (and perhaps find some people to talk to..); specifically for client-part numbers. >> >> Some reasons why I hadn't made it (yet?) more generic.. `EnableX86ECoreOpts` is supposed to be 'temporary' (the definition of which, for processors, is 'years'..). It currently enables 'emulation' type of (de)optimizations.. places where Atom cores have some catching up to do, but hopefully should be fixed: >> - MXCSR signaling flags >> - `vblendvp{sd}` emulation >> - pcmpestri 'emulation' in String.indexof >> - generate_fill (which perhaps could go under UseAVX=2 with more work/testing) >> >> In other words: we will at some point need to _disable_ `EnableX86ECoreOpts` on future hybrid cores and will again need another cpuid/flag to detect? > >> I updated this PR to check leaf 1Ah like [this branch](https://github.com/YaSuenag/jdk/compare/ecoreopt-hybrid...YaSuenag:jdk:check-ecore). @vpaprotsk Could you check this change on both SRF and CWF? > > I am waiting for some replies.. I do think adding hybrid check might be a good idea, at least for now. I still need to find a way to detect 'is ecore only'. And if I could detect only the parts that actually need this emulation. (Though maybe leave both of those to me for another PR.. I might have to start looking around 'experimentally' since I have the hardware and your program) @vpaprotsk > I do think adding hybrid check might be a good idea, at least for now. I still need to find a way to detect 'is ecore only'. And if I could detect only the parts that actually need this emulation. (Though maybe leave both of those to me for another PR.. Do you mean this PR should add to check hybrid flag only, without checking leaf 1Ah? If so, I will revert the merge for leaf 1Ah, and will add model ID for CWF. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29149#issuecomment-3787854671 From ghan at openjdk.org Fri Jan 23 03:16:40 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Fri, 23 Jan 2026 03:16:40 GMT Subject: RFR: 8374807: Crash in MethodData::extra_data_lock()+0x0 when running -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp -version [v4] In-Reply-To: References: <17qmKHGiPNSNpHn2By-gtJjPpwFFDj98wiY-bQG16nY=.4df59ed3-8120-496b-9a1e-06b80c9149ae@github.com> <5YSsP2h52Kp9WWb4YrthjtYSziRKM5FM3s5NHThrPTg=.8be8a6fc-e841-4e7b-b9d5-e3910c9bc2e6@github.com> Message-ID: <3lRq3TXzF4XjYLDNlbHfqamzIck_A9WSfXRhG7yA3Ww=.cf8ba7c6-29cf-403d-aea3-58a00a43a496@github.com> On Thu, 22 Jan 2026 10:09:46 GMT, Emanuel Peter wrote: >> @eme64 Thanks for the feedback. >> >> On @requires vm.debug: I?d like to keep it for this reproducer. ProfileTraps is the key knob here: the failure requires ProfileTraps=false (create_if_missing = ProfileTraps, so get_method_data(..., false) may return NULL). Since ProfileTraps is a develop_pd flag and not settable on product builds, this reproducer has to run on a non-product VM (i.e., a debug VM). >> >> On -Xcomp: agreed. I?ll keep it but restrict it with -XX:CompileCommand=compileonly,... so we only compile the relevant method(s). >> >> If that sounds reasonable, I?ll proceed with just the compileonly tightening. > > Generally, it would also be nicer to extract a reproducer into a `test` method, and only compile that one. That way, the code shape leading to the crash is preserved. Would that be possible? Otherwise, we risk that someone changes the code shape (maybe in the core libs), and the test would not reproduce any more. Hi @eme64 @iwanowww , I?ve updated the regression test to keep the reproducer self-contained in a dedicated test() method and restricted compilation to that method only. Could you please take another look? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29147#discussion_r2719423962 From duke at openjdk.org Fri Jan 23 03:25:35 2026 From: duke at openjdk.org (Robert Toyonaga) Date: Fri, 23 Jan 2026 03:25:35 GMT Subject: RFR: 8353564: Fail fatally if os::release_memory or os::uncommit_memory fails [v2] In-Reply-To: References: Message-ID: > This PR is a follow up to JDK-8341491. See original discussion: https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700 > > This PR makes `os::release_memory`, `os::uncommit_memory`, `os::release_memory_special`, and `os::unmap_memory` fail fatally if they encounter an error. These methods require obtaining the NMT lock. Fatally failing in these places would potentially allow for the tightening of NMT virtual memory locking scopes (future work, if this PR is accepted). Already in most cases, the callers fail fatally or assert(false) when these os:: methods fail. Another reason to fatally fail is that if the OS memory operation fails, it can be difficult to know for sure what state the OS left the memory in and recover. > > `release_memory`/`uncommit_memory`/`release_memory_special`/`unmap_memory` can fail due to ? Bad arguments, or ? The OS encountered an issue out of control of the JVM. > > ? > If there is a JVM bug, it's probably reasonable to fatally fail here. Or the caller could be intentionally passing arguments that may or may not be valid. I don't think there is any code like that currently, and this is probably a bad pattern to be following anyway. > > ? > In platform dependent code: > With regard to mmap/munmap, the only errors that aren't due to bad arguments are ENOMEM and ones related to file descriptors (which are not applicable to uncommit or release). > On Windows, VirtualFree only fails due to bad arguments. > On AIX, shmdt and disclaim64 only fail due to bad arguments. msync could spontaneously fail with EIO: "An I/O error occurred while reading from or writing to the file system." > On BSD, it seems like mprotect and madvise fail only due to bad arguments or invalid privileges. > > In the [original discussion](https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700), the main question was whether ENOMEM upon os::uncommit_memory was recoverable. This may be possible if we uncommit the middle of a region - splitting it in two. This could exceed the limit of the number of mappings resulting in ENOMEM. > > If none of the scenarios in ? are recoverable, then perhaps fatally failing is OK. > > Testing: > - Tier 1. > - Manual testing to make sure we fatally fail and the correct messages are printed. Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision: make memory functions void and remove error strings ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29240/files - new: https://git.openjdk.org/jdk/pull/29240/files/9666743a..23bd4dec Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29240&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29240&range=00-01 Stats: 154 lines in 18 files changed: 60 ins; 32 del; 62 mod Patch: https://git.openjdk.org/jdk/pull/29240.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29240/head:pull/29240 PR: https://git.openjdk.org/jdk/pull/29240 From duke at openjdk.org Fri Jan 23 03:33:03 2026 From: duke at openjdk.org (Robert Toyonaga) Date: Fri, 23 Jan 2026 03:33:03 GMT Subject: RFR: 8353564: Fail fatally if os::release_memory or os::uncommit_memory fails [v2] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 03:25:35 GMT, Robert Toyonaga wrote: >> This PR is a follow up to JDK-8341491. See original discussion: https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700 >> >> This PR makes `os::release_memory`, `os::uncommit_memory`, `os::release_memory_special`, and `os::unmap_memory` fail fatally if they encounter an error. These methods require obtaining the NMT lock. Fatally failing in these places would potentially allow for the tightening of NMT virtual memory locking scopes (future work, if this PR is accepted). Already in most cases, the callers fail fatally or assert(false) when these os:: methods fail. Another reason to fatally fail is that if the OS memory operation fails, it can be difficult to know for sure what state the OS left the memory in and recover. >> >> `release_memory`/`uncommit_memory`/`release_memory_special`/`unmap_memory` can fail due to ? Bad arguments, or ? The OS encountered an issue out of control of the JVM. >> >> ? >> If there is a JVM bug, it's probably reasonable to fatally fail here. Or the caller could be intentionally passing arguments that may or may not be valid. I don't think there is any code like that currently, and this is probably a bad pattern to be following anyway. >> >> ? >> In platform dependent code: >> With regard to mmap/munmap, the only errors that aren't due to bad arguments are ENOMEM and ones related to file descriptors (which are not applicable to uncommit or release). >> On Windows, VirtualFree only fails due to bad arguments. >> On AIX, shmdt and disclaim64 only fail due to bad arguments. msync could spontaneously fail with EIO: "An I/O error occurred while reading from or writing to the file system." >> On BSD, it seems like mprotect and madvise fail only due to bad arguments or invalid privileges. >> >> In the [original discussion](https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700), the main question was whether ENOMEM upon os::uncommit_memory was recoverable. This may be possible if we uncommit the middle of a region - splitting it in two. This could exceed the limit of the number of mappings resulting in ENOMEM. >> >> If none of the scenarios in ? are recoverable, then perhaps fatally failing is OK. >> >> Testing: >> - Tier 1. >> - Manual testing to make sure we fatally fail and the correct messages are printed. > > Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision: > > make memory functions void and remove error strings Thank you everyone for the feedback! I've removed the error strings now. >os::unmap_memory only returns true now. Is there a reason why the return value type of this function is not changed? Yes, they can all return void now. I've made the change and updated the callers where necessary too. > Much more sense would be to (in a separate PR) highlight the fact in the hs-err file that this particular native OOM may have been caused by running against the mapping limit, and that increasing said limit may help. Maybe we do this already, not sure. How about if I added that note in the fatal error message in `os::uncommit_memory`? I think then that note should also show up in the hs_err file. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29240#issuecomment-3787995053 From jbhateja at openjdk.org Fri Jan 23 04:24:57 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 23 Jan 2026 04:24:57 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v14] In-Reply-To: References: Message-ID: > 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. > > image > > 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 incrementally with one additional commit since the last revision: Refactoring and cleanups ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28002/files - new: https://git.openjdk.org/jdk/pull/28002/files/fe7075ee..72d15568 Webrevs: - full: Webrev is not available because diff is too large - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=12-13 Stats: 1415 lines in 52 files changed: 441 ins; 259 del; 715 mod Patch: https://git.openjdk.org/jdk/pull/28002.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002 PR: https://git.openjdk.org/jdk/pull/28002 From jbhateja at openjdk.org Fri Jan 23 05:01:46 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 23 Jan 2026 05:01:46 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v14] In-Reply-To: References: <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com> <1ElN5XvEXAYGINpCIB2smhDrzekGyiXmG6o8-jnxDxk=.83a69a64-2894-40af-a2ee-9c35448c88b2@github.com> Message-ID: <-cin72VWnqAukd5JbCMV9BfsGR1tWcWh_aGpdrlhHlM=.2d22e5da-35d2-4ffc-8ce5-86c90d662fd7@github.com> On Wed, 21 Jan 2026 07:01:39 GMT, Jatin Bhateja wrote: >> @jatin-bhateja Thanks for the ping! I'll put this on the list for review early in 2026 :) > > Hi @eme64 , Your comments have been addressed > @jatin-bhateja This patch is really really large. There are lots of renamings that could be done in a separate patch first (as a subtask). It would make reviewing easier, allowing focus on the substantial work. See discussion here: [#28002 (comment)](https://github.com/openjdk/jdk/pull/28002#discussion_r2705376899) Hi @eme64 , I have done some cleanups, following is the summary of changes included with the patch:- ``` 1 Changes to introduce a new (custom) basictype T_FLOAT16 - Global Definition. - Skip over handling where ever applicable. 2 Changes to pass laneType (BasicType) to intrinsific entry point instead of element classes. - Inline expander interface changes mainly. 3 Changes in abstract and concrete vector class generation templates. 4 Changing the nomenclature of Vector classes to avoid Float1664... sort of names... 5 Changes in the LaneType to add a new carrier type field. 6 Changes in inline expanders to selectivelty enable intrinsification for opration for which we have auto-vectorization and backend support in place.. 7 Changes in test generation templates. b. Assert wrappers to conver float16 (short) value to float before invoking testng Asserts. c. Scalar operation wrappers to selectivelty invoke Float16 math routine which are not part of Java SE math libraries. 8 New IR verification test. 9 New Micro-benchmark. 10 AARCH64 test failure - patch + test fixed by Bhavana Kilambi. Out of above change 7b consumes 40000+ LOC. Q. Why do we need wrapper assertions ? A. To handle all possible NaN representations of SNaN and QNaN, since float16 uses short carrier type hence we need to promote them float values before invoking TestNG assertions. This conversion is accomplished by assertion wrappers I think all the tasks are related and since most of source/test are generated using scripts we should not go by the size of patch and review the templates files. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3788233245 From iklam at openjdk.org Fri Jan 23 06:25:56 2026 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 23 Jan 2026 06:25:56 GMT Subject: RFR: 8374549: Extend MetaspaceClosure to cover non-MetaspaceObj types In-Reply-To: <7fCqqxJTaRd1JzzT7fqrcsTwSKpVnr7kb_SuubuMOTg=.15269a6d-6034-4335-8193-09891d63a422@github.com> References: <7fCqqxJTaRd1JzzT7fqrcsTwSKpVnr7kb_SuubuMOTg=.15269a6d-6034-4335-8193-09891d63a422@github.com> Message-ID: <8DiJMy5oef4CDKD4GTqCVgizgss5TpU4GLtPVwjd0II=.6edb5c0b-ec67-4168-ba36-388aa6db4a73@github.com> On Thu, 22 Jan 2026 17:35:14 GMT, Vladimir Kozlov wrote: >> Previously, `MetaspaceClosure` could iterate only `MetaspaceObject`, using its four member functions: >> >> - `is_read_only_by_default()` >> - `metaspace_pointers_do()` >> - `size()` >> - `type()` >> >> `PackageEntry`, `ModuleEntry` and `GrowableArray` cannot be subclasses from `MetaspaceObject` due to various constraints. As a result, they were copied with ad-hoc code. >> >> This PR updates the templates in `MetaspaceClosure` so that it can iterate any classes that have the above four functions. This allows new types of data to be uniformly copied into the AOT cache (aka CDS archive) without ad-hoc copiers. >> >> This PR is necessary for future evolution of AOT as more types of data will be copied into the AOT cache. For example, in Valhalla we have a `GrowableArray` that needs to be copied along with `AdapterHandleEntry`. > > src/hotspot/share/cds/cppVtables.cpp line 62: > >> 60: >> 61: // AOTGrowableArray has a vtable only when in non-product builds (due to >> 62: // the virtual printing functions in AnyObj). > > Can we devirtualize it? You would need to reconstruct Vpointer in non-debug build otherwise. Since `AnyObj` doesn't carry any type information, we cannot easily devirtualize this call. In debug builds, the vtable is updated in the production run. The vtable updates are driven by the `CPP_VTABLE_TYPES_DO` macro in cppVtables.cpp. The following have been added to this macro #ifndef PRODUCT // AOTGrowableArray has a vtable only when in non-product builds (due to // the virtual printing functions in AnyObj). using GrowableArray_ModuleEntry_ptr = AOTGrowableArray; #define DEBUG_CPP_VTABLE_TYPES_DO(f) \ f(GrowableArray_ModuleEntry_ptr) \ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29049#discussion_r2719775522 From jbhateja at openjdk.org Fri Jan 23 06:34:00 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 23 Jan 2026 06:34:00 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v12] In-Reply-To: References: Message-ID: > Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction. > It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails. > > Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java). > > Vector API jtreg tests pass at AVX level 2, remaining validation in progress. > > Performance numbers: > > > System : 13th Gen Intel(R) Core(TM) i3-1315U > > Baseline: > Benchmark (size) Mode Cnt Score Error Units > VectorSliceBenchmark.byteVectorSliceWithConstantIndex1 1024 thrpt 2 9444.444 ops/ms > VectorSliceBenchmark.byteVectorSliceWithConstantIndex2 1024 thrpt 2 10009.319 ops/ms > VectorSliceBenchmark.byteVectorSliceWithVariableIndex 1024 thrpt 2 9081.926 ops/ms > VectorSliceBenchmark.intVectorSliceWithConstantIndex1 1024 thrpt 2 6085.825 ops/ms > VectorSliceBenchmark.intVectorSliceWithConstantIndex2 1024 thrpt 2 6505.378 ops/ms > VectorSliceBenchmark.intVectorSliceWithVariableIndex 1024 thrpt 2 6204.489 ops/ms > VectorSliceBenchmark.longVectorSliceWithConstantIndex1 1024 thrpt 2 1651.334 ops/ms > VectorSliceBenchmark.longVectorSliceWithConstantIndex2 1024 thrpt 2 1642.784 ops/ms > VectorSliceBenchmark.longVectorSliceWithVariableIndex 1024 thrpt 2 1474.808 ops/ms > VectorSliceBenchmark.shortVectorSliceWithConstantIndex1 1024 thrpt 2 10399.394 ops/ms > VectorSliceBenchmark.shortVectorSliceWithConstantIndex2 1024 thrpt 2 10502.894 ops/ms > VectorSliceBenchmark.shortVectorSliceWithVariableIndex 1024 ... Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Review comments resolutions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24104/files - new: https://git.openjdk.org/jdk/pull/24104/files/2c7eb96d..ae242926 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=10-11 Stats: 23 lines in 10 files changed: 4 ins; 12 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/24104.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24104/head:pull/24104 PR: https://git.openjdk.org/jdk/pull/24104 From jbhateja at openjdk.org Fri Jan 23 06:34:02 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 23 Jan 2026 06:34:02 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v11] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 09:42:06 GMT, Xiaohong Gong wrote: >> Jatin Bhateja has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762 > > Overall, looks good to me; I?ve just left a few minor comments. Hi @XiaohongGong , your comments have been addressed. Hi @sviswa7, can you kindly review x86 part. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3788537143 From stuefe at openjdk.org Fri Jan 23 06:54:46 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 23 Jan 2026 06:54:46 GMT Subject: RFR: 8353564: Fail fatally if os::release_memory or os::uncommit_memory fails [v2] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 03:30:02 GMT, Robert Toyonaga wrote: > Thank you everyone for the feedback! > > I've removed the error strings now. > > > os::unmap_memory only returns true now. Is there a reason why the return value type of this function is not changed? > > Yes, they can all return void now. I've made the change and updated the callers where necessary too. > > > Much more sense would be to (in a separate PR) highlight the fact in the hs-err file that this particular native OOM may have been caused by running against the mapping limit, and that increasing said limit may help. Maybe we do this already, not sure. > > How about if I added that note in the fatal error message in `os::uncommit_memory`? I think then that note should also show up in the hs_err file. Sure, that would work, but this would be highly Linux-specific. So, would need ifdefs. Wait, the failing code is OS specific, too. So, okay :-) You need to do this for ENOMEM only then. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29240#issuecomment-3788609565 From stuefe at openjdk.org Fri Jan 23 07:04:44 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 23 Jan 2026 07:04:44 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v4] In-Reply-To: <93J0DXbDwwQDYqasv9f9lF4NofBWMLb4NTiyMCXkdsM=.bc351bf6-8408-4c4d-990d-99df03a21649@github.com> References: <93J0DXbDwwQDYqasv9f9lF4NofBWMLb4NTiyMCXkdsM=.bc351bf6-8408-4c4d-990d-99df03a21649@github.com> Message-ID: On Thu, 22 Jan 2026 11:11:04 GMT, Ivan Bereziuk wrote: >> `jcmd` provides great diagnostics but many commands lack a timestamp in their output. >> Adding a timestamp to the output would add value for those debugging JVM data. >> >> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. >> >> With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-t": >> >> jcmd [pid | main-class] [-t] command... | PerfCounter.print | -f filename >> ^^^^ >> >> * The choice for time format is ISO 8601 `yyyy-MM-dd'T'HH:mm:ss.SSSZ` (example `2026-01-21T16:58:49.518+0100`) >> * if "-t" flag is not passed, `Thread.print` keeps printing "yyyy-MM-dd HH:mm:ss" timestamp to preserve backwards compatibility. > > Ivan Bereziuk has updated the pull request incrementally with one additional commit since the last revision: > > change flag name from -T to -t Just piling on, sorry for bikeshedding... > OK thanks, yes not changing all the dcmds in https://github.com/openjdk/jdk/pull/29325/files is nice. 8-) > > Regarding whether JCmd.java could do the timestamp, or we need to change the native side: Yes a problem there is the timestamp duplication issue: if JCmd can optionally print a timestamp as a header before running the command, that timestamp info is duplicated in Thread.print. > > But is it really that bad, and is it worth the extra argument processing? (In diagnosticFramework, we need to introduce parse_common options just for this one flag.) I agree. > > If JCmd.java does the timestamp: if you opt-in to JCmd with a timestamp, you would get the new timestamp in the new format, followed by the old Thread.print timestamp in its format... This avoids the new complexity in the native code, and keeps the new timestamp handling in the simple JCmd.java wrapper. It sidesteps the problem that Thread.print uses an arguably "wrong" format. (An in time, maybe Thread.print would migrate to not printing a timestamp.) I would prefer if the hotspot did write the timestamp, because 1) The time may run differently on the jcmd side (e.g. target runs on a container on Windows or MacOS, or if we ever add remote capabilities to jcmd) 2) adding it to the hotspot will automatically work for every version of jcmd (e.g., I usually just call "jcmd" and use whatever jcmd tool happens to be on the path on that particular machine, but no guarantee it comes from the target VM) > > (JCmd could optionally print a duration at the end as was hinted somewhere earlier. Heap dumping prints its own time taken, but few other commands consider it interesting.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3788641543 From epeter at openjdk.org Fri Jan 23 08:11:15 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Fri, 23 Jan 2026 08:11:15 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v13] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 20:30:26 GMT, Srinivas Vamsi Parasa wrote: >> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: >> >> Update ALL of ArraysFill JMH micro > > ### Int VectorBulkOperationsArray Fill > > Benchmark (ns/op) | Size | -OptimizeFill (JITed code) | +OptimizeFill (Masked store) | +OptimizeFill (Unmasked store - This PR) | Delta (masked vs. unmasked) > -- | -- | -- | -- | -- | -- > VectorBulkOperationsArray.fill_var_int_arrays_fill | 0 | 0.649 | 0.651 | 0.655 | 1% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 1 | 2.371 | 2.801 | 2.827 | 1% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 2 | 2.374 | 2.585 | 2.942 | 12% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 3 | 2.809 | 2.589 | 3.094 | 16% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 4 | 3.356 | 2.587 | 2.852 | 9% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 5 | 3.531 | 2.588 | 3.158 | 18% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 6 | 3.747 | 2.589 | 3.118 | 17% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 7 | 3.989 | 2.589 | 3.332 | 22% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 8 | 5.047 | 2.588 | 2.832 | 9% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 9 | 4.79 | 2.845 | 3.056 | 7% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 10 | 4.982 | 2.85 | 3.274 | 13% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 11 | 4.551 | 2.852 | 3.521 | 19% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 12 | 4.281 | 2.853 | 3.12 | 9% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 13 | 4.391 | 2.894 | 3.499 | 17% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 14 | 4.909 | 2.848 | 3.339 | 15% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 15 | 5.269 | 2.853 | 3.524 | 19% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 16 | 5.663 | 2.836 | 3.101 | 9% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 17 | 5.553 | 2.924 | 3.111 | 6% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 18 | 5.105 | 2.933 | 3.358 | 13% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 19 | 5.09 | 2.942 | 3.583 | 18% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 20 | 4.457 | 2.927 | 3.272 | 11% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 21 | 4.745 | 3.104 | 3.598 | 14% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 22 | 4.949 | 2.932 | 3.481 | 16% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 23 | 4.992 | 2.939 | 3.761 | 22% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 24 | 5.198 | 2.92 | 3.205 | 9% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 25 | 5.097 | 3.116 | 3.387 | 8% > VectorBulkOperationsArray.fill_var_... > > @vamsi-parasa Ok, so now we have one benchmark that shows a speedup and one that shows a regression. How are we to proceed? > > It seems that without loads [#28442 (comment)](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761659799), this patch leads to a regression. > > Only if there is a load from one of the last elements that the `Arrays.fill` stored to with a masked operation do we get a slowdown. Because of missing load-to-store forwarding. If we instead started loading from the first elements, those would probably already be in cache, and we would not have any latency issues, right? > > But is it not rather an edge-case that we load from the last elements immediately after the `Arrays.fill`? At least for longer arrays, it seems an edge case. For short arrays it is probably more likely that we access the last element soon after the fill. > > It does not seem like a trivial decision to me if this patch is an improvement or not. What do you think @vamsi-parasa ? > > @sviswa7 @dwhite-intel You already approved this PR. What are your thoughts here? > > @eme64 My thoughts are to go ahead with this PR replacing masked stores with scalar tail processing. As we have seen from https://bugs.openjdk.org/browse/JDK-8349452 masked stores can cause big regression in certain scenarios: accessing elements just written or any other adjacent data that happens to fall in the masked store range. @sviswa7 But once this PR is integrated, I could file a performance regression with the benchmarks from [up here](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761659799). So what's the argument which choice is better, since we have a mix of speedups/regression going either way, and both are probably in the 10-20% range? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3788945532 From tschatzl at openjdk.org Fri Jan 23 08:36:44 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 23 Jan 2026 08:36:44 GMT Subject: RFR: 8376131: Convert ContiguousSpace to use Atomic Message-ID: Hi all, please review this conversions of `ContiguousSpace` to use `Atomic`. Testing: gha, tier1-5 Thanks, Thomas ------------- Commit messages: - 8376131 Changes: https://git.openjdk.org/jdk/pull/29370/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29370&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376131 Stats: 21 lines in 4 files changed: 2 ins; 7 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/29370.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29370/head:pull/29370 PR: https://git.openjdk.org/jdk/pull/29370 From stefank at openjdk.org Fri Jan 23 08:38:40 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 23 Jan 2026 08:38:40 GMT Subject: RFR: 8353564: Fail fatally if os::release_memory or os::uncommit_memory fails [v2] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 03:25:35 GMT, Robert Toyonaga wrote: >> This PR is a follow up to JDK-8341491. See original discussion: https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700 >> >> This PR makes `os::release_memory`, `os::uncommit_memory`, `os::release_memory_special`, and `os::unmap_memory` fail fatally if they encounter an error. These methods require obtaining the NMT lock. Fatally failing in these places would potentially allow for the tightening of NMT virtual memory locking scopes (future work, if this PR is accepted). Already in most cases, the callers fail fatally or assert(false) when these os:: methods fail. Another reason to fatally fail is that if the OS memory operation fails, it can be difficult to know for sure what state the OS left the memory in and recover. >> >> `release_memory`/`uncommit_memory`/`release_memory_special`/`unmap_memory` can fail due to ? Bad arguments, or ? The OS encountered an issue out of control of the JVM. >> >> ? >> If there is a JVM bug, it's probably reasonable to fatally fail here. Or the caller could be intentionally passing arguments that may or may not be valid. I don't think there is any code like that currently, and this is probably a bad pattern to be following anyway. >> >> ? >> In platform dependent code: >> With regard to mmap/munmap, the only errors that aren't due to bad arguments are ENOMEM and ones related to file descriptors (which are not applicable to uncommit or release). >> On Windows, VirtualFree only fails due to bad arguments. >> On AIX, shmdt and disclaim64 only fail due to bad arguments. msync could spontaneously fail with EIO: "An I/O error occurred while reading from or writing to the file system." >> On BSD, it seems like mprotect and madvise fail only due to bad arguments or invalid privileges. >> >> In the [original discussion](https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700), the main question was whether ENOMEM upon os::uncommit_memory was recoverable. This may be possible if we uncommit the middle of a region - splitting it in two. This could exceed the limit of the number of mappings resulting in ENOMEM. >> >> If none of the scenarios in ? are recoverable, then perhaps fatally failing is OK. >> >> Testing: >> - Tier 1. >> - Manual testing to make sure we fatally fail and the correct messages are printed. > > Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision: > > make memory functions void and remove error strings It feels a bit inconsistent that the os_linux.cpp version of `os::remove_stack_guard_pages` behaves differently than all the other platform implementations, and this happens only if we get an `::munmap` failure on the primordial thread. I think we need to wait for a follow-up comment from David before proceeding with the proposed change here. src/hotspot/share/memory/metaspace/virtualSpaceNode.cpp line 194: > 192: // Uncommit... > 193: os::uncommit_memory((char*)p, word_size * BytesPerWord, false); > 194: Suggestion: os::uncommit_memory((char*)p, word_size * BytesPerWord, false); ------------- PR Review: https://git.openjdk.org/jdk/pull/29240#pullrequestreview-3696270198 PR Review Comment: https://git.openjdk.org/jdk/pull/29240#discussion_r2720145183 From stefank at openjdk.org Fri Jan 23 08:38:42 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 23 Jan 2026 08:38:42 GMT Subject: RFR: 8353564: Fail fatally if os::release_memory or os::uncommit_memory fails [v2] In-Reply-To: References: Message-ID: <20Y1AigdfDmqEzbJlIw38m3zw6JLUdEUCJCbINdxvO4=.43600629-2c7e-4394-b87f-2deb4264f73e@github.com> On Fri, 23 Jan 2026 08:21:57 GMT, Stefan Karlsson wrote: >> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision: >> >> make memory functions void and remove error strings > > src/hotspot/share/memory/metaspace/virtualSpaceNode.cpp line 194: > >> 192: // Uncommit... >> 193: os::uncommit_memory((char*)p, word_size * BytesPerWord, false); >> 194: > > Suggestion: > > os::uncommit_memory((char*)p, word_size * BytesPerWord, false); This is just a removal of a stray extra blank line. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29240#discussion_r2720211450 From aph at openjdk.org Fri Jan 23 09:26:50 2026 From: aph at openjdk.org (Andrew Haley) Date: Fri, 23 Jan 2026 09:26:50 GMT Subject: RFR: 8374349: [VectorAPI]: AArch64: Prefer merging mode SVE CPY instruction In-Reply-To: References: <_0ouKSVAIyzg0g9hA2jZXNH-_cCqJjNCSh7kM2dn80w=.b93145c3-c465-423a-ab68-c8d7bd7e4280@github.com> Message-ID: On Fri, 23 Jan 2026 02:09:03 GMT, Eric Fang wrote: > > Can we do without `PreferSVEMergingModeCPY`? > > Thanks, @theRealAph. That?s a fair question ? in general, fewer options are definitely preferable. > > For this change, the main reason I introduced `PreferSVEMergingModeCPY` as an Arch-level flag is that the benefit and trade-offs of using the merging-mode sequence can be quite **microarchitecture-dependent**. The question is not whether something may possibly be better or worse, but is it significantly so? If you're going to add another flag, you have to provide evidence that the difference matters. The burden is on you to show that it does. > From a user?s point of view, the default behaviour should still be sensible: the option is enabled by default on `Neoverse V1/V2`, where we?ve confirmed the improvement, and disabled elsewhere. If, over time, we gain enough confidence that the merging-mode sequence is strictly preferable across a wider range of hardware, I?m happy to follow up with a separate change to hard-wire the behaviour and drop the flag. That's the wrong way to think about it. There are thousands of tiny decisions we've made in the AArch64 port, and the number of possible tweaks is almost infinite. If we need a flag in the future we can add one, but then we'll do a better job once we understand what we really need. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29359#issuecomment-3789258021 From epeter at openjdk.org Fri Jan 23 10:18:23 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Fri, 23 Jan 2026 10:18:23 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v14] In-Reply-To: <-cin72VWnqAukd5JbCMV9BfsGR1tWcWh_aGpdrlhHlM=.2d22e5da-35d2-4ffc-8ce5-86c90d662fd7@github.com> References: <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com> <1ElN5XvEXAYGINpCIB2smhDrzekGyiXmG6o8-jnxDxk=.83a69a64-2894-40af-a2ee-9c35448c88b2@github.com> <-cin72VWnqAukd5JbCMV9BfsGR1tWcWh_aGpdrlhHlM=.2d22e5da-35d2-4ffc-8ce5-86c90d662fd7@github.com> Message-ID: <0xRSPGoZtGTXyFJEH5pvABR-qa2UZjNnQ2mXCxbYP4U=.ac7ab717-3adf-4910-a333-dd15b3fedd32@github.com> On Fri, 23 Jan 2026 04:57:04 GMT, Jatin Bhateja wrote: >> Hi @eme64 , Your comments have been addressed > >> @jatin-bhateja This patch is really really large. There are lots of renamings that could be done in a separate patch first (as a subtask). It would make reviewing easier, allowing focus on the substantial work. See discussion here: [#28002 (comment)](https://github.com/openjdk/jdk/pull/28002#discussion_r2705376899) > > Hi @eme64 , > > I have done some cleanups, following is the summary of changes included with the patch:- > > ``` > 1 Changes to introduce a new (custom) basictype T_FLOAT16 > - Global Definition. > - Skip over handling where ever applicable. > 2 Changes to pass laneType (BasicType) to intrinsific entry point instead of element classes. > - Inline expander interface changes mainly. > 3 Changes in abstract and concrete vector class generation templates. > 4 Changing the nomenclature of Vector classes to avoid Float1664... sort of names... > 5 Changes in the LaneType to add a new carrier type field. > 6 Changes in inline expanders to selectivelty enable intrinsification for opration for which we have > auto-vectorization and backend support in place.. > 7 Changes in test generation templates. > b. Assert wrappers to conver float16 (short) value to float before invoking testng Asserts. > c. Scalar operation wrappers to selectivelty invoke Float16 math routine which are not > part of Java SE math libraries. > > 8 New IR verification test. > 9 New Micro-benchmark. > 10 AARCH64 test failure - patch + test fixed by Bhavana Kilambi. > > > Out of above change 7b consumes 40000+ LOC. > > Q. Why do we need wrapper assertions ? > A. To handle all possible NaN representations of SNaN and QNaN, since float16 uses short carrier type hence we need to promote them float values before invoking TestNG assertions. This conversion is accomplished by assertion wrappers > > All the tasks are related and most of source/test are generated using scripts we should not go by the size of patch and review the templates files. @jatin-bhateja Thanks for your response. And thanks for the list of changes included in the patch :) It seems to me, many of these subtasks you mention could be done as separate tasks prior to the Float16Vector and auto-vectorizer work: 1 Changes to introduce a new (custom) basictype T_FLOAT16 - Global Definition. - Skip over handling where ever applicable. And 2 Changes to pass laneType (BasicType) to intrinsific entry point instead of element classes. - Inline expander interface changes mainly. And in the below at least changes that don't include the Float16Vector: 3 Changes in abstract and concrete vector class generation templates. 4 Changing the nomenclature of Vector classes to avoid Float1664... sort of names... Probably also this: 5 Changes in the LaneType to add a new carrier type field. And maybe also this, as long as it is not Float16 specific: 6 Changes in inline expanders to selectivelty enable intrinsification for opration for which we have auto-vectorization and backend support in place.. For `7`, probably only the `7b` part, since `7a` is about Float16Vector. 7 Changes in test generation templates. b. Assert wrappers to conver float16 (short) value to float before invoking testng Asserts. c. Scalar operation wrappers to selectivelty invoke Float16 math routine which are not part of Java SE math libraries. Parts 8, 9, 10 seem Float16Vector specific, so those should stay here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3789507594 From epeter at openjdk.org Fri Jan 23 10:18:26 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Fri, 23 Jan 2026 10:18:26 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v14] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 04:24:57 GMT, Jatin Bhateja 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. >> >> image >> >> 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 incrementally with one additional commit since the last revision: > > Refactoring and cleanups The goal of separating these is that reviewing is much easier, and so we can reach a higher confidence in the quality of the code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3789510739 From dlong at openjdk.org Fri Jan 23 10:20:39 2026 From: dlong at openjdk.org (Dean Long) Date: Fri, 23 Jan 2026 10:20:39 GMT Subject: RFR: 8347396: Efficient TypeFunc creations [v5] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 07:33:39 GMT, Harshit470250 wrote: >> 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 one additional commit since the last revision: > > move include shenandoah to bottom Testing passed. ------------- Marked as reviewed by dlong (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27279#pullrequestreview-3696806493 From dlong at openjdk.org Fri Jan 23 10:21:38 2026 From: dlong at openjdk.org (Dean Long) Date: Fri, 23 Jan 2026 10:21:38 GMT Subject: RFR: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) [v9] In-Reply-To: References: Message-ID: <31ROwZLk7vP70S_r-9eLgW0z6zb0Ur6Vfi9qQcE_n_Y=.aee0d7f4-f776-4086-9b1e-77a63bfe3bfc@github.com> On Mon, 19 Jan 2026 05:49:22 GMT, Guanqiang Han wrote: >> Please review this change. Thanks! >> >> **Description:** >> >> When -XX:+PrintDeoptimizationDetails is enabled, vframeArray.cpp prints interpreted frames under ttyLocker. >> https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/runtime/vframeArray.cpp#L493-L503 >> In the WizardMode && Verbose branch it calls Method::print_codes() / print_codes_on(). The bytecode printing path may acquire MDOExtraData_lock (rank nosafepoint-1). >> https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/interpreter/bytecodeTracer.cpp#L597-L602 >> Calling it while holding tty_lock violates the global lock ranking order and triggers a lock rank inversion assertion. >> >> **Fix:** >> >> Generate the bytecode dump before taking tty_lock, and print it afterwards under ttyLocker to keep the output coherent while preserving correct lock acquisition order. >> To avoid double buffering when the target stream is already a thread-local stringStream, extend BytecodeTracer::print_method_codes with a buffered flag . The new call site uses buffered=false when dumping into the temporary stringStream. >> >> **Test:** >> >> GHA > > Guanqiang Han 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: > > - change variable name > - Merge remote-tracking branch 'upstream/master' into 8374862 > - remove unused code > - revert > - Merge remote-tracking branch 'upstream/master' into 8374862 > - fix a compile error > - remove unnecessary blank line > - correct copyright year > - Add outputStream::is_buffered() > - change variable name > - ... and 3 more: https://git.openjdk.org/jdk/compare/72b38ac9...a63c4613 I retested after merging with the latest in master branch and it passed. ------------- Marked as reviewed by dlong (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29186#pullrequestreview-3696811333 From ghan at openjdk.org Fri Jan 23 10:29:42 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Fri, 23 Jan 2026 10:29:42 GMT Subject: RFR: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) [v9] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 11:44:24 GMT, David Holmes wrote: >> Hi @dholmes-ora, Thank you for reviewing! >> I?ve integrated the change ? could you please sponsor it? Thanks! > > @hgqxjj hotspot changes require two reviews, so we will need to wait for @dean-long to have another look. @dholmes-ora @dean-long Thanks for the review . I?ve already integrated this PR . Could one of you please sponsor it ? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29186#issuecomment-3789556787 From erfang at openjdk.org Fri Jan 23 10:31:45 2026 From: erfang at openjdk.org (Eric Fang) Date: Fri, 23 Jan 2026 10:31:45 GMT Subject: RFR: 8374349: [VectorAPI]: AArch64: Prefer merging mode SVE CPY instruction In-Reply-To: References: <_0ouKSVAIyzg0g9hA2jZXNH-_cCqJjNCSh7kM2dn80w=.b93145c3-c465-423a-ab68-c8d7bd7e4280@github.com> Message-ID: <_qJ_Qo_Mqexx7dYu0Vkc9ru4SxZ0izfqifaUIAL1iyQ=.741b11d4-a89d-495e-8d31-78fed690abf6@github.com> On Fri, 23 Jan 2026 09:24:31 GMT, Andrew Haley wrote: >>> Can we do without `PreferSVEMergingModeCPY`? >> >> Thanks, @theRealAph. That?s a fair question ? in general, fewer options are definitely preferable. >> >> For this change, the main reason I introduced `PreferSVEMergingModeCPY` as an Arch-level flag is that the benefit and trade-offs of using the merging-mode sequence can be quite **microarchitecture-dependent**. At the moment, I?ve only been able to systematically evaluate it on `Neoverse V1/V2`, where the optimization is consistently neutral or positive in our VectorMask-related benchmarks, so it feels safe to keep it enabled by default there. On other AArch64 SVE implementations, we don?t yet have the same level of data. Keeping this knob gives us two advantages: >> >> 1. It provides a simple, low-friction escape hatch if some future core shows an unexpected regression with the merging-mode sequence. >> 2. It allows us (or downstream distributions) to selectively enable/disable the optimization per platform without needing to change the generated code shape again. >> >> From a user?s point of view, the default behaviour should still be sensible: the option is enabled by default on `Neoverse V1/V2`, where we?ve confirmed the improvement, and disabled elsewhere. If, over time, we gain enough confidence that the merging-mode sequence is strictly preferable across a wider range of hardware, I?m happy to follow up with a separate change to hard-wire the behaviour and drop the flag. > >> > Can we do without `PreferSVEMergingModeCPY`? >> >> Thanks, @theRealAph. That?s a fair question ? in general, fewer options are definitely preferable. >> >> For this change, the main reason I introduced `PreferSVEMergingModeCPY` as an Arch-level flag is that the benefit and trade-offs of using the merging-mode sequence can be quite **microarchitecture-dependent**. > > The question is not whether something may possibly be better or worse, but is it significantly so? If you're going to add another flag, you have to provide evidence that the difference matters. The burden is on you to show that it does. > >> From a user?s point of view, the default behaviour should still be sensible: the option is enabled by default on `Neoverse V1/V2`, where we?ve confirmed the improvement, and disabled elsewhere. If, over time, we gain enough confidence that the merging-mode sequence is strictly preferable across a wider range of hardware, I?m happy to follow up with a separate change to hard-wire the behaviour and drop the flag. > > That's the wrong way to think about it. There are thousands of tiny decisions we've made in the AArch64 port, and the number of possible tweaks is almost infinite. If we need a flag in the future we can add one, but then we'll do a better job once we understand what we really need. Thanks @theRealAph. I don't have test data on other aarch64 microarchitectures to show the difference with and without this optimization. I'm asking my Arm partners for help testing to see if they have more AArch64 environments. Adding a new flag for this optimization might not be appropriate. I'm thinking of handling it this way: **during JVM initialization (in `vm_version.cpp`), check the microarchitecture, set a global variable, and then use it in the assembler to determine whether to apply the optimization.** Maintaining microarchitecture-specific handling might be worthwhile. This provides some flexibility for different/future architectures. Because we're unsure how the future microarchitecture will behave, from a performance and code size perspective, we generally prefer single instruction over multiple instructions. Is it fine to you ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29359#issuecomment-3789562233 From kevinw at openjdk.org Fri Jan 23 11:14:20 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 23 Jan 2026 11:14:20 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v4] In-Reply-To: <93J0DXbDwwQDYqasv9f9lF4NofBWMLb4NTiyMCXkdsM=.bc351bf6-8408-4c4d-990d-99df03a21649@github.com> References: <93J0DXbDwwQDYqasv9f9lF4NofBWMLb4NTiyMCXkdsM=.bc351bf6-8408-4c4d-990d-99df03a21649@github.com> Message-ID: On Thu, 22 Jan 2026 11:11:04 GMT, Ivan Bereziuk wrote: >> `jcmd` provides great diagnostics but many commands lack a timestamp in their output. >> Adding a timestamp to the output would add value for those debugging JVM data. >> >> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. >> >> With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-t": >> >> jcmd [pid | main-class] [-t] command... | PerfCounter.print | -f filename >> ^^^^ >> >> * The choice for time format is ISO 8601 `yyyy-MM-dd'T'HH:mm:ss.SSSZ` (example `2026-01-21T16:58:49.518+0100`) >> * if "-t" flag is not passed, `Thread.print` keeps printing "yyyy-MM-dd HH:mm:ss" timestamp to preserve backwards compatibility. > > Ivan Bereziuk has updated the pull request incrementally with one additional commit since the last revision: > > change flag name from -T to -t Thanks Thomas yes it's kind of bikeshedding, but worth talking about hopefully. 8-) Glad you agree with the simplicity part. But you like the timestamp coming from the JVM: > The time may run differently on the jcmd side (e.g. target runs on a container on Windows or MacOS, or if we ever add remote capabilities to jcmd) We don't want to do anything which prohibits possible future features, but also don't want to be constrained by what might possibly happen. 8-) So you're on the same hardware, running jcmd that may contact a container. jcmd logs the time. Is the time in the container that different? The new info contains the TZ/offset I think. We also have DiagnosticCommandMBean for remove invokation. Keeping this timestamp on the client side means we don't need a project to look into what could happen there. > adding it to the hotspot will automatically work for every version of jcmd Yes, this works both ways. The new jcmd will give timestamps when talking to older VMs. You can opt-in to new behaviour by choosing a later jcmd, without a JDK update in the app. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3789758234 From ghan at openjdk.org Fri Jan 23 11:40:58 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Fri, 23 Jan 2026 11:40:58 GMT Subject: Integrated: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 08:42:07 GMT, Guanqiang Han wrote: > Please review this change. Thanks! > > **Description:** > > When -XX:+PrintDeoptimizationDetails is enabled, vframeArray.cpp prints interpreted frames under ttyLocker. > https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/runtime/vframeArray.cpp#L493-L503 > In the WizardMode && Verbose branch it calls Method::print_codes() / print_codes_on(). The bytecode printing path may acquire MDOExtraData_lock (rank nosafepoint-1). > https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/interpreter/bytecodeTracer.cpp#L597-L602 > Calling it while holding tty_lock violates the global lock ranking order and triggers a lock rank inversion assertion. > > **Fix:** > > Generate the bytecode dump before taking tty_lock, and print it afterwards under ttyLocker to keep the output coherent while preserving correct lock acquisition order. > To avoid double buffering when the target stream is already a thread-local stringStream, extend BytecodeTracer::print_method_codes with a buffered flag . The new call site uses buffered=false when dumping into the temporary stringStream. > > **Test:** > > GHA This pull request has now been integrated. Changeset: 6f6966b2 Author: Guanqiang Han Committer: Dean Long URL: https://git.openjdk.org/jdk/commit/6f6966b28b2c5a18b001be49f5db429c667d7a8f Stats: 71 lines in 6 files changed: 54 ins; 2 del; 15 mod 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) Reviewed-by: dholmes, dlong ------------- PR: https://git.openjdk.org/jdk/pull/29186 From tschatzl at openjdk.org Fri Jan 23 12:41:15 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 23 Jan 2026 12:41:15 GMT Subject: RFR: 8376195: Convert ThreadLocalAllocBuffer to use Atomic Message-ID: <1TAUwWsHEcAIzMF35Q3v9xsDhsNV6ZhGZDCO9fh93KI=.f14438d0-8874-4259-b33d-83ad8b9bf2b3@github.com> Hi all, please review the change to use `Atomic` in `ThreadLocalAllocBuffer`. Testing: gha Thanks, Thomas ------------- Commit messages: - 8376195 Changes: https://git.openjdk.org/jdk/pull/29386/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29386&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376195 Stats: 28 lines in 4 files changed: 2 ins; 9 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/29386.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29386/head:pull/29386 PR: https://git.openjdk.org/jdk/pull/29386 From vyazici at openjdk.org Fri Jan 23 13:50:39 2026 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 23 Jan 2026 13:50:39 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: On Mon, 12 Jan 2026 10:29:39 GMT, Damon Fenacci wrote: > ## Issue > > This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. > > This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. > > ## Causes > > The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. > > ## Fix > > A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: > https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 > This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. > > # Testing > > * Tier 1-3+ > * 2 JTReg tests added > * `TestRangeCheck.java` as regression test for the reported issue > * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion I'd like to provide some help for reviewers: 1. [JDK-8361842] (integrated in 655dc516c22) implemented changes for `java.lang.StringCoding` 2. [JDK-8374210] (integrated in 7e18de137c3) reported regressions against JDK-8361842, and used as the BACKOUT issue. 3. [JDK-8374582] (this PR) is the REDO of JDK-8361842, plus the fix for regressions reported in JDK-8374210 That is, this PR starts with 3c466d372b7 (i.e, the revert of 7e18de137c3), and continues with the fix, which is **the interesting part, and that can be viewed by diff'ing 3c466d372b7...ff22857609d**. (ff22857609d is the last commit as of date.) [JDK-8361842]: https://bugs.openjdk.org/browse/JDK-8361842 [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210 [JDK-8374582]: https://bugs.openjdk.org/browse/JDK-8374582 ------------- PR Comment: https://git.openjdk.org/jdk/pull/29164#issuecomment-3790314570 From vpaprotski at openjdk.org Fri Jan 23 13:57:43 2026 From: vpaprotski at openjdk.org (Volodymyr Paprotski) Date: Fri, 23 Jan 2026 13:57:43 GMT Subject: RFR: 8374926: EnableX86ECoreOpts was not enabled on some hybrid CPU [v3] In-Reply-To: References: <3wEINJR2IDU6Hi772So8ZqytuF775R-76c4ngkfWuqw=.aa820856-05d8-4fe6-a260-1c6b98bb2921@github.com> Message-ID: On Fri, 23 Jan 2026 02:39:31 GMT, Yasumasa Suenaga wrote: > Do you mean this PR should add to check hybrid flag only, without checking leaf 1Ah? If so, I will revert the merge for leaf 1Ah, and will add model ID for CWF. I would prefer that, at least for now/this PR.. keep the existing model checks and add `supports_hybrid()`. (The atom core might be a good idea, not sure. Would need some spelunking) ------------- PR Comment: https://git.openjdk.org/jdk/pull/29149#issuecomment-3790340915 From aph at openjdk.org Fri Jan 23 14:26:48 2026 From: aph at openjdk.org (Andrew Haley) Date: Fri, 23 Jan 2026 14:26:48 GMT Subject: RFR: 8374349: [VectorAPI]: AArch64: Prefer merging mode SVE CPY instruction In-Reply-To: <_qJ_Qo_Mqexx7dYu0Vkc9ru4SxZ0izfqifaUIAL1iyQ=.741b11d4-a89d-495e-8d31-78fed690abf6@github.com> References: <_0ouKSVAIyzg0g9hA2jZXNH-_cCqJjNCSh7kM2dn80w=.b93145c3-c465-423a-ab68-c8d7bd7e4280@github.com> <_qJ_Qo_Mqexx7dYu0Vkc9ru4SxZ0izfqifaUIAL1iyQ=.741b11d4-a89d-495e-8d31-78fed690abf6@github.com> Message-ID: On Fri, 23 Jan 2026 10:28:46 GMT, Eric Fang wrote: > Maintaining microarchitecture-specific handling might be worthwhile. Or not. :-) > This provides some flexibility for different/future architectures. We already have enough flexibility for the future. We can change the source code once we know what we need. We make new releases four times a year. > Because we're unsure how the future microarchitecture will behave, from a performance and code size perspective, we generally prefer single instruction over multiple instructions. Is it fine to you ? No. Please do the right thing for today's hardware. We don't know that some other SVE implementation will not benefit from this optimization, either,. One thing you can do is add a flag to control this minor optimization, but make it `constexpr bool = true` until we know what other SVE implementations might do. In general: Dead code in HotSpot is dangerous. Over time it rots, leading to hard-to-diagnose bugs when if it does get exercised. If we don't _know_ that we need something, we shouldn't do it. Don't speculatively add code. We don't need the AArch64 to be come (even more of) a jungle of microarchitecture-specific tweaks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29359#issuecomment-3790481835 From aph at openjdk.org Fri Jan 23 14:26:50 2026 From: aph at openjdk.org (Andrew Haley) Date: Fri, 23 Jan 2026 14:26:50 GMT Subject: RFR: 8374349: [VectorAPI]: AArch64: Prefer merging mode SVE CPY instruction In-Reply-To: <_0ouKSVAIyzg0g9hA2jZXNH-_cCqJjNCSh7kM2dn80w=.b93145c3-c465-423a-ab68-c8d7bd7e4280@github.com> References: <_0ouKSVAIyzg0g9hA2jZXNH-_cCqJjNCSh7kM2dn80w=.b93145c3-c465-423a-ab68-c8d7bd7e4280@github.com> Message-ID: On Thu, 22 Jan 2026 12:31:19 GMT, Eric Fang wrote: > Microbenchmarks show this change brings performance uplift ranging from **11%** to **33%**, depending on the specific operation and data types. I see 2% uplift on these numbers. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29359#issuecomment-3790486155 From rkennke at openjdk.org Fri Jan 23 14:34:24 2026 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 23 Jan 2026 14:34:24 GMT Subject: RFR: 8373021: aarch64: MacroAssembler::arrays_equals reads out of bounds In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 19:16:14 GMT, Cesar Soares Lucas wrote: > Please review this PR to add back array-length comparison to AArch64 array-equals intrinsic. > > [JDK-8331098](https://bugs.openjdk.org/browse/JDK-8331098) removed the direct comparison of both arrays' length but doing so will cause the code to index out of bounds of the array payload. The root cause of the problem is: 1) the main comparison loops only compare the array lengths (indirectly) after reading at least 16 bytes from _both_ arrays; 2) only the length of the first array, `a1`, is checked before the main comparison loop. Consequently, we code may read past the end of the array payload if the second array is shorter than 16 bytes. The result of indexing out of the array bounds is dependent on where the array is allocated and what comes after it: the VM may crash because of segment violation if the object is at the end of the heap (or Eden?) and there is no padding after the object or it can cause the array comparison to be incorrect. > > Testing: > > - [x] tier1 (+CCP) > - [x] tier1 (-CCP) > - [x] tier2 (+CCP) > - [x] tier2 (-CCP) Looks good, thank you! ------------- Marked as reviewed by rkennke (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29372#pullrequestreview-3697809699 From aph at openjdk.org Fri Jan 23 14:48:10 2026 From: aph at openjdk.org (Andrew Haley) Date: Fri, 23 Jan 2026 14:48:10 GMT Subject: RFR: 8373021: aarch64: MacroAssembler::arrays_equals reads out of bounds In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 19:16:14 GMT, Cesar Soares Lucas wrote: > Please review this PR to add back array-length comparison to AArch64 array-equals intrinsic. > > [JDK-8331098](https://bugs.openjdk.org/browse/JDK-8331098) removed the direct comparison of both arrays' length but doing so will cause the code to index out of bounds of the array payload. The root cause of the problem is: 1) the main comparison loops only compare the array lengths (indirectly) after reading at least 16 bytes from _both_ arrays; 2) only the length of the first array, `a1`, is checked before the main comparison loop. Consequently, we code may read past the end of the array payload if the second array is shorter than 16 bytes. The result of indexing out of the array bounds is dependent on where the array is allocated and what comes after it: the VM may crash because of segment violation if the object is at the end of the heap (or Eden?) and there is no padding after the object or it can cause the array comparison to be incorrect. > > Testing: > > - [x] tier1 (+CCP) > - [x] tier1 (-CCP) > - [x] tier2 (+CCP) > - [x] tier2 (-CCP) Thank you. ------------- Marked as reviewed by aph (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29372#pullrequestreview-3697883110 From duke at openjdk.org Fri Jan 23 15:02:09 2026 From: duke at openjdk.org (Ivan Bereziuk) Date: Fri, 23 Jan 2026 15:02:09 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v4] In-Reply-To: <93J0DXbDwwQDYqasv9f9lF4NofBWMLb4NTiyMCXkdsM=.bc351bf6-8408-4c4d-990d-99df03a21649@github.com> References: <93J0DXbDwwQDYqasv9f9lF4NofBWMLb4NTiyMCXkdsM=.bc351bf6-8408-4c4d-990d-99df03a21649@github.com> Message-ID: On Thu, 22 Jan 2026 11:11:04 GMT, Ivan Bereziuk wrote: >> `jcmd` provides great diagnostics but many commands lack a timestamp in their output. >> Adding a timestamp to the output would add value for those debugging JVM data. >> >> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. >> >> With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-t": >> >> jcmd [pid | main-class] [-t] command... | PerfCounter.print | -f filename >> ^^^^ >> >> * The choice for time format is ISO 8601 `yyyy-MM-dd'T'HH:mm:ss.SSSZ` (example `2026-01-21T16:58:49.518+0100`) >> * if "-t" flag is not passed, `Thread.print` keeps printing "yyyy-MM-dd HH:mm:ss" timestamp to preserve backwards compatibility. > > Ivan Bereziuk has updated the pull request incrementally with one additional commit since the last revision: > > change flag name from -T to -t Kevin, Thomas, thank you very much for comments. Indeed. The way `jcmd` is implemented currently and in older JDKs, the tool does not question arguments following PID. One more thing to keep in mind. The is a use case with a chain of commands passed to `jcmd`. With this MR we can timestamp per command: $ cat input.txt -t VM.version -t VM.version $ jcmd -f input.txt 51721: 2026-01-23T14:58:28.515+0100 Java HotSpot(TM) 64-Bit Server VM version 27-internal-john24.open JDK 27.0.0 2026-01-23T14:58:28.518+0100 Java HotSpot(TM) 64-Bit Server VM version 27-internal-john24.open JDK 27.0.0 The timestamping implemented in `JCmd.java` would print timestamp only once at the beginning. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3790630542 From duke at openjdk.org Fri Jan 23 15:05:44 2026 From: duke at openjdk.org (Robert Toyonaga) Date: Fri, 23 Jan 2026 15:05:44 GMT Subject: RFR: 8353564: Fail fatally if os::release_memory or os::uncommit_memory fails [v3] In-Reply-To: References: Message-ID: > This PR is a follow up to JDK-8341491. See original discussion: https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700 > > This PR makes `os::release_memory`, `os::uncommit_memory`, `os::release_memory_special`, and `os::unmap_memory` fail fatally if they encounter an error. These methods require obtaining the NMT lock. Fatally failing in these places would potentially allow for the tightening of NMT virtual memory locking scopes (future work, if this PR is accepted). Already in most cases, the callers fail fatally or assert(false) when these os:: methods fail. Another reason to fatally fail is that if the OS memory operation fails, it can be difficult to know for sure what state the OS left the memory in and recover. > > `release_memory`/`uncommit_memory`/`release_memory_special`/`unmap_memory` can fail due to ? Bad arguments, or ? The OS encountered an issue out of control of the JVM. > > ? > If there is a JVM bug, it's probably reasonable to fatally fail here. Or the caller could be intentionally passing arguments that may or may not be valid. I don't think there is any code like that currently, and this is probably a bad pattern to be following anyway. > > ? > In platform dependent code: > With regard to mmap/munmap, the only errors that aren't due to bad arguments are ENOMEM and ones related to file descriptors (which are not applicable to uncommit or release). > On Windows, VirtualFree only fails due to bad arguments. > On AIX, shmdt and disclaim64 only fail due to bad arguments. msync could spontaneously fail with EIO: "An I/O error occurred while reading from or writing to the file system." > On BSD, it seems like mprotect and madvise fail only due to bad arguments or invalid privileges. > > In the [original discussion](https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700), the main question was whether ENOMEM upon os::uncommit_memory was recoverable. This may be possible if we uncommit the middle of a region - splitting it in two. This could exceed the limit of the number of mappings resulting in ENOMEM. > > If none of the scenarios in ? are recoverable, then perhaps fatally failing is OK. > > Testing: > - Tier 1. > - Manual testing to make sure we fatally fail and the correct messages are printed. Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision: remove whitespace. Add extra message fro linux ENOMEM on uncommit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29240/files - new: https://git.openjdk.org/jdk/pull/29240/files/23bd4dec..2c7116ea Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29240&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29240&range=01-02 Stats: 4 lines in 2 files changed: 3 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29240.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29240/head:pull/29240 PR: https://git.openjdk.org/jdk/pull/29240 From duke at openjdk.org Fri Jan 23 15:07:08 2026 From: duke at openjdk.org (Robert Toyonaga) Date: Fri, 23 Jan 2026 15:07:08 GMT Subject: RFR: 8353564: Fail fatally if os::release_memory or os::uncommit_memory fails [v2] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 06:52:16 GMT, Thomas Stuefe wrote: > > Thank you everyone for the feedback! > > I've removed the error strings now. > > > os::unmap_memory only returns true now. Is there a reason why the return value type of this function is not changed? > > > > > > Yes, they can all return void now. I've made the change and updated the callers where necessary too. > > > Much more sense would be to (in a separate PR) highlight the fact in the hs-err file that this particular native OOM may have been caused by running against the mapping limit, and that increasing said limit may help. Maybe we do this already, not sure. > > > > > > How about if I added that note in the fatal error message in `os::uncommit_memory`? I think then that note should also show up in the hs_err file. > > Sure, that would work, but this would be highly Linux-specific. So, would need ifdefs. > > Wait, the failing code is OS specific, too. So, okay :-) > > You need to do this for ENOMEM only then. Because `os::uncommit_memory` could also fail due to bad arguments on other platforms, I added an earlier fatal error in os_linux.cpp `pd_uncommit_memory`. This should be reached before the general fatal error in `os::uncommit_memory` and avoids needing ifdefs. I also check the error number there too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29240#issuecomment-3790655758 From asmehra at openjdk.org Fri Jan 23 15:41:14 2026 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 23 Jan 2026 15:41:14 GMT Subject: RFR: 8374549: Extend MetaspaceClosure to cover non-MetaspaceObj types In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 20:32:46 GMT, Ioi Lam wrote: > PackageEntry, ModuleEntry and GrowableArray cannot be subclasses from MetaspaceObject due to various constraints. @iklam what prevents `PackageEntry` and `ModuleEntry` from being a subclass of `MetaspaceObject`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29049#issuecomment-3790849900 From aph at openjdk.org Fri Jan 23 15:51:45 2026 From: aph at openjdk.org (Andrew Haley) Date: Fri, 23 Jan 2026 15:51:45 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v23] In-Reply-To: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: > In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. > > Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. > > This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. > > The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. > > We mark all sites that we know will write to code memory with > `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. > > We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. > > It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. > > One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude, and it's better to be able to ... Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits: - Merge from master - Merge branch 'master' into JDK-8328306 - Merge from maaster - Merge from maaster - Merge branch 'master' into JDK-8328306 - Cleanup - Check for working WX - Check for working WX - Check for working WX - Check for working WX - ... and 35 more: https://git.openjdk.org/jdk/compare/6f6966b2...22c07994 ------------- Changes: https://git.openjdk.org/jdk/pull/26562/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=22 Stats: 458 lines in 35 files changed: 387 ins; 28 del; 43 mod Patch: https://git.openjdk.org/jdk/pull/26562.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26562/head:pull/26562 PR: https://git.openjdk.org/jdk/pull/26562 From aph at openjdk.org Fri Jan 23 16:05:30 2026 From: aph at openjdk.org (Andrew Haley) Date: Fri, 23 Jan 2026 16:05:30 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v22] In-Reply-To: <72UOc-ZUvUYUR2xoscmB1gN5TVSIFKb1izWjEln4jrc=.11893391-281c-4f37-8715-e90053ba9510@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <72UOc-ZUvUYUR2xoscmB1gN5TVSIFKb1izWjEln4jrc=.11893391-281c-4f37-8715-e90053ba9510@github.com> Message-ID: On Thu, 18 Dec 2025 01:55:12 GMT, Dean Long wrote: >> Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 43 commits: >> >> - Merge from maaster >> - Merge from maaster >> - Merge branch 'master' into JDK-8328306 >> - Cleanup >> - Check for working WX >> - Check for working WX >> - Check for working WX >> - Check for working WX >> - Check for working WX >> - Check for working WX >> - ... and 33 more: https://git.openjdk.org/jdk/compare/9a88d7f4...42e5505d > > src/hotspot/share/code/nmethod.cpp line 2197: > >> 2195: >> 2196: void nmethod::mark_as_maybe_on_stack() { >> 2197: MACOS_AARCH64_ONLY(os::thread_wx_enable_write()); > > After JDK-8373794, we won't need to be in write mode to modify nmethod fields. Sorry, found it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2721833416 From aph at openjdk.org Fri Jan 23 16:11:19 2026 From: aph at openjdk.org (Andrew Haley) Date: Fri, 23 Jan 2026 16:11:19 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v24] In-Reply-To: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: > In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. > > Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. > > This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. > > The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. > > We mark all sites that we know will write to code memory with > `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. > > We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. > > It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. > > One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude, and it's better to be able to ... Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: After JDK-8373794, we don't need to be in write mode to modify nmethod fields. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26562/files - new: https://git.openjdk.org/jdk/pull/26562/files/22c07994..37730e6a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=23 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=22-23 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26562.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26562/head:pull/26562 PR: https://git.openjdk.org/jdk/pull/26562 From duke at openjdk.org Fri Jan 23 16:26:57 2026 From: duke at openjdk.org (Ivan Bereziuk) Date: Fri, 23 Jan 2026 16:26:57 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v5] In-Reply-To: References: Message-ID: > `jcmd` provides great diagnostics but many commands lack a timestamp in their output. > Adding a timestamp to the output would add value for those debugging JVM data. > > Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. > > With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-t": > > jcmd [pid | main-class] [-t] command... | PerfCounter.print | -f filename > ^^^^ > > * The choice for time format is ISO 8601 `yyyy-MM-dd'T'HH:mm:ss.SSSZ` (example `2026-01-21T16:58:49.518+0100`) > * if "-t" flag is not passed, `Thread.print` keeps printing "yyyy-MM-dd HH:mm:ss" timestamp to preserve backwards compatibility. Ivan Bereziuk has updated the pull request incrementally with one additional commit since the last revision: tweaked help working for -t flag ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27368/files - new: https://git.openjdk.org/jdk/pull/27368/files/f0e39a34..7371f3c1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27368&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27368&range=03-04 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27368.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27368/head:pull/27368 PR: https://git.openjdk.org/jdk/pull/27368 From iklam at openjdk.org Fri Jan 23 16:30:31 2026 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 23 Jan 2026 16:30:31 GMT Subject: RFR: 8374549: Extend MetaspaceClosure to cover non-MetaspaceObj types In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 15:38:24 GMT, Ashutosh Mehra wrote: > > PackageEntry, ModuleEntry and GrowableArray cannot be subclasses from MetaspaceObject due to various constraints. > > @iklam what prevents `PackageEntry` and `ModuleEntry` from being a subclass of `MetaspaceObject`? These objects are allocated while holding the `Module_lock`. However, allocations from metaspace cannot be done while holding a native lock -- before metsapce is expanded, the JVM triggers a GC to reclaim metadata held by dead classes, but GCs cannot happen while a native lock is being held. Currently we have other types that aren't really in the metaspace but are declared as subclasses of `MetaspaceObject` (e.g., `KlassTrainingData`, `AdapterHandlerEntry`) just so that they can be visited by `MetaspaceClosure`. These are actually malloc'ed. After this PR, I plan to make a follow-up PR to change these to no subclass from `MetaspaceObject` ------------- PR Comment: https://git.openjdk.org/jdk/pull/29049#issuecomment-3791096921 From jvernee at openjdk.org Fri Jan 23 16:44:05 2026 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 23 Jan 2026 16:44:05 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v7] In-Reply-To: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> References: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> Message-ID: On Thu, 18 Dec 2025 00:03:10 GMT, Chen Liang wrote: >> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. >> >> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. >> >> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. >> >> Paging @minborg who requested Optional folding for review. >> >> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Move the test to a core library purposed directory Marked as reviewed by jvernee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28540#pullrequestreview-3698507443 From alanb at openjdk.org Fri Jan 23 16:51:02 2026 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 23 Jan 2026 16:51:02 GMT Subject: RFR: 8373924: Dangling pointer in ImageDecompressor::image_decompressor_close of imageDecompressor.cpp In-Reply-To: References: Message-ID: <2Eyztyttm_T8FTk0QITmfzXbVsz9yNpZRNptLnus6fs=.88f55f3e-1014-4dbb-8041-d174a3475e26@github.com> On Thu, 22 Jan 2026 18:57:30 GMT, Henry Jen wrote: > I don't see image_decompressor_close actually referenced in the code base, as the decompressors are static and setup from image_decompressor_init(). > > This PR implements proper cleanup for decompressors to be defensive. src/java.base/share/native/libjimage/imageDecompressor.cpp line 96: > 94: _decompressors = NULL; > 95: _decompressors_num = 0; > 96: } What would you think about removing it? Its dead code and not tested. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29371#discussion_r2722035594 From asmehra at openjdk.org Fri Jan 23 16:55:23 2026 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 23 Jan 2026 16:55:23 GMT Subject: RFR: 8374549: Extend MetaspaceClosure to cover non-MetaspaceObj types In-Reply-To: References: Message-ID: <2J18eid_bj9YDudx78DxfQ1-3nlBCWJdn8aGgINWOHo=.c2a68225-99d6-4cfc-b161-5cfae38ffe80@github.com> On Mon, 5 Jan 2026 20:32:46 GMT, Ioi Lam wrote: > Previously, `MetaspaceClosure` could iterate only `MetaspaceObject`, using its four member functions: > > - `is_read_only_by_default()` > - `metaspace_pointers_do()` > - `size()` > - `type()` > > `PackageEntry`, `ModuleEntry` and `GrowableArray` cannot be subclasses from `MetaspaceObject` due to various constraints. As a result, they were copied with ad-hoc code. > > This PR updates the templates in `MetaspaceClosure` so that it can iterate any classes that have the above four functions. This allows new types of data to be uniformly copied into the AOT cache (aka CDS archive) without ad-hoc copiers. > > This PR is necessary for future evolution of AOT as more types of data will be copied into the AOT cache. For example, in Valhalla we have a `GrowableArray` that needs to be copied along with `AdapterHandleEntry`. I think we should also move `_aot_metaspace_top` and `_aot_metaspace_base` out of `MetaspaceObj `. Seems like `AOTMetaspace` is a better place to store the bounds. I guess it can be done in a follow-up pr. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29049#issuecomment-3791231196 From cslucas at openjdk.org Fri Jan 23 17:58:57 2026 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Fri, 23 Jan 2026 17:58:57 GMT Subject: Integrated: 8373021: aarch64: MacroAssembler::arrays_equals reads out of bounds In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 19:16:14 GMT, Cesar Soares Lucas wrote: > Please review this PR to add back array-length comparison to AArch64 array-equals intrinsic. > > [JDK-8331098](https://bugs.openjdk.org/browse/JDK-8331098) removed the direct comparison of both arrays' length but doing so will cause the code to index out of bounds of the array payload. The root cause of the problem is: 1) the main comparison loops only compare the array lengths (indirectly) after reading at least 16 bytes from _both_ arrays; 2) only the length of the first array, `a1`, is checked before the main comparison loop. Consequently, we code may read past the end of the array payload if the second array is shorter than 16 bytes. The result of indexing out of the array bounds is dependent on where the array is allocated and what comes after it: the VM may crash because of segment violation if the object is at the end of the heap (or Eden?) and there is no padding after the object or it can cause the array comparison to be incorrect. > > Testing: > > - [x] tier1 (+CCP) > - [x] tier1 (-CCP) > - [x] tier2 (+CCP) > - [x] tier2 (-CCP) This pull request has now been integrated. Changeset: 2c3ad0f4 Author: Cesar Soares Lucas URL: https://git.openjdk.org/jdk/commit/2c3ad0f425c75332412a5e8e5733dd0d073a09c8 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod 8373021: aarch64: MacroAssembler::arrays_equals reads out of bounds Reviewed-by: rkennke, aph ------------- PR: https://git.openjdk.org/jdk/pull/29372 From cslucas at openjdk.org Fri Jan 23 17:58:57 2026 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Fri, 23 Jan 2026 17:58:57 GMT Subject: RFR: 8373021: aarch64: MacroAssembler::arrays_equals reads out of bounds In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 14:31:36 GMT, Roman Kennke wrote: >> Please review this PR to add back array-length comparison to AArch64 array-equals intrinsic. >> >> [JDK-8331098](https://bugs.openjdk.org/browse/JDK-8331098) removed the direct comparison of both arrays' length but doing so will cause the code to index out of bounds of the array payload. The root cause of the problem is: 1) the main comparison loops only compare the array lengths (indirectly) after reading at least 16 bytes from _both_ arrays; 2) only the length of the first array, `a1`, is checked before the main comparison loop. Consequently, we code may read past the end of the array payload if the second array is shorter than 16 bytes. The result of indexing out of the array bounds is dependent on where the array is allocated and what comes after it: the VM may crash because of segment violation if the object is at the end of the heap (or Eden?) and there is no padding after the object or it can cause the array comparison to be incorrect. >> >> Testing: >> >> - [x] tier1 (+CCP) >> - [x] tier1 (-CCP) >> - [x] tier2 (+CCP) >> - [x] tier2 (-CCP) > > Looks good, thank you! Thank you for reviewing @rkennke @theRealAph ------------- PR Comment: https://git.openjdk.org/jdk/pull/29372#issuecomment-3791519719 From liach at openjdk.org Fri Jan 23 18:26:09 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 23 Jan 2026 18:26:09 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v12] In-Reply-To: References: Message-ID: > Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) Chen Liang 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 23 additional commits since the last revision: - Design detail updates, thanks to jorn - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache - Missed IR test review, rearrange benches - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache - Stage - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache - Review - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache - Bugs and verify loader leak - Try to avoid loader leak - ... and 13 more: https://git.openjdk.org/jdk/compare/4ac48240...77ea5565 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28585/files - new: https://git.openjdk.org/jdk/pull/28585/files/1d5461db..77ea5565 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=10-11 Stats: 93166 lines in 3834 files changed: 46542 ins; 16001 del; 30623 mod Patch: https://git.openjdk.org/jdk/pull/28585.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28585/head:pull/28585 PR: https://git.openjdk.org/jdk/pull/28585 From kbarrett at openjdk.org Fri Jan 23 18:49:44 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 23 Jan 2026 18:49:44 GMT Subject: RFR: 8375535: G1: Convert CardTableBarrierSet and subclasses to use Atomic In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 12:58:39 GMT, Thomas Schatzl wrote: > Hi all, > > use `Atomic` instead of `AtomicAccess` in `CardTableBarrierSet` and subclasses. Since this modifies `CardTableBarrierSet::_card_table` the change has some fan-out. > > Testing: gha > > Thanks, > Thomas Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29360#pullrequestreview-3699068875 From henryjen at openjdk.org Fri Jan 23 18:59:53 2026 From: henryjen at openjdk.org (Henry Jen) Date: Fri, 23 Jan 2026 18:59:53 GMT Subject: RFR: 8373924: Dangling pointer in ImageDecompressor::image_decompressor_close of imageDecompressor.cpp In-Reply-To: <2Eyztyttm_T8FTk0QITmfzXbVsz9yNpZRNptLnus6fs=.88f55f3e-1014-4dbb-8041-d174a3475e26@github.com> References: <2Eyztyttm_T8FTk0QITmfzXbVsz9yNpZRNptLnus6fs=.88f55f3e-1014-4dbb-8041-d174a3475e26@github.com> Message-ID: On Fri, 23 Jan 2026 16:48:47 GMT, Alan Bateman wrote: >> I don't see image_decompressor_close actually referenced in the code base, as the decompressors are static and setup from image_decompressor_init(). >> >> This PR implements proper cleanup for decompressors to be defensive. > > src/java.base/share/native/libjimage/imageDecompressor.cpp line 96: > >> 94: _decompressors = NULL; >> 95: _decompressors_num = 0; >> 96: } > > What would you think about removing it? Its dead code and not tested. We can do that too since it's by design to have same lifespan as the process. I'll run some more tests to confirm removing is safe. The close can be added when the requirements change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29371#discussion_r2722455193 From jvernee at openjdk.org Fri Jan 23 19:22:03 2026 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 23 Jan 2026 19:22:03 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v12] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 18:26:09 GMT, Chen Liang wrote: >> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) > > Chen Liang 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 23 additional commits since the last revision: > > - Design detail updates, thanks to jorn > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache > - Missed IR test review, rearrange benches > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache > - Stage > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache > - Review > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache > - Bugs and verify loader leak > - Try to avoid loader leak > - ... and 13 more: https://git.openjdk.org/jdk/compare/d8405cdd...77ea5565 src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2043: > 2041: // > 2042: // Condition 1 and 2 indicates this access descriptor may see a VarHandle > 2043: // different from the captured VarHandle. Condition 3 requires the Suggestion: // Condition 1 and 2 indicates this access descriptor may see a VarHandle // different from the captured VarHandle. I don't see how this follows from condition 1 and 2 holding. A failure in either condition means we are may see multiple VH instance. I suggest: Suggestion: // If either condition 1 or 2 doesn't hold, we may see different var handle instances using the // same shared AccessDescriptor. In those cases we only cache the adaptation for one of the // var handle instances (the first one). Other instances will always use the slow path. src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2049: > 2047: // such as compareAndSet can appear at two sites, where each site > 2048: // has its own constant VarHandle. Such a usage pattern hurts adaption, > 2049: // but is perfectly dealt by the getMethodType_V constant folding branch. I think this information should be put on the template string instead, since it's mostly referencing that code. I think it's enough to say that we 'skip potentially costly adaptation' by going through the `getMethodType_V` branch. >From the text as written, it's not clear why such usage patterns hurt adaptation. I think It would be more accurate to say that: "in such cases, only one of the two var handles will have its adaptation cached". src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2055: > 2053: // invocation type of the underlying MemberName, or MH for indirect VH), > 2054: // perform a foldable lookup with a hash table, and hope C2 inline it > 2055: // all. Such an optimization applies for general MethodHandle.asType. Suggestion: // all. Such an optimization applies to general MethodHandle.asType. src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2055: > 2053: // invocation type of the underlying MemberName, or MH for indirect VH), > 2054: // perform a foldable lookup with a hash table, and hope C2 inline it > 2055: // all. Such an optimization applies for general MethodHandle.asType. This reads as "put a ... to another ... perform", which doesn't sounds grammatically correct. Maybe: Suggestion: // In the long run, we wish to cache each specific-type invoker that converts // from one fixed type (symbolicMethodTypeInvoker) to another (the // invocation type of the underlying MemberName, or MH for indirect VH), // using a foldable lookup with a hash table, and hope C2 inline it // all. Such an optimization applies for general MethodHandle.asType. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2722389574 PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2722416361 PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2722376203 PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2722514070 From kvn at openjdk.org Fri Jan 23 19:36:14 2026 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 23 Jan 2026 19:36:14 GMT Subject: RFR: 8374549: Extend MetaspaceClosure to cover non-MetaspaceObj types In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 20:32:46 GMT, Ioi Lam wrote: > Previously, `MetaspaceClosure` could iterate only `MetaspaceObject`, using its four member functions: > > - `is_read_only_by_default()` > - `metaspace_pointers_do()` > - `size()` > - `type()` > > `PackageEntry`, `ModuleEntry` and `GrowableArray` cannot be subclasses from `MetaspaceObject` due to various constraints. As a result, they were copied with ad-hoc code. > > This PR updates the templates in `MetaspaceClosure` so that it can iterate any classes that have the above four functions. This allows new types of data to be uniformly copied into the AOT cache (aka CDS archive) without ad-hoc copiers. > > This PR is necessary for future evolution of AOT as more types of data will be copied into the AOT cache. For example, in Valhalla we have a `GrowableArray` that needs to be copied along with `AdapterHandleEntry`. Reviewed. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29049#pullrequestreview-3699257406 From kvn at openjdk.org Fri Jan 23 19:36:17 2026 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 23 Jan 2026 19:36:17 GMT Subject: RFR: 8374549: Extend MetaspaceClosure to cover non-MetaspaceObj types In-Reply-To: <8DiJMy5oef4CDKD4GTqCVgizgss5TpU4GLtPVwjd0II=.6edb5c0b-ec67-4168-ba36-388aa6db4a73@github.com> References: <7fCqqxJTaRd1JzzT7fqrcsTwSKpVnr7kb_SuubuMOTg=.15269a6d-6034-4335-8193-09891d63a422@github.com> <8DiJMy5oef4CDKD4GTqCVgizgss5TpU4GLtPVwjd0II=.6edb5c0b-ec67-4168-ba36-388aa6db4a73@github.com> Message-ID: On Fri, 23 Jan 2026 06:22:50 GMT, Ioi Lam wrote: >> src/hotspot/share/cds/cppVtables.cpp line 62: >> >>> 60: >>> 61: // AOTGrowableArray has a vtable only when in non-product builds (due to >>> 62: // the virtual printing functions in AnyObj). >> >> Can we devirtualize it? You would need to reconstruct Vpointer in non-debug build otherwise. > > Since `AnyObj` doesn't carry any type information, we cannot easily devirtualize this call. > > In debug builds, the vtable is updated in the production run. The vtable updates are driven by the `CPP_VTABLE_TYPES_DO` macro in cppVtables.cpp. The following have been added to this macro > > > #ifndef PRODUCT > > // AOTGrowableArray has a vtable only when in non-product builds (due to > // the virtual printing functions in AnyObj). > > using GrowableArray_ModuleEntry_ptr = AOTGrowableArray; > > #define DEBUG_CPP_VTABLE_TYPES_DO(f) \ > f(GrowableArray_ModuleEntry_ptr) \ Thank you, for explanation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29049#discussion_r2722561825 From asmehra at openjdk.org Fri Jan 23 19:55:27 2026 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 23 Jan 2026 19:55:27 GMT Subject: RFR: 8374549: Extend MetaspaceClosure to cover non-MetaspaceObj types In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 20:32:46 GMT, Ioi Lam wrote: > Previously, `MetaspaceClosure` could iterate only `MetaspaceObject`, using its four member functions: > > - `is_read_only_by_default()` > - `metaspace_pointers_do()` > - `size()` > - `type()` > > `PackageEntry`, `ModuleEntry` and `GrowableArray` cannot be subclasses from `MetaspaceObject` due to various constraints. As a result, they were copied with ad-hoc code. > > This PR updates the templates in `MetaspaceClosure` so that it can iterate any classes that have the above four functions. This allows new types of data to be uniformly copied into the AOT cache (aka CDS archive) without ad-hoc copiers. > > This PR is necessary for future evolution of AOT as more types of data will be copied into the AOT cache. For example, in Valhalla we have a `GrowableArray` that needs to be copied along with `AdapterHandleEntry`. lgtm src/hotspot/share/utilities/growableArray.hpp line 302: > 300: > 301: // MetaspaceClosure support. > 302: E** data_addr() { My only concern is that it is marked public which breaks encapsulation. I think we can mark it as protected if only `AOTGrowableArray` is accessing it but gtest also uses it so I am not sure if anything can be done here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29049#issuecomment-3792099008 PR Review Comment: https://git.openjdk.org/jdk/pull/29049#discussion_r2722622911 From asmehra at openjdk.org Fri Jan 23 19:59:30 2026 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 23 Jan 2026 19:59:30 GMT Subject: RFR: 8374549: Extend MetaspaceClosure to cover non-MetaspaceObj types In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 20:32:46 GMT, Ioi Lam wrote: > Previously, `MetaspaceClosure` could iterate only `MetaspaceObject`, using its four member functions: > > - `is_read_only_by_default()` > - `metaspace_pointers_do()` > - `size()` > - `type()` > > `PackageEntry`, `ModuleEntry` and `GrowableArray` cannot be subclasses from `MetaspaceObject` due to various constraints. As a result, they were copied with ad-hoc code. > > This PR updates the templates in `MetaspaceClosure` so that it can iterate any classes that have the above four functions. This allows new types of data to be uniformly copied into the AOT cache (aka CDS archive) without ad-hoc copiers. > > This PR is necessary for future evolution of AOT as more types of data will be copied into the AOT cache. For example, in Valhalla we have a `GrowableArray` that needs to be copied along with `AdapterHandleEntry`. Marked as reviewed by asmehra (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29049#pullrequestreview-3699357150 From liach at openjdk.org Fri Jan 23 20:08:58 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 23 Jan 2026 20:08:58 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v13] In-Reply-To: References: Message-ID: > Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Wording update, thanks Jorn ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28585/files - new: https://git.openjdk.org/jdk/pull/28585/files/77ea5565..5ba75d45 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=11-12 Stats: 16 lines in 2 files changed: 1 ins; 3 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/28585.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28585/head:pull/28585 PR: https://git.openjdk.org/jdk/pull/28585 From jrose at openjdk.org Fri Jan 23 21:49:50 2026 From: jrose at openjdk.org (John R Rose) Date: Fri, 23 Jan 2026 21:49:50 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v7] In-Reply-To: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> References: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> Message-ID: On Thu, 18 Dec 2025 00:03:10 GMT, Chen Liang wrote: >> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. >> >> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. >> >> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. >> >> Paging @minborg who requested Optional folding for review. >> >> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Move the test to a core library purposed directory Good work. ------------- Marked as reviewed by jrose (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28540#pullrequestreview-3699825444 From kvn at openjdk.org Fri Jan 23 21:53:38 2026 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 23 Jan 2026 21:53:38 GMT Subject: RFR: 8372617: Save and restore stubgen stubs when using an AOT code cache [v4] In-Reply-To: References: Message-ID: <2UOkLPAYC5PUUl51bDgkHzm9QK3_1KdUENhFkUZvKN8=.6c3b86e7-9e2e-4902-ba24-ed9858b33bec@github.com> On Tue, 20 Jan 2026 09:57:56 GMT, Andrew Dinn wrote: >> src/hotspot/share/code/aotCodeCache.cpp line 191: >> >>> 189: >>> 190: // Disable stubs caching until JDK-8357398 is fixed. >>> 191: // FLAG_SET_ERGO(AOTStubCaching, false); >> >> I can't seem to access JDK-8357398. I am not sure if that bug is fixed or not. But if it is not fixed yet, I think we should keep this un-commented. I guess this was commented out for testing purpose. > > That's a private bug (I believe it related to some internal testing which cannot be made public). Yu are right that this change is there to ensure the test checks stub save and restore. I also tweaked the AOTCodeFlags test for the same purpose. This change cannot go in as is without checking that it avoids the issue in JDK-8357398. If it does not then we would need to reset the above edit and the test. However, that means tier1 testing could fail to catch stub changes that correctly update runtime generation but fail to cache (the most likely error is failing to register an external address with the AOT cache). So, I'd prefer it if we could recheck the problem in JDK-8357398 and leave these changes as is. Perhaps @vnkozlov could help here? I closed this confidential bug and created open: https://bugs.openjdk.org/browse/JDK-8357593 It is not fixed. I tried several times to find what is causing it without success. Let me run general testing for these changes. And then will try to reproduce JCK issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28433#discussion_r2722965712 From kvn at openjdk.org Fri Jan 23 21:53:39 2026 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 23 Jan 2026 21:53:39 GMT Subject: RFR: 8372617: Save and restore stubgen stubs when using an AOT code cache [v4] In-Reply-To: <2UOkLPAYC5PUUl51bDgkHzm9QK3_1KdUENhFkUZvKN8=.6c3b86e7-9e2e-4902-ba24-ed9858b33bec@github.com> References: <2UOkLPAYC5PUUl51bDgkHzm9QK3_1KdUENhFkUZvKN8=.6c3b86e7-9e2e-4902-ba24-ed9858b33bec@github.com> Message-ID: On Fri, 23 Jan 2026 21:50:27 GMT, Vladimir Kozlov wrote: >> That's a private bug (I believe it related to some internal testing which cannot be made public). Yu are right that this change is there to ensure the test checks stub save and restore. I also tweaked the AOTCodeFlags test for the same purpose. This change cannot go in as is without checking that it avoids the issue in JDK-8357398. If it does not then we would need to reset the above edit and the test. However, that means tier1 testing could fail to catch stub changes that correctly update runtime generation but fail to cache (the most likely error is failing to register an external address with the AOT cache). So, I'd prefer it if we could recheck the problem in JDK-8357398 and leave these changes as is. Perhaps @vnkozlov could help here? > > I closed this confidential bug and created open: https://bugs.openjdk.org/browse/JDK-8357593 > It is not fixed. I tried several times to find what is causing it without success. > > Let me run general testing for these changes. And then will try to reproduce JCK issue. If the issue persist we can comment C2 runtime stubs caching. Only they caused the issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28433#discussion_r2722968432 From jrose at openjdk.org Fri Jan 23 22:13:18 2026 From: jrose at openjdk.org (John R Rose) Date: Fri, 23 Jan 2026 22:13:18 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v13] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 20:08:58 GMT, Chen Liang wrote: >> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Wording update, thanks Jorn make/jdk/src/classes/build/tools/methodhandle/VarHandleGuardMethodGenerator.java line 130: > 128: > 129: // The void bypass is necessary if a (name + return-dropping type) combination has multiple call sites, each > 130: // having its own constant VarHandle. In that case, the AccessMode::adaptedMethodHandle adaption mechanism wrong word: s/adaption/adaptation/ https://grammarist.com/usage/adaption-adaptation/ (Wiktionary implies they are the same, but they apply to different areas of discourse. The grammarist article indicates that "adaptation" is the more correct word here. Also, the word "adaption" seems to be mostly obsolete.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2723023261 From missa at openjdk.org Fri Jan 23 23:04:43 2026 From: missa at openjdk.org (Mohamed Issa) Date: Fri, 23 Jan 2026 23:04:43 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v8] In-Reply-To: References: Message-ID: > Intel® 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 with a new target base due to a merge or a rebase. The pull request now contains 25 commits: - Merge branch 'master' into user/missa-prime/avx10_2 - Merge branch 'master' into user/missa-prime/avx10_2 - Change function names and extend IR encoding rules for CMove tests - Merge remote-tracking branch 'origin/master' into user/missa-prime/avx10_2 - Remove unnecessary CMOV blocks and adjust predicates involving APX and AVX10.2 - Remove extra jump instruction in signum floating point and unify three-way floating point comparison logic in x86.ad - Also update copyright year in IREncodingPrinter.java - Include apx_f in list of verified CPU features for IR encoding - Fix CMove IR tests to account for APX presence - Merge branch 'master' into user/missa-prime/avx10_2 - ... and 15 more: https://git.openjdk.org/jdk/compare/44b74e16...09d1e44d ------------- Changes: https://git.openjdk.org/jdk/pull/28337/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28337&range=07 Stats: 862 lines in 10 files changed: 663 ins; 105 del; 94 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 jrose at openjdk.org Fri Jan 23 23:05:30 2026 From: jrose at openjdk.org (John R Rose) Date: Fri, 23 Jan 2026 23:05:30 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v13] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 20:08:58 GMT, Chen Liang wrote: >> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Wording update, thanks Jorn src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2022: > 2020: // In a class file, the JVM creates one access descriptor for one (name, type) combination. > 2021: // Many call sites in one class can have the same (name, type) combination. > 2022: // In this case, they share the same access descriptor. I love it when, as part of maintenance, informative comments like these are added. Thanks! Please add a comment something like this as well: // Note: The integers type and mode are proxies for the AccessType and // AccessMode enumerations, and the access type simply summarizes something // about the shape of the access mode. The crucial type here, of the (name, type) // combination, is the MethodType that decorates the access shape with specific // strong types for the handle operation inputs and outputs. I think it was a small faux pas, some time ago, to choose the term `AccessType` instead of `AccessKind`, simply because the term "type" is already disastrously overloaded in our system. But that?s water under the bridge. Now we have one more "type" floating around in this neighborhood. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2723131985 From henryjen at openjdk.org Fri Jan 23 23:19:40 2026 From: henryjen at openjdk.org (Henry Jen) Date: Fri, 23 Jan 2026 23:19:40 GMT Subject: RFR: 8373924: Dangling pointer in ImageDecompressor::image_decompressor_close of imageDecompressor.cpp [v2] In-Reply-To: References: Message-ID: > I don't see image_decompressor_close actually referenced in the code base, as the decompressors are static and setup from image_decompressor_init(). > > This PR implements proper cleanup for decompressors to be defensive. Henry Jen 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 origin/master - 8373924: Dangling pointer in ImageDecompressor::image_decompressor_close of imageDecompressor.cpp:90 (ID: 34500) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29371/files - new: https://git.openjdk.org/jdk/pull/29371/files/a24ab6e1..d8bfef8d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29371&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29371&range=00-01 Stats: 36265 lines in 732 files changed: 20964 ins; 7321 del; 7980 mod Patch: https://git.openjdk.org/jdk/pull/29371.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29371/head:pull/29371 PR: https://git.openjdk.org/jdk/pull/29371 From henryjen at openjdk.org Fri Jan 23 23:24:50 2026 From: henryjen at openjdk.org (Henry Jen) Date: Fri, 23 Jan 2026 23:24:50 GMT Subject: RFR: 8373924: Dangling pointer in ImageDecompressor::image_decompressor_close of imageDecompressor.cpp [v3] In-Reply-To: References: Message-ID: > I don't see image_decompressor_close actually referenced in the code base, as the decompressors are static and setup from image_decompressor_init(). > > This PR implements proper cleanup for decompressors to be defensive. Henry Jen has updated the pull request incrementally with one additional commit since the last revision: remove dead code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29371/files - new: https://git.openjdk.org/jdk/pull/29371/files/d8bfef8d..bd6a2333 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29371&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29371&range=01-02 Stats: 13 lines in 2 files changed: 0 ins; 12 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29371.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29371/head:pull/29371 PR: https://git.openjdk.org/jdk/pull/29371 From jrose at openjdk.org Sat Jan 24 01:16:48 2026 From: jrose at openjdk.org (John R Rose) Date: Sat, 24 Jan 2026 01:16:48 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v13] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 20:08:58 GMT, Chen Liang wrote: >> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Wording update, thanks Jorn src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2014: > 2012: // Exists for the adaption mechanism of AccessDescriptor > 2013: // Each VH should report its explicitly (receiver, coordinates) and > 2014: // implicitly (static declaring class) used class to MethodHandle.isReachableFrom Perhaps add a comment: "Classes which define this abstract method should themselves be final or locally sealed, to make it possible to ensure that all relevant classes are taken into account." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2723365226 From jrose at openjdk.org Sat Jan 24 01:21:04 2026 From: jrose at openjdk.org (John R Rose) Date: Sat, 24 Jan 2026 01:21:04 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v13] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 20:08:58 GMT, Chen Liang wrote: >> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Wording update, thanks Jorn Good work. I?m assuming you will address my previous comments. src/java.base/share/classes/java/lang/invoke/SegmentVarHandle.java line 69: > 67: @Override > 68: boolean isReachableFrom(ClassLoader cl) { > 69: return true; Give a comment explaining why this is correct. Something like: The segment is neither an instance nor an array, so it is effectively common to all class loaders. Compare this to a class on the boot class loader, which also uses only types that are common reachable from all other class loaders. (Or something like that.) ------------- Marked as reviewed by jrose (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28585#pullrequestreview-3700343726 PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2723372435 From ysuenaga at openjdk.org Sat Jan 24 02:38:22 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 24 Jan 2026 02:38:22 GMT Subject: RFR: 8374926: EnableX86ECoreOpts was not enabled on some hybrid CPU [v5] In-Reply-To: References: Message-ID: > `EnableX86ECoreOpts` has been introduced in [JDK-8319429](https://bugs.openjdk.org/browse/JDK-8319429), however model numbers which should be enabled are hard-coded, so the flag would not be enabled by default on some models like Arrow Lake. > > I ran a [benchmark](https://github.com/YaSuenag/garakuta/tree/master/randminmax) to check for effectiveness of `-XX:+EnableX86ECoreOpts` with JDK 25.0.1 on Windows 11 25H2, I saw performance improvement a bit on Intel Core 5 Ultra 225U as following: > > Disabled (default) > > Benchmark Mode Cnt Score Error Units > RandMinVal.getMax thrpt 3 9707774.405 ? 27082629.015 ops/s > RandMinVal.getMin thrpt 3 7510319.839 ? 10923547.382 ops/s > > > Enabled > > Benchmark Mode Cnt Score Error Units > RandMinVal.getMax thrpt 3 10127809.127 ? 45404142.338 ops/s > RandMinVal.getMin thrpt 3 8467677.056 ? 1211998.200 ops/s > > > So I think it is better to enable this flag by default on all of hybrid CPUs. > > > To check what processor would be enabled E-core optimization, I made a [commit](https://github.com/openjdk/jdk/commit/f363ea1436b8100021fdac87b48ec43bcf6820af) to add comments for CPU models at first. I couldn't find out all of models (some models has not listed in SDM vol.4 so far), but most of models (excepts Sierra Forest) could be treated as hybrid CPU. Fortunately HotSpot identify hybrid flag from `CPUID`, so we can leverage it for this purpose. Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: - Add condition for CWF - Revert "Check E-Core with Leaf 1Ah" This reverts commit d77b43937911b33bf39175e45e3d9d97aa949617. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29149/files - new: https://git.openjdk.org/jdk/pull/29149/files/d77b4393..ffba7d8f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29149&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29149&range=03-04 Stats: 36 lines in 2 files changed: 2 ins; 30 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29149.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29149/head:pull/29149 PR: https://git.openjdk.org/jdk/pull/29149 From ysuenaga at openjdk.org Sat Jan 24 02:38:23 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 24 Jan 2026 02:38:23 GMT Subject: RFR: 8374926: EnableX86ECoreOpts was not enabled on some hybrid CPU [v3] In-Reply-To: References: <3wEINJR2IDU6Hi772So8ZqytuF775R-76c4ngkfWuqw=.aa820856-05d8-4fe6-a260-1c6b98bb2921@github.com> Message-ID: On Fri, 23 Jan 2026 13:54:39 GMT, Volodymyr Paprotski wrote: >> @vpaprotsk >>> I do think adding hybrid check might be a good idea, at least for now. I still need to find a way to detect 'is ecore only'. And if I could detect only the parts that actually need this emulation. (Though maybe leave both of those to me for another PR.. >> >> Do you mean this PR should add to check hybrid flag only, without checking leaf 1Ah? >> If so, I will revert the merge for leaf 1Ah, and will add model ID for CWF. > >> Do you mean this PR should add to check hybrid flag only, without checking leaf 1Ah? If so, I will revert the merge for leaf 1Ah, and will add model ID for CWF. > > I would prefer that, at least for now/this PR.. keep the existing model checks and add `supports_hybrid()`. (The atom core might be a good idea, not sure. Would need some spelunking) @vpaprotsk I updated this PR to check hybrid flag and model ID for SRF, CWF. Could you review? It works on Core Ultra 5 225U at least. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29149#issuecomment-3793556685 From dlong at openjdk.org Sat Jan 24 02:46:54 2026 From: dlong at openjdk.org (Dean Long) Date: Sat, 24 Jan 2026 02:46:54 GMT Subject: RFR: 8358957: [ubsan]: The assert in layout_helper_boolean_diffbit() in klass.hpp needs UB to fail [v8] In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 09:18:48 GMT, Afshin Zafari wrote: >> Avoid using loop and UB in left-shift operation as suggested by Kim's comment in the JBS-issue. >> >> Tests: >> mach5 tiers 1-5 {macosx-aarch64, linux-x64, windows-x64} x {debug, product} > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > disabling the msvc warning remoeved Marked as reviewed by dlong (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27288#pullrequestreview-3700455150 From azafari at openjdk.org Sat Jan 24 02:46:54 2026 From: azafari at openjdk.org (Afshin Zafari) Date: Sat, 24 Jan 2026 02:46:54 GMT Subject: RFR: 8358957: [ubsan]: The assert in layout_helper_boolean_diffbit() in klass.hpp needs UB to fail [v8] In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 09:18:48 GMT, Afshin Zafari wrote: >> Avoid using loop and UB in left-shift operation as suggested by Kim's comment in the JBS-issue. >> >> Tests: >> mach5 tiers 1-5 {macosx-aarch64, linux-x64, windows-x64} x {debug, product} > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > disabling the msvc warning remoeved Dear reviewers @dean-long and @jdksjolen, This PR is still waiting for your final review and comments. Please (re)review it and let it be moved forward. TIA. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27288#issuecomment-3789742737 From alanb at openjdk.org Sat Jan 24 07:18:50 2026 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 24 Jan 2026 07:18:50 GMT Subject: RFR: 8373924: Dangling pointer in ImageDecompressor::image_decompressor_close of imageDecompressor.cpp [v3] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 23:24:50 GMT, Henry Jen wrote: >> I don't see image_decompressor_close actually referenced in the code base, as the decompressors are static and setup from image_decompressor_init(). >> >> This PR implements proper cleanup for decompressors to be defensive. > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > remove dead code Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29371#pullrequestreview-3700924382 From lmesnik at openjdk.org Sat Jan 24 08:44:29 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sat, 24 Jan 2026 08:44:29 GMT Subject: RFR: 8214294: Post ResourceExhausted events generated by CompilerThread on the ServiceThread Message-ID: The [JDK-8213834](https://bugs.openjdk.org/browse/JDK-8213834) JVMTI ResourceExhausted should not be posted in CompilerThread disables posting ResourceExhausted events on CompilerThread because it can't post event. The ResourceExhausted is used by agents to identify VM issues (and usually kill instance). I think it makes sense to generate this event on the ServiceThread like other deferred events (methods loading/unloading). So tool like https://github.com/Netflix-Skunkworks/jvmquake can properly kill jvm if resource exhausting happens on any thread. Please note, that ResourceExhausted is NOT generated when CodeCache full. It might be makes sense to add it since performance degradation going to be critical and makes sense treat CodeCache as a resource. It is hard generate OOME in the CompilerThread to test this fix. The fix was tested by patch that generated event for codecache exchausting and new test. https://github.com/openjdk/jdk/compare/master...lmesnik:jdk:codecache-full?expand=1 ------------- Commit messages: - 8214294: Post ResourceExhausted events generated by CompilerThread on the ServiceThread Changes: https://git.openjdk.org/jdk/pull/29397/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29397&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8214294 Stats: 47 lines in 3 files changed: 37 ins; 5 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/29397.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29397/head:pull/29397 PR: https://git.openjdk.org/jdk/pull/29397 From alanb at openjdk.org Sat Jan 24 08:54:58 2026 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 24 Jan 2026 08:54:58 GMT Subject: RFR: 8372652: Re-enable LocalRandom clinit after monitor pinning improvements In-Reply-To: <0BI-aekYlNzNe8szo_NjO14MRbrV_NjjQN6IYB_AT40=.5c548a70-d6fa-4eb9-b7cc-3c44f84ea833@github.com> References: <0BI-aekYlNzNe8szo_NjO14MRbrV_NjjQN6IYB_AT40=.5c548a70-d6fa-4eb9-b7cc-3c44f84ea833@github.com> Message-ID: <3OxdOpu-E3kHqQDXvjrU_LIvK9lB7lIkv2MEuvU2bPk=.58600e4c-20e4-4dda-ba97-a2e0b9ed3712@github.com> On Mon, 1 Dec 2025 22:38:29 GMT, Leonid Mesnik wrote: >>> Unfortunately, there are might be failure of execution `vmTestbase/`with `JTREG_TEST_THREAD_FACTORY=Virtual`. So it enough ensure the your fix doesn't create new failures and timeouts >> >> I am trying to parse this :) So, if `make test TEST=vmTestbase/ JTREG=TEST_THREAD_FACTORY=Virtual` passes, we are good to go, correct? > >> > Unfortunately, there are might be failure of execution `vmTestbase/`with `JTREG_TEST_THREAD_FACTORY=Virtual`. So it enough ensure the your fix doesn't create new failures and timeouts >> >> I am trying to parse this :) So, if `make test TEST=vmTestbase/ JTREG=TEST_THREAD_FACTORY=Virtual` passes, we are good to go, correct? > > Sure. > I meant that we don't run whole vmTestbase with TEST_THREAD_FACTORY=Virtual, so I am unsure if there are some failures exist now. > @lmesnik @AlanBateman A gentle reminder for the review. I don't have anything to add. As Patricio's said in one of the messages, the "TODO" comment may not have been accurate. If the tests runs are good then it should be okay. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28547#issuecomment-3794251381 From duke at openjdk.org Sat Jan 24 10:34:56 2026 From: duke at openjdk.org (Vishal Chand) Date: Sat, 24 Jan 2026 10:34:56 GMT Subject: RFR: 8372652: Re-enable LocalRandom clinit after monitor pinning improvements In-Reply-To: <3OxdOpu-E3kHqQDXvjrU_LIvK9lB7lIkv2MEuvU2bPk=.58600e4c-20e4-4dda-ba97-a2e0b9ed3712@github.com> References: <0BI-aekYlNzNe8szo_NjO14MRbrV_NjjQN6IYB_AT40=.5c548a70-d6fa-4eb9-b7cc-3c44f84ea833@github.com> <3OxdOpu-E3kHqQDXvjrU_LIvK9lB7lIkv2MEuvU2bPk=.58600e4c-20e4-4dda-ba97-a2e0b9ed3712@github.com> Message-ID: On Sat, 24 Jan 2026 08:52:08 GMT, Alan Bateman wrote: >>> > Unfortunately, there are might be failure of execution `vmTestbase/`with `JTREG_TEST_THREAD_FACTORY=Virtual`. So it enough ensure the your fix doesn't create new failures and timeouts >>> >>> I am trying to parse this :) So, if `make test TEST=vmTestbase/ JTREG=TEST_THREAD_FACTORY=Virtual` passes, we are good to go, correct? >> >> Sure. >> I meant that we don't run whole vmTestbase with TEST_THREAD_FACTORY=Virtual, so I am unsure if there are some failures exist now. > >> @lmesnik @AlanBateman A gentle reminder for the review. > > I don't have anything to add. As Patricio's said in one of the messages, the "TODO" comment may not have been accurate. If the tests runs are good then it should be okay. @AlanBateman I confirmed that the test runs are fine [in this comment](https://github.com/openjdk/jdk/pull/28547#issuecomment-3675825598). I think Aleksey is waiting for your approval. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28547#issuecomment-3794430680 From eirbjo at openjdk.org Sat Jan 24 20:20:50 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Sat, 24 Jan 2026 20:20:50 GMT Subject: RFR: 8373924: Dangling pointer in ImageDecompressor::image_decompressor_close of imageDecompressor.cpp [v3] In-Reply-To: References: <2Eyztyttm_T8FTk0QITmfzXbVsz9yNpZRNptLnus6fs=.88f55f3e-1014-4dbb-8041-d174a3475e26@github.com> Message-ID: On Fri, 23 Jan 2026 18:56:55 GMT, Henry Jen wrote: >> src/java.base/share/native/libjimage/imageDecompressor.cpp line 96: >> >>> 94: _decompressors = NULL; >>> 95: _decompressors_num = 0; >>> 96: } >> >> What would you think about removing it? Its dead code and not tested. > > We can do that too since it's by design to have same lifespan as the process. I'll run some more tests to confirm removing is safe. > > The close can be added when the requirements change. Consider updating the issue / PR title to reflect the removal instead of fixing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29371#discussion_r2724573245 From kbarrett at openjdk.org Sat Jan 24 23:17:51 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 24 Jan 2026 23:17:51 GMT Subject: RFR: 8376195: Convert ThreadLocalAllocBuffer to use Atomic In-Reply-To: <1TAUwWsHEcAIzMF35Q3v9xsDhsNV6ZhGZDCO9fh93KI=.f14438d0-8874-4259-b33d-83ad8b9bf2b3@github.com> References: <1TAUwWsHEcAIzMF35Q3v9xsDhsNV6ZhGZDCO9fh93KI=.f14438d0-8874-4259-b33d-83ad8b9bf2b3@github.com> Message-ID: On Fri, 23 Jan 2026 12:35:03 GMT, Thomas Schatzl wrote: > Hi all, > > please review the change to use `Atomic` in `ThreadLocalAllocBuffer`. > > Testing: gha > > Thanks, > Thomas While looking at ThreadLocalAllocBuffer I noticed this comment that seems stale/dead: https://github.com/openjdk/jdk/blob/a40dbce495db9959624b72ff619e2e7ae7f7fb8b/src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp#L37-L39 ------------- PR Comment: https://git.openjdk.org/jdk/pull/29386#issuecomment-3795685300 From kbarrett at openjdk.org Sat Jan 24 23:34:51 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 24 Jan 2026 23:34:51 GMT Subject: RFR: 8376195: Convert ThreadLocalAllocBuffer to use Atomic In-Reply-To: <1TAUwWsHEcAIzMF35Q3v9xsDhsNV6ZhGZDCO9fh93KI=.f14438d0-8874-4259-b33d-83ad8b9bf2b3@github.com> References: <1TAUwWsHEcAIzMF35Q3v9xsDhsNV6ZhGZDCO9fh93KI=.f14438d0-8874-4259-b33d-83ad8b9bf2b3@github.com> Message-ID: On Fri, 23 Jan 2026 12:35:03 GMT, Thomas Schatzl wrote: > Hi all, > > please review the change to use `Atomic` in `ThreadLocalAllocBuffer`. > > Testing: gha > > Thanks, > Thomas src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp line 51: > 49: friend class JVMCIVMStructs; > 50: private: > 51: Atomic _start; // address of TLAB [pre-existing] I don't understand why `_start` is atomic but other members set by `initialize` are not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29386#discussion_r2724702445 From jbhateja at openjdk.org Sun Jan 25 07:05:40 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Sun, 25 Jan 2026 07:05:40 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v15] In-Reply-To: References: Message-ID: > 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. > > image > > 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 incrementally with one additional commit since the last revision: Refactoring and cleanups ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28002/files - new: https://git.openjdk.org/jdk/pull/28002/files/72d15568..0891bc70 Webrevs: - full: Webrev is not available because diff is too large - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=13-14 Stats: 822 lines in 48 files changed: 14 ins; 306 del; 502 mod Patch: https://git.openjdk.org/jdk/pull/28002.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002 PR: https://git.openjdk.org/jdk/pull/28002 From jbhateja at openjdk.org Sun Jan 25 08:00:30 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Sun, 25 Jan 2026 08:00:30 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v16] In-Reply-To: References: Message-ID: > 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. > > image > > 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 incrementally with one additional commit since the last revision: Refactoring vectorIntrinsics ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28002/files - new: https://git.openjdk.org/jdk/pull/28002/files/0891bc70..aeba2e68 Webrevs: - full: Webrev is not available because diff is too large - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=14-15 Stats: 150 lines in 1 file changed: 74 ins; 14 del; 62 mod Patch: https://git.openjdk.org/jdk/pull/28002.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002 PR: https://git.openjdk.org/jdk/pull/28002 From kbarrett at openjdk.org Sun Jan 25 15:50:59 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 25 Jan 2026 15:50:59 GMT Subject: RFR: 8347396: Efficient TypeFunc creations [v5] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 07:33:39 GMT, Harshit470250 wrote: >> 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 one additional commit since the last revision: > > move include shenandoah to bottom src/hotspot/share/opto/runtime.hpp line 235: > 233: static void monitor_notify_C(oopDesc* obj, JavaThread* current); > 234: static void monitor_notifyAll_C(oopDesc* obj, JavaThread* current); > 235: static const TypeFunc* _clone_type_Type; hotspot generally avoids public data members other than in simple data structs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27279#discussion_r2725645621 From erfang at openjdk.org Mon Jan 26 02:02:01 2026 From: erfang at openjdk.org (Eric Fang) Date: Mon, 26 Jan 2026 02:02:01 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v12] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 06:34:00 GMT, Jatin Bhateja wrote: >> Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction. >> It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails. >> >> Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java). >> >> Vector API jtreg tests pass at AVX level 2, remaining validation in progress. >> >> Performance numbers: >> >> >> System : 13th Gen Intel(R) Core(TM) i3-1315U >> >> Baseline: >> Benchmark (size) Mode Cnt Score Error Units >> VectorSliceBenchmark.byteVectorSliceWithConstantIndex1 1024 thrpt 2 9444.444 ops/ms >> VectorSliceBenchmark.byteVectorSliceWithConstantIndex2 1024 thrpt 2 10009.319 ops/ms >> VectorSliceBenchmark.byteVectorSliceWithVariableIndex 1024 thrpt 2 9081.926 ops/ms >> VectorSliceBenchmark.intVectorSliceWithConstantIndex1 1024 thrpt 2 6085.825 ops/ms >> VectorSliceBenchmark.intVectorSliceWithConstantIndex2 1024 thrpt 2 6505.378 ops/ms >> VectorSliceBenchmark.intVectorSliceWithVariableIndex 1024 thrpt 2 6204.489 ops/ms >> VectorSliceBenchmark.longVectorSliceWithConstantIndex1 1024 thrpt 2 1651.334 ops/ms >> VectorSliceBenchmark.longVectorSliceWithConstantIndex2 1024 thrpt 2 1642.784 ops/ms >> VectorSliceBenchmark.longVectorSliceWithVariableIndex 1024 thrpt 2 1474.808 ops/ms >> VectorSliceBenchmark.shortVectorSliceWithConstantIndex1 1024 thrpt 2 10399.394 ops/ms >> VectorSliceBenchmark.shortVectorSliceWithConstantIndex2 1024 thrpt 2 10502.894 ops/ms >> VectorSliceB... > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Review comments resolutions Marked as reviewed by erfang (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/24104#pullrequestreview-3704448350 From xgong at openjdk.org Mon Jan 26 02:37:00 2026 From: xgong at openjdk.org (Xiaohong Gong) Date: Mon, 26 Jan 2026 02:37:00 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v12] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 06:34:00 GMT, Jatin Bhateja wrote: >> Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction. >> It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails. >> >> Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java). >> >> Vector API jtreg tests pass at AVX level 2, remaining validation in progress. >> >> Performance numbers: >> >> >> System : 13th Gen Intel(R) Core(TM) i3-1315U >> >> Baseline: >> Benchmark (size) Mode Cnt Score Error Units >> VectorSliceBenchmark.byteVectorSliceWithConstantIndex1 1024 thrpt 2 9444.444 ops/ms >> VectorSliceBenchmark.byteVectorSliceWithConstantIndex2 1024 thrpt 2 10009.319 ops/ms >> VectorSliceBenchmark.byteVectorSliceWithVariableIndex 1024 thrpt 2 9081.926 ops/ms >> VectorSliceBenchmark.intVectorSliceWithConstantIndex1 1024 thrpt 2 6085.825 ops/ms >> VectorSliceBenchmark.intVectorSliceWithConstantIndex2 1024 thrpt 2 6505.378 ops/ms >> VectorSliceBenchmark.intVectorSliceWithVariableIndex 1024 thrpt 2 6204.489 ops/ms >> VectorSliceBenchmark.longVectorSliceWithConstantIndex1 1024 thrpt 2 1651.334 ops/ms >> VectorSliceBenchmark.longVectorSliceWithConstantIndex2 1024 thrpt 2 1642.784 ops/ms >> VectorSliceBenchmark.longVectorSliceWithVariableIndex 1024 thrpt 2 1474.808 ops/ms >> VectorSliceBenchmark.shortVectorSliceWithConstantIndex1 1024 thrpt 2 10399.394 ops/ms >> VectorSliceBenchmark.shortVectorSliceWithConstantIndex2 1024 thrpt 2 10502.894 ops/ms >> VectorSliceB... > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Review comments resolutions LGTM! Thanks for your updating! ------------- Marked as reviewed by xgong (Committer). PR Review: https://git.openjdk.org/jdk/pull/24104#pullrequestreview-3704485459 From duke at openjdk.org Mon Jan 26 03:52:16 2026 From: duke at openjdk.org (Kent Dong) Date: Mon, 26 Jan 2026 03:52:16 GMT Subject: RFR: 8364343: Virtual Thread transition management needs to be independent of JVM TI [v13] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 15:27:06 GMT, Patricio Chilano Mateo wrote: >> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes. >> >> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes: >> >> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. >> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version. >> >> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`. >> >> - The code was previously structured in t... > > Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: > > - Merge branch 'master' into JDK-8364343 > - simplify assert > - Merge branch 'master' into JDK-8364343 > - rebind in end_transition only for mount case > - Fix comment in inline_native_vthread_start_transition > - missing to initialize _is_disabler_at_start > - More changes from Coleen's review > - Drop VTMS from names > - keep preexisting rebind order for mount > - Remove INCLUDE_JVMTI macro > - ... and 5 more: https://git.openjdk.org/jdk/compare/829b8581...444ac0ce Hi guys, would this patch be backported to JDK 25? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28361#issuecomment-3797793059 From bperez at openjdk.org Mon Jan 26 04:25:44 2026 From: bperez at openjdk.org (Ben Perez) Date: Mon, 26 Jan 2026 04:25:44 GMT Subject: RFR: 8355216: Accelerate P-256 arithmetic on aarch64 [v4] In-Reply-To: References: Message-ID: <1pWEujfd2cR7cqahubA6lbBgtTfnX00oGLzR9tr1AOw=.9c3fa260-6c98-480d-aec8-82ebf8c63129@github.com> > An aarch64 implementation of the `MontgomeryIntegerPolynomial256.mult()` method Ben Perez has updated the pull request incrementally with one additional commit since the last revision: Added conditionalAssign() intrinsic, changed mult intrinsic to use hybrid neon/gpr approach ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27946/files - new: https://git.openjdk.org/jdk/pull/27946/files/ee2f01ac..3cadf6cf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27946&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27946&range=02-03 Stats: 948 lines in 1 file changed: 614 ins; 35 del; 299 mod Patch: https://git.openjdk.org/jdk/pull/27946.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27946/head:pull/27946 PR: https://git.openjdk.org/jdk/pull/27946 From aph at openjdk.org Mon Jan 26 10:46:33 2026 From: aph at openjdk.org (Andrew Haley) Date: Mon, 26 Jan 2026 10:46:33 GMT Subject: RFR: 8374513: AArch64: Improve receiver type profiling reliability [v2] In-Reply-To: References: Message-ID: <2l8VXN7i-QhZsGo2PfpXnryt4URDRqB0ooGJWghgOVE=.53addc43-a5b6-4d9c-841d-c6edce8a4c8b@github.com> On Thu, 22 Jan 2026 00:56:42 GMT, Chad Rakoczy wrote: >> [JDK-8374513](https://bugs.openjdk.org/browse/JDK-8374513) is the AArch64 port of [JDK-8357258](https://bugs.openjdk.org/browse/JDK-8357258). See the bug report for more detailed information. >> >> This PR executes the plan outlined in the bug: >> - Common the receiver type profiling code in interpreter and C1 >> - Rewrite receiver type profiling code to only do atomic receiver slot installations >> - 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. >> >> Functional Testing: Linux AArch64 fastdebug Tier1-4 >> >> Performance Testing (to show there is no performance regression): >> >> # Baseline >> Benchmark (randomized) Mode Cnt Score Error Units >> InterfaceCalls.test1stInt2Types false avgt 12 1.940 ? 0.002 ns/op >> InterfaceCalls.test1stInt2Types true avgt 12 7.714 ? 0.011 ns/op >> InterfaceCalls.test1stInt3Types false avgt 12 6.747 ? 0.066 ns/op >> InterfaceCalls.test1stInt3Types true avgt 12 18.733 ? 0.175 ns/op >> InterfaceCalls.test1stInt5Types false avgt 12 6.690 ? 0.083 ns/op >> InterfaceCalls.test1stInt5Types true avgt 12 21.299 ? 0.016 ns/op >> InterfaceCalls.test2ndInt2Types false avgt 12 1.997 ? 0.004 ns/op >> InterfaceCalls.test2ndInt2Types true avgt 12 8.027 ? 0.016 ns/op >> InterfaceCalls.test2ndInt3Types false avgt 12 7.915 ? 0.114 ns/op >> InterfaceCalls.test2ndInt3Types true avgt 12 16.988 ? 0.065 ns/op >> InterfaceCalls.test2ndInt5Types false avgt 12 9.422 ? 0.017 ns/op >> InterfaceCalls.test2ndInt5Types true avgt 12 22.736 ? 0.022 ns/op >> InterfaceCalls.testIfaceCall false avgt 12 5.860 ? 0.046 ns/op >> InterfaceCalls.testIfaceCall true avgt 12 5.794 ? 0.026 ns/op >> InterfaceCalls.testIfaceExtCall false avgt 12 6.310 ? 0.067 ns/op >> InterfaceCalls.testIfaceExtCall true avgt 12 6.239 ? 0.017 ns/op >> InterfaceCalls.testMonomorphic false avgt 12 1.146 ? 0.034 ns/op >> InterfaceCalls.testMonomorphic true avgt 12 1.131 ? 0.012 ns/op >> >> # With PR >> Benchmark (randomized) Mode Cnt Score Error Units >> InterfaceCalls.test1stInt2Type... > > Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision: > > Use increment macro OK. One drive-by comment. I don't think that we need a CAS here, a StoreLoad after the store would work as well. But I recommend that we use CAS, because a fence wouldn't be any better. ------------- Marked as reviewed by aph (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29283#pullrequestreview-3705499946 From tschatzl at openjdk.org Mon Jan 26 11:00:10 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 26 Jan 2026 11:00:10 GMT Subject: RFR: 8376195: Convert ThreadLocalAllocBuffer to use Atomic [v2] In-Reply-To: <1TAUwWsHEcAIzMF35Q3v9xsDhsNV6ZhGZDCO9fh93KI=.f14438d0-8874-4259-b33d-83ad8b9bf2b3@github.com> References: <1TAUwWsHEcAIzMF35Q3v9xsDhsNV6ZhGZDCO9fh93KI=.f14438d0-8874-4259-b33d-83ad8b9bf2b3@github.com> Message-ID: <2rAYqg4JIvntyUtk-qDU1oywjCA372LK1JyAZYQxTss=.12c4303f-cbcf-464e-83fd-edde06c83f30@github.com> > Hi all, > > please review the change to use `Atomic` in `ThreadLocalAllocBuffer`. > > Testing: gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision: - * kbarrett review - * kbarrett review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29386/files - new: https://git.openjdk.org/jdk/pull/29386/files/97f40d99..4fc931e7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29386&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29386&range=00-01 Stats: 28 lines in 4 files changed: 2 ins; 5 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/29386.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29386/head:pull/29386 PR: https://git.openjdk.org/jdk/pull/29386 From shade at openjdk.org Mon Jan 26 11:17:58 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 26 Jan 2026 11:17:58 GMT Subject: RFR: 8375359: Improve GC serviceability init staging In-Reply-To: References: Message-ID: <-e2HVxdrJneuh_T8zSca2WbbmijWnQ_iM2xaCzKnuuw=.6a6f3900-0e3b-4ecc-a268-a38ad655f56c@github.com> On Thu, 15 Jan 2026 16:43:40 GMT, Aleksey Shipilev wrote: > As per docs, `CollectedHeap::post_initialize` is for doing inits that should be done before general allocations are accepted. Currently, serviceability layer initialized there via the call to `CollectedHeap::initialize_serviceability`. This bug shows that after `CollectedHeap::post_initialize` returns, the rest of the serviceability layer had not been fully initialized yet. But GC code might assume general allocation path works at that point! So if that allocation path reports anything to the serviceability layer, it could encounter not yet fully initialized serviceability support and fail. > > This readily manifests in improved Epsilon stress test. Improved test fails pretty consistently on my machines, and serves as a good regression test. > > So the fix is to peel off serviceability initialization from post-init stage, and do it separately, before going (and finishing) `post_initialize`. Conveniently, we are nearly there, and "just" need to touch up a few things in `universe_post_init()`. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `gc/epsilon/TestInitAllocs.java`, 10x > - [x] Linux x86_64 server fastdebug, `hotspot_gc` Still looking for Reviewers. @stefank, @dholmes-ora, maybe? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29254#issuecomment-3799054975 From shade at openjdk.org Mon Jan 26 11:18:00 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 26 Jan 2026 11:18:00 GMT Subject: RFR: 8373266: Strengthen constant CardTable base accesses [v5] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 16:47:43 GMT, Aleksey Shipilev 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 > > Aleksey Shipilev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > Some polishing Still looking for a second Reviewer, please? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28703#issuecomment-3799053446 From shade at openjdk.org Mon Jan 26 11:42:27 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 26 Jan 2026 11:42:27 GMT Subject: RFR: 8374513: AArch64: Improve receiver type profiling reliability [v2] In-Reply-To: <2l8VXN7i-QhZsGo2PfpXnryt4URDRqB0ooGJWghgOVE=.53addc43-a5b6-4d9c-841d-c6edce8a4c8b@github.com> References: <2l8VXN7i-QhZsGo2PfpXnryt4URDRqB0ooGJWghgOVE=.53addc43-a5b6-4d9c-841d-c6edce8a4c8b@github.com> Message-ID: On Mon, 26 Jan 2026 10:44:04 GMT, Andrew Haley wrote: > I don't think that we need a CAS here, a StoreLoad after the store would work as well. Er, what, why? The whole point is to have atomic `nullptr -> actual-type` transition per receiver slot, so that you claim the slot only once. You cannot achieve this without CASes :) Are you seeing something I am not seeing here? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29283#issuecomment-3799139499 From adinn at openjdk.org Mon Jan 26 12:03:56 2026 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 26 Jan 2026 12:03:56 GMT Subject: RFR: 8372617: Save and restore stubgen stubs when using an AOT code cache [v4] In-Reply-To: References: <2UOkLPAYC5PUUl51bDgkHzm9QK3_1KdUENhFkUZvKN8=.6c3b86e7-9e2e-4902-ba24-ed9858b33bec@github.com> Message-ID: On Fri, 23 Jan 2026 21:51:16 GMT, Vladimir Kozlov wrote: >> I closed this confidential bug and created open: https://bugs.openjdk.org/browse/JDK-8357593 >> It is not fixed. I tried several times to find what is causing it without success. >> >> Let me run general testing for these changes. And then will try to reproduce JCK issue. > > If the issue persist we can comment C2 runtime stubs caching. Only they caused the issue. Ok, that's a good (more than) halfway solution if needed. Let's see first whether the problem is still present or, if it is, whether we can now pin it down. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28433#discussion_r2727337477 From aph at openjdk.org Mon Jan 26 12:10:49 2026 From: aph at openjdk.org (Andrew Haley) Date: Mon, 26 Jan 2026 12:10:49 GMT Subject: RFR: 8374513: AArch64: Improve receiver type profiling reliability [v2] In-Reply-To: References: <2l8VXN7i-QhZsGo2PfpXnryt4URDRqB0ooGJWghgOVE=.53addc43-a5b6-4d9c-841d-c6edce8a4c8b@github.com> Message-ID: On Mon, 26 Jan 2026 11:39:33 GMT, Aleksey Shipilev wrote: > > I don't think that we need a CAS here, a StoreLoad after the store would work as well. > > Er, what, why? The whole point is to have atomic `nullptr -> actual-type` transition per receiver slot, so that you claim the slot only once. You cannot achieve this without CASes :) Are you seeing something I am not seeing here? Er, no. I was somewhat over simplifying things. As you were. :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/29283#issuecomment-3799246588 From jbhateja at openjdk.org Mon Jan 26 12:17:02 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 26 Jan 2026 12:17:02 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v17] In-Reply-To: References: Message-ID: > 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. > > image > > 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 34 commits: - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 - Clanups - Refactoring vectorIntrinsics - Refactoring and cleanups - Refactoring and cleanups - Review comments resolutions - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 - Adding testpoint for JDK-8373574 - Review comments resolutions - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 - ... and 24 more: https://git.openjdk.org/jdk/compare/0f1b96a5...ce5768fa ------------- Changes: https://git.openjdk.org/jdk/pull/28002/files Webrev: Webrev is not available because diff is too large Stats: 519675 lines in 224 files changed: 284942 ins; 233000 del; 1733 mod Patch: https://git.openjdk.org/jdk/pull/28002.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002 PR: https://git.openjdk.org/jdk/pull/28002 From stefank at openjdk.org Mon Jan 26 12:25:46 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 26 Jan 2026 12:25:46 GMT Subject: RFR: 8375359: Improve GC serviceability init staging In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 16:43:40 GMT, Aleksey Shipilev wrote: > As per docs, `CollectedHeap::post_initialize` is for doing inits that should be done before general allocations are accepted. Currently, serviceability layer initialized there via the call to `CollectedHeap::initialize_serviceability`. This bug shows that after `CollectedHeap::post_initialize` returns, the rest of the serviceability layer had not been fully initialized yet. But GC code might assume general allocation path works at that point! So if that allocation path reports anything to the serviceability layer, it could encounter not yet fully initialized serviceability support and fail. > > This readily manifests in improved Epsilon stress test. Improved test fails pretty consistently on my machines, and serves as a good regression test. > > So the fix is to peel off serviceability initialization from post-init stage, and do it separately, before going (and finishing) `post_initialize`. Conveniently, we are nearly there, and "just" need to touch up a few things in `universe_post_init()`. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `gc/epsilon/TestInitAllocs.java`, 10x > - [x] Linux x86_64 server fastdebug, `hotspot_gc` Is there a way to restructure the code so that we don't get more locations in the VM initialization code (external to the GC code) that call various CollectedHeap initialization functions? I haven't fully looked at this in all details, but could the various `initialize_serviceability` function be called from within the `CollectedHeap::initialize` function instead? ------------- PR Review: https://git.openjdk.org/jdk/pull/29254#pullrequestreview-3705800541 From shade at openjdk.org Mon Jan 26 13:00:21 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 26 Jan 2026 13:00:21 GMT Subject: RFR: 8375359: Improve GC serviceability init staging In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 12:23:25 GMT, Stefan Karlsson wrote: > Is there a way to restructure the code so that we don't get more locations in the VM initialization code (external to the GC code) that call various CollectedHeap initialization functions? I have not looked deeply, but honestly, I doubt it would not introduce more bootstrapping issues. As it stands now, we are changing the init sequence only a little bit, and already when the rest of the system is initialized. Moving serviceability inits way up to `CollectedHeap::initialize` moves it before a lot of other inits, so there is IMO a risk there. Bootstraping sequence is fiddly and always comes with surprises. For example, AFAICS, after `CollectedHeap::initialize` completes, we have not yet initialized Metaspace including its perf counters, String table is not yet wired up, etc. It is plausible serviceability code would need some of that, maybe is some future changes. So I'd prefer to keep the patch as it is. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29254#issuecomment-3799475406 From stefank at openjdk.org Mon Jan 26 13:36:10 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 26 Jan 2026 13:36:10 GMT Subject: RFR: 8375359: Improve GC serviceability init staging In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 16:43:40 GMT, Aleksey Shipilev wrote: > As per docs, `CollectedHeap::post_initialize` is for doing inits that should be done before general allocations are accepted. Currently, serviceability layer initialized there via the call to `CollectedHeap::initialize_serviceability`. This bug shows that after `CollectedHeap::post_initialize` returns, the rest of the serviceability layer had not been fully initialized yet. But GC code might assume general allocation path works at that point! So if that allocation path reports anything to the serviceability layer, it could encounter not yet fully initialized serviceability support and fail. > > This readily manifests in improved Epsilon stress test. Improved test fails pretty consistently on my machines, and serves as a good regression test. > > So the fix is to peel off serviceability initialization from post-init stage, and do it separately, before going (and finishing) `post_initialize`. Conveniently, we are nearly there, and "just" need to touch up a few things in `universe_post_init()`. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `gc/epsilon/TestInitAllocs.java`, 10x > - [x] Linux x86_64 server fastdebug, `hotspot_gc` Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29254#pullrequestreview-3706055591 From stefank at openjdk.org Mon Jan 26 13:36:12 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 26 Jan 2026 13:36:12 GMT Subject: RFR: 8375359: Improve GC serviceability init staging In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 12:55:50 GMT, Aleksey Shipilev wrote: > > Is there a way to restructure the code so that we don't get more locations in the VM initialization code (external to the GC code) that call various CollectedHeap initialization functions? > > I have not looked deeply, but honestly, I doubt it would not introduce more bootstrapping issues. As it stands now, we are changing the init sequence only a little bit, and already when the rest of the system is initialized. Moving serviceability inits way up to `CollectedHeap::initialize` moves it before a lot of other inits, so there is IMO a risk there. Bootstraping sequence is fiddly and always comes with surprises. > > For example, AFAICS, after `CollectedHeap::initialize` completes, we have not yet initialized Metaspace including its perf counters, String table is not yet wired up, etc. It is plausible serviceability code would need some of that, maybe is some future changes. > > So I'd prefer to keep the patch as it is. You are right that the PerfCounters are problematic. The pools and memory mangers could probably be moved though. Oh well, I'll create an RFE and deal with that after you have integrated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29254#issuecomment-3799630787 From adinn at openjdk.org Mon Jan 26 13:42:28 2026 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 26 Jan 2026 13:42:28 GMT Subject: RFR: 8355216: Accelerate P-256 arithmetic on aarch64 [v4] In-Reply-To: <1pWEujfd2cR7cqahubA6lbBgtTfnX00oGLzR9tr1AOw=.9c3fa260-6c98-480d-aec8-82ebf8c63129@github.com> References: <1pWEujfd2cR7cqahubA6lbBgtTfnX00oGLzR9tr1AOw=.9c3fa260-6c98-480d-aec8-82ebf8c63129@github.com> Message-ID: On Mon, 26 Jan 2026 04:25:44 GMT, Ben Perez wrote: >> An aarch64 implementation of the `MontgomeryIntegerPolynomial256.mult()` method and `IntegerPolynomial.conditionalAssign()`. Since 64-bit multiplication is not supported on Neon and manually performing this operation with 32-bit limbs is slower than with GPRs, a hybrid neon/gpr approach is used. Neon instructions are used to compute intermediate values used in the last two iterations of the main "loop", while the GPRs compute the first few iterations. At the method level this improves performance by ~9% and at the API level roughly 5%. >> >> Performance no intrinsic: >> >> Benchmark (isMontBench) Mode Cnt Score Error Units >> PolynomialP256Bench.benchMultiply true thrpt 8 2427.562 ? 24.923 ops/s >> PolynomialP256Bench.benchMultiply false thrpt 8 1757.495 ? 41.805 ops/s >> PolynomialP256Bench.benchSquare true thrpt 8 2435.202 ? 20.822 ops/s >> PolynomialP256Bench.benchSquare false thrpt 8 2420.390 ? 33.594 ops/s >> >> Benchmark (algorithm) (dataSize) (keyLength) (provider) Mode Cnt Score Error Units >> SignatureBench.ECDSA.sign SHA256withECDSA 1024 256 thrpt 40 8439.881 ? 29.838 ops/s >> SignatureBench.ECDSA.sign SHA256withECDSA 16384 256 thrpt 40 7990.614 ? 30.998 ops/s >> SignatureBench.ECDSA.verify SHA256withECDSA 1024 256 thrpt 40 2677.737 ? 8.400 ops/s >> SignatureBench.ECDSA.verify SHA256withECDSA 16384 256 thrpt 40 2619.297 ? 9.737 ops/s >> >> Benchmark (algorithm) (keyLength) (kpgAlgorithm) (provider) Mode Cnt Score Error Units >> KeyAgreementBench.EC.generateSecret ECDH 256 EC thrpt 40 1905.369 ? 3.745 ops/s >> >> Benchmark (algorithm) (keyLength) (kpgAlgorithm) (provider) Mode Cnt Score Error Units >> KeyAgreementBench.EC.generateSecret ECDH 256 EC thrpt 40 1903.997 ? 4.092 ops/s >> >> >> Performance with intrinsic >> >> Benchmark (isMontBench) Mode Cnt Score Error Units >> PolynomialP256Bench.benchMultiply true thrpt 8 2676.599 ? 24.722 ops/s >> PolynomialP256Bench.benchMultiply false thrpt 8 1770.589 ? 2.584 op... > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > Added conditionalAssign() intrinsic, changed mult intrinsic to use hybrid neon/gpr approach src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7282: > 7280: __ mov(mul_ptr, sp); > 7281: > 7282: __ umullv(A[0], __ T2D, b_lows, __ T2S, a_vals, __ S, 0); I notice that this 4 line insn pattern recurs several times. You might consider defining a macro generator method to generate these sequences i.e. vs_umullv(VSeq<4> vs, FloatRegister bs, FloatRegister as, int lane_lo) { __ umullv(vs[0], __ T2D, bs, __ T2S, as, __S, lane_lo); __ umull2v(vs[1], __ T2D, bs, __ T4S. as, __S, lane_lo); __ umullv(vs[2], __ T2D, bs, __T2S, as, __S, lane_lo + 2); __ umull2v(vs[3], __ T2D, bs, __T4S, as, __S, lane_lo + 2); } So, in this case you would call vs_umullv(A, b_lows, a_vals, 0); and in other cases you can simply vary which arguments you provide for `vs`, `as`, `bs` and `lane_lo`. I'm suggesting that because the various cross multiplies generated by this macro-method appear to implement a specific subsequence of the mont mul computation (similar to what is done in e.g. the kyber code). So, this generator method abstraction should also abstract that a clear step in any pseudo-code algorithm you provide and ought therefore to make clear that (also make clear /how/) the generated code implements that algorithm. If you can provide such a pseudo-code algorithm then we might even be able come up with a better name for the generator method (e.g. montmul_uproduct or something else that reflects what is happening here). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2727648074 From adinn at openjdk.org Mon Jan 26 13:55:39 2026 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 26 Jan 2026 13:55:39 GMT Subject: RFR: 8355216: Accelerate P-256 arithmetic on aarch64 [v4] In-Reply-To: <1pWEujfd2cR7cqahubA6lbBgtTfnX00oGLzR9tr1AOw=.9c3fa260-6c98-480d-aec8-82ebf8c63129@github.com> References: <1pWEujfd2cR7cqahubA6lbBgtTfnX00oGLzR9tr1AOw=.9c3fa260-6c98-480d-aec8-82ebf8c63129@github.com> Message-ID: <9BNJyY7gZJtYmMduwlUp1seCnrCamkEpiVrKNKEHYhI=.a37c9472-1469-4e88-bada-128627110e57@github.com> On Mon, 26 Jan 2026 04:25:44 GMT, Ben Perez wrote: >> An aarch64 implementation of the `MontgomeryIntegerPolynomial256.mult()` method and `IntegerPolynomial.conditionalAssign()`. Since 64-bit multiplication is not supported on Neon and manually performing this operation with 32-bit limbs is slower than with GPRs, a hybrid neon/gpr approach is used. Neon instructions are used to compute intermediate values used in the last two iterations of the main "loop", while the GPRs compute the first few iterations. At the method level this improves performance by ~9% and at the API level roughly 5%. >> >> Performance no intrinsic: >> >> Benchmark (isMontBench) Mode Cnt Score Error Units >> PolynomialP256Bench.benchMultiply true thrpt 8 2427.562 ? 24.923 ops/s >> PolynomialP256Bench.benchMultiply false thrpt 8 1757.495 ? 41.805 ops/s >> PolynomialP256Bench.benchSquare true thrpt 8 2435.202 ? 20.822 ops/s >> PolynomialP256Bench.benchSquare false thrpt 8 2420.390 ? 33.594 ops/s >> >> Benchmark (algorithm) (dataSize) (keyLength) (provider) Mode Cnt Score Error Units >> SignatureBench.ECDSA.sign SHA256withECDSA 1024 256 thrpt 40 8439.881 ? 29.838 ops/s >> SignatureBench.ECDSA.sign SHA256withECDSA 16384 256 thrpt 40 7990.614 ? 30.998 ops/s >> SignatureBench.ECDSA.verify SHA256withECDSA 1024 256 thrpt 40 2677.737 ? 8.400 ops/s >> SignatureBench.ECDSA.verify SHA256withECDSA 16384 256 thrpt 40 2619.297 ? 9.737 ops/s >> >> Benchmark (algorithm) (keyLength) (kpgAlgorithm) (provider) Mode Cnt Score Error Units >> KeyAgreementBench.EC.generateSecret ECDH 256 EC thrpt 40 1905.369 ? 3.745 ops/s >> >> Benchmark (algorithm) (keyLength) (kpgAlgorithm) (provider) Mode Cnt Score Error Units >> KeyAgreementBench.EC.generateSecret ECDH 256 EC thrpt 40 1903.997 ? 4.092 ops/s >> >> >> Performance with intrinsic >> >> Benchmark (isMontBench) Mode Cnt Score Error Units >> PolynomialP256Bench.benchMultiply true thrpt 8 2676.599 ? 24.722 ops/s >> PolynomialP256Bench.benchMultiply false thrpt 8 1770.589 ? 2.584 op... > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > Added conditionalAssign() intrinsic, changed mult intrinsic to use hybrid neon/gpr approach src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7933: > 7931: __ ldr(b9, Address(bLimbs, 64)); > 7932: __ ldr(b10, Address(bLimbs, 72)); > 7933: You could use the existing macro generator method `vs_ldpq` to plant these load instructions vs_ldpq(a_vec, aLimbs); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2727688196 From adinn at openjdk.org Mon Jan 26 13:55:40 2026 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 26 Jan 2026 13:55:40 GMT Subject: RFR: 8355216: Accelerate P-256 arithmetic on aarch64 [v4] In-Reply-To: <9BNJyY7gZJtYmMduwlUp1seCnrCamkEpiVrKNKEHYhI=.a37c9472-1469-4e88-bada-128627110e57@github.com> References: <1pWEujfd2cR7cqahubA6lbBgtTfnX00oGLzR9tr1AOw=.9c3fa260-6c98-480d-aec8-82ebf8c63129@github.com> <9BNJyY7gZJtYmMduwlUp1seCnrCamkEpiVrKNKEHYhI=.a37c9472-1469-4e88-bada-128627110e57@github.com> Message-ID: On Mon, 26 Jan 2026 13:49:52 GMT, Andrew Dinn wrote: >> Ben Perez has updated the pull request incrementally with one additional commit since the last revision: >> >> Added conditionalAssign() intrinsic, changed mult intrinsic to use hybrid neon/gpr approach > > src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7933: > >> 7931: __ ldr(b9, Address(bLimbs, 64)); >> 7932: __ ldr(b10, Address(bLimbs, 72)); >> 7933: > > You could use the existing macro generator method `vs_ldpq` to plant these load instructions > > vs_ldpq(a_vec, aLimbs); Alternatively, if you need to fold in a fixed initial offset plus a suitable step then use `vs_ldpq_indexed` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2727698642 From adinn at openjdk.org Mon Jan 26 14:01:33 2026 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 26 Jan 2026 14:01:33 GMT Subject: RFR: 8355216: Accelerate P-256 arithmetic on aarch64 [v4] In-Reply-To: References: <1pWEujfd2cR7cqahubA6lbBgtTfnX00oGLzR9tr1AOw=.9c3fa260-6c98-480d-aec8-82ebf8c63129@github.com> <9BNJyY7gZJtYmMduwlUp1seCnrCamkEpiVrKNKEHYhI=.a37c9472-1469-4e88-bada-128627110e57@github.com> Message-ID: On Mon, 26 Jan 2026 13:52:58 GMT, Andrew Dinn wrote: >> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7933: >> >>> 7931: __ ldr(b9, Address(bLimbs, 64)); >>> 7932: __ ldr(b10, Address(bLimbs, 72)); >>> 7933: >> >> You could use the existing macro generator method `vs_ldpq` to plant these load instructions >> >> vs_ldpq(a_vec, aLimbs); > > Alternatively, if you need to fold in a fixed initial offset plus a suitable step then use `vs_ldpq_indexed` n.b. Note that you can use `vs_even(a_vec)` and `vs_odd(a_vec)` to select vector subsequences `a_vec[0]` and `a_vec[2]` or `a_vec[1]` and `a_vec[3]` respectively. Likewise, there is `vs_front` and `vs_back` to select the first and second halves of the vector sequence. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2727712970 From adinn at openjdk.org Mon Jan 26 14:01:37 2026 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 26 Jan 2026 14:01:37 GMT Subject: RFR: 8355216: Accelerate P-256 arithmetic on aarch64 [v4] In-Reply-To: <1pWEujfd2cR7cqahubA6lbBgtTfnX00oGLzR9tr1AOw=.9c3fa260-6c98-480d-aec8-82ebf8c63129@github.com> References: <1pWEujfd2cR7cqahubA6lbBgtTfnX00oGLzR9tr1AOw=.9c3fa260-6c98-480d-aec8-82ebf8c63129@github.com> Message-ID: <_sGnMq8gOMBI_7zccUovqLRS-kCEWvtGnsPNQ76S2QI=.c8b20bec-694b-4b51-a240-626b2c099d0a@github.com> On Mon, 26 Jan 2026 04:25:44 GMT, Ben Perez wrote: >> An aarch64 implementation of the `MontgomeryIntegerPolynomial256.mult()` method and `IntegerPolynomial.conditionalAssign()`. Since 64-bit multiplication is not supported on Neon and manually performing this operation with 32-bit limbs is slower than with GPRs, a hybrid neon/gpr approach is used. Neon instructions are used to compute intermediate values used in the last two iterations of the main "loop", while the GPRs compute the first few iterations. At the method level this improves performance by ~9% and at the API level roughly 5%. >> >> Performance no intrinsic: >> >> Benchmark (isMontBench) Mode Cnt Score Error Units >> PolynomialP256Bench.benchMultiply true thrpt 8 2427.562 ? 24.923 ops/s >> PolynomialP256Bench.benchMultiply false thrpt 8 1757.495 ? 41.805 ops/s >> PolynomialP256Bench.benchSquare true thrpt 8 2435.202 ? 20.822 ops/s >> PolynomialP256Bench.benchSquare false thrpt 8 2420.390 ? 33.594 ops/s >> >> Benchmark (algorithm) (dataSize) (keyLength) (provider) Mode Cnt Score Error Units >> SignatureBench.ECDSA.sign SHA256withECDSA 1024 256 thrpt 40 8439.881 ? 29.838 ops/s >> SignatureBench.ECDSA.sign SHA256withECDSA 16384 256 thrpt 40 7990.614 ? 30.998 ops/s >> SignatureBench.ECDSA.verify SHA256withECDSA 1024 256 thrpt 40 2677.737 ? 8.400 ops/s >> SignatureBench.ECDSA.verify SHA256withECDSA 16384 256 thrpt 40 2619.297 ? 9.737 ops/s >> >> Benchmark (algorithm) (keyLength) (kpgAlgorithm) (provider) Mode Cnt Score Error Units >> KeyAgreementBench.EC.generateSecret ECDH 256 EC thrpt 40 1905.369 ? 3.745 ops/s >> >> Benchmark (algorithm) (keyLength) (kpgAlgorithm) (provider) Mode Cnt Score Error Units >> KeyAgreementBench.EC.generateSecret ECDH 256 EC thrpt 40 1903.997 ? 4.092 ops/s >> >> >> Performance with intrinsic >> >> Benchmark (isMontBench) Mode Cnt Score Error Units >> PolynomialP256Bench.benchMultiply true thrpt 8 2676.599 ? 24.722 ops/s >> PolynomialP256Bench.benchMultiply false thrpt 8 1770.589 ? 2.584 op... > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > Added conditionalAssign() intrinsic, changed mult intrinsic to use hybrid neon/gpr approach src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7957: > 7955: > 7956: vs_eor(a_vec, a_vec, b_vec); > 7957: Likewise there are `vs_stpq` and `vs_stqp_indexed` that you can use here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2727717489 From epeter at openjdk.org Mon Jan 26 16:04:33 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 26 Jan 2026 16:04:33 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v17] In-Reply-To: <-cin72VWnqAukd5JbCMV9BfsGR1tWcWh_aGpdrlhHlM=.2d22e5da-35d2-4ffc-8ce5-86c90d662fd7@github.com> References: <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com> <1ElN5XvEXAYGINpCIB2smhDrzekGyiXmG6o8-jnxDxk=.83a69a64-2894-40af-a2ee-9c35448c88b2@github.com> <-cin72VWnqAukd5JbCMV9BfsGR1tWcWh_aGpdrlhHlM=.2d22e5da-35d2-4ffc-8ce5-86c90d662fd7@github.com> Message-ID: On Fri, 23 Jan 2026 04:57:04 GMT, Jatin Bhateja wrote: >> Hi @eme64 , Your comments have been addressed > >> @jatin-bhateja This patch is really really large. There are lots of renamings that could be done in a separate patch first (as a subtask). It would make reviewing easier, allowing focus on the substantial work. See discussion here: [#28002 (comment)](https://github.com/openjdk/jdk/pull/28002#discussion_r2705376899) > > Hi @eme64 , > > I have done some cleanups, following is the summary of changes included with the patch:- > > ``` > 1 Changes to introduce a new (custom) basictype T_FLOAT16 > - Global Definition. > - Skip over handling where ever applicable. > 2 Changes to pass laneType (BasicType) to intrinsific entry point instead of element classes. > - Inline expander interface changes mainly. > 3 Changes in abstract and concrete vector class generation templates. > 4 Changing the nomenclature of Vector classes to avoid Float1664... sort of names... > 5 Changes in the LaneType to add a new carrier type field. > 6 Changes in inline expanders to selectivelty enable intrinsification for opration for which we have > auto-vectorization and backend support in place.. > 7 Changes in test generation templates. > b. Assert wrappers to conver float16 (short) value to float before invoking testng Asserts. > c. Scalar operation wrappers to selectivelty invoke Float16 math routine which are not > part of Java SE math libraries. > > 8 New IR verification test. > 9 New Micro-benchmark. > 10 AARCH64 test failure - patch + test fixed by Bhavana Kilambi. > > > Out of above change 7b consumes 40000+ LOC. > > Q. Why do we need wrapper assertions ? > A. To handle all possible NaN representations of SNaN and QNaN, since float16 uses short carrier type hence we need to promote them float values before invoking TestNG assertions. This conversion is accomplished by assertion wrappers > > All the tasks are related and most of source/test are generated using scripts we should not go by the size of patch and review the templates files. @jatin-bhateja I was wondering: what prompted the decision to add a new `BasicType` for `Float16`? Would each additional numeric type get a new `BasicType`? How many do we anticipate? Currently, we are using `T_SHORT` for `Float16`, right? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3800362594 From epeter at openjdk.org Mon Jan 26 16:36:39 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 26 Jan 2026 16:36:39 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v17] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 12:17:02 GMT, Jatin Bhateja 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. >> >> image >> >> 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 34 commits: > > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Clanups > - Refactoring vectorIntrinsics > - Refactoring and cleanups > - Refactoring and cleanups > - Review comments resolutions > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Adding testpoint for JDK-8373574 > - Review comments resolutions > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - ... and 24 more: https://git.openjdk.org/jdk/compare/0f1b96a5...ce5768fa I asked some people internally, and they seem to be _very_ opposed to a new BasicType. Because it goes across the JVM, as I can also see in your patch. Apparently, they wanted to avoid the use of new BasicTypes, mostly managed except for the new `T_FLAT_ELEMENT`. Using `T_SHORT` for `Float16` would be strongly preferred. I think it may be good to ask @fparain @rose00 @iwanowww @vnkozlov if they have opinions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3800525049 From henryjen at openjdk.org Mon Jan 26 16:41:24 2026 From: henryjen at openjdk.org (Henry Jen) Date: Mon, 26 Jan 2026 16:41:24 GMT Subject: Integrated: 8373924: Remove unreferenced ImageDecompressor::image_decompressor_close In-Reply-To: References: Message-ID: <-aGCcumJZykUpC56GGxLRVMKNAVIemLLUrwGARXTkbk=.bfede5b8-6617-44e5-9ae3-1fa14565142e@github.com> On Thu, 22 Jan 2026 18:57:30 GMT, Henry Jen wrote: > I don't see image_decompressor_close actually referenced in the code base, as the decompressors are static and setup from image_decompressor_init(). > > This PR implements proper cleanup for decompressors to be defensive. This pull request has now been integrated. Changeset: 67beb9cd Author: Henry Jen URL: https://git.openjdk.org/jdk/commit/67beb9cd812db2af49c62c95d69f2f27d0a20af8 Stats: 8 lines in 2 files changed: 1 ins; 4 del; 3 mod 8373924: Remove unreferenced ImageDecompressor::image_decompressor_close Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/29371 From psandoz at openjdk.org Mon Jan 26 16:51:30 2026 From: psandoz at openjdk.org (Paul Sandoz) Date: Mon, 26 Jan 2026 16:51:30 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v17] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 12:17:02 GMT, Jatin Bhateja 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. >> >> image >> >> 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 34 commits: > > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Clanups > - Refactoring vectorIntrinsics > - Refactoring and cleanups > - Refactoring and cleanups > - Review comments resolutions > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Adding testpoint for JDK-8373574 > - Review comments resolutions > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - ... and 24 more: https://git.openjdk.org/jdk/compare/0f1b96a5...ce5768fa The underlying motivation was to avoid passing two parameters to the vector intrinsics that can get out of sync. Currently, we cannot use `Float16.class` like we can `Integer.class` that describes the vector element type to the intrinsic. Could we use an internal class that acts as a proxy until we can replace it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3800594113 From liach at openjdk.org Mon Jan 26 17:16:13 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 Jan 2026 17:16:13 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v4] In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 03:27:06 GMT, Quan Anh Mai wrote: >> Chen Liang 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 12 additional commits since the last revision: >> >> - Move test, fix merge garbage >> - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const >> - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const >> - Typo >> - assert >> - refactorings >> - Typo >> - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const >> - Cleanup >> - identity hash support in C2 >> - ... and 2 more: https://git.openjdk.org/jdk/compare/96fd00b6...67a3954f > > src/hotspot/share/ci/ciArray.cpp line 93: > >> 91: // Returns T_ILLEGAL if there is no element at the given index. >> 92: ciConstant ciArray::element_value(int index) { >> 93: assert(index >= 0, "out-of-bounds index: %d", index); > > IIUC, this is because you use `-1` as the offset for hashcode, so you need to make sure we are accessing a real element here, or the cache access will return something dubious. I think it is then more uniform to save the value at the cache using the offset instead of the element index. I think I will not touch ciArray but rather comment on the ConstantValue _off variable about it is just a key. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2728496636 From duke at openjdk.org Mon Jan 26 17:24:56 2026 From: duke at openjdk.org (Ryan Hallock) Date: Mon, 26 Jan 2026 17:24:56 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v4] In-Reply-To: References: Message-ID: <_aldMUgRlZczkrjTXtd7k1EVzaM3OzLoLJEPWAd-k6Q=.80ebeb4b-8181-4646-ac1a-73aeba1dbbdc@github.com> On Mon, 15 Dec 2025 19:49:52 GMT, Chen Liang wrote: >> Folding identity hash as constant if the incoming argument is constant would be useful for quick map lookups, such as for the [Classifier proposal](https://openjdk.org/jeps/8357674). Currently, identity hash is not constant because it loads the object header/mark word. We can add an explicit bypass to load an existing hash eagerly instead. > > Chen Liang 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 12 additional commits since the last revision: > > - Move test, fix merge garbage > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const > - Typo > - assert > - refactorings > - Typo > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const > - Cleanup > - identity hash support in C2 > - ... and 2 more: https://git.openjdk.org/jdk/compare/f449918c...67a3954f Would this PR allow the removal of the stable hash in Enum#hashCode, maybe that should be a followup? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28589#issuecomment-3800754288 From liach at openjdk.org Mon Jan 26 17:40:19 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 Jan 2026 17:40:19 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v4] In-Reply-To: References: Message-ID: On Mon, 15 Dec 2025 19:49:52 GMT, Chen Liang wrote: >> Folding identity hash as constant if the incoming argument is constant would be useful for quick map lookups, such as for the [Classifier proposal](https://openjdk.org/jeps/8357674). Currently, identity hash is not constant because it loads the object header/mark word. We can add an explicit bypass to load an existing hash eagerly instead. > > Chen Liang 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 12 additional commits since the last revision: > > - Move test, fix merge garbage > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const > - Typo > - assert > - refactorings > - Typo > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const > - Cleanup > - identity hash support in C2 > - ... and 2 more: https://git.openjdk.org/jdk/compare/8652dc25...67a3954f No, this only covers if a constant enum is passed. If an arbitrary enum constant is passed we still go through sone arithmetics and is slower. But this difference is probably small enough to warrant the removal. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28589#issuecomment-3800819255 From aph at openjdk.org Mon Jan 26 17:41:00 2026 From: aph at openjdk.org (Andrew Haley) Date: Mon, 26 Jan 2026 17:41:00 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v25] In-Reply-To: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: > In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. > > Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. > > This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. > > The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. > > We mark all sites that we know will write to code memory with > `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. > > We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. > > It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. > > One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude, and it's better to be able to ... Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: One more ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26562/files - new: https://git.openjdk.org/jdk/pull/26562/files/37730e6a..c6652628 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=24 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=23-24 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26562.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26562/head:pull/26562 PR: https://git.openjdk.org/jdk/pull/26562 From sviswanathan at openjdk.org Mon Jan 26 17:46:42 2026 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Mon, 26 Jan 2026 17:46:42 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v12] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 02:34:30 GMT, Xiaohong Gong wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments resolutions > > LGTM! Thanks for your updating! > Hi @XiaohongGong , your comments have been addressed. Hi @sviswa7, can you kindly review x86 part. Thanks @jatin-bhateja. I will take a look next week. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3800844163 From aph at openjdk.org Mon Jan 26 17:51:56 2026 From: aph at openjdk.org (Andrew Haley) Date: Mon, 26 Jan 2026 17:51:56 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v22] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: On Thu, 23 Oct 2025 19:30:32 GMT, Dean Long wrote: > There was one crash running applications/ctw/modules/java_base_2.java with the flags "-ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:+TieredCompilation -Djava.awt.headless=true": guarantee(StressWXHealing) failed: We should not reach here unless StressWXHealing Here: > > ``` > V [libjvm.dylib+0xead1c4] Thread::wx_enable_write()+0x0 > V [libjvm.dylib+0x10093cc] JVM_handle_bsd_signal+0x244 > ``` I found the root cause of that. Fixed in [this commit](https://github.com/openjdk/jdk/pull/26562/changes/c665262824a2e124c950881dce2c3eeda612a9f2) ------------- PR Comment: https://git.openjdk.org/jdk/pull/26562#issuecomment-3800863598 From aph at openjdk.org Mon Jan 26 17:51:59 2026 From: aph at openjdk.org (Andrew Haley) Date: Mon, 26 Jan 2026 17:51:59 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v25] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: <8otJbd6Lv2U_BSCZLUJQC54p7Q0WaTMCyAkkQ6jcH9c=.76815322-f109-4a3e-b73d-f948bb54ae93@github.com> On Mon, 26 Jan 2026 17:41:00 GMT, Andrew Haley wrote: >> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. >> >> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. >> >> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. >> >> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. >> >> We mark all sites that we know will write to code memory with >> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. >> >> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. >> >> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. >> >> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude... > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > One more If all the tests pass, this is good to go. Thanks, everyone! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26562#issuecomment-3800866809 From kvn at openjdk.org Mon Jan 26 17:53:57 2026 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 26 Jan 2026 17:53:57 GMT Subject: RFR: 8372617: Save and restore stubgen stubs when using an AOT code cache In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 17:21:46 GMT, Andrew Dinn wrote: >> I noticed that we have to add a lot of local data tables addresses for stubs (math intrinsics). >> May be we should consider to have platform specific AOT address tables for such address (and platform specific stubs). To avoid search in one big table. > > @vnkozlov > >> I noticed that we have to add a lot of local data tables addresses for stubs (math intrinsics). >> May be we should consider to have platform specific AOT address tables for such address (and platform specific stubs). To avoid search in one big table. > > I think we only need to search the the _extrs address list when we are saving stub or nmethod blobs and need to translate a target address to a table index. When loading code we simply use an index to lookup the corresponding address. So, performance is only an issue for the assembly phase. > > I don't think splitting the externals tables is going to be much help. If we flag stubs as arch-specific or generic then, sure, we can bypass the local externals table if we are saving a generic stub. But that does not avoid what is essentially an o(n^2) lookup, it merely reduces it by a constant factor (ratio of generic external references to all external references) that is not that much less than 1. > > I suggest instead that during stub save we populate a hash table of whenever we insert a new external address into the table. That way we can do the lookup in constant time. How does that sound? @adinn A lot of tests failed running with `-XX:+AOTClassLinking -XX:+UseZGC` and also other GCs except G1. It failed to find CodeBlob: # # Internal Error (c:\workspace\open\src\hotspot\share\code\aotCodeCache.cpp:2231), pid=101344, tid=56920 # assert(false) failed: Address 0x00007fff3f888e50 for runtime target 'ZPointerVectorLoadBadMask+0' is missing in AOT Code Cache addresses table # and an other: [2026-01-24T01:09:28,841Z] # assert(false) failed: Address 0x0000ffffb50272ec for runtime target 'ZBarrierSetRuntime::store_barrier_on_oop_field_without_healing(oop*)+0' is missing in AOT Code Cache addresses table I did not list all. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28433#issuecomment-3800876793 From kvn at openjdk.org Mon Jan 26 18:01:38 2026 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 26 Jan 2026 18:01:38 GMT Subject: RFR: 8372617: Save and restore stubgen stubs when using an AOT code cache [v4] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 17:16:15 GMT, Andrew Dinn wrote: >> This PR adds save and restore of all generated stubs to the AOT code cache on x86 and aarch64. Other arches are modified to deal with the related generic PAI changes. >> >> Small changes were required to the aarch64 and x86_64 generator code in order to meet two key constraints: >> 1. the first declared entry of every stub starts at the first instruction in the stub code range >> 2. all data/code cross-references from one stub to another target a declared stub entry > > Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision: > > - fix whitespace issue > - remaining asmehra feedback Also several tests (including runtime/cds/appcds/aotCache/) filed when run with GC different from G1: # SIGSEGV (0xb) at pc=0x00007f21738f106d, pid=3522829, tid=3522833 # # JRE version: Java(TM) SE Runtime Environment (27.0) (fastdebug build 27-internal-2026-01-24-0025574.vladimir.kozlov.jdkgit2) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 27-internal-2026-01-24-0025574.vladimir.kozlov.jdkgit2, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, serial gc, linux-amd64) # Problematic frame: # v ~BufferBlob::final_blob (stub gen) 0x00007f21738f106d -XX:MaxRAMPercentage=4.16667 -XX:+UseSerialGC -Xlog:class+load -Dcom.sun.management.jmxremote=true -Xlog:arguments,aot,cds:file=HelloAOTCache-with-management-agent.production.log::filesize=0 -XX:AOTMode=on -XX:AOTCache=HelloAOTCache-with-management-agent.aot HelloAOTCacheApp Stack: [0x00007f218dffc000,0x00007f218e0fd000], sp=0x00007f218e0f7af0, free space=1006k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) v ~BufferBlob::final_blob (stub gen) 0x00007f21738f106d J 280 c1 java.util.Arrays.copyOf([Ljava/lang/Object;ILjava/lang/Class;)[Ljava/lang/Object; java.base at 27-internal (40 bytes) @ 0x00007f216c30d2ce [0x00007f216c30d000+0x00000000000002ce] J 378 c1 java.util.ArrayList.grow(I)[Ljava/lang/Object; java.base at 27-internal (60 bytes) @ 0x00007f216c30cc2c [0x00007f216c30cb00+0x000000000000012c] ------------- PR Comment: https://git.openjdk.org/jdk/pull/28433#issuecomment-3800913606 From liach at openjdk.org Mon Jan 26 18:32:47 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 Jan 2026 18:32:47 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v7] In-Reply-To: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> References: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> Message-ID: On Thu, 18 Dec 2025 00:03:10 GMT, Chen Liang wrote: >> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. >> >> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. >> >> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. >> >> Paging @minborg who requested Optional folding for review. >> >> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Move the test to a core library purposed directory Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3801082528 From liach at openjdk.org Mon Jan 26 18:33:18 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 Jan 2026 18:33:18 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v5] In-Reply-To: References: Message-ID: > Folding identity hash as constant if the incoming argument is constant would be useful for quick map lookups, such as for the [Classifier proposal](https://openjdk.org/jeps/8357674). Currently, identity hash is not constant because it loads the object header/mark word. We can add an explicit bypass to load an existing hash eagerly instead. Chen Liang 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 14 additional commits since the last revision: - Copyright year, code style improvements - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const - Move test, fix merge garbage - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const - Typo - assert - refactorings - Typo - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const - ... and 4 more: https://git.openjdk.org/jdk/compare/a4c5fb85...e33f01e0 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28589/files - new: https://git.openjdk.org/jdk/pull/28589/files/67a3954f..e33f01e0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28589&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28589&range=03-04 Stats: 95520 lines in 3917 files changed: 47645 ins; 16634 del; 31241 mod Patch: https://git.openjdk.org/jdk/pull/28589.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28589/head:pull/28589 PR: https://git.openjdk.org/jdk/pull/28589 From liach at openjdk.org Mon Jan 26 18:33:21 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 Jan 2026 18:33:21 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v4] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 17:13:08 GMT, Chen Liang wrote: >> src/hotspot/share/ci/ciArray.cpp line 93: >> >>> 91: // Returns T_ILLEGAL if there is no element at the given index. >>> 92: ciConstant ciArray::element_value(int index) { >>> 93: assert(index >= 0, "out-of-bounds index: %d", index); >> >> IIUC, this is because you use `-1` as the offset for hashcode, so you need to make sure we are accessing a real element here, or the cache access will return something dubious. I think it is then more uniform to save the value at the cache using the offset instead of the element index. > > I think I will not touch ciArray but rather comment on the ConstantValue _off variable about it is just a key. I decided to rename ConstantValue's off into key, should reduce confusions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2728758977 From liach at openjdk.org Mon Jan 26 18:33:22 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 Jan 2026 18:33:22 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v4] In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 03:19:14 GMT, Quan Anh Mai wrote: >> src/hotspot/share/ci/ciObject.hpp line 76: >> >>> 74: }; >>> 75: >>> 76: const int IDENTITY_HASH_OFFSET = -1; >> >> `const` is fine, but `constexpr` is often preferred. Also, is `static` needed here? Another nitpick is that constants are usually not in uppercase in C++, as macros are often in uppercase. > > It is also useful to note what this value is. It is not clear at first glance why offset is -1 here. I see gc is now using `static constexpr int lowerCamelCase = ...` will use it here too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2728758052 From liach at openjdk.org Mon Jan 26 18:35:22 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 Jan 2026 18:35:22 GMT Subject: Integrated: 8372696: Allow boot classes to explicitly opt-in for final field trusting In-Reply-To: References: Message-ID: On Thu, 27 Nov 2025 16:16:05 GMT, Chen Liang wrote: > Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. > > They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. > > We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. > > Paging @minborg who requested Optional folding for review. > > I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. This pull request has now been integrated. Changeset: 3220c4cb Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/3220c4cb431a2c4eb8bb2d60f0d5046e40af69bd Stats: 168 lines in 13 files changed: 154 ins; 13 del; 1 mod 8372696: Allow boot classes to explicitly opt-in for final field trusting Reviewed-by: jvernee, jrose, alanb ------------- PR: https://git.openjdk.org/jdk/pull/28540 From iklam at openjdk.org Mon Jan 26 18:35:37 2026 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 26 Jan 2026 18:35:37 GMT Subject: RFR: 8374549: Extend MetaspaceClosure to cover non-MetaspaceObj types [v2] In-Reply-To: References: Message-ID: > Previously, `MetaspaceClosure` could iterate only `MetaspaceObject`, using its four member functions: > > - `is_read_only_by_default()` > - `metaspace_pointers_do()` > - `size()` > - `type()` > > `PackageEntry`, `ModuleEntry` and `GrowableArray` cannot be subclasses from `MetaspaceObject` due to various constraints. As a result, they were copied with ad-hoc code. > > This PR updates the templates in `MetaspaceClosure` so that it can iterate any classes that have the above four functions. This allows new types of data to be uniformly copied into the AOT cache (aka CDS archive) without ad-hoc copiers. > > This PR is necessary for future evolution of AOT as more types of data will be copied into the AOT cache. For example, in Valhalla we have a `GrowableArray` that needs to be copied along with `AdapterHandleEntry`. Ioi Lam 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 19 additional commits since the last revision: - @ashu-mehra review comment -- make data_addr() function protected - Merge branch 'master' into 8374549-extend-MetaspaceClosure-to-cover-non-MetaspaceObj-types - More clean up -- MetaspaceObj::Type -> MetaspaceClosureType - clean up - Remove test code inside HotSpot for OtherCArrayRef and MSOCArrayRef - Added OtherCArrayRef and MSOCArrayRef - Removed old code that explicitly convert between GrowableArray and Array - Finished copying and clean up of PackageEntry, ModuleEntry and their growable arrays. These are not actually used by the production run yet - clean up - rename size() to size_in_heapwords() for types that are not MetaspaceObj - ... and 9 more: https://git.openjdk.org/jdk/compare/e3ac86ea...5dd8b690 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29049/files - new: https://git.openjdk.org/jdk/pull/29049/files/331fe165..5dd8b690 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29049&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29049&range=00-01 Stats: 63071 lines in 1270 files changed: 35759 ins; 12795 del; 14517 mod Patch: https://git.openjdk.org/jdk/pull/29049.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29049/head:pull/29049 PR: https://git.openjdk.org/jdk/pull/29049 From iklam at openjdk.org Mon Jan 26 18:43:39 2026 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 26 Jan 2026 18:43:39 GMT Subject: RFR: 8374549: Extend MetaspaceClosure to cover non-MetaspaceObj types [v2] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 19:52:23 GMT, Ashutosh Mehra wrote: >> Ioi Lam 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 19 additional commits since the last revision: >> >> - @ashu-mehra review comment -- make data_addr() function protected >> - Merge branch 'master' into 8374549-extend-MetaspaceClosure-to-cover-non-MetaspaceObj-types >> - More clean up -- MetaspaceObj::Type -> MetaspaceClosureType >> - clean up >> - Remove test code inside HotSpot for OtherCArrayRef and MSOCArrayRef >> - Added OtherCArrayRef and MSOCArrayRef >> - Removed old code that explicitly convert between GrowableArray and Array >> - Finished copying and clean up of PackageEntry, ModuleEntry and their growable arrays. These are not actually used by the production run yet >> - clean up >> - rename size() to size_in_heapwords() for types that are not MetaspaceObj >> - ... and 9 more: https://git.openjdk.org/jdk/compare/a349f96e...5dd8b690 > > src/hotspot/share/utilities/growableArray.hpp line 302: > >> 300: >> 301: // MetaspaceClosure support. >> 302: E** data_addr() { > > My only concern is that it is marked public which breaks encapsulation. I think we can mark it as protected if only `AOTGrowableArray` is accessing it but gtest also uses it so I am not sure if anything can be done here. I moved the `data_addr()` function to `protected`. I had to modify the gtests a little to avoid using this function (as I didn't want to add messy `friend class` declarations), but I think we are still able to test all the relevant behaviors. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29049#discussion_r2728796185 From iklam at openjdk.org Mon Jan 26 18:47:31 2026 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 26 Jan 2026 18:47:31 GMT Subject: RFR: 8374549: Extend MetaspaceClosure to cover non-MetaspaceObj types In-Reply-To: <2J18eid_bj9YDudx78DxfQ1-3nlBCWJdn8aGgINWOHo=.c2a68225-99d6-4cfc-b161-5cfae38ffe80@github.com> References: <2J18eid_bj9YDudx78DxfQ1-3nlBCWJdn8aGgINWOHo=.c2a68225-99d6-4cfc-b161-5cfae38ffe80@github.com> Message-ID: On Fri, 23 Jan 2026 16:52:35 GMT, Ashutosh Mehra wrote: > I think we should also move `_aot_metaspace_top` and `_aot_metaspace_base` out of `MetaspaceObj `. Seems like `AOTMetaspace` is a better place to store the bounds. I guess it can be done in a follow-up pr. `allocation.h` is included by every cpp file. If we move these as members of the `AOTMetaspace` class, that means all files will include aotMetaspace.hpp, which is large. We should probably break up `AOTMetaspace` into small pieces first, perhaps in a future RFE. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29049#issuecomment-3801139929 From liach at openjdk.org Mon Jan 26 19:37:06 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 Jan 2026 19:37:06 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v6] In-Reply-To: References: Message-ID: > Folding identity hash as constant if the incoming argument is constant would be useful for quick map lookups, such as for the [Classifier proposal](https://openjdk.org/jeps/8357674). Currently, identity hash is not constant because it loads the object header/mark word. We can add an explicit bypass to load an existing hash eagerly instead. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Use UpperCamelCase ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28589/files - new: https://git.openjdk.org/jdk/pull/28589/files/e33f01e0..77ec309b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28589&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28589&range=04-05 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28589.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28589/head:pull/28589 PR: https://git.openjdk.org/jdk/pull/28589 From sparasa at openjdk.org Mon Jan 26 21:16:10 2026 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Mon, 26 Jan 2026 21:16:10 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v8] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 23:04:43 GMT, Mohamed Issa wrote: >> Intel® 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 with a new target base due to a merge or a rebase. The pull request now contains 25 commits: > > - Merge branch 'master' into user/missa-prime/avx10_2 > - Merge branch 'master' into user/missa-prime/avx10_2 > - Change function names and extend IR encoding rules for CMove tests > - Merge remote-tracking branch 'origin/master' into user/missa-prime/avx10_2 > - Remove unnecessary CMOV blocks and adjust predicates involving APX and AVX10.2 > - Remove extra jump instruction in signum floating point and unify three-way floating point comparison logic in x86.ad > - Also update copyright year in IREncodingPrinter.java > - Include apx_f in list of verified CPU features for IR encoding > - Fix CMove IR tests to account for APX presence > - Merge branch 'master' into user/missa-prime/avx10_2 > - ... and 15 more: https://git.openjdk.org/jdk/compare/44b74e16...09d1e44d src/hotspot/cpu/x86/x86.ad line 6075: > 6073: operand cmpOpUCF() %{ > 6074: match(Bool); > 6075: predicate((!UseAPX || !VM_Version::supports_avx10_2()) && Is there a reason why the check is not an and like !UseAPX `&&` !VM_Version::supports_avx10_2() ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2729273938 From missa at openjdk.org Mon Jan 26 21:50:23 2026 From: missa at openjdk.org (Mohamed Issa) Date: Mon, 26 Jan 2026 21:50:23 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v8] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 21:13:10 GMT, Srinivas Vamsi Parasa wrote: >> Mohamed Issa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: >> >> - Merge branch 'master' into user/missa-prime/avx10_2 >> - Merge branch 'master' into user/missa-prime/avx10_2 >> - Change function names and extend IR encoding rules for CMove tests >> - Merge remote-tracking branch 'origin/master' into user/missa-prime/avx10_2 >> - Remove unnecessary CMOV blocks and adjust predicates involving APX and AVX10.2 >> - Remove extra jump instruction in signum floating point and unify three-way floating point comparison logic in x86.ad >> - Also update copyright year in IREncodingPrinter.java >> - Include apx_f in list of verified CPU features for IR encoding >> - Fix CMove IR tests to account for APX presence >> - Merge branch 'master' into user/missa-prime/avx10_2 >> - ... and 15 more: https://git.openjdk.org/jdk/compare/44b74e16...09d1e44d > > src/hotspot/cpu/x86/x86.ad line 6075: > >> 6073: operand cmpOpUCF() %{ >> 6074: match(Bool); >> 6075: predicate((!UseAPX || !VM_Version::supports_avx10_2()) && > > Is there a reason why the check is not an and like !UseAPX `&&` !VM_Version::supports_avx10_2() ? We want to cover the cases where a platform has APX but not AVX10.2 and vice versa. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2729386788 From vpaprotski at openjdk.org Mon Jan 26 22:09:25 2026 From: vpaprotski at openjdk.org (Volodymyr Paprotski) Date: Mon, 26 Jan 2026 22:09:25 GMT Subject: RFR: 8374926: EnableX86ECoreOpts was not enabled on some hybrid CPU [v5] In-Reply-To: References: Message-ID: On Sat, 24 Jan 2026 02:38:22 GMT, Yasumasa Suenaga wrote: >> `EnableX86ECoreOpts` has been introduced in [JDK-8319429](https://bugs.openjdk.org/browse/JDK-8319429), however model numbers which should be enabled are hard-coded, so the flag would not be enabled by default on some models like Arrow Lake. >> >> I ran a [benchmark](https://github.com/YaSuenag/garakuta/tree/master/randminmax) to check for effectiveness of `-XX:+EnableX86ECoreOpts` with JDK 25.0.1 on Windows 11 25H2, I saw performance improvement a bit on Intel Core 5 Ultra 225U as following: >> >> Disabled (default) >> >> Benchmark Mode Cnt Score Error Units >> RandMinVal.getMax thrpt 3 9707774.405 ? 27082629.015 ops/s >> RandMinVal.getMin thrpt 3 7510319.839 ? 10923547.382 ops/s >> >> >> Enabled >> >> Benchmark Mode Cnt Score Error Units >> RandMinVal.getMax thrpt 3 10127809.127 ? 45404142.338 ops/s >> RandMinVal.getMin thrpt 3 8467677.056 ? 1211998.200 ops/s >> >> >> So I think it is better to enable this flag by default on all of hybrid CPUs. >> >> >> To check what processor would be enabled E-core optimization, I made a [commit](https://github.com/openjdk/jdk/commit/f363ea1436b8100021fdac87b48ec43bcf6820af) to add comments for CPU models at first. I couldn't find out all of models (some models has not listed in SDM vol.4 so far), but most of models (excepts Sierra Forest) could be treated as hybrid CPU. Fortunately HotSpot identify hybrid flag from `CPUID`, so we can leverage it for this purpose. > > Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: > > - Add condition for CWF > - Revert "Check E-Core with Leaf 1Ah" > > This reverts commit d77b43937911b33bf39175e45e3d9d97aa949617. Marked as reviewed by vpaprotski (Committer). src/hotspot/cpu/x86/vm_version_x86.cpp line 924: > 922: // Check if processor has Intel Ecore > 923: if (FLAG_IS_DEFAULT(EnableX86ECoreOpts) && is_intel() && is_intel_server_family() && > 924: (supports_hybrid() || for completeness, the removed models: - _model == 0x97 - Alderlake (hybrid) - _model == 0xAA - Raptorlake (&refresh) (hybrid) - _model == 0xAC - Meteorlake (hybrid) - _model == 0xCC - Pantherlake (hybrid) In the long term (once the emulations have been fixed..) we will have to come and address this again.. we might have to explicitly specify all the models again I suspect, but for now, this is 'future proof'. ------------- PR Review: https://git.openjdk.org/jdk/pull/29149#pullrequestreview-3708231886 PR Review Comment: https://git.openjdk.org/jdk/pull/29149#discussion_r2729439853 From sviswanathan at openjdk.org Mon Jan 26 23:04:09 2026 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Mon, 26 Jan 2026 23:04:09 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v8] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 23:04:43 GMT, Mohamed Issa wrote: >> Intel® 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 with a new target base due to a merge or a rebase. The pull request now contains 25 commits: > > - Merge branch 'master' into user/missa-prime/avx10_2 > - Merge branch 'master' into user/missa-prime/avx10_2 > - Change function names and extend IR encoding rules for CMove tests > - Merge remote-tracking branch 'origin/master' into user/missa-prime/avx10_2 > - Remove unnecessary CMOV blocks and adjust predicates involving APX and AVX10.2 > - Remove extra jump instruction in signum floating point and unify three-way floating point comparison logic in x86.ad > - Also update copyright year in IREncodingPrinter.java > - Include apx_f in list of verified CPU features for IR encoding > - Fix CMove IR tests to account for APX presence > - Merge branch 'master' into user/missa-prime/avx10_2 > - ... and 15 more: https://git.openjdk.org/jdk/compare/44b74e16...09d1e44d Looks good to me. ------------- Marked as reviewed by sviswanathan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28337#pullrequestreview-3708421027 From sparasa at openjdk.org Tue Jan 27 00:51:53 2026 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Tue, 27 Jan 2026 00:51:53 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v8] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 23:04:43 GMT, Mohamed Issa wrote: >> Intel® 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 with a new target base due to a merge or a rebase. The pull request now contains 25 commits: > > - Merge branch 'master' into user/missa-prime/avx10_2 > - Merge branch 'master' into user/missa-prime/avx10_2 > - Change function names and extend IR encoding rules for CMove tests > - Merge remote-tracking branch 'origin/master' into user/missa-prime/avx10_2 > - Remove unnecessary CMOV blocks and adjust predicates involving APX and AVX10.2 > - Remove extra jump instruction in signum floating point and unify three-way floating point comparison logic in x86.ad > - Also update copyright year in IREncodingPrinter.java > - Include apx_f in list of verified CPU features for IR encoding > - Fix CMove IR tests to account for APX presence > - Merge branch 'master' into user/missa-prime/avx10_2 > - ... and 15 more: https://git.openjdk.org/jdk/compare/44b74e16...09d1e44d The PR looks good! Thanks, Vamsi ------------- Marked as reviewed by sparasa (Committer). PR Review: https://git.openjdk.org/jdk/pull/28337#pullrequestreview-3708651889 From missa at openjdk.org Tue Jan 27 01:24:19 2026 From: missa at openjdk.org (Mohamed Issa) Date: Tue, 27 Jan 2026 01:24:19 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v8] In-Reply-To: References: Message-ID: <2yOILe6DNi_1xPH0fCwHfN-I3eUQkbRDyP7eMw1vPZE=.9f68c278-ca0a-414b-8965-51b9641db802@github.com> On Fri, 23 Jan 2026 23:04:43 GMT, Mohamed Issa wrote: >> Intel® 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 with a new target base due to a merge or a rebase. The pull request now contains 25 commits: > > - Merge branch 'master' into user/missa-prime/avx10_2 > - Merge branch 'master' into user/missa-prime/avx10_2 > - Change function names and extend IR encoding rules for CMove tests > - Merge remote-tracking branch 'origin/master' into user/missa-prime/avx10_2 > - Remove unnecessary CMOV blocks and adjust predicates involving APX and AVX10.2 > - Remove extra jump instruction in signum floating point and unify three-way floating point comparison logic in x86.ad > - Also update copyright year in IREncodingPrinter.java > - Include apx_f in list of verified CPU features for IR encoding > - Fix CMove IR tests to account for APX presence > - Merge branch 'master' into user/missa-prime/avx10_2 > - ... and 15 more: https://git.openjdk.org/jdk/compare/44b74e16...09d1e44d @TobiHartmann, @mhaessig, @eme64, @vnkozlov Please put through validation when available. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28337#issuecomment-3802579626 From sspitsyn at openjdk.org Tue Jan 27 01:57:11 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 27 Jan 2026 01:57:11 GMT Subject: RFR: 8373367: interp-only mechanism fails to work for carrier threads in a corner case Message-ID: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com> The `interp-only` mechanism is based on the `JavaThread` objects. Carrier and virtual threads can temporary share the same `JavaThread`. The `java_thread->jvmti_thread_state()` is re-linked to a virtual thread at `mount` and to the carrier thread at `unmount`. The `JvmtiThreadState` has a back link to the `JavaThread` which is also set for virtual thread at a `mount` and carrier thread at an `unmount`. Just one of these two links at the same time is set to the `JavaThread`, the other one has to be set to `nullptr`. The `interp-only` mechanism needs this invariant. However, there is a corner case when this invariant is broken. It happens when the `JvmtiThreadState` for carrier thread has just been created. In such case, the link to `JavaThread` is always `non-nullptr` even though a virtual thread is currently mounted on a carrier thread. This simple update fixes the issue in the `JvmtiThreadState` ctor. Testing: - TBD: Mach5 tiers 1-6 ------------- Commit messages: - 8373367: interp-only mechanism fails to work for carrier threads in a corner case Changes: https://git.openjdk.org/jdk/pull/29436/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29436&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373367 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29436.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29436/head:pull/29436 PR: https://git.openjdk.org/jdk/pull/29436 From asmehra at openjdk.org Tue Jan 27 02:20:22 2026 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 27 Jan 2026 02:20:22 GMT Subject: RFR: 8374549: Extend MetaspaceClosure to cover non-MetaspaceObj types [v2] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 18:35:37 GMT, Ioi Lam wrote: >> Previously, `MetaspaceClosure` could iterate only `MetaspaceObject`, using its four member functions: >> >> - `is_read_only_by_default()` >> - `metaspace_pointers_do()` >> - `size()` >> - `type()` >> >> `PackageEntry`, `ModuleEntry` and `GrowableArray` cannot be subclasses from `MetaspaceObject` due to various constraints. As a result, they were copied with ad-hoc code. >> >> This PR updates the templates in `MetaspaceClosure` so that it can iterate any classes that have the above four functions. This allows new types of data to be uniformly copied into the AOT cache (aka CDS archive) without ad-hoc copiers. >> >> This PR is necessary for future evolution of AOT as more types of data will be copied into the AOT cache. For example, in Valhalla we have a `GrowableArray` that needs to be copied along with `AdapterHandleEntry`. > > Ioi Lam 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 19 additional commits since the last revision: > > - @ashu-mehra review comment -- make data_addr() function protected > - Merge branch 'master' into 8374549-extend-MetaspaceClosure-to-cover-non-MetaspaceObj-types > - More clean up -- MetaspaceObj::Type -> MetaspaceClosureType > - clean up > - Remove test code inside HotSpot for OtherCArrayRef and MSOCArrayRef > - Added OtherCArrayRef and MSOCArrayRef > - Removed old code that explicitly convert between GrowableArray and Array > - Finished copying and clean up of PackageEntry, ModuleEntry and their growable arrays. These are not actually used by the production run yet > - clean up > - rename size() to size_in_heapwords() for types that are not MetaspaceObj > - ... and 9 more: https://git.openjdk.org/jdk/compare/79dbaf1e...5dd8b690 still looks good There is windows debug build failure but I don't see any logs. Looks like the job didn't run. ------------- Marked as reviewed by asmehra (Committer). PR Review: https://git.openjdk.org/jdk/pull/29049#pullrequestreview-3708807715 PR Comment: https://git.openjdk.org/jdk/pull/29049#issuecomment-3802708136 From iklam at openjdk.org Tue Jan 27 02:26:30 2026 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 27 Jan 2026 02:26:30 GMT Subject: RFR: 8374549: Extend MetaspaceClosure to cover non-MetaspaceObj types [v2] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 19:33:17 GMT, Vladimir Kozlov wrote: >> Ioi Lam 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 19 additional commits since the last revision: >> >> - @ashu-mehra review comment -- make data_addr() function protected >> - Merge branch 'master' into 8374549-extend-MetaspaceClosure-to-cover-non-MetaspaceObj-types >> - More clean up -- MetaspaceObj::Type -> MetaspaceClosureType >> - clean up >> - Remove test code inside HotSpot for OtherCArrayRef and MSOCArrayRef >> - Added OtherCArrayRef and MSOCArrayRef >> - Removed old code that explicitly convert between GrowableArray and Array >> - Finished copying and clean up of PackageEntry, ModuleEntry and their growable arrays. These are not actually used by the production run yet >> - clean up >> - rename size() to size_in_heapwords() for types that are not MetaspaceObj >> - ... and 9 more: https://git.openjdk.org/jdk/compare/dd4b5f5d...5dd8b690 > > Reviewed. Thanks @vnkozlov @ashu-mehra for the review. The Windows build failure looks like an infra issue. I tested with our CI and all Windows builds succeeded. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29049#issuecomment-3802722168 From kvn at openjdk.org Tue Jan 27 03:04:42 2026 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 27 Jan 2026 03:04:42 GMT Subject: RFR: 8374549: Extend MetaspaceClosure to cover non-MetaspaceObj types [v2] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 18:35:37 GMT, Ioi Lam wrote: >> Previously, `MetaspaceClosure` could iterate only `MetaspaceObject`, using its four member functions: >> >> - `is_read_only_by_default()` >> - `metaspace_pointers_do()` >> - `size()` >> - `type()` >> >> `PackageEntry`, `ModuleEntry` and `GrowableArray` cannot be subclasses from `MetaspaceObject` due to various constraints. As a result, they were copied with ad-hoc code. >> >> This PR updates the templates in `MetaspaceClosure` so that it can iterate any classes that have the above four functions. This allows new types of data to be uniformly copied into the AOT cache (aka CDS archive) without ad-hoc copiers. >> >> This PR is necessary for future evolution of AOT as more types of data will be copied into the AOT cache. For example, in Valhalla we have a `GrowableArray` that needs to be copied along with `AdapterHandleEntry`. > > Ioi Lam 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 19 additional commits since the last revision: > > - @ashu-mehra review comment -- make data_addr() function protected > - Merge branch 'master' into 8374549-extend-MetaspaceClosure-to-cover-non-MetaspaceObj-types > - More clean up -- MetaspaceObj::Type -> MetaspaceClosureType > - clean up > - Remove test code inside HotSpot for OtherCArrayRef and MSOCArrayRef > - Added OtherCArrayRef and MSOCArrayRef > - Removed old code that explicitly convert between GrowableArray and Array > - Finished copying and clean up of PackageEntry, ModuleEntry and their growable arrays. These are not actually used by the production run yet > - clean up > - rename size() to size_in_heapwords() for types that are not MetaspaceObj > - ... and 9 more: https://git.openjdk.org/jdk/compare/94538540...5dd8b690 Re-approved ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29049#pullrequestreview-3708886140 From dlong at openjdk.org Tue Jan 27 03:11:31 2026 From: dlong at openjdk.org (Dean Long) Date: Tue, 27 Jan 2026 03:11:31 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v25] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: On Mon, 26 Jan 2026 17:41:00 GMT, Andrew Haley wrote: >> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. >> >> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. >> >> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. >> >> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. >> >> We mark all sites that we know will write to code memory with >> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. >> >> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. >> >> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. >> >> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude... > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > One more src/hotspot/share/code/nmethod.cpp line 2216: > 2214: > 2215: void nmethod::mark_as_maybe_on_stack() { > 2216: AtomicAccess::store(&_gc_epoch, CodeCache::gc_epoch()); We should probably save this change until after JDK-8373794 has been pushed. I think there will be a lot more cleanup possible after 8373794. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2730057743 From iklam at openjdk.org Tue Jan 27 03:19:31 2026 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 27 Jan 2026 03:19:31 GMT Subject: Integrated: 8374549: Extend MetaspaceClosure to cover non-MetaspaceObj types In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 20:32:46 GMT, Ioi Lam wrote: > Previously, `MetaspaceClosure` could iterate only `MetaspaceObject`, using its four member functions: > > - `is_read_only_by_default()` > - `metaspace_pointers_do()` > - `size()` > - `type()` > > `PackageEntry`, `ModuleEntry` and `GrowableArray` cannot be subclasses from `MetaspaceObject` due to various constraints. As a result, they were copied with ad-hoc code. > > This PR updates the templates in `MetaspaceClosure` so that it can iterate any classes that have the above four functions. This allows new types of data to be uniformly copied into the AOT cache (aka CDS archive) without ad-hoc copiers. > > This PR is necessary for future evolution of AOT as more types of data will be copied into the AOT cache. For example, in Valhalla we have a `GrowableArray` that needs to be copied along with `AdapterHandleEntry`. This pull request has now been integrated. Changeset: cba7d88c Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/cba7d88ca427984ebb27a1634aab10a62c9eede1 Stats: 1166 lines in 30 files changed: 653 ins; 306 del; 207 mod 8374549: Extend MetaspaceClosure to cover non-MetaspaceObj types Reviewed-by: kvn, asmehra ------------- PR: https://git.openjdk.org/jdk/pull/29049 From epeter at openjdk.org Tue Jan 27 06:55:16 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 27 Jan 2026 06:55:16 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v6] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 19:37:06 GMT, Chen Liang wrote: >> Folding identity hash as constant if the incoming argument is constant would be useful for quick map lookups, such as for the [Classifier proposal](https://openjdk.org/jeps/8357674). Currently, identity hash is not constant because it loads the object header/mark word. We can add an explicit bypass to load an existing hash eagerly instead. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Use UpperCamelCase test/hotspot/jtreg/compiler/intrinsics/object/IdentityHashCodeFold.java line 37: > 35: * @summary Verify constant folding is possible for identity hash code > 36: * @library /test/lib / > 37: * @requires vm.compiler2.enabled Drive-by comment: Do you really need this restriction? IR rules are only executed if C2 is available anyway. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2730518926 From liach at openjdk.org Tue Jan 27 07:15:12 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 27 Jan 2026 07:15:12 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v6] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 06:51:54 GMT, Emanuel Peter wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Use UpperCamelCase > > test/hotspot/jtreg/compiler/intrinsics/object/IdentityHashCodeFold.java line 37: > >> 35: * @summary Verify constant folding is possible for identity hash code >> 36: * @library /test/lib / >> 37: * @requires vm.compiler2.enabled > > Drive-by comment: > Do you really need this restriction? IR rules are only executed if C2 is available anyway. Well, the plain test isn't that meaningful without C2. https://github.com/openjdk/jdk/pull/28589#discussion_r2615925589 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2730577795 From dholmes at openjdk.org Tue Jan 27 07:36:03 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 27 Jan 2026 07:36:03 GMT Subject: RFR: 8353564: Fail fatally if os::release_memory or os::uncommit_memory fails [v2] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 08:34:51 GMT, Stefan Karlsson wrote: > I think we need to wait for a follow-up comment from David before proceeding with the proposed change here. I will defer to yourself and others as to the "fatalness" of these errors. But happier to see the error message code removed. Can `remove_guard_pages` be a void method now? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29240#issuecomment-3803573064 From dholmes at openjdk.org Tue Jan 27 07:40:28 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 27 Jan 2026 07:40:28 GMT Subject: RFR: 8364343: Virtual Thread transition management needs to be independent of JVM TI [v13] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 15:27:06 GMT, Patricio Chilano Mateo wrote: >> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes. >> >> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes: >> >> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. >> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version. >> >> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`. >> >> - The code was previously structured in t... > > Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: > > - Merge branch 'master' into JDK-8364343 > - simplify assert > - Merge branch 'master' into JDK-8364343 > - rebind in end_transition only for mount case > - Fix comment in inline_native_vthread_start_transition > - missing to initialize _is_disabler_at_start > - More changes from Coleen's review > - Drop VTMS from names > - keep preexisting rebind order for mount > - Remove INCLUDE_JVMTI macro > - ... and 5 more: https://git.openjdk.org/jdk/compare/829b8581...444ac0ce I've added a comment to the JBS issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28361#issuecomment-3803589839 From epeter at openjdk.org Tue Jan 27 07:50:09 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 27 Jan 2026 07:50:09 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v3] In-Reply-To: References: <6ip4JrJ4WiYEe6d2FA_WQ5dDjxAk2RPaPbwth4jNeJM=.43d7879d-89a4-434c-80ea-371c92581686@github.com> <0b81mH1_Y6r905N2HmehXBbSFdzLpJIfuXHNfijpHBs=.c870b13e-a52f-4c00-b771-91cf9205cb4a@github.com> Message-ID: On Mon, 15 Dec 2025 19:44:47 GMT, Chen Liang wrote: >> I don't argue that there's always a chance to catch a bug, but unit tests on C2 IR are mostly trivial, so the actual chance to spot a unique problem is quite low. And the price is execution time. > > I kept the C2 limit (note this is a build restriction instead of a flag restriction), but updated to use test.main.class. Right. Vladimir already argued against it. I forgot. I still believe it is best practice not to limit tests unless they are very expensive. But I'll accept the majority vote. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2730682963 From epeter at openjdk.org Tue Jan 27 07:50:12 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 27 Jan 2026 07:50:12 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v6] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 07:12:28 GMT, Chen Liang wrote: >> test/hotspot/jtreg/compiler/intrinsics/object/IdentityHashCodeFold.java line 37: >> >>> 35: * @summary Verify constant folding is possible for identity hash code >>> 36: * @library /test/lib / >>> 37: * @requires vm.compiler2.enabled >> >> Drive-by comment: >> Do you really need this restriction? IR rules are only executed if C2 is available anyway. > > Well, the plain test isn't that meaningful without C2. https://github.com/openjdk/jdk/pull/28589#discussion_r2615925589 Right. Vladimir already argued against it. I forgot. I still believe it is best practice not to limit tests unless they are very expensive. But I'll accept the majority vote. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2730681732 From duke at openjdk.org Tue Jan 27 07:50:22 2026 From: duke at openjdk.org (duke) Date: Tue, 27 Jan 2026 07:50:22 GMT Subject: Withdrawn: 8367546: Clarify meaning of "corresponding header" for architecture-qualified .inline.hpp files In-Reply-To: <5CObrpoaAu3vff-Xv8k3o_s-5bBoKU5Y3Rd2BsBapXE=.c806157f-bea6-47b1-b50c-3a60c89b3d93@github.com> References: <5CObrpoaAu3vff-Xv8k3o_s-5bBoKU5Y3Rd2BsBapXE=.c806157f-bea6-47b1-b50c-3a60c89b3d93@github.com> Message-ID: On Fri, 12 Sep 2025 13:26:58 GMT, Francesco Andreuzzi wrote: > During the review of #27189 we stumbled on the lack of a clear indication of what constitutes the `corresponding .hpp` file for a `.inline.hpp` file having an architecture qualifier. > > For example, `continuationHelper_x86.inline.hpp` includes `runtime/continuationHelper.hpp`, and the include statement is on top as stated in the style guide: > > > #ifndef CPU_X86_CONTINUATIONHELPER_X86_INLINE_HPP > #define CPU_X86_CONTINUATIONHELPER_X86_INLINE_HPP > > #include "runtime/continuationHelper.hpp" > > #include "runtime/continuationEntry.inline.hpp" > #include "runtime/frame.inline.hpp" > #include "runtime/registerMap.hpp" > [...] > > > However, this order is not respected by `SortIncludes.java`, which does not designate `runtime/continuationHelper.hpp` as the "corresponding `.hpp` file". If this concept was clarified in the style guide, we could improve `SortIncludes` accordingly. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27259 From epeter at openjdk.org Tue Jan 27 08:00:06 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 27 Jan 2026 08:00:06 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v8] In-Reply-To: References: Message-ID: <4nlYmoQuUt0GFqk84hZN3YcEjBo1K8fEVZeUUOuN8Qs=.11d29fdf-18df-4c25-be12-146e7954812a@github.com> On Fri, 23 Jan 2026 23:04:43 GMT, Mohamed Issa wrote: >> Intel® 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 with a new target base due to a merge or a rebase. The pull request now contains 25 commits: > > - Merge branch 'master' into user/missa-prime/avx10_2 > - Merge branch 'master' into user/missa-prime/avx10_2 > - Change function names and extend IR encoding rules for CMove tests > - Merge remote-tracking branch 'origin/master' into user/missa-prime/avx10_2 > - Remove unnecessary CMOV blocks and adjust predicates involving APX and AVX10.2 > - Remove extra jump instruction in signum floating point and unify three-way floating point comparison logic in x86.ad > - Also update copyright year in IREncodingPrinter.java > - Include apx_f in list of verified CPU features for IR encoding > - Fix CMove IR tests to account for APX presence > - Merge branch 'master' into user/missa-prime/avx10_2 > - ... and 15 more: https://git.openjdk.org/jdk/compare/44b74e16...09d1e44d test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java line 65: > 63: applyIfPlatform = {"x64", "true"}, > 64: applyIfCPUFeatureAnd = {"apx_f", "true", "avx10_2", "true"}, > 65: phase = CompilePhase.FINAL_CODE) These are all `CMove` cases. I see you added branch/call cases in the benchmark. Would it make sense to have some similar cases here? And: this here is a test for `float`. Where do we cover `double`, which you are also making VM changes for? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2730715729 From jbhateja at openjdk.org Tue Jan 27 08:11:29 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 27 Jan 2026 08:11:29 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v17] In-Reply-To: <-cin72VWnqAukd5JbCMV9BfsGR1tWcWh_aGpdrlhHlM=.2d22e5da-35d2-4ffc-8ce5-86c90d662fd7@github.com> References: <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com> <1ElN5XvEXAYGINpCIB2smhDrzekGyiXmG6o8-jnxDxk=.83a69a64-2894-40af-a2ee-9c35448c88b2@github.com> <-cin72VWnqAukd5JbCMV9BfsGR1tWcWh_aGpdrlhHlM=.2d22e5da-35d2-4ffc-8ce5-86c90d662fd7@github.com> Message-ID: <5a11-TYC046h3ro4YgCI4oSBFfyjUWlWA2I3pOMTF-k=.bfff183a-d825-45ba-bc75-d515337119be@github.com> On Fri, 23 Jan 2026 04:57:04 GMT, Jatin Bhateja wrote: >> Hi @eme64 , Your comments have been addressed > >> @jatin-bhateja This patch is really really large. There are lots of renamings that could be done in a separate patch first (as a subtask). It would make reviewing easier, allowing focus on the substantial work. See discussion here: [#28002 (comment)](https://github.com/openjdk/jdk/pull/28002#discussion_r2705376899) > > Hi @eme64 , > > I have done some cleanups, following is the summary of changes included with the patch:- > > ``` > 1 Changes to introduce a new (custom) basictype T_FLOAT16 > - Global Definition. > - Skip over handling where ever applicable. > 2 Changes to pass laneType (BasicType) to intrinsific entry point instead of element classes. > - Inline expander interface changes mainly. > 3 Changes in abstract and concrete vector class generation templates. > 4 Changing the nomenclature of Vector classes to avoid Float1664... sort of names... > 5 Changes in the LaneType to add a new carrier type field. > 6 Changes in inline expanders to selectivelty enable intrinsification for opration for which we have > auto-vectorization and backend support in place.. > 7 Changes in test generation templates. > b. Assert wrappers to conver float16 (short) value to float before invoking testng Asserts. > c. Scalar operation wrappers to selectivelty invoke Float16 math routine which are not > part of Java SE math libraries. > > 8 New IR verification test. > 9 New Micro-benchmark. > 10 AARCH64 test failure - patch + test fixed by Bhavana Kilambi. > > > Out of above change 7b consumes 40000+ LOC. > > Q. Why do we need wrapper assertions ? > A. To handle all possible NaN representations of SNaN and QNaN, since float16 uses short carrier type hence we need to promote them float values before invoking TestNG assertions. This conversion is accomplished by assertion wrappers > > All the tasks are related and most of source/test are generated using scripts we should not go by the size of patch and review the templates files. > @jatin-bhateja I was wondering: what prompted the decision to add a new `BasicType` for `Float16`? Would each additional numeric type get a new `BasicType`? How many do we anticipate? > > Currently, we are using `T_SHORT` for `Float16`, right? Hi @eme64 , Currently in JDK mainline we pass element class as the lane type, problem with passing Float16.class is that its part of incubating module an we cannot declare a symbol for it in vmSymbols, thus if we pass Float16.class as element type we will need to do a fragile name based checks over element type to infer Float16 operation in inline expanders. To circumvent this problem started passing additional integer argument vector operation type (VECTOR_TYPE_FP16 / VECTOR_TYPE_PRIM) to intrinsic entry point. Paul suggested in his [prior comment](https://github.com/openjdk/jdk/pull/28002#issuecomment-3529452461) to add a new basicType for Float16 and instead of passing element class and vector operation type pass just the basicType since its already used in the LaneType. [Enum definitions of all the primitive basic types used in LaneType ](https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java*L153__;Iw!!ACWV5N9M2RV99hQ!J4ZZ1lwCxaG8mXxtjHB9uET0tlcqBdgJwsC3pCLt4WeUQYULtKPtxo_2NIJw67AYBe6k9ffftGh_EttPe1bY_kYW$) are as per JVM specification and in synchronism with [BasicType definition in VM side](https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/globalDefinitions.hpp*L671__;Iw!!ACWV5N9M2RV99hQ!J4ZZ1lwCxaG8mXxtjHB9uET0tlcqBdgJwsC3pCLt4WeUQYULtKPtxo_2NIJw67AYBe6k9ffftGh_EttPe6e5uGFc$). VM also defines some custom basic types like T_METADATA, T_NARROWKLASS. If we just create new basic type on Java side, then there is a chance that its value may conflict with existing custom basic types in VM side. One solution is to maintain the synchronization b/w basic type assignment for primitive type only and not modify any VM side code since current scope of T_FLOAT16 is only limited to intrinsic entry point. Adding a new custom BasicType on VM side is not just a change in one place and is cumbersome and not desirable given that its used all across VM code. Thus there are following options :- 1/ Create new basicType T_FLOAT16 in Java side, add it to LaneType and pass only basic types as element type to intrinsic entry point and maintain an efficient interface 2/ Pass Float16.class as element type to Float16Vector operations and do a fragile and inefficient name base lookup in inline expander to infer Float16 vector IR. 3/ Extend both BasicType definition on Java side and VM side and keep them in synchronism but this is not desirable given that VM makes extensive use of BasicType. 4/ Pass short.class as element type and pass another argument vector operation kind to intrinsic entry point to differentiate b/w ShortVector and Float16Vector operations. 5/ Paul's suggestion to create proxy class in java.base module for Float16 type. I am inclined to go with solution 1, let me know if you have other solutions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3803701515 From aph at openjdk.org Tue Jan 27 09:32:03 2026 From: aph at openjdk.org (Andrew Haley) Date: Tue, 27 Jan 2026 09:32:03 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v25] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: On Tue, 27 Jan 2026 03:08:33 GMT, Dean Long wrote: >> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: >> >> One more > > src/hotspot/share/code/nmethod.cpp line 2216: > >> 2214: >> 2215: void nmethod::mark_as_maybe_on_stack() { >> 2216: AtomicAccess::store(&_gc_epoch, CodeCache::gc_epoch()); > > We should probably save this change until after JDK-8373794 has been pushed. I think there will be a lot more cleanup possible after 8373794. Mmm, but is it OK to push this one now? I want to have time for it to bake before rampdown. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2731072273 From aph at openjdk.org Tue Jan 27 09:32:04 2026 From: aph at openjdk.org (Andrew Haley) Date: Tue, 27 Jan 2026 09:32:04 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v25] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: On Tue, 27 Jan 2026 09:28:16 GMT, Andrew Haley wrote: >> src/hotspot/share/code/nmethod.cpp line 2216: >> >>> 2214: >>> 2215: void nmethod::mark_as_maybe_on_stack() { >>> 2216: AtomicAccess::store(&_gc_epoch, CodeCache::gc_epoch()); >> >> We should probably save this change until after JDK-8373794 has been pushed. I think there will be a lot more cleanup possible after 8373794. > > Mmm, but is it OK to push this one now? I want to have time for it to bake before rampdown. So, I'll happily drop this one change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2731073741 From chagedorn at openjdk.org Tue Jan 27 09:33:02 2026 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Tue, 27 Jan 2026 09:33:02 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: On Mon, 12 Jan 2026 10:29:39 GMT, Damon Fenacci wrote: > ## Issue > > This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. > > This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. > > ## Causes > > The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. > > ## Fix > > A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: > https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 > This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. > > # Testing > > * Tier 1-3+ > * 2 JTReg tests added > * `TestRangeCheck.java` as regression test for the reported issue > * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion Overall, the fix idea with `Opaque` nodes looks good to me! src/hotspot/share/opto/library_call.hpp line 161: > 159: Node* generate_negative_guard(Node* index, RegionNode* region, > 160: // resulting CastII of index: > 161: Node* *pos_index = nullptr, Suggestion: Node** pos_index = nullptr, ------------- PR Review: https://git.openjdk.org/jdk/pull/29164#pullrequestreview-3710064929 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2731064422 From chagedorn at openjdk.org Tue Jan 27 09:33:03 2026 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Tue, 27 Jan 2026 09:33:03 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com> Message-ID: On Tue, 20 Jan 2026 09:06:27 GMT, Volkan Yazici wrote: >> It is true that they do pretty much the same thing ("avoid" C2 optimisations for checks) but I'd argue they are semantically slightly different: one prevents optimisations where we know the value cannot be null, the other where we know the value is in range. We could actually have only one class (e.g. with a `positive` flag like before) but I'm not sure it would be a cleaner/nicer solution. ? > > Fair enough ? I was just curious. I was about to ask the same question. It seems like both `OpaqueNotNullNode` and `OpaqueGuardNode` behave the same apart from eventually folding to a false or true constant. They might have slightly different reasons for adding them but AFAIU, they are both intended to keep control and data in sync. Apart from duplicating most of the logic and comments, an additional challenge with having both nodes is that we need to special case both nodes at various points in the code which makes it more complex and raises the question if we could really observe them both or not (would not be a problem when only having one node type). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2731057975 From aph at openjdk.org Tue Jan 27 10:03:29 2026 From: aph at openjdk.org (Andrew Haley) Date: Tue, 27 Jan 2026 10:03:29 GMT Subject: RFR: 8373794: Move nmethod header from CodeCache In-Reply-To: References: Message-ID: <-kzq5g8d69uvOXdFDYPXAJas_rM5FsaFuro_AKjb5wE=.4ac4c903-0573-45b5-a0ab-f1d922ac8a31@github.com> On Wed, 17 Dec 2025 11:34:46 GMT, Mikhail Ablakatov wrote: > nmethod objects in the CodeCache have the following layout: > > > | CodeBlob header | NMethod header | Constants | MainCode | StubCode | Data/oops | > > > Although mutable and immutable metadata have already been moved out of the code cache by JDK-8343789 and JDK-8331087 respectively, the embedded `nmethod` header fields still occupy ~160 B (with the `CodeBlob` header adding another 64 B). In JDK25 the total header footprint is 224 B. This space is reserved inside executable memory, which decreases overall executable code density. > > This patch relocates the `nmethod` header to a C-heap-allocated structure and keeps only 8-byte pointer to that header in the CodeCache. The resulting layout is: > > > | CodeBlob header | Ptr to NMethodHeader | Constants | MainCode | StubCode | Data/oops | > > > This change reduces the size of the CodeCache-resident header from 224 B to 72 B (64 B `CodeBlob` header + 8 B pointer), achieving roughly a **3x reduction** in header footprint. > > This change follows the direction established by JDK-7072317, JDK-8331087 and JDK-8343789. > > ## Testing > > The patch has passed `tier1-3` and `hotspot_all` tests on AArch64 and x86_64. src/hotspot/cpu/x86/templateTable_x86.cpp line 1856: > 1854: > 1855: // and begin the OSR nmethod > 1856: // Load the _hdr pointer from the nmethod into rscratch1 These comments are inappropriate. See [Rule 1: Comments should not duplicate the code.](https://stackoverflow.blog/2021/12/23/best-practices-for-writing-code-comments/) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28866#discussion_r2731197298 From duke at openjdk.org Tue Jan 27 10:02:05 2026 From: duke at openjdk.org (Harshit470250) Date: Tue, 27 Jan 2026 10:02:05 GMT Subject: RFR: 8347396: Efficient TypeFunc creations [v5] In-Reply-To: References: Message-ID: On Sun, 25 Jan 2026 15:47:58 GMT, Kim Barrett wrote: >> Harshit470250 has updated the pull request incrementally with one additional commit since the last revision: >> >> move include shenandoah to bottom > > src/hotspot/share/opto/runtime.hpp line 235: > >> 233: static void monitor_notify_C(oopDesc* obj, JavaThread* current); >> 234: static void monitor_notifyAll_C(oopDesc* obj, JavaThread* current); >> 235: static const TypeFunc* _clone_type_Type; > > hotspot generally avoids public data members other than in simple data structs. clone_type() is not a member function of OptoRuntime, Should I define a getter function? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27279#discussion_r2731195677 From aph at openjdk.org Tue Jan 27 10:12:39 2026 From: aph at openjdk.org (Andrew Haley) Date: Tue, 27 Jan 2026 10:12:39 GMT Subject: RFR: 8373794: Move nmethod header from CodeCache In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 11:34:46 GMT, Mikhail Ablakatov wrote: > nmethod objects in the CodeCache have the following layout: > > > | CodeBlob header | NMethod header | Constants | MainCode | StubCode | Data/oops | > > > Although mutable and immutable metadata have already been moved out of the code cache by JDK-8343789 and JDK-8331087 respectively, the embedded `nmethod` header fields still occupy ~160 B (with the `CodeBlob` header adding another 64 B). In JDK25 the total header footprint is 224 B. This space is reserved inside executable memory, which decreases overall executable code density. > > This patch relocates the `nmethod` header to a C-heap-allocated structure and keeps only 8-byte pointer to that header in the CodeCache. The resulting layout is: > > > | CodeBlob header | Ptr to NMethodHeader | Constants | MainCode | StubCode | Data/oops | > > > This change reduces the size of the CodeCache-resident header from 224 B to 72 B (64 B `CodeBlob` header + 8 B pointer), achieving roughly a **3x reduction** in header footprint. > > This change follows the direction established by JDK-7072317, JDK-8331087 and JDK-8343789. > > ## Testing > > The patch has passed `tier1-3` and `hotspot_all` tests on AArch64 and x86_64. src/hotspot/share/code/nmethod.cpp line 487: > 485: void nmethod::set_deoptimized_done() { > 486: ConditionalMutexLocker ml(NMethodState_lock, !NMethodState_lock->owned_by_self(), Mutex::_no_safepoint_check_flag); > 487: if (_hdr->_deoptimization_status != NMethodHeader::deoptimize_done) { // can't go backwards Suggestion: if (deoptimization_status() != deoptimize_done) { // can't go backwards Create an accessor for `deoptimization_status`. Why is it now necessary to use `NMethodHeader::`? src/hotspot/share/code/nmethod.cpp line 1301: > 1299: _hdr->_compiler_type = type; > 1300: _hdr->_orig_pc_offset = 0; > 1301: _hdr->_num_stack_arg_slots = 0; It'd be better to move this into a separate initializer for `NMethodHeader`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28866#discussion_r2731224628 PR Review Comment: https://git.openjdk.org/jdk/pull/28866#discussion_r2731235594 From aph at openjdk.org Tue Jan 27 10:29:45 2026 From: aph at openjdk.org (Andrew Haley) Date: Tue, 27 Jan 2026 10:29:45 GMT Subject: RFR: 8373794: Move nmethod header from CodeCache In-Reply-To: References: Message-ID: <3AwMiUeGLhif3W4e5f3rf4AAakQgMatr7HanisLLUMk=.db6de600-3e3c-4028-89fd-cde55b8762d3@github.com> On Wed, 17 Dec 2025 11:34:46 GMT, Mikhail Ablakatov wrote: > nmethod objects in the CodeCache have the following layout: > > > | CodeBlob header | NMethod header | Constants | MainCode | StubCode | Data/oops | > > > Although mutable and immutable metadata have already been moved out of the code cache by JDK-8343789 and JDK-8331087 respectively, the embedded `nmethod` header fields still occupy ~160 B (with the `CodeBlob` header adding another 64 B). In JDK25 the total header footprint is 224 B. This space is reserved inside executable memory, which decreases overall executable code density. > > This patch relocates the `nmethod` header to a C-heap-allocated structure and keeps only 8-byte pointer to that header in the CodeCache. The resulting layout is: > > > | CodeBlob header | Ptr to NMethodHeader | Constants | MainCode | StubCode | Data/oops | > > > This change reduces the size of the CodeCache-resident header from 224 B to 72 B (64 B `CodeBlob` header + 8 B pointer), achieving roughly a **3x reduction** in header footprint. > > This change follows the direction established by JDK-7072317, JDK-8331087 and JDK-8343789. > > ## Testing > > The patch has passed `tier1-3` and `hotspot_all` tests on AArch64 and x86_64. src/hotspot/share/code/nmethod.cpp line 1233: > 1231: _hdr->_has_flushed_dependencies = 0; > 1232: _hdr->_is_unlinked = 0; > 1233: _hdr->_load_reported = 0; // jvmti state Again, give `NMethodHeader` its own copy and initialize logic. src/hotspot/share/code/nmethod.cpp line 1460: > 1458: _hdr->_unwind_handler_offset = nm._hdr->_unwind_handler_offset; > 1459: _hdr->_num_stack_arg_slots = nm._hdr->_num_stack_arg_slots; > 1460: _hdr->_oops_size = nm._hdr->_oops_size; This stuff belongs in class `NMethodHeader` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28866#discussion_r2731301721 PR Review Comment: https://git.openjdk.org/jdk/pull/28866#discussion_r2731303752 From shade at openjdk.org Tue Jan 27 10:49:17 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 27 Jan 2026 10:49:17 GMT Subject: RFR: 8340297: Use-after-free recognition for metaspace and class space [v11] In-Reply-To: References: Message-ID: On Thu, 4 Dec 2025 10:48:25 GMT, Thomas Stuefe wrote: >> This patch will give us use-after-free recognition for Metaspace and Class space. >> >> Currently, checks for Klass validity typically only perform a variation of `Metaspace::contains` and some other basic tests. These checks won't find cases where the Klass had been prematurely freed (e.g., after class redefinition), nor cases of unloaded classes if the underlying metaspace chunks have not been uncommitted, which is quite common. >> >> The patch also provides us with improved analysis methods in case we encounter problems. E.g., answering whether the Klass had been redefined or unloaded. >> >> The implementation aims to be simple, fast, and safe against false positives. There is a small but non-null chance that we could get false negatives, but that cannot be avoided. >> >> How this works: >> >> - In `class Metadata`, we introduce a 32-bit token that holds the type of the object (1). It replaces the old "is_valid" field of the same size. That one was of limited use since any non-null garbage in those four bytes would be read as valid. >> - To check a Metadata for validity, the token is checked. Checks are done with SafeFetch, so they can be done with questionable pointers (e.g. into uncommitted metaspace after class unloading) >> - When metaspace is freed (bulk free after class unloading), the released chunks are zapped, destroying all tokens in the area. >> - When metaspace is freed (prematurely, e.g., after class redefinition), the released blocks are zapped. >> - The new checks replace Metadata::is_valid and supplement some other metadata checks done in GCs >> >> Testing: The patch has been extensively tested manually, at Oracle, and SAP. Tests were thorough to not only catch errors in the patch, but also to see if the patch would uncover a lot of existing sleeper bugs. So far, we only found a single bug in Shenandoah. >> >> Note: I did not yet hook up the new test to c1/c2 compiled code (there are already unimplemented functions for that). That is possible, but left for a later RFE. > > Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: > > - Merge branch 'openjdk:master' into JDK-8340297-Metaspace-API-for-checking-if-address-is-in-use > - includes sorted > - Merge branch 'master' into JDK-8340297-Metaspace-API-for-checking-if-address-is-in-use > - Merge master > - Feedback Johan, Axel > - Merge branch 'master' into JDK-8340297-Metaspace-API-for-checking-if-address-is-in-use > - remove stray macro > - feedback Caspar > - Merge branch 'master' into JDK-8340297-Metaspace-API-for-checking-if-address-is-in-use > - Feedback Johan > - ... and 11 more: https://git.openjdk.org/jdk/compare/b5970c97...8682e3b3 Sorry for leaving this hanging. I skimmed through it, and had no major concerns. Mostly focusing on Shenandoah parts here: src/hotspot/share/gc/g1/g1HeapRegion.cpp line 468: > 466: if (!Metaspace::klass_is_live(klass, true, &hint)) { > 467: log_error(gc, verify)("klass " PTR_FORMAT " of object " PTR_FORMAT " " > 468: "is an invalid klass pointer, not in metaspace, or refers to a dead klass (Hint: %u)", OK, here and other places: are we able to translate the hint to something human-readable? src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp line 246: > 244: if (!os::is_readable_pointer(obj)) { > 245: print_failure(_safe_unknown, obj, interior_loc, nullptr, "Shenandoah assert_correct failed", > 246: "Object klass pointer should not be null", But that's not what the check does, does it? It literally checks for readability, not for klass pointer being nullptr. Also, unnecessary white space change on the line below. src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp line 318: > 316: > 317: if (!Metaspace::klass_is_live(obj_klass, true, &hint)) { > 318: printf_failure(_safe_unknown, obj, interior_loc, nullptr, "Shenandoah assert_correct failed", Eh... This needs to be simpler. Instead of introducing the whole new type of failure printing -- and having bugs there on their own -- perhaps you want to amend the generic `ShenandoahAsserts::print_obj` handler so it reports the klass status there? src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp line 166: > 164: "Object klass pointer unreadable or invalid"); > 165: > 166: check_v(ShenandoahAsserts::_safe_unknown, obj, Metaspace::klass_is_live(obj_klass, true, &hint), Same comment as for `ShenandoahAsserts`: once you do the klass status printouts in `ShenandoahAsserts::print_failure`, you get the verifier printouts automagically. src/hotspot/share/memory/metaspace/blockTree.hpp line 82: > 80: > 81: // A leading canary section that is zapped with the same metaspace zap pattern > 82: // as the rest of the payload following the header (and all of dead/unsused metaspace). Suggestion: // as the rest of the payload following the header (and all of dead/unused metaspace). src/hotspot/share/oops/metadata.hpp line 105: > 103: } > 104: > 105: #undef BUILD32 Leftover? ------------- PR Review: https://git.openjdk.org/jdk/pull/25891#pullrequestreview-3710341484 PR Review Comment: https://git.openjdk.org/jdk/pull/25891#discussion_r2731300420 PR Review Comment: https://git.openjdk.org/jdk/pull/25891#discussion_r2731309020 PR Review Comment: https://git.openjdk.org/jdk/pull/25891#discussion_r2731349094 PR Review Comment: https://git.openjdk.org/jdk/pull/25891#discussion_r2731355481 PR Review Comment: https://git.openjdk.org/jdk/pull/25891#discussion_r2731378965 PR Review Comment: https://git.openjdk.org/jdk/pull/25891#discussion_r2731395053 From kevinw at openjdk.org Tue Jan 27 11:04:48 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 27 Jan 2026 11:04:48 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v10] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Wed, 21 Jan 2026 18:48:45 GMT, Larry Cable 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: fixed initialization bug in AOT cache sharing summary code src/hotspot/share/services/diagnosticCommand.cpp line 962: > 960: "R = has been redefined, " > 961: "S = is shared class (if -location then 's' indicates static 'd' indicates dynamic AOT cache)", > 962: "BOOLEAN", false, "false"), Not sure I understand the "if -location" in the text here and in the man page, as we print these flags always? Are the shared class/AOT related flags independent, like: R = has been redefined, S = is shared class, s = static shared class, d = AOT dynamic cache ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29048#discussion_r2731461130 From mablakatov at openjdk.org Tue Jan 27 11:21:58 2026 From: mablakatov at openjdk.org (Mikhail Ablakatov) Date: Tue, 27 Jan 2026 11:21:58 GMT Subject: RFR: 8359359: AArch64: share trampolines between static calls to the same method [v9] In-Reply-To: References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com> Message-ID: On Tue, 25 Nov 2025 18:00:10 GMT, Mikhail Ablakatov wrote: >> Modify the C2 compiler to share trampoline stubs between static calls that resolve to the same callee method. Since the relocation target for all static calls is initially set to the static call resolver stub, the call's target alone cannot be used to distinguish between different static method calls. Instead, trampoline stubs should be shared based on the actual callee. >> >> The `SharedTrampolineTest.java` was designed to verify the sharing of trampolines among static calls. However, due to imprecise log analysis, the test currently passes even when trampolines are not shared. Additionally, comments within the test suggest ambiguity regarding whether it was intended to assess trampoline sharing for static calls or runtime calls. To address these issues and eliminate ambiguity, this patch renames and updates the existing test. Furthermore, a new test is introduced, using the existing one as a foundation, to accurately evaluate trampoline sharing for both static and runtime calls. >> >> This has passed tier1-3 and jcstress testing on AArch64. > > Mikhail Ablakatov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge commit '8bafc2f0aecbbe548573712a9dc31c9764f82f71' into 8359359 > - cleanup: make tests source code more readable > - Merge commit 'f6f87bb6759c86d941453a1776e8abfdffc48183' into 8359359 > - the only trampoline in ArrayCopyStub is never shared > - fixup: a shared trampoline must branch to a statically bound method > - share static call trampolines generated by C1 as well > - assert callee is nullptr for runtime calls > - assert that call sites offsets aren't missing > - cleanup: rephrase comments in macroAssembler_aarch64.hpp > - Merge commit 'fd29677479797956e0d205b5ce6e7cb9ad407bd1' into 8359359 > - ... and 10 more: https://git.openjdk.org/jdk/compare/8bafc2f0...bd065434 Looking for reviewers. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25954#issuecomment-3804587470 From azafari at openjdk.org Tue Jan 27 11:58:31 2026 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 27 Jan 2026 11:58:31 GMT Subject: RFR: 8358957: [ubsan]: The assert in layout_helper_boolean_diffbit() in klass.hpp needs UB to fail [v5] In-Reply-To: References: <2tqtSNmhY0bGDrqu06wBvUWw_bpdv311BSM-ij5EEGY=.90ef7eb5-8d88-439c-b0df-f917f3543cc2@github.com> Message-ID: On Fri, 7 Nov 2025 06:34:41 GMT, Kim Barrett wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> review comments applied > > I have no further comments or issues. Since it's still essentially the > implementation I proposed, I'll leave it to others to approve. Thank you @kimbarrett and @dean-long for your reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27288#issuecomment-3804770818 From azafari at openjdk.org Tue Jan 27 11:58:33 2026 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 27 Jan 2026 11:58:33 GMT Subject: Integrated: 8358957: [ubsan]: The assert in layout_helper_boolean_diffbit() in klass.hpp needs UB to fail In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 09:01:56 GMT, Afshin Zafari wrote: > Avoid using loop and UB in left-shift operation as suggested by Kim's comment in the JBS-issue. > > Tests: > mach5 tiers 1-5 {macosx-aarch64, linux-x64, windows-x64} x {debug, product} This pull request has now been integrated. Changeset: 5990165d Author: Afshin Zafari URL: https://git.openjdk.org/jdk/commit/5990165d8257f39595b4c38f4e3e8d6ebb3393e8 Stats: 13 lines in 1 file changed: 2 ins; 0 del; 11 mod 8358957: [ubsan]: The assert in layout_helper_boolean_diffbit() in klass.hpp needs UB to fail Reviewed-by: dlong, jsjolen ------------- PR: https://git.openjdk.org/jdk/pull/27288 From jbhateja at openjdk.org Tue Jan 27 12:30:31 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 27 Jan 2026 12:30:31 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v17] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 16:48:11 GMT, Paul Sandoz wrote: > The underlying motivation was to avoid passing two parameters to the vector intrinsics that can get out of sync. Currently, we cannot use `Float16.class` like we can `Integer.class` that describes the vector element type to the intrinsic. Could we use an internal class that acts as a proxy until we can replace it? Hi @PaulSandoz , We will still need to create T_FLOAT16 basic type and associate it with Float16 LaneType, why not directly pass these basic types to intrinsic entry point ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3804950143 From jpbempel at openjdk.org Tue Jan 27 12:41:50 2026 From: jpbempel at openjdk.org (Jean-Philippe Bempel) Date: Tue, 27 Jan 2026 12:41:50 GMT Subject: RFR: 8376185: NoSuchFieldError thrown after a record with type annotation retransformed Message-ID: ?retransformed Fix a retransform error when retransforming a record with type annotation. processing the record type annotation was done by calling the wrong method and using the one to process regular annotation. Regular annotations have not the same structure and decoding was therefore incorrect. The decoding methods detect a problem but this error was not propagated correctly outside of VM_RedfineClass::load_new_class_versions method, swallowing the error and leaving the retransformed class in bad state. Here we have fixed the call to the right method for decoding the type annotations but also propagated the error when rewriting the constant pool as an JVMTI_ERROR_INTERNAL ------------- Commit messages: - add missing files - 8376185: NoSuchFieldError thrown after a record with type annotation retransformed Changes: https://git.openjdk.org/jdk/pull/29445/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29445&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376185 Stats: 487 lines in 6 files changed: 485 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29445.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29445/head:pull/29445 PR: https://git.openjdk.org/jdk/pull/29445 From stuefe at openjdk.org Tue Jan 27 12:53:01 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 27 Jan 2026 12:53:01 GMT Subject: RFR: 8373096: JFR: Path-to-gc-roots search should be non-recursive Message-ID: This is a continuation - second attempt - of https://github.com/openjdk/jdk/pull/28659. ---- A customer reported a native stack overflow when producing a JFR recording with path-to-gc-roots=true. This happens regularly, see similar cases in JBS (e.g. https://bugs.openjdk.org/browse/JDK-8371630, https://bugs.openjdk.org/browse/JDK-8282427 etc). We limit the maximum graph search depth (DFSClosure::max_dfs_depth) to prevent stack overflows. That solution is brittle, however, since recursion depth is not a good proxy for thread stack usage: it depends on many factors, e.g., compiler inlining decisions and platform specifics. In this case, the VMThread's stack was too small. This patch rewrites the DFS heap tracer to be non-recursive. This is mostly textbook stuff, but the devil is in the details. Nevertheless, the algorithm should be a straightforward read. ### Memory usage of old vs new algorithm: The new algorithm uses, on average, a bit less memory than the old one. The old algorithm did cost ((avg stackframe size in bytes) * depth). As we have seen, e.g., in JDK-8371630, a depth of 3200 can max out ~1MB of stack space. The new algorithm costs ((avg number of outgoing refs per instanceKlass oop) * depth * 16. For a depth of 3200, we get typical probe stack sizes of 100KB..200KB. But we also cap probestack size, similar to how we cap the max. graph depth. In any case, these numbers are nothing to worry about. For a more in-depth explanation about memory cost, please see the comment in dfsClosure.cpp. ### Possible improvements/simplifications in the future: DFS works perfectly well alone now. It no longer depends on stack size, and its memory usage is typically smaller than BFS. IMHO, it would be perfectly fine to get rid of BFS and rely solely on the non-recursive DFS. The benefit would be a decrease in complexity and fewer tests to run and maintain. It should also be easy to convert into a parallelized version later. I kept the _max_dfs_depth_ parameter for now, but tbh it is no longer very useful. Before, it prevented stack overflows. Now, it is just an indirect way to limit probe stack size. But we also explicitly cap the probe stack size, so _max_dfs_depth_ is redundant. Removing it would require changing the statically allocated reference stack to be dynamically allocated, but that should not be difficult. ### Observable differences There is one observable side effect to the changed algorithm. The non-recursive algorithm processes oops and roots in reverse order. That means we may see different GC roots in JMC now compared to the recursive version of this algorithm. For example, for a static main class member: - One order of root processing may process the CLDG first; this causes the CLDs to be iterated, which iterates the Klass, which iterates the associated j.l.Class object. The reference stack starts at the j.l.Class object, and the root displayed in JMC says "ClassLoader". - Another root processing order may process the global handles first; this causes the AppClassLoader to be processed first, which causes the main class Mirror to be processed, and we also hit the static member, but now the root in JMC is displayed as "Global Object Handle: VM Global" I think that effect is benign - a root is a root. But, as a future improvement, I think displaying the first (or first n) objects of the reference stack would be very helpful to the analyst (possibly more so than just printing the roots). But maybe that feature exists already; I am no JMC expert. ## Testing - I ran extensive tests manually to make sure the resulting jfr files showed the same information (apart from the observable differences mentioned above). - I manually tested that we handle max_depth reached and probestack exhaustion gracefully - I added a new test to execute DFS-only on a very small stack size. Works fine (crashes with stock JVM). - I added a new test that exercises the new array chunking in the tracer - I made sure the patch fixes https://bugs.openjdk.org/browse/JDK-8371630 by running the TestWaste.java with a tiny stack size - crashes without patch, works with patch ------------- Commit messages: - fix after JDK-8375040 - tests - wip - revert unnecessary changes - wip - small stack test - tweaking DFS-BFS test - fix windows build warning - reduce diff - fix performance problem on bfs-dfs mixed mode - ... and 8 more: https://git.openjdk.org/jdk/compare/cba7d88c...5d79624b Changes: https://git.openjdk.org/jdk/pull/29382/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29382&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373096 Stats: 543 lines in 8 files changed: 502 ins; 8 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/29382.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29382/head:pull/29382 PR: https://git.openjdk.org/jdk/pull/29382 From stuefe at openjdk.org Tue Jan 27 12:53:02 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 27 Jan 2026 12:53:02 GMT Subject: RFR: 8373096: JFR: Path-to-gc-roots search should be non-recursive In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 10:18:05 GMT, Thomas Stuefe wrote: > This is a continuation - second attempt - of https://github.com/openjdk/jdk/pull/28659. > > ---- > > A customer reported a native stack overflow when producing a JFR recording with path-to-gc-roots=true. This happens regularly, see similar cases in JBS (e.g. https://bugs.openjdk.org/browse/JDK-8371630, https://bugs.openjdk.org/browse/JDK-8282427 etc). > > We limit the maximum graph search depth (DFSClosure::max_dfs_depth) to prevent stack overflows. That solution is brittle, however, since recursion depth is not a good proxy for thread stack usage: it depends on many factors, e.g., compiler inlining decisions and platform specifics. In this case, the VMThread's stack was too small. > > This patch rewrites the DFS heap tracer to be non-recursive. This is mostly textbook stuff, but the devil is in the details. Nevertheless, the algorithm should be a straightforward read. > > ### Memory usage of old vs new algorithm: > > The new algorithm uses, on average, a bit less memory than the old one. The old algorithm did cost ((avg stackframe size in bytes) * depth). As we have seen, e.g., in JDK-8371630, a depth of 3200 can max out ~1MB of stack space. > > The new algorithm costs ((avg number of outgoing refs per instanceKlass oop) * depth * 16. For a depth of 3200, we get typical probe stack sizes of 100KB..200KB. But we also cap probestack size, similar to how we cap the max. graph depth. > > In any case, these numbers are nothing to worry about. For a more in-depth explanation about memory cost, please see the comment in dfsClosure.cpp. > > ### Possible improvements/simplifications in the future: > > DFS works perfectly well alone now. It no longer depends on stack size, and its memory usage is typically smaller than BFS. IMHO, it would be perfectly fine to get rid of BFS and rely solely on the non-recursive DFS. The benefit would be a decrease in complexity and fewer tests to run and maintain. It should also be easy to convert into a parallelized version later. > > I kept the _max_dfs_depth_ parameter for now, but tbh it is no longer very useful. Before, it prevented stack overflows. Now, it is just an indirect way to limit probe stack size. But we also explicitly cap the probe stack size, so _max_dfs_depth_ is redundant. Removing it would require changing the statically allocated reference stack to be dynamically allocated, but that should not be difficult. > > ### Observable differences > > There is one observable side effect to the changed algorithm. The non-recursive algorithm processes oops a... Ping @roberttoyonaga , @egahlin ------------- PR Comment: https://git.openjdk.org/jdk/pull/29382#issuecomment-3805038334 From stuefe at openjdk.org Tue Jan 27 12:57:37 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 27 Jan 2026 12:57:37 GMT Subject: RFR: 8353564: Fail fatally if os::release_memory or os::uncommit_memory fails [v2] In-Reply-To: References: Message-ID: <5g0fw7IQG2PVrJUH3KBwgjzEDyZz0rIEO2QlJGpv6VQ=.090a0f2e-73c1-4c7b-a255-cd79ac781a5a@github.com> On Tue, 27 Jan 2026 07:33:33 GMT, David Holmes wrote: > > Can `remove_guard_pages` be a void method now? +1 ------------- PR Comment: https://git.openjdk.org/jdk/pull/29240#issuecomment-3805074075 From bmaillard at openjdk.org Tue Jan 27 14:08:16 2026 From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard) Date: Tue, 27 Jan 2026 14:08:16 GMT Subject: RFR: 8375038: C2: Enforce that Ideal() returns the root of the subgraph if any change was made by checking the node hash Message-ID: This PR introduces an assert in `PhaseIterGVN` to check that `Ideal` actually returns something if the node was modified. ## Context In the description of `Node::Ideal` in `node.cpp`, we have: > If ANY change is made, it must return the root of the reshaped graph - even if the root is the same Node It is crucial that such changes do not go unnoticed and that they can propagate to other nodes. Current documentation also states: > Running with `-XX:VerifyIterativeGVN=1` checks > these invariants, although its too slow to have on by default. If you are > hacking an Ideal call, be sure to test with `-XX:VerifyIterativeGVN=1` However, `-XX:VerifyIterativeGVN=1` ends up veryfing that the `_in` and `_out` arrays are consistent, but does not verify the return value. This PR aims to enforce the return value invariant. It should also make regression testing of bugs caused by wrongly returning nullptr in `Ideal` easier, such as [JDK-8373251](https://bugs.openjdk.org/browse/JDK-8373251). ## Proposed Change In summary, this PR brings the following set of changes - Add a new flag bit to`-XX:VerifyIterativeGVN` for verifying return of `Ideal` calls - Add an assert on the hash of nodes before and after `Ideal` in `PhaseIterGVN::transform_old` - Fix `Ideal` optimizations that would cause harness errors with testing on tier1 - Update the comments in the code to clarify the invariant and how to enforce it After consideration, I took the decision to only check the hash if the node is not dead. It seems there are many cases where the control node is dead, and we propagate the information to all users with `kill_dead_code`, and end up return `nullptr`. This is basically a mechanism to "speed up" the propagation (it would also happen normally via the usual IGVN worklist). This somehow contradicts the "must return the root of the reshaped graph" invariant, but it seems to be a common practice. In addition to that, I have decided to implement this as part of a new flag bit to `-XX:VerifyIterativeGVN` instead of an existing one, because there is a risk that it causes new failures in existing usages of the flag. This PR is meant to introduce the new check and fix the most "obvious" failures that the new flag would introduce in common scenarios, such as when running with `-version` on tier1. Since there are known issues caused by bad return values of `Ideal` (such as [JDK-8373251](https://bugs.openjdk.org/browse/JDK-8373251)), I will fix other failures in follow-up PRs. ### Testing - [x] [GitHub Actions](https://github.com/benoitmaillard/jdk/actions?query=branch%3AJDK-8375038) - [x] tier1-3, plus some internal testing - [x] Make sure we don't get any harness failure with the new flag bit for tier1 Thank you for reviewing! ------------- Commit messages: - Update copyright years - Update copyright year to 2026 in cfgnode.cpp - Update copyright year in c2_globals.hpp - Update documentation for Node::Ideal - Check hash before and after Ideal call and fix phinode Changes: https://git.openjdk.org/jdk/pull/29421/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29421&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375038 Stats: 37 lines in 6 files changed: 23 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/29421.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29421/head:pull/29421 PR: https://git.openjdk.org/jdk/pull/29421 From rcastanedalo at openjdk.org Tue Jan 27 14:25:56 2026 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Tue, 27 Jan 2026 14:25:56 GMT Subject: RFR: 8375038: C2: Enforce that Ideal() returns the root of the subgraph if any change was made by checking the node hash In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 14:47:58 GMT, Beno?t Maillard wrote: > This PR introduces an assert in `PhaseIterGVN` to check that `Ideal` actually returns something if the node was modified. > > ## Context > > In the description of `Node::Ideal` in `node.cpp`, we have: > >> If ANY change is made, it must return the root of the reshaped graph - even if the root is the same Node > > It is crucial that such changes do not go unnoticed and that they can propagate to other nodes. Current documentation also states: > >> Running with `-XX:VerifyIterativeGVN=1` checks >> these invariants, although its too slow to have on by default. If you are >> hacking an Ideal call, be sure to test with `-XX:VerifyIterativeGVN=1` > > However, `-XX:VerifyIterativeGVN=1` ends up veryfing that the `_in` and `_out` arrays are consistent, but does not verify the return value. > > This PR aims to enforce the return value invariant. It should also make regression testing of bugs caused by wrongly returning nullptr in `Ideal` easier, such as [JDK-8373251](https://bugs.openjdk.org/browse/JDK-8373251). > > ## Proposed Change > > In summary, this PR brings the following set of changes > - Add a new flag bit to`-XX:VerifyIterativeGVN` for verifying return of `Ideal` calls > - Add an assert on the hash of nodes before and after `Ideal` in `PhaseIterGVN::transform_old` > - Fix `Ideal` optimizations that would cause harness errors with testing on tier1 > - Update the comments in the code to clarify the invariant and how to enforce it > > After consideration, I took the decision to only check the hash if the node is not dead. It seems there are many cases where the control node is dead, and we propagate the information to all users with `kill_dead_code`, and end up return `nullptr`. This is basically a mechanism to "speed up" the propagation (it would also happen normally via the usual IGVN worklist). This somehow contradicts the "must return the root of the reshaped graph" invariant, but it seems to be a common practice. > > In addition to that, I have decided to implement this as part of a new flag bit to `-XX:VerifyIterativeGVN` instead of an existing one, because there is a risk that it causes new failures in existing usages of the flag. > > This PR is meant to introduce the new check and fix the most "obvious" failures that the new flag would introduce in common scenarios, such as when running with `-version` on tier1. Since there are known issues caused by bad return values of `Ideal` (such as [JDK-8373251](https://bugs.openjdk.org/browse/JDK-8373251)), I will fix other failures in follow-up PRs.... src/hotspot/share/opto/node.cpp line 1157: > 1155: // can help with validating these invariants, although they are too slow to have on by default: > 1156: // - '-XX:VerifyIterativeGVN=1' checks the def-use info > 1157: // - '-XX:VerifyIterativeGVN=100000' cheks the return value Suggestion: // - '-XX:VerifyIterativeGVN=100000' checks the return value ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29421#discussion_r2732251370 From liach at openjdk.org Tue Jan 27 14:40:17 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 27 Jan 2026 14:40:17 GMT Subject: RFR: 8376185: NoSuchFieldError thrown after a record with type annotation retransformed In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 10:48:41 GMT, Jean-Philippe Bempel wrote: > ?retransformed > > Fix a retransform error when retransforming a record with type annotation. processing the record type annotation was done by calling the wrong method and using the one to process regular annotation. Regular annotations have not the same structure and decoding was therefore incorrect. The decoding methods detect a problem but this error was not propagated correctly outside of VM_RedfineClass::load_new_class_versions method, swallowing the error and leaving the retransformed class in bad state. > > Here we have fixed the call to the right method for decoding the type annotations but also propagated the error when rewriting the constant pool as an JVMTI_ERROR_INTERNAL Please add a copyright header for your affliation for the new files (.java, .jcod, .sh) that you add, or fallback to an Oracle copyright header. See https://openjdk.org/guide/#copyright-headers ------------- PR Comment: https://git.openjdk.org/jdk/pull/29445#issuecomment-3805583503 From jpbempel at openjdk.org Tue Jan 27 14:56:31 2026 From: jpbempel at openjdk.org (Jean-Philippe Bempel) Date: Tue, 27 Jan 2026 14:56:31 GMT Subject: RFR: 8376185: NoSuchFieldError thrown after a record with type annotation retransformed [v2] In-Reply-To: References: Message-ID: > ?retransformed > > Fix a retransform error when retransforming a record with type annotation. processing the record type annotation was done by calling the wrong method and using the one to process regular annotation. Regular annotations have not the same structure and decoding was therefore incorrect. The decoding methods detect a problem but this error was not propagated correctly outside of VM_RedfineClass::load_new_class_versions method, swallowing the error and leaving the retransformed class in bad state. > > Here we have fixed the call to the right method for decoding the type annotations but also propagated the error when rewriting the constant pool as an JVMTI_ERROR_INTERNAL Jean-Philippe Bempel has updated the pull request incrementally with one additional commit since the last revision: add copyright headers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29445/files - new: https://git.openjdk.org/jdk/pull/29445/files/33f92068..725f4edb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29445&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29445&range=00-01 Stats: 93 lines in 4 files changed: 93 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29445.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29445/head:pull/29445 PR: https://git.openjdk.org/jdk/pull/29445 From dfenacci at openjdk.org Tue Jan 27 16:22:52 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Tue, 27 Jan 2026 16:22:52 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v2] In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: > ## Issue > > This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. > > This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. > > ## Causes > > The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. > > ## Fix > > A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: > https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 > This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. > > # Testing > > * Tier 1-3+ > * 2 JTReg tests added > * `TestRangeCheck.java` as regression test for the reported issue > * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion Damon Fenacci has updated the pull request incrementally with two additional commits since the last revision: - JDK-8374852: fix macro expansion for OpaqueCheck - JDK-8374852: use only one opaque node ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29164/files - new: https://git.openjdk.org/jdk/pull/29164/files/ff228576..b79738c3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=00-01 Stats: 95 lines in 15 files changed: 11 ins; 42 del; 42 mod Patch: https://git.openjdk.org/jdk/pull/29164.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29164/head:pull/29164 PR: https://git.openjdk.org/jdk/pull/29164 From dfenacci at openjdk.org Tue Jan 27 16:22:52 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Tue, 27 Jan 2026 16:22:52 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v2] In-Reply-To: References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com> Message-ID: On Tue, 27 Jan 2026 09:24:34 GMT, Christian Hagedorn wrote: >> Fair enough ? I was just curious. > > I was about to ask the same question. It seems like both `OpaqueNotNullNode` and `OpaqueGuardNode` behave the same apart from eventually folding to a false or true constant. They might have slightly different reasons for adding them but AFAIU, they are both intended to keep control and data in sync. Apart from duplicating most of the logic and comments, an additional challenge with having both nodes is that we need to special case both nodes at various points in the code which makes it more complex and raises the question if we could really observe them both or not (would not be a problem when only having one node type). Thanks for reviewing @chhagedorn. > special case both nodes at various points Good point. I guess better have only one after all. Changed. (I called it `OpaqueCheck` for lack of a better idea) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2732811990 From dfenacci at openjdk.org Tue Jan 27 16:26:19 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Tue, 27 Jan 2026 16:26:19 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v3] In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: > ## Issue > > This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. > > This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. > > ## Causes > > The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. > > ## Fix > > A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: > https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 > This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. > > # Testing > > * Tier 1-3+ > * 2 JTReg tests added > * `TestRangeCheck.java` as regression test for the reported issue > * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision: JDK-8374852: fix star layout Co-authored-by: Christian Hagedorn ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29164/files - new: https://git.openjdk.org/jdk/pull/29164/files/b79738c3..0ef73ef9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29164.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29164/head:pull/29164 PR: https://git.openjdk.org/jdk/pull/29164 From duke at openjdk.org Tue Jan 27 17:00:03 2026 From: duke at openjdk.org (duke) Date: Tue, 27 Jan 2026 17:00:03 GMT Subject: RFR: 8374513: AArch64: Improve receiver type profiling reliability [v2] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 00:56:42 GMT, Chad Rakoczy wrote: >> [JDK-8374513](https://bugs.openjdk.org/browse/JDK-8374513) is the AArch64 port of [JDK-8357258](https://bugs.openjdk.org/browse/JDK-8357258). See the bug report for more detailed information. >> >> This PR executes the plan outlined in the bug: >> - Common the receiver type profiling code in interpreter and C1 >> - Rewrite receiver type profiling code to only do atomic receiver slot installations >> - 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. >> >> Functional Testing: Linux AArch64 fastdebug Tier1-4 >> >> Performance Testing (to show there is no performance regression): >> >> # Baseline >> Benchmark (randomized) Mode Cnt Score Error Units >> InterfaceCalls.test1stInt2Types false avgt 12 1.940 ? 0.002 ns/op >> InterfaceCalls.test1stInt2Types true avgt 12 7.714 ? 0.011 ns/op >> InterfaceCalls.test1stInt3Types false avgt 12 6.747 ? 0.066 ns/op >> InterfaceCalls.test1stInt3Types true avgt 12 18.733 ? 0.175 ns/op >> InterfaceCalls.test1stInt5Types false avgt 12 6.690 ? 0.083 ns/op >> InterfaceCalls.test1stInt5Types true avgt 12 21.299 ? 0.016 ns/op >> InterfaceCalls.test2ndInt2Types false avgt 12 1.997 ? 0.004 ns/op >> InterfaceCalls.test2ndInt2Types true avgt 12 8.027 ? 0.016 ns/op >> InterfaceCalls.test2ndInt3Types false avgt 12 7.915 ? 0.114 ns/op >> InterfaceCalls.test2ndInt3Types true avgt 12 16.988 ? 0.065 ns/op >> InterfaceCalls.test2ndInt5Types false avgt 12 9.422 ? 0.017 ns/op >> InterfaceCalls.test2ndInt5Types true avgt 12 22.736 ? 0.022 ns/op >> InterfaceCalls.testIfaceCall false avgt 12 5.860 ? 0.046 ns/op >> InterfaceCalls.testIfaceCall true avgt 12 5.794 ? 0.026 ns/op >> InterfaceCalls.testIfaceExtCall false avgt 12 6.310 ? 0.067 ns/op >> InterfaceCalls.testIfaceExtCall true avgt 12 6.239 ? 0.017 ns/op >> InterfaceCalls.testMonomorphic false avgt 12 1.146 ? 0.034 ns/op >> InterfaceCalls.testMonomorphic true avgt 12 1.131 ? 0.012 ns/op >> >> # With PR >> Benchmark (randomized) Mode Cnt Score Error Units >> InterfaceCalls.test1stInt2Type... > > Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision: > > Use increment macro @chadrako Your change (at version 555e0afa58ba9bf90dc6200e9555439ffdc8e186) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29283#issuecomment-3806347575 From shade at openjdk.org Tue Jan 27 17:10:18 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 27 Jan 2026 17:10:18 GMT Subject: RFR: 8376472: Shenandoah: Assembler store barriers read destination memory despite the decorators Message-ID: The issue is really a correctness issue, and it readily manifests in Valhalla, which sometimes does the stores with `IS_DEST_UNINITIALIZED` set. Unfortunately, Shenandoah SATB barriers ignore this attribute, and attempt to read the memory at store address. At best it crashes the VM with the "oopness" asserts, at worst it feeds "garbage" pointers into SATB machinery, which then wrecks havoc on everything else. We need to make sure store barriers are consistently checking these attributes. Unfortunately, that would mean doing the changes in arch-specific assembler code. This PR makes sure the ShenandoahBarrierSetAssembler store barriers are roughly in the same shape, and that they consult `ShenandoahBarrierSet::need_*_barrier` to make the proper decisions whether to use SATB/card barriers. `hotspot_gc_shenandoah` is enough to sanity-check this patch, but I am also running `all` tests for extra safety. Additional testing: - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah` - [x] Linux x86_64 server fastdebug, `all` + `-XX:+UseShenandoahGC` - [x] Linux AArch64 server fastdebug, `all` + `-XX:+UseShenandoahGC` - [x] Linux {PPC64, RISC-V, S390X} server fastdebug, cross-compilation ------------- Commit messages: - More polish - RISC-V version - More touchups, AArch64 version - Store barrier cleanup Changes: https://git.openjdk.org/jdk/pull/29444/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29444&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376472 Stats: 269 lines in 10 files changed: 47 ins; 61 del; 161 mod Patch: https://git.openjdk.org/jdk/pull/29444.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29444/head:pull/29444 PR: https://git.openjdk.org/jdk/pull/29444 From tschatzl at openjdk.org Tue Jan 27 17:55:08 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 27 Jan 2026 17:55:08 GMT Subject: RFR: 8376357: Parallel: Convert MutableSpace classes to use Atomic Message-ID: Hi all, please review these changes that convert `MutableSpace` classes to use `Atomic`. Testing: gha, tier1-5 Thanks, Thomas ------------- Commit messages: - 8376357 Changes: https://git.openjdk.org/jdk/pull/29427/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29427&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376357 Stats: 31 lines in 5 files changed: 4 ins; 8 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/29427.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29427/head:pull/29427 PR: https://git.openjdk.org/jdk/pull/29427 From psandoz at openjdk.org Tue Jan 27 18:28:32 2026 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 27 Jan 2026 18:28:32 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v17] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 12:27:46 GMT, Jatin Bhateja wrote: > We will still need to create T_FLOAT16 basic type and associate it with Float16 LaneType, why not directly pass these basic types to intrinsic entry point ? The strong feedback from HotSpot folks, which i agree with, is adding a new enum value to `BasicType` is not the way to go - it is too disruptive and does not scale. Sorry if i misled you earlier on, it was my intention in feedback to propose something that was limited in scope to vector support. The thought about a proxy class was motivated by a question i had - what would we do if `Float16.class` was already present in `java.base`? and answers to that might motivate what we do now in preparation for when that happens. Regardless i think we need to separate out the Vector API's direct dependence on BasicType and its values. Instead we should define our own constants for the vector element types, and provide mapping of those to BasicType values which might result in "erasure" to the carrier type. We should adjust/adapt LaneType accordingly. Does that make sense to you? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3806791602 From lkorinth at openjdk.org Tue Jan 27 18:42:51 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 27 Jan 2026 18:42:51 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v8] In-Reply-To: References: Message-ID: > This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. > > It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. > > This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. > > I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: - Revert "Stefan J 4" This reverts commit 203d11979524126add9ee5d04174bde07a5a3f5a. - Revert "remove commented out code" This reverts commit 9d9df671574be7a15a30ef0af452629330cb4fd1. - Merge branch 'master' into _8367993 - Merge branch '_master_jdk' into _8367993 - Merge branch '_8373253' into _8367993 - rename of method - Proposal by Stefan J - wip - Revert "8373253: Re-work InjectGCWorkerCreationFailure for future changes" This reverts commit d45ea8817ab2303b2decd8cbb2cd1bf5280aa181. - Revert "Fixup after comment from Ivan." This reverts commit 2aa8aa4b68027b62a8d4be1b86720fadfa48dda5. - ... and 11 more: https://git.openjdk.org/jdk/compare/90b54692...c5a7e2bb ------------- Changes: https://git.openjdk.org/jdk/pull/28723/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28723&range=07 Stats: 56 lines in 10 files changed: 29 ins; 6 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/28723.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28723/head:pull/28723 PR: https://git.openjdk.org/jdk/pull/28723 From lkorinth at openjdk.org Tue Jan 27 18:49:50 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 27 Jan 2026 18:49:50 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v8] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 18:42:51 GMT, Leo Korinth wrote: >> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. >> >> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. >> >> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. >> >> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. > > Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: > > - Revert "Stefan J 4" > > This reverts commit 203d11979524126add9ee5d04174bde07a5a3f5a. > - Revert "remove commented out code" > > This reverts commit 9d9df671574be7a15a30ef0af452629330cb4fd1. > - Merge branch 'master' into _8367993 > - Merge branch '_master_jdk' into _8367993 > - Merge branch '_8373253' into _8367993 > - rename of method > - Proposal by Stefan J > - wip > - Revert "8373253: Re-work InjectGCWorkerCreationFailure for future changes" > > This reverts commit d45ea8817ab2303b2decd8cbb2cd1bf5280aa181. > - Revert "Fixup after comment from Ivan." > > This reverts commit 2aa8aa4b68027b62a8d4be1b86720fadfa48dda5. > - ... and 11 more: https://git.openjdk.org/jdk/compare/90b54692...c5a7e2bb I think the current state is okay, sorry for the messy history (the last two commits was pushed by mistake, now reverted). Rerunning tier 1 - 5, they are not through yet. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28723#issuecomment-3806877202 From lmesnik at openjdk.org Tue Jan 27 18:59:36 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 27 Jan 2026 18:59:36 GMT Subject: RFR: 8373367: interp-only mechanism fails to work for carrier threads in a corner case In-Reply-To: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com> References: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com> Message-ID: <_0tOPRnuKQWXGAb9CON1DJ_Wj0-3JIKF8WaFHOQxcbM=.18c2c63f-5313-454f-8ee3-8a13d6be1fc2@github.com> On Tue, 27 Jan 2026 01:48:03 GMT, Serguei Spitsyn wrote: > The `interp-only` mechanism is based on the `JavaThread` objects. Carrier and virtual threads can temporary share the same `JavaThread`. The `java_thread->jvmti_thread_state()` is re-linked to a virtual thread at `mount` and to the carrier thread at `unmount`. The `JvmtiThreadState` has a back link to the `JavaThread` which is also set for virtual thread at a `mount` and carrier thread at an `unmount`. Just one of these two links at the same time is set to the `JavaThread`, the other one has to be set to `nullptr`. The `interp-only` mechanism needs this invariant. > However, there is a corner case when this invariant is broken. It happens when the `JvmtiThreadState` for carrier thread has just been created. In such case, the link to `JavaThread` is always `non-nullptr` even though a virtual thread is currently mounted on a carrier thread. This simple update fixes the issue in the `JvmtiThreadState` ctor. > > Testing: > - TBD: Mach5 tiers 1-6 src/hotspot/share/prims/jvmtiThreadState.cpp line 127: > 125: thread->set_interp_only_mode(false); > 126: } > 127: if (JvmtiEnvBase::is_thread_carrying_vthread(thread, thread_oop)) { wouldn't be better to move this into the beginning of ctor: if(!JvmtiEnvBase::is_thread_carrying_vthread(thread, thread_oop)) { _thread = thread; _thread_saved = nullptr; } else { _thread_saved = thread; _thread = nullptr; } and might be add comments with explanation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29436#discussion_r2733381607 From missa at openjdk.org Tue Jan 27 19:02:44 2026 From: missa at openjdk.org (Mohamed Issa) Date: Tue, 27 Jan 2026 19:02:44 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v9] In-Reply-To: References: Message-ID: > Intel® 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: Add double precision test to CMoveLConstants.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28337/files - new: https://git.openjdk.org/jdk/pull/28337/files/09d1e44d..0058e3e8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28337&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28337&range=07-08 Stats: 15 lines in 1 file changed: 14 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 missa at openjdk.org Tue Jan 27 19:14:31 2026 From: missa at openjdk.org (Mohamed Issa) Date: Tue, 27 Jan 2026 19:14:31 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v8] In-Reply-To: <4nlYmoQuUt0GFqk84hZN3YcEjBo1K8fEVZeUUOuN8Qs=.11d29fdf-18df-4c25-be12-146e7954812a@github.com> References: <4nlYmoQuUt0GFqk84hZN3YcEjBo1K8fEVZeUUOuN8Qs=.11d29fdf-18df-4c25-be12-146e7954812a@github.com> Message-ID: On Tue, 27 Jan 2026 07:57:03 GMT, Emanuel Peter wrote: >> Mohamed Issa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: >> >> - Merge branch 'master' into user/missa-prime/avx10_2 >> - Merge branch 'master' into user/missa-prime/avx10_2 >> - Change function names and extend IR encoding rules for CMove tests >> - Merge remote-tracking branch 'origin/master' into user/missa-prime/avx10_2 >> - Remove unnecessary CMOV blocks and adjust predicates involving APX and AVX10.2 >> - Remove extra jump instruction in signum floating point and unify three-way floating point comparison logic in x86.ad >> - Also update copyright year in IREncodingPrinter.java >> - Include apx_f in list of verified CPU features for IR encoding >> - Fix CMove IR tests to account for APX presence >> - Merge branch 'master' into user/missa-prime/avx10_2 >> - ... and 15 more: https://git.openjdk.org/jdk/compare/44b74e16...09d1e44d > > test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java line 65: > >> 63: applyIfPlatform = {"x64", "true"}, >> 64: applyIfCPUFeatureAnd = {"apx_f", "true", "avx10_2", "true"}, >> 65: phase = CompilePhase.FINAL_CODE) > > These are all `CMove` cases. I see you added branch/call cases in the benchmark. Would it make sense to have some similar cases here? > > And: this here is a test for `float`. Where do we cover `double`, which you are also making VM changes for? Unlike CMove, the branch/call cases don't have special definitions in the `x86.ad` file for constants. The jump instructions behave the same way for all value types because they only check the register flags. So, I think the branch tests in `TestFPComparison.java` are sufficient since they cover the comparison instructions as well. As for double precision, I just added a test mirroring the single precision one. Thanks for noting that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2733456586 From kevinw at openjdk.org Tue Jan 27 19:14:33 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 27 Jan 2026 19:14:33 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v10] In-Reply-To: References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: On Wed, 21 Jan 2026 18:48:45 GMT, Larry Cable 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: fixed initialization bug in AOT cache sharing summary code Ah ok thanks Larry - we always may show 'S', but I missed the _location check before printing s and d. It surprises me that the flags that can be printed are dependent on the -location flag. As we only show _aot_static and dynamics if _location is set, I guess I expected one if (_location) check before the AOTMetaspace::in_aot_cache_static_region and (AOTMetaspace::in_aot_cache_dynamic_region checks. The "-location" help is: "Print class file (and AOT cache) location url (if available)" ..but it's more than that, it affects what flags we might print as well. Is it simpler to just show the flags always? Actually, we already have a problem that the "Some classes are annotated with flags.." text is part of the "-verbose" flag description, but that is wrong. It should be in the description() method in the .hpp file? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29048#issuecomment-3807013254 From duke at openjdk.org Tue Jan 27 20:03:15 2026 From: duke at openjdk.org (Robert Toyonaga) Date: Tue, 27 Jan 2026 20:03:15 GMT Subject: RFR: 8373096: JFR: Path-to-gc-roots search should be non-recursive In-Reply-To: References: Message-ID: <9F7u-mBUQGEfA8o6PGa9XtHd0wa8ie6jBD444Hq2L5M=.701a8395-fc36-4cbc-b514-a589b93ceb14@github.com> On Fri, 23 Jan 2026 10:18:05 GMT, Thomas Stuefe wrote: > This is a continuation - second attempt - of https://github.com/openjdk/jdk/pull/28659. > > ---- > > A customer reported a native stack overflow when producing a JFR recording with path-to-gc-roots=true. This happens regularly, see similar cases in JBS (e.g. https://bugs.openjdk.org/browse/JDK-8371630, https://bugs.openjdk.org/browse/JDK-8282427 etc). > > We limit the maximum graph search depth (DFSClosure::max_dfs_depth) to prevent stack overflows. That solution is brittle, however, since recursion depth is not a good proxy for thread stack usage: it depends on many factors, e.g., compiler inlining decisions and platform specifics. In this case, the VMThread's stack was too small. > > This patch rewrites the DFS heap tracer to be non-recursive. This is mostly textbook stuff, but the devil is in the details. Nevertheless, the algorithm should be a straightforward read. > > ### Memory usage of old vs new algorithm: > > The new algorithm uses, on average, a bit less memory than the old one. The old algorithm did cost ((avg stackframe size in bytes) * depth). As we have seen, e.g., in JDK-8371630, a depth of 3200 can max out ~1MB of stack space. > > The new algorithm costs ((avg number of outgoing refs per instanceKlass oop) * depth * 16. For a depth of 3200, we get typical probe stack sizes of 100KB..200KB. But we also cap probestack size, similar to how we cap the max. graph depth. > > In any case, these numbers are nothing to worry about. For a more in-depth explanation about memory cost, please see the comment in dfsClosure.cpp. > > ### Possible improvements/simplifications in the future: > > DFS works perfectly well alone now. It no longer depends on stack size, and its memory usage is typically smaller than BFS. IMHO, it would be perfectly fine to get rid of BFS and rely solely on the non-recursive DFS. The benefit would be a decrease in complexity and fewer tests to run and maintain. It should also be easy to convert into a parallelized version later. > > I kept the _max_dfs_depth_ parameter for now, but tbh it is no longer very useful. Before, it prevented stack overflows. Now, it is just an indirect way to limit probe stack size. But we also explicitly cap the probe stack size, so _max_dfs_depth_ is redundant. Removing it would require changing the statically allocated reference stack to be dynamically allocated, but that should not be difficult. > > ### Observable differences > > There is one observable side effect to the changed algorithm. The non-recursive algorithm processes oops a... This looks good to me! And it fixes the [problem we talked about earlier](https://github.com/openjdk/jdk/pull/28659#discussion_r2632525732). I have left one minor comment below. src/hotspot/share/jfr/leakprofiler/chains/dfsClosure.cpp line 217: > 215: _current_pointee = _current_ref.dereference(); > 216: > 217: _num_objects_processed++; For large arrays that have many chunks, each chunk will count as another "object" processed. Is this okay? ------------- Marked as reviewed by roberttoyonaga at github.com (no known OpenJDK username). PR Review: https://git.openjdk.org/jdk/pull/29382#pullrequestreview-3712943595 PR Review Comment: https://git.openjdk.org/jdk/pull/29382#discussion_r2733410597 From duke at openjdk.org Tue Jan 27 20:06:02 2026 From: duke at openjdk.org (Robert Toyonaga) Date: Tue, 27 Jan 2026 20:06:02 GMT Subject: RFR: 8373096: JFR: Path-to-gc-roots search should be non-recursive In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 10:18:05 GMT, Thomas Stuefe wrote: > This is a continuation - second attempt - of https://github.com/openjdk/jdk/pull/28659. > > ---- > > A customer reported a native stack overflow when producing a JFR recording with path-to-gc-roots=true. This happens regularly, see similar cases in JBS (e.g. https://bugs.openjdk.org/browse/JDK-8371630, https://bugs.openjdk.org/browse/JDK-8282427 etc). > > We limit the maximum graph search depth (DFSClosure::max_dfs_depth) to prevent stack overflows. That solution is brittle, however, since recursion depth is not a good proxy for thread stack usage: it depends on many factors, e.g., compiler inlining decisions and platform specifics. In this case, the VMThread's stack was too small. > > This patch rewrites the DFS heap tracer to be non-recursive. This is mostly textbook stuff, but the devil is in the details. Nevertheless, the algorithm should be a straightforward read. > > ### Memory usage of old vs new algorithm: > > The new algorithm uses, on average, a bit less memory than the old one. The old algorithm did cost ((avg stackframe size in bytes) * depth). As we have seen, e.g., in JDK-8371630, a depth of 3200 can max out ~1MB of stack space. > > The new algorithm costs ((avg number of outgoing refs per instanceKlass oop) * depth * 16. For a depth of 3200, we get typical probe stack sizes of 100KB..200KB. But we also cap probestack size, similar to how we cap the max. graph depth. > > In any case, these numbers are nothing to worry about. For a more in-depth explanation about memory cost, please see the comment in dfsClosure.cpp. > > ### Possible improvements/simplifications in the future: > > DFS works perfectly well alone now. It no longer depends on stack size, and its memory usage is typically smaller than BFS. IMHO, it would be perfectly fine to get rid of BFS and rely solely on the non-recursive DFS. The benefit would be a decrease in complexity and fewer tests to run and maintain. It should also be easy to convert into a parallelized version later. > > I kept the _max_dfs_depth_ parameter for now, but tbh it is no longer very useful. Before, it prevented stack overflows. Now, it is just an indirect way to limit probe stack size. But we also explicitly cap the probe stack size, so _max_dfs_depth_ is redundant. Removing it would require changing the statically allocated reference stack to be dynamically allocated, but that should not be difficult. > > ### Observable differences > > There is one observable side effect to the changed algorithm. The non-recursive algorithm processes oops a... src/hotspot/share/jfr/leakprofiler/chains/dfsClosure.cpp line 125: > 123: // smaller. Not a problem at all. > 124: // > 125: // But we could run into weird pathological object graphs. Therfore we also Suggestion: // But we could run into weird pathological object graphs. Therefore we also ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29382#discussion_r2733627437 From duke at openjdk.org Tue Jan 27 20:39:14 2026 From: duke at openjdk.org (Larry Cable) Date: Tue, 27 Jan 2026 20:39:14 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v11] In-Reply-To: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: > 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: changes as per @kwalls last comments, improved help and optimized -location option checking ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29048/files - new: https://git.openjdk.org/jdk/pull/29048/files/341643a2..f2198458 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=09-10 Stats: 17 lines in 2 files changed: 2 ins; 0 del; 15 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 xpeng at openjdk.org Tue Jan 27 21:08:26 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 27 Jan 2026 21:08:26 GMT Subject: RFR: 8373266: Strengthen constant CardTable base accesses [v5] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 16:47:43 GMT, Aleksey Shipilev 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 > > Aleksey Shipilev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > Some polishing Thanks for generalize the safety mechanism. Looks good to me, and it is a nice PR to read. ------------- Marked as reviewed by xpeng (Committer). PR Review: https://git.openjdk.org/jdk/pull/28703#pullrequestreview-3713454244 From sviswanathan at openjdk.org Tue Jan 27 22:04:13 2026 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 27 Jan 2026 22:04:13 GMT Subject: RFR: 8374744: Enable dumping of APX EGPRs =?UTF-8?B?KFIxNuKAk1IzMSk=?= in JVM fatal error logs In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 20:28:14 GMT, Srinivas Vamsi Parasa wrote: > 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. src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp line 449: > 447: // Dump APX EGPRs (R16-R31) > 448: apx_state* apx = get_apx_state(uc); > 449: if (UseAPX && apx != nullptr) { This could be done as: apx_state* apx = UseAPX ? get_apx_state(uc) : nullptr; if (apx != nullptr) { src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp line 469: > 467: st->print(", R30=" INTPTR_FORMAT, (intptr_t)apx->regs[14]); > 468: st->print(", R31=" INTPTR_FORMAT, (intptr_t)apx->regs[15]); > 469: st->cr(); This could be done with a for loop. src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp line 556: > 554: CASE_PRINT_REG_APX(30, "R30=", 14); break; > 555: CASE_PRINT_REG_APX(31, "R31=", 15); break; > 556: } Don't need a switch case here. Could be achieved with something like below: st->print("R%d=", n); print_location(st, apx->regs[n]); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29098#discussion_r2700175735 PR Review Comment: https://git.openjdk.org/jdk/pull/29098#discussion_r2733973731 PR Review Comment: https://git.openjdk.org/jdk/pull/29098#discussion_r2733989504 From duke at openjdk.org Tue Jan 27 22:14:33 2026 From: duke at openjdk.org (Larry Cable) Date: Tue, 27 Jan 2026 22:14:33 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v12] In-Reply-To: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: > 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 VM.classes description as per previous changes to -help text ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29048/files - new: https://git.openjdk.org/jdk/pull/29048/files/f2198458..4b1bb228 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=10-11 Stats: 6 lines in 1 file changed: 3 ins; 1 del; 2 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 27 22:27:37 2026 From: duke at openjdk.org (Robert Toyonaga) Date: Tue, 27 Jan 2026 22:27:37 GMT Subject: RFR: 8353564: Fail fatally if os::release_memory or os::uncommit_memory fails [v4] In-Reply-To: References: Message-ID: > This PR is a follow up to JDK-8341491. See original discussion: https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700 > > This PR makes `os::release_memory`, `os::uncommit_memory`, `os::release_memory_special`, and `os::unmap_memory` fail fatally if they encounter an error. These methods require obtaining the NMT lock. Fatally failing in these places would potentially allow for the tightening of NMT virtual memory locking scopes (future work, if this PR is accepted). Already in most cases, the callers fail fatally or assert(false) when these os:: methods fail. Another reason to fatally fail is that if the OS memory operation fails, it can be difficult to know for sure what state the OS left the memory in and recover. > > `release_memory`/`uncommit_memory`/`release_memory_special`/`unmap_memory` can fail due to ? Bad arguments, or ? The OS encountered an issue out of control of the JVM. > > ? > If there is a JVM bug, it's probably reasonable to fatally fail here. Or the caller could be intentionally passing arguments that may or may not be valid. I don't think there is any code like that currently, and this is probably a bad pattern to be following anyway. > > ? > In platform dependent code: > With regard to mmap/munmap, the only errors that aren't due to bad arguments are ENOMEM and ones related to file descriptors (which are not applicable to uncommit or release). > On Windows, VirtualFree only fails due to bad arguments. > On AIX, shmdt and disclaim64 only fail due to bad arguments. msync could spontaneously fail with EIO: "An I/O error occurred while reading from or writing to the file system." > On BSD, it seems like mprotect and madvise fail only due to bad arguments or invalid privileges. > > In the [original discussion](https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700), the main question was whether ENOMEM upon os::uncommit_memory was recoverable. This may be possible if we uncommit the middle of a region - splitting it in two. This could exceed the limit of the number of mappings resulting in ENOMEM. > > If none of the scenarios in ? are recoverable, then perhaps fatally failing is OK. > > Testing: > - Tier 1. > - Manual testing to make sure we fatally fail and the correct messages are printed. Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision: make remove_stack_guard_pages return void ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29240/files - new: https://git.openjdk.org/jdk/pull/29240/files/2c7116ea..21e0a63e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29240&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29240&range=02-03 Stats: 21 lines in 6 files changed: 3 ins; 10 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/29240.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29240/head:pull/29240 PR: https://git.openjdk.org/jdk/pull/29240 From duke at openjdk.org Tue Jan 27 22:32:48 2026 From: duke at openjdk.org (Robert Toyonaga) Date: Tue, 27 Jan 2026 22:32:48 GMT Subject: RFR: 8353564: Fail fatally if os::release_memory or os::uncommit_memory fails [v4] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 22:27:37 GMT, Robert Toyonaga wrote: >> This PR is a follow up to JDK-8341491. See original discussion: https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700 >> >> This PR makes `os::release_memory`, `os::uncommit_memory`, `os::release_memory_special`, and `os::unmap_memory` fail fatally if they encounter an error. These methods require obtaining the NMT lock. Fatally failing in these places would potentially allow for the tightening of NMT virtual memory locking scopes (future work, if this PR is accepted). Already in most cases, the callers fail fatally or assert(false) when these os:: methods fail. Another reason to fatally fail is that if the OS memory operation fails, it can be difficult to know for sure what state the OS left the memory in and recover. >> >> `release_memory`/`uncommit_memory`/`release_memory_special`/`unmap_memory` can fail due to ? Bad arguments, or ? The OS encountered an issue out of control of the JVM. >> >> ? >> If there is a JVM bug, it's probably reasonable to fatally fail here. Or the caller could be intentionally passing arguments that may or may not be valid. I don't think there is any code like that currently, and this is probably a bad pattern to be following anyway. >> >> ? >> In platform dependent code: >> With regard to mmap/munmap, the only errors that aren't due to bad arguments are ENOMEM and ones related to file descriptors (which are not applicable to uncommit or release). >> On Windows, VirtualFree only fails due to bad arguments. >> On AIX, shmdt and disclaim64 only fail due to bad arguments. msync could spontaneously fail with EIO: "An I/O error occurred while reading from or writing to the file system." >> On BSD, it seems like mprotect and madvise fail only due to bad arguments or invalid privileges. >> >> In the [original discussion](https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700), the main question was whether ENOMEM upon os::uncommit_memory was recoverable. This may be possible if we uncommit the middle of a region - splitting it in two. This could exceed the limit of the number of mappings resulting in ENOMEM. >> >> If none of the scenarios in ? are recoverable, then perhaps fatally failing is OK. >> >> Testing: >> - Tier 1. >> - Manual testing to make sure we fatally fail and the correct messages are printed. > > Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision: > > make remove_stack_guard_pages return void Okay I've pushed a commit that allows `remove_stack_guard_pages` to return void. In the Linux implementation of `remove_stack_guard_pages` , if the `munmap` fails on the primordial thread, then it fails fatally. Now the Linux implementation matches the other platforms more closely. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29240#issuecomment-3807840525 From amenkov at openjdk.org Wed Jan 28 00:16:24 2026 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 28 Jan 2026 00:16:24 GMT Subject: RFR: 8373367: interp-only mechanism fails to work for carrier threads in a corner case In-Reply-To: <_0tOPRnuKQWXGAb9CON1DJ_Wj0-3JIKF8WaFHOQxcbM=.18c2c63f-5313-454f-8ee3-8a13d6be1fc2@github.com> References: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com> <_0tOPRnuKQWXGAb9CON1DJ_Wj0-3JIKF8WaFHOQxcbM=.18c2c63f-5313-454f-8ee3-8a13d6be1fc2@github.com> Message-ID: On Tue, 27 Jan 2026 18:50:13 GMT, Leonid Mesnik wrote: >> The `interp-only` mechanism is based on the `JavaThread` objects. Carrier and virtual threads can temporary share the same `JavaThread`. The `java_thread->jvmti_thread_state()` is re-linked to a virtual thread at `mount` and to the carrier thread at `unmount`. The `JvmtiThreadState` has a back link to the `JavaThread` which is also set for virtual thread at a `mount` and carrier thread at an `unmount`. Just one of these two links at the same time is set to the `JavaThread`, the other one has to be set to `nullptr`. The `interp-only` mechanism needs this invariant. >> However, there is a corner case when this invariant is broken. It happens when the `JvmtiThreadState` for carrier thread has just been created. In such case, the link to `JavaThread` is always `non-nullptr` even though a virtual thread is currently mounted on a carrier thread. This simple update fixes the issue in the `JvmtiThreadState` ctor. >> >> Testing: >> - TBD: Mach5 tiers 1-6 > > src/hotspot/share/prims/jvmtiThreadState.cpp line 127: > >> 125: thread->set_interp_only_mode(false); >> 126: } >> 127: if (JvmtiEnvBase::is_thread_carrying_vthread(thread, thread_oop)) { > > wouldn't be better to move this into the beginning of ctor: > > if(!JvmtiEnvBase::is_thread_carrying_vthread(thread, thread_oop)) { > _thread = thread; > _thread_saved = nullptr; > } else { > _thread_saved = thread; > _thread = nullptr; > } > > and might be add comments with explanation. +1 And have you tried to implement a test for the case? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29436#discussion_r2734329325 From dholmes at openjdk.org Wed Jan 28 02:18:15 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 28 Jan 2026 02:18:15 GMT Subject: RFR: 8353564: Fail fatally if os::release_memory or os::uncommit_memory fails [v4] In-Reply-To: References: Message-ID: <5OmV0pZrlB2thfsumjiPuZp2jGGdVvFZj9LuCjoCwXk=.d5405dc0-6963-4f20-82e2-0297d86825cc@github.com> On Tue, 27 Jan 2026 22:27:37 GMT, Robert Toyonaga wrote: >> This PR is a follow up to JDK-8341491. See original discussion: https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700 >> >> This PR makes `os::release_memory`, `os::uncommit_memory`, `os::release_memory_special`, and `os::unmap_memory` fail fatally if they encounter an error. These methods require obtaining the NMT lock. Fatally failing in these places would potentially allow for the tightening of NMT virtual memory locking scopes (future work, if this PR is accepted). Already in most cases, the callers fail fatally or assert(false) when these os:: methods fail. Another reason to fatally fail is that if the OS memory operation fails, it can be difficult to know for sure what state the OS left the memory in and recover. >> >> `release_memory`/`uncommit_memory`/`release_memory_special`/`unmap_memory` can fail due to ? Bad arguments, or ? The OS encountered an issue out of control of the JVM. >> >> ? >> If there is a JVM bug, it's probably reasonable to fatally fail here. Or the caller could be intentionally passing arguments that may or may not be valid. I don't think there is any code like that currently, and this is probably a bad pattern to be following anyway. >> >> ? >> In platform dependent code: >> With regard to mmap/munmap, the only errors that aren't due to bad arguments are ENOMEM and ones related to file descriptors (which are not applicable to uncommit or release). >> On Windows, VirtualFree only fails due to bad arguments. >> On AIX, shmdt and disclaim64 only fail due to bad arguments. msync could spontaneously fail with EIO: "An I/O error occurred while reading from or writing to the file system." >> On BSD, it seems like mprotect and madvise fail only due to bad arguments or invalid privileges. >> >> In the [original discussion](https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700), the main question was whether ENOMEM upon os::uncommit_memory was recoverable. This may be possible if we uncommit the middle of a region - splitting it in two. This could exceed the limit of the number of mappings resulting in ENOMEM. >> >> If none of the scenarios in ? are recoverable, then perhaps fatally failing is OK. >> >> Testing: >> - Tier 1. >> - Manual testing to make sure we fatally fail and the correct messages are printed. > > Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision: > > make remove_stack_guard_pages return void src/hotspot/os/bsd/os_bsd.cpp line 1766: > 1764: // If this is a growable mapping, remove the guard pages entirely by > 1765: // munmap()ping them. If not, just call uncommit_memory(). > 1766: void os::remove_stack_guard_pages(char* addr, size_t size) { Pre-existing but the method comment seems out-of-sync with the implementation. src/hotspot/os/bsd/os_bsd.cpp line 1767: > 1765: // munmap()ping them. If not, just call uncommit_memory(). > 1766: void os::remove_stack_guard_pages(char* addr, size_t size) { > 1767: os::uncommit_memory(addr, size, false); Why are you explicitly passing false now (here and in most other places below) instead of utilising the default argument? If you want to make this explicit then it would be helpful to comment what the `false` means: `false /* not executable */)` src/hotspot/os/linux/os_linux.cpp line 3457: > 3455: os::strerror(ep.saved_errno())); > 3456: if (ep.saved_errno() == ENOMEM) { > 3457: fatal("Failed to uncommit " RANGEFMT " It is possible that the process's maximum number of mappings would have been exceeded. Try increasing the limit.", RANGEFMTARGS(addr, size)); Suggestion: fatal("Failed to uncommit " RANGEFMT ". It is possible that the process's maximum number of mappings would have been exceeded. Try increasing the limit.", RANGEFMTARGS(addr, size)); Missing punctuation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29240#discussion_r2734560429 PR Review Comment: https://git.openjdk.org/jdk/pull/29240#discussion_r2734563555 PR Review Comment: https://git.openjdk.org/jdk/pull/29240#discussion_r2734551328 From dlong at openjdk.org Wed Jan 28 02:25:23 2026 From: dlong at openjdk.org (Dean Long) Date: Wed, 28 Jan 2026 02:25:23 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v6] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 19:37:06 GMT, Chen Liang wrote: >> Folding identity hash as constant if the incoming argument is constant would be useful for quick map lookups, such as for the [Classifier proposal](https://openjdk.org/jeps/8357674). Currently, identity hash is not constant because it loads the object header/mark word. We can add an explicit bypass to load an existing hash eagerly instead. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Use UpperCamelCase src/hotspot/share/ci/ciObject.hpp line 118: > 116: > 117: // Access to the constant value cache > 118: // Key must be nonnegative. Negative keys are reserved. Suggestion: // Keys representing an array index or field offset are nonnegative. Negative keys are reserved for special values such as identity hash code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2734576071 From dlong at openjdk.org Wed Jan 28 02:56:57 2026 From: dlong at openjdk.org (Dean Long) Date: Wed, 28 Jan 2026 02:56:57 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v6] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 19:37:06 GMT, Chen Liang wrote: >> Folding identity hash as constant if the incoming argument is constant would be useful for quick map lookups, such as for the [Classifier proposal](https://openjdk.org/jeps/8357674). Currently, identity hash is not constant because it loads the object header/mark word. We can add an explicit bypass to load an existing hash eagerly instead. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Use UpperCamelCase src/hotspot/share/oops/oop.inline.hpp line 443: > 441: intptr_t oopDesc::fast_identity_hash_or_no_hash() { > 442: // Note: The mark must be read into local variable to avoid concurrent updates. > 443: markWord mrk = mark_acquire(); Suggestion: markWord mrk = mark(); For the fast case, it seems safe to use mark() like oopDesc::identity_hash() does. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2734638145 From dlong at openjdk.org Wed Jan 28 03:14:45 2026 From: dlong at openjdk.org (Dean Long) Date: Wed, 28 Jan 2026 03:14:45 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v6] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 19:37:06 GMT, Chen Liang wrote: >> Folding identity hash as constant if the incoming argument is constant would be useful for quick map lookups, such as for the [Classifier proposal](https://openjdk.org/jeps/8357674). Currently, identity hash is not constant because it loads the object header/mark word. We can add an explicit bypass to load an existing hash eagerly instead. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Use UpperCamelCase src/hotspot/share/opto/library_call.cpp line 4791: > 4789: const TypeInstPtr* t = _gvn.type(obj)->isa_instptr(); > 4790: if (t != nullptr && t->const_oop() != nullptr) { > 4791: assert(!is_virtual, "no devirtualization for constant receiver?"); Don't we also need to check for `is_static`, to distinguish between `Object.hashCode` and `System.identityHashCode`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2734670836 From liach at openjdk.org Wed Jan 28 03:46:01 2026 From: liach at openjdk.org (Chen Liang) Date: Wed, 28 Jan 2026 03:46:01 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v6] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 03:11:52 GMT, Dean Long wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Use UpperCamelCase > > src/hotspot/share/opto/library_call.cpp line 4791: > >> 4789: const TypeInstPtr* t = _gvn.type(obj)->isa_instptr(); >> 4790: if (t != nullptr && t->const_oop() != nullptr) { >> 4791: assert(!is_virtual, "no devirtualization for constant receiver?"); > > Don't we also need to check for `is_static`, to distinguish between `Object.hashCode` and `System.identityHashCode`? I think once we are not virtual, the native Object::hashCode behaves like System::identityHashCode. The only difference is null check, but I think there's a null check in the beginning so we should be safe. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2734726026 From fgao at openjdk.org Wed Jan 28 04:08:08 2026 From: fgao at openjdk.org (Fei Gao) Date: Wed, 28 Jan 2026 04:08:08 GMT Subject: RFR: 8374349: [VectorAPI]: AArch64: Prefer merging mode SVE CPY instruction In-Reply-To: <_qJ_Qo_Mqexx7dYu0Vkc9ru4SxZ0izfqifaUIAL1iyQ=.741b11d4-a89d-495e-8d31-78fed690abf6@github.com> References: <_0ouKSVAIyzg0g9hA2jZXNH-_cCqJjNCSh7kM2dn80w=.b93145c3-c465-423a-ab68-c8d7bd7e4280@github.com> <_qJ_Qo_Mqexx7dYu0Vkc9ru4SxZ0izfqifaUIAL1iyQ=.741b11d4-a89d-495e-8d31-78fed690abf6@github.com> Message-ID: On Fri, 23 Jan 2026 10:28:46 GMT, Eric Fang wrote: >>> > Can we do without `PreferSVEMergingModeCPY`? >>> >>> Thanks, @theRealAph. That?s a fair question ? in general, fewer options are definitely preferable. >>> >>> For this change, the main reason I introduced `PreferSVEMergingModeCPY` as an Arch-level flag is that the benefit and trade-offs of using the merging-mode sequence can be quite **microarchitecture-dependent**. >> >> The question is not whether something may possibly be better or worse, but is it significantly so? If you're going to add another flag, you have to provide evidence that the difference matters. The burden is on you to show that it does. >> >>> From a user?s point of view, the default behaviour should still be sensible: the option is enabled by default on `Neoverse V1/V2`, where we?ve confirmed the improvement, and disabled elsewhere. If, over time, we gain enough confidence that the merging-mode sequence is strictly preferable across a wider range of hardware, I?m happy to follow up with a separate change to hard-wire the behaviour and drop the flag. >> >> That's the wrong way to think about it. There are thousands of tiny decisions we've made in the AArch64 port, and the number of possible tweaks is almost infinite. If we need a flag in the future we can add one, but then we'll do a better job once we understand what we really need. > > Thanks @theRealAph. I don't have test data on other aarch64 microarchitectures to show the difference with and without this optimization. I'm asking my Arm partners for help testing to see if they have more AArch64 environments. > > Adding a new flag for this optimization might not be appropriate. I'm thinking of handling it this way: **during JVM initialization (in `vm_version.cpp`), check the microarchitecture, set a global variable, and then use it in the assembler to determine whether to apply the optimization.** > > Maintaining microarchitecture-specific handling might be worthwhile. This provides some flexibility for different/future architectures. Because we're unsure how the future microarchitecture will behave, from a performance and code size perspective, we generally prefer single instruction over multiple instructions. Is it fine to you ? Hi @erifan , I ran some tests on a `Neoverse N2` platform, which supports `128-bit SVE2`. I executed `IndexInRangeBenchmark.java` with `@Warmup(iterations = 10, time = 1)` and `@Measurement(iterations = 10, time = 2)`, comparing runs with `PreferSVEMergingModeCPY` enabled and disabled in your patch. Benchmark (size) Mode Cnt Unit true/false IndexInRangeBenchmark.byteIndexInRange 7 thrpt 10 ops/ms 0.95 IndexInRangeBenchmark.byteIndexInRange 256 thrpt 10 ops/ms 1.00 IndexInRangeBenchmark.byteIndexInRange 259 thrpt 10 ops/ms 1.02 IndexInRangeBenchmark.byteIndexInRange 512 thrpt 10 ops/ms 1.01 IndexInRangeBenchmark.doubleIndexInRange 7 thrpt 10 ops/ms 0.96 IndexInRangeBenchmark.doubleIndexInRange 256 thrpt 10 ops/ms 1.02 IndexInRangeBenchmark.doubleIndexInRange 259 thrpt 10 ops/ms 1.10 IndexInRangeBenchmark.doubleIndexInRange 512 thrpt 10 ops/ms 1.01 IndexInRangeBenchmark.floatIndexInRange 7 thrpt 10 ops/ms 0.96 IndexInRangeBenchmark.floatIndexInRange 256 thrpt 10 ops/ms 1.00 IndexInRangeBenchmark.floatIndexInRange 259 thrpt 10 ops/ms 1.06 IndexInRangeBenchmark.floatIndexInRange 512 thrpt 10 ops/ms 1.00 IndexInRangeBenchmark.intIndexInRange 7 thrpt 10 ops/ms 0.96 IndexInRangeBenchmark.intIndexInRange 256 thrpt 10 ops/ms 0.98 IndexInRangeBenchmark.intIndexInRange 259 thrpt 10 ops/ms 1.04 IndexInRangeBenchmark.intIndexInRange 512 thrpt 10 ops/ms 0.98 IndexInRangeBenchmark.longIndexInRange 7 thrpt 10 ops/ms 1.01 IndexInRangeBenchmark.longIndexInRange 256 thrpt 10 ops/ms 1.00 IndexInRangeBenchmark.longIndexInRange 259 thrpt 10 ops/ms 0.92 IndexInRangeBenchmark.longIndexInRange 512 thrpt 10 ops/ms 1.00 IndexInRangeBenchmark.shortIndexInRange 7 thrpt 10 ops/ms 0.95 IndexInRangeBenchmark.shortIndexInRange 256 thrpt 10 ops/ms 1.00 IndexInRangeBenchmark.shortIndexInRange 259 thrpt 10 ops/ms 0.96 IndexInRangeBenchmark.shortIndexInRange 512 thrpt 10 ops/ms 1.00 The uplift in `doubleIndexInRange` and `floatIndexInRange` appears significant. For the other data types, however, the JMH results are quite noisy. To better isolate JMH noise, I also ran some simple C microbenchmark loops directly. For `zeroing immediate` mode, the generated C assembly looks like: .L3: ld1d z1.d, p0/z, [x3] add w0, w0, 1 cmpne p1.d, p0/z, z1.d, #0 mov z0.d, p1/z, #1 add z0.d, z0.d, z1.d st1d z0.d, p0, [x2] cmp w1, w0 bne .L3 For `merging immediate` mode, the generated code is: .L12: ld1d z1.d, p0/z, [x3] mov z0.d, x0 cmpne p1.d, p0/z, z1.d, #0 add x0, x0, 1 mov z0.d, p1/m, #1 add z0.d, z0.d, z1.d st1d z0.d, p0, [x2] cmp w1, w0 bgt .L12 The `mov + merging immediate` variant performs noticeably better than the `zeroing immediate` version. Based on this, I believe your change should also benefit the `Neoverse N2` platform. We suspect that the minor regressions observed in some JMH cases (e.g., `longIndexInRange`) may be due to code layout or alignment effects, since enabling the optimization introduces an extra `mov`. See Section 4.9: Branch instruction alignment of N2 software optimization guide: https://developer.arm.com/documentation/109914/0500/?lang=en. To test this hypothesis, I made a small experimental modification to your patch by adding an extra `nop` to the existing `zeroing` mode: diff --git a/src/hotspot/cpu/aarch64/assembler_aarch64.hpp b/src/hotspot/cpu/aarch64/assembler_aarch64.hpp index 4dd19574f30..295a763f260 100644 --- a/src/hotspot/cpu/aarch64/assembler_aarch64.hpp +++ b/src/hotspot/cpu/aarch64/assembler_aarch64.hpp @@ -3846,6 +3846,8 @@ template // According to the Arm Software Optimization Guide, `movi` is zero cost. movi(Zd, T2D, 0); isMerge = true; + } else if(!isMerge){ + nop(); } sve_cpy(Zd, T, Pg, imm8, isMerge, /*isFloat*/false); } After rerunning the JMH benchmarks, the results appeared more stable: Benchmark (size) Mode Cnt Unit true/false IndexInRangeBenchmark.byteIndexInRange 7 thrpt 10 ops/ms 0.98 IndexInRangeBenchmark.byteIndexInRange 256 thrpt 10 ops/ms 1.00 IndexInRangeBenchmark.byteIndexInRange 259 thrpt 10 ops/ms 0.99 IndexInRangeBenchmark.byteIndexInRange 512 thrpt 10 ops/ms 0.99 IndexInRangeBenchmark.doubleIndexInRange 7 thrpt 10 ops/ms 0.97 IndexInRangeBenchmark.doubleIndexInRange 256 thrpt 10 ops/ms 1.01 IndexInRangeBenchmark.doubleIndexInRange 259 thrpt 10 ops/ms 1.13 IndexInRangeBenchmark.doubleIndexInRange 512 thrpt 10 ops/ms 1.00 IndexInRangeBenchmark.floatIndexInRange 7 thrpt 10 ops/ms 0.99 IndexInRangeBenchmark.floatIndexInRange 256 thrpt 10 ops/ms 1.00 IndexInRangeBenchmark.floatIndexInRange 259 thrpt 10 ops/ms 1.07 IndexInRangeBenchmark.floatIndexInRange 512 thrpt 10 ops/ms 1.01 IndexInRangeBenchmark.intIndexInRange 7 thrpt 10 ops/ms 1.04 IndexInRangeBenchmark.intIndexInRange 256 thrpt 10 ops/ms 1.00 IndexInRangeBenchmark.intIndexInRange 259 thrpt 10 ops/ms 1.00 IndexInRangeBenchmark.intIndexInRange 512 thrpt 10 ops/ms 1.00 IndexInRangeBenchmark.longIndexInRange 7 thrpt 10 ops/ms 1.00 IndexInRangeBenchmark.longIndexInRange 256 thrpt 10 ops/ms 1.00 IndexInRangeBenchmark.longIndexInRange 259 thrpt 10 ops/ms 1.04 IndexInRangeBenchmark.longIndexInRange 512 thrpt 10 ops/ms 1.00 IndexInRangeBenchmark.shortIndexInRange 7 thrpt 10 ops/ms 0.99 IndexInRangeBenchmark.shortIndexInRange 256 thrpt 10 ops/ms 1.00 IndexInRangeBenchmark.shortIndexInRange 259 thrpt 10 ops/ms 1.00 IndexInRangeBenchmark.shortIndexInRange 512 thrpt 10 ops/ms 1.00 Overall, these results suggest that the patch should also be beneficial on `Neoverse N2`. Thanks for your work! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29359#issuecomment-3804576835 From erfang at openjdk.org Wed Jan 28 04:08:09 2026 From: erfang at openjdk.org (Eric Fang) Date: Wed, 28 Jan 2026 04:08:09 GMT Subject: RFR: 8374349: [VectorAPI]: AArch64: Prefer merging mode SVE CPY instruction In-Reply-To: References: <_0ouKSVAIyzg0g9hA2jZXNH-_cCqJjNCSh7kM2dn80w=.b93145c3-c465-423a-ab68-c8d7bd7e4280@github.com> <_qJ_Qo_Mqexx7dYu0Vkc9ru4SxZ0izfqifaUIAL1iyQ=.741b11d4-a89d-495e-8d31-78fed690abf6@github.com> Message-ID: On Tue, 27 Jan 2026 11:15:55 GMT, Fei Gao wrote: >> Thanks @theRealAph. I don't have test data on other aarch64 microarchitectures to show the difference with and without this optimization. I'm asking my Arm partners for help testing to see if they have more AArch64 environments. >> >> Adding a new flag for this optimization might not be appropriate. I'm thinking of handling it this way: **during JVM initialization (in `vm_version.cpp`), check the microarchitecture, set a global variable, and then use it in the assembler to determine whether to apply the optimization.** >> >> Maintaining microarchitecture-specific handling might be worthwhile. This provides some flexibility for different/future architectures. Because we're unsure how the future microarchitecture will behave, from a performance and code size perspective, we generally prefer single instruction over multiple instructions. Is it fine to you ? > > Hi @erifan , > > I ran some tests on a `Neoverse N2` platform, which supports `128-bit SVE2`. > > I executed `IndexInRangeBenchmark.java` with `@Warmup(iterations = 10, time = 1)` and `@Measurement(iterations = 10, time = 2)`, comparing runs with `PreferSVEMergingModeCPY` enabled and disabled in your patch. > > Benchmark (size) Mode Cnt Unit true/false > IndexInRangeBenchmark.byteIndexInRange 7 thrpt 10 ops/ms 0.95 > IndexInRangeBenchmark.byteIndexInRange 256 thrpt 10 ops/ms 1.00 > IndexInRangeBenchmark.byteIndexInRange 259 thrpt 10 ops/ms 1.02 > IndexInRangeBenchmark.byteIndexInRange 512 thrpt 10 ops/ms 1.01 > IndexInRangeBenchmark.doubleIndexInRange 7 thrpt 10 ops/ms 0.96 > IndexInRangeBenchmark.doubleIndexInRange 256 thrpt 10 ops/ms 1.02 > IndexInRangeBenchmark.doubleIndexInRange 259 thrpt 10 ops/ms 1.10 > IndexInRangeBenchmark.doubleIndexInRange 512 thrpt 10 ops/ms 1.01 > IndexInRangeBenchmark.floatIndexInRange 7 thrpt 10 ops/ms 0.96 > IndexInRangeBenchmark.floatIndexInRange 256 thrpt 10 ops/ms 1.00 > IndexInRangeBenchmark.floatIndexInRange 259 thrpt 10 ops/ms 1.06 > IndexInRangeBenchmark.floatIndexInRange 512 thrpt 10 ops/ms 1.00 > IndexInRangeBenchmark.intIndexInRange 7 thrpt 10 ops/ms 0.96 > IndexInRangeBenchmark.intIndexInRange 256 thrpt 10 ops/ms 0.98 > IndexInRangeBenchmark.intIndexInRange 259 thrpt 10 ops/ms 1.04 > IndexInRangeBenchmark.intIndexInRange 512 thrpt 10 ops/ms 0.98 > IndexInRangeBenchmark.longIndexInRange 7 thrpt 10 ops/ms 1.01 > IndexInRangeBenchmark.longIndexInRange 256 thrpt 10 ops/ms 1.00 > IndexInRangeBenchmark.longIndexInRange 259 thrpt 10 ops/ms 0.92 > IndexInRangeBenchmark.longIndexInRange 512 thrpt 10 ops/ms 1.00 > IndexInRangeBenchmark.shortIndexInRange 7 thrpt 10 ops/ms 0.95 > IndexInRangeBenchmark.shortIndexInRange 256 thrpt 10 ops/ms 1.00 > IndexInRangeBenchmark.shortIndexInRange 259 thrpt 10 ops/ms 0.96 > IndexInRangeBenchmark.shortIndexInRange 512 thrpt 10 ops/ms 1.00 > > The uplift in `doubleIndexInRange` and `floatIndexInRange` appear... @fg1417 thanks for your help, this is really helpful! You've also noticed slight regression in a few cases, which is reasonable. The optimization effect is influenced by multiple factors, such as the alignment you mentioned on N2, as well as code generation and register allocation. The underlying principle of this optimization is that the latency of the `cpy(imm, zeroing)` instruction seems quite high, while the `movi + cpy(imm, merging)` combination improves the parallelism of the program. In some cases, a `mov` or other instruction with the same effect is already generated before the `cpy(imm, zeroing)` instruction, thus achieving the optimization effect of the `movi + cpy(imm, merging)` instruction combination. Therefore, the slight regression caused by the extra `movi` instruction in these cases is reasonable. However, for cases where this optimization applies, the performance improvement will be more significant. For example, in the following case, I even saw a **2x** performance improvement on Neoverse-V2. @Param({"128"}) private int loop_iteration; private static final VectorSpecies ispecies = VectorSpecies.ofLargestShape(int.class); private boolean[] mask_arr; @Setup(Level.Trial) public void BmSetup() { int array_size = loop_iteration * bspecies.length(); mask_arr = new boolean[array_size]; Random r = new Random(); for (int i = 0; i < array_size; i++) { mask_arr[i] = r.nextBoolean(); } } @CompilerControl(CompilerControl.Mode.INLINE) private long testIndexInRangeToLongKernel(VectorSpecies species) { long sum = 0; VectorMask m = VectorMask.fromArray(species, mask_arr, 0); for (int i = 0; i < loop_iteration; i++) { sum += m.indexInRange(i & (m.length() - 1), m.length()).toLong(); } return sum; } @Benchmark public long indexInRangeToLongInt() { return testIndexInRangeToLongKernel(ispecies); } Therefore, when you test this change using the C case, you will see a significant performance improvement. > I see 2% uplift on these numbers. @theRealAph And I think this also explains your question on these numbers. > One thing you can do is add a flag to control this minor optimization, but make it constexpr bool = true until we know what other SVE implementations might do. In general: Dead code in HotSpot is dangerous. Over time it rots, leading to hard-to-diagnose bugs when if it does get exercised. If we don't know that we need something, we shouldn't do it. Don't speculatively add code. We don't need the AArch64 to be come (even more of) a jungle of microarchitecture-specific tweaks. Yeah I agree with you, we shouldn't add dead code that makes the project increasingly difficult to maintain. I tried adding a user invisible **constexpr** global variable `constexpr bool _prefer_merging_mode_sve_cpy = true` to `vm_version` class, like [_max_supported_sve_vector_length](https://github.com/openjdk/jdk/blob/fa1b1d677ac492dfdd3110b9303a4c2b009046c8/src/hotspot/cpu/aarch64/vm_version_aarch64.hpp#L53), but then we had to delete these ASM instruction tests for [cpy(imm, zeroing)](https://github.com/openjdk/jdk/blob/fa1b1d677ac492dfdd3110b9303a4c2b009046c8/test/hotspot/gtest/aarch64/aarch64-asmtest.py#L1958). Because now the `cpy(imm, zeroing)` instruction corresponds to two instructions `movi + cpy(imm, merging)`. So I'm inclined to make this global variable **non-constexpr**, so we can set it to false while doing this test and restore it after the test. Is it fine to you? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29359#issuecomment-3808829111 From dholmes at openjdk.org Wed Jan 28 04:28:41 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 28 Jan 2026 04:28:41 GMT Subject: RFR: 8374926: EnableX86ECoreOpts was not enabled on some hybrid CPU [v5] In-Reply-To: References: Message-ID: On Sat, 24 Jan 2026 02:38:22 GMT, Yasumasa Suenaga wrote: >> `EnableX86ECoreOpts` has been introduced in [JDK-8319429](https://bugs.openjdk.org/browse/JDK-8319429), however model numbers which should be enabled are hard-coded, so the flag would not be enabled by default on some models like Arrow Lake. >> >> I ran a [benchmark](https://github.com/YaSuenag/garakuta/tree/master/randminmax) to check for effectiveness of `-XX:+EnableX86ECoreOpts` with JDK 25.0.1 on Windows 11 25H2, I saw performance improvement a bit on Intel Core 5 Ultra 225U as following: >> >> Disabled (default) >> >> Benchmark Mode Cnt Score Error Units >> RandMinVal.getMax thrpt 3 9707774.405 ? 27082629.015 ops/s >> RandMinVal.getMin thrpt 3 7510319.839 ? 10923547.382 ops/s >> >> >> Enabled >> >> Benchmark Mode Cnt Score Error Units >> RandMinVal.getMax thrpt 3 10127809.127 ? 45404142.338 ops/s >> RandMinVal.getMin thrpt 3 8467677.056 ? 1211998.200 ops/s >> >> >> So I think it is better to enable this flag by default on all of hybrid CPUs. >> >> >> To check what processor would be enabled E-core optimization, I made a [commit](https://github.com/openjdk/jdk/commit/f363ea1436b8100021fdac87b48ec43bcf6820af) to add comments for CPU models at first. I couldn't find out all of models (some models has not listed in SDM vol.4 so far), but most of models (excepts Sierra Forest) could be treated as hybrid CPU. Fortunately HotSpot identify hybrid flag from `CPUID`, so we can leverage it for this purpose. > > Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: > > - Add condition for CWF > - Revert "Check E-Core with Leaf 1Ah" > > This reverts commit d77b43937911b33bf39175e45e3d9d97aa949617. Seems reasonable. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29149#pullrequestreview-3714520645 From dholmes at openjdk.org Wed Jan 28 04:53:14 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 28 Jan 2026 04:53:14 GMT Subject: RFR: 8375359: Improve GC serviceability init staging In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 12:55:50 GMT, Aleksey Shipilev wrote: >> Is there a way to restructure the code so that we don't get more locations in the VM initialization code (external to the GC code) that call various CollectedHeap initialization functions? >> >> I haven't fully looked at this in all details, but could the various `initialize_serviceability` function be called from within the `CollectedHeap::initialize` function instead? > >> Is there a way to restructure the code so that we don't get more locations in the VM initialization code (external to the GC code) that call various CollectedHeap initialization functions? > > I have not looked deeply, but honestly, I doubt it would not introduce more bootstrapping issues. As it stands now, we are changing the init sequence only a little bit, and already when the rest of the system is initialized. Moving serviceability inits way up to `CollectedHeap::initialize` moves it before a lot of other inits, so there is IMO a risk there. Bootstraping sequence is fiddly and always comes with surprises. > > For example, AFAICS, after `CollectedHeap::initialize` completes, we have not yet initialized Metaspace including its perf counters, String table is not yet wired up, etc. It is plausible serviceability code would need some of that, maybe is some future changes. > > So I'd prefer to keep the patch as it is. @shipilev I took a look at this but it is not code I know anything about. Hard to determine what the implications of moving these pieces of code around could be. Sorry. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29254#issuecomment-3808940265 From dholmes at openjdk.org Wed Jan 28 05:01:53 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 28 Jan 2026 05:01:53 GMT Subject: RFR: 8376131: Convert ContiguousSpace to use Atomic In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 17:51:08 GMT, Thomas Schatzl wrote: > Hi all, > > please review this conversions of `ContiguousSpace` to use `Atomic`. > > Testing: gha, tier1-5 > > Thanks, > Thomas Looks good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29370#pullrequestreview-3714587669 From shade at openjdk.org Wed Jan 28 07:37:27 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 28 Jan 2026 07:37:27 GMT Subject: RFR: 8375359: Improve GC serviceability init staging In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 12:55:50 GMT, Aleksey Shipilev wrote: >> Is there a way to restructure the code so that we don't get more locations in the VM initialization code (external to the GC code) that call various CollectedHeap initialization functions? >> >> I haven't fully looked at this in all details, but could the various `initialize_serviceability` function be called from within the `CollectedHeap::initialize` function instead? > >> Is there a way to restructure the code so that we don't get more locations in the VM initialization code (external to the GC code) that call various CollectedHeap initialization functions? > > I have not looked deeply, but honestly, I doubt it would not introduce more bootstrapping issues. As it stands now, we are changing the init sequence only a little bit, and already when the rest of the system is initialized. Moving serviceability inits way up to `CollectedHeap::initialize` moves it before a lot of other inits, so there is IMO a risk there. Bootstraping sequence is fiddly and always comes with surprises. > > For example, AFAICS, after `CollectedHeap::initialize` completes, we have not yet initialized Metaspace including its perf counters, String table is not yet wired up, etc. It is plausible serviceability code would need some of that, maybe is some future changes. > > So I'd prefer to keep the patch as it is. > @shipilev I took a look at this but it is not code I know anything about. Hard to determine what the implications of moving these pieces of code around could be. Sorry. No problem. You can think about this as: Before: 1. post_initialize() -> initialize_serviceabillity() -> MemoryPools inits, claims CollectedHeap is fully operational 2. So GC is claimed ready to early. After: 1. initialize_serviceability() -> MemoryPool inits 2. 3. post_initialize() -> claims heap is fully operational ------------- PR Comment: https://git.openjdk.org/jdk/pull/29254#issuecomment-3809527835 From stuefe at openjdk.org Wed Jan 28 07:46:29 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 28 Jan 2026 07:46:29 GMT Subject: RFR: 8373096: JFR: Path-to-gc-roots search should be non-recursive [v2] In-Reply-To: References: Message-ID: > This is a continuation - second attempt - of https://github.com/openjdk/jdk/pull/28659. > > ---- > > A customer reported a native stack overflow when producing a JFR recording with path-to-gc-roots=true. This happens regularly, see similar cases in JBS (e.g. https://bugs.openjdk.org/browse/JDK-8371630, https://bugs.openjdk.org/browse/JDK-8282427 etc). > > We limit the maximum graph search depth (DFSClosure::max_dfs_depth) to prevent stack overflows. That solution is brittle, however, since recursion depth is not a good proxy for thread stack usage: it depends on many factors, e.g., compiler inlining decisions and platform specifics. In this case, the VMThread's stack was too small. > > This patch rewrites the DFS heap tracer to be non-recursive. This is mostly textbook stuff, but the devil is in the details. Nevertheless, the algorithm should be a straightforward read. > > ### Memory usage of old vs new algorithm: > > The new algorithm uses, on average, a bit less memory than the old one. The old algorithm did cost ((avg stackframe size in bytes) * depth). As we have seen, e.g., in JDK-8371630, a depth of 3200 can max out ~1MB of stack space. > > The new algorithm costs ((avg number of outgoing refs per instanceKlass oop) * depth * 16. For a depth of 3200, we get typical probe stack sizes of 100KB..200KB. But we also cap probestack size, similar to how we cap the max. graph depth. > > In any case, these numbers are nothing to worry about. For a more in-depth explanation about memory cost, please see the comment in dfsClosure.cpp. > > ### Possible improvements/simplifications in the future: > > DFS works perfectly well alone now. It no longer depends on stack size, and its memory usage is typically smaller than BFS. IMHO, it would be perfectly fine to get rid of BFS and rely solely on the non-recursive DFS. The benefit would be a decrease in complexity and fewer tests to run and maintain. It should also be easy to convert into a parallelized version later. > > I kept the _max_dfs_depth_ parameter for now, but tbh it is no longer very useful. Before, it prevented stack overflows. Now, it is just an indirect way to limit probe stack size. But we also explicitly cap the probe stack size, so _max_dfs_depth_ is redundant. Removing it would require changing the statically allocated reference stack to be dynamically allocated, but that should not be difficult. > > ### Observable differences > > There is one observable side effect to the changed algorithm. The non-recursive algorithm processes oops a... Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/share/jfr/leakprofiler/chains/dfsClosure.cpp Co-authored-by: Robert Toyonaga ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29382/files - new: https://git.openjdk.org/jdk/pull/29382/files/5d79624b..af5c5585 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29382&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29382&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29382.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29382/head:pull/29382 PR: https://git.openjdk.org/jdk/pull/29382 From shade at openjdk.org Wed Jan 28 07:48:04 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 28 Jan 2026 07:48:04 GMT Subject: Integrated: 8373266: Strengthen constant CardTable base accesses In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 18:45:04 GMT, Aleksey Shipilev 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 This pull request has now been integrated. Changeset: 88c8a55a Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/88c8a55a4337a857ac17ffff068f730f67cf5763 Stats: 99 lines in 15 files changed: 35 ins; 25 del; 39 mod 8373266: Strengthen constant CardTable base accesses Reviewed-by: tschatzl, xpeng ------------- PR: https://git.openjdk.org/jdk/pull/28703 From shade at openjdk.org Wed Jan 28 07:48:03 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 28 Jan 2026 07:48:03 GMT Subject: RFR: 8373266: Strengthen constant CardTable base accesses [v5] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 16:47:43 GMT, Aleksey Shipilev 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 > > Aleksey Shipilev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > Some polishing Thanks folks! Here goes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28703#issuecomment-3809555279 From stuefe at openjdk.org Wed Jan 28 07:52:58 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 28 Jan 2026 07:52:58 GMT Subject: RFR: 8353564: Fail fatally if os::release_memory or os::uncommit_memory fails [v4] In-Reply-To: <5OmV0pZrlB2thfsumjiPuZp2jGGdVvFZj9LuCjoCwXk=.d5405dc0-6963-4f20-82e2-0297d86825cc@github.com> References: <5OmV0pZrlB2thfsumjiPuZp2jGGdVvFZj9LuCjoCwXk=.d5405dc0-6963-4f20-82e2-0297d86825cc@github.com> Message-ID: <_spitwr7E2ZOosdO55zaal5x_KivtEb4VypVHGXd2D0=.9b2f66a7-8221-470a-b217-2463334fcef2@github.com> On Wed, 28 Jan 2026 02:13:20 GMT, David Holmes wrote: >> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision: >> >> make remove_stack_guard_pages return void > > src/hotspot/os/bsd/os_bsd.cpp line 1766: > >> 1764: // If this is a growable mapping, remove the guard pages entirely by >> 1765: // munmap()ping them. If not, just call uncommit_memory(). >> 1766: void os::remove_stack_guard_pages(char* addr, size_t size) { > > Pre-existing but the method comment seems out-of-sync with the implementation. Yes, this only applies to Linux and its primordial stack segment. Maybe the whole function was copied over from Linux, including comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29240#discussion_r2735298210 From stuefe at openjdk.org Wed Jan 28 07:53:47 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 28 Jan 2026 07:53:47 GMT Subject: RFR: 8373096: JFR: Path-to-gc-roots search should be non-recursive [v3] In-Reply-To: References: Message-ID: > This is a continuation - second attempt - of https://github.com/openjdk/jdk/pull/28659. > > ---- > > A customer reported a native stack overflow when producing a JFR recording with path-to-gc-roots=true. This happens regularly, see similar cases in JBS (e.g. https://bugs.openjdk.org/browse/JDK-8371630, https://bugs.openjdk.org/browse/JDK-8282427 etc). > > We limit the maximum graph search depth (DFSClosure::max_dfs_depth) to prevent stack overflows. That solution is brittle, however, since recursion depth is not a good proxy for thread stack usage: it depends on many factors, e.g., compiler inlining decisions and platform specifics. In this case, the VMThread's stack was too small. > > This patch rewrites the DFS heap tracer to be non-recursive. This is mostly textbook stuff, but the devil is in the details. Nevertheless, the algorithm should be a straightforward read. > > ### Memory usage of old vs new algorithm: > > The new algorithm uses, on average, a bit less memory than the old one. The old algorithm did cost ((avg stackframe size in bytes) * depth). As we have seen, e.g., in JDK-8371630, a depth of 3200 can max out ~1MB of stack space. > > The new algorithm costs ((avg number of outgoing refs per instanceKlass oop) * depth * 16. For a depth of 3200, we get typical probe stack sizes of 100KB..200KB. But we also cap probestack size, similar to how we cap the max. graph depth. > > In any case, these numbers are nothing to worry about. For a more in-depth explanation about memory cost, please see the comment in dfsClosure.cpp. > > ### Possible improvements/simplifications in the future: > > DFS works perfectly well alone now. It no longer depends on stack size, and its memory usage is typically smaller than BFS. IMHO, it would be perfectly fine to get rid of BFS and rely solely on the non-recursive DFS. The benefit would be a decrease in complexity and fewer tests to run and maintain. It should also be easy to convert into a parallelized version later. > > I kept the _max_dfs_depth_ parameter for now, but tbh it is no longer very useful. Before, it prevented stack overflows. Now, it is just an indirect way to limit probe stack size. But we also explicitly cap the probe stack size, so _max_dfs_depth_ is redundant. Removing it would require changing the statically allocated reference stack to be dynamically allocated, but that should not be difficult. > > ### Observable differences > > There is one observable side effect to the changed algorithm. The non-recursive algorithm processes oops a... Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: dont incremement _num_objects_processed for follow-up chunks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29382/files - new: https://git.openjdk.org/jdk/pull/29382/files/af5c5585..66276985 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29382&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29382&range=01-02 Stats: 6 lines in 1 file changed: 4 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29382.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29382/head:pull/29382 PR: https://git.openjdk.org/jdk/pull/29382 From stuefe at openjdk.org Wed Jan 28 07:53:49 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 28 Jan 2026 07:53:49 GMT Subject: RFR: 8373096: JFR: Path-to-gc-roots search should be non-recursive [v3] In-Reply-To: <9F7u-mBUQGEfA8o6PGa9XtHd0wa8ie6jBD444Hq2L5M=.701a8395-fc36-4cbc-b514-a589b93ceb14@github.com> References: <9F7u-mBUQGEfA8o6PGa9XtHd0wa8ie6jBD444Hq2L5M=.701a8395-fc36-4cbc-b514-a589b93ceb14@github.com> Message-ID: On Tue, 27 Jan 2026 18:57:56 GMT, Robert Toyonaga wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> dont incremement _num_objects_processed for follow-up chunks > > src/hotspot/share/jfr/leakprofiler/chains/dfsClosure.cpp line 217: > >> 215: _current_pointee = _current_ref.dereference(); >> 216: >> 217: _num_objects_processed++; > > For large arrays that have many chunks, each chunk will count as another "object" processed. Is this okay? Thank you for catching that; I fixed it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29382#discussion_r2735291019 From duke at openjdk.org Wed Jan 28 08:11:27 2026 From: duke at openjdk.org (Chad Rakoczy) Date: Wed, 28 Jan 2026 08:11:27 GMT Subject: Integrated: 8374513: AArch64: Improve receiver type profiling reliability In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 01:28:40 GMT, Chad Rakoczy wrote: > [JDK-8374513](https://bugs.openjdk.org/browse/JDK-8374513) is the AArch64 port of [JDK-8357258](https://bugs.openjdk.org/browse/JDK-8357258). See the bug report for more detailed information. > > This PR executes the plan outlined in the bug: > - Common the receiver type profiling code in interpreter and C1 > - Rewrite receiver type profiling code to only do atomic receiver slot installations > - 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. > > Functional Testing: Linux AArch64 fastdebug Tier1-4 > > Performance Testing (to show there is no performance regression): > > # Baseline > Benchmark (randomized) Mode Cnt Score Error Units > InterfaceCalls.test1stInt2Types false avgt 12 1.940 ? 0.002 ns/op > InterfaceCalls.test1stInt2Types true avgt 12 7.714 ? 0.011 ns/op > InterfaceCalls.test1stInt3Types false avgt 12 6.747 ? 0.066 ns/op > InterfaceCalls.test1stInt3Types true avgt 12 18.733 ? 0.175 ns/op > InterfaceCalls.test1stInt5Types false avgt 12 6.690 ? 0.083 ns/op > InterfaceCalls.test1stInt5Types true avgt 12 21.299 ? 0.016 ns/op > InterfaceCalls.test2ndInt2Types false avgt 12 1.997 ? 0.004 ns/op > InterfaceCalls.test2ndInt2Types true avgt 12 8.027 ? 0.016 ns/op > InterfaceCalls.test2ndInt3Types false avgt 12 7.915 ? 0.114 ns/op > InterfaceCalls.test2ndInt3Types true avgt 12 16.988 ? 0.065 ns/op > InterfaceCalls.test2ndInt5Types false avgt 12 9.422 ? 0.017 ns/op > InterfaceCalls.test2ndInt5Types true avgt 12 22.736 ? 0.022 ns/op > InterfaceCalls.testIfaceCall false avgt 12 5.860 ? 0.046 ns/op > InterfaceCalls.testIfaceCall true avgt 12 5.794 ? 0.026 ns/op > InterfaceCalls.testIfaceExtCall false avgt 12 6.310 ? 0.067 ns/op > InterfaceCalls.testIfaceExtCall true avgt 12 6.239 ? 0.017 ns/op > InterfaceCalls.testMonomorphic false avgt 12 1.146 ? 0.034 ns/op > InterfaceCalls.testMonomorphic true avgt 12 1.131 ? 0.012 ns/op > > # With PR > Benchmark (randomized) Mode Cnt Score Error Units > InterfaceCalls.test1stInt2Types false avgt 12 1.941 ? 0.004 ns/op > InterfaceCalls.test1stIn... This pull request has now been integrated. Changeset: 4ae4ffd5 Author: Chad Rakoczy Committer: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/4ae4ffd5a3114aa2a3832818ee30dc38d9aa2b72 Stats: 387 lines in 7 files changed: 158 ins; 207 del; 22 mod 8374513: AArch64: Improve receiver type profiling reliability Reviewed-by: shade, aph ------------- PR: https://git.openjdk.org/jdk/pull/29283 From chagedorn at openjdk.org Wed Jan 28 08:23:31 2026 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Wed, 28 Jan 2026 08:23:31 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v3] In-Reply-To: References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: On Tue, 27 Jan 2026 16:26:19 GMT, Damon Fenacci wrote: >> ## Issue >> >> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. >> >> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. >> >> ## Causes >> >> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. >> >> ## Fix >> >> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: >> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 >> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. >> >> # Testing >> >> * Tier 1-3+ >> * 2 JTReg tests added >> * `TestRangeCheck.java` as regression test for the reported issue >> * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion > > Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8374852: fix star layout > > Co-authored-by: Christian Hagedorn Thanks for unifying the two opaque nodes! I have some more comments. src/hotspot/share/opto/macro.cpp line 2559: > 2557: #else > 2558: bool is_positive = n->as_OpaqueCheck()->is_positive(); > 2559: _igvn.replace_node(n, _igvn.intcon(is_positive?1:0)); Suggestion: _igvn.replace_node(n, _igvn.intcon(is_positive ? 1 : 0)); src/hotspot/share/opto/opaquenode.hpp line 146: > 144: // builds, we keep the actual checks as additional verification code (i.e. removing OpaqueCheckNodes and use the > 145: // BoolNode inputs instead). > 146: class OpaqueCheckNode : public Node { I've also thought about the name. `OpaqueCheck` is already a good indication what the node is about. Maybe we could go a step further and call it `OpaqueConstantBoolNode` to emphasize more that it is belonging to a `BoolNode` whose result we already know. What do you think? Then we could also think about changing `_positive` to `_constant` (still can be a boolean to just pass true and false which seems more intuitive then passing in 1 and 0). src/hotspot/share/opto/opaquenode.hpp line 148: > 146: class OpaqueCheckNode : public Node { > 147: private: > 148: bool _positive; Now that we define a field, we also need to override `size_of()` (see for example `OpaqueMultiversioningNode`). src/hotspot/share/opto/opaquenode.hpp line 150: > 148: bool _positive; > 149: public: > 150: OpaqueCheckNode(Compile* C, Node* tst, bool positive) : Node(nullptr, tst), _positive(positive) { `tst` is probably almost always a `BoolNode`. I'm wondering if it could also be a constant because we already folded the `BoolNode`? But then it's probably also useless to create the opaque node in the first place. src/hotspot/share/opto/opaquenode.hpp line 159: > 157: virtual const Type* Value(PhaseGVN* phase) const; > 158: virtual const Type* bottom_type() const { return TypeInt::BOOL; } > 159: bool is_positive() { return _positive; } When going with `_constant`, we could turn this into int constant() const { return _constant ? 1 : 0; } ------------- PR Review: https://git.openjdk.org/jdk/pull/29164#pullrequestreview-3715097474 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2735306919 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2735376625 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2735315675 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2735369034 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2735392835 From stuefe at openjdk.org Wed Jan 28 08:33:00 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 28 Jan 2026 08:33:00 GMT Subject: RFR: 8373096: JFR: Path-to-gc-roots search should be non-recursive [v3] In-Reply-To: <9F7u-mBUQGEfA8o6PGa9XtHd0wa8ie6jBD444Hq2L5M=.701a8395-fc36-4cbc-b514-a589b93ceb14@github.com> References: <9F7u-mBUQGEfA8o6PGa9XtHd0wa8ie6jBD444Hq2L5M=.701a8395-fc36-4cbc-b514-a589b93ceb14@github.com> Message-ID: On Tue, 27 Jan 2026 20:00:51 GMT, Robert Toyonaga wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> dont incremement _num_objects_processed for follow-up chunks > > This looks good to me! And it fixes the [problem we talked about earlier](https://github.com/openjdk/jdk/pull/28659#discussion_r2632525732). I have left one minor comment below. Thank you, @roberttoyonaga ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29382#issuecomment-3809764432 From shade at openjdk.org Wed Jan 28 09:38:50 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 28 Jan 2026 09:38:50 GMT Subject: RFR: 8375046: C2: Incremental inlining step asserts when processing empty late inlines list [v4] In-Reply-To: References: <_tSvASngm2bL0X2wavXI63kJZoypsY5S-dus_KGhs18=.ace489be-48bf-4254-a88e-b4fe456edf02@github.com> Message-ID: <9PqllSJF-_pStpPeBK3yqLZLaeO15h1ryIsXZjS9wYg=.3f0a47f5-53ce-4000-afc9-64d3db08464a@github.com> On Tue, 20 Jan 2026 19:39:24 GMT, Vladimir Ivanov wrote: > The behavior is counter-intuitive and can cause other surprises later. Instead, I suggest to add ` if (_late_inlines.length() == 0) return;` in `Compile::inline_incrementally()` before calling into `inline_incrementally_one()`. All right, that makes sense as well. In fact, I think the existing check within `Compile::inline_incrementally()` loop is in the wrong place, as `_late_inlines.length() > 0` would be immediately checked as loop condition. So the fix is to move the check a bit earlier. See new PR version. This passes light testing, I am going to run a more thorough CTW loop and see if it holds. I'll move `GrowableArray` improvement to a separate PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29171#issuecomment-3810105644 From jbhateja at openjdk.org Wed Jan 28 09:39:42 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 28 Jan 2026 09:39:42 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v18] In-Reply-To: References: Message-ID: <23D_3Ap5t-E3oXX8yiulKT0bhbumyT4N8ucWDjNMZPE=.054aef2e-8280-448e-88b8-cbfcf91fbfaf@github.com> > 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. > > image > > 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 incrementally with one additional commit since the last revision: Adding new lane type constants for intrinsic entries, removing basictype extension changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28002/files - new: https://git.openjdk.org/jdk/pull/28002/files/ce5768fa..68145fd9 Webrevs: - full: Webrev is not available because diff is too large - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=16-17 Stats: 1162 lines in 58 files changed: 25 ins; 26 del; 1111 mod Patch: https://git.openjdk.org/jdk/pull/28002.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002 PR: https://git.openjdk.org/jdk/pull/28002 From jbhateja at openjdk.org Wed Jan 28 09:39:44 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 28 Jan 2026 09:39:44 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v17] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 18:25:25 GMT, Paul Sandoz wrote: > > We will still need to create T_FLOAT16 basic type and associate it with Float16 LaneType, why not directly pass these basic types to intrinsic entry point ? > > The strong feedback from HotSpot folks, which i agree with, is adding a new enum value to `BasicType` is not the way to go - it is too disruptive and does not scale. Sorry if i misled you earlier on, it was my intention in feedback to propose something that was limited in scope to vector support. > > The thought about a proxy class was motivated by a question i had - what would we do if `Float16.class` was already present in `java.base`? and answers to that might motivate what we do now in preparation for when that happens. Regardless i think we need to separate out the Vector API's direct dependence on BasicType and its values. Instead we should define our own constants for the vector element types, and provide mapping of those to BasicType values which might result in "erasure" to the carrier type. We should adjust/adapt LaneType accordingly. Does that make sense to you? Hi @PaulSandoz , Yes this looks good to me, I have modified the patch accordingly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3810098116 From shade at openjdk.org Wed Jan 28 09:43:32 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 28 Jan 2026 09:43:32 GMT Subject: RFR: 8375046: C2: Incremental inlining step asserts when processing empty late inlines list [v6] In-Reply-To: <_tSvASngm2bL0X2wavXI63kJZoypsY5S-dus_KGhs18=.ace489be-48bf-4254-a88e-b4fe456edf02@github.com> References: <_tSvASngm2bL0X2wavXI63kJZoypsY5S-dus_KGhs18=.ace489be-48bf-4254-a88e-b4fe456edf02@github.com> Message-ID: <0bZ35MkAh88k08YJCy2eFddNuI_s-kMf0NZCJIp3lpo=.1bd652e6-a9ba-452b-8cf3-77972ab21e86@github.com> > Seen this assert in stress CTW runs: > > > # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/utilities/growableArray.hpp:498), pid=2972347, tid=2973775 > # assert(start < end && end <= this->_len) failed: erase called with invalid range (0, 0) for length 0 > > Stack: [0x00007fd660bea000,0x00007fd660cea000], sp=0x00007fd660ce4fc0, free space=1003k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0xc00a41] Compile::inline_incrementally_one()+0x801 (growableArray.hpp:498) > V [libjvm.so+0xc01650] Compile::inline_incrementally(PhaseIterGVN&)+0x2f0 (compile.cpp:2212) > V [libjvm.so+0xc04581] Compile::Optimize()+0x7d1 (compile.cpp:2357) > > > It looks innocuous, as `GrowableArray::remove_range` does nothing real on `[0, 0)`. It is still IMO a bug to call it with `[0, 0)`, as it is not clear whether to trust inclusive or exclusive boundary. But for `remove_till`, it looks plausible that `remove_till(0)` should work and be a no-op. Looks like it readily happens in C2 CTW when `_late_inlines` is empty. > > Additional testing: > - [x] Linux x86_64 server fastdebug, additional new gtest to verify `remove_range` works > - [x] Linux x86_64 server fastdebug, `all` Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision: - Alternative fix - Remove old patch - Merge branch 'master' into JDK-8375046-growable-array-till-zero - Missing case - More tests - Merge branch 'master' into JDK-8375046-growable-array-till-zero - Revert - Leave only the C2 fix - Merge branch 'master' into JDK-8375046-growable-array-till-zero - Only clear pos when needed - ... and 3 more: https://git.openjdk.org/jdk/compare/3ecdecf8...2f755fb5 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29171/files - new: https://git.openjdk.org/jdk/pull/29171/files/bbcc37ea..2f755fb5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29171&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29171&range=04-05 Stats: 23206 lines in 705 files changed: 10204 ins; 4207 del; 8795 mod Patch: https://git.openjdk.org/jdk/pull/29171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29171/head:pull/29171 PR: https://git.openjdk.org/jdk/pull/29171 From shade at openjdk.org Wed Jan 28 09:51:32 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 28 Jan 2026 09:51:32 GMT Subject: RFR: 8375046: C2: Incremental inlining step asserts when processing empty late inlines list [v4] In-Reply-To: <9PqllSJF-_pStpPeBK3yqLZLaeO15h1ryIsXZjS9wYg=.3f0a47f5-53ce-4000-afc9-64d3db08464a@github.com> References: <_tSvASngm2bL0X2wavXI63kJZoypsY5S-dus_KGhs18=.ace489be-48bf-4254-a88e-b4fe456edf02@github.com> <9PqllSJF-_pStpPeBK3yqLZLaeO15h1ryIsXZjS9wYg=.3f0a47f5-53ce-4000-afc9-64d3db08464a@github.com> Message-ID: On Wed, 28 Jan 2026 09:36:08 GMT, Aleksey Shipilev wrote: > I'll move `GrowableArray` improvement to a separate PR. That would be [JDK-8376570](https://bugs.openjdk.org/browse/JDK-8376570) and https://github.com/openjdk/jdk/pull/29462. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29171#issuecomment-3810183608 From shade at openjdk.org Wed Jan 28 09:55:00 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 28 Jan 2026 09:55:00 GMT Subject: RFR: 8376570: GrowableArray::remove_{till, range} should work on empty list Message-ID: Split from [JDK-8375046](https://bugs.openjdk.org/browse/JDK-8375046), we want to make sure GrowableArray removal methods work appropriately with empty lists. Testing: - [x] New test - [ ] Linux x86_64 server fastdebug, `all` (in course of [JDK-8375046](https://bugs.openjdk.org/browse/JDK-8375046) testing) ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/29462/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29462&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376570 Stats: 122 lines in 2 files changed: 115 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/29462.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29462/head:pull/29462 PR: https://git.openjdk.org/jdk/pull/29462 From stuefe at openjdk.org Wed Jan 28 10:01:11 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 28 Jan 2026 10:01:11 GMT Subject: RFR: 8353564: Fail fatally if os::release_memory or os::uncommit_memory fails [v4] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 22:27:37 GMT, Robert Toyonaga wrote: >> This PR is a follow up to JDK-8341491. See original discussion: https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700 >> >> This PR makes `os::release_memory`, `os::uncommit_memory`, `os::release_memory_special`, and `os::unmap_memory` fail fatally if they encounter an error. These methods require obtaining the NMT lock. Fatally failing in these places would potentially allow for the tightening of NMT virtual memory locking scopes (future work, if this PR is accepted). Already in most cases, the callers fail fatally or assert(false) when these os:: methods fail. Another reason to fatally fail is that if the OS memory operation fails, it can be difficult to know for sure what state the OS left the memory in and recover. >> >> `release_memory`/`uncommit_memory`/`release_memory_special`/`unmap_memory` can fail due to ? Bad arguments, or ? The OS encountered an issue out of control of the JVM. >> >> ? >> If there is a JVM bug, it's probably reasonable to fatally fail here. Or the caller could be intentionally passing arguments that may or may not be valid. I don't think there is any code like that currently, and this is probably a bad pattern to be following anyway. >> >> ? >> In platform dependent code: >> With regard to mmap/munmap, the only errors that aren't due to bad arguments are ENOMEM and ones related to file descriptors (which are not applicable to uncommit or release). >> On Windows, VirtualFree only fails due to bad arguments. >> On AIX, shmdt and disclaim64 only fail due to bad arguments. msync could spontaneously fail with EIO: "An I/O error occurred while reading from or writing to the file system." >> On BSD, it seems like mprotect and madvise fail only due to bad arguments or invalid privileges. >> >> In the [original discussion](https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700), the main question was whether ENOMEM upon os::uncommit_memory was recoverable. This may be possible if we uncommit the middle of a region - splitting it in two. This could exceed the limit of the number of mappings resulting in ENOMEM. >> >> If none of the scenarios in ? are recoverable, then perhaps fatally failing is OK. >> >> Testing: >> - Tier 1. >> - Manual testing to make sure we fatally fail and the correct messages are printed. > > Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision: > > make remove_stack_guard_pages return void It looks okay; but please, as @dholmes-ora suggested, remove the explicit false from the os::uncommit calls. Passing the executable flag to uncommit feels strange and ugly anyway, though I remember why we do this. But we could continue to rely on the default parameter. That would also make the diff smaller and a bit easier to review. src/hotspot/os/windows/os_windows.cpp line 3260: > 3258: aligned_base = align_up(extra_base, alignment); > 3259: > 3260: if ((file_desc != -1)) { get rid of double brackets? src/hotspot/os/windows/os_windows.cpp line 3263: > 3261: os::unmap_memory(extra_base, extra_size); > 3262: } else { > 3263: os::release_memory(extra_base, extra_size); Pre-existing, but all these ugly reserve-release-reserve hacks on Windows can probably now replaced with a clean and non-racy version using VirtualAlloc2 and MEM_RESERVE_PLACEHOLDER. I opened https://bugs.openjdk.org/browse/JDK-8376561 for that. ------------- PR Review: https://git.openjdk.org/jdk/pull/29240#pullrequestreview-3715093432 PR Review Comment: https://git.openjdk.org/jdk/pull/29240#discussion_r2735302884 PR Review Comment: https://git.openjdk.org/jdk/pull/29240#discussion_r2735358936 From aph at openjdk.org Wed Jan 28 10:19:48 2026 From: aph at openjdk.org (Andrew Haley) Date: Wed, 28 Jan 2026 10:19:48 GMT Subject: RFR: 8374349: [VectorAPI]: AArch64: Prefer merging mode SVE CPY instruction In-Reply-To: References: <_0ouKSVAIyzg0g9hA2jZXNH-_cCqJjNCSh7kM2dn80w=.b93145c3-c465-423a-ab68-c8d7bd7e4280@github.com> <_qJ_Qo_Mqexx7dYu0Vkc9ru4SxZ0izfqifaUIAL1iyQ=.741b11d4-a89d-495e-8d31-78fed690abf6@github.com> Message-ID: On Wed, 28 Jan 2026 04:05:15 GMT, Eric Fang wrote: > Therefore, when you test this change using the C case, you will see a significant performance improvement. > > > I see 2% uplift on these numbers. > > @theRealAph And I think this also explains your question on these numbers. Not at all. The performance claim above was: > Microbenchmarks show this change brings performance uplift ranging from 11% to 33%, depending on the specific operation and data types. But the real performance uplift, as measured in Java microbenchmarks, is 2%. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29359#issuecomment-3810374167 From bmaillard at openjdk.org Wed Jan 28 10:25:25 2026 From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard) Date: Wed, 28 Jan 2026 10:25:25 GMT Subject: RFR: 8370519: C2: Hit MemLimit when running with +VerifyLoopOptimizations [v6] In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 15:42:42 GMT, Roland Westrelin wrote: >> For this failure memory stats are: >> >> >> Total Usage: 1095525816 >> --- Arena Usage by Arena Type and compilation phase, at arena usage peak of 1095525816 --- >> Phase Total ra node comp type states reglive regsplit regmask superword cienv ha other >> none 5976032 331560 5402064 197512 33712 10200 0 0 984 0 0 0 0 >> parse 2716464 65456 1145480 196408 1112752 0 0 0 0 0 196368 0 0 >> optimizer 98184 0 32728 0 65456 0 0 0 0 0 0 0 0 >> connectionGraph 32728 0 0 32728 0 0 0 0 0 0 0 0 0 >> iterGVN 32728 0 32728 0 0 0 0 0 0 0 0 0 0 >> idealLoop 918189632 0 38687056 872824784 392776 0 0 0 0 0 6285016 0 0 >> idealLoopVerify 2228144 0 0 2228144 0 0 0 0 0 0 0 0 0 >> macroExpand 32728 0 32728 0 0 0 0 0 0 0 0 0 0 >> graphReshape 32728 0 32728 0 0 0 0 0 0 0 0 0 0 >> matcher 20135944 3369848 9033208 7536400 65456 131032 0 0 0 0 0 0 0 >> postselect_cleanup 294872 294872 0 0 0 0 0 0 0 0 0 0 0 >> scheduler 752944 196488 556456 0 0 0 0 0 0 0 0 0 0 >> regalloc 388736 388736 0 0 0 0 0 0 0 0 0 0 0 >> ... > > Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision: > > package declaration I was able to come up with this test, which is a bit more that 2 times faster than the original one on my machine. Its `memlimit` is set to `600M`, which is enough to make the old version fail. With the new one, the test passes even with a `memlimit` of `200M`, so this should be a good enough margin. While looking into this I have also found out that some programs have an unexpectedly high usage of `output` (as was the case in the test case that I initially suggested). I am trying to get a good reproducer and will most likely file a follow-up. /** * @test * @key stress randomness * @bug 8370519 * @summary C2: Hit MemLimit when running with +VerifyLoopOptimizations * @run main/othervm -XX:CompileCommand=compileonly,${test.main.class}::* -XX:-TieredCompilation -Xbatch * -XX:+UnlockDiagnosticVMOptions -XX:+IgnoreUnrecognizedVMOptions * -XX:+StressLoopPeeling -XX:+VerifyLoopOptimizations * -XX:CompileCommand=memlimit,${test.main.class}::*,600M~crash * -XX:StressSeed=3106998670 ${test.main.class} * @run main ${test.main.class} */ package compiler.c2; public class TestVerifyLoopOptimizationsHighMemUsage { public static final int N = 400; public static long instanceCount = -13L; public static volatile short sFld = -16143; public static int iFld = -159; public static float fArrFld[] = new float[N]; public static long lMeth(int i1) { int i2 = 11, i3 = 37085, i4 = 177, i5 = 190, i6 = -234, i7 = 13060, iArr[] = new int[N]; float f = 1.179F; double d = 2.9685; long lArr[] = new long[N]; for (i2 = 15; i2 < 330; ++i2) for (i4 = 1; i4 < 5; ++i4) { fArrFld[i4 + 1] = (++i1); for (i6 = 2; i6 > 1; i6 -= 3) switch ((i2 * 5) + 54) { case 156: if (i4 != 0) ; case 168: case 342: case 283: case 281: case 328: case 322: case 228: case 114: case 207: case 209: case 354: case 108: i1 <<= i1; case 398: case 144: case 218: case 116: case 296: case 198: case 173: case 105: case 120: case 248: case 140: case 352: try { } catch (ArithmeticException a_e) { } case 404: i5 += (i6 ^ instanceCount); case 370: case 211: case 231: try { } catch (ArithmeticException a_e) { } case 251: case 179: f += (((i6 * sFld) + i4) - iFld); } } long meth_res = i1 + i2 + i3 + i4 + i5 + i6 + i7 + Float.floatToIntBits(f) + Double.doubleToLongBits(d) + +checkSum(iArr) + checkSum(lArr); return meth_res; } public static long checkSum(int[] a) { long sum = 0; for (int j = 0; j < a.length; j++) sum += (a[j] / (j + 1) + a[j] % (j + 1)); return sum; } public static long checkSum(long[] a) { long sum = 0; for (int j = 0; j < a.length; j++) sum += (a[j] / (j + 1) + a[j] % (j + 1)); return sum; } public static void main(String[] strArr) { for (int i = 0; i < 10; i++) lMeth(-159); } } ------------- PR Comment: https://git.openjdk.org/jdk/pull/28581#issuecomment-3810407567 From aph at openjdk.org Wed Jan 28 10:36:35 2026 From: aph at openjdk.org (Andrew Haley) Date: Wed, 28 Jan 2026 10:36:35 GMT Subject: RFR: 8374349: [VectorAPI]: AArch64: Prefer merging mode SVE CPY instruction In-Reply-To: <_0ouKSVAIyzg0g9hA2jZXNH-_cCqJjNCSh7kM2dn80w=.b93145c3-c465-423a-ab68-c8d7bd7e4280@github.com> References: <_0ouKSVAIyzg0g9hA2jZXNH-_cCqJjNCSh7kM2dn80w=.b93145c3-c465-423a-ab68-c8d7bd7e4280@github.com> Message-ID: On Thu, 22 Jan 2026 12:31:19 GMT, Eric Fang wrote: > When optimizing some VectorMask related APIs , we found an optimization opportunity related to the `cpy (immediate, zeroing)` instruction [1]. Implementing the functionality of this instruction using `cpy (immediate, merging)` instruction [2] leads to better performance. > > Currently the `cpy (imm, zeroing)` instruction is used in code generated by `VectorStoreMaskNode` and `VectorReinterpretNode`. Doing this optimization benefits all vector APIs that generate these two IRs potentially, such as `VectorMask.intoArray()` and `VectorMask.toLong()`. > > Microbenchmarks show this change brings performance uplift ranging from **11%** to **33%**, depending on the specific operation and data types. > > The specific changes in this PR: > 1. Achieve the functionality of the `cpy (imm, zeroing)` instruction with the `movi + cpy (imm, merging)` instructions in assembler: > > cpy z17.d, p1/z, #1 => > > movi v17.2d, #0 // this instruction is zero cost > cpy z17.d, p1/m, #1 > > > 2. Add a new option `PreferSVEMergingModeCPY` to indicate whether to apply this optimization or not. > - This option belongs to the Arch product category. > - The default value is true on Neoverse-V1/V2 where the improvement has been confirmed, false on others. > - When its value is true, the change is applied. > > 3. Add a jtreg test to verify the behavior of this option. > > This PR was tested on aarch64 and x86 machines with different configurations, and all tests passed. > > JMH benchmarks: > > On a Nvidia Grace (Neoverse-V2) machine with 128-bit SVE2: > > Benchmark Unit size Before Error After Error Uplift > byteIndexInRange ops/ms 7.00 471816.15 1125.96 473237.77 1593.92 1.00 > byteIndexInRange ops/ms 256.00 149654.21 416.57 149259.95 116.59 1.00 > byteIndexInRange ops/ms 259.00 177850.31 991.13 179785.19 1110.07 1.01 > byteIndexInRange ops/ms 512.00 133393.26 167.26 133484.61 281.83 1.00 > doubleIndexInRange ops/ms 7.00 302176.39 12848.8 299813.02 37.76 0.99 > doubleIndexInRange ops/ms 256.00 47831.93 56.70 46708.70 56.11 0.98 > doubleIndexInRange ops/ms 259.00 11550.02 27.95 15333.50 10.40 1.33 > doubleIndexInRange ops/ms 512.00 23687.76 61.65 23996.08 69.52 1.01 > floatIndexInRange ops/ms 7.00 412195.79 124.71 411770.23 78.73 1.00 > floatIndexInRange ops/ms 256.00 84479.98 70.69 84237.31 70.15 1.00 > floatIndexInRange ops/ms 259.00 22585.65 80.07 28296.21 7.98 1.25 > floatIndexInRange ops/ms 512.00 46902.99 51.60 46686.68 66.01 1.00 > intIndexInRange ops/ms 7.00 413411.70 50.59 420684.66 253.55 1.02 > intIndexInRange ops/... src/hotspot/cpu/aarch64/assembler_aarch64.hpp line 3849: > 3847: movi(Zd, T2D, 0); > 3848: isMerge = true; > 3849: } Definitions in `Assembler` should generate the instructions in the Architecture reference Manual. When doing this, please override `sve_cpy` in `MacroAssembler` instead of here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29359#discussion_r2735993449 From egahlin at openjdk.org Wed Jan 28 11:01:46 2026 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 28 Jan 2026 11:01:46 GMT Subject: RFR: 8373096: JFR: Path-to-gc-roots search should be non-recursive [v3] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 07:53:47 GMT, Thomas Stuefe wrote: >> This is a continuation - second attempt - of https://github.com/openjdk/jdk/pull/28659. >> >> ---- >> >> A customer reported a native stack overflow when producing a JFR recording with path-to-gc-roots=true. This happens regularly, see similar cases in JBS (e.g. https://bugs.openjdk.org/browse/JDK-8371630, https://bugs.openjdk.org/browse/JDK-8282427 etc). >> >> We limit the maximum graph search depth (DFSClosure::max_dfs_depth) to prevent stack overflows. That solution is brittle, however, since recursion depth is not a good proxy for thread stack usage: it depends on many factors, e.g., compiler inlining decisions and platform specifics. In this case, the VMThread's stack was too small. >> >> This patch rewrites the DFS heap tracer to be non-recursive. This is mostly textbook stuff, but the devil is in the details. Nevertheless, the algorithm should be a straightforward read. >> >> ### Memory usage of old vs new algorithm: >> >> The new algorithm uses, on average, a bit less memory than the old one. The old algorithm did cost ((avg stackframe size in bytes) * depth). As we have seen, e.g., in JDK-8371630, a depth of 3200 can max out ~1MB of stack space. >> >> The new algorithm costs ((avg number of outgoing refs per instanceKlass oop) * depth * 16. For a depth of 3200, we get typical probe stack sizes of 100KB..200KB. But we also cap probestack size, similar to how we cap the max. graph depth. >> >> In any case, these numbers are nothing to worry about. For a more in-depth explanation about memory cost, please see the comment in dfsClosure.cpp. >> >> ### Possible improvements/simplifications in the future: >> >> DFS works perfectly well alone now. It no longer depends on stack size, and its memory usage is typically smaller than BFS. IMHO, it would be perfectly fine to get rid of BFS and rely solely on the non-recursive DFS. The benefit would be a decrease in complexity and fewer tests to run and maintain. It should also be easy to convert into a parallelized version later. >> >> I kept the _max_dfs_depth_ parameter for now, but tbh it is no longer very useful. Before, it prevented stack overflows. Now, it is just an indirect way to limit probe stack size. But we also explicitly cap the probe stack size, so _max_dfs_depth_ is redundant. Removing it would require changing the statically allocated reference stack to be dynamically allocated, but that should not be difficult. >> >> ### Observable differences >> >> There is one observable side effect to the changed a... > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > dont incremement _num_objects_processed for follow-up chunks src/hotspot/share/jfr/leakprofiler/chains/dfsClosure.cpp line 152: > 150: assert(_probe_stack.is_empty(), "We should have drained the probe stack?"); > 151: } > 152: log_info(jfr, system, dfs)("DFS: objects processed: " UINT64_FORMAT "," I think it would be better to use the already existing oldobject log tag instead of a new dfs tag. Also, info is a bit verbose, debug might be better. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29382#discussion_r2736092382 From sjohanss at openjdk.org Wed Jan 28 11:06:29 2026 From: sjohanss at openjdk.org (Stefan Johansson) Date: Wed, 28 Jan 2026 11:06:29 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v8] In-Reply-To: References: Message-ID: <1yNQc7QkIDbQ7WvVCHICL4dDN036pPD373wE3H200R4=.43d38367-6988-4531-829f-349d206250f8@github.com> On Tue, 27 Jan 2026 18:42:51 GMT, Leo Korinth wrote: >> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. >> >> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. >> >> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. >> >> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. > > Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: > > - Revert "Stefan J 4" > > This reverts commit 203d11979524126add9ee5d04174bde07a5a3f5a. > - Revert "remove commented out code" > > This reverts commit 9d9df671574be7a15a30ef0af452629330cb4fd1. > - Merge branch 'master' into _8367993 > - Merge branch '_master_jdk' into _8367993 > - Merge branch '_8373253' into _8367993 > - rename of method > - Proposal by Stefan J > - wip > - Revert "8373253: Re-work InjectGCWorkerCreationFailure for future changes" > > This reverts commit d45ea8817ab2303b2decd8cbb2cd1bf5280aa181. > - Revert "Fixup after comment from Ivan." > > This reverts commit 2aa8aa4b68027b62a8d4be1b86720fadfa48dda5. > - ... and 11 more: https://git.openjdk.org/jdk/compare/90b54692...c5a7e2bb Changes requested by sjohanss (Reviewer). src/hotspot/share/gc/g1/g1YoungCollector.cpp line 1128: > 1126: > 1127: void G1YoungCollector::collect() { > 1128: _g1h->_cm->fully_initialize(); Why did you revert the call to this location? Instead of having it in G1CollectedHeap::do_collection_pause_at_safepoint()? ------------- PR Review: https://git.openjdk.org/jdk/pull/28723#pullrequestreview-3716074772 PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2736113065 From shade at openjdk.org Wed Jan 28 11:08:05 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 28 Jan 2026 11:08:05 GMT Subject: RFR: 8360557: CTW: Inline cold methods to reach more code [v12] In-Reply-To: References: Message-ID: > We use CTW testing for making sure compilers behave well. But we compile the code that is not executed at all, and since our inlining heuristics often looks back at profiles, we end up not actually inlining all too much! This means CTW testing likely misses lots of bugs that normal code is exposed to, especially e.g. in loop optimizations. > > There is an intrinsic tradeoff with accepting more inilned methods in CTW: the compilation time gets significantly worse. With just accepting the cold methods we have reasonable CTW times, eating the improvements we have committed in mainline recently. And it still finds bugs. See the RFE for sample data. > > After this lands and CTW starts to compile cold methods, one can greatly expand the scope of the CTW testing by overriding the static inlining limits. Doing e.g. `TEST_VM_OPTS="-XX:MaxInlineSize=70 -XX:C1MaxInlineSize=70"` finds even more bugs. Unfortunately, the compilation times suffer so much, they are impractical to run in standard configurations, see data in RFE. We will enable some of that testing in special testing pipelines. > > Pre-empting the question: "Well, why not use -Xcomp then, and make sure it inlines well?" The answer is in RFE as well: Xcomp causes _a lot_ of stray compilations for JDK and CTW infra itself. For small JARs in large corpus this eats precious testing time that we would instead like to spend on deeper inlining in the actual JAR code. This also does not force us to look into how CTW works in Xcomp at all; I expect some surprises there. Feather-touching the inlining heuristic paths to just accept methods without looking at profiles looks better. > > Tobias had an idea to implement the stress randomized inlining that would expand the scope of inlining. This improvement stacks well with it. This improvement provides the base case of inlining most reasonable methods, and then allow stress infra to inline some more on top of that. > > Additional testing: > - [x] GHA > - [x] Linux x86_64 server fastdebug, `applications/ctw/modules` > - [x] Linux x86_64 server fastdebug, large CTW corpus (now failing in interesting ways) 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 11 additional commits since the last revision: - Roll in good fix - Revert bad fix - Merge branch 'master' into JDK-8360557-ctw-inlining - Coopt InlineColdMethods to drive inlining decisions when Xcomp is enabled - Merge branch 'master' into JDK-8360557-ctw-inlining - JDK-8375046 fix - JDK-8375694 POC fix - Merge branch 'master' into JDK-8360557-ctw-inlining - Debug - Merge branch 'master' into JDK-8360557-ctw-inlining - ... and 1 more: https://git.openjdk.org/jdk/compare/c151a68c...f1a06e35 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26068/files - new: https://git.openjdk.org/jdk/pull/26068/files/6513fc52..f1a06e35 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26068&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26068&range=10-11 Stats: 21678 lines in 638 files changed: 9471 ins; 3867 del; 8340 mod Patch: https://git.openjdk.org/jdk/pull/26068.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26068/head:pull/26068 PR: https://git.openjdk.org/jdk/pull/26068 From ghan at openjdk.org Wed Jan 28 11:09:09 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Wed, 28 Jan 2026 11:09:09 GMT Subject: RFR: 8374516: -version asserts with "-XX:+UseAESCTRIntrinsics -XX:-UseAES": "need AES instructions and misaligned SSE support" in generate_counterMode_AESCrypt_Parallel() In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 08:32:59 GMT, Guanqiang Han wrote: > Please review this change. Thanks! > > **Description:** > > VM crashes during startup on x86 when running with -XX:+UseAESCTRIntrinsics -XX:-UseAES. In this configuration, UseAESCTRIntrinsics may remain enabled while UseAES is explicitly disabled, and the VM generates AES-CTR stubs, hitting an assert(UseAES) in generate_counterMode_AESCrypt_Parallel(). > > **Fix:** > > Update x86 flag initialization to enforce the dependency between UseAESCTRIntrinsics and UseAES. When UseAES is disabled, explicitly disable UseAESCTRIntrinsics (with a warning when it was set on the command line), aligning behavior with the existing UseAES/UseAESIntrinsics gating and avoiding stub generation with inconsistent flag states. > > **Test:** > > GHA Hi @vnkozlov and @ascarpino , Sorry for the ping ? could you please take a look at this PR when you have a moment? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29338#issuecomment-3810647933 From ysuenaga at openjdk.org Wed Jan 28 11:10:48 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Wed, 28 Jan 2026 11:10:48 GMT Subject: RFR: 8374926: EnableX86ECoreOpts was not enabled on some hybrid CPU [v5] In-Reply-To: References: Message-ID: On Sat, 24 Jan 2026 02:38:22 GMT, Yasumasa Suenaga wrote: >> `EnableX86ECoreOpts` has been introduced in [JDK-8319429](https://bugs.openjdk.org/browse/JDK-8319429), however model numbers which should be enabled are hard-coded, so the flag would not be enabled by default on some models like Arrow Lake. >> >> I ran a [benchmark](https://github.com/YaSuenag/garakuta/tree/master/randminmax) to check for effectiveness of `-XX:+EnableX86ECoreOpts` with JDK 25.0.1 on Windows 11 25H2, I saw performance improvement a bit on Intel Core 5 Ultra 225U as following: >> >> Disabled (default) >> >> Benchmark Mode Cnt Score Error Units >> RandMinVal.getMax thrpt 3 9707774.405 ? 27082629.015 ops/s >> RandMinVal.getMin thrpt 3 7510319.839 ? 10923547.382 ops/s >> >> >> Enabled >> >> Benchmark Mode Cnt Score Error Units >> RandMinVal.getMax thrpt 3 10127809.127 ? 45404142.338 ops/s >> RandMinVal.getMin thrpt 3 8467677.056 ? 1211998.200 ops/s >> >> >> So I think it is better to enable this flag by default on all of hybrid CPUs. >> >> >> To check what processor would be enabled E-core optimization, I made a [commit](https://github.com/openjdk/jdk/commit/f363ea1436b8100021fdac87b48ec43bcf6820af) to add comments for CPU models at first. I couldn't find out all of models (some models has not listed in SDM vol.4 so far), but most of models (excepts Sierra Forest) could be treated as hybrid CPU. Fortunately HotSpot identify hybrid flag from `CPUID`, so we can leverage it for this purpose. > > Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: > > - Add condition for CWF > - Revert "Check E-Core with Leaf 1Ah" > > This reverts commit d77b43937911b33bf39175e45e3d9d97aa949617. Thanks a lot for your help! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29149#issuecomment-3810652432 From ysuenaga at openjdk.org Wed Jan 28 11:14:47 2026 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Wed, 28 Jan 2026 11:14:47 GMT Subject: Integrated: 8374926: EnableX86ECoreOpts was not enabled on some hybrid CPU In-Reply-To: References: Message-ID: On Sat, 10 Jan 2026 03:34:22 GMT, Yasumasa Suenaga wrote: > `EnableX86ECoreOpts` has been introduced in [JDK-8319429](https://bugs.openjdk.org/browse/JDK-8319429), however model numbers which should be enabled are hard-coded, so the flag would not be enabled by default on some models like Arrow Lake. > > I ran a [benchmark](https://github.com/YaSuenag/garakuta/tree/master/randminmax) to check for effectiveness of `-XX:+EnableX86ECoreOpts` with JDK 25.0.1 on Windows 11 25H2, I saw performance improvement a bit on Intel Core 5 Ultra 225U as following: > > Disabled (default) > > Benchmark Mode Cnt Score Error Units > RandMinVal.getMax thrpt 3 9707774.405 ? 27082629.015 ops/s > RandMinVal.getMin thrpt 3 7510319.839 ? 10923547.382 ops/s > > > Enabled > > Benchmark Mode Cnt Score Error Units > RandMinVal.getMax thrpt 3 10127809.127 ? 45404142.338 ops/s > RandMinVal.getMin thrpt 3 8467677.056 ? 1211998.200 ops/s > > > So I think it is better to enable this flag by default on all of hybrid CPUs. > > > To check what processor would be enabled E-core optimization, I made a [commit](https://github.com/openjdk/jdk/commit/f363ea1436b8100021fdac87b48ec43bcf6820af) to add comments for CPU models at first. I couldn't find out all of models (some models has not listed in SDM vol.4 so far), but most of models (excepts Sierra Forest) could be treated as hybrid CPU. Fortunately HotSpot identify hybrid flag from `CPUID`, so we can leverage it for this purpose. This pull request has now been integrated. Changeset: 127bfc9b Author: Yasumasa Suenaga URL: https://git.openjdk.org/jdk/commit/127bfc9b0dd122c78e702867a88e0847ec362e68 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod 8374926: EnableX86ECoreOpts was not enabled on some hybrid CPU Reviewed-by: vpaprotski, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/29149 From stefank at openjdk.org Wed Jan 28 12:23:36 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 28 Jan 2026 12:23:36 GMT Subject: RFR: 8353564: Fail fatally if os::release_memory or os::uncommit_memory fails [v4] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 22:27:37 GMT, Robert Toyonaga wrote: >> This PR is a follow up to JDK-8341491. See original discussion: https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700 >> >> This PR makes `os::release_memory`, `os::uncommit_memory`, `os::release_memory_special`, and `os::unmap_memory` fail fatally if they encounter an error. These methods require obtaining the NMT lock. Fatally failing in these places would potentially allow for the tightening of NMT virtual memory locking scopes (future work, if this PR is accepted). Already in most cases, the callers fail fatally or assert(false) when these os:: methods fail. Another reason to fatally fail is that if the OS memory operation fails, it can be difficult to know for sure what state the OS left the memory in and recover. >> >> `release_memory`/`uncommit_memory`/`release_memory_special`/`unmap_memory` can fail due to ? Bad arguments, or ? The OS encountered an issue out of control of the JVM. >> >> ? >> If there is a JVM bug, it's probably reasonable to fatally fail here. Or the caller could be intentionally passing arguments that may or may not be valid. I don't think there is any code like that currently, and this is probably a bad pattern to be following anyway. >> >> ? >> In platform dependent code: >> With regard to mmap/munmap, the only errors that aren't due to bad arguments are ENOMEM and ones related to file descriptors (which are not applicable to uncommit or release). >> On Windows, VirtualFree only fails due to bad arguments. >> On AIX, shmdt and disclaim64 only fail due to bad arguments. msync could spontaneously fail with EIO: "An I/O error occurred while reading from or writing to the file system." >> On BSD, it seems like mprotect and madvise fail only due to bad arguments or invalid privileges. >> >> In the [original discussion](https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700), the main question was whether ENOMEM upon os::uncommit_memory was recoverable. This may be possible if we uncommit the middle of a region - splitting it in two. This could exceed the limit of the number of mappings resulting in ENOMEM. >> >> If none of the scenarios in ? are recoverable, then perhaps fatally failing is OK. >> >> Testing: >> - Tier 1. >> - Manual testing to make sure we fatally fail and the correct messages are printed. > > Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision: > > make remove_stack_guard_pages return void I went over the latest patch and added a few suggestions. src/hotspot/os/linux/os_linux.cpp line 3577: > 3575: return; > 3576: } > 3577: os::uncommit_memory(addr, size, false); Restore removed blank line: Suggestion: os::uncommit_memory(addr, size, false); src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1771: > 1769: void ShenandoahHeap::reclaim_aux_bitmap_for_iteration() { > 1770: if (!_aux_bitmap_region_special) { > 1771: os::uncommit_memory((char*)_aux_bitmap_region.start(), _aux_bitmap_region.byte_size(), false); Another uncommit with an extraneous false argument: Suggestion: os::uncommit_memory((char*)_aux_bitmap_region.start(), _aux_bitmap_region.byte_size()); src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2621: > 2619: > 2620: char* addr = (char*) _bitmap_region.start() + off; > 2621: os::uncommit_memory(addr, len, false); Suggestion: os::uncommit_memory(addr, len); src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 814: > 812: ShenandoahHeap* heap = ShenandoahHeap::heap(); > 813: if (!heap->is_heap_region_special()) { > 814: os::uncommit_memory((char *) bottom(), RegionSizeBytes, false); Suggestion: os::uncommit_memory((char *) bottom(), RegionSizeBytes); src/hotspot/share/memory/metaspace/virtualSpaceNode.cpp line 193: > 191: > 192: // Uncommit... > 193: os::uncommit_memory((char*)p, word_size * BytesPerWord, false); Suggestion: os::uncommit_memory((char*)p, word_size * BytesPerWord); ------------- PR Review: https://git.openjdk.org/jdk/pull/29240#pullrequestreview-3716368580 PR Review Comment: https://git.openjdk.org/jdk/pull/29240#discussion_r2736340461 PR Review Comment: https://git.openjdk.org/jdk/pull/29240#discussion_r2736358193 PR Review Comment: https://git.openjdk.org/jdk/pull/29240#discussion_r2736358685 PR Review Comment: https://git.openjdk.org/jdk/pull/29240#discussion_r2736359823 PR Review Comment: https://git.openjdk.org/jdk/pull/29240#discussion_r2736361893 From jsikstro at openjdk.org Wed Jan 28 13:08:23 2026 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 28 Jan 2026 13:08:23 GMT Subject: RFR: 8371777: Clean up preferred address of G1's archive region In-Reply-To: <7eIqYfnErWOUoWNEYH1R0GJjKNBQLIzi4biECVggAR0=.341543f8-53a1-4a08-b852-c5f12d13b82c@github.com> References: <7eIqYfnErWOUoWNEYH1R0GJjKNBQLIzi4biECVggAR0=.341543f8-53a1-4a08-b852-c5f12d13b82c@github.com> Message-ID: On Tue, 20 Jan 2026 12:49:05 GMT, Paul H?bner wrote: > Hi all, > > There exists infrastructure in G1 to map the archived region at a certain address, `preferred_addr`. This was however never implemented and abandoned in favour of JEP 516. This is a small cleanup that removes the unused parameter. > > Note: the `requested_start` address is still necessary to compute pointer deltas and to perform patching if necessary. If folks feel like `requested` is a misleading name I'm happy to address that as part of a separate RFE. > > Testing: tiers 1-5 Linux (x64, AArch64), macOS (x64, AArch64), Windows x64. Looks good. I think the naming should have been "desired" all the way, not "requested". That way we'd use the "desired" value for the request to allocate the archive region (which we now remove). Sounds good with a follow-up. ------------- Marked as reviewed by jsikstro (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29317#pullrequestreview-3716603148 From phubner at openjdk.org Wed Jan 28 13:13:05 2026 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Wed, 28 Jan 2026 13:13:05 GMT Subject: RFR: 8371777: Clean up preferred address of G1's archive region In-Reply-To: <7eIqYfnErWOUoWNEYH1R0GJjKNBQLIzi4biECVggAR0=.341543f8-53a1-4a08-b852-c5f12d13b82c@github.com> References: <7eIqYfnErWOUoWNEYH1R0GJjKNBQLIzi4biECVggAR0=.341543f8-53a1-4a08-b852-c5f12d13b82c@github.com> Message-ID: On Tue, 20 Jan 2026 12:49:05 GMT, Paul H?bner wrote: > Hi all, > > There exists infrastructure in G1 to map the archived region at a certain address, `preferred_addr`. This was however never implemented and abandoned in favour of JEP 516. This is a small cleanup that removes the unused parameter. > > Note: the `requested_start` address is still necessary to compute pointer deltas and to perform patching if necessary. If folks feel like `requested` is a misleading name I'm happy to address that as part of a separate RFE. > > Testing: tiers 1-5 Linux (x64, AArch64), macOS (x64, AArch64), Windows x64. Thanks for the reviews Stefan and Joel! I'll file a follow-up RFE. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29317#issuecomment-3811213039 From duke at openjdk.org Wed Jan 28 13:13:06 2026 From: duke at openjdk.org (duke) Date: Wed, 28 Jan 2026 13:13:06 GMT Subject: RFR: 8371777: Clean up preferred address of G1's archive region In-Reply-To: <7eIqYfnErWOUoWNEYH1R0GJjKNBQLIzi4biECVggAR0=.341543f8-53a1-4a08-b852-c5f12d13b82c@github.com> References: <7eIqYfnErWOUoWNEYH1R0GJjKNBQLIzi4biECVggAR0=.341543f8-53a1-4a08-b852-c5f12d13b82c@github.com> Message-ID: <5LlhuI7TgpNhP9FcZ5P6KLqBofDRTFY3O6NXi9b9luM=.37783c8c-e606-4b48-938b-125cfb8b85b5@github.com> On Tue, 20 Jan 2026 12:49:05 GMT, Paul H?bner wrote: > Hi all, > > There exists infrastructure in G1 to map the archived region at a certain address, `preferred_addr`. This was however never implemented and abandoned in favour of JEP 516. This is a small cleanup that removes the unused parameter. > > Note: the `requested_start` address is still necessary to compute pointer deltas and to perform patching if necessary. If folks feel like `requested` is a misleading name I'm happy to address that as part of a separate RFE. > > Testing: tiers 1-5 Linux (x64, AArch64), macOS (x64, AArch64), Windows x64. @Arraying Your change (at version 66c503625dd53390d5a30291bee64f4667f4bd30) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29317#issuecomment-3811220167 From phubner at openjdk.org Wed Jan 28 13:18:27 2026 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Wed, 28 Jan 2026 13:18:27 GMT Subject: Integrated: 8371777: Clean up preferred address of G1's archive region In-Reply-To: <7eIqYfnErWOUoWNEYH1R0GJjKNBQLIzi4biECVggAR0=.341543f8-53a1-4a08-b852-c5f12d13b82c@github.com> References: <7eIqYfnErWOUoWNEYH1R0GJjKNBQLIzi4biECVggAR0=.341543f8-53a1-4a08-b852-c5f12d13b82c@github.com> Message-ID: On Tue, 20 Jan 2026 12:49:05 GMT, Paul H?bner wrote: > Hi all, > > There exists infrastructure in G1 to map the archived region at a certain address, `preferred_addr`. This was however never implemented and abandoned in favour of JEP 516. This is a small cleanup that removes the unused parameter. > > Note: the `requested_start` address is still necessary to compute pointer deltas and to perform patching if necessary. If folks feel like `requested` is a misleading name I'm happy to address that as part of a separate RFE. > > Testing: tiers 1-5 Linux (x64, AArch64), macOS (x64, AArch64), Windows x64. This pull request has now been integrated. Changeset: 2a465cb0 Author: Paul H?bner Committer: Joel Sikstr?m URL: https://git.openjdk.org/jdk/commit/2a465cb0eba6ffe397cf3ad8c1def06bf7a1e392 Stats: 6 lines in 3 files changed: 0 ins; 2 del; 4 mod 8371777: Clean up preferred address of G1's archive region Reviewed-by: stefank, jsikstro ------------- PR: https://git.openjdk.org/jdk/pull/29317 From adinn at openjdk.org Wed Jan 28 14:09:00 2026 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 28 Jan 2026 14:09:00 GMT Subject: RFR: 8372617: Save and restore stubgen stubs when using an AOT code cache [v5] In-Reply-To: References: Message-ID: > This PR adds save and restore of all generated stubs to the AOT code cache on x86 and aarch64. Other arches are modified to deal with the related generic PAI changes. > > Small changes were required to the aarch64 and x86_64 generator code in order to meet two key constraints: > 1. the first declared entry of every stub starts at the first instruction in the stub code range > 2. all data/code cross-references from one stub to another target a declared stub entry Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: added missing GC external addresses and speeded up address to id lookup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28433/files - new: https://git.openjdk.org/jdk/pull/28433/files/83855bef..d063ddf3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28433&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28433&range=03-04 Stats: 213 lines in 5 files changed: 73 ins; 0 del; 140 mod Patch: https://git.openjdk.org/jdk/pull/28433.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28433/head:pull/28433 PR: https://git.openjdk.org/jdk/pull/28433 From dfenacci at openjdk.org Wed Jan 28 16:10:53 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Wed, 28 Jan 2026 16:10:53 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v4] In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: > ## Issue > > This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. > > This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. > > ## Causes > > The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. > > ## Fix > > A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: > https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 > This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. > > # Testing > > * Tier 1-3+ > * 2 JTReg tests added > * `TestRangeCheck.java` as regression test for the reported issue > * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion Damon Fenacci has updated the pull request incrementally with five additional commits since the last revision: - JDK-8374582: fix indent - JDK-8374582: constant - JDK-8374582: add size_of - JDK-8374852: OpaqueCheck -> OpaqueConstantBool - JDK-8374852: fix number of OpaqueCheck nodes in test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29164/files - new: https://git.openjdk.org/jdk/pull/29164/files/0ef73ef9..a3690526 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=02-03 Stats: 162 lines in 16 files changed: 60 ins; 60 del; 42 mod Patch: https://git.openjdk.org/jdk/pull/29164.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29164/head:pull/29164 PR: https://git.openjdk.org/jdk/pull/29164 From dfenacci at openjdk.org Wed Jan 28 16:10:57 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Wed, 28 Jan 2026 16:10:57 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v3] In-Reply-To: References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: On Wed, 28 Jan 2026 08:13:23 GMT, Christian Hagedorn wrote: >> Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8374852: fix star layout >> >> Co-authored-by: Christian Hagedorn > > src/hotspot/share/opto/opaquenode.hpp line 146: > >> 144: // builds, we keep the actual checks as additional verification code (i.e. removing OpaqueCheckNodes and use the >> 145: // BoolNode inputs instead). >> 146: class OpaqueCheckNode : public Node { > > I've also thought about the name. `OpaqueCheck` is already a good indication what the node is about. Maybe we could go a step further and call it `OpaqueConstantBoolNode` to emphasize more that it is belonging to a `BoolNode` whose result we already know. What do you think? > > Then we could also think about changing `_positive` to `_constant` (still can be a boolean to just pass true and false which seems more intuitive then passing in 1 and 0). I was still had a doubt about what to put first (`Constant` or `Bool`) but I think `ConstantBool` is actually more correct. I suppose `_constant` is better than `_value` since we use it already ? Done. > src/hotspot/share/opto/opaquenode.hpp line 148: > >> 146: class OpaqueCheckNode : public Node { >> 147: private: >> 148: bool _positive; > > Now that we define a field, we also need to override `size_of()` (see for example `OpaqueMultiversioningNode`). Good to know. Thanks! > src/hotspot/share/opto/opaquenode.hpp line 150: > >> 148: bool _positive; >> 149: public: >> 150: OpaqueCheckNode(Compile* C, Node* tst, bool positive) : Node(nullptr, tst), _positive(positive) { > > `tst` is probably almost always a `BoolNode`. I'm wondering if it could also be a constant because we already folded the `BoolNode`? But then it's probably also useless to create the opaque node in the first place. Hmmm... I find it hard to totally exclude a constant (e.g. if its inputs are constant...?). In that case we could skip all the opaque business (I guess in the few places where new `OpaqueConstantBool` nodes are created). On the other hand the opaque node should only really delay the folding... ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2737356877 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2737353309 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2737355777 From alanb at openjdk.org Wed Jan 28 16:15:25 2026 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 28 Jan 2026 16:15:25 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases Message-ID: JDK-8364343 upgraded the virtual thread transition management to be independent of JVMTI. We can update java_lang_Thread::async_get_stack_trace to use it and remove the suspend + retry code from Thread.getStackTrace. A summary of the changes: - java_lang_Thread::async_get_stack_trace is changed to use the new handshake op so it can be called to get the stack trace of a started thread in any state - Thread::getStackTrace is changed to use async_get_stack_trace for all cases - The SUSPENDED substate in VirtualThread is removed - JVM_CreateThreadSnapshot is changed to be usable when JVMTI is not compiled in - ThreadSnapshotFactory::get_thread_snapshot is changed to not upcall to StackTraceElement to complete the init of the stack trace The changes mean that Thread::getStackTrace may be slower when sampling a virtual thread in transition. This case should be rare, and it isn't really a performance critical op anyway. I prototyped use a spin loop and an increasing wait time in MountUnmountDisabler::disable_transition_for_one to avoid the wait(10) but decided to leave it out for now. Future work may examine this issue as there may be other cases (with JVMTI) that would benefit from avoiding the wait. A future PR might propose to change Thread.getStackTrace to use ThreadSnapshot and allow java_lang_Thread::async_get_stack_trace be removed. This requires more extensive changes to ThreadSnapshotFactory to reduce overhead when only the stack trace is required. Testing: tier1-5. The changes has been already been tested in the loom repo for a few months. ------------- Commit messages: - Cleanup - Merge branch 'master' into Thread.getStackTrace - Initial commit Changes: https://git.openjdk.org/jdk/pull/29461/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29461&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376568 Stats: 656 lines in 19 files changed: 445 ins; 168 del; 43 mod Patch: https://git.openjdk.org/jdk/pull/29461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29461/head:pull/29461 PR: https://git.openjdk.org/jdk/pull/29461 From dfenacci at openjdk.org Wed Jan 28 16:23:21 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Wed, 28 Jan 2026 16:23:21 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v5] In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: > ## Issue > > This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. > > This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. > > ## Causes > > The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. > > ## Fix > > A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: > https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 > This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. > > # Testing > > * Tier 1-3+ > * 2 JTReg tests added > * `TestRangeCheck.java` as regression test for the reported issue > * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion Damon Fenacci has updated the pull request incrementally with two additional commits since the last revision: - JDK-8374582: fix comment layout - JDK-8374582: fix constructor argument name ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29164/files - new: https://git.openjdk.org/jdk/pull/29164/files/a3690526..bddec5b5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=03-04 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/29164.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29164/head:pull/29164 PR: https://git.openjdk.org/jdk/pull/29164 From duke at openjdk.org Wed Jan 28 16:29:05 2026 From: duke at openjdk.org (duke) Date: Wed, 28 Jan 2026 16:29:05 GMT Subject: Withdrawn: 8236073: G1: Use SoftMaxHeapSize to guide GC heuristics In-Reply-To: <8jjBh52pZlAjsLJ4ce1oacnDVdu8qCe2pJYApXsU5HM=.462adbdd-e3b7-4d4a-a130-aecadba36b00@github.com> References: <8jjBh52pZlAjsLJ4ce1oacnDVdu8qCe2pJYApXsU5HM=.462adbdd-e3b7-4d4a-a130-aecadba36b00@github.com> Message-ID: On Fri, 26 Sep 2025 11:45:52 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to implement `SoftMaxHeapSize` for G1. > > Main change is that `SoftMaxHeapSize` now impacts the `G1IHOPControl::target_occupancy()`, i.e. the amount of bytes G1 when reclaim should start. > > Most of the other changes are just about updating logging/JFR and making sure that the `SoftMaxHeapSize` values are consistent across calls. > > Testing: tier1-5 > > Thanks, > Thomas This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27524 From psandoz at openjdk.org Wed Jan 28 16:45:25 2026 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 28 Jan 2026 16:45:25 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v17] In-Reply-To: References: Message-ID: <6-fyVKW-u3b6Bmm1FAhe7gMzlxOqr9wVwzk-FWXvR8s=.db3b9aa0-87f2-4861-b282-d198fc5ae543@github.com> On Tue, 27 Jan 2026 18:25:25 GMT, Paul Sandoz 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 34 commits: >> >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 >> - Clanups >> - Refactoring vectorIntrinsics >> - Refactoring and cleanups >> - Refactoring and cleanups >> - Review comments resolutions >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 >> - Adding testpoint for JDK-8373574 >> - Review comments resolutions >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 >> - ... and 24 more: https://git.openjdk.org/jdk/compare/0f1b96a5...ce5768fa > >> We will still need to create T_FLOAT16 basic type and associate it with Float16 LaneType, why not directly pass these basic types to intrinsic entry point ? > > The strong feedback from HotSpot folks, which i agree with, is adding a new enum value to `BasicType` is not the way to go - it is too disruptive and does not scale. Sorry if i misled you earlier on, it was my intention in feedback to propose something that was limited in scope to vector support. > > The thought about a proxy class was motivated by a question i had - what would we do if `Float16.class` was already present in `java.base`? and answers to that might motivate what we do now in preparation for when that happens. Regardless i think we need to separate out the Vector API's direct dependence on BasicType and its values. Instead we should define our own constants for the vector element types, and provide mapping of those to BasicType values which might result in "erasure" to the carrier type. We should adjust/adapt LaneType accordingly. Does that make sense to you? > Hi @PaulSandoz , Yes this looks good to me, I have modified the patch accordingly. Thanks, i think this is much better, more localized. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3812429459 From adinn at openjdk.org Wed Jan 28 17:06:06 2026 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 28 Jan 2026 17:06:06 GMT Subject: RFR: 8372617: Save and restore stubgen stubs when using an AOT code cache [v6] In-Reply-To: References: Message-ID: > This PR adds save and restore of all generated stubs to the AOT code cache on x86 and aarch64. Other arches are modified to deal with the related generic PAI changes. > > Small changes were required to the aarch64 and x86_64 generator code in order to meet two key constraints: > 1. the first declared entry of every stub starts at the first instruction in the stub code range > 2. all data/code cross-references from one stub to another target a declared stub entry Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: fix thinko in idx save restore and tweak aarch64 external addresses ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28433/files - new: https://git.openjdk.org/jdk/pull/28433/files/d063ddf3..eaa58529 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28433&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28433&range=04-05 Stats: 9 lines in 1 file changed: 1 ins; 1 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/28433.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28433/head:pull/28433 PR: https://git.openjdk.org/jdk/pull/28433 From bmaillard at openjdk.org Wed Jan 28 17:14:22 2026 From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard) Date: Wed, 28 Jan 2026 17:14:22 GMT Subject: RFR: 8375038: C2: Enforce that Ideal() returns the root of the subgraph if any change was made by checking the node hash [v2] In-Reply-To: References: Message-ID: > This PR introduces an assert in `PhaseIterGVN` to check that `Ideal` actually returns something if the node was modified. > > ## Context > > In the description of `Node::Ideal` in `node.cpp`, we have: > >> If ANY change is made, it must return the root of the reshaped graph - even if the root is the same Node > > It is crucial that such changes do not go unnoticed and that they can propagate to other nodes. Current documentation also states: > >> Running with `-XX:VerifyIterativeGVN=1` checks >> these invariants, although its too slow to have on by default. If you are >> hacking an Ideal call, be sure to test with `-XX:VerifyIterativeGVN=1` > > However, `-XX:VerifyIterativeGVN=1` ends up veryfing that the `_in` and `_out` arrays are consistent, but does not verify the return value. > > This PR aims to enforce the return value invariant. It should also make regression testing of bugs caused by wrongly returning nullptr in `Ideal` easier, such as [JDK-8373251](https://bugs.openjdk.org/browse/JDK-8373251). > > ## Proposed Change > > In summary, this PR brings the following set of changes > - Add a new flag bit to`-XX:VerifyIterativeGVN` for verifying return of `Ideal` calls > - Add an assert on the hash of nodes before and after `Ideal` in `PhaseIterGVN::transform_old` > - Fix `Ideal` optimizations that would cause harness errors with testing on tier1 > - Update the comments in the code to clarify the invariant and how to enforce it > > After consideration, I took the decision to only check the hash if the node is not dead. It seems there are many cases where the control node is dead, and we propagate the information to all users with `kill_dead_code`, and end up return `nullptr`. This is basically a mechanism to "speed up" the propagation (it would also happen normally via the usual IGVN worklist). This somehow contradicts the "must return the root of the reshaped graph" invariant, but it seems to be a common practice. > > In addition to that, I have decided to implement this as part of a new flag bit to `-XX:VerifyIterativeGVN` instead of an existing one, because there is a risk that it causes new failures in existing usages of the flag. > > This PR is meant to introduce the new check and fix the most "obvious" failures that the new flag would introduce in common scenarios, such as when running with `-version` on tier1. Since there are known issues caused by bad return values of `Ideal` (such as [JDK-8373251](https://bugs.openjdk.org/browse/JDK-8373251)), I will fix other failures in follow-up PRs.... Beno?t Maillard has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/share/opto/node.cpp Co-authored-by: Roberto Casta?eda Lozano ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29421/files - new: https://git.openjdk.org/jdk/pull/29421/files/3528807f..76dbb85f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29421&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29421&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29421.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29421/head:pull/29421 PR: https://git.openjdk.org/jdk/pull/29421 From bmaillard at openjdk.org Wed Jan 28 17:14:24 2026 From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard) Date: Wed, 28 Jan 2026 17:14:24 GMT Subject: RFR: 8375038: C2: Enforce that Ideal() returns the root of the subgraph if any change was made by checking the node hash [v2] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 14:22:21 GMT, Roberto Casta?eda Lozano wrote: >> Beno?t Maillard has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/hotspot/share/opto/node.cpp >> >> Co-authored-by: Roberto Casta?eda Lozano > > src/hotspot/share/opto/node.cpp line 1157: > >> 1155: // can help with validating these invariants, although they are too slow to have on by default: >> 1156: // - '-XX:VerifyIterativeGVN=1' checks the def-use info >> 1157: // - '-XX:VerifyIterativeGVN=100000' cheks the return value > > Suggestion: > > // - '-XX:VerifyIterativeGVN=100000' checks the return value Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29421#discussion_r2737660301 From adinn at openjdk.org Wed Jan 28 17:25:49 2026 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 28 Jan 2026 17:25:49 GMT Subject: RFR: 8372617: Save and restore stubgen stubs when using an AOT code cache [v7] In-Reply-To: References: Message-ID: > This PR adds save and restore of all generated stubs to the AOT code cache on x86 and aarch64. Other arches are modified to deal with the related generic PAI changes. > > Small changes were required to the aarch64 and x86_64 generator code in order to meet two key constraints: > 1. the first declared entry of every stub starts at the first instruction in the stub code range > 2. all data/code cross-references from one stub to another target a declared stub entry Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: add missing external for aarch64 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28433/files - new: https://git.openjdk.org/jdk/pull/28433/files/eaa58529..924a30f4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28433&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28433&range=05-06 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28433.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28433/head:pull/28433 PR: https://git.openjdk.org/jdk/pull/28433 From vyazici at openjdk.org Wed Jan 28 19:06:27 2026 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 28 Jan 2026 19:06:27 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v5] In-Reply-To: References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: On Wed, 28 Jan 2026 16:23:21 GMT, Damon Fenacci wrote: >> ## Issue >> >> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. >> >> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. >> >> ## Causes >> >> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. >> >> ## Fix >> >> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: >> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 >> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. >> >> # Testing >> >> * Tier 1-3+ >> * 2 JTReg tests added >> * `TestRangeCheck.java` as regression test for the reported issue >> * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion > > Damon Fenacci has updated the pull request incrementally with two additional commits since the last revision: > > - JDK-8374582: fix comment layout > - JDK-8374582: fix constructor argument name Copyright years don't point to 2026 for the following touched files: src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp src/hotspot/cpu/x86/macroAssembler_x86.cpp src/hotspot/share/classfile/vmIntrinsics.hpp src/hotspot/share/opto/classes.hpp src/hotspot/share/opto/escape.cpp src/hotspot/share/opto/library_call.cpp src/hotspot/share/opto/library_call.hpp src/hotspot/share/opto/loopTransform.cpp src/hotspot/share/opto/loopopts.cpp src/hotspot/share/opto/macro.cpp src/hotspot/share/opto/node.hpp src/hotspot/share/opto/opaquenode.cpp src/hotspot/share/opto/opaquenode.hpp src/hotspot/share/opto/split_if.cpp src/java.base/share/classes/java/lang/String.java src/java.base/share/classes/java/lang/StringCoding.java src/java.base/share/classes/java/lang/System.java src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java src/java.base/share/classes/sun/nio/cs/CESU_8.java src/java.base/share/classes/sun/nio/cs/DoubleByte.java src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java src/java.base/share/classes/sun/nio/cs/SingleByte.java src/java.base/share/classes/sun/nio/cs/US_ASCII.java src/java.base/share/classes/sun/nio/cs/UTF_8.java src/jdk.charsets/share/classes/sun/nio/cs/ext/EUC_JP.java.template test/hotspot/jtreg/compiler/escapeAnalysis/TestCanReduceCheckUsersDifferentIfs.java test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java test/hotspot/jtreg/compiler/unsafe/OpaqueAccesses.java ------------- PR Review: https://git.openjdk.org/jdk/pull/29164#pullrequestreview-3718529560 From egahlin at openjdk.org Wed Jan 28 20:41:54 2026 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 28 Jan 2026 20:41:54 GMT Subject: RFR: 8373096: JFR: Path-to-gc-roots search should be non-recursive [v3] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 07:53:47 GMT, Thomas Stuefe wrote: >> This is a continuation - second attempt - of https://github.com/openjdk/jdk/pull/28659. >> >> ---- >> >> A customer reported a native stack overflow when producing a JFR recording with path-to-gc-roots=true. This happens regularly, see similar cases in JBS (e.g. https://bugs.openjdk.org/browse/JDK-8371630, https://bugs.openjdk.org/browse/JDK-8282427 etc). >> >> We limit the maximum graph search depth (DFSClosure::max_dfs_depth) to prevent stack overflows. That solution is brittle, however, since recursion depth is not a good proxy for thread stack usage: it depends on many factors, e.g., compiler inlining decisions and platform specifics. In this case, the VMThread's stack was too small. >> >> This patch rewrites the DFS heap tracer to be non-recursive. This is mostly textbook stuff, but the devil is in the details. Nevertheless, the algorithm should be a straightforward read. >> >> ### Memory usage of old vs new algorithm: >> >> The new algorithm uses, on average, a bit less memory than the old one. The old algorithm did cost ((avg stackframe size in bytes) * depth). As we have seen, e.g., in JDK-8371630, a depth of 3200 can max out ~1MB of stack space. >> >> The new algorithm costs ((avg number of outgoing refs per instanceKlass oop) * depth * 16. For a depth of 3200, we get typical probe stack sizes of 100KB..200KB. But we also cap probestack size, similar to how we cap the max. graph depth. >> >> In any case, these numbers are nothing to worry about. For a more in-depth explanation about memory cost, please see the comment in dfsClosure.cpp. >> >> ### Possible improvements/simplifications in the future: >> >> DFS works perfectly well alone now. It no longer depends on stack size, and its memory usage is typically smaller than BFS. IMHO, it would be perfectly fine to get rid of BFS and rely solely on the non-recursive DFS. The benefit would be a decrease in complexity and fewer tests to run and maintain. It should also be easy to convert into a parallelized version later. >> >> I kept the _max_dfs_depth_ parameter for now, but tbh it is no longer very useful. Before, it prevented stack overflows. Now, it is just an indirect way to limit probe stack size. But we also explicitly cap the probe stack size, so _max_dfs_depth_ is redundant. Removing it would require changing the statically allocated reference stack to be dynamically allocated, but that should not be difficult. >> >> ### Observable differences >> >> There is one observable side effect to the changed a... > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > dont incremement _num_objects_processed for follow-up chunks test/jdk/jdk/jfr/jcmd/TestJcmdDumpPathToGCRootsDFSBase.java line 53: > 51: try (Recording r = new Recording()) { > 52: Map p = new HashMap<>(settings); > 53: p.put(EventNames.OldObjectSample + "#" + Enabled.NAME, "true"); No need to set disk to true, it's true by default. It much easier to enable an event this way: r.enable(EventNames.OldObjectSample); test/jdk/jdk/jfr/jcmd/TestJcmdDumpPathToGCRootsDFSBase.java line 67: > 65: File recording = new File(jfrFileName + r.getId() + ".jfr"); > 66: recording.delete(); > 67: JcmdHelper.jcmd("JFR.dump", "name=dodo", pathToGcRoots, "filename=" + recording.getAbsolutePath()); Why do we need to do this using jcmd? test/jdk/jdk/jfr/jcmd/TestJcmdDumpPathToGCRootsDFSBase.java line 68: > 66: recording.delete(); > 67: JcmdHelper.jcmd("JFR.dump", "name=dodo", pathToGcRoots, "filename=" + recording.getAbsolutePath()); > 68: r.setSettings(Collections.emptyMap()); No need to clear settings ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29382#discussion_r2738506314 PR Review Comment: https://git.openjdk.org/jdk/pull/29382#discussion_r2738511154 PR Review Comment: https://git.openjdk.org/jdk/pull/29382#discussion_r2738513128 From pchilanomate at openjdk.org Wed Jan 28 20:59:12 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 28 Jan 2026 20:59:12 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 09:35:00 GMT, Alan Bateman wrote: > JDK-8364343 upgraded the virtual thread transition management to be independent of JVMTI. We can update java_lang_Thread::async_get_stack_trace to use it and remove the suspend + retry code from Thread.getStackTrace. > > A summary of the changes: > > - java_lang_Thread::async_get_stack_trace is changed to use the new handshake op so it can be called to get the stack trace of a started thread in any state > - Thread::getStackTrace is changed to use async_get_stack_trace for all cases > - The SUSPENDED substate in VirtualThread is removed > - JVM_CreateThreadSnapshot is changed to be usable when JVMTI is not compiled in > - ThreadSnapshotFactory::get_thread_snapshot is changed to not upcall to StackTraceElement to complete the init of the stack trace > > The changes mean that Thread::getStackTrace may be slower when sampling a virtual thread in transition. This case should be rare, and it isn't really a performance critical op anyway. I prototyped use a spin loop and an increasing wait time in MountUnmountDisabler::disable_transition_for_one to avoid the wait(10) but decided to leave it out for now. Future work may examine this issue as there may be other cases (with JVMTI) that would benefit from avoiding the wait. > > A future PR might propose to change Thread.getStackTrace to use ThreadSnapshot and allow java_lang_Thread::async_get_stack_trace be removed. This requires more extensive changes to ThreadSnapshotFactory to reduce overhead when only the stack trace is required. > > Testing: tier1-5. The changes has been already been tested in the loom repo for a few months. Nice cleanup, looks good to me. src/hotspot/share/classfile/javaClasses.cpp line 1914: > 1912: > 1913: bool has_java_thread = tlh.cv_internal_thread_to_JavaThread(jthread, &java_thread, &thread_oop); > 1914: assert((has_java_thread && thread_oop != nullptr) || !has_java_thread, "Missing Thread oop"); Suggestion: assert(!has_java_thread || thread_oop != nullptr, "Missing Thread oop"); src/hotspot/share/classfile/javaClasses.cpp line 1944: > 1942: > 1943: bool is_virtual = java_lang_VirtualThread::is_instance(_thread_h()); > 1944: bool vthread_carrier = !is_virtual && (java_thread != nullptr) && (java_thread->vthread_continuation() != nullptr); The extra `java_thread != nullptr` should not be necessary. ------------- PR Review: https://git.openjdk.org/jdk/pull/29461#pullrequestreview-3719083411 PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2738545829 PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2738566963 From duke at openjdk.org Wed Jan 28 21:15:30 2026 From: duke at openjdk.org (Larry Cable) Date: Wed, 28 Jan 2026 21:15:30 GMT Subject: RFR: 8327246: Add a jcmd diagnostic command to list the jar files loaded by a process [v13] In-Reply-To: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> References: <0WMu1GnozgmbPail_47NH3fIkjC74aHQzIKnc2BqK0o=.20ce4cf4-8da5-4620-8ef0-d1dd9e7f0319@github.com> Message-ID: > 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 VM.classes 'help' description ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29048/files - new: https://git.openjdk.org/jdk/pull/29048/files/4b1bb228..369b8c02 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29048&range=11-12 Stats: 8 lines in 1 file changed: 1 ins; 0 del; 7 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 dholmes at openjdk.org Wed Jan 28 21:20:27 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 28 Jan 2026 21:20:27 GMT Subject: RFR: 8376357: Parallel: Convert MutableSpace classes to use Atomic In-Reply-To: References: Message-ID: <6AE-M8uvq7FAfVoArxQTWI5zM61RxTapF0OjUHz8YNY=.fed7cbf8-6f33-4c78-a38b-1beb56580beb@github.com> On Mon, 26 Jan 2026 17:14:07 GMT, Thomas Schatzl wrote: > Hi all, > > please review these changes that convert `MutableSpace` classes to use `Atomic`. > > Testing: gha, tier1-5 > > Thanks, > Thomas Overall looks good to me, but one nit. Thanks src/hotspot/share/runtime/vmStructs.cpp line 904: > 902: \ > 903: declare_toplevel_type(void*) \ > 904: declare_toplevel_type(Atomic) \ This placement (under "C primitive pointer types ") seems inappropriate. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29427#pullrequestreview-3719192589 PR Review Comment: https://git.openjdk.org/jdk/pull/29427#discussion_r2738641833 From duke at openjdk.org Wed Jan 28 21:24:33 2026 From: duke at openjdk.org (Robert Toyonaga) Date: Wed, 28 Jan 2026 21:24:33 GMT Subject: RFR: 8353564: Fail fatally if os::release_memory or os::uncommit_memory fails [v5] In-Reply-To: References: Message-ID: > This PR is a follow up to JDK-8341491. See original discussion: https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700 > > This PR makes `os::release_memory`, `os::uncommit_memory`, `os::release_memory_special`, and `os::unmap_memory` fail fatally if they encounter an error. These methods require obtaining the NMT lock. Fatally failing in these places would potentially allow for the tightening of NMT virtual memory locking scopes (future work, if this PR is accepted). Already in most cases, the callers fail fatally or assert(false) when these os:: methods fail. Another reason to fatally fail is that if the OS memory operation fails, it can be difficult to know for sure what state the OS left the memory in and recover. > > `release_memory`/`uncommit_memory`/`release_memory_special`/`unmap_memory` can fail due to ? Bad arguments, or ? The OS encountered an issue out of control of the JVM. > > ? > If there is a JVM bug, it's probably reasonable to fatally fail here. Or the caller could be intentionally passing arguments that may or may not be valid. I don't think there is any code like that currently, and this is probably a bad pattern to be following anyway. > > ? > In platform dependent code: > With regard to mmap/munmap, the only errors that aren't due to bad arguments are ENOMEM and ones related to file descriptors (which are not applicable to uncommit or release). > On Windows, VirtualFree only fails due to bad arguments. > On AIX, shmdt and disclaim64 only fail due to bad arguments. msync could spontaneously fail with EIO: "An I/O error occurred while reading from or writing to the file system." > On BSD, it seems like mprotect and madvise fail only due to bad arguments or invalid privileges. > > In the [original discussion](https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700), the main question was whether ENOMEM upon os::uncommit_memory was recoverable. This may be possible if we uncommit the middle of a region - splitting it in two. This could exceed the limit of the number of mappings resulting in ENOMEM. > > If none of the scenarios in ? are recoverable, then perhaps fatally failing is OK. > > Testing: > - Tier 1. > - Manual testing to make sure we fatally fail and the correct messages are printed. Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision: Don't pass false, rely on default argument. Punctuation. Whitespace. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29240/files - new: https://git.openjdk.org/jdk/pull/29240/files/21e0a63e..e41a9734 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29240&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29240&range=03-04 Stats: 12 lines in 6 files changed: 1 ins; 2 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/29240.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29240/head:pull/29240 PR: https://git.openjdk.org/jdk/pull/29240 From duke at openjdk.org Wed Jan 28 21:24:35 2026 From: duke at openjdk.org (Robert Toyonaga) Date: Wed, 28 Jan 2026 21:24:35 GMT Subject: RFR: 8353564: Fail fatally if os::release_memory or os::uncommit_memory fails [v4] In-Reply-To: <_spitwr7E2ZOosdO55zaal5x_KivtEb4VypVHGXd2D0=.9b2f66a7-8221-470a-b217-2463334fcef2@github.com> References: <5OmV0pZrlB2thfsumjiPuZp2jGGdVvFZj9LuCjoCwXk=.d5405dc0-6963-4f20-82e2-0297d86825cc@github.com> <_spitwr7E2ZOosdO55zaal5x_KivtEb4VypVHGXd2D0=.9b2f66a7-8221-470a-b217-2463334fcef2@github.com> Message-ID: <0HBa7B7nkHimQfCmGvBHbzCk5madLD0dcoApdkrCFM0=.1c27b901-76ae-4222-939d-4bd9ff102870@github.com> On Wed, 28 Jan 2026 07:50:14 GMT, Thomas Stuefe wrote: >> src/hotspot/os/bsd/os_bsd.cpp line 1766: >> >>> 1764: // If this is a growable mapping, remove the guard pages entirely by >>> 1765: // munmap()ping them. If not, just call uncommit_memory(). >>> 1766: void os::remove_stack_guard_pages(char* addr, size_t size) { >> >> Pre-existing but the method comment seems out-of-sync with the implementation. > > Yes, this only applies to Linux and its primordial stack segment. Maybe the whole function was copied over from Linux, including comment. I've removed this comment now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29240#discussion_r2738654525 From duke at openjdk.org Wed Jan 28 21:24:38 2026 From: duke at openjdk.org (Robert Toyonaga) Date: Wed, 28 Jan 2026 21:24:38 GMT Subject: RFR: 8353564: Fail fatally if os::release_memory or os::uncommit_memory fails [v4] In-Reply-To: <5OmV0pZrlB2thfsumjiPuZp2jGGdVvFZj9LuCjoCwXk=.d5405dc0-6963-4f20-82e2-0297d86825cc@github.com> References: <5OmV0pZrlB2thfsumjiPuZp2jGGdVvFZj9LuCjoCwXk=.d5405dc0-6963-4f20-82e2-0297d86825cc@github.com> Message-ID: On Wed, 28 Jan 2026 02:15:11 GMT, David Holmes wrote: >> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision: >> >> make remove_stack_guard_pages return void > > src/hotspot/os/bsd/os_bsd.cpp line 1767: > >> 1765: // munmap()ping them. If not, just call uncommit_memory(). >> 1766: void os::remove_stack_guard_pages(char* addr, size_t size) { >> 1767: os::uncommit_memory(addr, size, false); > > Why are you explicitly passing false now (here and in most other places below) instead of utilising the default argument? > > If you want to make this explicit then it would be helpful to comment what the `false` means: `false /* not executable */)` This was left over from when I was previously passing error strings. I agree we should instead be relying on the default argument. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29240#discussion_r2738666163 From dholmes at openjdk.org Wed Jan 28 21:31:14 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 28 Jan 2026 21:31:14 GMT Subject: RFR: 8353564: Fail fatally if os::release_memory or os::uncommit_memory fails [v5] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 21:24:33 GMT, Robert Toyonaga wrote: >> This PR is a follow up to JDK-8341491. See original discussion: https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700 >> >> This PR makes `os::release_memory`, `os::uncommit_memory`, `os::release_memory_special`, and `os::unmap_memory` fail fatally if they encounter an error. These methods require obtaining the NMT lock. Fatally failing in these places would potentially allow for the tightening of NMT virtual memory locking scopes (future work, if this PR is accepted). Already in most cases, the callers fail fatally or assert(false) when these os:: methods fail. Another reason to fatally fail is that if the OS memory operation fails, it can be difficult to know for sure what state the OS left the memory in and recover. >> >> `release_memory`/`uncommit_memory`/`release_memory_special`/`unmap_memory` can fail due to ? Bad arguments, or ? The OS encountered an issue out of control of the JVM. >> >> ? >> If there is a JVM bug, it's probably reasonable to fatally fail here. Or the caller could be intentionally passing arguments that may or may not be valid. I don't think there is any code like that currently, and this is probably a bad pattern to be following anyway. >> >> ? >> In platform dependent code: >> With regard to mmap/munmap, the only errors that aren't due to bad arguments are ENOMEM and ones related to file descriptors (which are not applicable to uncommit or release). >> On Windows, VirtualFree only fails due to bad arguments. >> On AIX, shmdt and disclaim64 only fail due to bad arguments. msync could spontaneously fail with EIO: "An I/O error occurred while reading from or writing to the file system." >> On BSD, it seems like mprotect and madvise fail only due to bad arguments or invalid privileges. >> >> In the [original discussion](https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700), the main question was whether ENOMEM upon os::uncommit_memory was recoverable. This may be possible if we uncommit the middle of a region - splitting it in two. This could exceed the limit of the number of mappings resulting in ENOMEM. >> >> If none of the scenarios in ? are recoverable, then perhaps fatally failing is OK. >> >> Testing: >> - Tier 1. >> - Manual testing to make sure we fatally fail and the correct messages are printed. > > Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision: > > Don't pass false, rely on default argument. Punctuation. Whitespace. Nothing further from me. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29240#pullrequestreview-3719250288 From duke at openjdk.org Wed Jan 28 21:31:15 2026 From: duke at openjdk.org (Robert Toyonaga) Date: Wed, 28 Jan 2026 21:31:15 GMT Subject: RFR: 8353564: Fail fatally if os::release_memory or os::uncommit_memory fails [v5] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 21:24:33 GMT, Robert Toyonaga wrote: >> This PR is a follow up to JDK-8341491. See original discussion: https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700 >> >> This PR makes `os::release_memory`, `os::uncommit_memory`, `os::release_memory_special`, and `os::unmap_memory` fail fatally if they encounter an error. These methods require obtaining the NMT lock. Fatally failing in these places would potentially allow for the tightening of NMT virtual memory locking scopes (future work, if this PR is accepted). Already in most cases, the callers fail fatally or assert(false) when these os:: methods fail. Another reason to fatally fail is that if the OS memory operation fails, it can be difficult to know for sure what state the OS left the memory in and recover. >> >> `release_memory`/`uncommit_memory`/`release_memory_special`/`unmap_memory` can fail due to ? Bad arguments, or ? The OS encountered an issue out of control of the JVM. >> >> ? >> If there is a JVM bug, it's probably reasonable to fatally fail here. Or the caller could be intentionally passing arguments that may or may not be valid. I don't think there is any code like that currently, and this is probably a bad pattern to be following anyway. >> >> ? >> In platform dependent code: >> With regard to mmap/munmap, the only errors that aren't due to bad arguments are ENOMEM and ones related to file descriptors (which are not applicable to uncommit or release). >> On Windows, VirtualFree only fails due to bad arguments. >> On AIX, shmdt and disclaim64 only fail due to bad arguments. msync could spontaneously fail with EIO: "An I/O error occurred while reading from or writing to the file system." >> On BSD, it seems like mprotect and madvise fail only due to bad arguments or invalid privileges. >> >> In the [original discussion](https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700), the main question was whether ENOMEM upon os::uncommit_memory was recoverable. This may be possible if we uncommit the middle of a region - splitting it in two. This could exceed the limit of the number of mappings resulting in ENOMEM. >> >> If none of the scenarios in ? are recoverable, then perhaps fatally failing is OK. >> >> Testing: >> - Tier 1. >> - Manual testing to make sure we fatally fail and the correct messages are printed. > > Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision: > > Don't pass false, rely on default argument. Punctuation. Whitespace. Thanks again everyone for the review feedback. I've pushed another commit adopting all of your suggestions. I got rid of passing the unnecessary false argument to os::uncommit_memory. Once https://github.com/openjdk/jdk/pull/29471 has been integrated, the Windows Github CI test should pass. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29240#issuecomment-3814025508 From wkemper at openjdk.org Wed Jan 28 22:44:05 2026 From: wkemper at openjdk.org (William Kemper) Date: Wed, 28 Jan 2026 22:44:05 GMT Subject: RFR: 8376472: Shenandoah: Assembler store barriers read destination memory despite the decorators In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 10:47:54 GMT, Aleksey Shipilev wrote: > The issue is really a correctness issue, and it readily manifests in Valhalla, which sometimes does the stores with `IS_DEST_UNINITIALIZED` set. Unfortunately, Shenandoah SATB barriers ignore this attribute, and attempt to read the memory at store address. At best it crashes the VM with the "oopness" asserts, at worst it feeds "garbage" pointers into SATB machinery, which then wrecks havoc on everything else. > > We need to make sure store barriers are consistently checking these attributes. Unfortunately, that would mean doing the changes in arch-specific assembler code. > > This PR makes sure the ShenandoahBarrierSetAssembler store barriers are roughly in the same shape, and that they consult `ShenandoahBarrierSet::need_*_barrier` to make the proper decisions whether to use SATB/card barriers. > > `hotspot_gc_shenandoah` is enough to sanity-check this patch, but I am also running `all` tests for extra safety. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` > - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah` > - [x] Linux x86_64 server fastdebug, `all` + `-XX:+UseShenandoahGC` > - [x] Linux AArch64 server fastdebug, `all` + `-XX:+UseShenandoahGC` > - [x] Linux {PPC64, RISC-V, S390X} server fastdebug, cross-compilation Marked as reviewed by wkemper (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29444#pullrequestreview-3719515006 From vlivanov at openjdk.org Wed Jan 28 22:48:13 2026 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 28 Jan 2026 22:48:13 GMT Subject: RFR: 8375046: C2: Incremental inlining step asserts when processing empty late inlines list [v6] In-Reply-To: <0bZ35MkAh88k08YJCy2eFddNuI_s-kMf0NZCJIp3lpo=.1bd652e6-a9ba-452b-8cf3-77972ab21e86@github.com> References: <_tSvASngm2bL0X2wavXI63kJZoypsY5S-dus_KGhs18=.ace489be-48bf-4254-a88e-b4fe456edf02@github.com> <0bZ35MkAh88k08YJCy2eFddNuI_s-kMf0NZCJIp3lpo=.1bd652e6-a9ba-452b-8cf3-77972ab21e86@github.com> Message-ID: On Wed, 28 Jan 2026 09:43:32 GMT, Aleksey Shipilev wrote: >> Seen this assert in stress CTW runs: >> >> >> # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/utilities/growableArray.hpp:498), pid=2972347, tid=2973775 >> # assert(start < end && end <= this->_len) failed: erase called with invalid range (0, 0) for length 0 >> >> Stack: [0x00007fd660bea000,0x00007fd660cea000], sp=0x00007fd660ce4fc0, free space=1003k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0xc00a41] Compile::inline_incrementally_one()+0x801 (growableArray.hpp:498) >> V [libjvm.so+0xc01650] Compile::inline_incrementally(PhaseIterGVN&)+0x2f0 (compile.cpp:2212) >> V [libjvm.so+0xc04581] Compile::Optimize()+0x7d1 (compile.cpp:2357) >> >> >> It looks innocuous, as `GrowableArray::remove_range` does nothing real on `[0, 0)`. It is still IMO a bug to call it with `[0, 0)`, as it is not clear whether to trust inclusive or exclusive boundary. But for `remove_till`, it looks plausible that `remove_till(0)` should work and be a no-op. Looks like it readily happens in C2 CTW when `_late_inlines` is empty. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, additional new gtest to verify `remove_range` works >> - [x] Linux x86_64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision: > > - Alternative fix > - Remove old patch > - Merge branch 'master' into JDK-8375046-growable-array-till-zero > - Missing case > - More tests > - Merge branch 'master' into JDK-8375046-growable-array-till-zero > - Revert > - Leave only the C2 fix > - Merge branch 'master' into JDK-8375046-growable-array-till-zero > - Only clear pos when needed > - ... and 3 more: https://git.openjdk.org/jdk/compare/e53cbcbf...2f755fb5 Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29171#pullrequestreview-3719522678 From erfang at openjdk.org Thu Jan 29 01:24:48 2026 From: erfang at openjdk.org (Eric Fang) Date: Thu, 29 Jan 2026 01:24:48 GMT Subject: RFR: 8374349: [VectorAPI]: AArch64: Prefer merging mode SVE CPY instruction In-Reply-To: References: <_0ouKSVAIyzg0g9hA2jZXNH-_cCqJjNCSh7kM2dn80w=.b93145c3-c465-423a-ab68-c8d7bd7e4280@github.com> <_qJ_Qo_Mqexx7dYu0Vkc9ru4SxZ0izfqifaUIAL1iyQ=.741b11d4-a89d-495e-8d31-78fed690abf6@github.com> Message-ID: On Wed, 28 Jan 2026 10:17:30 GMT, Andrew Haley wrote: > > Therefore, when you test this change using the C case, you will see a significant performance improvement. > > > I see 2% uplift on these numbers. > > > > > > @theRealAph And I think this also explains your question on these numbers. > > Not at all. > > The performance claim above was: > > > Microbenchmarks show this change brings performance uplift ranging from 11% to 33%, depending on the specific operation and data types. > > But the real performance uplift, as measured in Java microbenchmarks, is 2%. Sorry, this is my mistake, I should be more precise. I should say that when this optimization takes effect, the performance improvement is 11%-33%, depending on the specific operation and data types. Thanks for point this out! > Definitions in Assembler should generate the instructions in the Architecture reference Manual. When doing this, please override sve_cpy in MacroAssembler instead of here. Agreed, that's exactly what I was thinking too. @theRealAph Thank you for your suggestion. I will address the issue you pointed out in the next commit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29359#issuecomment-3814815084 From dholmes at openjdk.org Thu Jan 29 04:24:16 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 29 Jan 2026 04:24:16 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 20:54:35 GMT, Patricio Chilano Mateo wrote: >> JDK-8364343 upgraded the virtual thread transition management to be independent of JVMTI. We can update java_lang_Thread::async_get_stack_trace to use it and remove the suspend + retry code from Thread.getStackTrace. >> >> A summary of the changes: >> >> - java_lang_Thread::async_get_stack_trace is changed to use the new handshake op so it can be called to get the stack trace of a started thread in any state >> - Thread::getStackTrace is changed to use async_get_stack_trace for all cases >> - The SUSPENDED substate in VirtualThread is removed >> - JVM_CreateThreadSnapshot is changed to be usable when JVMTI is not compiled in >> - ThreadSnapshotFactory::get_thread_snapshot is changed to not upcall to StackTraceElement to complete the init of the stack trace >> >> The changes mean that Thread::getStackTrace may be slower when sampling a virtual thread in transition. This case should be rare, and it isn't really a performance critical op anyway. I prototyped use a spin loop and an increasing wait time in MountUnmountDisabler::disable_transition_for_one to avoid the wait(10) but decided to leave it out for now. Future work may examine this issue as there may be other cases (with JVMTI) that would benefit from avoiding the wait. >> >> A future PR might propose to change Thread.getStackTrace to use ThreadSnapshot and allow java_lang_Thread::async_get_stack_trace be removed. This requires more extensive changes to ThreadSnapshotFactory to reduce overhead when only the stack trace is required. >> >> Testing: tier1-5. The changes has been already been tested in the loom repo for a few months. > > src/hotspot/share/classfile/javaClasses.cpp line 1944: > >> 1942: >> 1943: bool is_virtual = java_lang_VirtualThread::is_instance(_thread_h()); >> 1944: bool vthread_carrier = !is_virtual && (java_thread != nullptr) && (java_thread->vthread_continuation() != nullptr); > > The extra `java_thread != nullptr` should not be necessary. What would force it to be non-null? (Related: under what conditions will `th` be null and what does that imply about the value of `_thread_h()`?) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2739888377 From dholmes at openjdk.org Thu Jan 29 04:59:48 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 29 Jan 2026 04:59:48 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 09:35:00 GMT, Alan Bateman wrote: > JDK-8364343 upgraded the virtual thread transition management to be independent of JVMTI. We can update java_lang_Thread::async_get_stack_trace to use it and remove the suspend + retry code from Thread.getStackTrace. > > A summary of the changes: > > - java_lang_Thread::async_get_stack_trace is changed to use the new handshake op so it can be called to get the stack trace of a started thread in any state > - Thread::getStackTrace is changed to use async_get_stack_trace for all cases > - The SUSPENDED substate in VirtualThread is removed > - JVM_CreateThreadSnapshot is changed to be usable when JVMTI is not compiled in > - ThreadSnapshotFactory::get_thread_snapshot is changed to not upcall to StackTraceElement to complete the init of the stack trace > > The changes mean that Thread::getStackTrace may be slower when sampling a virtual thread in transition. This case should be rare, and it isn't really a performance critical op anyway. I prototyped use a spin loop and an increasing wait time in MountUnmountDisabler::disable_transition_for_one to avoid the wait(10) but decided to leave it out for now. Future work may examine this issue as there may be other cases (with JVMTI) that would benefit from avoiding the wait. > > A future PR might propose to change Thread.getStackTrace to use ThreadSnapshot and allow java_lang_Thread::async_get_stack_trace be removed. This requires more extensive changes to ThreadSnapshotFactory to reduce overhead when only the stack trace is required. > > Testing: tier1-5. The changes has been already been tested in the loom repo for a few months. I've taken a pass through this. Great to see all the cleanup and simplification but unless you know the detailed back-story here it is difficult to understand some of the changes (or even some of the code that hasn't changed). src/hotspot/share/services/threadService.cpp line 1479: > 1477: if (cl._thread_status == JavaThreadStatus::NEW || cl._thread_status == JavaThreadStatus::TERMINATED) { > 1478: return nullptr; > 1479: } It is not obvious to me why this is only a possibility now? src/hotspot/share/services/threadService.cpp line 1509: > 1507: > 1508: // call static StackTraceElement[] StackTraceElement.of(StackTraceElement[] stackTrace) > 1509: // to properly initialize STEs. Why can this be removed? src/java.base/share/classes/java/lang/StackTraceElement.java line 578: > 576: } > 577: > 578: static StackTraceElement[] finishInit(StackTraceElement[] stackTrace) { Out of curiousity what does this actually do, and why do we need it? src/java.base/share/classes/java/lang/Thread.java line 2218: > 2216: } > 2217: Object trace = getStackTrace0(); > 2218: if (trace instanceof StackTraceElement[] stackTrace) { What can this return other than a `StackTraceElement[]` ?? src/java.base/share/classes/jdk/internal/vm/ThreadSnapshot.java line 65: > 63: ThreadSnapshot snapshot = create(thread); > 64: if (snapshot == null) { > 65: return null; // thread not alive I can understand that you might call this on a thread that terminates before the operation can be performed. But not-alive implies NEW threads too and I would have expected NEW threads to be filtered out long before we get here. test/micro/org/openjdk/bench/java/lang/ThreadGetStackTraceWhenParked.java line 2: > 1: /* > 2: * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. Are these "new" test files from the Loom repo? ------------- PR Review: https://git.openjdk.org/jdk/pull/29461#pullrequestreview-3720632723 PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2739903913 PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2739905261 PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2739932529 PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2739914245 PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2739919446 PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2739928137 From dholmes at openjdk.org Thu Jan 29 04:59:50 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 29 Jan 2026 04:59:50 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 20:48:26 GMT, Patricio Chilano Mateo wrote: >> JDK-8364343 upgraded the virtual thread transition management to be independent of JVMTI. We can update java_lang_Thread::async_get_stack_trace to use it and remove the suspend + retry code from Thread.getStackTrace. >> >> A summary of the changes: >> >> - java_lang_Thread::async_get_stack_trace is changed to use the new handshake op so it can be called to get the stack trace of a started thread in any state >> - Thread::getStackTrace is changed to use async_get_stack_trace for all cases >> - The SUSPENDED substate in VirtualThread is removed >> - JVM_CreateThreadSnapshot is changed to be usable when JVMTI is not compiled in >> - ThreadSnapshotFactory::get_thread_snapshot is changed to not upcall to StackTraceElement to complete the init of the stack trace >> >> The changes mean that Thread::getStackTrace may be slower when sampling a virtual thread in transition. This case should be rare, and it isn't really a performance critical op anyway. I prototyped use a spin loop and an increasing wait time in MountUnmountDisabler::disable_transition_for_one to avoid the wait(10) but decided to leave it out for now. Future work may examine this issue as there may be other cases (with JVMTI) that would benefit from avoiding the wait. >> >> A future PR might propose to change Thread.getStackTrace to use ThreadSnapshot and allow java_lang_Thread::async_get_stack_trace be removed. This requires more extensive changes to ThreadSnapshotFactory to reduce overhead when only the stack trace is required. >> >> Testing: tier1-5. The changes has been already been tested in the loom repo for a few months. > > src/hotspot/share/classfile/javaClasses.cpp line 1914: > >> 1912: >> 1913: bool has_java_thread = tlh.cv_internal_thread_to_JavaThread(jthread, &java_thread, &thread_oop); >> 1914: assert((has_java_thread && thread_oop != nullptr) || !has_java_thread, "Missing Thread oop"); > > Suggestion: > > assert(!has_java_thread || thread_oop != nullptr, "Missing Thread oop"); FWIW the same "shape" assert is in threadService.cpp ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2739949321 From dlong at openjdk.org Thu Jan 29 06:50:32 2026 From: dlong at openjdk.org (Dean Long) Date: Thu, 29 Jan 2026 06:50:32 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v6] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 03:43:15 GMT, Chen Liang wrote: >> src/hotspot/share/opto/library_call.cpp line 4791: >> >>> 4789: const TypeInstPtr* t = _gvn.type(obj)->isa_instptr(); >>> 4790: if (t != nullptr && t->const_oop() != nullptr) { >>> 4791: assert(!is_virtual, "no devirtualization for constant receiver?"); >> >> Don't we also need to check for `is_static`, to distinguish between `Object.hashCode` and `System.identityHashCode`? > > I think once we are not virtual, the native Object::hashCode behaves like System::identityHashCode. The only difference is null check, but I think there's a null check in the beginning so we should be safe. OK so if we get here we are guaranteed to be calling Object::hashCode and not a devirtualized MySubClass::hashCode? I guess the intrinsic lookup would fail if the callee was a subclass. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2740204610 From jbhateja at openjdk.org Thu Jan 29 07:25:03 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 29 Jan 2026 07:25:03 GMT Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass them to intrinsic entries Message-ID: As per [discussions ](https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594) on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch in preparation of Float16 vector API support. Patch add new lane type constants and pass them to vector intrinsic entry points. All existing Vector API jtreg test are passing with the patch. Kindly review and share your feedback. Best Regards, Jatin ------------- Commit messages: - [VectorAPI] Define new lane type constants and pass them to intrinsic entries Changes: https://git.openjdk.org/jdk/pull/29481/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29481&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376187 Stats: 1744 lines in 52 files changed: 192 ins; 79 del; 1473 mod Patch: https://git.openjdk.org/jdk/pull/29481.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29481/head:pull/29481 PR: https://git.openjdk.org/jdk/pull/29481 From dfenacci at openjdk.org Thu Jan 29 07:32:12 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Thu, 29 Jan 2026 07:32:12 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v6] In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: > ## Issue > > This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. > > This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. > > ## Causes > > The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. > > ## Fix > > A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: > https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 > This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. > > # Testing > > * Tier 1-3+ > * 2 JTReg tests added > * `TestRangeCheck.java` as regression test for the reported issue > * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion Damon Fenacci 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 31 additional commits since the last revision: - JDK-8374582: merge and update copyright year - Merge branch 'master' into JDK-8374582 - Merge branch 'master' into JDK-8374582 - JDK-8374582: fix comment layout - JDK-8374582: fix constructor argument name - JDK-8374582: fix indent - JDK-8374582: constant - JDK-8374582: add size_of - JDK-8374852: OpaqueCheck -> OpaqueConstantBool - JDK-8374852: fix number of OpaqueCheck nodes in test - ... and 21 more: https://git.openjdk.org/jdk/compare/7e545381...a587a269 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29164/files - new: https://git.openjdk.org/jdk/pull/29164/files/bddec5b5..a587a269 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=04-05 Stats: 61562 lines in 1281 files changed: 34520 ins; 12116 del; 14926 mod Patch: https://git.openjdk.org/jdk/pull/29164.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29164/head:pull/29164 PR: https://git.openjdk.org/jdk/pull/29164 From dfenacci at openjdk.org Thu Jan 29 07:32:12 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Thu, 29 Jan 2026 07:32:12 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v5] In-Reply-To: References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: On Wed, 28 Jan 2026 19:03:23 GMT, Volkan Yazici wrote: > Copyright years don't point to 2026 for the following touched files: Right! Fixed. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29164#issuecomment-3815950950 From shade at openjdk.org Thu Jan 29 07:46:55 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 29 Jan 2026 07:46:55 GMT Subject: RFR: 8376472: Shenandoah: Assembler store barriers read destination memory despite the decorators In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 22:41:43 GMT, William Kemper wrote: >> The issue is really a correctness issue, and it readily manifests in Valhalla, which sometimes does the stores with `IS_DEST_UNINITIALIZED` set. Unfortunately, Shenandoah SATB barriers ignore this attribute, and attempt to read the memory at store address. At best it crashes the VM with the "oopness" asserts, at worst it feeds "garbage" pointers into SATB machinery, which then wrecks havoc on everything else. >> >> We need to make sure store barriers are consistently checking these attributes. Unfortunately, that would mean doing the changes in arch-specific assembler code. >> >> This PR makes sure the ShenandoahBarrierSetAssembler store barriers are roughly in the same shape, and that they consult `ShenandoahBarrierSet::need_*_barrier` to make the proper decisions whether to use SATB/card barriers. >> >> `hotspot_gc_shenandoah` is enough to sanity-check this patch, but I am also running `all` tests for extra safety. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` >> - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah` >> - [x] Linux x86_64 server fastdebug, `all` + `-XX:+UseShenandoahGC` >> - [x] Linux AArch64 server fastdebug, `all` + `-XX:+UseShenandoahGC` >> - [x] Linux {PPC64, RISC-V, S390X} server fastdebug, cross-compilation > > Marked as reviewed by wkemper (Reviewer). Thanks @earthling-amzn! @RealFYang, @TheRealMDoerr -- you might want to run RISC-V / PPC tests on this PR? I am pretty sure the move did not break anything. A simple `make test TEST=hotspot_gc_shenandoah` would do for testing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29444#issuecomment-3816010648 From shade at openjdk.org Thu Jan 29 07:47:53 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 29 Jan 2026 07:47:53 GMT Subject: RFR: 8375046: C2: Incremental inlining step asserts when processing empty late inlines list [v4] In-Reply-To: References: <_tSvASngm2bL0X2wavXI63kJZoypsY5S-dus_KGhs18=.ace489be-48bf-4254-a88e-b4fe456edf02@github.com> Message-ID: <01pQ17oZgy_VgKTXDFh3fpmxaoWniyQq7kFYT4FRFDE=.efc6d7f6-e6c4-48cd-bcc9-c61e42f34c18@github.com> On Tue, 20 Jan 2026 19:39:24 GMT, Vladimir Ivanov wrote: >>> The code implicitly assumes that `_late_inlines` is not empty and it's a reasonable assumption. Any particular reason to handle empty case instead of finishing early? >> >> The case shows up in CTW -- and fairly rarely at that -- so I think there is no reason for us to care all that much about that corner case, as long as it does not break correctness. Current code just creates the noise in testing, so we are fixing that noise. > >> The case shows up in CTW -- and fairly rarely at that -- so I think there is no reason for us to care all that much about that corner case, as long as it does not break correctness. Current code just creates the noise in testing, so we are fixing that noise. > > The point I'm trying to make is `Compile::inline_incrementally_one()` assumes `_late_inlines` is not empty. Both callers (`Compile::inline_incrementally()` and `Compile::process_late_inline_calls_no_inline()`) do have `_late_inlines.length() > 0` guards, but it seems it doesn't hold when `PhaseIdealLoop` removes remaining elements from `_late_inlines`. > > The behavior is counter-intuitive and can cause other surprises later. Instead, I suggest to add ` if (_late_inlines.length() == 0) return;` in `Compile::inline_incrementally()` before calling into `inline_incrementally_one()`. Thanks @iwanowww! I think I need another quick Review, since Kim effectively reviewed completely different code. @TobiHartmann, @chhagedorn, maybe? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29171#issuecomment-3816014750 From stuefe at openjdk.org Thu Jan 29 08:02:46 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 29 Jan 2026 08:02:46 GMT Subject: RFR: 8353564: Fail fatally if os::release_memory or os::uncommit_memory fails [v5] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 21:24:33 GMT, Robert Toyonaga wrote: >> This PR is a follow up to JDK-8341491. See original discussion: https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700 >> >> This PR makes `os::release_memory`, `os::uncommit_memory`, `os::release_memory_special`, and `os::unmap_memory` fail fatally if they encounter an error. These methods require obtaining the NMT lock. Fatally failing in these places would potentially allow for the tightening of NMT virtual memory locking scopes (future work, if this PR is accepted). Already in most cases, the callers fail fatally or assert(false) when these os:: methods fail. Another reason to fatally fail is that if the OS memory operation fails, it can be difficult to know for sure what state the OS left the memory in and recover. >> >> `release_memory`/`uncommit_memory`/`release_memory_special`/`unmap_memory` can fail due to ? Bad arguments, or ? The OS encountered an issue out of control of the JVM. >> >> ? >> If there is a JVM bug, it's probably reasonable to fatally fail here. Or the caller could be intentionally passing arguments that may or may not be valid. I don't think there is any code like that currently, and this is probably a bad pattern to be following anyway. >> >> ? >> In platform dependent code: >> With regard to mmap/munmap, the only errors that aren't due to bad arguments are ENOMEM and ones related to file descriptors (which are not applicable to uncommit or release). >> On Windows, VirtualFree only fails due to bad arguments. >> On AIX, shmdt and disclaim64 only fail due to bad arguments. msync could spontaneously fail with EIO: "An I/O error occurred while reading from or writing to the file system." >> On BSD, it seems like mprotect and madvise fail only due to bad arguments or invalid privileges. >> >> In the [original discussion](https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700), the main question was whether ENOMEM upon os::uncommit_memory was recoverable. This may be possible if we uncommit the middle of a region - splitting it in two. This could exceed the limit of the number of mappings resulting in ENOMEM. >> >> If none of the scenarios in ? are recoverable, then perhaps fatally failing is OK. >> >> Testing: >> - Tier 1. >> - Manual testing to make sure we fatally fail and the correct messages are printed. > > Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision: > > Don't pass false, rely on default argument. Punctuation. Whitespace. Some small remarks remain, otherwise this is good. src/hotspot/os/linux/os_linux.cpp line 3458: > 3456: if (ep.saved_errno() == ENOMEM) { > 3457: fatal("Failed to uncommit " RANGEFMT ". It is possible that the process's maximum number of mappings would have been exceeded. Try increasing the limit.", RANGEFMTARGS(addr, size)); > 3458: } good. src/hotspot/share/memory/memoryReserver.cpp line 236: > 234: > 235: if (reserved.special()) { > 236: os::release_memory_special(reserved.base(), reserved.size()); Here is another possible simplification. The point of `os::release_memory_special` was to handle system V shm backed large pages on Linux. We got rid of that mechanism though, so now it just calls os::release_memory. I created https://bugs.openjdk.org/browse/JDK-8376650 to track that. test/hotspot/gtest/runtime/test_os.cpp line 667: > 665: char* p = setup_release_test_memory(); > 666: os::release_memory(p, M); // Release part of the range > 667: } This is a good rewrite of the tests. I did not even think of this. Proposal: do this: #ifdef ASSERT #define TEST_RELEASE_RANGE_ERROR(name) TEST_VM_ASSERT_MSG(os, name, ".*bad release") #else #define TEST_RELEASE_RANGE_ERROR(name) TEST_VM_FATAL_ERROR_MSG(os, name, ".*Failed to release.*") #endif and use TEST_RELEASE_RANGE_ERROR as header, saves duplicating these lines five times. test/hotspot/gtest/runtime/test_os.cpp line 745: > 743: > 744: if (p2 != nullptr) { > 745: os::release_memory((char*)p2, stripe_len); All these tests, if os::commit is broken, will crash now instead of giving us a test error in gtest. But I think that is acceptable. These errors are very improbable. ------------- PR Review: https://git.openjdk.org/jdk/pull/29240#pullrequestreview-3721135695 PR Review Comment: https://git.openjdk.org/jdk/pull/29240#discussion_r2740336278 PR Review Comment: https://git.openjdk.org/jdk/pull/29240#discussion_r2740365722 PR Review Comment: https://git.openjdk.org/jdk/pull/29240#discussion_r2740394411 PR Review Comment: https://git.openjdk.org/jdk/pull/29240#discussion_r2740401554 From qamai at openjdk.org Thu Jan 29 08:13:59 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 29 Jan 2026 08:13:59 GMT Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass them to intrinsic entries In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 07:16:35 GMT, Jatin Bhateja wrote: > As per [discussions ](https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594) on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch in preparation of Float16 vector API support. > > Patch add new lane type constants and pass them to vector intrinsic entry points. > > All existing Vector API jtreg test are passing with the patch. > > Kindly review and share your feedback. > > Best Regards, > Jatin src/hotspot/share/prims/vectorSupport.hpp line 140: > 138: }; > 139: > 140: enum { Please use a scoped enum instead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2740433980 From stuefe at openjdk.org Thu Jan 29 08:16:04 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 29 Jan 2026 08:16:04 GMT Subject: RFR: 8353564: Fail fatally if os::release_memory or os::uncommit_memory fails [v5] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 21:24:33 GMT, Robert Toyonaga wrote: >> This PR is a follow up to JDK-8341491. See original discussion: https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700 >> >> This PR makes `os::release_memory`, `os::uncommit_memory`, `os::release_memory_special`, and `os::unmap_memory` fail fatally if they encounter an error. These methods require obtaining the NMT lock. Fatally failing in these places would potentially allow for the tightening of NMT virtual memory locking scopes (future work, if this PR is accepted). Already in most cases, the callers fail fatally or assert(false) when these os:: methods fail. Another reason to fatally fail is that if the OS memory operation fails, it can be difficult to know for sure what state the OS left the memory in and recover. >> >> `release_memory`/`uncommit_memory`/`release_memory_special`/`unmap_memory` can fail due to ? Bad arguments, or ? The OS encountered an issue out of control of the JVM. >> >> ? >> If there is a JVM bug, it's probably reasonable to fatally fail here. Or the caller could be intentionally passing arguments that may or may not be valid. I don't think there is any code like that currently, and this is probably a bad pattern to be following anyway. >> >> ? >> In platform dependent code: >> With regard to mmap/munmap, the only errors that aren't due to bad arguments are ENOMEM and ones related to file descriptors (which are not applicable to uncommit or release). >> On Windows, VirtualFree only fails due to bad arguments. >> On AIX, shmdt and disclaim64 only fail due to bad arguments. msync could spontaneously fail with EIO: "An I/O error occurred while reading from or writing to the file system." >> On BSD, it seems like mprotect and madvise fail only due to bad arguments or invalid privileges. >> >> In the [original discussion](https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700), the main question was whether ENOMEM upon os::uncommit_memory was recoverable. This may be possible if we uncommit the middle of a region - splitting it in two. This could exceed the limit of the number of mappings resulting in ENOMEM. >> >> If none of the scenarios in ? are recoverable, then perhaps fatally failing is OK. >> >> Testing: >> - Tier 1. >> - Manual testing to make sure we fatally fail and the correct messages are printed. > > Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision: > > Don't pass false, rely on default argument. Punctuation. Whitespace. The patch uncovers a hidden error in ZGC tests. It uses `os::uncommit_memory` without checking the return type (ZForwardingTest::TearDown). It probably never worked before; now we assert. I actually like the new behavior better. Releasing not-matching memory ranges is dangerous (NMT would catch that too, though). I think what happens here is that the underlying memory we operate on was reserved (in ZVirtualMemoryReserver -> ZVirtualMemoryReserverSmallPages::reserve -> ZMapper::reserve) via VirtualAlloc2, and that for whatever reason os::uncommit does not work here. Maybe the range does not match ? Or we need to call a different API. I may be wrong, I did not look that closely. Maybe @stefank knows more. Also, maybe it would be worth to run more complete tests. I'll ping some of the SAP guys to run this patch through the mangler, maybe there are more cases of bad uncommits that were ignored before and now assert. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29240#issuecomment-3816140193 PR Comment: https://git.openjdk.org/jdk/pull/29240#issuecomment-3816147944 From stefank at openjdk.org Thu Jan 29 08:29:30 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 29 Jan 2026 08:29:30 GMT Subject: RFR: 8353564: Fail fatally if os::release_memory or os::uncommit_memory fails [v5] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 08:12:31 GMT, Thomas Stuefe wrote: > The patch uncovers a hidden error in ZGC tests. It uses `os::uncommit_memory` without checking the return type (ZForwardingTest::TearDown). It probably never worked before; now we assert. I actually like the new behavior better. Releasing not-matching memory ranges is dangerous (NMT would catch that too, though). > > I think what happens here is that the underlying memory we operate on was reserved (in ZVirtualMemoryReserver -> ZVirtualMemoryReserverSmallPages::reserve -> ZMapper::reserve) via VirtualAlloc2, and that for whatever reason os::uncommit does not work here. Maybe the range does not match ? Or we need to call a different API. > > I may be wrong, I did not look that closely. Maybe @stefank knows more. Yes, but it was the os::commit work with ZGC's usage of VirtualAlloc2. There's a PR out for this: https://github.com/openjdk/jdk/pull/29471 ------------- PR Comment: https://git.openjdk.org/jdk/pull/29240#issuecomment-3816211381 From alanb at openjdk.org Thu Jan 29 09:03:48 2026 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 29 Jan 2026 09:03:48 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 04:57:11 GMT, David Holmes wrote: >> src/hotspot/share/classfile/javaClasses.cpp line 1914: >> >>> 1912: >>> 1913: bool has_java_thread = tlh.cv_internal_thread_to_JavaThread(jthread, &java_thread, &thread_oop); >>> 1914: assert((has_java_thread && thread_oop != nullptr) || !has_java_thread, "Missing Thread oop"); >> >> Suggestion: >> >> assert(!has_java_thread || thread_oop != nullptr, "Missing Thread oop"); > > FWIW the same "shape" assert is in threadService.cpp Thanks, that is a better assert. We can change the assert in threadService.cpp too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2740604845 From alanb at openjdk.org Thu Jan 29 09:03:53 2026 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 29 Jan 2026 09:03:53 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 04:31:43 GMT, David Holmes wrote: >> JDK-8364343 upgraded the virtual thread transition management to be independent of JVMTI. We can update java_lang_Thread::async_get_stack_trace to use it and remove the suspend + retry code from Thread.getStackTrace. >> >> A summary of the changes: >> >> - java_lang_Thread::async_get_stack_trace is changed to use the new handshake op so it can be called to get the stack trace of a started thread in any state >> - Thread::getStackTrace is changed to use async_get_stack_trace for all cases >> - The SUSPENDED substate in VirtualThread is removed >> - JVM_CreateThreadSnapshot is changed to be usable when JVMTI is not compiled in >> - ThreadSnapshotFactory::get_thread_snapshot is changed to not upcall to StackTraceElement to complete the init of the stack trace >> >> The changes mean that Thread::getStackTrace may be slower when sampling a virtual thread in transition. This case should be rare, and it isn't really a performance critical op anyway. I prototyped use a spin loop and an increasing wait time in MountUnmountDisabler::disable_transition_for_one to avoid the wait(10) but decided to leave it out for now. Future work may examine this issue as there may be other cases (with JVMTI) that would benefit from avoiding the wait. >> >> A future PR might propose to change Thread.getStackTrace to use ThreadSnapshot and allow java_lang_Thread::async_get_stack_trace be removed. This requires more extensive changes to ThreadSnapshotFactory to reduce overhead when only the stack trace is required. >> >> Testing: tier1-5. The changes has been already been tested in the loom repo for a few months. > > src/hotspot/share/services/threadService.cpp line 1509: > >> 1507: >> 1508: // call static StackTraceElement[] StackTraceElement.of(StackTraceElement[] stackTrace) >> 1509: // to properly initialize STEs. > > Why can this be removed? All "finishing" is now done in ThreadSnapshort.of(Thread) for all the components (locks, blockers, ...). It previously left the finishing of the stack trace to ThreadSnapshotFactory::get_thread_snapshot, so different to Thread::getStackTrace which has always done the finish in Java code. > src/java.base/share/classes/java/lang/Thread.java line 2218: > >> 2216: } >> 2217: Object trace = getStackTrace0(); >> 2218: if (trace instanceof StackTraceElement[] stackTrace) { > > What can this return other than a `StackTraceElement[]` ?? It can only return a StackTraceElement[] or null. Using a type pattern seemed nicer here to avoid a null check + explicit cast. > test/micro/org/openjdk/bench/java/lang/ThreadGetStackTraceWhenParked.java line 2: > >> 1: /* >> 2: * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. > > Are these "new" test files from the Loom repo? Yes (and from 2025). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2740608688 PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2740614233 PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2740614537 From epeter at openjdk.org Thu Jan 29 09:04:53 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Thu, 29 Jan 2026 09:04:53 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v9] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 19:02:44 GMT, Mohamed Issa wrote: >> Intel® 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: > > Add double precision test to CMoveLConstants.java FYI: testing launched ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28337#issuecomment-3816377081 From jbhateja at openjdk.org Thu Jan 29 09:04:53 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 29 Jan 2026 09:04:53 GMT Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass them to intrinsic entries In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 08:09:36 GMT, Quan Anh Mai wrote: >> As per [discussions ](https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594) on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch in preparation of Float16 vector API support. >> >> Patch add new lane type constants and pass them to vector intrinsic entry points. >> >> All existing Vector API jtreg test are passing with the patch. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > src/hotspot/share/prims/vectorSupport.hpp line 140: > >> 138: }; >> 139: >> 140: enum { > > Please use a scoped enum instead. Its contained in VectorSupport class which makes it implicitly scoped. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2740618259 From alanb at openjdk.org Thu Jan 29 09:08:53 2026 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 29 Jan 2026 09:08:53 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases In-Reply-To: References: Message-ID: <5yJEl4AoQCIk6otjuEKfbtcLJ3cGBWcF3qasy-9ts7Y=.966925dc-f747-4e50-82c3-c0f544139796@github.com> On Thu, 29 Jan 2026 04:47:55 GMT, David Holmes wrote: >> JDK-8364343 upgraded the virtual thread transition management to be independent of JVMTI. We can update java_lang_Thread::async_get_stack_trace to use it and remove the suspend + retry code from Thread.getStackTrace. >> >> A summary of the changes: >> >> - java_lang_Thread::async_get_stack_trace is changed to use the new handshake op so it can be called to get the stack trace of a started thread in any state >> - Thread::getStackTrace is changed to use async_get_stack_trace for all cases >> - The SUSPENDED substate in VirtualThread is removed >> - JVM_CreateThreadSnapshot is changed to be usable when JVMTI is not compiled in >> - ThreadSnapshotFactory::get_thread_snapshot is changed to not upcall to StackTraceElement to complete the init of the stack trace >> >> The changes mean that Thread::getStackTrace may be slower when sampling a virtual thread in transition. This case should be rare, and it isn't really a performance critical op anyway. I prototyped use a spin loop and an increasing wait time in MountUnmountDisabler::disable_transition_for_one to avoid the wait(10) but decided to leave it out for now. Future work may examine this issue as there may be other cases (with JVMTI) that would benefit from avoiding the wait. >> >> A future PR might propose to change Thread.getStackTrace to use ThreadSnapshot and allow java_lang_Thread::async_get_stack_trace be removed. This requires more extensive changes to ThreadSnapshotFactory to reduce overhead when only the stack trace is required. >> >> Testing: tier1-5. The changes has been already been tested in the loom repo for a few months. > > src/java.base/share/classes/java/lang/StackTraceElement.java line 578: > >> 576: } >> 577: >> 578: static StackTraceElement[] finishInit(StackTraceElement[] stackTrace) { > > Out of curiousity what does this actually do, and why do we need it? The format depends on whether the class loader has a name and other complexity as to whether a module version is included. Nothing has changed, only the name of the method to finish the initialization. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2740630911 From qamai at openjdk.org Thu Jan 29 09:10:55 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 29 Jan 2026 09:10:55 GMT Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass them to intrinsic entries In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 09:02:29 GMT, Jatin Bhateja wrote: >> src/hotspot/share/prims/vectorSupport.hpp line 140: >> >>> 138: }; >>> 139: >>> 140: enum { >> >> Please use a scoped enum instead. > > Its contained in VectorSupport class which makes it implicitly scoped for external uses without being a named (scoped) enum I mean an `enum class`. With this we just pass `int` around which is not recommended. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2740638154 From tschatzl at openjdk.org Thu Jan 29 09:14:19 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 29 Jan 2026 09:14:19 GMT Subject: RFR: 8376357: Parallel: Convert MutableSpace classes to use Atomic In-Reply-To: <6AE-M8uvq7FAfVoArxQTWI5zM61RxTapF0OjUHz8YNY=.fed7cbf8-6f33-4c78-a38b-1beb56580beb@github.com> References: <6AE-M8uvq7FAfVoArxQTWI5zM61RxTapF0OjUHz8YNY=.fed7cbf8-6f33-4c78-a38b-1beb56580beb@github.com> Message-ID: On Wed, 28 Jan 2026 21:15:50 GMT, David Holmes wrote: >> Hi all, >> >> please review these changes that convert `MutableSpace` classes to use `Atomic`. >> >> Testing: gha, tier1-5 >> >> Thanks, >> Thomas > > src/hotspot/share/runtime/vmStructs.cpp line 904: > >> 902: \ >> 903: declare_toplevel_type(void*) \ >> 904: declare_toplevel_type(Atomic) \ > > This placement (under "C primitive pointer types ") seems inappropriate. Since other changes also place this toplevel type at the same location to avoid future merge issues, I would like to wait finding a more appropriate place until later, filed https://bugs.openjdk.org/browse/JDK-8376664 and assigned it to me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29427#discussion_r2740651055 From alanb at openjdk.org Thu Jan 29 09:15:36 2026 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 29 Jan 2026 09:15:36 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 04:30:46 GMT, David Holmes wrote: >> JDK-8364343 upgraded the virtual thread transition management to be independent of JVMTI. We can update java_lang_Thread::async_get_stack_trace to use it and remove the suspend + retry code from Thread.getStackTrace. >> >> A summary of the changes: >> >> - java_lang_Thread::async_get_stack_trace is changed to use the new handshake op so it can be called to get the stack trace of a started thread in any state >> - Thread::getStackTrace is changed to use async_get_stack_trace for all cases >> - The SUSPENDED substate in VirtualThread is removed >> - JVM_CreateThreadSnapshot is changed to be usable when JVMTI is not compiled in >> - ThreadSnapshotFactory::get_thread_snapshot is changed to not upcall to StackTraceElement to complete the init of the stack trace >> >> The changes mean that Thread::getStackTrace may be slower when sampling a virtual thread in transition. This case should be rare, and it isn't really a performance critical op anyway. I prototyped use a spin loop and an increasing wait time in MountUnmountDisabler::disable_transition_for_one to avoid the wait(10) but decided to leave it out for now. Future work may examine this issue as there may be other cases (with JVMTI) that would benefit from avoiding the wait. >> >> A future PR might propose to change Thread.getStackTrace to use ThreadSnapshot and allow java_lang_Thread::async_get_stack_trace be removed. This requires more extensive changes to ThreadSnapshotFactory to reduce overhead when only the stack trace is required. >> >> Testing: tier1-5. The changes has been already been tested in the loom repo for a few months. > > src/hotspot/share/services/threadService.cpp line 1479: > >> 1477: if (cl._thread_status == JavaThreadStatus::NEW || cl._thread_status == JavaThreadStatus::TERMINATED) { >> 1478: return nullptr; >> 1479: } > > It is not obvious to me why this is only a possibility now? ThreadSnapshot.of(Thread) may be invoked with a platform or virtual Thread in any state. It could sample the thread state before calling ThreadSnapshotFactory::get_thread_snapshot. That would allow it to filter out unstarted/NEW threads. It could also filter terminated threads but that would be racy and get_thread_snapshot would still need to handle terminated threads. For platform threads, get_thread_snapshot will bail out early if there is no JavaThread. So the effect of the above is to have virtual threads also be filtered out. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2740654504 From sspitsyn at openjdk.org Thu Jan 29 09:23:41 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 29 Jan 2026 09:23:41 GMT Subject: RFR: 8373367: interp-only mechanism fails to work for carrier threads in a corner case [v2] In-Reply-To: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com> References: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com> Message-ID: > The `interp-only` mechanism is based on the `JavaThread` objects. Carrier and virtual threads can temporary share the same `JavaThread`. The `java_thread->jvmti_thread_state()` is re-linked to a virtual thread at `mount` and to the carrier thread at `unmount`. The `JvmtiThreadState` has a back link to the `JavaThread` which is also set for virtual thread at a `mount` and carrier thread at an `unmount`. Just one of these two links at the same time is set to the `JavaThread`, the other one has to be set to `nullptr`. The `interp-only` mechanism needs this invariant. > However, there is a corner case when this invariant is broken. It happens when the `JvmtiThreadState` for carrier thread has just been created. In such case, the link to `JavaThread` is always `non-nullptr` even though a virtual thread is currently mounted on a carrier thread. This simple update fixes the issue in the `JvmtiThreadState` ctor. > > Testing: > - TBD: Mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: some tweaks for carrier thread JvmtiThreadState initialization ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29436/files - new: https://git.openjdk.org/jdk/pull/29436/files/4e3ff29a..23d6f88e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29436&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29436&range=00-01 Stats: 15 lines in 1 file changed: 9 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29436.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29436/head:pull/29436 PR: https://git.openjdk.org/jdk/pull/29436 From sspitsyn at openjdk.org Thu Jan 29 09:23:43 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 29 Jan 2026 09:23:43 GMT Subject: RFR: 8373367: interp-only mechanism fails to work for carrier threads in a corner case [v2] In-Reply-To: References: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com> <_0tOPRnuKQWXGAb9CON1DJ_Wj0-3JIKF8WaFHOQxcbM=.18c2c63f-5313-454f-8ee3-8a13d6be1fc2@github.com> Message-ID: On Wed, 28 Jan 2026 00:13:53 GMT, Alex Menkov wrote: >> src/hotspot/share/prims/jvmtiThreadState.cpp line 127: >> >>> 125: thread->set_interp_only_mode(false); >>> 126: } >>> 127: if (JvmtiEnvBase::is_thread_carrying_vthread(thread, thread_oop)) { >> >> wouldn't be better to move this into the beginning of ctor: >> >> if(!JvmtiEnvBase::is_thread_carrying_vthread(thread, thread_oop)) { >> _thread = thread; >> _thread_saved = nullptr; >> } else { >> _thread_saved = thread; >> _thread = nullptr; >> } >> >> and might be add comments with explanation. > > +1 > And have you tried to implement a test for the case? > wouldn't be better to move this into the beginning of ctor Good suggestion, thanks. Fixed now and added a comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29436#discussion_r2740677522 From sspitsyn at openjdk.org Thu Jan 29 09:27:57 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 29 Jan 2026 09:27:57 GMT Subject: RFR: 8373367: interp-only mechanism fails to work for carrier threads in a corner case [v2] In-Reply-To: References: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com> <_0tOPRnuKQWXGAb9CON1DJ_Wj0-3JIKF8WaFHOQxcbM=.18c2c63f-5313-454f-8ee3-8a13d6be1fc2@github.com> Message-ID: <7UKo8YzijAm9n3S5ePQjJbIR9E8Z7cQfmpLSHwcBe_w=.6cce24e2-294a-4b67-86d5-acf698c32213@github.com> On Thu, 29 Jan 2026 09:18:37 GMT, Serguei Spitsyn wrote: >> +1 >> And have you tried to implement a test for the case? > >> wouldn't be better to move this into the beginning of ctor > > Good suggestion, thanks. Fixed now and added a comment. > And have you tried to implement a test for the case? This issue was discovered in a branch with another PR as it has an optimized implementation for the `FramePop` events. Some of the existing tests were failing intermittently. Now, I do not remember the exact failing tests. In fact, it is not easy to provide a test coverage for this issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29436#discussion_r2740700582 From stuefe at openjdk.org Thu Jan 29 09:33:11 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 29 Jan 2026 09:33:11 GMT Subject: RFR: 8253683: Clean up and clarify uses of os::vm_allocation_granularity In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 11:30:32 GMT, Frederic Thevenet wrote: >> Hi everyone, >> >> `os::vm_allocation_granularity()` is meant to describe the alignment restrictions of the operating system when we reserve memory. That is 64 KiB on Windows (`VirtualAlloc`) and 256 MiB on AIX (with `shmat`). On every other platform it happens to match the page size. The page size (available via `os::vm_page_size()`) is what matters when we later commit or protect the reserved pages. >> >> Because the functions are poorly documented and the two numbers are identical on most systems, they have gradually been used more and more interchangeably. We now have many code paths that round **sizes** up to `os::vm_allocation_granularity()` or assert that a size is a multiple of it. That is wrong. Only addresses need that alignment, sizes merely have to be page-aligned. Places that round sizes should instead use `os::vm_page_size()` as they are unrelated to attach alignment. >> >> For this change I have gone over the call sites of `os::vm_allocation_granularity()` and where it was being used to pad or sanity-check a size I have instead replaced it with `os::vm_page_size()`. The calls that genuinely deal with an attach address are left untouched. >> >> Testing: >> - Oracle tiers 1-8 > > src/hotspot/os/windows/os_windows.cpp line 2997: > >> 2995: char * p_buf; >> 2996: // note: at setup time we guaranteed that NUMAInterleaveGranularity was aligned up to a page size >> 2997: size_t page_size = UseLargePages ? _large_page_size : os::vm_page_size(); > > I don't think using `vm_page_size` instead of `vm_allocation_granularity` is appropriate here, as `page_size` is later used to align an address to pass to `virtualAlloc` (`next_alloc_addr`), not just region sizes (see lines 3023-3030) Hmm, I agree with @fthevenet in that this code looks strange if it were ever called for non numa non largepages. In practice, this is only called for `(UseLargePagesIndividualAllocation || UseNUMAInterleaving)` and maybe we should assert this here, if only as documentation. For NUMA, we use `NUMAInterleaveGranularity` for chunksize, which is constrained to be at least allocation granularity (see `NUMAInterleaveGranularityConstraintFunc`). For large pages, these are large 2MB pages. So the value for chunk size will always be >= pagesize since alloc granularity >= page size. And maybe we also should assert that :-) --- Note that this also could benefit from a rewrite using VirtualAlloc2 and placeholder regions. See https://bugs.openjdk.org/browse/JDK-8376561. Ping @roberttoyonaga - another case of reserve-release-reserve. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28493#discussion_r2740692794 From stuefe at openjdk.org Thu Jan 29 09:33:09 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 29 Jan 2026 09:33:09 GMT Subject: RFR: 8253683: Clean up and clarify uses of os::vm_allocation_granularity In-Reply-To: References: Message-ID: On Tue, 25 Nov 2025 14:31:39 GMT, Casper Norrbin wrote: > Hi everyone, > > `os::vm_allocation_granularity()` is meant to describe the alignment restrictions of the operating system when we reserve memory. That is 64 KiB on Windows (`VirtualAlloc`) and 256 MiB on AIX (with `shmat`). On every other platform it happens to match the page size. The page size (available via `os::vm_page_size()`) is what matters when we later commit or protect the reserved pages. > > Because the functions are poorly documented and the two numbers are identical on most systems, they have gradually been used more and more interchangeably. We now have many code paths that round **sizes** up to `os::vm_allocation_granularity()` or assert that a size is a multiple of it. That is wrong. Only addresses need that alignment, sizes merely have to be page-aligned. Places that round sizes should instead use `os::vm_page_size()` as they are unrelated to attach alignment. > > For this change I have gone over the call sites of `os::vm_allocation_granularity()` and where it was being used to pad or sanity-check a size I have instead replaced it with `os::vm_page_size()`. The calls that genuinely deal with an attach address are left untouched. > > Testing: > - Oracle tiers 1-8 I think this looks good and was a lot of work. This requires some thorough testing, though, since I did not follow all use cases and derived sizes may now be different. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28493#pullrequestreview-3721552391 From mdoerr at openjdk.org Thu Jan 29 09:35:10 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 29 Jan 2026 09:35:10 GMT Subject: RFR: 8376472: Shenandoah: Assembler store barriers read destination memory despite the decorators In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 22:41:43 GMT, William Kemper wrote: >> The issue is really a correctness issue, and it readily manifests in Valhalla, which sometimes does the stores with `IS_DEST_UNINITIALIZED` set. Unfortunately, Shenandoah SATB barriers ignore this attribute, and attempt to read the memory at store address. At best it crashes the VM with the "oopness" asserts, at worst it feeds "garbage" pointers into SATB machinery, which then wrecks havoc on everything else. >> >> We need to make sure store barriers are consistently checking these attributes. Unfortunately, that would mean doing the changes in arch-specific assembler code. >> >> This PR makes sure the ShenandoahBarrierSetAssembler store barriers are roughly in the same shape, and that they consult `ShenandoahBarrierSet::need_*_barrier` to make the proper decisions whether to use SATB/card barriers. >> >> `hotspot_gc_shenandoah` is enough to sanity-check this patch, but I am also running `all` tests for extra safety. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` >> - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah` >> - [x] Linux x86_64 server fastdebug, `all` + `-XX:+UseShenandoahGC` >> - [x] Linux AArch64 server fastdebug, `all` + `-XX:+UseShenandoahGC` >> - [x] Linux {PPC64, RISC-V, S390X} server fastdebug, cross-compilation > > Marked as reviewed by wkemper (Reviewer). > Thanks @earthling-amzn! > > @RealFYang, @TheRealMDoerr -- you might want to run RISC-V / PPC tests on this PR? I am pretty sure the move did not break anything. A simple `make test TEST=hotspot_gc_shenandoah` would do for testing. Thanks a lot for implementing it for all platforms! Test results on PPC64 look good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29444#issuecomment-3816506314 From stuefe at openjdk.org Thu Jan 29 09:39:25 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 29 Jan 2026 09:39:25 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v4] In-Reply-To: References: <93J0DXbDwwQDYqasv9f9lF4NofBWMLb4NTiyMCXkdsM=.bc351bf6-8408-4c4d-990d-99df03a21649@github.com> Message-ID: On Fri, 23 Jan 2026 14:59:45 GMT, Ivan Bereziuk wrote: > The timestamping implemented in JCmd.java would print timestamp only once at the beginning. Good point. For me the biggest point would be to cleanly correlate time in logs, e.g. gc logs, with time from command invocations the analyst or customer does. Without wondering about offsets. > We also have DiagnosticCommandMBean for remove invokation. Keeping this timestamp on the client side means we don't need a project to look into what could happen there. Also good point. I know I am of no help here :-D My gut instinct is to keep jcmd client side simple and stupid, and put logic like this into hotspot. But I can live with both solutions. Having a timestamp always printed will be a good thing in any case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3816525840 From jbhateja at openjdk.org Thu Jan 29 09:43:30 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 29 Jan 2026 09:43:30 GMT Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass them to intrinsic entries [v2] In-Reply-To: References: Message-ID: > As per [discussions ](https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594) on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch in preparation of Float16 vector API support. > > Patch add new lane type constants and pass them to vector intrinsic entry points. > > All existing Vector API jtreg test are passing with the patch. > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Review comments resolution ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29481/files - new: https://git.openjdk.org/jdk/pull/29481/files/ef96506d..11021544 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29481&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29481&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29481.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29481/head:pull/29481 PR: https://git.openjdk.org/jdk/pull/29481 From stuefe at openjdk.org Thu Jan 29 09:50:30 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 29 Jan 2026 09:50:30 GMT Subject: RFR: 8359706: Add file descriptor count to VM.info [v8] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 19:53:41 GMT, Kieran Farrell wrote: >> 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 incrementally with one additional commit since the last revision: > > minor updates Sorry for the long delay. Can you please add some jtreg test for this? The simplest way would be to extend test/jdk/sun/tools/jcmd/TestJcmdSanity.java. See testJcmdPidVMinfo. Please test that the output shows the parameter "END." at the end (indicating that the printout did not time out). And please test, on Mac and Linux, that we see "Open File Descriptors: \\d+". (you can just use Platform.isxxx to exclude other platforms). Thanks! src/hotspot/os/bsd/os_bsd.cpp line 2617: > 2615: st->print_cr("Open File Descriptors: unknown"); > 2616: #endif > 2617: } stray newline src/hotspot/os/linux/os_linux.cpp line 5412: > 5410: timed_out = true; > 5411: break; > 5412: } Can you please do a little manual test like this: if (fds > some number) sleep(Timeout * 2); and check if the timeout works? ------------- PR Review: https://git.openjdk.org/jdk/pull/27971#pullrequestreview-3721621599 PR Review Comment: https://git.openjdk.org/jdk/pull/27971#discussion_r2740752734 PR Review Comment: https://git.openjdk.org/jdk/pull/27971#discussion_r2740765861 From adinn at openjdk.org Thu Jan 29 10:48:32 2026 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 29 Jan 2026 10:48:32 GMT Subject: RFR: 8372617: Save and restore stubgen stubs when using an AOT code cache [v8] In-Reply-To: References: Message-ID: <4GvCD6GmYPb9SNGB9spUf7JnhXKRMXsZ14yEGTKnIjI=.8dffb830-af67-4bcc-9553-6ef76226a2a8@github.com> > This PR adds save and restore of all generated stubs to the AOT code cache on x86 and aarch64. Other arches are modified to deal with the related generic PAI changes. > > Small changes were required to the aarch64 and x86_64 generator code in order to meet two key constraints: > 1. the first declared entry of every stub starts at the first instruction in the stub code range > 2. all data/code cross-references from one stub to another target a declared stub entry Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: Run AOTCodeFlags test with multiple GCs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28433/files - new: https://git.openjdk.org/jdk/pull/28433/files/924a30f4..1c4b3f43 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28433&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28433&range=06-07 Stats: 84 lines in 1 file changed: 80 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28433.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28433/head:pull/28433 PR: https://git.openjdk.org/jdk/pull/28433 From adinn at openjdk.org Thu Jan 29 10:57:40 2026 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 29 Jan 2026 10:57:40 GMT Subject: RFR: 8372617: Save and restore stubgen stubs when using an AOT code cache [v4] In-Reply-To: References: Message-ID: <2u7_uahnB2vGhVMPpgmmZtCtGLECRW2lNjWiJle9w4U=.3574cd76-e68e-46c2-a40d-f5a786e6d525@github.com> On Mon, 26 Jan 2026 17:58:49 GMT, Vladimir Kozlov wrote: >> Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision: >> >> - fix whitespace issue >> - remaining asmehra feedback > > Also several tests (including runtime/cds/appcds/aotCache/) filed when run with GC different from G1: > > > # SIGSEGV (0xb) at pc=0x00007f21738f106d, pid=3522829, tid=3522833 > # > # JRE version: Java(TM) SE Runtime Environment (27.0) (fastdebug build 27-internal-2026-01-24-0025574.vladimir.kozlov.jdkgit2) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 27-internal-2026-01-24-0025574.vladimir.kozlov.jdkgit2, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, serial gc, linux-amd64) > # Problematic frame: > # v ~BufferBlob::final_blob (stub gen) 0x00007f21738f106d > > -XX:MaxRAMPercentage=4.16667 -XX:+UseSerialGC -Xlog:class+load -Dcom.sun.management.jmxremote=true -Xlog:arguments,aot,cds:file=HelloAOTCache-with-management-agent.production.log::filesize=0 -XX:AOTMode=on -XX:AOTCache=HelloAOTCache-with-management-agent.aot HelloAOTCacheApp > > Stack: [0x00007f218dffc000,0x00007f218e0fd000], sp=0x00007f218e0f7af0, free space=1006k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > v ~BufferBlob::final_blob (stub gen) 0x00007f21738f106d > J 280 c1 java.util.Arrays.copyOf([Ljava/lang/Object;ILjava/lang/Class;)[Ljava/lang/Object; java.base at 27-internal (40 bytes) @ 0x00007f216c30d2ce [0x00007f216c30d000+0x00000000000002ce] > J 378 c1 java.util.ArrayList.grow(I)[Ljava/lang/Object; java.base at 27-internal (60 bytes) @ 0x00007f216c30cc2c [0x00007f216c30cb00+0x000000000000012c] @vnkozlov @ashu-mehra I have added a hash table to speed up address to id translation during assembly and that now appears to be working correctly. I also put a check into the table insert method to detect and refuse repeated registrations of externals. That allowed me to prune a few unnecessary additions from the `init_extrs` and `init_extrs2` methods of `AOTCodeAddressTable`. The previous GC errors were to do with callouts from the Z and Shenandoah stubs currently in mainline that we did not have to deal with in the earlier premain version. I believe I have fixed this by adding the necessary external address initializations to `AOTCodeAddressTable::init_extrs`. I also modified the AOTCodeFlags test to run 4 times, with G1 (default), Z, Shenandoah and Parallel GCs, and it passed all 4 on aarch64. I have not yet tested it on x86_64 but I did get HelloWorld to work on both arches. If this passes the PR gate plus any further testing you can do then that would be enough to allow the present PR to be integrated. That said, it would probably be better if we removed addition of the GC-specific externals from `init_extrs` and instead delegated responsibility to a static method of BarrierSetRuntime (and through it to BarrierSetNMethod and BarrierSetAssembler) called immediately after GC stub generation i.e. we can make the GC was responsible for adding the externals that it relies on. Likewise, when we integrate save and restore of nmethods into mainline (also when we merge this back into premain) we can delegate to the C1BarrierSet and C2BarrierSet in order to register externals that are specific to compiled C1 and C2 Java method code. Should I make the delegation changes now? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28433#issuecomment-3816913020 From stuefe at openjdk.org Thu Jan 29 11:04:04 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 29 Jan 2026 11:04:04 GMT Subject: RFR: 8373096: JFR: Path-to-gc-roots search should be non-recursive [v3] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 20:36:34 GMT, Erik Gahlin wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> dont incremement _num_objects_processed for follow-up chunks > > test/jdk/jdk/jfr/jcmd/TestJcmdDumpPathToGCRootsDFSBase.java line 67: > >> 65: File recording = new File(jfrFileName + r.getId() + ".jfr"); >> 66: recording.delete(); >> 67: JcmdHelper.jcmd("JFR.dump", "name=dodo", pathToGcRoots, "filename=" + recording.getAbsolutePath()); > > Why do we need to do this using jcmd? Hmm, I just followed the same approach as `TestJcmdDumpPathToGCRoots`. I guess the alternative would be to start a child process JVM with -XX:StartFlightRecording dumponexit=true? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29382#discussion_r2741088293 From alanb at openjdk.org Thu Jan 29 11:15:20 2026 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 29 Jan 2026 11:15:20 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases [v2] In-Reply-To: References: Message-ID: <0mAlTvcltJnprgF188hBZ3fJuIUb9OR7YUjGEWyyJo0=.fdeed8d4-a5dd-4185-8809-bbc5ccc4e3ab@github.com> > JDK-8364343 upgraded the virtual thread transition management to be independent of JVMTI. We can update java_lang_Thread::async_get_stack_trace to use it and remove the suspend + retry code from Thread.getStackTrace. > > A summary of the changes: > > - java_lang_Thread::async_get_stack_trace is changed to use the new handshake op so it can be called to get the stack trace of a started thread in any state > - Thread::getStackTrace is changed to use async_get_stack_trace for all cases > - The SUSPENDED substate in VirtualThread is removed > - JVM_CreateThreadSnapshot is changed to be usable when JVMTI is not compiled in > - ThreadSnapshotFactory::get_thread_snapshot is changed to not upcall to StackTraceElement to complete the init of the stack trace > > The changes mean that Thread::getStackTrace may be slower when sampling a virtual thread in transition. This case should be rare, and it isn't really a performance critical op anyway. I prototyped use a spin loop and an increasing wait time in MountUnmountDisabler::disable_transition_for_one to avoid the wait(10) but decided to leave it out for now. Future work may examine this issue as there may be other cases (with JVMTI) that would benefit from avoiding the wait. > > A future PR might propose to change Thread.getStackTrace to use ThreadSnapshot and allow java_lang_Thread::async_get_stack_trace be removed. This requires more extensive changes to ThreadSnapshotFactory to reduce overhead when only the stack trace is required. > > Testing: tier1-5. The changes has been already been tested in the loom repo for a few months. Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: Improve asserts ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29461/files - new: https://git.openjdk.org/jdk/pull/29461/files/cb4222e9..12214cd8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29461&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29461&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29461/head:pull/29461 PR: https://git.openjdk.org/jdk/pull/29461 From adinn at openjdk.org Thu Jan 29 11:19:15 2026 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 29 Jan 2026 11:19:15 GMT Subject: RFR: 8372617: Save and restore stubgen stubs when using an AOT code cache [v8] In-Reply-To: <4GvCD6GmYPb9SNGB9spUf7JnhXKRMXsZ14yEGTKnIjI=.8dffb830-af67-4bcc-9553-6ef76226a2a8@github.com> References: <4GvCD6GmYPb9SNGB9spUf7JnhXKRMXsZ14yEGTKnIjI=.8dffb830-af67-4bcc-9553-6ef76226a2a8@github.com> Message-ID: On Thu, 29 Jan 2026 10:48:32 GMT, Andrew Dinn wrote: >> This PR adds save and restore of all generated stubs to the AOT code cache on x86 and aarch64. Other arches are modified to deal with the related generic PAI changes. >> >> Small changes were required to the aarch64 and x86_64 generator code in order to meet two key constraints: >> 1. the first declared entry of every stub starts at the first instruction in the stub code range >> 2. all data/code cross-references from one stub to another target a declared stub entry > > Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: > > Run AOTCodeFlags test with multiple GCs n.b. Updated AOTCodeFlags test also passes on x86_64 ------------- PR Comment: https://git.openjdk.org/jdk/pull/28433#issuecomment-3817007691 From qamai at openjdk.org Thu Jan 29 11:22:29 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 29 Jan 2026 11:22:29 GMT Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass them to intrinsic entries [v2] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 09:43:30 GMT, Jatin Bhateja wrote: >> As per [discussions ](https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594) on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch in preparation of Float16 vector API support. >> >> Patch add new lane type constants and pass them to vector intrinsic entry points. >> >> All existing Vector API jtreg test are passing with the patch. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Review comments resolution src/hotspot/share/prims/vectorSupport.cpp line 202: > 200: } > 201: > 202: int VectorSupport::vop2ideal(jint id, BasicType bt) { Previously, this method accepts a `BasicType`, now it accepts an untyped `int`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2741153639 From qamai at openjdk.org Thu Jan 29 11:22:31 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 29 Jan 2026 11:22:31 GMT Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass them to intrinsic entries [v2] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 09:07:54 GMT, Quan Anh Mai wrote: >> Its contained in VectorSupport class which makes it implicitly scoped for external uses without being a named (scoped) enum > > I mean an `enum class`. With this we just pass `int` around which is not recommended. I don't see this gets resolved. My suggestion is to use a scoped enum so we have a strongly typed value instead of using an unscoped enum and passing `int` all over the places. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2741147870 From shade at openjdk.org Thu Jan 29 11:29:09 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 29 Jan 2026 11:29:09 GMT Subject: RFR: 8375359: Improve GC serviceability init staging In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 16:43:40 GMT, Aleksey Shipilev wrote: > As per docs, `CollectedHeap::post_initialize` is for doing inits that should be done before general allocations are accepted. Currently, serviceability layer initialized there via the call to `CollectedHeap::initialize_serviceability`. This bug shows that after `CollectedHeap::post_initialize` returns, the rest of the serviceability layer had not been fully initialized yet. But GC code might assume general allocation path works at that point! So if that allocation path reports anything to the serviceability layer, it could encounter not yet fully initialized serviceability support and fail. > > This readily manifests in improved Epsilon stress test. Improved test fails pretty consistently on my machines, and serves as a good regression test. > > So the fix is to peel off serviceability initialization from post-init stage, and do it separately, before going (and finishing) `post_initialize`. Conveniently, we are nearly there, and "just" need to touch up a few things in `universe_post_init()`. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `gc/epsilon/TestInitAllocs.java`, 10x > - [x] Linux x86_64 server fastdebug, `hotspot_gc` Still fishing for more reviewers... :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/29254#issuecomment-3817053925 From jbhateja at openjdk.org Thu Jan 29 11:39:35 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 29 Jan 2026 11:39:35 GMT Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass them to intrinsic entries [v2] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 11:19:18 GMT, Quan Anh Mai wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments resolution > > src/hotspot/share/prims/vectorSupport.cpp line 202: > >> 200: } >> 201: >> 202: int VectorSupport::vop2ideal(jint id, BasicType bt) { > > Previously, this method accepts a `BasicType`, now it accepts an untyped `int`. Correct, we are passing an integer laneType from java side to intrinsic entry points. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2741207425 From qamai at openjdk.org Thu Jan 29 11:45:33 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 29 Jan 2026 11:45:33 GMT Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass them to intrinsic entries [v2] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 11:34:51 GMT, Jatin Bhateja wrote: >> src/hotspot/share/prims/vectorSupport.cpp line 202: >> >>> 200: } >>> 201: >>> 202: int VectorSupport::vop2ideal(jint id, BasicType bt) { >> >> Previously, this method accepts a `BasicType`, now it accepts an untyped `int`. > > Correct, we are passing an integer laneType from java side to intrinsic entry points. Please use a separate named type instead of `int`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2741235103 From jbhateja at openjdk.org Thu Jan 29 11:50:35 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 29 Jan 2026 11:50:35 GMT Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass them to intrinsic entries [v2] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 11:43:06 GMT, Quan Anh Mai wrote: >> Correct, we are passing an integer laneType from java side to intrinsic entry points. > > Please use a separate named type instead of `int`. It is indeed an integral value which is passed from Java side which is casted to BasicType. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2741250148 From stuefe at openjdk.org Thu Jan 29 11:56:23 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 29 Jan 2026 11:56:23 GMT Subject: RFR: 8373096: JFR: Path-to-gc-roots search should be non-recursive [v4] In-Reply-To: References: Message-ID: > This is a continuation - second attempt - of https://github.com/openjdk/jdk/pull/28659. > > ---- > > A customer reported a native stack overflow when producing a JFR recording with path-to-gc-roots=true. This happens regularly, see similar cases in JBS (e.g. https://bugs.openjdk.org/browse/JDK-8371630, https://bugs.openjdk.org/browse/JDK-8282427 etc). > > We limit the maximum graph search depth (DFSClosure::max_dfs_depth) to prevent stack overflows. That solution is brittle, however, since recursion depth is not a good proxy for thread stack usage: it depends on many factors, e.g., compiler inlining decisions and platform specifics. In this case, the VMThread's stack was too small. > > This patch rewrites the DFS heap tracer to be non-recursive. This is mostly textbook stuff, but the devil is in the details. Nevertheless, the algorithm should be a straightforward read. > > ### Memory usage of old vs new algorithm: > > The new algorithm uses, on average, a bit less memory than the old one. The old algorithm did cost ((avg stackframe size in bytes) * depth). As we have seen, e.g., in JDK-8371630, a depth of 3200 can max out ~1MB of stack space. > > The new algorithm costs ((avg number of outgoing refs per instanceKlass oop) * depth * 16. For a depth of 3200, we get typical probe stack sizes of 100KB..200KB. But we also cap probestack size, similar to how we cap the max. graph depth. > > In any case, these numbers are nothing to worry about. For a more in-depth explanation about memory cost, please see the comment in dfsClosure.cpp. > > ### Possible improvements/simplifications in the future: > > DFS works perfectly well alone now. It no longer depends on stack size, and its memory usage is typically smaller than BFS. IMHO, it would be perfectly fine to get rid of BFS and rely solely on the non-recursive DFS. The benefit would be a decrease in complexity and fewer tests to run and maintain. It should also be easy to convert into a parallelized version later. > > I kept the _max_dfs_depth_ parameter for now, but tbh it is no longer very useful. Before, it prevented stack overflows. Now, it is just an indirect way to limit probe stack size. But we also explicitly cap the probe stack size, so _max_dfs_depth_ is redundant. Removing it would require changing the statically allocated reference stack to be dynamically allocated, but that should not be difficult. > > ### Observable differences > > There is one observable side effect to the changed algorithm. The non-recursive algorithm processes oops a... Thomas Stuefe 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 23 additional commits since the last revision: - erics test remarks - different ul log tag - Merge branch 'master' into JFR-leak-profiler-path-to-gc-roots-non-recursive-take2-with-tracing - dont incremement _num_objects_processed for follow-up chunks - Update src/hotspot/share/jfr/leakprofiler/chains/dfsClosure.cpp Co-authored-by: Robert Toyonaga - fix after JDK-8375040 - tests - wip - revert unnecessary changes - wip - ... and 13 more: https://git.openjdk.org/jdk/compare/dd83f006...dd8c1bfd ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29382/files - new: https://git.openjdk.org/jdk/pull/29382/files/66276985..dd8c1bfd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29382&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29382&range=02-03 Stats: 5269 lines in 146 files changed: 3544 ins; 904 del; 821 mod Patch: https://git.openjdk.org/jdk/pull/29382.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29382/head:pull/29382 PR: https://git.openjdk.org/jdk/pull/29382 From stuefe at openjdk.org Thu Jan 29 11:56:24 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 29 Jan 2026 11:56:24 GMT Subject: RFR: 8373096: JFR: Path-to-gc-roots search should be non-recursive [v3] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 07:53:47 GMT, Thomas Stuefe wrote: >> This is a continuation - second attempt - of https://github.com/openjdk/jdk/pull/28659. >> >> ---- >> >> A customer reported a native stack overflow when producing a JFR recording with path-to-gc-roots=true. This happens regularly, see similar cases in JBS (e.g. https://bugs.openjdk.org/browse/JDK-8371630, https://bugs.openjdk.org/browse/JDK-8282427 etc). >> >> We limit the maximum graph search depth (DFSClosure::max_dfs_depth) to prevent stack overflows. That solution is brittle, however, since recursion depth is not a good proxy for thread stack usage: it depends on many factors, e.g., compiler inlining decisions and platform specifics. In this case, the VMThread's stack was too small. >> >> This patch rewrites the DFS heap tracer to be non-recursive. This is mostly textbook stuff, but the devil is in the details. Nevertheless, the algorithm should be a straightforward read. >> >> ### Memory usage of old vs new algorithm: >> >> The new algorithm uses, on average, a bit less memory than the old one. The old algorithm did cost ((avg stackframe size in bytes) * depth). As we have seen, e.g., in JDK-8371630, a depth of 3200 can max out ~1MB of stack space. >> >> The new algorithm costs ((avg number of outgoing refs per instanceKlass oop) * depth * 16. For a depth of 3200, we get typical probe stack sizes of 100KB..200KB. But we also cap probestack size, similar to how we cap the max. graph depth. >> >> In any case, these numbers are nothing to worry about. For a more in-depth explanation about memory cost, please see the comment in dfsClosure.cpp. >> >> ### Possible improvements/simplifications in the future: >> >> DFS works perfectly well alone now. It no longer depends on stack size, and its memory usage is typically smaller than BFS. IMHO, it would be perfectly fine to get rid of BFS and rely solely on the non-recursive DFS. The benefit would be a decrease in complexity and fewer tests to run and maintain. It should also be easy to convert into a parallelized version later. >> >> I kept the _max_dfs_depth_ parameter for now, but tbh it is no longer very useful. Before, it prevented stack overflows. Now, it is just an indirect way to limit probe stack size. But we also explicitly cap the probe stack size, so _max_dfs_depth_ is redundant. Removing it would require changing the statically allocated reference stack to be dynamically allocated, but that should not be difficult. >> >> ### Observable differences >> >> There is one observable side effect to the changed a... > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > dont incremement _num_objects_processed for follow-up chunks @egahlin thank you for reviewing this. I changed the UL tag as suggested and changed the test (also removed the cutoff setting since infinity is default) ------------- PR Comment: https://git.openjdk.org/jdk/pull/29382#issuecomment-3817180949 From qamai at openjdk.org Thu Jan 29 11:56:51 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 29 Jan 2026 11:56:51 GMT Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass them to intrinsic entries [v2] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 11:47:33 GMT, Jatin Bhateja wrote: >> Please use a separate named type instead of `int`. > > It is indeed an integral value which is passed from Java side which is casted to BasicType. So please cast it in the intrinsics functions in `vectorIntrinsics.cpp` and pass the `LaneType` into this function. static bool is_primitive_lane_type(int laneType) { return laneType >= VectorSupport::LT_FLOAT && laneType <= VectorSupport::LT_LONG; } This function could return a `LaneType` for you. Also, when do we pass in something that is not a valid value? Should this be an `assert`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2741273046 From stuefe at openjdk.org Thu Jan 29 12:01:20 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 29 Jan 2026 12:01:20 GMT Subject: RFR: 8373096: JFR: Path-to-gc-roots search should be non-recursive [v5] In-Reply-To: References: Message-ID: > This is a continuation - second attempt - of https://github.com/openjdk/jdk/pull/28659. > > ---- > > A customer reported a native stack overflow when producing a JFR recording with path-to-gc-roots=true. This happens regularly, see similar cases in JBS (e.g. https://bugs.openjdk.org/browse/JDK-8371630, https://bugs.openjdk.org/browse/JDK-8282427 etc). > > We limit the maximum graph search depth (DFSClosure::max_dfs_depth) to prevent stack overflows. That solution is brittle, however, since recursion depth is not a good proxy for thread stack usage: it depends on many factors, e.g., compiler inlining decisions and platform specifics. In this case, the VMThread's stack was too small. > > This patch rewrites the DFS heap tracer to be non-recursive. This is mostly textbook stuff, but the devil is in the details. Nevertheless, the algorithm should be a straightforward read. > > ### Memory usage of old vs new algorithm: > > The new algorithm uses, on average, a bit less memory than the old one. The old algorithm did cost ((avg stackframe size in bytes) * depth). As we have seen, e.g., in JDK-8371630, a depth of 3200 can max out ~1MB of stack space. > > The new algorithm costs ((avg number of outgoing refs per instanceKlass oop) * depth * 16. For a depth of 3200, we get typical probe stack sizes of 100KB..200KB. But we also cap probestack size, similar to how we cap the max. graph depth. > > In any case, these numbers are nothing to worry about. For a more in-depth explanation about memory cost, please see the comment in dfsClosure.cpp. > > ### Possible improvements/simplifications in the future: > > DFS works perfectly well alone now. It no longer depends on stack size, and its memory usage is typically smaller than BFS. IMHO, it would be perfectly fine to get rid of BFS and rely solely on the non-recursive DFS. The benefit would be a decrease in complexity and fewer tests to run and maintain. It should also be easy to convert into a parallelized version later. > > I kept the _max_dfs_depth_ parameter for now, but tbh it is no longer very useful. Before, it prevented stack overflows. Now, it is just an indirect way to limit probe stack size. But we also explicitly cap the probe stack size, so _max_dfs_depth_ is redundant. Removing it would require changing the statically allocated reference stack to be dynamically allocated, but that should not be difficult. > > ### Observable differences > > There is one observable side effect to the changed algorithm. The non-recursive algorithm processes oops a... Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: - remove unnecessary diff - copyrights ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29382/files - new: https://git.openjdk.org/jdk/pull/29382/files/dd8c1bfd..ecc2bb74 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29382&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29382&range=03-04 Stats: 8 lines in 7 files changed: 0 ins; 1 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/29382.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29382/head:pull/29382 PR: https://git.openjdk.org/jdk/pull/29382 From egahlin at openjdk.org Thu Jan 29 12:05:28 2026 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 29 Jan 2026 12:05:28 GMT Subject: RFR: 8373096: JFR: Path-to-gc-roots search should be non-recursive [v3] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 11:00:49 GMT, Thomas Stuefe wrote: >> test/jdk/jdk/jfr/jcmd/TestJcmdDumpPathToGCRootsDFSBase.java line 67: >> >>> 65: File recording = new File(jfrFileName + r.getId() + ".jfr"); >>> 66: recording.delete(); >>> 67: JcmdHelper.jcmd("JFR.dump", "name=dodo", pathToGcRoots, "filename=" + recording.getAbsolutePath()); >> >> Why do we need to do this using jcmd? > > Hmm, I just followed the same approach as `TestJcmdDumpPathToGCRoots`. I guess the alternative would be to start a child process JVM with -XX:StartFlightRecording dumponexit=true? This is how I would implement it: [patch.txt](https://github.com/user-attachments/files/24935579/patch.txt) - Put all relevant information in the test file so that, when it fails, it can be easily analyzed without having to flip back and forth between a base class during triage, for example. - Dump data programmatically, as it is quicker and easier to understand. - Use the Events class to dump and extract and recording data. - Place helper methods in the OldObjects class for reuse. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29382#discussion_r2741301803 From dfenacci at openjdk.org Thu Jan 29 12:42:44 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Thu, 29 Jan 2026 12:42:44 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v7] In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: > ## Issue > > This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. > > This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. > > ## Causes > > The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. > > ## Fix > > A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: > https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 > This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. > > # Testing > > * Tier 1-3+ > * 2 JTReg tests added > * `TestRangeCheck.java` as regression test for the reported issue > * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision: JDK-8374582: add flagless to test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29164/files - new: https://git.openjdk.org/jdk/pull/29164/files/a587a269..083d5698 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=05-06 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29164.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29164/head:pull/29164 PR: https://git.openjdk.org/jdk/pull/29164 From fyang at openjdk.org Thu Jan 29 12:56:23 2026 From: fyang at openjdk.org (Fei Yang) Date: Thu, 29 Jan 2026 12:56:23 GMT Subject: RFR: 8376472: Shenandoah: Assembler store barriers read destination memory despite the decorators In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 22:41:43 GMT, William Kemper wrote: >> The issue is really a correctness issue, and it readily manifests in Valhalla, which sometimes does the stores with `IS_DEST_UNINITIALIZED` set. Unfortunately, Shenandoah SATB barriers ignore this attribute, and attempt to read the memory at store address. At best it crashes the VM with the "oopness" asserts, at worst it feeds "garbage" pointers into SATB machinery, which then wrecks havoc on everything else. >> >> We need to make sure store barriers are consistently checking these attributes. Unfortunately, that would mean doing the changes in arch-specific assembler code. >> >> This PR makes sure the ShenandoahBarrierSetAssembler store barriers are roughly in the same shape, and that they consult `ShenandoahBarrierSet::need_*_barrier` to make the proper decisions whether to use SATB/card barriers. >> >> `hotspot_gc_shenandoah` is enough to sanity-check this patch, but I am also running `all` tests for extra safety. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` >> - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah` >> - [x] Linux x86_64 server fastdebug, `all` + `-XX:+UseShenandoahGC` >> - [x] Linux AArch64 server fastdebug, `all` + `-XX:+UseShenandoahGC` >> - [x] Linux {PPC64, RISC-V, S390X} server fastdebug, cross-compilation > > Marked as reviewed by wkemper (Reviewer). > Thanks @earthling-amzn! > > @RealFYang, @TheRealMDoerr -- you might want to run RISC-V / PPC tests on this PR? I am pretty sure the move did not break anything. A simple `make test TEST=hotspot_gc_shenandoah` would do for testing. Thanks for the ping. `hotspot_gc_shenandoah` test is good with fastdebug build on linux-riscv64. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29444#issuecomment-3817510169 From jbhateja at openjdk.org Thu Jan 29 12:58:57 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 29 Jan 2026 12:58:57 GMT Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass them to intrinsic entries [v3] In-Reply-To: References: Message-ID: > As per [discussions ](https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594) on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch in preparation of Float16 vector API support. > > Patch add new lane type constants and pass them to vector intrinsic entry points. > > All existing Vector API jtreg test are passing with the patch. > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Review comments resolutions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29481/files - new: https://git.openjdk.org/jdk/pull/29481/files/11021544..d81035fd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29481&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29481&range=01-02 Stats: 103 lines in 3 files changed: 23 ins; 0 del; 80 mod Patch: https://git.openjdk.org/jdk/pull/29481.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29481/head:pull/29481 PR: https://git.openjdk.org/jdk/pull/29481 From lkorinth at openjdk.org Thu Jan 29 14:47:12 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 29 Jan 2026 14:47:12 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v9] In-Reply-To: References: Message-ID: > This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. > > It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. > > This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. > > I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. Leo Korinth has updated the pull request incrementally with two additional commits since the last revision: - Reapply "remove commented out code" This reverts commit d0d1860058f0dae7813c3e5115e2784da8331f3b. - Reapply "Stefan J 4" This reverts commit c5a7e2bb44ce111f8c8d1d7f728f1bf8013475e0. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28723/files - new: https://git.openjdk.org/jdk/pull/28723/files/c5a7e2bb..4cf44ec8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28723&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28723&range=07-08 Stats: 3 lines in 2 files changed: 2 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28723.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28723/head:pull/28723 PR: https://git.openjdk.org/jdk/pull/28723 From lkorinth at openjdk.org Thu Jan 29 14:51:36 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 29 Jan 2026 14:51:36 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v8] In-Reply-To: <1yNQc7QkIDbQ7WvVCHICL4dDN036pPD373wE3H200R4=.43d38367-6988-4531-829f-349d206250f8@github.com> References: <1yNQc7QkIDbQ7WvVCHICL4dDN036pPD373wE3H200R4=.43d38367-6988-4531-829f-349d206250f8@github.com> Message-ID: On Wed, 28 Jan 2026 11:03:32 GMT, Stefan Johansson wrote: >> Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: >> >> - Revert "Stefan J 4" >> >> This reverts commit 203d11979524126add9ee5d04174bde07a5a3f5a. >> - Revert "remove commented out code" >> >> This reverts commit 9d9df671574be7a15a30ef0af452629330cb4fd1. >> - Merge branch 'master' into _8367993 >> - Merge branch '_master_jdk' into _8367993 >> - Merge branch '_8373253' into _8367993 >> - rename of method >> - Proposal by Stefan J >> - wip >> - Revert "8373253: Re-work InjectGCWorkerCreationFailure for future changes" >> >> This reverts commit d45ea8817ab2303b2decd8cbb2cd1bf5280aa181. >> - Revert "Fixup after comment from Ivan." >> >> This reverts commit 2aa8aa4b68027b62a8d4be1b86720fadfa48dda5. >> - ... and 11 more: https://git.openjdk.org/jdk/compare/90b54692...c5a7e2bb > > src/hotspot/share/gc/g1/g1YoungCollector.cpp line 1128: > >> 1126: >> 1127: void G1YoungCollector::collect() { >> 1128: _g1h->_cm->fully_initialize(); > > Why did you revert the call to this location? Instead of having it in G1CollectedHeap::do_collection_pause_at_safepoint()? I have now reapplied the patch. It seems we are all okay with the current position of `_g1h->_cm->fully_initialize();`, and that it can be moved after [JDK-8371720](https://bugs.openjdk.org/browse/JDK-8371720) has been fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2742035071 From qpzhang at openjdk.org Thu Jan 29 14:54:13 2026 From: qpzhang at openjdk.org (Patrick Zhang) Date: Thu, 29 Jan 2026 14:54:13 GMT Subject: RFR: 8365991: AArch64: Ignore BlockZeroingLowLimit when UseBlockZeroing is false [v10] In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 09:55:59 GMT, Andrew Haley wrote: >> Patrick Zhang has updated the pull request incrementally with one additional commit since the last revision: >> >> Renamed the vars to unroll_words >> >> Signed-off-by: Patrick Zhang > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 6264: > >> 6262: // There is no need to check UseBlockZeroing here because that is >> 6263: // delegated to the zero_blocks stub. The code here is inlined, so >> 6264: // it is important to keep it small. > > Suggestion: > > // The code here is inlined, so it is important to keep it small. > > I find this "There is no need..." comment more confusing than helpful. It is to warn others from having similar confusion or misunderstanding about why `BlockZeroingLowLimit` is checked is this `if-condition` without checking `UseBlockZeroing`. I think the comment is a necessary alarm. > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 6277: > >> 6275: #endif >> 6276: // Use 16 words (128 bytes) as the block size to unroll. >> 6277: const int unroll_words = 2 * MacroAssembler::zero_words_block_size; > > const int unroll_words = 2 * MacroAssembler::zero_words_block_size; > > > I do not believe this makes the code easier to understand. It's explicitly two DC ZVA blocks. Maybe `two_blocks` or somesuch would be clearer to the reader. > > The "replace literal constants with named constants" advice helps when the named constant is informative, which `unroll_words` is not. Sure, I will change it accordingly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26917#discussion_r2742006220 PR Review Comment: https://git.openjdk.org/jdk/pull/26917#discussion_r2742043269 From shade at openjdk.org Thu Jan 29 14:56:37 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 29 Jan 2026 14:56:37 GMT Subject: RFR: 8376472: Shenandoah: Assembler store barriers read destination memory despite the decorators In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 10:47:54 GMT, Aleksey Shipilev wrote: > The issue is really a correctness issue, and it readily manifests in Valhalla, which sometimes does the stores with `IS_DEST_UNINITIALIZED` set. Unfortunately, Shenandoah SATB barriers ignore this attribute, and attempt to read the memory at store address. At best it crashes the VM with the "oopness" asserts, at worst it feeds "garbage" pointers into SATB machinery, which then wrecks havoc on everything else. > > We need to make sure store barriers are consistently checking these attributes. Unfortunately, that would mean doing the changes in arch-specific assembler code. > > This PR makes sure the ShenandoahBarrierSetAssembler store barriers are roughly in the same shape, and that they consult `ShenandoahBarrierSet::need_*_barrier` to make the proper decisions whether to use SATB/card barriers. > > `hotspot_gc_shenandoah` is enough to sanity-check this patch, but I am also running `all` tests for extra safety. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` > - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah` > - [x] Linux x86_64 server fastdebug, `all` + `-XX:+UseShenandoahGC` > - [x] Linux AArch64 server fastdebug, `all` + `-XX:+UseShenandoahGC` > - [x] Linux {PPC64, RISC-V, S390X} server fastdebug, cross-compilation All right, thanks for testing! I am willing to integrate this soon, so I am looking for more formal Reviews at this point. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29444#issuecomment-3818202381 From stuefe at openjdk.org Thu Jan 29 14:57:04 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 29 Jan 2026 14:57:04 GMT Subject: RFR: 8373096: JFR: Path-to-gc-roots search should be non-recursive [v6] In-Reply-To: References: Message-ID: > This is a continuation - second attempt - of https://github.com/openjdk/jdk/pull/28659. > > ---- > > A customer reported a native stack overflow when producing a JFR recording with path-to-gc-roots=true. This happens regularly, see similar cases in JBS (e.g. https://bugs.openjdk.org/browse/JDK-8371630, https://bugs.openjdk.org/browse/JDK-8282427 etc). > > We limit the maximum graph search depth (DFSClosure::max_dfs_depth) to prevent stack overflows. That solution is brittle, however, since recursion depth is not a good proxy for thread stack usage: it depends on many factors, e.g., compiler inlining decisions and platform specifics. In this case, the VMThread's stack was too small. > > This patch rewrites the DFS heap tracer to be non-recursive. This is mostly textbook stuff, but the devil is in the details. Nevertheless, the algorithm should be a straightforward read. > > ### Memory usage of old vs new algorithm: > > The new algorithm uses, on average, a bit less memory than the old one. The old algorithm did cost ((avg stackframe size in bytes) * depth). As we have seen, e.g., in JDK-8371630, a depth of 3200 can max out ~1MB of stack space. > > The new algorithm costs ((avg number of outgoing refs per instanceKlass oop) * depth * 16. For a depth of 3200, we get typical probe stack sizes of 100KB..200KB. But we also cap probestack size, similar to how we cap the max. graph depth. > > In any case, these numbers are nothing to worry about. For a more in-depth explanation about memory cost, please see the comment in dfsClosure.cpp. > > ### Possible improvements/simplifications in the future: > > DFS works perfectly well alone now. It no longer depends on stack size, and its memory usage is typically smaller than BFS. IMHO, it would be perfectly fine to get rid of BFS and rely solely on the non-recursive DFS. The benefit would be a decrease in complexity and fewer tests to run and maintain. It should also be easy to convert into a parallelized version later. > > I kept the _max_dfs_depth_ parameter for now, but tbh it is no longer very useful. Before, it prevented stack overflows. Now, it is just an indirect way to limit probe stack size. But we also explicitly cap the probe stack size, so _max_dfs_depth_ is redundant. Removing it would require changing the statically allocated reference stack to be dynamically allocated, but that should not be difficult. > > ### Observable differences > > There is one observable side effect to the changed algorithm. The non-recursive algorithm processes oops a... Thomas Stuefe has updated the pull request incrementally with three additional commits since the last revision: - remove unnecessary copyright change - remove debug output - Erics test suggestions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29382/files - new: https://git.openjdk.org/jdk/pull/29382/files/ecc2bb74..957e001a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29382&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29382&range=04-05 Stats: 442 lines in 9 files changed: 195 ins; 245 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29382.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29382/head:pull/29382 PR: https://git.openjdk.org/jdk/pull/29382 From stuefe at openjdk.org Thu Jan 29 14:57:07 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 29 Jan 2026 14:57:07 GMT Subject: RFR: 8373096: JFR: Path-to-gc-roots search should be non-recursive [v5] In-Reply-To: References: Message-ID: <_13pfLfGnYCREnI81qi-sM3dyeaCVyy6KHJBRxTfrqE=.5a239109-0190-4cd3-abec-d9a13354eb16@github.com> On Thu, 29 Jan 2026 12:01:20 GMT, Thomas Stuefe wrote: >> This is a continuation - second attempt - of https://github.com/openjdk/jdk/pull/28659. >> >> ---- >> >> A customer reported a native stack overflow when producing a JFR recording with path-to-gc-roots=true. This happens regularly, see similar cases in JBS (e.g. https://bugs.openjdk.org/browse/JDK-8371630, https://bugs.openjdk.org/browse/JDK-8282427 etc). >> >> We limit the maximum graph search depth (DFSClosure::max_dfs_depth) to prevent stack overflows. That solution is brittle, however, since recursion depth is not a good proxy for thread stack usage: it depends on many factors, e.g., compiler inlining decisions and platform specifics. In this case, the VMThread's stack was too small. >> >> This patch rewrites the DFS heap tracer to be non-recursive. This is mostly textbook stuff, but the devil is in the details. Nevertheless, the algorithm should be a straightforward read. >> >> ### Memory usage of old vs new algorithm: >> >> The new algorithm uses, on average, a bit less memory than the old one. The old algorithm did cost ((avg stackframe size in bytes) * depth). As we have seen, e.g., in JDK-8371630, a depth of 3200 can max out ~1MB of stack space. >> >> The new algorithm costs ((avg number of outgoing refs per instanceKlass oop) * depth * 16. For a depth of 3200, we get typical probe stack sizes of 100KB..200KB. But we also cap probestack size, similar to how we cap the max. graph depth. >> >> In any case, these numbers are nothing to worry about. For a more in-depth explanation about memory cost, please see the comment in dfsClosure.cpp. >> >> ### Possible improvements/simplifications in the future: >> >> DFS works perfectly well alone now. It no longer depends on stack size, and its memory usage is typically smaller than BFS. IMHO, it would be perfectly fine to get rid of BFS and rely solely on the non-recursive DFS. The benefit would be a decrease in complexity and fewer tests to run and maintain. It should also be easy to convert into a parallelized version later. >> >> I kept the _max_dfs_depth_ parameter for now, but tbh it is no longer very useful. Before, it prevented stack overflows. Now, it is just an indirect way to limit probe stack size. But we also explicitly cap the probe stack size, so _max_dfs_depth_ is redundant. Removing it would require changing the statically allocated reference stack to be dynamically allocated, but that should not be difficult. >> >> ### Observable differences >> >> There is one observable side effect to the changed a... > > Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: > > - remove unnecessary diff > - copyrights @egahlin yes, that is nicer and simpler. I adapted your approach. Not sure if this helps, but back in December, when I rewrote this, I drew up a quick visio to help with reviews. I'll attach the pdf. [JFR-leakprofiler-DFS.pdf](https://github.com/user-attachments/files/24940854/JFR-leakprofiler-DFS.pdf) ------------- PR Comment: https://git.openjdk.org/jdk/pull/29382#issuecomment-3818189519 From qpzhang at openjdk.org Thu Jan 29 15:27:15 2026 From: qpzhang at openjdk.org (Patrick Zhang) Date: Thu, 29 Jan 2026 15:27:15 GMT Subject: RFR: 8365991: AArch64: Ignore BlockZeroingLowLimit when UseBlockZeroing is false [v11] In-Reply-To: References: Message-ID: > Issue: > In AArch64 port, `UseBlockZeroing` is by default set to true and `BlockZeroingLowLimit` is initialized to 256. If `DC ZVA` is supported, `BlockZeroingLowLimit` is later updated to `4 * VM_Version::zva_length()`. When `UseBlockZeroing` is set to false, all related conditional checks should ignore `BlockZeroingLowLimit`. However, the function `MacroAssembler::zero_words(Register base, uint64_t cnt)` still evaluates the lower limit and bases its code generation logic on it, which seems to be an incomplete conditional check. > > This PR: > 1. Reset `BlockZeroingLowLimit` to `4 * VM_Version::zva_length()` or 256 with a warning message if it was manually configured from the default while `UseBlockZeroing` is disabled. > 2. Added necessary comments in `MacroAssembler::zero_words(Register base, uint64_t cnt)` and `MacroAssembler::zero_words(Register ptr, Register cnt)` to explain why we do not check `UseBlockZeroing` in the outer part of these functions. Instead, the decision is delegated to the stub function `zero_blocks`, which encapsulates the DC ZVA instructions and serves as the inner implementation of `zero_words`. This approach helps better control the increase in code cache size during array or object instance initialization. > 3. Added more testing sizes to `test/micro/org/openjdk/bench/vm/gc/RawAllocationRate.java` to better cover scenarios involving smaller arrays and objects.. > > Tests: > 1. Performance tests on the bundled JMH `vm.compiler.ClearMemory`, and `vm.gc.RawAllocationRate` (including `arrayTest` and `instanceTest`) showed no obvious regression. Negative tests with `jdk/bin/java -jar images/test/micro/benchmarks.jar RawAllocationRate.arrayTest_C1 -bm thrpt -gc false -wi 0 -w 30 -i 1 -r 30 -t 1 -f 1 -tu s -jvmArgs "-XX:-UseBlockZeroing -XX:BlockZeroingLowLimit=8" -p size=32` demonstrated good wall times on `zero_words_reg_imm` calls, as expected. > 2. Jtreg ter1 test on Ampere Altra, AmpereOne, Graviton2 and 3, tier2 on Altra. No new issues found. Passed tests of GHA Sanity Checks. Patrick Zhang has updated the pull request incrementally with one additional commit since the last revision: Rename unroll_words to two_blocks Signed-off-by: Patrick Zhang ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26917/files - new: https://git.openjdk.org/jdk/pull/26917/files/5401fdf5..5535721e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26917&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26917&range=09-10 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/26917.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26917/head:pull/26917 PR: https://git.openjdk.org/jdk/pull/26917 From lmesnik at openjdk.org Thu Jan 29 15:39:48 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 29 Jan 2026 15:39:48 GMT Subject: RFR: 8373367: interp-only mechanism fails to work for carrier threads in a corner case [v2] In-Reply-To: References: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com> Message-ID: On Thu, 29 Jan 2026 09:23:41 GMT, Serguei Spitsyn wrote: >> The `interp-only` mechanism is based on the `JavaThread` objects. Carrier and virtual threads can temporary share the same `JavaThread`. The `java_thread->jvmti_thread_state()` is re-linked to a virtual thread at `mount` and to the carrier thread at `unmount`. The `JvmtiThreadState` has a back link to the `JavaThread` which is also set for virtual thread at a `mount` and carrier thread at an `unmount`. Just one of these two links at the same time is set to the `JavaThread`, the other one has to be set to `nullptr`. The `interp-only` mechanism needs this invariant. >> However, there is a corner case when this invariant is broken. It happens when the `JvmtiThreadState` for carrier thread has just been created. In such case, the link to `JavaThread` is always `non-nullptr` even though a virtual thread is currently mounted on a carrier thread. This simple update fixes the issue in the `JvmtiThreadState` ctor. >> >> Testing: >> - TBD: Mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: some tweaks for carrier thread JvmtiThreadState initialization Thanks for updating. Fix looks good. ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29436#pullrequestreview-3723483018 From sspitsyn at openjdk.org Thu Jan 29 15:55:19 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 29 Jan 2026 15:55:19 GMT Subject: RFR: 8373367: interp-only mechanism fails to work for carrier threads in a corner case [v2] In-Reply-To: References: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com> Message-ID: On Thu, 29 Jan 2026 09:23:41 GMT, Serguei Spitsyn wrote: >> The `interp-only` mechanism is based on the `JavaThread` objects. Carrier and virtual threads can temporary share the same `JavaThread`. The `java_thread->jvmti_thread_state()` is re-linked to a virtual thread at `mount` and to the carrier thread at `unmount`. The `JvmtiThreadState` has a back link to the `JavaThread` which is also set for virtual thread at a `mount` and carrier thread at an `unmount`. Just one of these two links at the same time is set to the `JavaThread`, the other one has to be set to `nullptr`. The `interp-only` mechanism needs this invariant. >> However, there is a corner case when this invariant is broken. It happens when the `JvmtiThreadState` for carrier thread has just been created. In such case, the link to `JavaThread` is always `non-nullptr` even though a virtual thread is currently mounted on a carrier thread. This simple update fixes the issue in the `JvmtiThreadState` ctor. >> >> Testing: >> - TBD: Mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: some tweaks for carrier thread JvmtiThreadState initialization Thank you for review, Leonid! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29436#issuecomment-3818555405 From duke at openjdk.org Thu Jan 29 17:50:50 2026 From: duke at openjdk.org (Robert Toyonaga) Date: Thu, 29 Jan 2026 17:50:50 GMT Subject: RFR: 8353564: Fail fatally if os::release_memory or os::uncommit_memory fails [v6] In-Reply-To: References: Message-ID: > This PR is a follow up to JDK-8341491. See original discussion: https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700 > > This PR makes `os::release_memory`, `os::uncommit_memory`, `os::release_memory_special`, and `os::unmap_memory` fail fatally if they encounter an error. These methods require obtaining the NMT lock. Fatally failing in these places would potentially allow for the tightening of NMT virtual memory locking scopes (future work, if this PR is accepted). Already in most cases, the callers fail fatally or assert(false) when these os:: methods fail. Another reason to fatally fail is that if the OS memory operation fails, it can be difficult to know for sure what state the OS left the memory in and recover. > > `release_memory`/`uncommit_memory`/`release_memory_special`/`unmap_memory` can fail due to ? Bad arguments, or ? The OS encountered an issue out of control of the JVM. > > ? > If there is a JVM bug, it's probably reasonable to fatally fail here. Or the caller could be intentionally passing arguments that may or may not be valid. I don't think there is any code like that currently, and this is probably a bad pattern to be following anyway. > > ? > In platform dependent code: > With regard to mmap/munmap, the only errors that aren't due to bad arguments are ENOMEM and ones related to file descriptors (which are not applicable to uncommit or release). > On Windows, VirtualFree only fails due to bad arguments. > On AIX, shmdt and disclaim64 only fail due to bad arguments. msync could spontaneously fail with EIO: "An I/O error occurred while reading from or writing to the file system." > On BSD, it seems like mprotect and madvise fail only due to bad arguments or invalid privileges. > > In the [original discussion](https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700), the main question was whether ENOMEM upon os::uncommit_memory was recoverable. This may be possible if we uncommit the middle of a region - splitting it in two. This could exceed the limit of the number of mappings resulting in ENOMEM. > > If none of the scenarios in ? are recoverable, then perhaps fatally failing is OK. > > Testing: > - Tier 1. > - Manual testing to make sure we fatally fail and the correct messages are printed. Robert Toyonaga has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - refactor to simplify windows tests - Merge branch 'master' into JDK-8353564 - Don't pass false, rely on default argument. Punctuation. Whitespace. - make remove_stack_guard_pages return void - remove whitespace. Add extra message fro linux ENOMEM on uncommit - make memory functions void and remove error strings - fail fatally if OS memory ops fail ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29240/files - new: https://git.openjdk.org/jdk/pull/29240/files/e41a9734..d3408097 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29240&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29240&range=04-05 Stats: 52430 lines in 1157 files changed: 27518 ins; 10494 del; 14418 mod Patch: https://git.openjdk.org/jdk/pull/29240.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29240/head:pull/29240 PR: https://git.openjdk.org/jdk/pull/29240 From duke at openjdk.org Thu Jan 29 17:50:51 2026 From: duke at openjdk.org (Robert Toyonaga) Date: Thu, 29 Jan 2026 17:50:51 GMT Subject: RFR: 8353564: Fail fatally if os::release_memory or os::uncommit_memory fails [v5] In-Reply-To: References: Message-ID: <55K7ZSNoiZPN_XKf7T2gQiyUu09dRY-2WW6bD1gs85Q=.f2ca3b3b-9f98-4afd-841f-30d009f8736c@github.com> On Wed, 28 Jan 2026 21:24:33 GMT, Robert Toyonaga wrote: >> This PR is a follow up to JDK-8341491. See original discussion: https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700 >> >> This PR makes `os::release_memory`, `os::uncommit_memory`, `os::release_memory_special`, and `os::unmap_memory` fail fatally if they encounter an error. These methods require obtaining the NMT lock. Fatally failing in these places would potentially allow for the tightening of NMT virtual memory locking scopes (future work, if this PR is accepted). Already in most cases, the callers fail fatally or assert(false) when these os:: methods fail. Another reason to fatally fail is that if the OS memory operation fails, it can be difficult to know for sure what state the OS left the memory in and recover. >> >> `release_memory`/`uncommit_memory`/`release_memory_special`/`unmap_memory` can fail due to ? Bad arguments, or ? The OS encountered an issue out of control of the JVM. >> >> ? >> If there is a JVM bug, it's probably reasonable to fatally fail here. Or the caller could be intentionally passing arguments that may or may not be valid. I don't think there is any code like that currently, and this is probably a bad pattern to be following anyway. >> >> ? >> In platform dependent code: >> With regard to mmap/munmap, the only errors that aren't due to bad arguments are ENOMEM and ones related to file descriptors (which are not applicable to uncommit or release). >> On Windows, VirtualFree only fails due to bad arguments. >> On AIX, shmdt and disclaim64 only fail due to bad arguments. msync could spontaneously fail with EIO: "An I/O error occurred while reading from or writing to the file system." >> On BSD, it seems like mprotect and madvise fail only due to bad arguments or invalid privileges. >> >> In the [original discussion](https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700), the main question was whether ENOMEM upon os::uncommit_memory was recoverable. This may be possible if we uncommit the middle of a region - splitting it in two. This could exceed the limit of the number of mappings resulting in ENOMEM. >> >> If none of the scenarios in ? are recoverable, then perhaps fatally failing is OK. >> >> Testing: >> - Tier 1. >> - Manual testing to make sure we fatally fail and the correct messages are printed. > > Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision: > > Don't pass false, rely on default argument. Punctuation. Whitespace. Thank you for the review Thomas! >The patch uncovers a hidden error in ZGC tests. It uses os::uncommit_memory without checking the return type (ZForwardingTest::TearDown). It probably never worked before; now we assert. I actually like the new behavior better. Releasing not-matching memory ranges is dangerous (NMT would catch that too, though). > >I think what happens here is that the underlying memory we operate on was reserved (in ZVirtualMemoryReserver -> ZVirtualMemoryReserverSmallPages::reserve -> ZMapper::reserve) via VirtualAlloc2, and that for whatever reason os::uncommit does not work here. Maybe the range does not match ? Or we need to call a different API. Yes, the problem was that the ZGC API reserves using `VirtualAlloc2` placeholders and then `os::commit_memory` was called on the same region - which uses `VirtualAlloc` and doesn't support placeholders. The commit fails, so later the `os::uncommit_memory` fails too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29240#issuecomment-3819250968 From duke at openjdk.org Thu Jan 29 17:50:54 2026 From: duke at openjdk.org (Robert Toyonaga) Date: Thu, 29 Jan 2026 17:50:54 GMT Subject: RFR: 8353564: Fail fatally if os::release_memory or os::uncommit_memory fails [v5] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 07:56:06 GMT, Thomas Stuefe wrote: >> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Don't pass false, rely on default argument. Punctuation. Whitespace. > > test/hotspot/gtest/runtime/test_os.cpp line 667: > >> 665: char* p = setup_release_test_memory(); >> 666: os::release_memory(p, M); // Release part of the range >> 667: } > > This is a good rewrite of the tests. I did not even think of this. > > Proposal: do this: > > > #ifdef ASSERT > #define TEST_RELEASE_RANGE_ERROR(name) TEST_VM_ASSERT_MSG(os, name, ".*bad release") > #else > #define TEST_RELEASE_RANGE_ERROR(name) TEST_VM_FATAL_ERROR_MSG(os, name, ".*Failed to release.*") > #endif > > > and use TEST_RELEASE_RANGE_ERROR as header, saves duplicating these lines five times. That's a good idea! I've adopted it and pushed a new commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29240#discussion_r2742806170 From pchilanomate at openjdk.org Thu Jan 29 17:55:57 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 29 Jan 2026 17:55:57 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases [v2] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 04:21:18 GMT, David Holmes wrote: >> src/hotspot/share/classfile/javaClasses.cpp line 1944: >> >>> 1942: >>> 1943: bool is_virtual = java_lang_VirtualThread::is_instance(_thread_h()); >>> 1944: bool vthread_carrier = !is_virtual && (java_thread != nullptr) && (java_thread->vthread_continuation() != nullptr); >> >> The extra `java_thread != nullptr` should not be necessary. > > What would force it to be non-null? (Related: under what conditions will `th` be null and what does that imply about the value of `_thread_h()`?) A null `java_thread` is only possible for the unmounted vthread case. The oop should always be a valid `java.lang.Thread` though. Maybe `thread_oop` should be initialized to `nullptr` and the assert at line 1914 be just `assert(thread_oop != nullptr, "Missing Thread oop");`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2742835509 From shade at openjdk.org Thu Jan 29 18:05:29 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 29 Jan 2026 18:05:29 GMT Subject: RFR: 8360557: CTW: Inline cold methods to reach more code [v13] In-Reply-To: References: Message-ID: <6IVTRd5ca8lQpk1YmC2PUEdbmSR-KnFmz-XLkF5dtNY=.89f819fb-e93e-4860-af32-8e5e4cec988a@github.com> > We use CTW testing for making sure compilers behave well. But we compile the code that is not executed at all, and since our inlining heuristics often looks back at profiles, we end up not actually inlining all too much! This means CTW testing likely misses lots of bugs that normal code is exposed to, especially e.g. in loop optimizations. > > There is an intrinsic tradeoff with accepting more inilned methods in CTW: the compilation time gets significantly worse. With just accepting the cold methods we have reasonable CTW times, eating the improvements we have committed in mainline recently. And it still finds bugs. See the RFE for sample data. > > After this lands and CTW starts to compile cold methods, one can greatly expand the scope of the CTW testing by overriding the static inlining limits. Doing e.g. `TEST_VM_OPTS="-XX:MaxInlineSize=70 -XX:C1MaxInlineSize=70"` finds even more bugs. Unfortunately, the compilation times suffer so much, they are impractical to run in standard configurations, see data in RFE. We will enable some of that testing in special testing pipelines. > > Pre-empting the question: "Well, why not use -Xcomp then, and make sure it inlines well?" The answer is in RFE as well: Xcomp causes _a lot_ of stray compilations for JDK and CTW infra itself. For small JARs in large corpus this eats precious testing time that we would instead like to spend on deeper inlining in the actual JAR code. This also does not force us to look into how CTW works in Xcomp at all; I expect some surprises there. Feather-touching the inlining heuristic paths to just accept methods without looking at profiles looks better. > > Tobias had an idea to implement the stress randomized inlining that would expand the scope of inlining. This improvement stacks well with it. This improvement provides the base case of inlining most reasonable methods, and then allow stress infra to inline some more on top of that. > > Additional testing: > - [x] GHA > - [x] Linux x86_64 server fastdebug, `applications/ctw/modules` > - [x] Linux x86_64 server fastdebug, large CTW corpus (now failing in interesting ways) Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: - Potential fix for dead loop - Roll back some dead weight ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26068/files - new: https://git.openjdk.org/jdk/pull/26068/files/f1a06e35..2ded3cee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26068&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26068&range=11-12 Stats: 16 lines in 4 files changed: 11 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26068.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26068/head:pull/26068 PR: https://git.openjdk.org/jdk/pull/26068 From psandoz at openjdk.org Thu Jan 29 18:15:43 2026 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 29 Jan 2026 18:15:43 GMT Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass them to intrinsic entries [v3] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 12:58:57 GMT, Jatin Bhateja wrote: >> As per [discussions ](https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594) on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch in preparation of Float16 vector API support. >> >> Patch add new lane type constants and pass them to vector intrinsic entry points. >> >> All existing Vector API jtreg test are passing with the patch. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Review comments resolutions src/hotspot/share/prims/vectorSupport.hpp line 146: > 144: LT_SHORT = 9, > 145: LT_INT = 10, > 146: LT_LONG = 11 Are the values designed to be in sync with the `BasicType` values where the lane type and the basic type are the same? If so we should call this out via explicit assignment. Otherwise, i think we should adjust the values (which may require some adjustment elsewhere e.g., VectorOperators.java). src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java line 152: > 150: public static final int MODE_BITS_COERCED_LONG_TO_MASK = 1; > 151: > 152: // BasicType codes, for primitives only: This comment needs to be updated. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java line 544: > 542: public byte laneHelper(int i) { > 543: return (byte) VectorSupport.extract( > 544: VCLASS, LT_BYTE, VLENGTH, Can we declare a static final field `LANE_TYPE_ORDINAL` (or `LANE_TYPE_ID`, see comment on `LaneType` as the naming is important) and use that consistently like we already do for `ETYPE`? src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LaneType.java line 88: > 86: final String printName; > 87: final char typeChar; // one of "BSILFD" > 88: final int laneType; // lg(size/8) | (kind=='F'?4:kind=='I'?8) We need to change the name of this field to more clearly distinguish between it and the class name. If we can change the values of `LT_*` and align them with the enum ordinal values then we can call it `laneTypeOrdinal` and consistently use that, then we don't likely need the `LT_*` constants. If the values need to align with `BasicType` values then it might be better called `laneTypeIdentifier` or `laneTypeId`. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LaneType.java line 197: > 195: /*package-private*/ > 196: @ForceInline > 197: static LaneType ofBasicType(int bt) { The method name and argument need updating. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2742857369 PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2742850134 PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2742840498 PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2742894994 PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2742873650 From kvn at openjdk.org Thu Jan 29 18:26:00 2026 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 29 Jan 2026 18:26:00 GMT Subject: RFR: 8372617: Save and restore stubgen stubs when using an AOT code cache [v4] In-Reply-To: <2u7_uahnB2vGhVMPpgmmZtCtGLECRW2lNjWiJle9w4U=.3574cd76-e68e-46c2-a40d-f5a786e6d525@github.com> References: <2u7_uahnB2vGhVMPpgmmZtCtGLECRW2lNjWiJle9w4U=.3574cd76-e68e-46c2-a40d-f5a786e6d525@github.com> Message-ID: <-PYZHNWhUkw8mGGWWarPsMiMM6pfwkMmlbH7ueJabWg=.51f78e41-b7b3-4d5e-9999-3db49f1537ac@github.com> On Thu, 29 Jan 2026 10:54:09 GMT, Andrew Dinn wrote: > Should I make the delegation changes now? Do it in separate changes. Could be followup of this REF when you have time. I will submit new testing with latest changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28433#issuecomment-3819426025 From krk at openjdk.org Thu Jan 29 18:30:39 2026 From: krk at openjdk.org (Kerem Kat) Date: Thu, 29 Jan 2026 18:30:39 GMT Subject: RFR: 8366117: Shenandoah: Notify barrier nodes when transitive inputs change during IGVN Message-ID: `ShenandoahLoadReferenceBarrierNode::Identity()` determines if a barrier can be eliminated by traversing through intermediate nodes (`Phi`, `DecodeN`, `CastPP`, etc.) via `needs_barrier_impl()`. When these intermediate nodes change during IGVN, the barrier is not re-evaluated because IGVN only notifies direct users. This causes `TestVerifyIterativeGVN` to fail with Shenandoah, reporting missed optimization opportunities. This fix adds a `BarrierSetC2::enqueue_dependent_gc_barriers()` virtual method that Shenandoah overrides to traverse outputs through the same node types and enqueue dependent barriers for re-evaluation. There are more barrier eliminations enabled with this, e.g. in the arbitrarily chosen scrabble of renaissance benchmarks: java -XX:+UseShenandoahGC -Xbatch -Xcomp -XX:-TieredCompilation -jar ~/.cache/stress/renaissance-gpl-0.16.1.jar scrabble -r 1 |& tee /dev/stderr | grep "optimize barrier" | sort | uniq -c | sort -rn # with fix 236 optimize barrier on call 75 optimize barrier on alloc 35 optimize barrier on barrier 23 optimize barrier on parm 15 optimize barrier on const 1 optimize barrier on barrier 1 optimize barrier on null TOTAL = 386 # without fix 193 optimize barrier on call 72 optimize barrier on alloc 32 optimize barrier on barrier 23 optimize barrier on parm 1 optimize barrier on barrier 1 optimize barrier on null 1 optimize barrier on const TOTAL = 323 This requires uncommenting prints with `optimize barrier` in `c2/shenandoahSupport.cpp`. Also tested with `make test CONF=linux-x86_64-server-fastdebug TEST=compiler/c2/TestVerifyIterativeGVN.java JTREG="VM_OPTIONS=-XX:+UseShenandoahGC -Xcomp -Xbatch -XX:-TieredCompilation"` which passes with the fix and fails without. ------------- Commit messages: - 8366117: Shenandoah: Notify barrier nodes when transitive inputs change during IGVN Changes: https://git.openjdk.org/jdk/pull/29491/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29491&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366117 Stats: 37 lines in 4 files changed: 37 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29491.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29491/head:pull/29491 PR: https://git.openjdk.org/jdk/pull/29491 From duke at openjdk.org Thu Jan 29 18:45:05 2026 From: duke at openjdk.org (Robert Toyonaga) Date: Thu, 29 Jan 2026 18:45:05 GMT Subject: RFR: 8353564: Fail fatally if os::release_memory or os::uncommit_memory fails [v7] In-Reply-To: References: Message-ID: > This PR is a follow up to JDK-8341491. See original discussion: https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700 > > This PR makes `os::release_memory`, `os::uncommit_memory`, `os::release_memory_special`, and `os::unmap_memory` fail fatally if they encounter an error. These methods require obtaining the NMT lock. Fatally failing in these places would potentially allow for the tightening of NMT virtual memory locking scopes (future work, if this PR is accepted). Already in most cases, the callers fail fatally or assert(false) when these os:: methods fail. Another reason to fatally fail is that if the OS memory operation fails, it can be difficult to know for sure what state the OS left the memory in and recover. > > `release_memory`/`uncommit_memory`/`release_memory_special`/`unmap_memory` can fail due to ? Bad arguments, or ? The OS encountered an issue out of control of the JVM. > > ? > If there is a JVM bug, it's probably reasonable to fatally fail here. Or the caller could be intentionally passing arguments that may or may not be valid. I don't think there is any code like that currently, and this is probably a bad pattern to be following anyway. > > ? > In platform dependent code: > With regard to mmap/munmap, the only errors that aren't due to bad arguments are ENOMEM and ones related to file descriptors (which are not applicable to uncommit or release). > On Windows, VirtualFree only fails due to bad arguments. > On AIX, shmdt and disclaim64 only fail due to bad arguments. msync could spontaneously fail with EIO: "An I/O error occurred while reading from or writing to the file system." > On BSD, it seems like mprotect and madvise fail only due to bad arguments or invalid privileges. > > In the [original discussion](https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700), the main question was whether ENOMEM upon os::uncommit_memory was recoverable. This may be possible if we uncommit the middle of a region - splitting it in two. This could exceed the limit of the number of mappings resulting in ENOMEM. > > If none of the scenarios in ? are recoverable, then perhaps fatally failing is OK. > > Testing: > - Tier 1. > - Manual testing to make sure we fatally fail and the correct messages are printed. Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision: stray whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29240/files - new: https://git.openjdk.org/jdk/pull/29240/files/d3408097..66e5b065 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29240&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29240&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29240.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29240/head:pull/29240 PR: https://git.openjdk.org/jdk/pull/29240 From sviswanathan at openjdk.org Thu Jan 29 19:46:40 2026 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Thu, 29 Jan 2026 19:46:40 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v13] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 20:30:26 GMT, Srinivas Vamsi Parasa wrote: >> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: >> >> Update ALL of ArraysFill JMH micro > > ### Int VectorBulkOperationsArray Fill > > Benchmark (ns/op) | Size | -OptimizeFill (JITed code) | +OptimizeFill (Masked store) | +OptimizeFill (Unmasked store - This PR) | Delta (masked vs. unmasked) > -- | -- | -- | -- | -- | -- > VectorBulkOperationsArray.fill_var_int_arrays_fill | 0 | 0.649 | 0.651 | 0.655 | 1% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 1 | 2.371 | 2.801 | 2.827 | 1% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 2 | 2.374 | 2.585 | 2.942 | 12% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 3 | 2.809 | 2.589 | 3.094 | 16% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 4 | 3.356 | 2.587 | 2.852 | 9% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 5 | 3.531 | 2.588 | 3.158 | 18% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 6 | 3.747 | 2.589 | 3.118 | 17% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 7 | 3.989 | 2.589 | 3.332 | 22% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 8 | 5.047 | 2.588 | 2.832 | 9% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 9 | 4.79 | 2.845 | 3.056 | 7% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 10 | 4.982 | 2.85 | 3.274 | 13% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 11 | 4.551 | 2.852 | 3.521 | 19% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 12 | 4.281 | 2.853 | 3.12 | 9% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 13 | 4.391 | 2.894 | 3.499 | 17% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 14 | 4.909 | 2.848 | 3.339 | 15% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 15 | 5.269 | 2.853 | 3.524 | 19% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 16 | 5.663 | 2.836 | 3.101 | 9% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 17 | 5.553 | 2.924 | 3.111 | 6% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 18 | 5.105 | 2.933 | 3.358 | 13% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 19 | 5.09 | 2.942 | 3.583 | 18% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 20 | 4.457 | 2.927 | 3.272 | 11% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 21 | 4.745 | 3.104 | 3.598 | 14% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 22 | 4.949 | 2.932 | 3.481 | 16% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 23 | 4.992 | 2.939 | 3.761 | 22% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 24 | 5.198 | 2.92 | 3.205 | 9% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 25 | 5.097 | 3.116 | 3.387 | 8% > VectorBulkOperationsArray.fill_var_... > > > @vamsi-parasa Ok, so now we have one benchmark that shows a speedup and one that shows a regression. How are we to proceed? > > > It seems that without loads [#28442 (comment)](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761659799), this patch leads to a regression. > > > Only if there is a load from one of the last elements that the `Arrays.fill` stored to with a masked operation do we get a slowdown. Because of missing load-to-store forwarding. If we instead started loading from the first elements, those would probably already be in cache, and we would not have any latency issues, right? > > > But is it not rather an edge-case that we load from the last elements immediately after the `Arrays.fill`? At least for longer arrays, it seems an edge case. For short arrays it is probably more likely that we access the last element soon after the fill. > > > It does not seem like a trivial decision to me if this patch is an improvement or not. What do you think @vamsi-parasa ? > > > @sviswa7 @dwhite-intel You already approved this PR. What are your thoughts here? > > > > > > @eme64 My thoughts are to go ahead with this PR replacing masked stores with scalar tail processing. As we have seen from https://bugs.openjdk.org/browse/JDK-8349452 masked stores can cause big regression in certain scenarios: accessing elements just written or any other adjacent data that happens to fall in the masked store range. > > @sviswa7 But once this PR is integrated, I could file a performance regression with the benchmarks from [up here](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761659799). So what's the argument which choice is better, since we have a mix of speedups/regression going either way, and both are probably in the 10-20% range? @eme64 You have a point there, but if you see the performance numbers for ByteMatrix.java (from JDK-8349452) in the PR description above we are talking about a recovery of 3x or so. The ByteMatrix.java is doing only Arrays.fill() on individual arrays of a 2D array. The individual arrays happened to be allocated alongside each other by the JVM and the next store sees stalls due to the masked store of previous array initialization. That was the reason to look for a solution without masked stores. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3819899021 From sparasa at openjdk.org Thu Jan 29 21:48:13 2026 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Thu, 29 Jan 2026 21:48:13 GMT Subject: RFR: 8374744: Enable dumping of APX EGPRs =?UTF-8?B?KFIxNuKAk1IzMSk=?= in JVM fatal error logs [v2] In-Reply-To: References: Message-ID: > 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. Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: undo verbose code to print registers; repalce it with for loop ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29098/files - new: https://git.openjdk.org/jdk/pull/29098/files/a052e848..40ffe2d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29098&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29098&range=00-01 Stats: 42 lines in 1 file changed: 0 ins; 34 del; 8 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 sparasa at openjdk.org Thu Jan 29 21:48:18 2026 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Thu, 29 Jan 2026 21:48:18 GMT Subject: RFR: 8374744: Enable dumping of APX EGPRs =?UTF-8?B?KFIxNuKAk1IzMSk=?= in JVM fatal error logs [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 22:25:30 GMT, Sandhya Viswanathan wrote: >> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: >> >> undo verbose code to print registers; repalce it with for loop > > src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp line 449: > >> 447: // Dump APX EGPRs (R16-R31) >> 448: apx_state* apx = get_apx_state(uc); >> 449: if (UseAPX && apx != nullptr) { > > This could be done as: > apx_state* apx = UseAPX ? get_apx_state(uc) : nullptr; > if (apx != nullptr) { Please see the updated code with the suggested change. > src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp line 469: > >> 467: st->print(", R30=" INTPTR_FORMAT, (intptr_t)apx->regs[14]); >> 468: st->print(", R31=" INTPTR_FORMAT, (intptr_t)apx->regs[15]); >> 469: st->cr(); > > This could be done with a for loop. Please see the new code with the for loop. > src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp line 556: > >> 554: CASE_PRINT_REG_APX(30, "R30=", 14); break; >> 555: CASE_PRINT_REG_APX(31, "R31=", 15); break; >> 556: } > > Don't need a switch case here. Could be achieved with something like below: > > st->print("R%d=", n); > print_location(st, apx->regs[n]); Please see the new code without the switch statement. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29098#discussion_r2743684120 PR Review Comment: https://git.openjdk.org/jdk/pull/29098#discussion_r2743684769 PR Review Comment: https://git.openjdk.org/jdk/pull/29098#discussion_r2743685853 From sparasa at openjdk.org Thu Jan 29 21:50:23 2026 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Thu, 29 Jan 2026 21:50:23 GMT Subject: RFR: 8374744: Enable dumping of APX EGPRs =?UTF-8?B?KFIxNuKAk1IzMSk=?= in JVM fatal error logs In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 02:17:38 GMT, David Holmes wrote: > Why is this only implemented for Linux? Hello David (@dholmes-ora), this change is only implemented for Linux as APX support is available from kernel >= 6.16. For Windows, the status of APX support is not known. Thanks, Vamsi ------------- PR Comment: https://git.openjdk.org/jdk/pull/29098#issuecomment-3820580878 From sviswanathan at openjdk.org Thu Jan 29 22:07:03 2026 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Thu, 29 Jan 2026 22:07:03 GMT Subject: RFR: 8374744: Enable dumping of APX EGPRs =?UTF-8?B?KFIxNuKAk1IzMSk=?= in JVM fatal error logs [v2] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 21:48:13 GMT, Srinivas Vamsi Parasa wrote: >> 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. > > Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: > > undo verbose code to print registers; repalce it with for loop Looks good to me. ------------- Marked as reviewed by sviswanathan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29098#pullrequestreview-3725285147 From kvn at openjdk.org Thu Jan 29 22:44:14 2026 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 29 Jan 2026 22:44:14 GMT Subject: RFR: 8372617: Save and restore stubgen stubs when using an AOT code cache [v8] In-Reply-To: <4GvCD6GmYPb9SNGB9spUf7JnhXKRMXsZ14yEGTKnIjI=.8dffb830-af67-4bcc-9553-6ef76226a2a8@github.com> References: <4GvCD6GmYPb9SNGB9spUf7JnhXKRMXsZ14yEGTKnIjI=.8dffb830-af67-4bcc-9553-6ef76226a2a8@github.com> Message-ID: <3Sv0LoJ28ZG0KUVQre1Ajq89vByPYPtIA-OMQKtYSCY=.4e9a28e2-5640-4f71-bc64-44d678117dcb@github.com> On Thu, 29 Jan 2026 10:48:32 GMT, Andrew Dinn wrote: >> This PR adds save and restore of all generated stubs to the AOT code cache on x86 and aarch64. Other arches are modified to deal with the related generic PAI changes. >> >> Small changes were required to the aarch64 and x86_64 generator code in order to meet two key constraints: >> 1. the first declared entry of every stub starts at the first instruction in the stub code range >> 2. all data/code cross-references from one stub to another target a declared stub entry > > Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: > > Run AOTCodeFlags test with multiple GCs I still see a lot of failures running with not G1 GCs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28433#issuecomment-3820794568 From kvn at openjdk.org Thu Jan 29 22:48:07 2026 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 29 Jan 2026 22:48:07 GMT Subject: RFR: 8372617: Save and restore stubgen stubs when using an AOT code cache [v8] In-Reply-To: <4GvCD6GmYPb9SNGB9spUf7JnhXKRMXsZ14yEGTKnIjI=.8dffb830-af67-4bcc-9553-6ef76226a2a8@github.com> References: <4GvCD6GmYPb9SNGB9spUf7JnhXKRMXsZ14yEGTKnIjI=.8dffb830-af67-4bcc-9553-6ef76226a2a8@github.com> Message-ID: <9Sfxm6Nvi_-o23D3jam7r6T8USUslqnVwmvwkhiQlFo=.23f7fc3e-f484-4d21-85e0-164c4440b7b1@github.com> On Thu, 29 Jan 2026 10:48:32 GMT, Andrew Dinn wrote: >> This PR adds save and restore of all generated stubs to the AOT code cache on x86 and aarch64. Other arches are modified to deal with the related generic PAI changes. >> >> Small changes were required to the aarch64 and x86_64 generator code in order to meet two key constraints: >> 1. the first declared entry of every stub starts at the first instruction in the stub code range >> 2. all data/code cross-references from one stub to another target a declared stub entry > > Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: > > Run AOTCodeFlags test with multiple GCs You also need to add CPU features check to aotCodeCache from `premain` Some tests asserted because they use `UseSSE` flag to low features: `compiler/arguments/TestUseSSE42IntrinsicsWithLowLevelSSE.java` ------------- PR Comment: https://git.openjdk.org/jdk/pull/28433#issuecomment-3820805075 From kvn at openjdk.org Thu Jan 29 23:14:00 2026 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 29 Jan 2026 23:14:00 GMT Subject: RFR: 8372617: Save and restore stubgen stubs when using an AOT code cache [v8] In-Reply-To: <4GvCD6GmYPb9SNGB9spUf7JnhXKRMXsZ14yEGTKnIjI=.8dffb830-af67-4bcc-9553-6ef76226a2a8@github.com> References: <4GvCD6GmYPb9SNGB9spUf7JnhXKRMXsZ14yEGTKnIjI=.8dffb830-af67-4bcc-9553-6ef76226a2a8@github.com> Message-ID: <1-EPWMLqXAESmXDCz1T4CSStN4KmiJuki9vJW5TFZF4=.324d7028-9c33-4af2-b6a8-9721d34c66c2@github.com> On Thu, 29 Jan 2026 10:48:32 GMT, Andrew Dinn wrote: >> This PR adds save and restore of all generated stubs to the AOT code cache on x86 and aarch64. Other arches are modified to deal with the related generic PAI changes. >> >> Small changes were required to the aarch64 and x86_64 generator code in order to meet two key constraints: >> 1. the first declared entry of every stub starts at the first instruction in the stub code range >> 2. all data/code cross-references from one stub to another target a declared stub entry > > Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: > > Run AOTCodeFlags test with multiple GCs I reproduced crash locally on linux-x64-debug (fast debug build) $ make test CONF=fast TEST=runtime/cds/appcds/aotCode/AOTCodeFlags.java#parallel In hs_err file: # SIGSEGV (0xb) at pc=0x00007fe1eb77da6d, pid=12380, tid=12383 # # JRE version: Java(TM) SE Runtime Environment (27.0) (fastdebug build 27-internal-vkozlov.open) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 27-internal-vkozlov.open, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, parallel gc, linux-amd64) # Problematic frame: # v ~BufferBlob::final_blob (stub gen) 0x00007fe1eb77da6d ... Stack: [0x00007fe205c5c000,0x00007fe205d5d000], sp=0x00007fe205d59790, free space=1013k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) v ~BufferBlob::final_blob (stub gen) 0x00007fe1eb77da6d J 416 c1 java.util.Arrays.copyOf([Ljava/lang/Object;ILjava/lang/Class;)[Ljava/lang/Object; java.base at 27-internal (40 bytes) @ 0x00007fe1e432044e [0x00007fe1e4320180+0x00000000000002ce] j java.util.Arrays.copyOf([Ljava/lang/Object;I)[Ljava/lang/Object;+6 java.base at 27-internal j java.lang.invoke.LambdaFormBuffer.startEdit()V+138 java.base at 27-internal j java.lang.invoke.LambdaFormEditor.makeArgumentCombinationForm(ILjava/lang/invoke/MethodType;ZZ)Ljava/lang/invoke/LambdaForm;+8 java.base at 27-internal j java.lang.invoke.LambdaFormEditor.filterArgumentForm(ILjava/lang/invoke/LambdaForm$BasicType;)Ljava/lang/invoke/LambdaForm;+108 java.base at 27-internal ------------- PR Comment: https://git.openjdk.org/jdk/pull/28433#issuecomment-3820875064 From dholmes at openjdk.org Fri Jan 30 00:00:52 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 30 Jan 2026 00:00:52 GMT Subject: RFR: 8373367: interp-only mechanism fails to work for carrier threads in a corner case [v2] In-Reply-To: References: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com> Message-ID: <-7m7MOydFmVaRTVIEB6Im58q0fRxzCSYypY6bu7h0aA=.78339733-0d06-4739-9d86-ca93e6e40bc5@github.com> On Thu, 29 Jan 2026 09:23:41 GMT, Serguei Spitsyn wrote: >> The `interp-only` mechanism is based on the `JavaThread` objects. Carrier and virtual threads can temporary share the same `JavaThread`. The `java_thread->jvmti_thread_state()` is re-linked to a virtual thread at `mount` and to the carrier thread at `unmount`. The `JvmtiThreadState` has a back link to the `JavaThread` which is also set for virtual thread at a `mount` and carrier thread at an `unmount`. Just one of these two links at the same time is set to the `JavaThread`, the other one has to be set to `nullptr`. The `interp-only` mechanism needs this invariant. >> However, there is a corner case when this invariant is broken. It happens when the `JvmtiThreadState` for carrier thread has just been created. In such case, the link to `JavaThread` is always `non-nullptr` even though a virtual thread is currently mounted on a carrier thread. This simple update fixes the issue in the `JvmtiThreadState` ctor. >> >> Testing: >> - TBD: Mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: some tweaks for carrier thread JvmtiThreadState initialization src/hotspot/share/prims/jvmtiThreadState.cpp line 61: > 59: > 60: if (JvmtiEnvBase::is_thread_carrying_vthread(thread, thread_oop)) { > 61: // Carrier and virtual threads can temporary share the same JavaThread. Suggestion: // Carrier and virtual threads can temporarily share the same JavaThread. src/hotspot/share/prims/jvmtiThreadState.cpp line 65: > 63: // It is needed for interp-only mechanism. > 64: _thread = nullptr; > 65: _thread_saved = thread; The meaning of these variables is not described here or in the header file. That makes it hard to assess the correctness based on the comments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29436#discussion_r2744014657 PR Review Comment: https://git.openjdk.org/jdk/pull/29436#discussion_r2744018321 From dholmes at openjdk.org Fri Jan 30 00:00:53 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 30 Jan 2026 00:00:53 GMT Subject: RFR: 8373367: interp-only mechanism fails to work for carrier threads in a corner case [v2] In-Reply-To: <-7m7MOydFmVaRTVIEB6Im58q0fRxzCSYypY6bu7h0aA=.78339733-0d06-4739-9d86-ca93e6e40bc5@github.com> References: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com> <-7m7MOydFmVaRTVIEB6Im58q0fRxzCSYypY6bu7h0aA=.78339733-0d06-4739-9d86-ca93e6e40bc5@github.com> Message-ID: On Thu, 29 Jan 2026 23:56:32 GMT, David Holmes wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> review: some tweaks for carrier thread JvmtiThreadState initialization > > src/hotspot/share/prims/jvmtiThreadState.cpp line 61: > >> 59: >> 60: if (JvmtiEnvBase::is_thread_carrying_vthread(thread, thread_oop)) { >> 61: // Carrier and virtual threads can temporary share the same JavaThread. > > Suggestion: > > // Carrier and virtual threads can temporarily share the same JavaThread. Also I think this comment block should come before the if statement as it seems to be explaining both the if and else cases. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29436#discussion_r2744016478 From dholmes at openjdk.org Fri Jan 30 00:49:53 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 30 Jan 2026 00:49:53 GMT Subject: RFR: 8374744: Enable dumping of APX EGPRs =?UTF-8?B?KFIxNuKAk1IzMSk=?= in JVM fatal error logs In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 21:47:27 GMT, Srinivas Vamsi Parasa wrote: > > Why is this only implemented for Linux? > > Hello David (@dholmes-ora), this change is only implemented for Linux as APX support is available from kernel >= 6.16. For Windows, the status of APX support is not known. > > Thanks, Vamsi None of the code predicated on `UseAPX` is Linux-only but is all OS-agnostic as far as I can see. These changes seem applicable to all x86 platforms: Linux, Windows, macOS. Unfortunately `os::print_register_info` is duplicated across all three OS (with one key difference for each OS - how to read a register from the context). ------------- PR Comment: https://git.openjdk.org/jdk/pull/29098#issuecomment-3821170840 From dholmes at openjdk.org Fri Jan 30 01:07:55 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 30 Jan 2026 01:07:55 GMT Subject: RFR: 8374744: Enable dumping of APX EGPRs =?UTF-8?B?KFIxNuKAk1IzMSk=?= in JVM fatal error logs In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 00:47:29 GMT, David Holmes wrote: > > > Why is this only implemented for Linux? > > > > > > Hello David (@dholmes-ora), this change is only implemented for Linux as APX support is available from kernel >= 6.16. For Windows, the status of APX support is not known. > > Thanks, Vamsi > > None of the code predicated on `UseAPX` is Linux-only but is all OS-agnostic as far as I can see. These changes seem applicable to all x86 platforms: Linux, Windows, macOS. Unfortunately `os::print_register_info` is duplicated across all three OS (with one key difference for each OS - how to read a register from the context). Of course that is why this is OS-specific - the relevant details need to be exposed by the OS eg. via the `uc_mcontext` on Linux. So in general this could apply to all platforms, but we need the OS-specific way to get the data. Sorry for my misunderstanding. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29098#issuecomment-3821215854 From dholmes at openjdk.org Fri Jan 30 01:28:32 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 30 Jan 2026 01:28:32 GMT Subject: RFR: 8374744: Enable dumping of APX EGPRs =?UTF-8?B?KFIxNuKAk1IzMSk=?= in JVM fatal error logs [v2] In-Reply-To: References: Message-ID: <63vripAxYXARhmiCY5n8c-I05Cj4vwvTwXZQcl_cPDY=.a399f1a0-2a9c-4d19-a168-25ba6ee6892b@github.com> On Thu, 29 Jan 2026 21:48:13 GMT, Srinivas Vamsi Parasa wrote: >> 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. > > Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: > > undo verbose code to print registers; repalce it with for loop This looks fine. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29098#pullrequestreview-3725846689 From kbarrett at openjdk.org Fri Jan 30 01:51:55 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 30 Jan 2026 01:51:55 GMT Subject: RFR: 8376570: GrowableArray::remove_{till,range} should work on empty list In-Reply-To: References: Message-ID: <_P2T8u2uCS5g4N7-cuhbfQt9v3vM80paArj5FylA19o=.b8aa0cd9-747f-4de7-9264-4bb54f51c341@github.com> On Wed, 28 Jan 2026 09:48:58 GMT, Aleksey Shipilev wrote: > Split from [JDK-8375046](https://bugs.openjdk.org/browse/JDK-8375046), we want to make sure GrowableArray removal methods work appropriately with empty lists. > > Testing: > - [x] New test > - [x] Linux x86_64 server fastdebug, `all` (in course of [JDK-8375046](https://bugs.openjdk.org/browse/JDK-8375046) testing) Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29462#pullrequestreview-3725899158 From dlong at openjdk.org Fri Jan 30 03:46:04 2026 From: dlong at openjdk.org (Dean Long) Date: Fri, 30 Jan 2026 03:46:04 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v25] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: On Tue, 27 Jan 2026 09:28:40 GMT, Andrew Haley wrote: >> Mmm, but is it OK to push this PR now? I want to have time for it to bake before rampdown. > > So, I'll happily drop this one change. Yes, drop this change and I'll test it again. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2744481326 From dlong at openjdk.org Fri Jan 30 04:00:49 2026 From: dlong at openjdk.org (Dean Long) Date: Fri, 30 Jan 2026 04:00:49 GMT Subject: RFR: 8347396: Efficient TypeFunc creations [v5] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 09:59:47 GMT, Harshit470250 wrote: >> src/hotspot/share/opto/runtime.hpp line 235: >> >>> 233: static void monitor_notify_C(oopDesc* obj, JavaThread* current); >>> 234: static void monitor_notifyAll_C(oopDesc* obj, JavaThread* current); >>> 235: static const TypeFunc* _clone_type_Type; >> >> hotspot generally avoids public data members other than in simple data structs. > > clone_type() is not a member function of OptoRuntime, Should I define a getter function? I suggest you do it the same as the ShenandoahBarrierSetC2 types. That would mean moving _clone_type_Type to BarrierSetC2 and setting it in make_clone_type(), just like you did for all ShenandoahBarrierSetC2::make_*_Type(). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27279#discussion_r2744506683 From dholmes at openjdk.org Fri Jan 30 04:42:45 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 30 Jan 2026 04:42:45 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases [v2] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 17:53:26 GMT, Patricio Chilano Mateo wrote: >> What would force it to be non-null? (Related: under what conditions will `th` be null and what does that imply about the value of `_thread_h()`?) > > A null `java_thread` is only possible for the unmounted vthread case. The oop should always be a valid `java.lang.Thread` though. Maybe `thread_oop` should be initialized to `nullptr` and the assert at line 1914 be just `assert(thread_oop != nullptr, "Missing Thread oop");`? Okay so `!is_virtual => java_thread != nullptr`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2744574434 From dholmes at openjdk.org Fri Jan 30 04:47:50 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 30 Jan 2026 04:47:50 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases [v2] In-Reply-To: References: Message-ID: <6WdkzWF-d6yGLKVUP9pCiYE1ghOdL5sTlcBiA1bE4c0=.802606b6-f958-4dea-a6a7-3d8a406c177c@github.com> On Thu, 29 Jan 2026 09:12:21 GMT, Alan Bateman wrote: >> src/hotspot/share/services/threadService.cpp line 1479: >> >>> 1477: if (cl._thread_status == JavaThreadStatus::NEW || cl._thread_status == JavaThreadStatus::TERMINATED) { >>> 1478: return nullptr; >>> 1479: } >> >> It is not obvious to me why this is only a possibility now? > > ThreadSnapshot.of(Thread) may be invoked with a platform or virtual Thread in any state. It could sample the thread state before calling ThreadSnapshotFactory::get_thread_snapshot. That would allow it to filter out unstarted/NEW threads. It could also filter terminated threads but that would be racy and get_thread_snapshot would still need to handle terminated threads. > > For platform threads, get_thread_snapshot will bail out early if there is no JavaThread. So the effect of the above is to have virtual threads also be filtered out. Still not clear to me why any new thread is not already filtered out long before now; nor why we have not needed this in the past. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2744583241 From dholmes at openjdk.org Fri Jan 30 04:50:26 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 30 Jan 2026 04:50:26 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases [v2] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 09:01:20 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/lang/Thread.java line 2218: >> >>> 2216: } >>> 2217: Object trace = getStackTrace0(); >>> 2218: if (trace instanceof StackTraceElement[] stackTrace) { >> >> What can this return other than a `StackTraceElement[]` ?? > > It can only return a StackTraceElement[] or null. Using a type pattern seemed nicer here to avoid a null check + explicit cast. Sorry I have to disagree - a type check screams to me that this could be some other type when it can't. A null check would be better IMO. On the matter of the cast, why doesn't getStackTrace0 return STE[] instead of object? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2744587005 From jbhateja at openjdk.org Fri Jan 30 07:35:43 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 30 Jan 2026 07:35:43 GMT Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass them to intrinsic entries [v4] In-Reply-To: References: Message-ID: > As per [discussions ](https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594) on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch in preparation of Float16 vector API support. > > Patch add new lane type constants and pass them to vector intrinsic entry points. > > All existing Vector API jtreg test are passing with the patch. > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Review comments resolutions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29481/files - new: https://git.openjdk.org/jdk/pull/29481/files/d81035fd..ff73dc3d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29481&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29481&range=02-03 Stats: 858 lines in 48 files changed: 290 ins; 13 del; 555 mod Patch: https://git.openjdk.org/jdk/pull/29481.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29481/head:pull/29481 PR: https://git.openjdk.org/jdk/pull/29481 From jbhateja at openjdk.org Fri Jan 30 07:35:46 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 30 Jan 2026 07:35:46 GMT Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass them to intrinsic entries [v3] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 18:08:03 GMT, Paul Sandoz wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments resolutions > > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LaneType.java line 88: > >> 86: final String printName; >> 87: final char typeChar; // one of "BSILFD" >> 88: final int laneType; // lg(size/8) | (kind=='F'?4:kind=='I'?8) > > We need to change the name of this field to more clearly distinguish between it and the class name. > > If we can change the values of `LT_*` and align them with the enum ordinal values then we can call it `laneTypeOrdinal` and consistently use that, then we don't likely need the `LT_*` constants. If the values need to align with `BasicType` values then it might be better called `laneTypeIdentifier` or `laneTypeId`. Thanks @PaulSandoz , I have incorporated your comments, it will still be useful to keep new LT_* constants as its better to pass named constants to intrinsic entries rather than numeric values. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2745013458 From sspitsyn at openjdk.org Fri Jan 30 07:45:04 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 30 Jan 2026 07:45:04 GMT Subject: RFR: 8373367: interp-only mechanism fails to work for carrier threads in a corner case [v3] In-Reply-To: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com> References: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com> Message-ID: > The `interp-only` mechanism is based on the `JavaThread` objects. Carrier and virtual threads can temporary share the same `JavaThread`. The `java_thread->jvmti_thread_state()` is re-linked to a virtual thread at `mount` and to the carrier thread at `unmount`. The `JvmtiThreadState` has a back link to the `JavaThread` which is also set for virtual thread at a `mount` and carrier thread at an `unmount`. Just one of these two links at the same time is set to the `JavaThread`, the other one has to be set to `nullptr`. The `interp-only` mechanism needs this invariant. > However, there is a corner case when this invariant is broken. It happens when the `JvmtiThreadState` for carrier thread has just been created. In such case, the link to `JavaThread` is always `non-nullptr` even though a virtual thread is currently mounted on a carrier thread. This simple update fixes the issue in the `JvmtiThreadState` ctor. > > Testing: > - TBD: Mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: moved and extended comment in JvmtiThreadState ctor ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29436/files - new: https://git.openjdk.org/jdk/pull/29436/files/23d6f88e..e5735668 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29436&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29436&range=01-02 Stats: 10 lines in 1 file changed: 7 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29436.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29436/head:pull/29436 PR: https://git.openjdk.org/jdk/pull/29436 From sspitsyn at openjdk.org Fri Jan 30 07:45:07 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 30 Jan 2026 07:45:07 GMT Subject: RFR: 8373367: interp-only mechanism fails to work for carrier threads in a corner case [v2] In-Reply-To: References: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com> <-7m7MOydFmVaRTVIEB6Im58q0fRxzCSYypY6bu7h0aA=.78339733-0d06-4739-9d86-ca93e6e40bc5@github.com> Message-ID: <898pyR61j5geo_EGN0nEeNSkP0Bn5e7Wu5BH-MqxG9k=.1786e7b6-fa1a-4eff-9b1a-8cfe439a35f1@github.com> On Thu, 29 Jan 2026 23:57:26 GMT, David Holmes wrote: >> src/hotspot/share/prims/jvmtiThreadState.cpp line 61: >> >>> 59: >>> 60: if (JvmtiEnvBase::is_thread_carrying_vthread(thread, thread_oop)) { >>> 61: // Carrier and virtual threads can temporary share the same JavaThread. >> >> Suggestion: >> >> // Carrier and virtual threads can temporarily share the same JavaThread. > > Also I think this comment block should come before the if statement as it seems to be explaining both the if and else cases. Thank you for suggestions. Moved and extended the comment to make it more understandable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29436#discussion_r2745036660 From sspitsyn at openjdk.org Fri Jan 30 07:45:11 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 30 Jan 2026 07:45:11 GMT Subject: RFR: 8373367: interp-only mechanism fails to work for carrier threads in a corner case [v2] In-Reply-To: <-7m7MOydFmVaRTVIEB6Im58q0fRxzCSYypY6bu7h0aA=.78339733-0d06-4739-9d86-ca93e6e40bc5@github.com> References: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com> <-7m7MOydFmVaRTVIEB6Im58q0fRxzCSYypY6bu7h0aA=.78339733-0d06-4739-9d86-ca93e6e40bc5@github.com> Message-ID: On Thu, 29 Jan 2026 23:58:16 GMT, David Holmes wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> review: some tweaks for carrier thread JvmtiThreadState initialization > > src/hotspot/share/prims/jvmtiThreadState.cpp line 65: > >> 63: // It is needed for interp-only mechanism. >> 64: _thread = nullptr; >> 65: _thread_saved = thread; > > The meaning of these variables is not described here or in the header file. That makes it hard to assess the correctness based on the comments. Thanks. Addressed. Please, see above. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29436#discussion_r2745038193 From alanb at openjdk.org Fri Jan 30 08:10:33 2026 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 30 Jan 2026 08:10:33 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases [v2] In-Reply-To: <6WdkzWF-d6yGLKVUP9pCiYE1ghOdL5sTlcBiA1bE4c0=.802606b6-f958-4dea-a6a7-3d8a406c177c@github.com> References: <6WdkzWF-d6yGLKVUP9pCiYE1ghOdL5sTlcBiA1bE4c0=.802606b6-f958-4dea-a6a7-3d8a406c177c@github.com> Message-ID: On Fri, 30 Jan 2026 04:45:33 GMT, David Holmes wrote: >> ThreadSnapshot.of(Thread) may be invoked with a platform or virtual Thread in any state. It could sample the thread state before calling ThreadSnapshotFactory::get_thread_snapshot. That would allow it to filter out unstarted/NEW threads. It could also filter terminated threads but that would be racy and get_thread_snapshot would still need to handle terminated threads. >> >> For platform threads, get_thread_snapshot will bail out early if there is no JavaThread. So the effect of the above is to have virtual threads also be filtered out. > > Still not clear to me why any new thread is not already filtered out long before now; nor why we have not needed this in the past. We want ThreadSnapshot.of(Thread) to accept a Thread in any state. Existing behavior is to return null for platform threads that are not alive. For virtual threads it will return a snapshot so we want to change that. The ThreadNotAlive test in the PR allows to specifically check these cases as they are hard to demonstrate with the thread dump. ThreadSnapshot.of(Thread) does not filter out the "not alive" cases. It could, in which case ThreadSnapshotFactory::get_thread_snapshot would need to assert if called with a new/unstarted thread. The terminating thread case would still need to be handled by ThreadSnapshotFactory::get_thread_snapshot. For platform threads there is no JavaThread so it bails easy. For virtual threads it needs to examine the state. So would you prefer that? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2745112416 From sspitsyn at openjdk.org Fri Jan 30 08:27:26 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 30 Jan 2026 08:27:26 GMT Subject: RFR: 8376185: NoSuchFieldError thrown after a record with type annotation retransformed [v2] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 14:56:31 GMT, Jean-Philippe Bempel wrote: >> ?retransformed >> >> Fix a retransform error when retransforming a record with type annotation. processing the record type annotation was done by calling the wrong method and using the one to process regular annotation. Regular annotations have not the same structure and decoding was therefore incorrect. The decoding methods detect a problem but this error was not propagated correctly outside of VM_RedfineClass::load_new_class_versions method, swallowing the error and leaving the retransformed class in bad state. >> >> Here we have fixed the call to the right method for decoding the type annotations but also propagated the error when rewriting the constant pool as an JVMTI_ERROR_INTERNAL > > Jean-Philippe Bempel has updated the pull request incrementally with one additional commit since the last revision: > > add copyright headers src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1477: > 1475: if (res != JVMTI_ERROR_NONE) { > 1476: return res; > 1477: } Pending exception need to be processed and cleared below (see lines: 1478-1487). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29445#discussion_r2745165920 From epeter at openjdk.org Fri Jan 30 08:36:42 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Fri, 30 Jan 2026 08:36:42 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v13] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 19:43:27 GMT, Sandhya Viswanathan wrote: >> ### Int VectorBulkOperationsArray Fill >> >> Benchmark (ns/op) | Size | -OptimizeFill (JITed code) | +OptimizeFill (Masked store) | +OptimizeFill (Unmasked store - This PR) | Delta (masked vs. unmasked) >> -- | -- | -- | -- | -- | -- >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 0 | 0.649 | 0.651 | 0.655 | 1% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 1 | 2.371 | 2.801 | 2.827 | 1% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 2 | 2.374 | 2.585 | 2.942 | 12% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 3 | 2.809 | 2.589 | 3.094 | 16% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 4 | 3.356 | 2.587 | 2.852 | 9% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 5 | 3.531 | 2.588 | 3.158 | 18% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 6 | 3.747 | 2.589 | 3.118 | 17% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 7 | 3.989 | 2.589 | 3.332 | 22% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 8 | 5.047 | 2.588 | 2.832 | 9% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 9 | 4.79 | 2.845 | 3.056 | 7% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 10 | 4.982 | 2.85 | 3.274 | 13% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 11 | 4.551 | 2.852 | 3.521 | 19% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 12 | 4.281 | 2.853 | 3.12 | 9% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 13 | 4.391 | 2.894 | 3.499 | 17% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 14 | 4.909 | 2.848 | 3.339 | 15% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 15 | 5.269 | 2.853 | 3.524 | 19% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 16 | 5.663 | 2.836 | 3.101 | 9% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 17 | 5.553 | 2.924 | 3.111 | 6% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 18 | 5.105 | 2.933 | 3.358 | 13% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 19 | 5.09 | 2.942 | 3.583 | 18% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 20 | 4.457 | 2.927 | 3.272 | 11% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 21 | 4.745 | 3.104 | 3.598 | 14% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 22 | 4.949 | 2.932 | 3.481 | 16% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 23 | 4.992 | 2.939 | 3.761 | 22% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 24 | 5.198 | 2.92 | 3.205 | 9% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 25 | 5.... > >> > > @vamsi-parasa Ok, so now we have one benchmark that shows a speedup and one that shows a regression. How are we to proceed? >> > > It seems that without loads [#28442 (comment)](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761659799), this patch leads to a regression. >> > > Only if there is a load from one of the last elements that the `Arrays.fill` stored to with a masked operation do we get a slowdown. Because of missing load-to-store forwarding. If we instead started loading from the first elements, those would probably already be in cache, and we would not have any latency issues, right? >> > > But is it not rather an edge-case that we load from the last elements immediately after the `Arrays.fill`? At least for longer arrays, it seems an edge case. For short arrays it is probably more likely that we access the last element soon after the fill. >> > > It does not seem like a trivial decision to me if this patch is an improvement or not. What do you think @vamsi-parasa ? >> > > @sviswa7 @dwhite-intel You already approved this PR. What are your thoughts here? >> > >> > >> > @eme64 My thoughts are to go ahead with this PR replacing masked stores with scalar tail processing. As we have seen from https://bugs.openjdk.org/browse/JDK-8349452 masked stores can cause big regression in certain scenarios: accessing elements just written or any other adjacent data that happens to fall in the masked store range. >> >> @sviswa7 But once this PR is integrated, I could file a performance regression with the benchmarks from [up here](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761659799). So what's the argument which choice is better, since we have a mix of speedups/regression going either way, and both are probably in the 10-20% range? > > @eme64 You have a point there, but if you see the performance numbers for ByteMatrix.java (from JDK-8349452) in the PR description above we are talking about a recovery of 3x or so. The ByteMatrix.java is doing only Arrays.fill() on individual arrays of a 2D array. The individual arrays happened to be allocated alongside each other by the JVM and the next store sees stalls due to the masked store of previous array initialization. That was the reason to look for a solution without masked stores. @sviswa7 Ah right, the ByteMatrix.java is yet another case. There, we don't seem to have any loads. > The individual arrays happened to be allocated alongside each other by the JVM and the next store sees stalls due to the masked store of previous array initialization. Ah, that sounds interesting! Is there some tool that would let me see that it was due to masked store stalls? My (probably uneducated) guess would have been that it is just because a single element store would be much cheaper than a masked operation. If you only access a single or 2 elements, then a masked store is not yet profitable. What if the masked stores were a bit further away, say a cacheline away? Would that be significantly faster, because there are no stalls? Or still slow because of the inherent higher cost of masked operations? If we take the ByteMatrix.java benchmark: how would the performance change if we increase the size of the arrays (height)? Is there some height before which the non-masked solution is faster, and after which the masked is faster? Would it be a solution to use scalar stores for very small arrays, and only use the masked loop starting at a certain threshold? ----------------------- I would like to see a summary of all the benchmarks we have here, and in which cases we get speedups/slowdowns, and for which reason. Maybe listing those reasons lets us see some third option we did not yet consider. And listing all the reasons and code shapes may help us find out which shapes we care about most, and then come to a decision that weighs off the pros and cons. We should also document our decision nicely in the code, so that if someone gets a regression in the future, we can see if we had already considered that code shape. Does that make sense? Or do you have a better idea how to make a good decision here? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3822517559 From alanb at openjdk.org Fri Jan 30 08:42:37 2026 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 30 Jan 2026 08:42:37 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases [v2] In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 04:47:59 GMT, David Holmes wrote: >> It can only return a StackTraceElement[] or null. Using a type pattern seemed nicer here to avoid a null check + explicit cast. > > Sorry I have to disagree - a type check screams to me that this could be some other type when it can't. A null check would be better IMO. > > On the matter of the cast, why doesn't getStackTrace0 return STE[] instead of object? The idiom is nice, but I can see how it might be confusing. Your question about getStackTrace0 returning Object is a good question. It should return STE[] but I didn't want to change it as we want it to go away. In the mean-time then it would be clearer and avoid any confusion that it could return anything else. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2745220496 From alanb at openjdk.org Fri Jan 30 09:01:58 2026 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 30 Jan 2026 09:01:58 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases [v2] In-Reply-To: References: Message-ID: <-NLqJNjfFWXKcbdxdRtLnPhX9pye6K406JHWzy6kNTQ=.09e2995d-55aa-4a83-b532-7ab80d0a658f@github.com> On Fri, 30 Jan 2026 04:40:11 GMT, David Holmes wrote: >> A null `java_thread` is only possible for the unmounted vthread case. The oop should always be a valid `java.lang.Thread` though. Maybe `thread_oop` should be initialized to `nullptr` and the assert at line 1914 be just `assert(thread_oop != nullptr, "Missing Thread oop");`? > > Okay so `!is_virtual => java_thread != nullptr`. > Maybe thread_oop should be initialized to nullptr and the assert at line 1914 be just assert(thread_oop != nullptr, "Missing Thread oop");? That would be simpler again, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2745279902 From shade at openjdk.org Fri Jan 30 09:08:59 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 30 Jan 2026 09:08:59 GMT Subject: RFR: 8376472: Shenandoah: Assembler store barriers read destination memory despite the decorators In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 10:47:54 GMT, Aleksey Shipilev wrote: > The issue is really a correctness issue, and it readily manifests in Valhalla, which sometimes does the stores with `IS_DEST_UNINITIALIZED` set. Unfortunately, Shenandoah SATB barriers ignore this attribute, and attempt to read the memory at store address. At best it crashes the VM with the "oopness" asserts, at worst it feeds "garbage" pointers into SATB machinery, which then wrecks havoc on everything else. > > We need to make sure store barriers are consistently checking these attributes. Unfortunately, that would mean doing the changes in arch-specific assembler code. > > This PR makes sure the ShenandoahBarrierSetAssembler store barriers are roughly in the same shape, and that they consult `ShenandoahBarrierSet::need_*_barrier` to make the proper decisions whether to use SATB/card barriers. > > `hotspot_gc_shenandoah` is enough to sanity-check this patch, but I am also running `all` tests for extra safety. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` > - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah` > - [x] Linux x86_64 server fastdebug, `all` + `-XX:+UseShenandoahGC` > - [x] Linux AArch64 server fastdebug, `all` + `-XX:+UseShenandoahGC` > - [x] Linux {PPC64, RISC-V, S390X} server fastdebug, cross-compilation Oh, actually William is Reviewer, so we are covered for the minimal bar. I just need a few additional reviews -- even without formal Reviewer -- to pass the 2 reviews rule bar. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29444#issuecomment-3822640123 From jpbempel at openjdk.org Fri Jan 30 09:09:58 2026 From: jpbempel at openjdk.org (Jean-Philippe Bempel) Date: Fri, 30 Jan 2026 09:09:58 GMT Subject: RFR: 8376185: NoSuchFieldError thrown after a record with type annotation retransformed [v2] In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 08:24:22 GMT, Serguei Spitsyn wrote: >> Jean-Philippe Bempel has updated the pull request incrementally with one additional commit since the last revision: >> >> add copyright headers > > src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1477: > >> 1475: if (res != JVMTI_ERROR_NONE) { >> 1476: return res; >> 1477: } > > Pending exception need to be processed and cleared below (see lines: 1478-1487). @sspitsyn I am not sure to follow your comment. In the case of invalid structure, no exception was pending and therefore the method `load_new_class_versions` returns no error. if `merge_cp_and_rewrite` returns anything else than `JVMTI_ERROR_NONE` it should be propagated. Now, if you want to process pending exception first I can move the check result after, but for example the call above to `compare_and_normalize_class_versions` is done like this also ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29445#discussion_r2745309806 From mchevalier at openjdk.org Fri Jan 30 09:22:44 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Fri, 30 Jan 2026 09:22:44 GMT Subject: RFR: 8375038: C2: Enforce that Ideal() returns the root of the subgraph if any change was made by checking the node hash [v2] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 17:14:22 GMT, Beno?t Maillard wrote: >> This PR introduces an assert in `PhaseIterGVN` to check that `Ideal` actually returns something if the node was modified. >> >> ## Context >> >> In the description of `Node::Ideal` in `node.cpp`, we have: >> >>> If ANY change is made, it must return the root of the reshaped graph - even if the root is the same Node >> >> It is crucial that such changes do not go unnoticed and that they can propagate to other nodes. Current documentation also states: >> >>> Running with `-XX:VerifyIterativeGVN=1` checks >>> these invariants, although its too slow to have on by default. If you are >>> hacking an Ideal call, be sure to test with `-XX:VerifyIterativeGVN=1` >> >> However, `-XX:VerifyIterativeGVN=1` ends up veryfing that the `_in` and `_out` arrays are consistent, but does not verify the return value. >> >> This PR aims to enforce the return value invariant. It should also make regression testing of bugs caused by wrongly returning nullptr in `Ideal` easier, such as [JDK-8373251](https://bugs.openjdk.org/browse/JDK-8373251). >> >> ## Proposed Change >> >> In summary, this PR brings the following set of changes >> - Add a new flag bit to`-XX:VerifyIterativeGVN` for verifying return of `Ideal` calls >> - Add an assert on the hash of nodes before and after `Ideal` in `PhaseIterGVN::transform_old` >> - Fix `Ideal` optimizations that would cause harness errors with testing on tier1 >> - Update the comments in the code to clarify the invariant and how to enforce it >> >> After consideration, I took the decision to only check the hash if the node is not dead. It seems there are many cases where the control node is dead, and we propagate the information to all users with `kill_dead_code`, and end up return `nullptr`. This is basically a mechanism to "speed up" the propagation (it would also happen normally via the usual IGVN worklist). This somehow contradicts the "must return the root of the reshaped graph" invariant, but it seems to be a common practice. >> >> In addition to that, I have decided to implement this as part of a new flag bit to `-XX:VerifyIterativeGVN` instead of an existing one, because there is a risk that it causes new failures in existing usages of the flag. >> >> This PR is meant to introduce the new check and fix the most "obvious" failures that the new flag would introduce in common scenarios, such as when running with `-version` on tier1. Since there are known issues caused by bad return values of `Ideal` (such as [JDK-8373251](https://bugs.openjdk.org/browse/... > > Beno?t Maillard has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/share/opto/node.cpp > > Co-authored-by: Roberto Casta?eda Lozano Is it going to be added in testing? Maybe we can at least add it to https://github.com/openjdk/jdk/blob/42370e22c5bc4ebd40fd500a2e6e9e07f0b8bcd8/test/hotspot/jtreg/compiler/c2/TestVerifyIterativeGVN.java#L24-L37 There starts to be a lot of sub-flags in this flag. Would is be meaningful to merge the new one with https://github.com/openjdk/jdk/blob/42370e22c5bc4ebd40fd500a2e6e9e07f0b8bcd8/src/hotspot/share/opto/c2_globals.hpp#L702 Since it's also about verifying whether something changed? That would mean fixing everything before merging this, alas. And if I'm fine with merged flags that enable more things than maybe useful, I can also spam the `1`s for `VerifyIterativeGVN`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29421#issuecomment-3822695081 From mdoerr at openjdk.org Fri Jan 30 09:51:04 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 30 Jan 2026 09:51:04 GMT Subject: RFR: 8376472: Shenandoah: Assembler store barriers read destination memory despite the decorators In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 10:47:54 GMT, Aleksey Shipilev wrote: > The issue is really a correctness issue, and it readily manifests in Valhalla, which sometimes does the stores with `IS_DEST_UNINITIALIZED` set. Unfortunately, Shenandoah SATB barriers ignore this attribute, and attempt to read the memory at store address. At best it crashes the VM with the "oopness" asserts, at worst it feeds "garbage" pointers into SATB machinery, which then wrecks havoc on everything else. > > We need to make sure store barriers are consistently checking these attributes. Unfortunately, that would mean doing the changes in arch-specific assembler code. > > This PR makes sure the ShenandoahBarrierSetAssembler store barriers are roughly in the same shape, and that they consult `ShenandoahBarrierSet::need_*_barrier` to make the proper decisions whether to use SATB/card barriers. > > `hotspot_gc_shenandoah` is enough to sanity-check this patch, but I am also running `all` tests for extra safety. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` > - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah` > - [x] Linux x86_64 server fastdebug, `all` + `-XX:+UseShenandoahGC` > - [x] Linux AArch64 server fastdebug, `all` + `-XX:+UseShenandoahGC` > - [x] Linux {PPC64, RISC-V, S390X} server fastdebug, cross-compilation src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp line 613: > 611: val, > 612: tmp1, tmp2, tmp3, > 613: preservation_level); Shouldn't there be a `return` statement? There's another `BarrierSetAssembler::store_at` below. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29444#discussion_r2745464876 From duke at openjdk.org Fri Jan 30 09:58:52 2026 From: duke at openjdk.org (Harshit470250) Date: Fri, 30 Jan 2026 09:58:52 GMT Subject: RFR: 8347396: Efficient TypeFunc creations [v5] In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 03:58:23 GMT, Dean Long wrote: >> clone_type() is not a member function of OptoRuntime, Should I define a getter function? > > I suggest you do it the same as the ShenandoahBarrierSetC2 types. That would mean moving _clone_type_Type to BarrierSetC2 and setting it in make_clone_type(), just like you did for all ShenandoahBarrierSetC2::make_*_Type(). ShenandoahBarrierSetC2 types are also public data members, they can also be made private. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27279#discussion_r2745489991 From shade at openjdk.org Fri Jan 30 10:16:19 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 30 Jan 2026 10:16:19 GMT Subject: RFR: 8376472: Shenandoah: Assembler store barriers read destination memory despite the decorators [v2] In-Reply-To: References: Message-ID: > The issue is really a correctness issue, and it readily manifests in Valhalla, which sometimes does the stores with `IS_DEST_UNINITIALIZED` set. Unfortunately, Shenandoah SATB barriers ignore this attribute, and attempt to read the memory at store address. At best it crashes the VM with the "oopness" asserts, at worst it feeds "garbage" pointers into SATB machinery, which then wrecks havoc on everything else. > > We need to make sure store barriers are consistently checking these attributes. Unfortunately, that would mean doing the changes in arch-specific assembler code. > > This PR makes sure the ShenandoahBarrierSetAssembler store barriers are roughly in the same shape, and that they consult `ShenandoahBarrierSet::need_*_barrier` to make the proper decisions whether to use SATB/card barriers. > > `hotspot_gc_shenandoah` is enough to sanity-check this patch, but I am also running `all` tests for extra safety. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` > - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah` > - [x] Linux x86_64 server fastdebug, `all` + `-XX:+UseShenandoahGC` > - [x] Linux AArch64 server fastdebug, `all` + `-XX:+UseShenandoahGC` > - [x] Linux {PPC64, RISC-V, S390X} server fastdebug, cross-compilation 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 six additional commits since the last revision: - Missing return in PPC64 for non-reference stores - Merge branch 'master' into JDK-8376472-shenandoah-store-barriers - More polish - RISC-V version - More touchups, AArch64 version - Store barrier cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29444/files - new: https://git.openjdk.org/jdk/pull/29444/files/f15c6cdf..327550e4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29444&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29444&range=00-01 Stats: 16541 lines in 533 files changed: 6042 ins; 3521 del; 6978 mod Patch: https://git.openjdk.org/jdk/pull/29444.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29444/head:pull/29444 PR: https://git.openjdk.org/jdk/pull/29444 From shade at openjdk.org Fri Jan 30 10:16:21 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 30 Jan 2026 10:16:21 GMT Subject: RFR: 8376472: Shenandoah: Assembler store barriers read destination memory despite the decorators [v2] In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 09:48:45 GMT, Martin Doerr wrote: >> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Missing return in PPC64 for non-reference stores >> - Merge branch 'master' into JDK-8376472-shenandoah-store-barriers >> - More polish >> - RISC-V version >> - More touchups, AArch64 version >> - Store barrier cleanup > > src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp line 613: > >> 611: val, >> 612: tmp1, tmp2, tmp3, >> 613: preservation_level); > > Shouldn't there be a `return` statement? There's another `BarrierSetAssembler::store_at` below. Oh, YES, it should short-cut on non-reference stores. Excellent spot! So it does double write of the same value. Only fine-grained memory model tests would have caught this. Fixed in new commit. I think this is the only place where I made this mistake. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29444#discussion_r2745545810 From mdoerr at openjdk.org Fri Jan 30 10:23:01 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 30 Jan 2026 10:23:01 GMT Subject: RFR: 8376472: Shenandoah: Assembler store barriers read destination memory despite the decorators [v2] In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 10:10:43 GMT, Aleksey Shipilev wrote: >> src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp line 613: >> >>> 611: val, >>> 612: tmp1, tmp2, tmp3, >>> 613: preservation_level); >> >> Shouldn't there be a `return` statement? There's another `BarrierSetAssembler::store_at` below. > > Oh, YES, it should short-cut on non-reference stores. Excellent spot! So it does double write of the same value. Only fine-grained memory model tests would have caught this. Fixed in new commit. I think this is the only place where I made this mistake. Looks correct. Thanks! Isn't it better to avoid having `BarrierSetAssembler::store_at` twice? I liked that in the old code. I leave you free to decide. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29444#discussion_r2745581668 From mdoerr at openjdk.org Fri Jan 30 10:22:57 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 30 Jan 2026 10:22:57 GMT Subject: RFR: 8376472: Shenandoah: Assembler store barriers read destination memory despite the decorators [v2] In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 10:16:19 GMT, Aleksey Shipilev wrote: >> The issue is really a correctness issue, and it readily manifests in Valhalla, which sometimes does the stores with `IS_DEST_UNINITIALIZED` set. Unfortunately, Shenandoah SATB barriers ignore this attribute, and attempt to read the memory at store address. At best it crashes the VM with the "oopness" asserts, at worst it feeds "garbage" pointers into SATB machinery, which then wrecks havoc on everything else. >> >> We need to make sure store barriers are consistently checking these attributes. Unfortunately, that would mean doing the changes in arch-specific assembler code. >> >> This PR makes sure the ShenandoahBarrierSetAssembler store barriers are roughly in the same shape, and that they consult `ShenandoahBarrierSet::need_*_barrier` to make the proper decisions whether to use SATB/card barriers. >> >> `hotspot_gc_shenandoah` is enough to sanity-check this patch, but I am also running `all` tests for extra safety. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` >> - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah` >> - [x] Linux x86_64 server fastdebug, `all` + `-XX:+UseShenandoahGC` >> - [x] Linux AArch64 server fastdebug, `all` + `-XX:+UseShenandoahGC` >> - [x] Linux {PPC64, RISC-V, S390X} server fastdebug, cross-compilation > > 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 six additional commits since the last revision: > > - Missing return in PPC64 for non-reference stores > - Merge branch 'master' into JDK-8376472-shenandoah-store-barriers > - More polish > - RISC-V version > - More touchups, AArch64 version > - Store barrier cleanup Marked as reviewed by mdoerr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29444#pullrequestreview-3727470494 From shade at openjdk.org Fri Jan 30 10:30:03 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 30 Jan 2026 10:30:03 GMT Subject: RFR: 8376472: Shenandoah: Assembler store barriers read destination memory despite the decorators [v2] In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 10:20:18 GMT, Martin Doerr wrote: >> Oh, YES, it should short-cut on non-reference stores. Excellent spot! So it does double write of the same value. Only fine-grained memory model tests would have caught this. Fixed in new commit. I think this is the only place where I made this mistake. > > Looks correct. Thanks! Isn't it better to avoid having `BarrierSetAssembler::store_at` twice? I liked that in the old code. I leave you free to decide. Other barriers do flattening for access address, this is what non-reference store shortcut avoids in them. Given the prevalence of non-reference stores, it is worthwhile to optimize for. It is not the issue for PPC64 per se. I like to have barriers in the same shape across architectures, so that we do not have to think twice (pun intended) why did not we do `BSA::store_at` twice in PPC64, like in other arches :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29444#discussion_r2745594476 From mdoerr at openjdk.org Fri Jan 30 10:30:04 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 30 Jan 2026 10:30:04 GMT Subject: RFR: 8376472: Shenandoah: Assembler store barriers read destination memory despite the decorators [v2] In-Reply-To: References: Message-ID: <_0v5g0SEkCEB0lpNwIpwqprPMHzS-MTEUcCsErkVHt4=.e2407dcf-251c-4a1a-9b90-e620639bc896@github.com> On Fri, 30 Jan 2026 10:24:04 GMT, Aleksey Shipilev wrote: > I like to have barriers in the same shape across architectures Agreed. My idea was rather changing it for all platforms. But that may be a bit out of scope, here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29444#discussion_r2745606685 From shade at openjdk.org Fri Jan 30 10:37:13 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 30 Jan 2026 10:37:13 GMT Subject: RFR: 8376472: Shenandoah: Assembler store barriers read destination memory despite the decorators [v2] In-Reply-To: <_0v5g0SEkCEB0lpNwIpwqprPMHzS-MTEUcCsErkVHt4=.e2407dcf-251c-4a1a-9b90-e620639bc896@github.com> References: <_0v5g0SEkCEB0lpNwIpwqprPMHzS-MTEUcCsErkVHt4=.e2407dcf-251c-4a1a-9b90-e620639bc896@github.com> Message-ID: On Fri, 30 Jan 2026 10:27:30 GMT, Martin Doerr wrote: >> Other barriers do flattening for access address, this is what non-reference store shortcut avoids in them. Given the prevalence of non-reference stores, it is worthwhile to optimize for. It is not the issue for PPC64 per se. I like to have barriers in the same shape across architectures, so that we do not have to think twice (pun intended) why did not we do `BSA::store_at` twice in PPC64, like in other arches :) > >> I like to have barriers in the same shape across architectures > > Agreed. My idea was rather changing it for all platforms. But that may be a bit out of scope, here. Yeah, I was looking at it when implementing, and like I said: the flattening comes into picture sideways for x86 and AArch64, robbing us of real readability benefits. Plus, other barriers, e.g. `load_at`, have the same initial check for reference-ness. I think we are in good place with this shape now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29444#discussion_r2745633151 From chagedorn at openjdk.org Fri Jan 30 10:47:17 2026 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Fri, 30 Jan 2026 10:47:17 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v7] In-Reply-To: References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: On Thu, 29 Jan 2026 12:42:44 GMT, Damon Fenacci wrote: >> ## Issue >> >> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. >> >> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. >> >> ## Causes >> >> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. >> >> ## Fix >> >> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: >> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 >> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. >> >> # Testing >> >> * Tier 1-3+ >> * 2 JTReg tests added >> * `TestRangeCheck.java` as regression test for the reported issue >> * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion > > Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8374582: add flagless to test src/hotspot/share/opto/library_call.cpp line 894: > 892: > 893: inline Node* LibraryCallKit::generate_negative_guard(Node* index, RegionNode* region, > 894: Node* *pos_index, bool is_opaque) { Suggestion: Node** pos_index, bool is_opaque) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2745638291 From chagedorn at openjdk.org Fri Jan 30 10:47:19 2026 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Fri, 30 Jan 2026 10:47:19 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v3] In-Reply-To: References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: On Wed, 28 Jan 2026 16:02:56 GMT, Damon Fenacci wrote: >> src/hotspot/share/opto/opaquenode.hpp line 150: >> >>> 148: bool _positive; >>> 149: public: >>> 150: OpaqueCheckNode(Compile* C, Node* tst, bool positive) : Node(nullptr, tst), _positive(positive) { >> >> `tst` is probably almost always a `BoolNode`. I'm wondering if it could also be a constant because we already folded the `BoolNode`? But then it's probably also useless to create the opaque node in the first place. > > Hmmm... I find it hard to totally exclude a constant (e.g. if its inputs are constant...?). In that case we could skip all the opaque business (I guess in the few places where new `OpaqueConstantBool` nodes are created). On the other hand the opaque node should only really delay the folding... ? I think folding is fine since we implement `Value()` to take the input's `Value()`. My understanding is that we insert an additional check that is actually not needed because we already checked it in Java code. So, it should be true at that point but C2 does not know that. We still insert the check in order to make sure to also fold control away if data is dying. Once we know that data will not die anymore, we can remove the useless check again. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2745545348 From thartmann at openjdk.org Fri Jan 30 10:59:01 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 30 Jan 2026 10:59:01 GMT Subject: RFR: 8375046: C2: Incremental inlining step asserts when processing empty late inlines list [v6] In-Reply-To: <0bZ35MkAh88k08YJCy2eFddNuI_s-kMf0NZCJIp3lpo=.1bd652e6-a9ba-452b-8cf3-77972ab21e86@github.com> References: <_tSvASngm2bL0X2wavXI63kJZoypsY5S-dus_KGhs18=.ace489be-48bf-4254-a88e-b4fe456edf02@github.com> <0bZ35MkAh88k08YJCy2eFddNuI_s-kMf0NZCJIp3lpo=.1bd652e6-a9ba-452b-8cf3-77972ab21e86@github.com> Message-ID: On Wed, 28 Jan 2026 09:43:32 GMT, Aleksey Shipilev wrote: >> Seen this assert in stress CTW runs: >> >> >> # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/utilities/growableArray.hpp:498), pid=2972347, tid=2973775 >> # assert(start < end && end <= this->_len) failed: erase called with invalid range (0, 0) for length 0 >> >> Stack: [0x00007fd660bea000,0x00007fd660cea000], sp=0x00007fd660ce4fc0, free space=1003k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0xc00a41] Compile::inline_incrementally_one()+0x801 (growableArray.hpp:498) >> V [libjvm.so+0xc01650] Compile::inline_incrementally(PhaseIterGVN&)+0x2f0 (compile.cpp:2212) >> V [libjvm.so+0xc04581] Compile::Optimize()+0x7d1 (compile.cpp:2357) >> >> >> It looks innocuous, as `GrowableArray::remove_range` does nothing real on `[0, 0)`. It is still IMO a bug to call it with `[0, 0)`, as it is not clear whether to trust inclusive or exclusive boundary. But for `remove_till`, it looks plausible that `remove_till(0)` should work and be a no-op. Looks like it readily happens in C2 CTW when `_late_inlines` is empty. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, additional new gtest to verify `remove_range` works >> - [x] Linux x86_64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision: > > - Alternative fix > - Remove old patch > - Merge branch 'master' into JDK-8375046-growable-array-till-zero > - Missing case > - More tests > - Merge branch 'master' into JDK-8375046-growable-array-till-zero > - Revert > - Leave only the C2 fix > - Merge branch 'master' into JDK-8375046-growable-array-till-zero > - Only clear pos when needed > - ... and 3 more: https://git.openjdk.org/jdk/compare/9c891cab...2f755fb5 Looks good to me too. ------------- Marked as reviewed by thartmann (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29171#pullrequestreview-3727622703 From shade at openjdk.org Fri Jan 30 11:33:07 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 30 Jan 2026 11:33:07 GMT Subject: RFR: 8375046: C2: Incremental inlining step asserts when processing empty late inlines list [v6] In-Reply-To: <0bZ35MkAh88k08YJCy2eFddNuI_s-kMf0NZCJIp3lpo=.1bd652e6-a9ba-452b-8cf3-77972ab21e86@github.com> References: <_tSvASngm2bL0X2wavXI63kJZoypsY5S-dus_KGhs18=.ace489be-48bf-4254-a88e-b4fe456edf02@github.com> <0bZ35MkAh88k08YJCy2eFddNuI_s-kMf0NZCJIp3lpo=.1bd652e6-a9ba-452b-8cf3-77972ab21e86@github.com> Message-ID: On Wed, 28 Jan 2026 09:43:32 GMT, Aleksey Shipilev wrote: >> Seen this assert in stress CTW runs: >> >> >> # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/utilities/growableArray.hpp:498), pid=2972347, tid=2973775 >> # assert(start < end && end <= this->_len) failed: erase called with invalid range (0, 0) for length 0 >> >> Stack: [0x00007fd660bea000,0x00007fd660cea000], sp=0x00007fd660ce4fc0, free space=1003k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0xc00a41] Compile::inline_incrementally_one()+0x801 (growableArray.hpp:498) >> V [libjvm.so+0xc01650] Compile::inline_incrementally(PhaseIterGVN&)+0x2f0 (compile.cpp:2212) >> V [libjvm.so+0xc04581] Compile::Optimize()+0x7d1 (compile.cpp:2357) >> >> >> It looks innocuous, as `GrowableArray::remove_range` does nothing real on `[0, 0)`. It is still IMO a bug to call it with `[0, 0)`, as it is not clear whether to trust inclusive or exclusive boundary. But for `remove_till`, it looks plausible that `remove_till(0)` should work and be a no-op. Looks like it readily happens in C2 CTW when `_late_inlines` is empty. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, additional new gtest to verify `remove_range` works >> - [x] Linux x86_64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision: > > - Alternative fix > - Remove old patch > - Merge branch 'master' into JDK-8375046-growable-array-till-zero > - Missing case > - More tests > - Merge branch 'master' into JDK-8375046-growable-array-till-zero > - Revert > - Leave only the C2 fix > - Merge branch 'master' into JDK-8375046-growable-array-till-zero > - Only clear pos when needed > - ... and 3 more: https://git.openjdk.org/jdk/compare/acf44d3f...2f755fb5 Thanks folks! Here goes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29171#issuecomment-3823231267 From shade at openjdk.org Fri Jan 30 11:35:58 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 30 Jan 2026 11:35:58 GMT Subject: Integrated: 8375046: C2: Incremental inlining step asserts when processing empty late inlines list In-Reply-To: <_tSvASngm2bL0X2wavXI63kJZoypsY5S-dus_KGhs18=.ace489be-48bf-4254-a88e-b4fe456edf02@github.com> References: <_tSvASngm2bL0X2wavXI63kJZoypsY5S-dus_KGhs18=.ace489be-48bf-4254-a88e-b4fe456edf02@github.com> Message-ID: On Mon, 12 Jan 2026 15:33:28 GMT, Aleksey Shipilev wrote: > Seen this assert in stress CTW runs: > > > # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/utilities/growableArray.hpp:498), pid=2972347, tid=2973775 > # assert(start < end && end <= this->_len) failed: erase called with invalid range (0, 0) for length 0 > > Stack: [0x00007fd660bea000,0x00007fd660cea000], sp=0x00007fd660ce4fc0, free space=1003k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0xc00a41] Compile::inline_incrementally_one()+0x801 (growableArray.hpp:498) > V [libjvm.so+0xc01650] Compile::inline_incrementally(PhaseIterGVN&)+0x2f0 (compile.cpp:2212) > V [libjvm.so+0xc04581] Compile::Optimize()+0x7d1 (compile.cpp:2357) > > > It looks innocuous, as `GrowableArray::remove_range` does nothing real on `[0, 0)`. It is still IMO a bug to call it with `[0, 0)`, as it is not clear whether to trust inclusive or exclusive boundary. But for `remove_till`, it looks plausible that `remove_till(0)` should work and be a no-op. Looks like it readily happens in C2 CTW when `_late_inlines` is empty. > > Additional testing: > - [x] Linux x86_64 server fastdebug, additional new gtest to verify `remove_range` works > - [x] Linux x86_64 server fastdebug, `all` This pull request has now been integrated. Changeset: 0a3809d3 Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/0a3809d380bcae8cb24d50886057d8586fa77f7c Stats: 9 lines in 1 file changed: 5 ins; 4 del; 0 mod 8375046: C2: Incremental inlining step asserts when processing empty late inlines list Reviewed-by: vlivanov, thartmann, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/29171 From alanb at openjdk.org Fri Jan 30 12:20:04 2026 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 30 Jan 2026 12:20:04 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases [v3] In-Reply-To: References: Message-ID: > JDK-8364343 upgraded the virtual thread transition management to be independent of JVMTI. We can update java_lang_Thread::async_get_stack_trace to use it and remove the suspend + retry code from Thread.getStackTrace. > > A summary of the changes: > > - java_lang_Thread::async_get_stack_trace is changed to use the new handshake op so it can be called to get the stack trace of a started thread in any state > - Thread::getStackTrace is changed to use async_get_stack_trace for all cases > - The SUSPENDED substate in VirtualThread is removed > - JVM_CreateThreadSnapshot is changed to be usable when JVMTI is not compiled in > - ThreadSnapshotFactory::get_thread_snapshot is changed to not upcall to StackTraceElement to complete the init of the stack trace > > The changes mean that Thread::getStackTrace may be slower when sampling a virtual thread in transition. This case should be rare, and it isn't really a performance critical op anyway. I prototyped use a spin loop and an increasing wait time in MountUnmountDisabler::disable_transition_for_one to avoid the wait(10) but decided to leave it out for now. Future work may examine this issue as there may be other cases (with JVMTI) that would benefit from avoiding the wait. > > A future PR might propose to change Thread.getStackTrace to use ThreadSnapshot and allow java_lang_Thread::async_get_stack_trace be removed. This requires more extensive changes to ThreadSnapshotFactory to reduce overhead when only the stack trace is required. > > Testing: tier1-5. The changes has been already been tested in the loom repo for a few months. Alan Bateman 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 JDK-8376568 - Review feedback - Improve asserts - Cleanup - Merge branch 'master' into Thread.getStackTrace - Initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29461/files - new: https://git.openjdk.org/jdk/pull/29461/files/12214cd8..1b7c9ad7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29461&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29461&range=01-02 Stats: 5098 lines in 109 files changed: 3579 ins; 1148 del; 371 mod Patch: https://git.openjdk.org/jdk/pull/29461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29461/head:pull/29461 PR: https://git.openjdk.org/jdk/pull/29461 From shade at openjdk.org Fri Jan 30 12:35:28 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 30 Jan 2026 12:35:28 GMT Subject: RFR: 8360557: CTW: Inline cold methods to reach more code [v14] In-Reply-To: References: Message-ID: > We use CTW testing for making sure compilers behave well. But we compile the code that is not executed at all, and since our inlining heuristics often looks back at profiles, we end up not actually inlining all too much! This means CTW testing likely misses lots of bugs that normal code is exposed to, especially e.g. in loop optimizations. > > There is an intrinsic tradeoff with accepting more inilned methods in CTW: the compilation time gets significantly worse. With just accepting the cold methods we have reasonable CTW times, eating the improvements we have committed in mainline recently. And it still finds bugs. See the RFE for sample data. > > After this lands and CTW starts to compile cold methods, one can greatly expand the scope of the CTW testing by overriding the static inlining limits. Doing e.g. `TEST_VM_OPTS="-XX:MaxInlineSize=70 -XX:C1MaxInlineSize=70"` finds even more bugs. Unfortunately, the compilation times suffer so much, they are impractical to run in standard configurations, see data in RFE. We will enable some of that testing in special testing pipelines. > > Pre-empting the question: "Well, why not use -Xcomp then, and make sure it inlines well?" The answer is in RFE as well: Xcomp causes _a lot_ of stray compilations for JDK and CTW infra itself. For small JARs in large corpus this eats precious testing time that we would instead like to spend on deeper inlining in the actual JAR code. This also does not force us to look into how CTW works in Xcomp at all; I expect some surprises there. Feather-touching the inlining heuristic paths to just accept methods without looking at profiles looks better. > > Tobias had an idea to implement the stress randomized inlining that would expand the scope of inlining. This improvement stacks well with it. This improvement provides the base case of inlining most reasonable methods, and then allow stress infra to inline some more on top of that. > > Additional testing: > - [x] GHA > - [x] Linux x86_64 server fastdebug, `applications/ctw/modules` > - [x] Linux x86_64 server fastdebug, large CTW corpus (now failing in interesting ways) Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - JDK-8375694 fix - Fix ------------- Changes: https://git.openjdk.org/jdk/pull/26068/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26068&range=13 Stats: 60 lines in 7 files changed: 32 ins; 3 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/26068.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26068/head:pull/26068 PR: https://git.openjdk.org/jdk/pull/26068 From sjohanss at openjdk.org Fri Jan 30 12:50:17 2026 From: sjohanss at openjdk.org (Stefan Johansson) Date: Fri, 30 Jan 2026 12:50:17 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v9] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 14:47:12 GMT, Leo Korinth wrote: >> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. >> >> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. >> >> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. >> >> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. > > Leo Korinth has updated the pull request incrementally with two additional commits since the last revision: > > - Reapply "remove commented out code" > > This reverts commit d0d1860058f0dae7813c3e5115e2784da8331f3b. > - Reapply "Stefan J 4" > > This reverts commit c5a7e2bb44ce111f8c8d1d7f728f1bf8013475e0. Ship it! ------------- Marked as reviewed by sjohanss (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28723#pullrequestreview-3728110245 From egahlin at openjdk.org Fri Jan 30 13:12:48 2026 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 30 Jan 2026 13:12:48 GMT Subject: RFR: 8373096: JFR: Path-to-gc-roots search should be non-recursive [v5] In-Reply-To: <_13pfLfGnYCREnI81qi-sM3dyeaCVyy6KHJBRxTfrqE=.5a239109-0190-4cd3-abec-d9a13354eb16@github.com> References: <_13pfLfGnYCREnI81qi-sM3dyeaCVyy6KHJBRxTfrqE=.5a239109-0190-4cd3-abec-d9a13354eb16@github.com> Message-ID: On Thu, 29 Jan 2026 14:53:01 GMT, Thomas Stuefe wrote: > @egahlin yes, that is nicer and simpler. I adapted your approach. > > Not sure if this helps, but back in December, when I rewrote this, I drew up a quick visio to help with reviews. I'll attach the pdf. [JFR-leakprofiler-DFS.pdf](https://github.com/user-attachments/files/24940854/JFR-leakprofiler-DFS.pdf) Thanks, I need some more time to review your PR, but the change is now more confined and should not be hard to backport. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29382#issuecomment-3823663593 From roland at openjdk.org Fri Jan 30 13:35:16 2026 From: roland at openjdk.org (Roland Westrelin) Date: Fri, 30 Jan 2026 13:35:16 GMT Subject: RFR: 8370519: C2: Hit MemLimit when running with +VerifyLoopOptimizations [v7] In-Reply-To: References: Message-ID: > For this failure memory stats are: > > > Total Usage: 1095525816 > --- Arena Usage by Arena Type and compilation phase, at arena usage peak of 1095525816 --- > Phase Total ra node comp type states reglive regsplit regmask superword cienv ha other > none 5976032 331560 5402064 197512 33712 10200 0 0 984 0 0 0 0 > parse 2716464 65456 1145480 196408 1112752 0 0 0 0 0 196368 0 0 > optimizer 98184 0 32728 0 65456 0 0 0 0 0 0 0 0 > connectionGraph 32728 0 0 32728 0 0 0 0 0 0 0 0 0 > iterGVN 32728 0 32728 0 0 0 0 0 0 0 0 0 0 > idealLoop 918189632 0 38687056 872824784 392776 0 0 0 0 0 6285016 0 0 > idealLoopVerify 2228144 0 0 2228144 0 0 0 0 0 0 0 0 0 > macroExpand 32728 0 32728 0 0 0 0 0 0 0 0 0 0 > graphReshape 32728 0 32728 0 0 0 0 0 0 0 0 0 0 > matcher 20135944 3369848 9033208 7536400 65456 131032 0 0 0 0 0 0 0 > postselect_cleanup 294872 294872 0 0 0 0 0 0 0 0 0 0 0 > scheduler 752944 196488 556456 0 0 0 0 0 0 0 0 0 0 > regalloc 388736 388736 0 0 0 0 0 0 0 0 0 0 0 > ctorChaitin 160032 ... 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 19 additional commits since the last revision: - new test - Merge branch 'master' into JDK-8370519 - Benoit's test case - Merge branch 'master' into JDK-8370519 - package declaration - review - Merge branch 'master' into JDK-8370519 - Update test/hotspot/jtreg/compiler/c2/TestVerifyLoopOptimizationsHighMemUsage.java Co-authored-by: Emanuel Peter - Update test/hotspot/jtreg/compiler/c2/TestVerifyLoopOptimizationsHighMemUsage.java Co-authored-by: Beno?t Maillard - Update src/hotspot/share/opto/loopnode.hpp Co-authored-by: Emanuel Peter - ... and 9 more: https://git.openjdk.org/jdk/compare/536b4f02...1284ae3c ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28581/files - new: https://git.openjdk.org/jdk/pull/28581/files/1c040156..1284ae3c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28581&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28581&range=05-06 Stats: 112132 lines in 4283 files changed: 57826 ins; 20012 del; 34294 mod Patch: https://git.openjdk.org/jdk/pull/28581.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28581/head:pull/28581 PR: https://git.openjdk.org/jdk/pull/28581 From roland at openjdk.org Fri Jan 30 13:35:17 2026 From: roland at openjdk.org (Roland Westrelin) Date: Fri, 30 Jan 2026 13:35:17 GMT Subject: RFR: 8370519: C2: Hit MemLimit when running with +VerifyLoopOptimizations [v6] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 10:22:01 GMT, Beno?t Maillard wrote: > I was able to come up with this test, which is a bit more that 2 times faster than the original one on my machine. Its `memlimit` is set to `600M`, which is enough to make the old version fail. With the new one, the test passes even with a `memlimit` of `200M`, so this should be a good enough margin. Great. The new test looks good to me. I replaced the existing test with that one. Thanks for taking the time to do that. > While looking into this I have also found out that some programs have an unexpectedly high usage of `output` (as was the case in the test case that I initially suggested). I am trying to get a good reproducer and will most likely file a follow-up. Can you post links to the bugs? Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28581#issuecomment-3823765937 From dfenacci at openjdk.org Fri Jan 30 13:56:01 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Fri, 30 Jan 2026 13:56:01 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v8] In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: > ## Issue > > This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. > > This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. > > ## Causes > > The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. > > ## Fix > > A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: > https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 > This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. > > # Testing > > * Tier 1-3+ > * 2 JTReg tests added > * `TestRangeCheck.java` as regression test for the reported issue > * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision: JDK-8374582: fix star layout Co-authored-by: Christian Hagedorn ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29164/files - new: https://git.openjdk.org/jdk/pull/29164/files/083d5698..c5390e4a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29164.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29164/head:pull/29164 PR: https://git.openjdk.org/jdk/pull/29164 From mhaessig at openjdk.org Fri Jan 30 14:40:46 2026 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Fri, 30 Jan 2026 14:40:46 GMT Subject: RFR: 8370519: C2: Hit MemLimit when running with +VerifyLoopOptimizations [v7] In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 13:35:16 GMT, Roland Westrelin wrote: >> For this failure memory stats are: >> >> >> Total Usage: 1095525816 >> --- Arena Usage by Arena Type and compilation phase, at arena usage peak of 1095525816 --- >> Phase Total ra node comp type states reglive regsplit regmask superword cienv ha other >> none 5976032 331560 5402064 197512 33712 10200 0 0 984 0 0 0 0 >> parse 2716464 65456 1145480 196408 1112752 0 0 0 0 0 196368 0 0 >> optimizer 98184 0 32728 0 65456 0 0 0 0 0 0 0 0 >> connectionGraph 32728 0 0 32728 0 0 0 0 0 0 0 0 0 >> iterGVN 32728 0 32728 0 0 0 0 0 0 0 0 0 0 >> idealLoop 918189632 0 38687056 872824784 392776 0 0 0 0 0 6285016 0 0 >> idealLoopVerify 2228144 0 0 2228144 0 0 0 0 0 0 0 0 0 >> macroExpand 32728 0 32728 0 0 0 0 0 0 0 0 0 0 >> graphReshape 32728 0 32728 0 0 0 0 0 0 0 0 0 0 >> matcher 20135944 3369848 9033208 7536400 65456 131032 0 0 0 0 0 0 0 >> postselect_cleanup 294872 294872 0 0 0 0 0 0 0 0 0 0 0 >> scheduler 752944 196488 556456 0 0 0 0 0 0 0 0 0 0 >> regalloc 388736 388736 0 0 0 0 0 0 0 0 0 0 0 >> ... > > 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 19 additional commits since the last revision: > > - new test > - Merge branch 'master' into JDK-8370519 > - Benoit's test case > - Merge branch 'master' into JDK-8370519 > - package declaration > - review > - Merge branch 'master' into JDK-8370519 > - Update test/hotspot/jtreg/compiler/c2/TestVerifyLoopOptimizationsHighMemUsage.java > > Co-authored-by: Emanuel Peter > - Update test/hotspot/jtreg/compiler/c2/TestVerifyLoopOptimizationsHighMemUsage.java > > Co-authored-by: Beno?t Maillard > - Update src/hotspot/share/opto/loopnode.hpp > > Co-authored-by: Emanuel Peter > - ... and 9 more: https://git.openjdk.org/jdk/compare/a221fd63...1284ae3c The new test looks good. I'm just giving this another spin on the CI. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28581#issuecomment-3824099099 From roland at openjdk.org Fri Jan 30 15:04:25 2026 From: roland at openjdk.org (Roland Westrelin) Date: Fri, 30 Jan 2026 15:04:25 GMT Subject: RFR: 8370519: C2: Hit MemLimit when running with +VerifyLoopOptimizations [v8] In-Reply-To: References: Message-ID: > For this failure memory stats are: > > > Total Usage: 1095525816 > --- Arena Usage by Arena Type and compilation phase, at arena usage peak of 1095525816 --- > Phase Total ra node comp type states reglive regsplit regmask superword cienv ha other > none 5976032 331560 5402064 197512 33712 10200 0 0 984 0 0 0 0 > parse 2716464 65456 1145480 196408 1112752 0 0 0 0 0 196368 0 0 > optimizer 98184 0 32728 0 65456 0 0 0 0 0 0 0 0 > connectionGraph 32728 0 0 32728 0 0 0 0 0 0 0 0 0 > iterGVN 32728 0 32728 0 0 0 0 0 0 0 0 0 0 > idealLoop 918189632 0 38687056 872824784 392776 0 0 0 0 0 6285016 0 0 > idealLoopVerify 2228144 0 0 2228144 0 0 0 0 0 0 0 0 0 > macroExpand 32728 0 32728 0 0 0 0 0 0 0 0 0 0 > graphReshape 32728 0 32728 0 0 0 0 0 0 0 0 0 0 > matcher 20135944 3369848 9033208 7536400 65456 131032 0 0 0 0 0 0 0 > postselect_cleanup 294872 294872 0 0 0 0 0 0 0 0 0 0 0 > scheduler 752944 196488 556456 0 0 0 0 0 0 0 0 0 0 > regalloc 388736 388736 0 0 0 0 0 0 0 0 0 0 0 > ctorChaitin 160032 ... Roland Westrelin has updated the pull request incrementally with three additional commits since the last revision: - Update src/hotspot/share/memory/arena.hpp Co-authored-by: Manuel H?ssig - Update src/hotspot/share/opto/loopnode.cpp Co-authored-by: Manuel H?ssig - Update src/hotspot/share/opto/loopnode.hpp Co-authored-by: Manuel H?ssig ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28581/files - new: https://git.openjdk.org/jdk/pull/28581/files/1284ae3c..ce29db29 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28581&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28581&range=06-07 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28581.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28581/head:pull/28581 PR: https://git.openjdk.org/jdk/pull/28581 From mhaessig at openjdk.org Fri Jan 30 15:04:31 2026 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Fri, 30 Jan 2026 15:04:31 GMT Subject: RFR: 8370519: C2: Hit MemLimit when running with +VerifyLoopOptimizations [v7] In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 13:35:16 GMT, Roland Westrelin wrote: >> For this failure memory stats are: >> >> >> Total Usage: 1095525816 >> --- Arena Usage by Arena Type and compilation phase, at arena usage peak of 1095525816 --- >> Phase Total ra node comp type states reglive regsplit regmask superword cienv ha other >> none 5976032 331560 5402064 197512 33712 10200 0 0 984 0 0 0 0 >> parse 2716464 65456 1145480 196408 1112752 0 0 0 0 0 196368 0 0 >> optimizer 98184 0 32728 0 65456 0 0 0 0 0 0 0 0 >> connectionGraph 32728 0 0 32728 0 0 0 0 0 0 0 0 0 >> iterGVN 32728 0 32728 0 0 0 0 0 0 0 0 0 0 >> idealLoop 918189632 0 38687056 872824784 392776 0 0 0 0 0 6285016 0 0 >> idealLoopVerify 2228144 0 0 2228144 0 0 0 0 0 0 0 0 0 >> macroExpand 32728 0 32728 0 0 0 0 0 0 0 0 0 0 >> graphReshape 32728 0 32728 0 0 0 0 0 0 0 0 0 0 >> matcher 20135944 3369848 9033208 7536400 65456 131032 0 0 0 0 0 0 0 >> postselect_cleanup 294872 294872 0 0 0 0 0 0 0 0 0 0 0 >> scheduler 752944 196488 556456 0 0 0 0 0 0 0 0 0 0 >> regalloc 388736 388736 0 0 0 0 0 0 0 0 0 0 0 >> ... > > 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 19 additional commits since the last revision: > > - new test > - Merge branch 'master' into JDK-8370519 > - Benoit's test case > - Merge branch 'master' into JDK-8370519 > - package declaration > - review > - Merge branch 'master' into JDK-8370519 > - Update test/hotspot/jtreg/compiler/c2/TestVerifyLoopOptimizationsHighMemUsage.java > > Co-authored-by: Emanuel Peter > - Update test/hotspot/jtreg/compiler/c2/TestVerifyLoopOptimizationsHighMemUsage.java > > Co-authored-by: Beno?t Maillard > - Update src/hotspot/share/opto/loopnode.hpp > > Co-authored-by: Emanuel Peter > - ... and 9 more: https://git.openjdk.org/jdk/compare/78de1ad5...1284ae3c Well, the CI tells me that the copyright years need updating. src/hotspot/share/memory/arena.hpp line 2: > 1: /* > 2: * Copyright (c) 2017, 2025, Oracle and/or its affiliates. All rights reserved. Suggestion: * Copyright (c) 2017, 2026, Oracle and/or its affiliates. All rights reserved. src/hotspot/share/opto/loopnode.cpp line 2: > 1: /* > 2: * Copyright (c) 1998, 2025, Oracle and/or its affiliates. All rights reserved. Suggestion: * Copyright (c) 1998, 2026, Oracle and/or its affiliates. All rights reserved. src/hotspot/share/opto/loopnode.hpp line 2: > 1: /* > 2: * Copyright (c) 1998, 2025, Oracle and/or its affiliates. All rights reserved. Suggestion: * Copyright (c) 1998, 2026, Oracle and/or its affiliates. All rights reserved. ------------- Changes requested by mhaessig (Committer). PR Review: https://git.openjdk.org/jdk/pull/28581#pullrequestreview-3728810358 PR Review Comment: https://git.openjdk.org/jdk/pull/28581#discussion_r2746683181 PR Review Comment: https://git.openjdk.org/jdk/pull/28581#discussion_r2746682501 PR Review Comment: https://git.openjdk.org/jdk/pull/28581#discussion_r2746680565 From bmaillard at openjdk.org Fri Jan 30 16:13:27 2026 From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard) Date: Fri, 30 Jan 2026 16:13:27 GMT Subject: RFR: 8370519: C2: Hit MemLimit when running with +VerifyLoopOptimizations [v8] In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 15:04:25 GMT, Roland Westrelin wrote: >> For this failure memory stats are: >> >> >> Total Usage: 1095525816 >> --- Arena Usage by Arena Type and compilation phase, at arena usage peak of 1095525816 --- >> Phase Total ra node comp type states reglive regsplit regmask superword cienv ha other >> none 5976032 331560 5402064 197512 33712 10200 0 0 984 0 0 0 0 >> parse 2716464 65456 1145480 196408 1112752 0 0 0 0 0 196368 0 0 >> optimizer 98184 0 32728 0 65456 0 0 0 0 0 0 0 0 >> connectionGraph 32728 0 0 32728 0 0 0 0 0 0 0 0 0 >> iterGVN 32728 0 32728 0 0 0 0 0 0 0 0 0 0 >> idealLoop 918189632 0 38687056 872824784 392776 0 0 0 0 0 6285016 0 0 >> idealLoopVerify 2228144 0 0 2228144 0 0 0 0 0 0 0 0 0 >> macroExpand 32728 0 32728 0 0 0 0 0 0 0 0 0 0 >> graphReshape 32728 0 32728 0 0 0 0 0 0 0 0 0 0 >> matcher 20135944 3369848 9033208 7536400 65456 131032 0 0 0 0 0 0 0 >> postselect_cleanup 294872 294872 0 0 0 0 0 0 0 0 0 0 0 >> scheduler 752944 196488 556456 0 0 0 0 0 0 0 0 0 0 >> regalloc 388736 388736 0 0 0 0 0 0 0 0 0 0 0 >> ... > > Roland Westrelin has updated the pull request incrementally with three additional commits since the last revision: > > - Update src/hotspot/share/memory/arena.hpp > > Co-authored-by: Manuel H?ssig > - Update src/hotspot/share/opto/loopnode.cpp > > Co-authored-by: Manuel H?ssig > - Update src/hotspot/share/opto/loopnode.hpp > > Co-authored-by: Manuel H?ssig Marked as reviewed by bmaillard (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28581#pullrequestreview-3729170387 From bmaillard at openjdk.org Fri Jan 30 16:13:29 2026 From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard) Date: Fri, 30 Jan 2026 16:13:29 GMT Subject: RFR: 8370519: C2: Hit MemLimit when running with +VerifyLoopOptimizations [v6] In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 13:30:25 GMT, Roland Westrelin wrote: > Can you post links to the bugs? Thanks. I haven't filed it yet. I observed something suspicious once, but at the moment I am not able to reproduce it anymore. I will take another look, and I will post here or tag you in the issue if there is any update @rwestrel. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28581#issuecomment-3824502330 From cstein at openjdk.org Fri Jan 30 16:19:07 2026 From: cstein at openjdk.org (Christian Stein) Date: Fri, 30 Jan 2026 16:19:07 GMT Subject: RFR: 8376355: Update to use jtreg 8.2.1 Message-ID: Please review the change to update to using jtreg 8.2.1. The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. ------------- Commit messages: - 8376355: Update to use jtreg 8.2.1 - 8376355: Update to use jtreg 8.2 Changes: https://git.openjdk.org/jdk/pull/29452/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29452&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376355 Stats: 17 lines in 9 files changed: 0 ins; 0 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/29452.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29452/head:pull/29452 PR: https://git.openjdk.org/jdk/pull/29452 From iris at openjdk.org Fri Jan 30 16:28:47 2026 From: iris at openjdk.org (Iris Clark) Date: Fri, 30 Jan 2026 16:28:47 GMT Subject: RFR: 8376355: Update to use jtreg 8.2.1 In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 15:26:20 GMT, Christian Stein wrote: > Please review the change to update to using jtreg 8.2.1. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29452#pullrequestreview-3729267371 From sviswanathan at openjdk.org Fri Jan 30 17:16:32 2026 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Fri, 30 Jan 2026 17:16:32 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v13] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 19:43:27 GMT, Sandhya Viswanathan wrote: >> ### Int VectorBulkOperationsArray Fill >> >> Benchmark (ns/op) | Size | -OptimizeFill (JITed code) | +OptimizeFill (Masked store) | +OptimizeFill (Unmasked store - This PR) | Delta (masked vs. unmasked) >> -- | -- | -- | -- | -- | -- >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 0 | 0.649 | 0.651 | 0.655 | 1% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 1 | 2.371 | 2.801 | 2.827 | 1% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 2 | 2.374 | 2.585 | 2.942 | 12% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 3 | 2.809 | 2.589 | 3.094 | 16% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 4 | 3.356 | 2.587 | 2.852 | 9% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 5 | 3.531 | 2.588 | 3.158 | 18% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 6 | 3.747 | 2.589 | 3.118 | 17% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 7 | 3.989 | 2.589 | 3.332 | 22% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 8 | 5.047 | 2.588 | 2.832 | 9% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 9 | 4.79 | 2.845 | 3.056 | 7% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 10 | 4.982 | 2.85 | 3.274 | 13% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 11 | 4.551 | 2.852 | 3.521 | 19% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 12 | 4.281 | 2.853 | 3.12 | 9% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 13 | 4.391 | 2.894 | 3.499 | 17% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 14 | 4.909 | 2.848 | 3.339 | 15% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 15 | 5.269 | 2.853 | 3.524 | 19% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 16 | 5.663 | 2.836 | 3.101 | 9% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 17 | 5.553 | 2.924 | 3.111 | 6% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 18 | 5.105 | 2.933 | 3.358 | 13% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 19 | 5.09 | 2.942 | 3.583 | 18% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 20 | 4.457 | 2.927 | 3.272 | 11% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 21 | 4.745 | 3.104 | 3.598 | 14% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 22 | 4.949 | 2.932 | 3.481 | 16% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 23 | 4.992 | 2.939 | 3.761 | 22% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 24 | 5.198 | 2.92 | 3.205 | 9% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 25 | 5.... > >> > > @vamsi-parasa Ok, so now we have one benchmark that shows a speedup and one that shows a regression. How are we to proceed? >> > > It seems that without loads [#28442 (comment)](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761659799), this patch leads to a regression. >> > > Only if there is a load from one of the last elements that the `Arrays.fill` stored to with a masked operation do we get a slowdown. Because of missing load-to-store forwarding. If we instead started loading from the first elements, those would probably already be in cache, and we would not have any latency issues, right? >> > > But is it not rather an edge-case that we load from the last elements immediately after the `Arrays.fill`? At least for longer arrays, it seems an edge case. For short arrays it is probably more likely that we access the last element soon after the fill. >> > > It does not seem like a trivial decision to me if this patch is an improvement or not. What do you think @vamsi-parasa ? >> > > @sviswa7 @dwhite-intel You already approved this PR. What are your thoughts here? >> > >> > >> > @eme64 My thoughts are to go ahead with this PR replacing masked stores with scalar tail processing. As we have seen from https://bugs.openjdk.org/browse/JDK-8349452 masked stores can cause big regression in certain scenarios: accessing elements just written or any other adjacent data that happens to fall in the masked store range. >> >> @sviswa7 But once this PR is integrated, I could file a performance regression with the benchmarks from [up here](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761659799). So what's the argument which choice is better, since we have a mix of speedups/regression going either way, and both are probably in the 10-20% range? > > @eme64 You have a point there, but if you see the performance numbers for ByteMatrix.java (from JDK-8349452) in the PR description above we are talking about a recovery of 3x or so. The ByteMatrix.java is doing only Arrays.fill() on individual arrays of a 2D array. The individual arrays happened to be allocated alongside each other by the JVM and the next store sees stalls due to the masked store of previous array initialization. That was the reason to look for a solution without masked stores. > @sviswa7 Ah right, the ByteMatrix.java is yet another case. There, we don't seem to have any loads. > > > The individual arrays happened to be allocated alongside each other by the JVM and the next store sees stalls due to the masked store of previous array initialization. > > Ah, that sounds interesting! Is there some tool that would let me see that it was due to masked store stalls? My (probably uneducated) guess would have been that it is just because a single element store would be much cheaper than a masked operation. If you only access a single or 2 elements, then a masked store is not yet profitable. What if the masked stores were a bit further away, say a cacheline away? Would that be significantly faster, because there are no stalls? Or still slow because of the inherent higher cost of masked operations? > > If we take the ByteMatrix.java benchmark: how would the performance change if we increase the size of the arrays (height)? Is there some height before which the non-masked solution is faster, and after which the masked is faster? > > Would it be a solution to use scalar stores for very small arrays, and only use the masked loop starting at a certain threshold? > > I would like to see a summary of all the benchmarks we have here, and in which cases we get speedups/slowdowns, and for which reason. Maybe listing those reasons lets us see some third option we did not yet consider. And listing all the reasons and code shapes may help us find out which shapes we care about most, and then come to a decision that weighs off the pros and cons. > > We should also document our decision nicely in the code, so that if someone gets a regression in the future, we can see if we had already considered that code shape. > > Does that make sense? Or do you have a better idea how to make a good decision here? @eme64 Again very good points and suggestions as always. One of the data points that you are requesting is visible from the ByteMatrix numbers posted in PR description. If you see the second column vs fourth column in the table, i.e. +OptimizeFill (Masked store stub) vs +OptimizeFill (Unmasked store stub), you can see that for up to 48 bytes we see significant performance improvement with unmasked scalar stores over masked vector store. Between 48 to 64 byte masked store wins. The same behavior repeats for size range 64-128 bytes as that would involve an unmasked 64 byte vector write, followed by a 64 byte masked write. This is all assuming that the on the platform that Vamsi ran this, we are using 64 byte vectors. Vamsi should be able to confirm this. Regarding whether the slow down is due to masked stores stalls, that was my hypothesis based on the optimization guide, excerpts of which Vamsi shared above. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3824789519 From erikj at openjdk.org Fri Jan 30 17:46:27 2026 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 30 Jan 2026 17:46:27 GMT Subject: RFR: 8376355: Update to use jtreg 8.2.1 In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 15:26:20 GMT, Christian Stein wrote: > Please review the change to update to using jtreg 8.2.1. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29452#pullrequestreview-3729610652 From sparasa at openjdk.org Fri Jan 30 17:54:26 2026 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Fri, 30 Jan 2026 17:54:26 GMT Subject: RFR: 8374744: Enable dumping of APX EGPRs =?UTF-8?B?KFIxNuKAk1IzMSk=?= in JVM fatal error logs [v2] In-Reply-To: <63vripAxYXARhmiCY5n8c-I05Cj4vwvTwXZQcl_cPDY=.a399f1a0-2a9c-4d19-a168-25ba6ee6892b@github.com> References: <63vripAxYXARhmiCY5n8c-I05Cj4vwvTwXZQcl_cPDY=.a399f1a0-2a9c-4d19-a168-25ba6ee6892b@github.com> Message-ID: <_OlmH3KXwcfsUjQ8XjxB2jiWYlPVo-HT7d_r_MZp_70=.f8e3d339-bbb0-4be9-89ef-3a0dab85e5f7@github.com> On Fri, 30 Jan 2026 01:26:08 GMT, David Holmes wrote: > This looks fine. Thanks Thanks David! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29098#issuecomment-3824921629 From sparasa at openjdk.org Fri Jan 30 17:54:27 2026 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Fri, 30 Jan 2026 17:54:27 GMT Subject: Integrated: 8374744: Enable dumping of APX EGPRs =?UTF-8?B?KFIxNuKAk1IzMSk=?= in JVM fatal error logs In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 20:28:14 GMT, Srinivas Vamsi Parasa wrote: > 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. This pull request has now been integrated. Changeset: 3a4277db Author: Srinivas Vamsi Parasa URL: https://git.openjdk.org/jdk/commit/3a4277db74f889d0b8350145515c1a1f4e399ec8 Stats: 105 lines in 3 files changed: 83 ins; 1 del; 21 mod 8374744: Enable dumping of APX EGPRs (R16?R31) in JVM fatal error logs Reviewed-by: sviswanathan, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/29098 From sparasa at openjdk.org Fri Jan 30 19:29:45 2026 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Fri, 30 Jan 2026 19:29:45 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v13] In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 17:13:49 GMT, Sandhya Viswanathan wrote: > Vamsi should be able to confirm this. Regarding whether the slow down is due to masked stores stalls, that was my hypothesis > based on the optimization guide, excerpts of which Vamsi shared above. > The MaxVectorSize=64 for the platform used to collect the data in the PR's description for ByteMatrix fill workload. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3825339469 From sparasa at openjdk.org Fri Jan 30 19:29:47 2026 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Fri, 30 Jan 2026 19:29:47 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v13] In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 08:33:57 GMT, Emanuel Peter wrote: >>> > > @vamsi-parasa Ok, so now we have one benchmark that shows a speedup and one that shows a regression. How are we to proceed? >>> > > It seems that without loads [#28442 (comment)](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761659799), this patch leads to a regression. >>> > > Only if there is a load from one of the last elements that the `Arrays.fill` stored to with a masked operation do we get a slowdown. Because of missing load-to-store forwarding. If we instead started loading from the first elements, those would probably already be in cache, and we would not have any latency issues, right? >>> > > But is it not rather an edge-case that we load from the last elements immediately after the `Arrays.fill`? At least for longer arrays, it seems an edge case. For short arrays it is probably more likely that we access the last element soon after the fill. >>> > > It does not seem like a trivial decision to me if this patch is an improvement or not. What do you think @vamsi-parasa ? >>> > > @sviswa7 @dwhite-intel You already approved this PR. What are your thoughts here? >>> > >>> > >>> > @eme64 My thoughts are to go ahead with this PR replacing masked stores with scalar tail processing. As we have seen from https://bugs.openjdk.org/browse/JDK-8349452 masked stores can cause big regression in certain scenarios: accessing elements just written or any other adjacent data that happens to fall in the masked store range. >>> >>> @sviswa7 But once this PR is integrated, I could file a performance regression with the benchmarks from [up here](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761659799). So what's the argument which choice is better, since we have a mix of speedups/regression going either way, and both are probably in the 10-20% range? >> >> @eme64 You have a point there, but if you see the performance numbers for ByteMatrix.java (from JDK-8349452) in the PR description above we are talking about a recovery of 3x or so. The ByteMatrix.java is doing only Arrays.fill() on individual arrays of a 2D array. The individual arrays happened to be allocated alongside each other by the JVM and the next store sees stalls due to the masked store of previous array initialization. That was the reason to look for a solution without masked stores. > > @sviswa7 Ah right, the ByteMatrix.java is yet another case. There, we don't seem to have any loads. > >> The individual arrays happened to be allocated alongside each other by the JVM and the next store sees stalls due to the masked store of previous array initialization. > > Ah, that sounds interesting! Is there some tool that would let me see that it was due to masked store stalls? > My (probably uneducated) guess would have been that it is just because a single element store would be much cheaper than a masked operation. If you only access a single or 2 elements, then a masked store is not yet profitable. What if the masked stores were a bit further away, say a cacheline away? Would that be significantly faster, because there are no stalls? Or still slow because of the inherent higher cost of masked operations? > > If we take the ByteMatrix.java benchmark: how would the performance change if we increase the size of the arrays (height)? Is there some height before which the non-masked solution is faster, and after which the masked is faster? > > Would it be a solution to use scalar stores for very small arrays, and only use the masked loop starting at a certain threshold? > > ----------------------- > > I would like to see a summary of all the benchmarks we have here, and in which cases we get speedups/slowdowns, and for which reason. Maybe listing those reasons lets us see some third option we did not yet consider. And listing all the reasons and code shapes may help us find out which shapes we care about most, and then come to a decision that weighs off the pros and cons. > > We should also document our decision nicely in the code, so that if someone gets a regression in the future, we can see if we had already considered that code shape. > > Does that make sense? Or do you have a better idea how to make a good decision here? Hi Emanuel (@eme64), Based on the discussion, I will run further experiments to see if the regressions can be addressed and get back to you at a later date. Thanks, Vamsi ------------- PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3825349231 From duke at openjdk.org Fri Jan 30 22:22:50 2026 From: duke at openjdk.org (Ruben) Date: Fri, 30 Jan 2026 22:22:50 GMT Subject: RFR: 8372942: AArch64: Set JVM flags for Neoverse V3AE core [v2] In-Reply-To: References: Message-ID: > 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. Ruben has updated the pull request incrementally with one additional commit since the last revision: Introduce `model_is_in` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28607/files - new: https://git.openjdk.org/jdk/pull/28607/files/b4fce62d..5705b5a7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28607&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28607&range=00-01 Stats: 48 lines in 2 files changed: 24 ins; 14 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/28607.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28607/head:pull/28607 PR: https://git.openjdk.org/jdk/pull/28607 From duke at openjdk.org Fri Jan 30 22:49:14 2026 From: duke at openjdk.org (Ruben) Date: Fri, 30 Jan 2026 22:49:14 GMT Subject: RFR: 8360654: AArch64: Remove redundant dmb from C1 compareAndSet In-Reply-To: References: Message-ID: <25N5pSkyXsS8Jki3LlBQ2xivpj8p3gmX1xWWX5xe18I=.e810f5a0-5a0b-45b3-a50a-b083d0d51149@github.com> On Sat, 17 Jan 2026 04:28:33 GMT, Ruben wrote: > This is duplicate of the PR #26000 which was originally created by @spchee. > > =========== > > AtomicLong.CompareAndSet has the following assembly dump snippet which gets emitted from the intermediary LIRGenerator::atomic_cmpxchg: > > > ;; cmpxchg { > 0x0000e708d144cf60: mov x8, x2 > 0x0000e708d144cf64: casal x8, x3, [x0] > 0x0000e708d144cf68: cmp x8, x2 > ;; 0x1F1F1F1F1F1F1F1F > 0x0000e708d144cf6c: mov x8, #0x1f1f1f1f1f1f1f1f > ;; } cmpxchg > 0x0000e708d144cf70: cset x8, ne // ne = any > 0x0000e708d144cf74: dmb ish > > According to the Oracle Java Specification, AtomicLong.CompareAndSet [1] has the same memory effects as specified by VarHandle.compareAndSet which has the following effects: [2] > >> Atomically sets the value of a variable to the >> newValue with the memory semantics of setVolatile if >> the variable's current value, referred to as the witness >> value, == the expectedValue, as accessed with the memory >> semantics of getVolatile. > > Hence the release on the store due to setVolatile only occurs if the compare is successful. Since casal already satisfies these requirements, the dmb does not need to occur to ensure memory ordering in case the compare fails and a release does not happen. > > Hence we remove the dmb from both casl and casw (same logic applies to the non-long variant) > > This is also reflected by C2 not having a dmb for the same respective method. > > [1] https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/concurrent/atomic/AtomicLong.html#compareAndSet(long,long) > [2] https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/invoke/VarHandle.html#compareAndSet(java.lang.Object...) I've run java -jar jcstress.jar (revision 1d143cbd430f4cca63a8f0c8c1fad3aabc065421) for this PR with -XX:TieredStopAtLevel=1 combined with -XX:-UseLSE / -XX:+UseLSE. Result for `-XX:TieredStopAtLevel=1 -XX:+UseLSE`: Jan 28 00:12:16 Failed tests: No matches. Jan 28 00:12:16 Jan 28 00:12:16 Error tests: No matches. Jan 28 00:12:16 Jan 28 00:12:16 All remaining tests: 4957 matching test results. Use -v to print them. Result for `-XX:TieredStopAtLevel=1 -XX:-UseLSE`: Jan 29 01:43:00 Failed tests: No matches. Jan 29 01:43:00 Jan 29 01:43:00 Error tests: No matches. Jan 29 01:43:00 Jan 29 01:43:00 All remaining tests: 4947 matching test results. Use -v to print them. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29287#issuecomment-3826168430 From psandoz at openjdk.org Sat Jan 31 00:03:08 2026 From: psandoz at openjdk.org (Paul Sandoz) Date: Sat, 31 Jan 2026 00:03:08 GMT Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass them to intrinsic entries [v4] In-Reply-To: References: Message-ID: <-fsfUEvFpvmAsupQFgx1CBkH9vr_efE5-qYeUzy5VFQ=.4abb05e0-1f82-4d6c-8bc4-ca4bc6fc5e80@github.com> On Fri, 30 Jan 2026 07:35:43 GMT, Jatin Bhateja wrote: >> As per [discussions ](https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594) on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch in preparation of Float16 vector API support. >> >> Patch add new lane type constants and pass them to vector intrinsic entry points. >> >> All existing Vector API jtreg test are passing with the patch. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Review comments resolutions This is looking good. Just one last comment on the location of `LANE_TYPE_ORDINAL`. src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java line 152: > 150: public static final int MODE_BITS_COERCED_LONG_TO_MASK = 1; > 151: > 152: // Lane type codes for vector: Suggest you change the comment to indicate the values correspond to `jdk.incubator.vector.LaneType` ordinals e.g., jdk.incubator.vector.LaneType.FLOAT.ordinal() == LT_FLOAT etc. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractSpecies.java line 152: > 150: int laneTypeOrdinal() { > 151: return laneType.ordinal(); > 152: } Is this needed? Won't all concrete sub types override this? src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java line 60: > 58: > 59: static final int LANE_TYPE_ORDINAL = LT_BYTE; > 60: You can move this up to `ByteVector` and then reuse it to replace `byte.class`, so it is used consistently. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LaneType.java line 270: > 268: > 269: static { > 270: assert(ofLaneTypeOrdinal(LT_FLOAT) == FLOAT); Very good! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java line 821: > 819: convert(String name, char kind, Class dom, Class ran, int opCode, int flags) { > 820: int domran = ((LaneType.of(dom).ordinal() << VO_DOM_SHIFT) + > 821: (LaneType.of(ran).ordinal() << VO_RAN_SHIFT)); As i understand this is still correct because the maximum ordinal value is less than 16 (as was already the case for the basic type). ------------- PR Review: https://git.openjdk.org/jdk/pull/29481#pullrequestreview-3730928806 PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2748410039 PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2748387527 PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2748483577 PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2748392412 PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2748427970 From xtex at envs.net Sat Jan 31 09:51:36 2026 From: xtex at envs.net (xtex) Date: Sat, 31 Jan 2026 17:51:36 +0800 Subject: Giving up upstream-ing my patches & feel free to pick them up Message-ID: <4555062.ejJDZkT8p0@xtex1> Hi, About one year ago, in Jan. 2025, I began my adventure of the OpenJDK codebase. Later I attempted to make some patches into the repository. I checked the documentation and learned that I have to sign an Oracle Contributor Agreement before submitting patches to OpenJDK. At that time, I dreamed that it was just a pretty normal CLA, like the ones I signed for other projects and shall just take at most several days. A few days later, I received an email asking me to update some information in the agreement. I did. After that, I have sent 5 emails to opensource_ww_grp at oracle.com asking if there was anything wrong (once a month from January to May). For each of my emails, I got a reply, saying that they "sincerely apologize" and "@Dalibor Topic Can you please review...", with no actual progress being made. Now it has been (more than) one year since I submitted my first OCA submission. And I have been tired of "/touch"-ing my PR once a month. I wonder if there is a reason for not reviewing my OCA submission. I do live in Chinese Mainland but I have no contractual or subordinate or teacher- student relationship with any entities that are restricted by the US import/ export control laws (according to OpenSanctions). If you think that I have such a relationship or should be rejected for any other reasons, please simply reject my OCA submission, instead of hanging it for months. As I no longer have enough interest and spare time to work on OpenJDK, I decided to give up upstreaming those patches. If anyone is interested in them, please feel free to pick up and submit these patches, most of which are small but I believe they are useful. As OCA requires that "each contribution that you submit is and shall be an original work of authorship", you may rewrite my patches from scratch so it is an original work, and you don't need to sign my name or ping me. I would like to give a list of the patches that I wanted to upstream but failed: - Checks if "llvm-config" is broken: https://github.com/AOSC-Tracking/jdk/commit/ 6a8b12b1ad700d994a2803de593ca06e698ef1a9 - Extend default thread stack size for zero: This addresses the stack overflow exception in javac when building JDK 24 with zero variants. https://github.com/AOSC-Tracking/jdk/commit/ 4534fcaafc149f649105dc9914c7cf4aaf8c802c https://www.mail-archive.com/build-dev at openjdk.org/msg14818.html Some patches that are not for the upstream OpenJDK but Loongson's fork of JDK and were also blocked by OCA: https://github.com/loongson/jdk/pull/134 https://github.com/loongson/jdk/pull/126 https://github.com/loongson/jdk/pull/125 https://github.com/loongson/jdk/pull/135 https://github.com/loongson/jdk/pull/136 https://github.com/AOSC-Tracking/jdk/commit/ 913dcb2b2759437876ae3a40a1b074eeb1bfe09f https://github.com/AOSC-Tracking/jdk/commit/ caba8e6de73fd9ffa078d6c257d6be8500b9d16a Best wishes, Bye. -- Bingwu Zhang (a.k.a. xtex) @ Sat, 31 Jan 2026 08:42:31 +0000 From davidalayachew at gmail.com Sat Jan 31 15:59:32 2026 From: davidalayachew at gmail.com (David Alayachew) Date: Sat, 31 Jan 2026 10:59:32 -0500 Subject: Giving up upstream-ing my patches & feel free to pick them up In-Reply-To: <4555062.ejJDZkT8p0@xtex1> References: <4555062.ejJDZkT8p0@xtex1> Message-ID: Sorry to hear this. If it makes you feel better, I am born and raised in America, currently live in Washington DC, and I still had to wait over 2 months for mine to be done. @Dalibor Topic , can we get this prioritized? On Sat, Jan 31, 2026, 4:52?AM xtex wrote: > Hi, > > About one year ago, in Jan. 2025, I began my adventure of the OpenJDK > codebase. Later I attempted to make some patches into the repository. > I checked the documentation and learned that I have to sign an Oracle > Contributor Agreement before submitting patches to OpenJDK. At that time, > I > dreamed that it was just a pretty normal CLA, like the ones I signed for > other > projects and shall just take at most several days. > > A few days later, I received an email asking me to update some information > in > the agreement. I did. After that, I have sent 5 emails to > opensource_ww_grp at oracle.com asking if there was anything wrong (once a > month > from January to May). For each of my emails, I got a reply, saying that > they > "sincerely apologize" and "@Dalibor Topic Can you please review...", with > no > actual progress being made. Now it has been (more than) one year since I > submitted my first OCA submission. And I have been tired of "/touch"-ing > my PR > once a month. > > I wonder if there is a reason for not reviewing my OCA submission. I do > live > in Chinese Mainland but I have no contractual or subordinate or teacher- > student relationship with any entities that are restricted by the US > import/ > export control laws (according to OpenSanctions). If you think that I have > such a relationship or should be rejected for any other reasons, please > simply > reject my OCA submission, instead of hanging it for months. > > As I no longer have enough interest and spare time to work on OpenJDK, I > decided to give up upstreaming those patches. > If anyone is interested in them, please feel free to pick up and submit > these > patches, most of which are small but I believe they are useful. > As OCA requires that "each contribution that you submit is and shall be an > original work of authorship", you may rewrite my patches from scratch so > it is > an original work, and you don't need to sign my name or ping me. > > I would like to give a list of the patches that I wanted to upstream but > failed: > > - Checks if "llvm-config" is broken: > https://github.com/AOSC-Tracking/jdk/commit/ > 6a8b12b1ad700d994a2803de593ca06e698ef1a9 > - Extend default thread stack size for zero: > This addresses the stack overflow exception in javac when building JDK 24 > with > zero variants. > https://github.com/AOSC-Tracking/jdk/commit/ > 4534fcaafc149f649105dc9914c7cf4aaf8c802c > https://www.mail-archive.com/build-dev at openjdk.org/msg14818.html > > Some patches that are not for the upstream OpenJDK but Loongson's fork of > JDK > and were also blocked by OCA: > https://github.com/loongson/jdk/pull/134 > https://github.com/loongson/jdk/pull/126 > https://github.com/loongson/jdk/pull/125 > https://github.com/loongson/jdk/pull/135 > https://github.com/loongson/jdk/pull/136 > https://github.com/AOSC-Tracking/jdk/commit/ > 913dcb2b2759437876ae3a40a1b074eeb1bfe09f > https://github.com/AOSC-Tracking/jdk/commit/ > caba8e6de73fd9ffa078d6c257d6be8500b9d16a > > Best wishes, > Bye. > -- > Bingwu Zhang (a.k.a. xtex) @ Sat, 31 Jan 2026 08:42:31 +0000 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Sat Jan 31 16:29:10 2026 From: davidalayachew at gmail.com (David Alayachew) Date: Sat, 31 Jan 2026 11:29:10 -0500 Subject: Giving up upstream-ing my patches & feel free to pick them up In-Reply-To: References: <4555062.ejJDZkT8p0@xtex1> Message-ID: In fact, I just looked. It actually took 3.5 months for mine to get approved. Request made -- April 11 2022 Request approved -- July 27 2022 All of that to say, your experience is, sadly, common. If you have any patience left to exercise, would you be willing to wait a little longer? I can make much louder noise than you can. Let me bang on the door, and get this done quickly. Would you accept that xtex? On Sat, Jan 31, 2026, 10:59?AM David Alayachew wrote: > Sorry to hear this. > > If it makes you feel better, I am born and raised in America, currently > live in Washington DC, and I still had to wait over 2 months for mine to be > done. > > @Dalibor Topic , can we get this prioritized? > > On Sat, Jan 31, 2026, 4:52?AM xtex wrote: > >> Hi, >> >> About one year ago, in Jan. 2025, I began my adventure of the OpenJDK >> codebase. Later I attempted to make some patches into the repository. >> I checked the documentation and learned that I have to sign an Oracle >> Contributor Agreement before submitting patches to OpenJDK. At that time, >> I >> dreamed that it was just a pretty normal CLA, like the ones I signed for >> other >> projects and shall just take at most several days. >> >> A few days later, I received an email asking me to update some >> information in >> the agreement. I did. After that, I have sent 5 emails to >> opensource_ww_grp at oracle.com asking if there was anything wrong (once a >> month >> from January to May). For each of my emails, I got a reply, saying that >> they >> "sincerely apologize" and "@Dalibor Topic Can you please review...", with >> no >> actual progress being made. Now it has been (more than) one year since I >> submitted my first OCA submission. And I have been tired of "/touch"-ing >> my PR >> once a month. >> >> I wonder if there is a reason for not reviewing my OCA submission. I do >> live >> in Chinese Mainland but I have no contractual or subordinate or teacher- >> student relationship with any entities that are restricted by the US >> import/ >> export control laws (according to OpenSanctions). If you think that I >> have >> such a relationship or should be rejected for any other reasons, please >> simply >> reject my OCA submission, instead of hanging it for months. >> >> As I no longer have enough interest and spare time to work on OpenJDK, I >> decided to give up upstreaming those patches. >> If anyone is interested in them, please feel free to pick up and submit >> these >> patches, most of which are small but I believe they are useful. >> As OCA requires that "each contribution that you submit is and shall be >> an >> original work of authorship", you may rewrite my patches from scratch so >> it is >> an original work, and you don't need to sign my name or ping me. >> >> I would like to give a list of the patches that I wanted to upstream but >> failed: >> >> - Checks if "llvm-config" is broken: >> https://github.com/AOSC-Tracking/jdk/commit/ >> 6a8b12b1ad700d994a2803de593ca06e698ef1a9 >> - Extend default thread stack size for zero: >> This addresses the stack overflow exception in javac when building JDK 24 >> with >> zero variants. >> https://github.com/AOSC-Tracking/jdk/commit/ >> 4534fcaafc149f649105dc9914c7cf4aaf8c802c >> https://www.mail-archive.com/build-dev at openjdk.org/msg14818.html >> >> Some patches that are not for the upstream OpenJDK but Loongson's fork of >> JDK >> and were also blocked by OCA: >> https://github.com/loongson/jdk/pull/134 >> https://github.com/loongson/jdk/pull/126 >> https://github.com/loongson/jdk/pull/125 >> https://github.com/loongson/jdk/pull/135 >> https://github.com/loongson/jdk/pull/136 >> https://github.com/AOSC-Tracking/jdk/commit/ >> 913dcb2b2759437876ae3a40a1b074eeb1bfe09f >> https://github.com/AOSC-Tracking/jdk/commit/ >> caba8e6de73fd9ffa078d6c257d6be8500b9d16a >> >> Best wishes, >> Bye. >> -- >> Bingwu Zhang (a.k.a. xtex) @ Sat, 31 Jan 2026 08:42:31 +0000 >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dalibor.topic at oracle.com Sat Jan 31 20:06:08 2026 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Sat, 31 Jan 2026 21:06:08 +0100 Subject: Giving up upstream-ing my patches & feel free to pick them up In-Reply-To: <4555062.ejJDZkT8p0@xtex1> References: <4555062.ejJDZkT8p0@xtex1> Message-ID: <3e35a936-a1f6-4328-b214-dba8fa0d6798@oracle.com> Hi, I'm sorry to hear your adventure with the OCA submission system wasn't as fun as you hoped it could be. As far as I can see, your first submission was on January 21 and marked as rejected (by me) on January 23rd. The second one was on January 24th and rejected (by me) on January 30th, after a thread we had about what needs to be corrected between January 25th and January 30th. Since you had some problems with the submissions system, I asked you to get in touch with the opensource team that runs the OCA submission system. Unfortunately, I do not see any further submissions from an 'xtex' address in the OCA system. I don't know why that's the case, if you've submitted another OCA for review later. But if it's not in the OCA system's queue for review, it can't be reviewed (by me). If you'd still like to submit a fresh OCA I'd be happy to review the new submission, of course. cheers, dalibor topic On 31/01/2026 10:51, xtex wrote: > Hi, > > About one year ago, in Jan. 2025, I began my adventure of the OpenJDK > codebase. Later I attempted to make some patches into the repository. > I checked the documentation and learned that I have to sign an Oracle > Contributor Agreement before submitting patches to OpenJDK. At that time, I > dreamed that it was just a pretty normal CLA, like the ones I signed for other > projects and shall just take at most several days. > > A few days later, I received an email asking me to update some information in > the agreement. I did. After that, I have sent 5 emails to > opensource_ww_grp at oracle.com asking if there was anything wrong (once a month > from January to May). For each of my emails, I got a reply, saying that they > "sincerely apologize" and "@Dalibor Topic Can you please review...", with no > actual progress being made. Now it has been (more than) one year since I > submitted my first OCA submission. And I have been tired of "/touch"-ing my PR > once a month. > > I wonder if there is a reason for not reviewing my OCA submission. I do live > in Chinese Mainland but I have no contractual or subordinate or teacher- > student relationship with any entities that are restricted by the US import/ > export control laws (according to OpenSanctions). If you think that I have > such a relationship or should be rejected for any other reasons, please simply > reject my OCA submission, instead of hanging it for months. > > As I no longer have enough interest and spare time to work on OpenJDK, I > decided to give up upstreaming those patches. > If anyone is interested in them, please feel free to pick up and submit these > patches, most of which are small but I believe they are useful. > As OCA requires that "each contribution that you submit is and shall be an > original work of authorship", you may rewrite my patches from scratch so it is > an original work, and you don't need to sign my name or ping me. > > I would like to give a list of the patches that I wanted to upstream but > failed: > > - Checks if "llvm-config" is broken: > https://github.com/AOSC-Tracking/jdk/commit/ > 6a8b12b1ad700d994a2803de593ca06e698ef1a9 > - Extend default thread stack size for zero: > This addresses the stack overflow exception in javac when building JDK 24 with > zero variants. > https://github.com/AOSC-Tracking/jdk/commit/ > 4534fcaafc149f649105dc9914c7cf4aaf8c802c > https://www.mail-archive.com/build-dev at openjdk.org/msg14818.html > > Some patches that are not for the upstream OpenJDK but Loongson's fork of JDK > and were also blocked by OCA: > https://github.com/loongson/jdk/pull/134 > https://github.com/loongson/jdk/pull/126 > https://github.com/loongson/jdk/pull/125 > https://github.com/loongson/jdk/pull/135 > https://github.com/loongson/jdk/pull/136 > https://github.com/AOSC-Tracking/jdk/commit/ > 913dcb2b2759437876ae3a40a1b074eeb1bfe09f > https://github.com/AOSC-Tracking/jdk/commit/ > caba8e6de73fd9ffa078d6c257d6be8500b9d16a > > Best wishes, > Bye. -- Dalibor Topic Consulting Product Manager Phone: +494089091214 , Mobile: +491737185961 Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann From xtex at envs.net Sat Jan 31 23:27:52 2026 From: xtex at envs.net (xtex) Date: Sun, 01 Feb 2026 07:27:52 +0800 Subject: Giving up upstream-ing my patches & feel free to pick them up In-Reply-To: <3e35a936-a1f6-4328-b214-dba8fa0d6798@oracle.com> References: <3e35a936-a1f6-4328-b214-dba8fa0d6798@oracle.com> Message-ID: <4716627.LvFx2qVVIh@xtex1> Hi. I am sorry for the confusion I caused. I withdrew my OCA submission (which IIRC was submitted in March) yesterday after sending out that email. I have submitted a new agreement just now. Thank you for looking into it. Please let me know if there is anything that I need to change. Thank you! -- xtex @ Sat, 31 Jan 2026 23:26:57 +0000